Oracle® Enterprise Manager

Cloud Control管理者ガイド

13cリリース1

E70363-03(原本部品番号:E60047-04)

2016年4月

Oracle Enterprise Manager Cloud Control管理者ガイド, 13cリリース1

E70363-03

Copyright © 2016, Oracle and/or its affiliatesAll 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およびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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

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

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

第I部 ターゲットの監視および管理

1 エンタープライズ・モニタリング

- 1.1 監視の概要

- 1.2 包括的な即時利用可能な監視

- 1.3 監視: 基本

- 1.3.1 メトリックしきい値: 監視対象の状況が問題である時点を判断

- 1.3.2 メトリック・ベースライン: 有効なメトリックしきい値の決定

- 1.3.3 高度なしきい値管理

- 1.3.4 イベント: 対象の状況を定義

- 1.3.5 修正処理: 問題の自動的な解決

- 1.3.6 メトリック拡張: 監視のカスタマイズ

- 1.3.7 ブラックアウトおよび通知ブラックアウト

- 1.4 監視: 高度な設定

- 1.4.1 監視テンプレート

- 1.4.2 管理グループおよびテンプレート・コレクション

- 1.4.3 アラート・メッセージのカスタマイズ

- 1.5 通知

- 1.5.1 通知のカスタマイズ

- 1.6 イベント、インシデントおよび問題の管理

- 1.6.1 インシデント・マネージャ

- 1.6.2 インシデント・ルールとルール・セット

- 1.6.3 コネクタ

- 1.7 監視情報へのアクセス

2 インシデント管理の使用

- 2.1 管理の概念

- 2.1.1 イベント管理

- 2.1.2 インシデント管理

- 2.1.2.1 インシデントの処理

- 2.1.2.2 単一イベントから構成されるインシデント

- 2.1.2.3 複数イベントから構成されるインシデント

- 2.1.2.4 インシデントの作成方法

- 2.1.3 問題管理

- 2.1.4 ルール・セット

- 2.1.4.1 即時利用可能なルール・セット

- 2.1.4.2 ルール・セット・タイプ

- 2.1.4.3 ルール

- 2.1.5 インシデント・マネージャ

- 2.1.5.1 ビュー

- 2.1.6 要約

- 2.2 インシデント管理環境の設定

- 2.2.1 監視インフラストラクチャの設定

- 2.2.1.1 ルール・セットの開発

- 2.2.2 管理者および権限の設定

- 2.2.3 モニタリング権限

- 2.2.4 ルール・セットの設定

- 2.2.4.1 ルール・セットの作成

- 2.2.4.2 ロールの作成によるインシデントの作成

- 2.2.4.3 インシデントのエスカレーションを管理するルールの作成

- 2.2.4.4 問題をエスカレートするルールの作成

- 2.2.4.5 ルール・セットのテスト

- 2.2.4.6 ルールからの電子メールを受信するためのサブスクライブ

- 2.2.4.7 プライベート・ルールに対する電子メールの受信

- 2.3 インシデントの処理

- 2.3.1 処理が必要な事項の発見

- 2.3.2 インシデントの検索

- 2.3.3 カスタム・ビューの設定

- 2.3.3.1 インシデント・ダッシュボード

- 2.3.4 カスタム・ビューの共有/共有解除

- 2.3.5 単純なインシデントへの応答および処理

- 2.3.6 複数のインシデント、イベントおよび問題への一括応答

- 2.3.7 My Oracle Supportナレッジの検索

- 2.3.8 サービス・リクエストのオープンの発行(問題のみ)

- 2.3.9 インシデントと問題の抑止

- 2.3.10 インシデントのワークロード分散の管理

- 2.3.11 定期的なイベントの確認

- 2.3.11.1 インシデントの手動作成

- 2.4 高度なトピック

- 2.4.1 自動診断リポジトリ(ADR): インシデントのフラッド制御

- 2.4.1.1 インシデント・マネージャを使用したADR診断インシデントの処理

- 2.4.1.2 インシデントのフラッド制御

- 2.4.2 カスタム・インシデント・ステータスの定義

- 2.4.2.1 新しい解決状態の作成

- 2.4.2.2 既存の解決状態の変更

- 2.4.3 メトリック・アラート・イベント・タイプのステートレス・アラートのクリア

- 2.4.4 手動でクリア可能なイベントの自動クリア

- 2.4.5 ユーザー報告のイベント

- 2.4.5.1 形式

- 2.4.5.2 オプション

- 2.4.5.3 例

- 2.4.6 追加のルール・アプリケーション

- 2.4.6.1 イベントの重大度状態別に異なる通知を送信するルールの設定

- 2.4.6.2 イベント・タイプに基づいて異なる管理者に通知するルールの作成

- 2.4.6.3 インシデントのチケットを作成するルールの作成

- 2.4.6.4 サード・パーティ・システムにSNMPトラップを送信するルールの作成

- 2.4.7 インシデント・ルールのエクスポートとインポート

- 2.4.7.1 Enterprise Managerコンソールを使用したルール・セットのエクスポート

- 2.4.7.2 Enterprise Managerコンソールを使用したルール・セットのインポート

- 2.4.7.3 EM CLIを使用したルール・セットのインポート

- 2.4.7.4 EM CLIを使用したルール・セットのエクスポート

- 2.4.8 イベントに対する修正処理の作成

- 2.4.9 1つのインシデントへの複数イベントの圧縮

- 2.4.10 イベントの優先度付け

- 2.4.11 根本原因分析(RCA)とターゲットの停止イベント

- 2.4.11.1 RCAの動作

- 2.4.11.2 インシデント・ルール・セットにおけるRCA結果の活用

- 2.4.11.3 インシデント・マネージャにおけるRCA結果の活用

- 2.4.11.4 システム・ダッシュボードにおけるRCA結果の活用

- 2.4.11.5 兆候以外のイベントのインシデント優先度を更新するルールの作成

- 2.4.11.6 兆候以外のイベントのインシデントの作成

- 2.4.11.7 遅延時間の概要

- 2.5 Enterprise Manager 10/11gから12c以上への移行

- 監視: 一般的なタスク

- 電子メール・ゲートウェイの設定

- メトリック・アラートの電子メール送信

- メトリック・アラートのSNMPトラップ送信

- イベント・コネクタへのイベント送信

- 異なる期間での異なる電子メール・アドレスへの電子メール送信

3 通知の使用

- 3.1 通知の設定

- 3.1.1 通知用のメール・サーバーの設定

- 3.1.2 自分用の電子メールの設定

- 3.1.2.1 電子メール・アドレスの定義

- 3.1.2.2 通知スケジュールの設定

- 3.1.2.3 インシデント・ルールの電子メールを受信するようにサブスクライブ

- 3.1.3 他の管理者のための電子メールの設定

- 3.1.4 電子メールのカスタマイズ

- 3.1.4.1 電子メールのカスタマイズのリファレンス

- 3.1.5 繰返し通知の設定

- 3.2 電子メール以外の通知の拡張

- 3.3 OSコマンドおよびスクリプトを使用した通知の送信

- 3.3.1 スクリプト例

- 3.3.2 12cより前のOSコマンド・スクリプトの移行

- 3.3.2.1 メトリック・アラート・イベント・タイプの移行

- 3.3.2.2 ターゲット可用性イベント・タイプの移行

- 3.3.2.3 ジョブ・ステータス変更イベント・タイプの移行

- 3.3.2.4 修正処理関連のOSスクリプトの移行

- 3.3.2.5 通知タイプのマッピング

- 3.4 PL/SQLプロシージャを使用した通知の送信

- 3.4.1 PL/SQLベースの通知メソッドの定義

- 3.4.2 12cより前のPL/SQL拡張通知メソッドの移行

- 3.4.2.1 MGMT_NOTIFY_SEVERITYのマッピング

- 3.4.2.2 MGMT_NOTIFY_JOBのマッピング

- 3.4.2.3 MGMT_NOTIFY_CORRECTIVE_ACTIONのマッピング

- 3.5 サード・パーティ・システムへのSNMPトラップの送信

- 3.5.1 SNMPバージョン1とSNMPバージョン3

- 3.5.2 SNMP V3トラップ通知メソッドの操作

- 3.5.2.1 SNMPトラップ通知を送信するOMSの構成

- 3.5.2.2 SNMP V3トラップ通知メソッドの作成/編集

- 3.5.2.3 ユーザー・セキュリティ・モデル・エントリの編集

- 3.5.2.4 使用可能なSNMP V3トラップ通知メソッドの表示

- 3.5.2.5 SNMP V3トラップ通知メソッドの削除

- 3.5.3 SNMP V1トラップの作成

- 3.5.4 SNMPトラップ: 以前のEnterprise Managerリリースから12c以上への移行

- 3.6 管理情報ベース(MIB)

- 3.6.1 MIBについて

- 3.6.2 MIB定義

- 3.6.3 MIB変数の説明の解釈

- 3.6.3.1 変数名

- 3.7 修正処理ステータス変更情報の受渡し

- 3.7.1 OSコマンドまたはスクリプトへの修正処理実行ステータスの受渡し

- 3.7.2 PL/SQLプロシージャへの修正処理実行ステータスの受渡し

- 3.8 ジョブ実行ステータス情報の受渡し

- 3.8.1 PL/SQLプロシージャへのジョブ実行ステータスの受渡し

- 3.8.2 OSコマンドまたはスクリプトへのジョブ実行ステータスの受渡し

- 3.9 ユーザー定義のターゲット・プロパティの通知メソッドへの受渡し

- 3.10 通知のリファレンス

- 3.10.1 EMOMSプロパティ

- 3.10.2 OSコマンドまたはスクリプトへのイベント、インシデント、問題情報の受渡し

- 3.10.2.1 イベント、インシデントおよび問題に共通の環境変数

- 3.10.2.2 イベント通知固有の環境変数

- 3.10.2.3 イベント・タイプに固有の環境変数

- 3.10.2.4 インシデント通知に固有の環境変数

- 3.10.2.5 問題通知に固有の環境変数

- 3.10.2.6 インシデントおよび問題通知に共通の環境変数

- 3.10.3 PL/SQLプロシージャへの情報の受渡し

- 3.10.3.1 イベント・タイプに固有の通知ペイロード要素

- 3.10.4 通知に関するトラブルシューティング

- 3.10.4.1 一般的な設定

- 3.10.4.2 通知システムのエラー

- 3.10.4.3 通知システムのトレース・メッセージ

- 3.10.4.4 電子メールのエラー

- 3.10.4.5 OSコマンドのエラー

- 3.10.4.6 SNMPトラップのエラー

- 3.10.4.7 PL/SQLエラー

- 3.11 システム・ブロードキャスト

4 ブラックアウトと通知ブラックアウトの使用方法

- 4.1 ブラックアウトおよび通知ブラックアウト

- 4.1.1 ブラックアウトについて

- 4.1.2 通知ブラックアウトについて

- 4.2 ブラックアウト/通知ブラックアウトの処理

- 4.2.1 ブラックアウト/通知ブラックアウトの作成

- 4.2.2 ブラックアウト/通知ブラックアウトの編集

- 4.2.3 ブラックアウト/通知ブラックアウトの表示

- 4.2.4 終了したブラックアウト/通知ブラックアウトのパージ

- 4.3 コマンドライン・ユーティリティを使用したブラックアウトの制御

- 4.4 ブラックアウト・ベスト・エフォート

- 4.4.1 ブラックアウト・ベスト・エフォートを使用する状況

5 グループの管理

- 5.1 グループの概要

- 5.1.1 グループの概要

- 5.1.2 権限伝播グループの概要

- 5.1.3 動的グループの概要

- 5.1.4 管理グループの概要

- 5.1.5 使用するグループのタイプの選択

- 5.2 グループの管理

- 5.2.1 グループの作成および編集

- 5.2.2 動的グループの作成

- 5.2.3 権限伝播グループへのメンバーの追加

- 5.2.4 権限伝播グループへの従来のグループの変換

- 5.2.5 グループの表示および管理

- 5.2.6 グループ・チャートの概要

- 5.2.7 グループ・メンバーの概要

- 5.2.8 グループ・ステータス履歴の表示

- 5.2.9 システム・ダッシュボードとは

- 5.3 即時利用可能なレポートの使用

6 管理グループの使用

- 6.1 管理グループとは

- 6.1.1 管理グループの開発

- 6.2 管理グループの計画

- 6.3 管理グループおよびテンプレート・コレクションの実装

- 6.3.1 管理グループ階層の作成

- 6.3.2 管理グループのホームページへのアクセス

- 6.3.3 階層の定義

- 6.3.4 テンプレート・コレクションの定義

- 6.3.4.1 必要な権限

- 6.3.4.2 修正処理の資格証明

- 6.3.5 テンプレート・コレクションと管理グループの関連付け

- 6.3.5.1 管理グループへのテンプレート・コレクションの関連付け

- 6.3.5.2 管理グループの検索

- 6.3.5.3 グローバル同期スケジュールの設定

- 6.3.5.4 テンプレート・コレクションが同期化されるタイミング

- 6.3.5.5 同期ステータスの表示

- 6.3.5.6 グループ・メンバーのタイプと同期化

- 6.3.5.7 システム・ターゲットおよび管理グループ

- 6.3.5.8 テンプレート・コレクションとグループの関連付けの解除

- 6.3.5.9 集約(グループ管理)設定の表示

- 6.3.5.10 管理グループ・ホームページの表示

- 6.3.5.11 任意の管理グループの一部でないターゲットの識別

- 6.4 管理グループ階層の変更

- 6.4.1 新しい階層レベルの追加

- 6.4.2 階層レベルの削除

- 6.4.3 管理グループのマージ

- 6.4.4 管理グループの削除

7 監視テンプレートの使用

- 7.1 監視テンプレートについて

- 7.2 監視テンプレートの定義

- 7.3 デフォルト・テンプレート(自動適用テンプレート)

- 7.4 監視テンプレートのリスト表示

- 7.5 監視テンプレートの作成

- 7.6 監視テンプレートの編集

- 7.7 ターゲットへの監視テンプレートの適用

- 7.7.1 監視テンプレートの適用

- 7.7.2 監視テンプレートの適用オプション

- 7.7.2.1 適用オプション

- 7.7.2.2 キー値設定を持つメトリック

- 7.8 ターゲットとの監視テンプレートの比較

- 7.8.1 テンプレートとターゲットのメトリックが異なると判断される場合

- 7.9 情報パブリッシャを使用したメトリック設定の比較

- 7.10 監視テンプレートのエクスポートとインポート

- 7.11 Enterprise Managerのアップグレード: 監視テンプレートの比較

- 7.12 監視テンプレート適用履歴保存期間の変更

8 メトリック拡張の使用

- 8.1 メトリック拡張とは

- 8.2 メトリック拡張のライフサイクル

- 8.3 メトリック拡張の使用

- 8.3.1 管理者権限の要件

- 8.3.2 「メトリック拡張の作成」権限の付与

- 8.3.3 管理者権限の管理

- 8.3.4 メトリック拡張への管理者アクセスの管理

- 8.3.4.1 メトリック拡張の完全/編集権限の付与

- 8.3.4.2 トリック拡張のアクセス権限の取消し

- 8.3.4.3 メトリック拡張の所有権の転送

- 8.3.5 新しいメトリック拡張の作成

- 8.3.6 新しいメトリック拡張の作成(類似作成)

- 8.3.7 メトリック拡張の編集

- 8.3.8 既存のメトリック拡張の新バージョンの作成

- 8.3.9 メトリック拡張のインポート

- 8.3.10 メトリック拡張のエクスポート

- 8.3.11 メトリック拡張の削除

- 8.3.12 ターゲットのグループへのメトリック拡張のデプロイ

- 8.3.13 メトリック拡張から電子メールを送信するためのインシデント・ルールの作成

- 8.3.14 ターゲットのグループにデプロイ済でバージョンの古いメトリック拡張の更新

- 8.3.15 リポジトリ側メトリック拡張の作成

- 8.4 アダプタ

- 8.4.1 OSコマンド・アダプタ - 単一列

- 8.4.2 OSコマンド・アダプタ - 複数値

- 8.4.3 OSコマンド・アダプタ - 複数列

- 8.4.4 SQLアダプタ

- 8.4.5 SNMP(Simple Network Management Protocol)アダプタ

- 8.4.6 JMXアダプタ

- 8.5 メトリック拡張へのユーザー定義メトリックの変換

- 8.5.1 概要

- 8.5.2 コマンド

- 8.6 メトリック拡張のコマンドライン動詞

9 高度なしきい値管理

- 9.1 「高度なしきい値管理」ページへのアクセス

- 9.2 適応しきい値

- 9.2.1 適応しきい値メトリックの登録

- 9.2.2 適応しきい値の構成

- 9.2.3 適応しきい値が正しいことの確認

- 9.2.4 適応メトリックしきい値のテスト

- 9.2.5 適応しきい値メトリックの登録解除

- 9.2.6 モニタリング・テンプレートを使用した適応しきい値の設定

- 9.3 時間ベースの静的しきい値

- 9.3.1 時間ベースの静的しきい値の登録

- 9.3.2 時間ベースの静的しきい値の登録解除

- 9.4 有効なメトリックしきい値の確認

10 ジョブ・システムと修正処理の使用

- 10.1 ジョブ・システムの目的および概要

- 10.1.1 「ジョブ・アクティビティ・サマリー」表ビューの変更

- 10.1.2 ジョブ検索

- 10.1.2.1 ジョブ検索の保存

- 10.1.2.2 保存済ジョブ検索の編集

- 10.1.2.3 保存済ジョブ検索のインポート

- 10.1.3 個別ジョブ実行とジョブ実行について

- 10.1.3.1 ジョブ実行

- 10.1.3.2 ジョブ実行

- 10.1.4 個別ジョブ実行とジョブ実行の操作

- 10.2 事前の考慮事項

- 10.2.1 管理者ロール

- 10.2.2 スクリプトの作成

- 10.2.3 ジョブ職責の共有

- 10.2.4 グループに対するジョブの発行

- 10.3 ジョブの作成

- 10.3.1 ジョブ・タイプの選択

- 10.3.2 OSコマンド・ジョブの作成

- 10.3.2.1 単一操作の指定

- 10.3.2.2 スクリプトの指定

- 10.3.2.3 アクセス・レベルのルール

- 10.3.3 SQLスクリプト・ジョブの作成

- 10.3.3.1 ターゲットの指定

- 10.3.3.2 パラメータ・ページのオプションの指定

- 10.3.3.3 ホスト資格証明とデータベース資格証明の指定

- 10.3.3.4 SQLスクリプト・ジョブからのエラー・コードの戻り

- 10.3.4 マルチタスク・ジョブの作成

- 10.3.4.1 ジョブの機能

- 10.3.4.2 マルチタスクのジョブのターゲットの指定

- 10.3.4.3 ジョブへのタスクの追加

- 10.4 ジョブ・ステータスの表示と分析

- 10.5 ジョブ・イベント基準の生成

- 10.5.1 ジョブ・ステータス、ステータス重大度およびターゲットのないジョブのイベントの有効化

- 10.5.2 ジョブ・ステータスのイベントを生成するためのターゲットの追加

- 10.6 ジョブ・ステータス変更イベントのイベント・ルールの作成

- 10.6.1 ジョブのジョブ・ステータス変更イベント・ルールの作成

- 10.6.2 ターゲットのジョブ・ステータス変更イベント・ルールの作成

- 10.7 診断ツールの使用

- 10.7.1 ジョブ・ロギングの有効化

- 10.7.2 ジョブ・ロギングの表示

- 10.7.3 失敗したジョブのデバッグ

- 10.7.4 失敗したジョブに関連するインシデントの確認

- 10.7.5 ジョブ・ステップで生成されるインシデントのパッケージ化

- 10.7.6 リモート・ログ・ファイルの表示

- 10.7.7 Cloud Control管理ツールによる問題の診断

- 10.7.7.1 状態の概要

- 10.7.7.2 リポジトリ・ホームページ

- 10.7.7.3 管理サービスとリポジトリ: すべてのメトリック

- 10.7.7.4 OMSとリポジトリ: 診断メトリック

- 10.7.7.5 OMSとリポジトリ: チャート

- 10.7.7.6 「管理サーバー」ページと「ジョブ・アクティビティ詳細」ページ

- 10.7.7.7 ジョブ・システム・レポート

- 10.8 修正処理の作成

- 10.8.1 資格証明の指定

- 10.8.2 メトリックに対する修正処理の作成

- 10.8.3 ライブラリの修正処理の作成

- 10.8.4 修正処理のアクセスの指定

- 10.8.4.1 アクセスの定義または変更

- 10.8.4.2 アクセス・レベルのルール

- 10.8.5 修正処理の通知の設定

- 10.8.6 エージェント側のレスポンス処理の用意

- 10.8.6.1 コマンドとスクリプトの指定

- 10.8.6.2 コマンドでのターゲット・プロパティの使用

- 10.8.6.3 拡張機能の使用

- 10.8.7 修正処理の実行の詳細の表示

11 ターゲットに構成されたアクセス・ポイントのモニタリング

- 11.1 アクセス・ポイントのモニタリングの概要

- 11.2 ターゲットに構成されているアクセス・ポイント・リストの表示

- 11.3 ターゲットに構成されているアクセス・ポイントの削除

- 11.4 ターゲットの機能メトリック・マップの表示

- 11.5 ターゲットでサポートされている様々な操作に最適なアクセス・ポイント・インプリメンタ(およびその履歴)の表示

- 11.6 ターゲットに構成されているアクセス・ポイントのモニタリング・プロパティの変更または再構成

- 11.7 ターゲットに構成されたアクセス・ポイントを管理するためのEM CLI動詞

12 Always-On Monitoring

- 12.1 ベスト・プラクティス

- 12.2 Always-On Monitoringのインストール

- 12.2.1 Always-On Monitoringリポジトリ・データベースのインストール

- 12.2.1.1 データベースのサイズ設定

- 12.2.1.2 データベース文字セットの定義

- 12.2.2 Always-On Monitoringリポジトリ・ユーザーの作成

- 12.2.2.1 Always-On Monitoringスキーマ所有者への必要な権限の付与

- 12.2.3 Always-On Monitoringのインストール

- 12.3 Always-On Monitoringの構成

- 12.3.1 Always-On Monitoring構成アシスタント(EMSCA)の使用方法

- 12.3.2 Enterprise Managerでの電子メール・サーバーの構成

- 12.3.3 Enterprise Managerでの停止時連絡先の構成

- 12.3.4 Always-On MonitoringとEnterprise Managerの初回同期

- 12.3.5 Enterprise ManagerとAlways-On Monitoringの連動の構成

- 12.3.6 Enterprise ManagerでのAlways-On MonitoringアップロードURLの確認

- 12.4 EMキーの保存

- 12.5 サービスの制御

- 12.5.1 Always-On Monitoringのコマンド

- 12.6 Always-On Monitoringの更新

- 12.7 データ・メンテナンス

- 12.8 Always-On Monitoring構成設定の制御

- 12.9 パフォーマンス情報の取得

- 12.10 変更可能なAlways-On Monitoringのプロパティ

- 12.11 問題の診断

- 12.12 高可用性および障害時リカバリ

- 12.12.1 複数のAlways-On Monitoringインスタンスの実行

- 12.12.1.1 複数インスタンスの共有構成ストレージ

- 12.12.1.2 受信アラートを追跡するための通知キュー

- 12.12.1.3 タスク・スケジューラ・システム

- 12.12.1.4 SLBの構成

- 12.12.2 Always-On Monitoringの障害時リカバリ

第II部 検出

13 ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- 13.1 ターゲットの検出および追加の概要

- 13.1.1 検出の用語の理解

- 13.1.1.1 ターゲットおよび管理対象ターゲットとは

- 13.1.1.2 検出とは

- 13.1.1.3 昇格とは

- 13.1.2 ターゲット検出のオプション

- 13.1.3 Enterprise Managerライフサイクルでの検出および監視

- 13.1.4 検出および監視プロセス

- 13.2 ホスト・ターゲットの検出および追加

- 13.2.1 ホスト・ターゲットの自動検出の構成

- 13.2.1.1 ホスト・ターゲットの自動検出の前提条件

- 13.2.1.2 ホスト・ターゲットの自動検出の設定

- 13.2.2 手動のガイド付き検出プロセスを使用したホスト・ターゲットの追加

- 13.3 非ホスト・ターゲットの検出および追加

- 13.3.1 非ホスト・ターゲットの自動検出の構成

- 13.3.2 ガイド付き検出プロセスを使用した非ホスト・ターゲットの追加

- 13.3.3 宣言的プロセスを使用した非ホスト・ターゲットの追加

- 13.4 Oracleホームの検出および昇格

- 13.5 削除済ターゲットの取得

- 13.5.1 削除済ターゲット・タイプの取得

- 13.5.2 削除済ホストと対応する管理エージェント・ターゲットの取得

14 データベース・ターゲットの検出および追加

- 14.1 データベース・ターゲットの自動検出の有効化

- 14.2 コンテナ・データベース・ターゲットおよびプラガブル・データベース・ターゲットの検出および追加

- 14.2.1 自動検出を使用したCDBターゲットおよびPDBターゲットの検出

- 14.2.2 ガイド付き検出プロセスを使用したCDBターゲットおよびPDBターゲットの追加

- 14.2.3 宣言的プロセスを使用したCDBターゲットおよびPDBターゲットの追加

- 14.3 クラスタ・データベース・ターゲットの検出および追加

- 14.3.1 自動検出を使用したクラスタ・データベース・ターゲットの検出

- 14.3.2 ガイド付き検出プロセスを使用したクラスタ・データベース・ターゲットの追加

- 14.3.3 宣言的プロセスを使用したクラスタ・データベース・ターゲットの追加

- 14.4 単一インスタンス・データベース・ターゲットの検出および追加

- 14.4.1 自動検出を使用した単一インスタンス・データベース・ターゲットの検出

- 14.4.2 ガイド付き検出プロセスを使用した単一インスタンス・データベース・ターゲットの追加

- 14.4.3 宣言的プロセスを使用した単一インスタンス・データベース・ターゲットの追加

- 14.5 クラスタ・ターゲットの検出および追加

- 14.5.1 自動検出を使用したクラスタ・ターゲットの検出

- 14.5.2 ガイド付き検出プロセスを使用したクラスタ・ターゲットの追加

- 14.5.3 宣言的プロセスを使用したクラスタ・ターゲットの追加

- 14.6 単一インスタンス高可用性サービス・ターゲットの検出および追加

- 14.6.1 自動検出を使用した単一インスタンス高可用性サービス・ターゲットの検出

- 14.6.2 ガイド付き検出プロセスを使用した単一インスタンス高可用性サービス・ターゲットの追加

- 14.6.3 宣言的プロセスを使用した単一インスタンス高可用性サービス・ターゲットの追加

- 14.7 クラスタの自動ストレージ管理ターゲットの検出および追加

- 14.7.1 自動検出を使用したクラスタASMターゲットの検出

- 14.7.2 ガイド付き検出プロセスを使用したクラスタASMターゲットの追加

- 14.7.3 宣言的プロセスを使用したクラスタASMターゲットの追加

- 14.8 セキュアな監視のターゲット・データベースの構成

- 14.8.1 データベースのセキュア・モニタリングについて

- 14.8.2 セキュアな監視のターゲット・データベースの構成

15 ミドルウェア・ターゲットの検出および追加

- 15.1 WebLogicドメインの検出および追加

- 15.1.1 自動検出を使用したWebLogicドメインの検出

- 15.1.2 ガイド付き検出プロセスを使用したWebLogicドメインの追加

- 15.1.3 EM CLIを使用した複数のWebLogicドメインの追加

- 15.2 新規または変更されたドメイン・メンバーの検出

- 15.2.1 新規ドメイン・メンバーの自動検出の有効化

- 15.2.2 新規または変更されたドメイン・メンバーの手動チェック

- 15.3 スタンドアロンOracle HTTP Serverの追加

- 15.3.1 前提条件の確認

- 15.3.2 ガイド付き検出プロセスを使用したスタンドアロンのOracle HTTP Serverの追加

- 15.4 Exalyticsターゲットの追加

- 15.4.1 前提条件の確認

- 15.4.2 ガイド付き検出プロセスを使用したExalyticsシステム・ターゲットの追加

- 15.5 ミドルウェア・ターゲットの削除

16 システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- 16.1 システム・インフラストラクチャ・ターゲットの検出、昇格および追加について

- 16.2 オペレーティング・システムの検出および昇格

- 16.3 Oracle Solarisゾーンの検出および昇格

- 16.4 Oracle VM Server for SPARCの検出および昇格

- 16.5 サーバーの検出および昇格

- 16.5.1 ユーザー・インタフェースを使用したILOMサーバーの検出

- 16.5.2 コマンドライン・インタフェースを使用したILOMサーバーの検出

- 16.5.3 検出されたILOMサーバーの表示名の変更

- 16.6 Oracle SuperClusterの検出および昇格

- 16.6.1 前提条件

- 16.6.2 検出事前チェック・スクリプトの取得

- 16.6.3 検出事前チェック・スクリプトの実行

- 16.6.4 Oracle SuperCluster検出に必要な資格証明

- 16.6.5 手動での前提条件の検証

- 16.6.6 Oracle SuperCluster検出

- 16.7 PDUの検出および昇格

- 16.7.1 PDU v1 NMSテーブルおよびTrap Hosts Setupテーブルの確認

- 16.7.2 PDU v2 NMSテーブルおよびTrap Hosts Setupテーブルの確認

- 16.7.3 Enterprise ManagerでのPDU検出

- 16.7.4 コマンドライン・インタフェースを使用したPDUの検出

- 16.8 Oracle ZFS Storageの検出および昇格

- 16.8.1 Oracle ZFS Storage Applianceの検出

- 16.8.1.1 Oracle ZFS Storage Applianceのターゲット・メンバー

- 16.8.1.2 Oracle ZFS Storage Applianceクラスタのターゲット・メンバー

- 16.9 ファブリックの検出

- 16.9.1 インフィニバンド・ネットワーク・スイッチの検出

- 16.9.2 イーサネット・ネットワーク・スイッチの検出

- 16.9.3 コマンドラインを使用したスイッチの検出

- 16.10 システム・インフラストラクチャ・ターゲットの検出および昇格の関連リソース

第III部 Hybrid Cloud Management

17Hybrid Cloud Managementの有効化

- 17.1 サポートされていない機能のリスト

- 17.2Hybrid Cloud Managementに関する用語の概要

- 17.3 Hybrid Cloud Managementの開始

- 17.4 Hybrid Cloudアーキテクチャと通信の概要

- 17.5 Hybrid Cloud Gatewayエージェントを構成するための前提条件

- 17.6 Hybrid Cloud Gatewayエージェントとしての管理エージェントの構成

- 17.7 Hybrid Cloud Gatewayエージェントを有効化してOracle Cloudと通信するための外部プロキシの構成

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

- 17.9 Hybrid Cloudエージェントのインストール

- 17.9.1 ホスト・ターゲットの追加ウィザードを使用したHybrid Cloudエージェントのインストール

- 17.9.2 EM CLIを使用したHybrid Cloudエージェントのインストール

- 17.10 Hybrid Cloud GatewayエージェントおよびHybrid Cloudエージェントのアップグレード

- 17.11 Hybrid Cloud Managementの追加タスクの実行

- 17.11.1 高可用性確保のためのHybrid Cloudエージェントの構成(推奨)

- 17.11.2 Hybrid Cloud Gatewayエージェントの無効化

- 17.11.3 Hybrid Cloud GatewayエージェントとHybrid Cloudエージェントとの関連付けの解除

- 17.11.4 Hybrid Cloudエージェントの廃止

- 17.12 Hybrid CloudエージェントとHybrid Cloud Gatewayエージェントへのパッチの適用

- 17.13 Oracle Cloudターゲットの検出および監視

- 17.14 Hybrid Cloud Managementに関するよくある質問

- 17.14.1 Oracle Cloud仮想ホストにHybrid Cloudエージェントがデプロイされている場合、同じ仮想ホストに他のHybrid Cloudエージェントをデプロイすることはできますか。

- 17.14.2 関連付けられているHybrid CloudエージェントをアンインストールせずにHybrid Cloud Gatewayエージェントのアンインストールと構成解除を行えますか。

- 17.14.3 他に何もアンインストールせずにHybrid Cloud Gatewayエージェントを他のホストに再配置するにはどうすればよいですか。

- 17.14.4 Hybrid Cloud Gatewayエージェントを追加した後になって接続を再分配するにはどうすればよいですか。再構成が必要ですか。

- 17.14.5 Oracle Cloud PortalからOracle PaaSインスタンスを廃止した後、Hybrid CloudエージェントおよびEnterprise Manager Cloud Controlコンソールの関連ターゲットに対し行う必要があることは何ですか。

- 17.14.6 Oracle CloudでSSHキーを変更した場合、Enterprise Managerでは何をすればよいですか。

- 17.14.7 Hybrid Cloud Gatewayエージェントの数を決めるための指標は何ですか。Hybrid Cloud Gatewayエージェントが過負荷になっていることを示す兆候は何ですか。

- 17.14.8 高可用性を得るために複数のHybrid Cloud Gatewayエージェントを構成した状態で、Hybrid Cloud Gatewayエージェントのうち1つにパッチを適用したところ、モニタリングが他のHybrid Cloud Gatewayエージェントに切り替わりました。最初のHybrid Cloud Gatewayエージェントをパッチ適用後に起動すれば、Hybrid Cloudエージェントをモニターするようになるのでしょうか。

- 17.14.9 Hybrid CloudエージェントおよびOracle Cloudのターゲットでのユーザーに対する制限は何ですか。

- 17.14.10 どんなオペレーティング・システムにHybrid CloudエージェントおよびHybrid Cloud Gatewayエージェントをデプロイできますか。

18 Hybrid CloudへのJVMDのデプロイ

- 18.1 Hybrid CloudへのJVMDデプロイの概要

- 18.2 Oracle Cloud仮想ホストにJVMDエージェントをデプロイするための前提条件

- 18.3 Oracle Cloud仮想ホストへのJVMDエージェントのデプロイ

- 18.4 Hybrid Cloud Gatewayエージェントに対するデフォルトJVMDエンド・ポイントの変更

- 18.5 Oracle Cloud仮想ホストへのJVMDエージェントのデプロイ終了後

第IV部 Cloud Controlの管理

19 Enterprise Managerの管理

- 19.1 概要: Managerの管理

- 19.2 状態の概要

- 19.2.1 Enterprise Managerのトポロジとチャートの表示

- 19.2.2 Enterprise Managerのページ・パフォーマンスの確認

- 19.3 リポジトリ

- 19.3.1 「リポジトリ」タブ

- 19.3.2 「メトリック」タブ

- 19.3.3 「スキーマ」タブ

- 19.4 管理エージェントの制御と構成

- 19.4.1 Cloud Controlエージェントの管理ページ

- 19.4.2 エージェント・ホームページ

- 19.4.3 単一エージェントの制御

- 19.4.4 単一管理エージェントの構成

- 19.4.5 複数の管理エージェントの制御

- 19.4.6 複数のエージェントの構成

- 19.4.7 複数の管理エージェントのアップグレード

- 19.5 管理サーバー

20 管理リポジトリのメンテナンスおよびトラブルシューティング

- 20.1 管理リポジトリのデプロイメント・ガイドライン

- 20.2 管理リポジトリのデータ保持ポリシー

- 20.2.1 管理リポジトリの集計とパージのデフォルトのポリシー

- 20.2.2 その他の管理データに関する管理リポジトリの集計およびパージのデフォルトのポリシー

- 20.2.3 集計およびパージのデフォルトのポリシーの変更

- 20.2.4 ジョブ履歴の保存時間の変更方法

- 20.2.5 DBMS_SCHEDULERのトラブルシューティング

- 20.3 管理リポジトリの削除および再作成

- 20.3.1 管理リポジトリの削除

- 20.3.2 管理リポジトリの再作成

- 20.3.2.1 接続記述子を使用した管理リポジトリ・データベースの特定

- 20.4 管理リポジトリの作成エラーのトラブルシューティング

- 20.4.1 管理リポジトリの作成時に発生するパッケージ本体が存在しないエラー

- 20.4.2 管理リポジトリの作成時に発生するサーバー接続ハング・エラー

- 20.4.3 管理リポジトリを作成するための一般的なトラブルシューティング技法

- 20.5 クロス・プラットフォームのEnterprise Managerリポジトリの移行

- 20.5.1 一般的な前提条件

- 20.5.2 手法

- 20.5.2.1 クロス・プラットフォーム・トランスポータブル・データベースの使用方法

- 20.5.2.2 フィジカル・スタンバイを使用した移行

- 20.5.3 移行後の検証

21 Cloud Controlの更新

- 21.1 自己更新の使用方法

- 21.1.1 更新できる内容

- 21.2 自己更新の設定

- 21.2.1 Enterprise Manager自己更新モードの設定

- 21.2.2 ユーザーへの自己更新権限の割当て

- 21.2.3 ソフトウェア・ライブラリの設定

- 21.2.4 My Oracle Support優先資格証明の設定

- 21.2.5 My Oracle Support用のプロキシ詳細の登録

- 21.2.6 EM CLIユーティリティの設定(オプション)

- 21.3 更新の適用

- 21.3.1 オンライン・モードでの更新の適用

- 21.3.2 オフライン・モードでの更新の適用

- 21.4 情報更新へのアクセス

- 21.5 管理エージェント・ソフトウェアの取得または更新

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

- 22.1 ソフトウェア・ライブラリの概要

- 22.2 ユーザー、ロールおよび権限

- 22.3 ソフトウェア・ライブラリの新機能

- 22.4 EM CLI動詞またはグラフィカル・モードを使用したソフトウェア・ライブラリ・タスクの実行

- 22.5 ソフトウェア・ライブラリ記憶域

- 22.5.1 アップロード・ファイルの場所

- 22.5.2 参照先ファイルの場所

- 22.5.3 キャッシュ・ノード

- 22.6 ソフトウェア・ライブラリの構成に関する前提条件

- 22.7 ソフトウェア・ライブラリ記憶域の場所の構成

- 22.7.1 OMS共有ファイル・システムの場所の構成

- 22.7.2 OMSエージェント・ファイル・システムの場所の構成

- 22.7.3 参照されるファイルの場所の構成

- 22.8 複数OMSシステムでのソフトウェア・ライブラリの構成

- 22.9 ソフトウェア・ライブラリのキャッシュ・ノード

- 22.9.1 キャッシュ・ノードの構成

- 22.9.1.1 キャッシュ・ノードの追加

- 22.9.1.2 キャッシュ・ノードの編集

- 22.9.1.3 キャッシュ・ノードの削除

- 22.9.1.4 キャッシュ・ノードのアクティブ化または非アクティブ化

- 22.9.1.5 キャッシュ・ノードのクリア

- 22.9.1.6 キャッシュ・ノードの同期

- 22.9.2 キャッシュ・ノードのファイルのエクスポートおよびインポート

- 22.9.2.1 エクスポート

- 22.9.2.2 インポート

- 22.10 ソフトウェア・ライブラリ・ファイルの転送

- 22.11 ソフトウェア・ライブラリ・エンティティの使用

- 22.12 ソフトウェア・ライブラリのホームページを使用して実行できるタスク

- 22.12.1 エンティティの編成

- 22.12.2 エンティティの作成

- 22.12.2.1 汎用コンポーネントの作成

- 22.12.2.2 ディレクティブの作成

- 22.12.3 エンティティのカスタマイズ

- 22.12.4 エンティティの管理

- 22.12.4.1 ソフトウェア・ライブラリ・ホーム・ページへのアクセス

- 22.12.4.2 ソフトウェア・ライブラリの管理・ページへのアクセス

- 22.12.4.3 権限の付与または取消し

- 22.12.4.4 エンティティの移動

- 22.12.4.5 エンティティの成熟度の変更

- 22.12.4.6 エンティティへのノートの追加

- 22.12.4.7 エンティティへの添付ファイルの追加

- 22.12.4.8 エンティティの表示、編集および削除

- 22.12.4.9 削除されたエンティティのパージ

- 22.12.4.10 エンティティの検索

- 22.12.4.11 エンティティのエクスポート

- 22.12.4.12 エンティティのインポート

- 22.12.5 エンティティのステージング

- 22.13 ソフトウェア・ライブラリの管理

- 22.13.1 定期的なメンテナンス・タスク

- 22.13.2 Oracle所有エンティティ・ファイルの再インポート

- 22.13.3 ソフトウェア・ライブラリ記憶域の場所の削除(および移行)

- 22.13.4 参照先記憶域の場所の削除

- 22.13.5 記憶域の場所の非アクティブ化およびアクティブ化

- 22.13.6 パージ・ジョブのスケジュール

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

23 プラグインの管理

- 23.1 スタート・ガイド

- 23.2 プラグインの概要

- 23.2.1 Enterprise Managerの拡張性の枠組み

- 23.2.2 プラグイン

- 23.2.3 デフォルトでデプロイされるプラグイン

- 23.2.4 プラグイン・リリース

- 23.2.5 廃止および非推奨のプラグイン

- 23.2.6 プラグインを管理するために必要なロール

- 23.3 プラグインのデプロイ・ワークフロー

- 23.4 プラグイン・マネージャの概要

- 23.4.1 プラグイン・マネージャのアクセス

- 23.4.2 プラグイン・マネージャを使用した操作の実行

- 23.5 プラグインについて

- 23.5.1 表示のカスタマイズ

- 23.5.1.1 表示されるプラグインのカスタマイズ

- 23.5.1.2 表示される列のカスタマイズ

- 23.5.2 プラグインの可用性の確認

- 23.5.3 プラグインに関する情報の表示

- 23.5.3.1 プラグイン・リリースとEnterprise Managerプラットフォーム・リリースの違い

- 23.5.3.2 プラグインIDの識別

- 23.5.3.3 デプロイ済プラグインに対して動作保証済のターゲットおよびオペレーティング・システムの表示

- 23.5.3.4 プラグイン依存性の表示

- 23.5.3.5 デプロイ済プラグインの確認

- 23.6 プラグインのダウンロード、デプロイおよびアップグレード

- 23.6.1 プラグインのダウンロード

- 23.6.1.1 オンライン・モードでのプラグインのダウンロード

- 23.6.1.2 オフライン・モードでのプラグインのダウンロード

- 23.6.1.3 カタログ・アーカイブのインポート

- 23.6.1.4 プラグイン・アーカイブのインポート

- 23.6.2 Oracle Management Serviceへのプラグインのデプロイ(OMS再起動時間および停止時間の削減)

- 23.6.2.1 Oracle Management Serviceへのプラグインのデプロイメント・ステータスのトラッキング

- 23.6.3 Oracle Management Serviceにデプロイ済のプラグインのアップグレード

- 23.6.4 Oracle Management Agentへのプラグインのデプロイ

- 23.6.4.1 Oracle Management Agentへのプラグインのデプロイメント・ステータスのトラッキング

- 23.6.5 Oracle Management Agentにデプロイ済のプラグインのアップグレード

- 23.7 プラグインのアンデプロイ

- 23.7.1 Oracle Management Serviceからのプラグインのアンデプロイ

- 23.7.2 Oracle Management Agentからのプラグインのアンデプロイ

- 23.8 プラグインの高度な操作

- 23.8.1 Oracle Management Agentへのプラグインの再デプロイ

- 23.8.2 管理エージェントのデプロイまたはアップグレード中にプラグイン・パッチをデプロイ(カスタム・プラグイン更新の作成)

- 23.8.2.1 EMCLIを使用したカスタム・プラグイン更新の作成

- 23.8.2.2 EDKを使用したカスタム・プラグイン更新の作成

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

- 23.9.1 プラグイン・ホームについて

- 23.9.2 OMSプラグインのデプロイメントおよびアップグレードの問題のトラブルシューティング

- 23.9.2.1 OMSプラグインのデプロイメントの問題のトラブルシューティング

- 23.9.2.2 OMSプラグイン・アップグレードのロールバックおよび再開

- 23.9.3 管理エージェント・プラグインのデプロイメント、アップグレードおよびブロックの問題のトラブルシューティング

- 23.9.3.1 管理エージェント・プラグインのデプロイメントの問題のトラブルシューティング

- 23.9.3.2 管理エージェント・プラグインのアップグレードの問題のトラブルシューティング

- 23.9.3.3 管理エージェントのプラグインの不一致の解決

- 23.9.3.4 すべてのプラグインの不一致を解決するプラグインの不一致ジョブの実行

24 Oracle Management Serviceとリポジトリへのパッチ適用

- 24.1 OMSPatcherの自動化

- 24.1.1 サポートされるOMS構成およびOMSPatcherパッチ適用機能

- 24.1.2 OUIインベントリ構成

- 24.1.3 サポートされるパッチの形式

- 24.1.4 サポートされるパッチ適用手法

- 24.2 必須OMSPatcherパラメータ

- 24.2.1 プロパティ・ファイルの作成

- 24.3 OMSPatcherの実行の前提条件

- 24.4 OMSPatcherの使用方法

- 24.4.1 My Oracle Support: パッチの検索

- 24.4.2 omspatcher applyの実行

- 24.4.3 omspatcher rollbackの実行

- 24.4.4 omspatcher lspatchesの実行

- 24.4.5 omspatcher versionの実行

- 24.4.6 スタンバイOMSシステムへのパッチ適用

- OMSPatcherコマンド構文

- Apply

- Rollback

- lspatches

- version

- checkApplicable

- saveConfigurationSnapshot

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

- OMSPatcherトラブルシューティング・アーキテクチャ

- OMSPatcherログ管理アーキテクチャ

- Oracleサポートのログ

- OMSPatcher: ケース分析、エラー・コードおよび処置/提案

- OMSPatcher: 外部ユーティリティ・エラー・コード

- OMSPatcher OMS自動化の特別なエラー・ケース

- UNIXベースのシステムでの複数OMS実行

- OMSPatcherリリース13.6.0.0.0の機能

- 単一OMS構成での再開機能

- 複数OMS構成での再開機能

25 Oracle Management Agentへのパッチ適用

- 25.1 概要

- 25.2 パッチ計画による管理エージェントへのパッチ自動適用(推奨)

- 25.2.1 自動による管理エージェントへのパッチ適用のメリット

- 25.2.2 「パッチと更新版」ページの利用

- 25.2.3 パッチ推奨の表示

- 25.2.4 パッチの検索

- 25.2.4.1 My Oracle Supportでのパッチの検索

- 25.2.4.2 ソフトウェア・ライブラリでのパッチの検索

- 25.2.5 管理エージェント・パッチの適用

- 25.2.6 適用した管理エージェント・パッチの検証

- 25.2.7 管理エージェント・パッチの適用エラー

- 25.2.7.1 Oracleホーム資格証明が設定されていない

- 25.2.7.2 管理エージェント・ターゲットが停止している

- 25.2.7.3 パッチの競合が検出された

- 25.2.7.4 ユーザーはスーパー・ユーザーではない

- 25.2.7.5 パッチがステージングされていないか見つからない

- 25.3 手動による管理エージェントへのパッチ適用

26 Cloud Controlのパーソナライズ

- 26.1 Cloud Controlページのパーソナライズ

- 26.2 リージョンのカスタマイズ

- 26.3 独自のホームページの設定

- 26.4 ポップアップ・メッセージのプリファレンスの設定

27 EMCTLコマンドを使用したEnterprise Managerの管理

- 27.1 EMCTLコマンドの実行

- 27.2 単一ホストで複数のEnterprise Managerコンポーネントを起動する際のガイドライン

- 27.3 Oracle Enterprise Manager 12c Cloud Controlの起動および停止

- 27.3.1 Cloud Controlとそのすべてのコンポーネントの起動

- 27.3.2 Cloud Controlとそのすべてのコンポーネントの停止

- 27.4 Oracle Management Serviceとともに起動されるサービス

- 27.5 Windows上のOracle Management ServiceとManagement Agentの起動および停止

- 27.6 EMCTLコマンドを使用したメトリック収集の再評価

- 27.7 新規のターゲット・モニタリング資格証明のEnterprise Managerでの指定

- 27.8 OMSのEMCTLコマンド

- 27.9 管理エージェントのEMCTLコマンド

- 27.10 EMCTLのセキュリティ・コマンド

- 27.10.1 EMCTLのセキュリティ・コマンド

- 27.10.2 セキュリティ診断コマンド

- 27.10.3 EMCTL EMキー・コマンド

- 27.10.4 認証の構成

- 27.10.4.1 OSSO認証の構成

- 27.10.4.2 OAM認証の構成

- 27.10.4.3 LDAP (OIDおよびAD)認証の構成

- 27.10.4.4 リポジトリ認証(デフォルトの認証)の構成

- 27.11 EMCTLのHAConfigコマンド

- 27.12 EMCTLのResyncコマンド

- 27.13 EMCTLのコネクタ・コマンド

- 27.14 EMCTLのパッチ・リポジトリ・コマンド

- 27.15 Windows NTのEMCTLコマンド

- 27.16 EMCTLのPartoolコマンド

- 27.17 EMCTLのプラグイン・コマンド

- 27.18 OPSSポリシー・ストアとの同期のためのEMCTLコマンド

- 27.19 Oracle Management Service起動エラーのトラブルシューティング

- 27.20 管理エージェント起動エラーのトラブルシューティング

- 27.20.1 起動した管理エージェントの準備未完了

- 27.20.2 エージェントとOMS間のタイムゾーンの不一致による管理エージェント起動の失敗

- 27.20.3 使用可能ポートの競合による管理エージェントの起動失敗

- 27.20.4 保護または保護解除の失敗による管理エージェントの起動失敗

- 27.21 emctl.logファイルを使用したトラブルシューティング

28 Enterprise Managerのログ・ファイルの検索および構成

- 28.1 ログ・ファイルの管理

- 28.1.1 ログ・ファイルおよびそのメッセージの表示

- 28.1.1.1 「ログ・メッセージの表示」メニュー項目および機能へのアクセス制限

- 28.1.1.2 追加のログ・ファイルの登録

- 28.1.2 ログ・ファイルの検索

- 28.1.2.1 ログ・ファイルの検索: 基本検索

- 28.1.2.2 ログ・ファイルの検索: 拡張検索

- 28.1.3 ログ・ファイルのダウンロード

- 28.2 保存済検索の管理

- 28.2.1 検索の保存

- 28.2.2 保存済検索の取得

- 28.2.3 保存済検索の管理

- 28.3 管理エージェントのログ・ファイルおよびトレース・ファイルの検索

- 28.3.1 管理エージェントのログ・ファイルおよびトレース・ファイルについて

- 28.3.1.1 エージェント・ログ・ファイルの構造

- 28.3.2 管理エージェントのログ・ファイルおよびトレース・ファイルの検索

- 28.3.3 Oracle Management Agentのログ・レベルの設定

- 28.3.3.1 デフォルトのロギング・レベルの変更

- 28.3.3.2 gcagent.logの設定

- 28.3.3.3 gcagent_error.logの設定

- 28.3.3.4 個々のクラスおよびパッケージのログ・レベルの設定

- 28.3.3.5 gcagent_mdu.logの設定

- 28.3.3.6 TRACEレベルの設定

- 28.4 Oracle Management Serviceのログ・ファイルとトレース・ファイルの検索および構成

- 28.4.1 Oracle Management Serviceのログ・ファイルおよびトレース・ファイルについて

- 28.4.2 Oracle Management Serviceのログ・ファイルおよびトレース・ファイルの検索

- 28.4.3 Oracle Management Serviceのログ・ファイルおよびトレース・ファイルのサイズと数の制御

- 28.4.4 Oracle Management Serviceのトレース・ファイルの内容の制御

- 28.4.5 Oracle WebLogic ServerおよびOracle HTTP Serverのログ・ファイルの制御

- 28.5 ログ・ファイルのモニタリング

- 28.5.1 ログ・ビューアについて

- 28.5.2 WebLogic Serverとアプリケーション・デプロイメントのログ・ファイル監視の概要

- 28.5.3 ログ・ファイル監視の有効化

- 28.5.4 ログ・ファイル監視の構成

- 28.5.5 ログ・ファイル監視からのアラートの表示

- 28.6 ログ・アーカイブの場所の構成

29 サービスの構成および使用

- 29.1 サービスの概要

- 29.1.1 Enterprise Managerのサービスの定義

- 29.2 サービスの作成

- 29.2.1 汎用サービス - テスト・ベースの作成

- 29.2.2 汎用サービス - システム・ベースの作成

- 29.2.3 集約サービスの作成

- 29.3 サービスのモニタリング

- 29.3.1 「汎用サービス / 集計サービス」ホームページの表示

- 29.3.2 「パフォーマンス/インシデント」ページの表示

- 29.3.3 SLAダッシュボードの表示

- 29.3.4 テストの要約の表示

- 29.3.5 サービス・トポロジの表示

- 29.3.6 サブ・サービス

- 29.4 サービスの構成

- 29.4.1 可用性定義 (汎用サービスおよび集計サービス)

- 29.4.2 根本原因分析の構成

- 29.4.2.1 根本原因分析の最大限の活用

- 29.4.3 システム・アソシエーション

- 29.4.4 モニタリング設定

- 29.4.5 サービス・テストとビーコン

- 29.4.5.1 追加のサービス・テストの定義

- 29.4.5.2 ビーコンのデプロイと使用

- 29.4.5.3 ビーコンの構成

- 29.4.5.4 OATSロード・スクリプトを使用したATSサービス・テストの作成

- 29.4.6 パフォーマンス・メトリック

- 29.4.6.1 ルール・ベース・ターゲット・リスト

- 29.4.6.2 静的ベースのターゲット・リスト

- 29.4.7 使用状況メトリック

- 29.5 トランザクション・レコーダの使用

- 29.6 サービス・レベル合意の設定および使用

- 29.6.1 SLAのアクション可能なアイテム・ルール

- 29.6.2 サービス・レベル目標の作成

- 29.6.3 SLAのライフサイクル

- 29.6.4 サービスのSLAのステータスの表示

- 29.6.5 カスタムSLAビジネス・カレンダの定義

- 29.7 サービス・ダッシュボードの使用

- 29.7.1 すべてのダッシュボード・ページの表示

- 29.7.2 ダッシュボードの詳細ページの表示

- 29.7.3 ダッシュボードのカスタマイズおよびパーソナライズ

- 29.7.4 ダッシュボード・サービスの詳細ページの表示

- 29.8 テスト・リポジトリの使用

- 29.8.1 テスト・リポジトリの表示

- 29.8.2 ATSスクリプトの編集

- 29.9 サービス・レベルの設定

- 29.9.1 サービス・レベル・ルールの定義

- 29.9.2 サービス・レベルの詳細の表示

- 29.10 コマンドライン・インタフェースを使用したサービスの構成

- 29.11 サービス・テストのトラブルシューティング

- 29.11.1 Formsトランザクションの検証およびトラブルシューティング

- 29.11.1.1 Formsトランザクション再生時のトラブルシューティング

- 29.11.1.2 Formsトランザクション記録時のトラブルシューティング

- 29.11.2 Webトランザクションの検証およびトラブルシューティング

30 Enterprise ManagerのSNMPサポートの概要

- 30.1 SNMPサポートの利点

- 30.2 SNMP管理ステーションについて

- 30.3 Enterprise ManagerのSNMPのサポート方法

- 30.4 SNMPトラップ通知の送信

- 30.4.1 管理情報ベース(MIB)について

- 30.5 SNMPを使用した外部デバイスの監視

- 30.5.1 SNMP receiveletについて

- 30.5.2 SNMP fetchletについて

- 30.6 メトリック拡張について

第V部 システム・インフラストラクチャ

31 システム・インフラストラクチャ・ターゲットの処理

- 31.1 Enterprise Managerシステム・インフラストラクチャの概要

- 31.1.1 システム・インフラストラクチャ・ターゲットのモニタリングについて

- 31.1.2 システム・インフラストラクチャ・ターゲットの動的ビューについて

- 31.2 システム・インフラストラクチャのユーザー・インタフェースの概要

- 31.2.1 ターゲット・ホームページについて

- 31.2.2 仮想化ホームページについて

- 31.2.3 Oracleエンジニアド・システムのホームページについて

- 31.3 システム・インフラストラクチャ管理のロールの作成

- 31.4 システム・インフラストラクチャ・ターゲットの関連リソース

32 ネットワークの管理

- 32.1 ネットワーク管理のスタート・ガイド

- 32.2 ユーザー・インタフェース内でのネットワーク情報の場所

- 32.3 ネットワーク管理の処理

- 32.4 トポロジの表示

- 32.5 ファブリック

- 32.5.1 ファブリックについて

- 32.5.2 ファブリックに関する情報の表示

- 32.5.3 ファブリック情報について

- 32.5.4 ファブリックのパフォーマンスについて

- 32.5.5 アクセス・ポイントの表示

- 32.5.6 ファブリックの削除

- 32.6 データリンク

- 32.6.1 データリンクについて

- 32.6.2 データリンクに関する情報の表示

- 32.7 ネットワーク

- 32.7.1 ネットワークについて

- 32.7.2 ネットワークに関する情報の表示

- 32.7.3 ネットワークの削除

- 32.7.4 OSアセットのネットワークの詳細の表示

- 32.8 ネットワーク管理の関連リソース

33 記憶域の管理

- 33.1 記憶域の管理のスタート・ガイド

- 33.2 ユーザー・インタフェース内でのストレージ情報の場所

- 33.3 記憶域管理の処理

- 33.4 記憶域アプライアンス・ダッシュボードについて

- 33.4.1 記憶域アプライアンス・ダッシュボードの表示

- 33.4.2 記憶域アプライアンス・クラスタ・ダッシュボードの表示

- 33.5 フォトリアリスティック画像について

- 33.5.1 フォトリアリスティック画像の表示

- 33.6 サマリーについて

- 33.6.1 サマリーの表示

- 33.7 プロジェクトについて

- 33.7.1 プロジェクトの表示

- 33.8 チャートについて

- 33.8.1 「リソース」グラフの表示

- 33.8.2 「デバイス」グラフの表示

- 33.8.3 「SAN使用状況」グラフの表示

- 33.8.4 「NAS使用状況」グラフの表示

- 33.8.5 「ZFS記憶域プール」グラフの表示

- 33.9 ホストの記憶域情報について

- 33.9.1 ホストのディスク

- 33.9.1.1 ホストのディスクの表示

- 33.9.2 ホストのファイルシステム

- 33.9.2.1 ホストのファイルシステムの表示

- 33.9.3 ホストのSAN構成

- 33.9.3.1 ホストのSAN構成の表示

- 33.9.4 ホストのLinuxボリューム・グループ

- 33.9.4.1 ホストのLinuxボリューム・グループの表示

- 33.9.5 ホストのZFS記憶域プール

- 33.9.5.1 ホストのZFS記憶域プールの表示

- 33.10 記憶域構成トポロジについて

- 33.10.1 記憶域構成トポロジの表示

- 33.11 記憶域メトリックについて

- 33.11.1 記憶域パフォーマンス・メトリックの表示

- 33.11.2 記憶域構成メトリックの表示

- 33.11.3 メトリック収集の変更

- 33.12 記憶域クラスタ・メンバーシップについて

- 33.12.1 記憶域クラスタ・メンバーシップの表示

- 33.13 記憶域リソースの削除について

- 33.13.1 ストレージ・リソースの削除

- 33.13.2 Oracle ZFS Storage Applianceクラスタの削除

- 33.14 エンジニアド・システムのOracle ZFS Storage Applianceの使用方法

- 33.15 ストレージの関連リソース

34 サーバーのモニタリング

- 34.1 サーバー管理のスタート・ガイド

- 34.2 UI中でのサーバー情報の場所

- 34.3 サーバー管理の処理

- 34.4 「ハードウェア」ダッシュボードについて

- 34.4.1 基本的なハードウェア情報について

- 34.4.2 オープン・インシデントについて

- 34.4.3 ファンおよび温度情報について

- 34.4.4 電力使用量について

- 34.4.5 コア情報について

- 34.4.6 最後の構成変更およびインシデントについて

- 34.5 「ハードウェア」ダッシュボードの表示

- 34.6 サーバー・メトリックについて

- 34.7 サーバー・メトリックの表示

- 34.8 ハードウェアのフォトリアリスティック画像について

- 34.9 ハードウェアのフォトリアリスティック画像の表示

- 34.10 論理ビューについて

- 34.10.1 CPU情報について

- 34.10.2 メモリー情報について

- 34.10.3 電力情報について

- 34.10.4 ファン情報について

- 34.10.5 記憶域情報について

- 34.10.6 ディスク・コントローラ情報について

- 34.10.7 ディスク・エキスパンダ情報について

- 34.10.8 ネットワーク・ポート情報について

- 34.10.9 PCIデバイス情報について

- 34.10.10 PDOM情報について

- 34.10.11 DCU情報について

- 34.11 論理ビューの表示

- 34.12 エネルギ消費について

- 34.13 エネルギ消費の表示

- 34.14 ネットワークの接続性

- 34.14.1 ネットワーク・インタフェースについて

- 34.14.2 ネットワーク・データ・リンクについて

- 34.14.3 ネットワーク・ポートについて

- 34.15 ネットワーク接続性の表示

- 34.16 サービス・プロセッサ構成について

- 34.16.1 ファームウェア情報について

- 34.16.2 ホスト・ポリシー構成について

- 34.16.3 電源オン・セルフ・テスト構成について

- 34.16.4 SPアラート構成について

- 34.16.5 DNSおよびNTP情報について

- 34.17 サービス・プロセッサ構成の表示

- 34.18 メトリックおよびインシデント通知の管理

- 34.18.1 メトリック収集エラーの表示

- 34.18.2 メトリックおよび収集設定の編集

- 34.18.3 モニタリング構成の編集

- 34.18.4 モニタリングの一時停止の通知

- 34.18.5 メンテナンスのためのモニタリングの一時停止

- 34.18.6 ブラウンアウトまたはブラックアウトのモニタリングの終了

- 34.19 サーバーの管理

- 34.19.1 コンプライアンスの表示

- 34.19.2 サーバー構成における変更の識別

- 34.19.3 サーバー管理者アクセスの編集

- 34.19.4 サーバーのグループへの追加

- 34.19.5 サーバー・プロパティの編集

- 34.20 サーバー管理の関連リソース

35 PDUの管理

- 35.1 PDU管理のスタート・ガイド

- 35.2 ユーザー・インタフェース内でのPDU情報の場所

- 35.3 PDUの処理

- 35.4 PDUバージョン識別

- 35.5 PDU情報の表示

- 35.5.1 PDUの物理ビュー

- 35.5.2 PDU負荷ビュー

- 35.6 PDUモニタリング資格証明の変更

- 35.6.1 HTTP資格証明の変更

- 35.6.2 SNMP資格証明の変更

- 35.7 PDUテスト接続およびメトリック収集のエラーのトラブルシューティング

- 35.7.1 テスト接続エラーの識別

- 35.7.2 メトリック収集エラーの識別

- 35.7.3 メトリックの再収集

- 35.8 PDUのエラー状態

- 35.9 PDUのアラートおよび構成

- 35.9.1 レガシーPDUでのアラートの構成

- 35.9.2 Enterprise Managerでのアラートの構成

- 35.9.3 アラート・インシデントの表示

- 35.10 PDU管理の関連リソース

36 ラックの管理

- 36.1 ラック管理のスタート・ガイド

- 36.2 ユーザー・インタフェース内でのラック情報の場所

- 36.3 ラックの処理

- 36.4 ラック管理のターゲット・ナビゲーション

- 36.5 ラックの作成

- 36.5.1 コマンドライン・インタフェースを使用したラックの作成

- 36.5.1.1 ラックのプロパティ

- 36.6 ラック情報の表示

- 36.6.1 ラックの物理ビュー

- 36.6.2 「ファームウェア」ビュー

- 36.6.3 「負荷」ビュー

- 36.6.4 「温度」ビュー

- 36.7 ラック内のターゲットの配置

- 36.7.1 ラック内のターゲットの配置

- 36.7.2 ラック内のターゲット配置の編集

- 36.7.3 ラックからのターゲットの削除

- 36.7.4 ラックの削除

- 36.8 ラック管理の関連リソース

37 Oracle SuperClusterの管理

- 37.1 Oracle SuperClusterのスタート・ガイド

- 37.2 Oracle SuperClusterの処理

- 37.3 Oracle SuperClusterのターゲット・ナビゲーション

- 37.4 Oracle SuperClusterシステムの表示

- 37.4.1 Oracle SuperClusterの物理ビュー

- 37.4.2 Oracle SuperClusterシステムでの仮想化管理

- 37.5 Oracle SuperClusterの関連リソース

38 Oracleのオペレーティング・システムのモニタリング

- 38.1 Oracleのオペレーティング・システムのモニタリングのスタート・ガイド

- 38.2 UI中でのOracleのオペレーティング・システム情報の場所

- 38.3 オペレーティング・システムの処理

- 38.4 すべてのホストのダッシュボードについて

- 38.4.1 すべてのホストのダッシュボードの表示

- 38.5 特定のホストに関する情報の取得方法

- 38.5.1 ホスト・ターゲットのサマリーの表示

- 38.5.2 ホストのダッシュレットについて

- 38.5.3 ホストのタブについて

- 38.6 ホスト・メニューについて

- 38.6.1 ホスト・モニタリング・メニューの表示

- 38.7 オープン・インシデントについて

- 38.7.1 オープン・インシデントの表示

- 38.7.2 OS構成の変更の識別

- 38.8 パフォーマンスおよびリソース・メトリックの概要

- 38.8.1 CPU使用率について

- 38.8.2 CPUメトリックの表示

- 38.8.3 CPUスレッド使用率について

- 38.8.4 Oracle Solaris 11のプロセッサ・グループ使用率について

- 38.9 ホスト・メモリーについて

- 38.9.1 ホスト・メモリー使用率の表示

- 38.9.2 メモリーおよびスワップ・ファイルの詳細の表示

- 38.9.3 ホストのメモリーの詳細の表示

- 38.10 ホスト記憶域の表示

- 38.11 ネットワーク接続性の表示

- 38.12 ブート環境について

- 38.12.1 Oracle Solarisブート環境の表示

- 38.13 実行中のホスト・プロセスの表示

- 38.14 管理対象ホスト・サービスの表示

- 38.15 ホスト・メトリックの処理

- 38.15.1 ホストのCPU、メモリーおよびディスクの詳細の表示

- 38.15.2 ホストのプログラム・リソース使用率の表示

- 38.15.3 すべてのメトリックの表示

- 38.16 ホストのメトリックおよびインシデント通知の管理

- 38.16.1 ホストのメトリック収集エラーの表示

- 38.16.2 ホストのメトリックおよび収集設定の編集

- 38.17 ホスト・コンプライアンスについて

- 38.17.1 コンプライアンス・フレームワークの表示

- 38.17.2 コンプライアンス標準の表示

- 38.17.3 ターゲット・コンプライアンスの表示

- 38.18 オペレーティング・システムの関連リソース

39 Oracle Solarisゾーンのモニタリング

- 39.1 Oracle Solarisゾーンのモニタリングのスタート・ガイド

- 39.2 UI中でのOracle Solarisゾーン情報の場所

- 39.3 ゾーンの処理

- 39.4 ゾーンのターゲット・ナビゲーション

- 39.5 ゾーンに関する情報の取得方法

- 39.6 ゾーン・プラットフォーム・メトリックの処理

- 39.6.1 ゾーン・プラットフォーム・メトリックの表示

- 39.7 ゾーン固有のメトリックの処理

- 39.7.1 ゾーン・メトリックのサマリーの表示

- 39.7.2 ゾーンのCPUおよびメモリーのメトリックの表示

- 39.8 すべてのメトリックの表示

- 39.9 ゾーンのインシデントの処理

- 39.9.1 ゾーンのインシデントについて

- 39.9.2 ゾーンのオープン・インシデントの表示

- 39.10 ゾーンのメトリックおよびインシデント通知の管理

- 39.10.1 ゾーンのメトリック収集エラーの表示

- 39.10.2 ゾーンのメトリックおよび収集設定の編集

- 39.10.3 ゾーンのモニタリング構成の編集

- 39.10.4 ゾーンのモニタリングの一時停止の通知

- 39.10.5 メンテナンスのためのゾーン・モニタリングの一時停止

- 39.10.6 ゾーンのブラウンアウトまたはブラックアウトのモニタリングの終了

- 39.11 ゾーンの管理

- 39.11.1 ゾーンのコンプライアンスの表示

- 39.11.2 ゾーン構成における変更の識別

- 39.11.3 ゾーン管理者アクセスの編集

- 39.11.4 グループへのゾーンの追加

- 39.11.5 ゾーン・プロパティの編集

- 39.12 Oracle Solarisゾーンの追加リソース

40 Oracle VM Server for SPARCのモニタリング

- 40.1 Oracle VM Server for SPARCの仮想化のスタート・ガイド

- 40.1.1 用語

- 40.1.2 論理ドメイン

- 40.2 UI中でのOracle VM Server for SPARC情報の場所

- 40.3 Oracle VM Server for SPARCの処理

- 40.4 Oracle VM Server for SPARCのターゲット・ナビゲーション

- 40.5 サポートされているバージョン

- 40.6 Oracle VM Server for SPARC仮想化プラットフォームすべての表示

- 40.7 仮想化プラットフォームの情報について

- 40.7.1 仮想化プラットフォームの基本情報の表示

- 40.7.2 仮想化プラットフォームのゲスト・サマリーについて

- 40.7.3 仮想化プラットフォームのゲスト・サマリーの表示

- 40.7.4 仮想化プラットフォームのサービスについて

- 40.7.5 仮想化プラットフォームのサービスの表示

- 40.7.6 仮想化プラットフォームのvCPUおよびコア割当てについて

- 40.7.7 仮想化プラットフォームのvCPUおよびコア割当ての表示

- 40.7.8 仮想化プラットフォームのメトリックについて

- 40.7.9 プラットフォーム・メトリックの表示

- 40.8 論理ドメイン内のゾーン

- 40.8.1 論理ドメイン内のゾーンの表示

- 40.9 論理ドメイン情報について

- 40.9.1 論理ドメインの基本情報の表示

- 40.9.2 仮想サーバーのサマリー情報について

- 40.9.3 仮想サーバーのサマリー情報の表示

- 40.9.4 仮想サーバーの電力およびCPU使用率チャートについて

- 40.9.5 仮想サーバーの電力およびCPU使用率チャートの表示

- 40.10 メトリックおよびインシデント通知の管理

- 40.10.1 メトリック収集エラーの表示

- 40.10.2 メトリックおよび収集設定の編集

- 40.10.3 モニタリング構成の編集

- 40.10.4 モニタリングの一時停止の通知

- 40.10.5 メンテナンスのためのモニタリングの一時停止

- 40.10.6 ブラウンアウトまたはブラックアウトのモニタリングの終了

- 40.11 Oracle VM Server for SPARCの管理

- 40.11.1 コンプライアンスの表示

- 40.11.2 仮想サーバー構成における変更の識別

- 40.11.3 仮想サーバー管理者アクセスの編集

- 40.11.4 仮想サーバーのグループへの追加

- 40.11.5 仮想サーバー・プロパティの編集

- 40.12 Oracle VM Server for SPARCの関連リソース

第VI部 レポートの生成

41 情報パブリッシャの使用

- 41.1 情報パブリッシャについて

- 41.2 即時利用可能なレポート定義

- 41.3 カスタム・レポート

- 41.3.1 カスタム・レポートの作成

- 41.3.2 レポート・パラメータ

- 41.3.3 レポート要素

- 41.4 レポートのスケジュール

- 41.4.1 柔軟なスケジュール

- 41.4.2 レポートのコピーの格納およびパージ

- 41.4.3 レポートの電子メール送信

- 41.5 レポートの共有

42 使用状況トラッキング・レポートの作成

- 42.1 使用状況トラッキング・レポート

- 42.2 データベース使用状況トラッキングのためのデータ収集

- 42.2.1 データベース使用状況トラッキング資格証明の設定

- 42.2.2 監視テンプレートを使用したメトリック収集の有効化/無効化

- 42.2.3 コマンドライン・インタフェースを使用したメトリック収集の有効化/無効化

- 42.2.3.1 EM CLIログインの設定

- 42.2.3.2 メトリック収集の有効化/無効化

- 42.2.3.3 EM CLIを使用したすべてのデータベース・ターゲットの一覧表示

- 42.2.3.4 SQLを使用した収集ステータスの確認

- 42.2.4 データベース使用状況トラッキング・レポートの作成

- 42.3 データベース使用状況トラッキング・レポートの生成

- 42.3.1 Business Intelligence Publisher (BI Publisher)の構成

- 42.3.2 使用状況トラッキング・レポートの実行:

- 42.4 データベース使用状況トラッキング・サマリー・レポート

- 42.5 Fusion Middleware使用状況トラッキング・サマリー・レポートの生成

- 42.6 ホスト使用状況トラッキング・レポート

- 42.6.1 ホスト使用状況トラッキング・サマリー・レポートの生成

- 42.6.2 ホスト使用状況トラッキング詳細レポートの生成

第VII部 モバイル機器からのEnterprise Managerアクセス

43 Enterprise Managerへのリモート・アクセス

- 43.1 システム要件の確認

- 43.2 初期設定の実行

- 43.3 初回の接続

- 43.4 ログイン画面の表示

- 43.5 管理設定

- 43.6 インシデント・マネージャでのCloud Control Mobileの使用

- 43.7 Cloud Control Mobileでの操作

- 43.7.1 インシデントおよび問題の表示

- 43.7.2 ビューの変更

- 43.7.3 アクションの実行

- 43.8 ヒントとテクニックの習得

- 43.9 Enterprise Managerデスクトップ・バージョンへの接続

第VIII部 付録

A Enterprise Manager MIBの変数の解釈

- A.1 oraEMNGEvent

- A.1.1 oraEMNGEventIndex

- A.1.2 oraEMNGEventNotifType

- A.1.3 oraEMNGEventMessage

- A.1.4 oraEMNGEventMessageURL

- A.1.5 oraEMNGEventSeverity

- A.1.6 oraEMNGEventSeverityCode

- A.1.7 oraEMNGEventRepeatCount

- A.1.8 oraEMNGEventActionMsg

- A.1.9 oraEMNGEventOccurrenceTime

- A.1.10 oraEMNGEventReportedTime

- A.1.11 oraEMNGEventCategories

- A.1.12 oraEMNGEventCategoryCodes

- A.1.13 oraEMNGEventType

- A.1.14 oraEMNGEventName

- A.1.15 oraEMNGAssocIncidentId

- A.1.16 oraEMNGAssocIncidentOwner

- A.1.17 oraEMNGAssocIncidentAcked

- A.1.18 oraEMNGAssocIncidentStatus

- A.1.19 oraEMNGAssocIncidentPriority

- A.1.20 oraEMNGAssocIncidentEscLevel

- A.1.21 oraEMNGEventTargetName

- A.1.22 oraEMNGEventTargetNameURL

- A.1.23 oraEMNGEventTargetType

- A.1.24 oraEMNGEventHostName

- A.1.25 oraEMNGEventTargetOwner

- A.1.26 oraEMNGEventTgtLifeCycleStatus

- A.1.27 oraEMNGEventTargetVersion

- A.1.28 oraEMNGEventUserDefinedTgtProp

- A.1.29 oraEMNGEventSourceObjName

- A.1.30 oraEMNGEventSourceObjNameURL

- A.1.31 oraEMNGEventSourceObjType

- A.1.32 oraEMNGEventSourceObjSubType

- A.1.33 oraEMNGEventSourceObjOwner

- A.1.34 oraEMNGEventCAJobName

- A.1.35 oraEMNGEventCAJobStatus

- A.1.36 oraEMNGEventCAJobOwner

- A.1.37 oraEMNGEventCAJobStepOutput

- A.1.38 oraEMNGEventCAJobType

- A.1.39 oraEMNGEventRuleSetName

- A.1.40 oraEMNGEventRuleName

- A.1.41 oraEMNGEventRuleOwner

- A.1.42 oraEMNGEventSequenceId

- A.1.43 oraEMNGEventRCADetails

- A.1.44 oraEMNGEventContextAttrs

- A.1.45 oraEMNGEventUserComments

- A.1.46 oraEMNGEventUpdates

- A.1.47 oraEMNGEventTotalOccurrenceCount

- A.1.48 oraEMNGEventCurrOccurrenceCount

- A.1.49 oraEMNGEventCurrFirstOccurDate

- A.1.50 oraEMNGEventCurrLastOccurDate

- A.1.51 oraEMNGRCAStatus

- A.1.52 oraEMNGEventReportedState

- A.1.53 oraEMNGEventTypeAttr(1-71)

- A.2 oraEM4AlertTable

- A.2.1 oraEM4AlertTargetName

- A.2.2 oraEM4AlertTargetType

- A.2.3 oraEM4AlertHostName

- A.2.4 oraEM4AlertMetricName

- A.2.5 oraEM4AlertKeyName

- A.2.6 oraEM4AlertKeyValue

- A.2.7 oraEM4AlertTimeStamp

- A.2.8 oraEM4AlertSeverity

- A.2.9 oraEM4AlertMessage

- A.2.10 oraEM4AlertRuleName

- A.2.11 oraEM4AlertRuleOwner

- A.2.12 oraEM4AlertMetricValue

- A.2.13 oraEM4AlertContext

- A.2.14 oraEM4AlertCycleGuid

- A.2.15 oraEM4AlertRepeatCount

- A.2.16 oraEM4AlertUDTargetProperties

- A.2.17 oraEM4AlertAck

- A.2.18 oraEM4AlertAckBy

- A.2.19 oraEM4AlertNotifType

- A.2.20 oraEM4AlertViolationGuid

- A.3 oraEM4JobAlertTable

- A.3.1 oraEM4JobAlertJobName

- A.3.2 oraEM4JobAlertJobOwner

- A.3.3 oraEM4JobAlertJobType

- A.3.4 oraEM4JobAlertJobStatus

- A.3.5 oraEM4JobAlertTargets

- A.3.6 oraEM4JobAlertTimeStamp

- A.3.7 oraEM4JobAlertRuleName

- A.3.8 oraEM4JobAlertRuleOwner

- A.3.9 oraEM4JobAlertMetricName

- A.3.10 oraEM4JobAlertMetricValue

- A.3.11 oraEM4JobAlertContext

- A.3.12 oraEM4JobAlertKeyName

- A.3.13 oraEM4JobAlertKeyValue

- A.3.14 oraEM4JobAlertSeverity

- A.3.15 oraEM4JobAlertJobId

- A.3.16 oraEM4JobAlertJobExecId

B Enterprise Manager MIBの定義

- B.1 MIB定義

C SNMPトラップのマッピング

- C.1 12c以前のEnterprise Managerメトリック・アラート

- C.2 12C以前のターゲットの可用性アラート

- C.3 12c以前のメトリック・アラートの修正処理結果

- C.4 ターゲットの可用性の修正処理結果

- C.5 ジョブ・ステータスの変更

D ターゲットの可用性状態の概要

- D.1 ターゲットの可用性状態の変更

- D.2 ターゲット・ステータス変更の更新

E Enterprise Managerコンポーネントのタイムアウト値

索引

はじめに

このマニュアルでは、Oracle Enterprise Manager Cloud Control 12cの中心的な機能について、使用方法を説明します。

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

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、Enterprise Managerインフラストラクチャを管理するEnterprise Manager管理者および開発者を対象としています。

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

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

Oracleサポートへのアクセス

サポートをご購入の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(聴覚障害者向け)を参照してください。

関連ドキュメント

これらのドキュメントやその他のOracleドキュメントの最新リリースについては、Oracle Technology Networkの次のページを確認してください。

http://docs.oracle.com/en/enterprise-manager/

Oracle Enterprise Managerには詳細なオンライン・ヘルプも用意されています。オンライン・ヘルプ・ウィンドウを表示するには、Enterprise Managerページの上部にある「ユーザー」メニューから、「ヘルプ」を選択します。

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

第I部

ターゲットの監視および管理

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

- エンタープライズ・モニタリング

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- インシデント管理の使用

- 通知の使用

- ブラックアウトと通知ブラックアウトの使用方法

- グループの管理

- 管理グループの使用

- 監視テンプレートの使用

- メトリック拡張の使用

- 高度なしきい値管理

- ジョブ・システムと修正処理の使用

- ターゲットに構成されたアクセス・ポイントのモニタリング

- Always-On Monitoring

1 エンタープライズ・モニタリング

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

- 監視の概要

- 監視: 基本

- 監視: 高度な設定

- 通知

- イベント、インシデントおよび問題の管理

- 監視情報へのアクセス

1.1 監視の概要

Enterprise Manager Cloud Control監視機能により、使用中のIT環境の無人監視が可能になります。Enterprise Managerには、パフォーマンスと状態メトリックのセットが付属しており、これにより、ご使用環境内の主要コンポーネント(アプリケーション、アプリケーション・サーバー、データベースなど)はもちろんのこと、ホスト、オペレーティング・システム、ストレージなど、それらの依存するバックエンド・コンポーネントの監視も可能です。

各管理対象ホストの管理エージェントによって、そのホストのすべての管理対象コンポーネント(ターゲット)のステータス、状態およびパフォーマンスが監視されます。ターゲットが停止するか、パフォーマンス・メトリックが警告またはクリティカルのしきい値を超えると、イベントが作成され、Enterprise Managerに送信されます。管理者または関連するパーティには、Enterprise Manager通知システムを通じてトリガーされたイベントを通知できます。

監視するターゲットの追加は簡単です。Enterprise Managerでは、ターゲットを手動で追加するか、またはホスト上の監視可能なすべてのターゲットを自動的に検出するかを選択できます。Enterprise Managerではまた、新たに追加したターゲットに対する監視設定を自動的およびインテリジェントに適用できます。詳細は、第1.4.2項「管理グループおよびテンプレート・コレクション」を参照してください。Enterprise Managerでは監視に使用する包括的なメトリックのセットを提供しますが、使用環境に特有の状況を監視するために、メトリック拡張も使用できます(第1.3.6項「メトリック拡張: 監視のカスタマイズ」参照)。データ・センターの拡大に従い、各ターゲットを個別に管理することはさらに難しくなるので、Enterprise Managerのグループ管理機能を使用すると、多数のターゲットのセットをグループ化し、多数のターゲットを1つのものとして監視および管理できます。

1.2 包括的な即時利用可能な監視

監視はEnterprise Manager Cloud Control 12cをインストールするとすぐに開始します。Enterprise Managerの管理エージェントは、デプロイおよび起動されるとすぐに、ホストのシステム(ホストのハードウェアおよびソフトウェア構成データを含む)の監視を自動的に開始します。Enterprise Managerが提供する自動検出スクリプトにより、これらのエージェントは、すべてのOracleコンポーネントを自動的に検出し、Oracle推奨のしきい値が設定された広範なメトリックのセットを使用して監視を開始できます。

この監視機能には、NetApp Filer、BIG-IPロード・バランサ、Checkpoint FirewallおよびIBM WebSphereなどの、Oracleエコシステムの他のコンポーネントも含まれます。すべての監視対象コンポーネントからのメトリックは、管理リポジトリに格納および集計され、管理者に診断情報と傾向分析データの豊富なソースを提供します。クリティカル・アラートが検出されると、迅速な解決を促す通知が管理者に送信されます。

デフォルトのEnterprise Managerの監視機能は、次のとおりです。

- オラクル社推奨のメトリックおよびしきい値による詳細な監視。

- 実行中のアプリケーションおよびサービスはもちろん、使用中のITインフラストラクチャ(Oracle製品、Oracle以外の製品を問わず)のすべてのコンポーネントの監視。

- リアルタイム・パフォーマンス・チャートへのアクセス。

- 管理リポジトリへのメトリック・データの収集、格納および集約。これにより、傾向分析やレポート作成などの戦略的タスクを実行できます。

- 検出したクリティカル・イベントの電子メールおよびページャによる通知。

Enterprise Managerでは、ITインフラストラクチャの多様なコンポーネント(データベース、ホストおよびルーターなど)を監視できます。

監視されるメトリックの例は、次のとおりです。

- アーカイブ領域使用量(データベース)

- コンポーネント・メモリー使用量(アプリケーション・サーバー)

- 最大エクステントに近づいているセグメント数(データベース)

- ネットワーク・インタフェース合計I/Oレート(ホスト)

管理エージェントなしの監視

IPトラフィック・コントローラまたはリモートWebアプリケーションなど、ITインフラストラクチャの特定のコンポーネントを監視するように管理エージェントを配置することが実用的でない場合に備えて、Enterprise Managerでは拡張ネットワークおよびクリティカルURL監視機能が用意されています。この機能により、エージェントがそのデバイスに物理的に存在することなく、エージェントのビーコン機能によって、可用性および反応性について、リモート・ネットワーク・デバイスおよびURLを監視できます。必要な作業は、特定のビーコンを選択し、主要ネットワーク・コンポーネントおよびURLをネットワークおよびURL監視リストに追加するのみです。Enterprise Manager監視の概念とこの機能をサポートする基本となるサブシステムについては、次の各項で説明します。

1.3 監視: 基本

Enterprise Manager Cloud Control 13cには、パフォーマンスと状態メトリックのセットが付属しており、これにより、環境内の主要コンポーネント(アプリケーション、アプリケーション・サーバー、データベースなど)はもちろんのこと、ホスト、オペレーティング・システム、ストレージなど、それらの依存するバックエンド・コンポーネントの自動モニタリングも可能です。Enterprise Managerは多くのタイプの条件(イベント)を監視できますが、この監視機能の最も一般的な用途は、メトリック値で定義された許容可能なパフォーマンス境界の違反の監視の基本が中心です。次の各項では、基本概念とターゲットの監視をサポートするEnterprise Mangerの機能について説明します。

1.3.1 メトリックしきい値: 監視対象の状況が問題である時点を判断

一部のメトリックには、しきい値と呼ばれる事前定義済の制限パラメータが関連付けられており、収集されたメトリック値がその制限を超えると、メトリック・アラート(イベントのタイプに特有)が起動されます。Enterprise Managerでは、次の2つのレベルのアラート重大度に対してメトリックしきい値を設定できます。

- 警告 - 特定の領域で注意が必要ですが、その領域は機能を続けています。

- クリティカル - 特定の領域で迅速な対処が必要です。その領域は、機能していないか、緊急の問題が発生しています。

したがって、しきい値は監視対象のメトリックと比較される境界値です。たとえば、ディスク使用状況(%)メトリックに関連付けられた各ディスク・デバイスごとに、警告しきい値をディスク使用領域80%に、クリティカルしきい値を95%に定義します。

注意:
すべてのメトリックにしきい値が必要なわけではなく、値に意味がない場合や、特定の環境でその値が必要ない場合は、削除したり、設定せずにおくこともできます。

即時利用可能な事前定義済のメトリックしきい値はほとんどの監視条件で使用可能ですが、環境によっては操作基準をより正確に反映するため、しきい値のカスタマイズが必要になります。ただし、パフォーマンス・メトリックなどの特定カテゴリのメトリックでは、正確なしきい値の設定は困難な場合があります。

たとえば、1トランザクション当たりレスポンス時間のデータベース・メトリックでは、適切な警告およびクリティカルしきい値はどのようになるか考えます。このようなメトリックの場合、パフォーマンス・メトリックに対する管理対象の値が通常動作から逸脱した場合のアラート発生がより有効です。Enterprise Managerでは、ターゲットについて通常のパフォーマンス動作を取得し、そのパフォーマンス基準からの逸脱を示すしきい値を決定可能な機能が提供されます。

注意:
Enterprise Managerの管理者がメトリックしきい値を変更するには、ターゲットに対する「ターゲット・メトリックの管理」以上の権限が付与されている必要があります。

1.3.2 メトリック・ベースライン: 有効なメトリックしきい値の決定

どのメトリックしきい値が環境のパフォーマンス監視要求を正確に反映しているかを決定することは重要です。正しい値を決定するために試行錯誤に頼るのではなく、Enterprise Managerではメトリック・ベースラインを提供します。メトリック・ベースラインは、Enterprise Managerがシステムのパフォーマンス・メトリックを取得した期間に相当する適切に定義された時間間隔(ベースライン期間)で、特定の期間のシステム・パフォーマンスの統計的特性です。この履歴データは、システム・パフォーマンスの正規化されたビューを提供することにより、有効なメトリックしきい値を決定する作業を大幅に簡略化します。メトリック動作のベースラインで正規化されたビューにより、管理者はイベントの発生を説明および理解できます。

メトリック・ベースラインの基礎となる仮定は、比較的安定したパフォーマンスのシステムが、比較可能なワークロード期間において同じようなメトリック測定(値)を示していることです。2つのタイプのベースライン期間がサポートされます。

- 変動ウィンドウ・ベースライン期間: 変動ウィンドウ・ベースライン期間は現在の日付より前の一定の日数(過去7日間など)として定義されます。これにより、現在のメトリック値と最近測定された履歴を比較できます。変動ウィンドウ・ベースラインは、予測可能なワークロード・サイクル(日中はOLTP処理、夜間はバッチ処理など)で運用されている業務系システムに適しています。

- 静的ベースライン期間: 静的ベースラインは、管理者が特に関心のある対象として定義した時間間隔(会計年度末など)です。これらのベースラインは、将来同じワークロードが発生したときに比較対象とするワークロード期間を指定するために使用できます(ある暦年と次の暦年の会計年度末を比較する場合など)。

1.3.3 高度なしきい値管理

一般的に、メトリック・ベースラインは有効なターゲットのアラートしきい値を判断するために有効ですが、これらのしきい値は静的で、予測されるパフォーマンスの変化に対応することができません。定期的な(予測できる)間隔で、ターゲットに異なるワークロードが発生する監視状況があります。この場合、静的なアラートしきい値では正確な結果が得られないことがわかります。たとえば、日中はオンライン・トランザクション処理(OLTP)を実行していて、夜間にバッチ処理を実行するデータベースのアラートしきい値は異なります。同様に、平日と週末など、期間が異なれば、データベースのワークロードは変わります。つまり、しきい値が固定された静的な値であれば、間違ったアラート・レポートが生成される可能性があり、過剰なアラートによって、パフォーマンス管理に関するオーバーヘッドが大幅に増える可能性があります。このOLTPの例では、正確なアラートのしきい値を判断するために静的なベースラインを使用することで、予測されるパフォーマンスの循環的な変化に対応することに失敗し、逆に問題の検出に影響を与えました。静的なベースラインによって、次の構成上の問題が発生します。

- バッチ・パフォーマンス用に構成されたベースラインでは、OLTPのパフォーマンスの低下を検出できません。

- OLTPパフォーマンス用に構成されたベースラインでは、バッチ・サイクルで過剰なアラートが生成されます。

Enterprise Managerリリース12.1.0.4以上では、高度なしきい値管理によって、適応(自己調整)または時間ベース(ユーザー定義)のいずれかのベースラインを使用して、しきい値を計算できます。

- 適応しきい値: Enterprise Managerが適応しきい値を統計的に計算できます。適応しきい値は、すべてのターゲット(エージェントおよびリポジトリの両方が監視するターゲット)に適用されます。

- 時間ベースのしきい値: 時間によって変化するワークロードに対応するために、様々な時間に使用する固有のしきい値を定義できます。

便利なUIを使用すると、時間ベースのしきい値および適応しきい値を作成できます。ターゲットのホームページ(ホストなど)から、メトリック・コレクションおよび設定ページに移動します。「関連リンク」リージョンの「高度なしきい値管理」をクリックします。

適応しきい値として登録できるのは、数値およびコレクションの表示メトリックのみです。また、許可されるのは、次のタイプのメトリックのみです。

- 負荷

- ロード・タイプ

- 使用率およびレスポンス

1.3.4 イベント: 対象の状況を定義

メトリックしきい値に達すると、メトリック・アラートが発生します。メトリック・アラートは、イベントの1タイプです。イベントは、監視されているメトリックの警告またはクリティカルしきい値のいずれかがクロスしたなどの、潜在的な問題を示す重要な発生です。イベントの別の例には、データベース・インスタンスの停止、構成ファイルの変更、ジョブ実行のエラーでの終了、ホストの指定したCPU使用率のパーセントの超過などがあります。次の2つの最も重要なイベント・タイプがエンタープライズ監視で使用されます。

- メトリック・アラート

- ターゲット可用性

イベントと監視可能なイベント・タイプの詳細は、第2章「インシデント管理の使用」を参照してください。

1.3.5 修正処理: 問題の自動的な解決

修正処理により、メトリック・アラートに対して自動化されたレスポンスを指定できるため、管理者は時間を節約でき、ユーザーに対して顕著な影響が出る前に問題を処理できます。たとえば、Enterprise ManagerがSQL*Netリスナーなどのコンポーネントの停止を検出した場合に、自動的にバックアップを開始する修正処理を指定できます。したがって、修正処理は、メトリックによって警告またはクリティカルの重大度のアラートが発生したときに実行されるユーザー指定の任意のタスクです。修正タスクを実行することに加え、必要に応じてより多くの診断情報を収集するために修正処理を使用できます。デフォルトでは、修正処理はイベントが発生したターゲット上で実行されます。

修正処理は、それぞれ別のターゲットで実行される複数のタスクで構成することも可能です。管理者は、修正処理の成功または失敗に対する通知を受け取ることもできます。修正処理は、それぞれ別のターゲットで実行される複数のタスクで構成することも可能です。

ターゲットの修正処理を定義できるのは、そのターゲットに対する「ターゲット・メトリックの管理」以上の権限を付与されているすべてのEnterprise Manager管理者です。任意のメトリックについて、そのメトリックが警告またはクリティカルの重大度に到達した場合に異なる修正処理を定義できます。

修正処理は、特定のEnterprise Manager管理者の資格証明を使用して実行する必要があります。そのため、修正処理を作成または変更する場合は、常に変更した処理を実行するための資格証明を指定する必要があります。これらの資格証明は、修正処理をインシデントやイベント・ルールなどの要素に関連付けるときに指定します。

1.3.6 メトリック拡張: 監視のカスタマイズ

メトリック拡張を使用すると、Enterprise Managerの監視機能を拡張して使用IT環境に固有の条件を網羅でき、監視環境の完全な包括的なビューが提供されます。

メトリック拡張では、Oracleが提供するメトリックにより使用されるデータ収集メカニズムと同じフルセットを利用する、あらゆるターゲット・タイプに新しいメトリックを定義できます。たとえば、次のターゲット・タイプにメトリックを作成できます。

- ホスト

- データベース

- IBM Websphere

- Oracle Exadataデータベースおよびストレージ・サーバー

- Oracle Business Intelligenceコンポーネント

これらの新しいメトリックが定義されると、その他のEnterprise Managerメトリックのように使用できます。メトリック拡張の詳細は、第8章「メトリック拡張の使用」を参照してください。

ユーザー定義メトリック(12cより前)

Enterprise Manager 12cサイトを以前のバージョンのEnterprise Managerからアップグレードした場合、以前のバージョンで定義したすべてのユーザー定義メトリックもEnterprise Manager 12cに移行されます。これらのユーザー定義メトリックは引き続き動作しますが、将来のリリースではサポートされなくなります。既存のユーザー定義メトリックがある場合、できるだけ早くメトリック拡張に移行して、管理環境内で監視の中断が起こらないようにすることをお薦めします。移行プロセスの詳細は、第8章「メトリック拡張の使用」の「メトリック拡張へのユーザー定義メトリックの変換」を参照してください。

1.3.7 ブラックアウトおよび通知ブラックアウト

ブラックアウトにより、緊急メンテナンスや予定されているメンテナンスを実行するための計画停止期間をサポートできます。ターゲットがブラックアウト状態になると、監視は一時停止されます。そのため、データベース・バックアップやハードウェア・アップグレードなどの予定されているメンテナンス作業でターゲットを停止するときに、不要なアラートが送信されるのを回避できます。ターゲットの全体的な可用性を計算する場合、ブラックアウト期間は自動的に除外されます。

ブラックアウト期間は、個々のターゲット、ターゲットのグループ、またはホスト上のすべてのターゲットに対して定義できます。ブラックアウトは、即時実行または将来において実行、あるいは無期限に実行または特定期間実行後に停止のいずれかにスケジュールできます。ブラックアウトは必要に応じて作成でき、また定期的に実行するようスケジュールできます。メンテナンス期間中にメンテナンス・タスクの完了までにより長い(または短い)時間が必要であることがわかった場合は、その時点で有効なブラックアウトを簡単に延長(または停止)できます。ブラックアウト機能は、Enterprise Managerコンソールと、Enterprise Managerコマンドライン・インタフェース(EM CLI)のどちらからでも使用できます。EM CLIは、通常、管理者がメンテナンス・スクリプト内にターゲットのブラックアウトを組み込むために使用できます。ブラックアウトが終了すると、管理エージェントによって、ターゲットのすべてのメトリックが自動的に再評価され、ブラックアウト後のターゲットの現行のステータスが表示されます。

管理者が、先にターゲットをブラックアウトせずに、そのターゲットで予定されたメンテナンスを誤って実行すると、その期間は計画されたブラックアウト期間ではなく、ターゲットの停止時間として認識されます。これは、ターゲットの可用性の記録にとって不都合な結果となります。このような場合、Enterprise Managerでは、スーパー管理者が前に戻ってその期間に発生する予定だったブラックアウト期間を定義できます。これらの遡及ブラックアウト作成機能により、スーパー管理者は、ターゲットの可用性のより正確な記録を柔軟に定義できます。

通知ブラックアウト

Enterprise Manager 13cからは、通知のみを停止できるようになりました。これは通知ブラックアウトと呼ばれ、ターゲットでのイベント通知の抑止のみを目的としています。エージェントは通知ブラックアウト中もターゲットのモニタリングを継続するため、OMSでは、ターゲットが現在通知ブラックアウト中であることを示しながら、実際のターゲット・ステータスの表示を継続します。

1.4 監視: 高度な設定

Enterprise Managerでは、監視環境の管理が大幅に簡略化され、Enterprise Managerの監視機能をカスタマイズおよび拡張することもできます。しかし、Enterprise Managerの監視の一番の利点は、大規模な異機種環境を監視および管理できる機能が提供されることです。監視している環境に存在するターゲットが10であろうと10,000であろうと、次のEnterprise Managerの高度な機能により、同じレベルの利便性と簡単さで、監視環境を実装および保守できます。

1.4.1 監視テンプレート

監視テンプレートを使用すると、監視の標準をテンプレートに一度指定してそれらを組織全体の監視ターゲットに適用することで、エンタープライズ全体の監視設定を簡単に標準化できます。これにより、エンタープライズ全体で特定の監視設定をターゲットの特定のクラスに適用することが容易になります。たとえば、ある監視テンプレートをテスト・データベース用に定義し、別の監視テンプレートを本番データベース用に定義できます。

監視テンプレートでは、ターゲットを監視するために通常設定している次のようなすべてのEnterprise Managerパラメータを定義します。

- テンプレートを適用するターゲット・タイプ。

- メトリック(ユーザー定義メトリックを含む)、しきい値、メトリック収集スケジュールおよび修正処理。

テンプレートを変更したら、その新しい変更を伝播するために、影響を受けるターゲット全体にテンプレートを再適用できます。適用操作は管理グループおよびテンプレート・コレクションを使用して自動化できます。どのターゲットでも、テンプレートによる上書きが不可能なメトリック設定を指定することで、カスタム監視設定を維持できます。

Enterprise Managerには多数のオラクル社認定テンプレートが用意され、様々なOracleターゲット・タイプ用の推奨メトリック設定が提供されます。

監視テンプレートの詳細は、第7章「監視テンプレートの使用」を参照してください。

1.4.2 管理グループおよびテンプレート・コレクション

監視環境は静的であることはほとんどありません。エコシステム全体から新しいターゲットが常に追加されます。Enterprise Managerではこの動的環境の制御を管理グループを通じて管理できます。管理グループは、設定またはコンプライアンス標準の監視などの管理設定の自動的な適用により、Enterprise Managerで管理するターゲットの設定プロセスを自動化します。通常、これらの設定は個別のターゲットに手動で適用されるか、監視テンプレート(第1.4.1項「監視テンプレート」)またはカスタム・スクリプトを使用して、半自動的に適用されることもあります。管理グループは、監視テンプレートを使用した監視設定の適用の利便性と自動化の力とを組み合せます。

テンプレート・コレクションには、ターゲットを管理グループに追加する際に適用する監視設定およびその他の管理設定が含まれています。ターゲットの監視設定は監視テンプレートに定義されています。監視テンプレートはターゲット・タイプごとに定義されるため、管理グループ内の異なるターゲット・タイプのそれぞれに対して監視テンプレートを作成する必要があります。おそらく、複数の監視テンプレートを作成し、管理グループに適した監視設定を定義することになります。

Enterprise Managerに追加された各ターゲットはターゲット・プロパティと呼ばれる固有の属性を処理します。Enterprise Managerはこれらのターゲット・プロパティを使用してターゲットを適切な管理グループに追加します。管理グループのメンバーシップはメンバーシップ基準としてターゲット・プロパティに基づくので、ターゲット・メンバーシップは動的です。管理グループに追加されると、Enterprise Managerにより、関連付けられたテンプレート・コレクションの一部である監視テンプレートを使用して、必要な監視設定が自動的に適用されます。

管理グループは次のターゲット・プロパティを使用してメンバーシップ基準を定義します。

- 連絡先

- コストセンター

- カスタマ・サポートID

- 部門

- ライフサイクル・ステータス

- ライン・オブ・ビジネス

- 場所

- ターゲット・バージョン

- ターゲット・タイプ

1.4.3 アラート・メッセージのカスタマイズ

メトリックのしきい値に到達すると、メトリック固有のメッセージと一緒にアラートが生成されます。これらのメッセージは、一般的なメトリック・アラート条件に対処するように書き込まれます。Enterprise Managerリリース12.1.0.4以降では、監視対象環境固有の要件に合うようにこれらのメッセージをカスタマイズできます。

アラート・メッセージをカスタマイズして、監視のニーズに合うようにメッセージを変更できます。メッセージを変更して、データ・センターで使用されるITエラー・コードなど、環境固有の操作コンテキストを含めたり、Enterprise Managerによって収集される次の情報を追加したりすることができます。

- アラートがトリガーされたメトリック名

- アラートまたは違反の重大レベル

- 警告違反またはクリティカル違反がトリガーされたしきい値

- アラートがトリガーされた後の発生数

アラート・メッセージをカスタマイズすると、メッセージが使いやすくなり、アラートの管理効率が向上します。

メトリック・アラート・メッセージをカスタマイズする手順:

1. ターゲットのホームページにナビゲートします。

2. ターゲットのメニュー(ホスト・ターゲット・タイプが図に表示される)から、「モニタリング」を選択し、「メトリックと収集設定」を選択します。

「メトリックと収集設定」ページが表示されます。

3. メトリック表で、変更しようとするメッセージのメトリックを探し、編集アイコン(鉛筆)をクリックします。

「詳細設定の編集」ページが表示されます。

4. 「モニター対象オブジェクト」リージョンで「アラート・メッセージの編集」をクリックします。

5. 必要に応じてアラート・メッセージを変更します。

注意:
変更したメッセージをOracleによって定義された元のメッセージに戻すには、いつでも「アラート・メッセージのリセット」をクリックします。

6. 「続行」をクリックして、「メトリックと収集設定」ページに戻ります。

7. さらにメトリック・アラート・メッセージを変更するには、3から6までの手順を繰り返します。

8. 終了したら、「OK」をクリックして、すべての変更内容をEnterprise Managerリポジトリに保存します。更新が成功したことを示すメッセージがEnterprise Managerによって表示されます。

9. 「OK」をクリックしてメッセージを閉じ、ターゲットのホームページに戻ります。

1.5 通知

通常の監視シナリオでは、ターゲットが使用不可になるか、パフォーマンスのしきい値を超えると、イベントが発生し、適切な管理者に通知が送信されます。Enterprise Managerでは、電子メール、ページャ、SNMPトラップ、またはカスタム・スクリプトの実行による通知がサポートされ、これにより管理者は次のものを通じた通知メカニズムを制御できます。

- 通知メソッド

- ルールとルール・セット

- 通知ブラックアウト

通知メソッド

通知メソッドは通知を送信する特定の方法を表します。電子メール以外にも、OSコマンド、PL/SQL、SNMPトラップの3種類の通知メソッドがあります。通知メソッドの構成時に、電子メールにどのSMTPゲートウェイを使用するか、どのカスタムOSスクリプトを実行するかといった、特定の通知メカニズムと関連付けられた詳細を指定する必要があります。スーパー管理者は、使用できる様々なタイプの通知メソッドの設定を1回のみ行います。

ルール

ルールでは、イベントまたはインシデント(1つの重要なイベントまたは関連イベントを含むエンティティ)が発生したときに、管理者への通知やヘルプデスク・チケットのオープンなどの、Enterprise Managerがとる特定のアクションを指示します(第1.6項「イベント、インシデントおよび問題の管理」を参照)。たとえば、ホスト・ターゲットのCPU使用率がクリティカルな重要度になったら電子メールが送信されることを指定するルールや、インシデントが24時間以内に確認できなかったら管理者のスーパーバイザに通知する別のルールを定義できます。

通知ブラックアウト

通知ブラックアウトを使用すると、エージェントでターゲットのモニタリングを継続しながら通知を停止できます。これにより、Enterprise Managerはより正確にターゲットの可用性情報を収集できます。詳細は、「ブラックアウトおよび通知ブラックアウト」を参照してください。

1.5.1 通知のカスタマイズ

管理者に送信される通知は、メッセージ・タイプおよびオンコール・スケジュールに基づいてカスタマイズできます。メッセージのカスタマイズは、通知の受信手段として電子メールとページング・システムの両方を使用している管理者には便利です。これらのシステム間では、メッセージの書式は通常異なります。電子メールで送信されるメッセージは長く、URLを含む可能性があります。ページャに送信されるメッセージは短く、文字数に制限があります。これらのタイプのメカニズムをサポートするため、管理者はEnterprise Managerを使用して長いメッセージ書式および短いメッセージ書式を各電子メール・アドレスに関連付けできます。通常の電子メール送信に使用される電子メール・アドレスは、長い書式に関連付けでき、ページ送信に使用される電子メール・アドレスは、短い書式に関連付けできます。長い書式にはイベント/インシデントの詳細が完全な形で含まれ、短い書式には情報の最も重要な部分のみが含まれます。

通知は管理者のオンコール・スケジュールに基づいてもカスタマイズできます。オンコールの管理者には、業務時間中は本人のページャおよび会社の電子メール・アドレス、業務時間外には本人のページャのアドレスのみで連絡を受ける場合があります。Enterprise Managerは、多様なオンコール・スケジュールをサポートする柔軟な通知スケジュールを提供しています。管理者はこのスケジュールを使用して、オンコール時の連絡用の電子メール・アドレスを指定し、自身のオンコール・スケジュールを定義します。オンコール以外の期間、またはインシデント通知を受信しない期間については、単にスケジュールの該当部分を空白のままにします。管理者に送信されるすべてのアラートが、指定したスケジュールに従って自動的に処理されます。

1.6 イベント、インシデントおよび問題の管理

Enterprise Managerの監視機能は、例外による監視の教訓に基づき構築されています。つまり、例外状況がIT環境に存在するとイベントが発生し、監視して、管理者は適時に対応できます。前述のとおり、監視に最もよく使用される2つのイベント・タイプは「メトリック・アラート」と「ターゲット可用性」です。これらはEnterprise Managerが監視する最も一般的なイベント・タイプですが、他にも多数あります。使用可能なイベント・タイプは次のとおりです。

- ターゲット可用性

- メトリック・アラート

- メトリック評価エラー

- ジョブ・ステータスの変更

- コンプライアンス標準ルール違反

- コンプライアンス標準スコア違反

- 高可用性

- サービス・レベル合意のアラート

- ユーザー報告

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

- JVM診断しきい値違反

定義によると、インシデントは、管理環境内で管理者の注意を必要とする問題を識別する、単一または密接に関連付けられたイベントのセットを含む1つの単位です。そのため、インシデントは、表領域内の使用可能領域が指定した制限を下回ったことを示す単一のイベントと同じくらい単純な場合もあれば、リソース不足でサーバーが実行しているときの潜在的なパフォーマンスの問題に関連する複数のイベントを含む1つのインシデントのようにもっと複雑な場合もあります。このようなイベントは、CPU、I/Oおよびメモリー・リソースに関連するイベントを含みます。インシデントによる管理では、いくつもの原因となる要素からなる可能性のある問題に対応できます。インシデントおよびイベントに関する詳細な説明は、第2章「インシデント管理の使用」を参照してください。

インシデントは1つのイベントに対応する場合もありますが、より一般的には、関連するイベントのグループに対応します。多数のイベントはすぐに管理しにくくなりますが、関連イベントの集合として処理されるインシデントにより、多数のイベント発生をより効果的に管理できます。

インシデントが作成されると、Enterprise Managerの豊富なインシデント管理ワークフロー機能群が使用できるようになり、インシデントをライフサイクル全体を通して管理および追跡できます。インシデント管理機能には次のものが含まれます。

- インシデント所有権の割当て。

- インシデント解決ステータスの追跡。

- インシデント優先度の設定。

- インシデントのエスカレーション・レベルの設定。

- 手動での要約を提供する機能。

- ユーザー・コメントを追加する機能。

- 抑止および抑止解除する機能。

- 手動でインシデントをクリアする機能。

- 手動でチケットを作成する機能。

問題は、自動診断リポジトリ(ADR)に格納される診断インシデントおよび問題に関係し、そのような問題は、ソフトウェアにクリティカルなエラーが発生したときにOracleソフトウェアにより自動的に生成されます。Oracleソフトウェアに問題が発生した場合、オラクル社の推奨する問題解決の手続きは、サービス・リクエスト(SR)をオープンしてサポートに診断ログを送信してもらい、最終的にオラクル社からソリューションを提供することです。問題は、インシデントの基礎となる根本原因を表します。Enterprise Managerには、問題のライフサイクルを追跡し管理する機能が用意されています。

1.6.1 インシデント・マネージャ

Enterprise Manager Cloud Controlは、インシデント管理を、インシデント・マネージャと呼ばれる直感的なUIを使用して実行します。インシデント・マネージャは使いやすいインタフェースを提供し、これにより、環境に影響を与えるインシデントおよび問題を検索、表示、管理および解決できます。インシデント・マネージャにアクセスするには、「エンタープライズ」メニューから、「監視」、「インシデント・マネージャ」の順に選択します。

図1-1 インシデント・マネージャ

インシデント・マネージャのUIから、次のことを実行できます。

- カスタム・ビューの使用によるインシデント、問題およびイベントのフィルタ処理

- インシデントの応答および処理

- 割当て、確認、ステータスの追跡、優先度付け、およびエスカレーションといったインシデントのライフサイクル管理

- インシデントの解決には、My Oracle Supportのナレッジ・ベースの記事へのアクセス(コンテキスト依存)、およびその他のオラクル社のドキュメントが役立ちます。

- インシデントをすばやく診断または解決するには、関連するEnterprise Manager機能へのコンテキスト依存の診断/アクション・リンクに直接アクセスします。

1.6.2 インシデント・ルールとルール・セット

インシデント・ルールは、イベントまたはインシデントが発生したときに通知が送信されるタイミングや送信方法を決定する、条件とアクションを指定します。ルール内で定義された基準は、ターゲット・タイプ、イベントおよび重要度の状態(クリア、警告、クリティカル)などの属性や、ルール基準に一致するインシデントが発生したときに使用される通知メソッドに適用できます。ルール・アクションには、条件的な性質が含まれます。たとえば、ルール・アクションを定義して、インシデントの重大度がクリティカルの場合にページを表示し、警告の場合には電子メールを送信するのみにできます。

ルール・セットは、ホスト、データベース、グループ、ジョブ、メトリック拡張、または自己更新などのターゲットの共通セットに適用され、基礎となるインシデントのビジネス・プロセスを自動化する適切なアクションをとる、ルールのコレクションです。インシデント・ルール・セットは、管理者間で共有するために公開できます。たとえば、各管理者がルールに定義されたものと同じ基準で通知を受信する場合、それぞれの管理者は同じルール・セットにサブスクライブできます。または、Enterprise Managerのスーパー管理者は、ルールに定義されたとおりにインシデントの通知を受信するよう他の管理者にインシデント・ルール・セットを割り当てることができます。

通知システムによる使用(第1.5項「通知」の「ルール」参照)に加えて、第1.6.3項「コネクタ」での説明のとおり、ルール・セットにより、Enterprise Managerがインシデントの作成、インシデントの更新、またはトラブル・チケット・システムへのコールなどのその他のアクションを実行するように指示することもできます。

1.6.3 コネクタ

Oracle Management Connectorはサード・パーティの管理システムとEnterprise Managerを統合します。コネクタには、イベント・コネクタとヘルプデスク・コネクタの2つのタイプがあります。

イベント・コネクタを使用して、Enterprise ManagerをOracle以外の管理システムとイベントを共有するように構成できます。コネクタはOracle Enterprise Managerからのすべてのイベントを監視し、サード・パーティの管理システムでのアラート情報を自動的に更新します。イベント・コネクタは次の機能をサポートします。

- Oracle Enterprise Managerからサード・パーティの管理システムへのイベント情報の共有。

- Oracle Enterprise Managerとサード・パーティの管理システム間でのアラート・マッピングへのイベントのカスタマイズ。

- Oracle Enterprise Managerでのイベント変更と、サード・パーティの管理システムでのアラートの同期化。

ヘルプデスク・コネクタを使用して、Enterprise Managerで作成されたイベントのチケットを作成、更新またはクローズするようにEnterprise Managerを構成できます。コネクタにより生成されたチケットには、Enterprise Managerインシデントに関連する情報が含まれ、これにはヘルプデスク・アナリストがインシデントを解決するためのEnterprise Managerの診断および解決機能を利用できる、Enterprise Managerコンソールへのリンクが含まれています。Enterprise Mangerでは、チケットID、チケット・ステータス、およびサード・パーティのチケッティング・システムへのリンクが、インシデントのコンテキストに表示されます。これによりEnterprise Manager管理者にはチケット・ステータス情報と、チケットにすばやくアクセスする簡単な方法が提供されます。

使用可能なコネクタは次のとおりです。

- BMC Remedy Service Deskコネクタ

- HP Service Managerコネクタ

- CA Service Deskコネクタ

- HP Operations Managerコネクタ

- Microsoft Systems Center Operations Managerコネクタ

- IBM Tivoli Enterprise Consoleコネクタ

- IBM Tivoli Netcool/OMNIbusコネクタ

Oracle組込みコネクタの詳細は、Enterprise Manager Plug-ins Exchangeを参照してください。

http://www.oracle.com/goto/emextensibility

1.7 監視情報へのアクセス

Enterprise Managerでは監視情報にアクセスするための複数の方法を用意しています。インシデント管理の主な焦点は、インシデント・マネージャ・コンソールですが、Enterprise Managerにも、監視情報にアクセスするための別の方法が用意されています。次の図に、Enterprise Manager内でターゲット監視情報を表示する様々な場所を示します。次の図に、ターゲット・ステータスのロールアップとインシデントのロールアップを便利に表示するEnterprise Managerの概要ページを示します。

図1-2 Enterprise Managerコンソール

次の図に、システムまたはターゲットのインシデントを表示するインシデント・マネージャのホームページを示します。

図1-3 インシデント・マネージャ(システムまたはターゲットのコンテキスト)

監視情報はターゲットのホームページにも表示されます。次の図で、ターゲット・ステータスとインシデントのロールアップを確認できます。

図1-4 ターゲット・ホームページ

2 インシデント管理の使用

インシデント管理によって、根本的な問題が同じである可能性のある個別のイベントではなく、より広い管理の観点(インシデント)から重要な事項に焦点をあてることで、サービス中断を迅速かつ効率的に監視し解決できます。

この章の項:

学習内容:

管理の概念

管理対象の環境を管理するための基本的な方法。

- イベント管理

- インシデント管理

- 問題管理

インシデント管理環境の設定

インシデント管理に使用するEnterprise Managerの主要コンポーネントの設定および構成方法。

- 監視インフラストラクチャの設定

- 通知の設定

- 管理者および権限の設定

インシデントの処理

IT操作の問題を追跡および解決するためのインシデント管理の使用方法。

- 処理が必要な事項の発見

- インシデントの検索

- カスタム・ビューの設定

- 単純なインシデントへの応答および処理

- 複数のインシデント、イベントおよび問題への一括応答

- My Oracle Supportナレッジの検索

- サービス・リクエストのオープンの発行(問題のみ)

- インシデントと問題の抑止

- インシデントのワークロード分散の管理

- 定期的なイベントの確認

一般的なタスク

インシデント管理の一般的なタスクを実行する方法を説明するサンプル手順。

- メトリック・アラートの電子メール送信

- メトリック・アラートのSNMPトラップ送信

- イベント・コネクタへのイベント送信

- 異なる期間での異なる電子メール・アドレスへの電子メール送信

高度なトピック

特別なインシデント管理操作の実行方法。

- カスタム・インシデント・ステータスの定義

- メトリック・アラート・イベント・タイプのステートレス・アラートのクリア

- ユーザー報告のイベント

- 追加のルール・アプリケーション

- イベントの優先度付け

- 根本原因分析(RCA)とターゲットの停止イベント

Enterprise Manager 10/11gから12c以上への移行

通知ルールのインシデント・ルールへの移行

オラクル社はこの章の説明を補完するために、環境を監視するためのインシデント管理の基本について速習する手段を提供する説明用ビデオを作成しています。

説明用ビデオ:
インシデント管理に関するビデオ・チュートリアルは、次を参照してください。
インシデント管理の概要

https://apex.oracle.com/pls/apex/f?p=44785:24:2961267987520:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5738%2C24">>https://apex.oracle.com/pls/apex/f?p=44785:24:2961267987520:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5738%2C24

インシデント管理: インシデント・マネージャでのビューの作成

https://apex.oracle.com/pls/apex/f?p=44785:24:6091052115237:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5739%2C24

インシデント管理: インシデント詳細の表示

https://apex.oracle.com/pls/apex/f?p=44785:24:107664888945874:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5740%2C24

インシデント管理: インシデント・ルール・セットの使用のパート1

https://apex.oracle.com/pls/apex/f?p=44785:24:114716879428375:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5758%2C24

インシデント管理: インシデント・ルール・セットの使用のパート2

https://apex.oracle.com/pls/apex/f?p=44785:24:102172707760983:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5759%2C24

2.1 管理の概念

Enterprise Managerでは、3レベルの管理の精度を公開し、それらを組み合せて、環境を完全に監視および管理できます。次の管理レベルがあります。

- イベント管理

- インシデント管理

- 問題管理

2.1.1 イベント管理

直感的に、監視環境内の特定のイベントを監視します。イベントは、管理対象ターゲットについての重要な事象であり、一般的には、通常の運用状態から逸脱した出来事の発生を示します。これにより、Enterprise Managerにより管理された環境内で、関心のある何かが発生したことを示す共通の方法を提供します。イベントの例は次のとおりです。

- メトリック・アラート

- コンプライアンス違反

- ジョブ・イベント

- 可用性アラート

既存のEnterprise Managerのユーザーは、メトリック・アラートおよびメトリック・コレクション・エラーについてよく知っているかもしれません。Enterprise Manager 12cでは、メトリック・アラートはイベントの一種であり、数多くあるイベント・タイプの1つです。イベントの概念は、監視の問題やコンプライアンスの問題などのEnterprise Managerにより検知される様々な例外条件を、共通の概念に統一します。これは、Enterprise Managerにより管理されたデータセンター内で関心のある何かが発生したことを示すことができる、イベント管理機能の一貫性のある共通のセットにより裏付けられています。

すべてのイベントには、次の属性があります。

表2-1 イベント属性

属性

説明

Type

報告されるイベントのタイプ。特定のタイプのすべてのイベントは、問題の性質を正確に記述する同じ属性のセットを共有します。たとえば、「メトリック・アラート」、「コンプライアンス標準スコア違反」、「ジョブ・ステータスの変更」があります。

Severity

イベントの重大度。たとえば、「致命的」、「警告」、「クリティカル」があります。

内部名

内部名はイベントの性質を記述するもので、イベントの検索に使用できます。たとえば、すべてのtablespacePctUsedイベントを検索することができます。

イベントが発生するエンティティ。

イベントは、ターゲット、非ターゲット・ソース・オブジェクト(ジョブなど)で発生、またはターゲットおよび非ターゲット・ソース・オブジェクトに関係する可能性があります。注意: この属性はイベントの管理に必要な権限を決定するときに重要です。

メッセージ

イベントに関連付けられた情報テキスト。

報告日

イベントが報告された時刻。

カテゴリ

イベントの機能上または操作上の分類。

使用可能なカテゴリ

- 可用性

- ビジネス

- 容量

- 構成

- 診断

- エラー

- フォルト

- ジョブ

- 負荷

- パフォーマンス

- セキュリティ

原因分析の更新

ターゲットの停止イベントの根本原因分析に使用します。

可能な値: 根本原因または兆候

イベント・タイプ

イベントのタイプは、イベントの構造およびペイロードを定義し、記述する条件の詳細を提供します。たとえば、しきい値違反により発生したメトリック・アラートが特定のペイロードを持つのに対し、ジョブ状態の変更は別の構造を持ちます。次の表に示すように、様々なイベント・タイプにより、Enterprise Managerの監視の柔軟性が大幅に拡張されています。

イベント・タイプ

説明

ターゲット可用性

ターゲット可用性イベントは、ターゲットの可用性ステータス(「稼働中」、「停止中」、「エージェント使用不可」、「ブラックアウト」など)を表します。

メトリック・アラート

特定のターゲットのメトリック(ホスト・ターゲットのCPU使用率など)またはターゲットとオブジェクトの組合せのメトリック(データベース・ターゲットの特定表領域の領域使用率など)でアラートが発生した場合に、メトリック・アラート・イベントが生成されます。

メトリック評価エラー

ターゲットに対して特定のメトリック・グループを収集できなかった場合に、メトリック評価エラーが生成されます。

ジョブ・ステータスの変更

Enterprise Managerジョブのステータス変更はすべてイベントとして処理され、これらのイベントは「ジョブ・ステータスの変更」イベント・クラスによって使用できます。
注意: インシデント・ルールの作成の前提条件は、関連するジョブ・ステータスが有効になっていることと、必要なターゲットがジョブ・イベント生成基準に追加されていることです。この条件を変更するには、「設定」メニューから、「インシデント」、「ジョブ・イベント」の順に選択します。

コンプライアンス標準ルール違反

コンプライアンス基準ルールの違反に対して生成されるイベント。各イベントは、特定のターゲットに関するコンプライアンス・ルールの違反に対応します。

コンプライアンス標準スコア違反

コンプライアンス基準スコアの違反に対して生成されるイベント。特定のターゲットに関するコンプライアンス基準について、コンプライアンス・スコアが事前定義済のしきい値を下回ると、イベントが生成されます。

高可用性

高可用性イベントがデータベースの可用性操作(停止、起動)、データベースのバックアップおよびData Guard操作(スイッチオーバー、フェイルオーバーおよびその他の状態の変更)に対して生成されます。

サービス・レベル合意のアラート

これらのイベントは、サービス・レベルまたはサービス・レベル目標がサービスに対して違反すると生成されます。サービス・レベル合意またはサービス・レベル目標に対して発生します。

ユーザー報告

これらのイベントはエンドユーザーによって作成されます。

アプリケーションの依存性とパフォーマンスのアラート

J2EEアプリケーションまたはコンポーネント関連のメトリックでしきい値を超えた場合に、アプリケーションの依存性とパフォーマンス(ADP)監視によってアラートが生成されます。

アプリケーション・パフォーマンス管理KPIアラート

アプリケーション・パフォーマンス管理(APM)のキー・パフォーマンス・インジケータ(KPI)アラート・イベントは、ビジネス・アプリケーション・ターゲットに関連付けられているAPM管理対象エンティティでメトリックのKPI違反アラートが発生したときに生成されます。

JVM診断しきい値違反

Java仮想マシン・ターゲットでJVMDメトリックがしきい値を超えると、JVMD診断イベントが発生します。

イベントの重大度

イベントの重大度は特定の問題の重要性を示します。次の表に、様々なイベントの重大度レベルをそれに対応するアイコンとともに示します。

アイコン

Severity

説明

致命的

対応するサービスはすでに使用不可となっています。たとえば、監視対象ターゲットは停止しています(ターゲット停止イベント)。「致命的」は最高レベルの重大度で、イベント・タイプ「ターゲット可用性」にのみ適用されます。

クリティカル

特定の領域で即時のアクションが必要です。その領域は、機能していないか、緊急の問題が発生しています。

警告

特定の領域で注意が必要ですが、その領域は機能を続けています。

アドバイザ

特定の領域に即時のアクションは不要ですが、領域の現在の状態について注意することをお薦めします。この重大度は、たとえばOracleのベスト・プラクティス違反を報告するのに使用できます。

クリア

イベントを発生させた条件が解決されました。

情報

特定の条件が発生しましたが、改善処置は必要ありません。
重大度が情報のイベントは

- インシデント管理UIに表示されません。

- インシデントを作成できません。

- Enterprise Manager内に格納されません。

2.1.2 インシデント管理

Enterprise Manager環境は、(インシデントが単一のイベントで構成されていたとしても)個々のイベントではなくインシデントを介して監視および管理します。管理対象環境で生成されるすべてのイベントの中には、ビジネス・アプリケーションに影響を与えるため、対処を必要とするイベントのサブセットが存在します(ターゲットの停止イベントなど)。しかし、インシデントによる管理では、関心のあるイベントのサブセットが関連している、個別のイベントとしてではなく1つの問題として対応する必要のあるより高いレベルの問題を示す可能性のある、より複雑な状況に対応できます。イベントの1つのクラスタはそれ自身では小さな管理上の問題であっても、一緒に見てみると、監視インフラストラクチャの複数のドメイン/レイヤーからイベントを構成する可能性のある、より大きい問題を表している可能性があります。

たとえば、ホストを監視中とします。1つ以上のホストの負荷を監視する場合、興味を引かれるイベントとしては、許容可能なメトリックしきい値を超過しているCPU使用率、メモリー使用率、スワップ使用量などのイベントなどがあります。個別では、これらのイベントはホストの問題を示している場合もそうでない場合もありますが、全体として、これらのイベントは監視対象のホストの負荷が非常に高くなっていることを示すインシデントを形成します。

インシデントは、個別のイベントではなく、ビジネスに影響を与える可能性のあるより大きなサービスの中断を表します。そのためインシデントによる管理では、ビジネスに影響を与える可能性のある、複数のドメインに関連する可能性のある複雑な操作の問題を監視できます。これらのインシデントは、通常、追跡され、適切な人員が割り当てられ、できるだけ早く解決する必要があります。監視情報を統合し、エコシステム間でリソースをより効果的に割り当てる集中管理監視を効果的に実装して、問題を解決または問題の発生を防ぐことができます。最終的な成果は、ITリソースのより高いパフォーマンスを導く、ビジネス・プロセスをより適切に実装することです。

イベントが管理対象の環境で対応が必要な問題を示している間は、関連するイベントをまとめたサブセットを1つの作業単位として処理する方が効率的です。同じ問題を表している異なるイベントを処理したり、複数の領域関連のイベントを含む1つのインシデントを処理したりできます。たとえば、実行中に領域が少なくなっていることを示す複数のスペース・イベントを様々なターゲットから受け取ります。多数の個別のイベントを管理するかわりに、より小さいインシデントのセットをより効果的に管理できます。

インシデントは、潜在的にビジネス・アプリケーションに影響を与える可能性があり、その管理を必要とする重要なイベントまたは関連する重要なイベントのセットです。これらのインシデントは、通常、追跡され、適切な人員が割り当てられ、できるだけ早く解決する必要があります。これらのインシデント管理操作を、Enterprise Manager内の直感的なUIであるインシデント・マネージャを使用して実行します。

インシデント・マネージャは、インシデントを表示、管理、診断および解決し、混乱の根本原因を識別、解決および排除する中枢となる場所を提供します。このUIの詳細は、第2.1.5項「インシデント・マネージャ」を参照してください。

2.1.2.1 インシデントの処理

インシデントが作成されると、Enterprise Managerの豊富なインシデント管理ワークフロー機能群が使用できるようになり、インシデントをライフサイクル全体を通して管理および追跡できます。

- インシデント所有権の割当て。

- インシデント解決ステータスの追跡。

- インシデント優先度の設定。

- インシデントのエスカレーション・レベルの設定。

- 手動での要約を提供する機能。

- ユーザー・コメントを追加する機能。

- 抑止および抑止解除する機能。

- 手動でインシデントをクリアする機能。

- 手動でチケットを作成する機能。

すべてのインシデント管理/追跡操作は、インシデント・マネージャから実行します。イベントに対するインシデントの作成では、管理者へのインシデントの割当て、優先度の設定、通知の送信およびその他のアクションが、(インシデント)ルールを使用して自動化できます。

インシデントのステータス

組織内でのインシデントのライフサイクルは、通常、2つの部分の情報で決定されます。インシデントの現在の解決状態(インシデント・ステータス)と、他のインシデントと比較したインシデントの解決の重要度(優先度)です。主要なインシデント属性として、次のオプションを使用できます。

- 新規

- 処理中

- クローズ

- 解決

デフォルトのオプションが適切でない場合に、追加のステータスを定義できます。また、Enterprise Manageコマンドライン・インタフェース(EM CLI)を使用して、ラベルを変更できます。詳細は、「高度なトピック」を参照してください。

優先度

優先度を変更することで、インシデントをエスカレートし、特定のITオペレータへの割当てや上級管理者への通知などの操作を実行できます。次の優先度オプションを使用できます。

- なし

- 低

- 中

- 高

- 非常に高

- 緊急

優先度は多くの場合、ビジネスへの影響と解決の緊急性によって決まる単純なビジネス・ルールに基づいています。

インシデント属性

すべてのインシデントには、ID、追跡用のステータス、所有権などの情報を提供する属性があります。次の表に、使用可能なインシデント属性を示します。

インシデント属性

定義

エスカレート済

組織のITまたは管理階層からのインシデントでの注意のレベルを上げるためのエスカレーションを示すエスカレーション・レベル。
使用可能なエスカレーションのレベルは次のとおりです。

- なし(エスカレートされていない)

- 「レベル1」から「レベル5」まで

カテゴリ

インシデントの操作上または組織上の分類。インシデント(およびイベント)は複数のカテゴリを持つことができます。
インシデント内のすべてのイベントのカテゴリが集計されます。

使用可能なカテゴリ

- 可用性

- ビジネス

- 容量

- 構成

- 診断

- エラー

- フォルト

- ジョブ

- 負荷

- パフォーマンス

- セキュリティ

サマリー

インシデントの内容を示す直感的なメッセージ。デフォルトでは、インシデント・サマリーはインシデントの最後のイベントのメッセージから取得されますが、このメッセージはインシデントを操作している管理者が修正されたサマリーに変更できます。

インシデント作成

インシデントが作成された日時。

最終更新

インシデントが最後に更新された、またはインシデントがクローズした日時。

Severity

重大度はインシデント内のイベントの最悪の重大度に基づきます。たとえば、「致命的」、「警告」、「クリティカル」があります。

ソース

インシデントのソース・エンティティ。

優先度

優先度の値

- なし(デフォルト)

- 低

- 中

- 高

- 非常に高

- 緊急

ステータス

インシデントのステータス。

- 新規(デフォルト)

- 処理中

- クローズ(インシデントがクローズされたときのターミナルの状態。詳細は、次を参照してください。)

- 解決

デフォルトのオプションが適切でない場合に、追加のステータスを定義できます。また、Enterprise Manageコマンドライン・インタフェース(EM CLI)を使用して、ラベルを変更できます。

クローズ・ステータス: インシデント重大度がクリアされると、Enterprise Managerによってステータスが自動的にクローズに設定され、管理者が手動でクローズ・ステータスを選択することはありません。インシデント内に含まれるすべてのイベントがクリアされると、インシデント重大度はクリアに設定されます。一般的に、メトリック・アラート値が重大度しきい値未満になるときと同様に、エージェントがクリアの重大度を設定します。イベントまたはインシデントが手動のクリアをサポートする場合、インシデント・マネージャUIに「クリア」オプションが表示されます。インシデントが管理者またはEnterprise Managerによってクリアされたときのみ、Enterprise Managerによってステータスがクローズに設定されます。UIにインシデントをクリアするオプションが表示されない場合、Enterprise Managerが、監視対象の条件が真でないことを検出したときに自動的にステータスをクリアに設定することを意味します。たとえば、インシデントが修正されたことを示すとします。ステータスを解決に設定することができ、Enterprise Managerは重大度をクリアしたときにステータスをクローズに設定します。

コメント

分析情報またはインシデントを解決するためのアクションを伝えるために管理者によって追加される注釈。

owner

現在、そのインシデントについて作業中の管理者/ユーザー。

確認済

ユーザーがインシデントまたは問題の所有権を受け入れたことを示します。使用可能なオプションは「はい」または「いいえ」です。
インシデントが確認された場合、そのインシデントは暗黙的にそれを確認したユーザーに割り当てられます。ユーザーがインシデントを自分自身に割り当てた場合、そのインシデントは「確認済」とみなされます。一度確認済となったインシデントを未確認にはできませんが、別のユーザーに割り当てることはできます。インシデントを確認することで、そのインシデントについての通知が繰り返されることを停止します。

原因分析の更新

ターゲットの停止インシデントの根本原因分析に使用します。
可能な値: 根本原因または兆候

2.1.2.2 単一イベントから構成されるインシデント

最も単純なインシデントは、単一イベントから構成されます。次の例では、ユーザーはなんらかの製品ターゲットの停止に関心があります。管理対象ターゲットの停止を検出したときにEnterprise Managerによって生成される、ターゲットの停止イベント用のインシデントを作成できます。インシデントが作成されると、ソリューションの追跡と管理に必要なすべてのインシデント管理が使用可能になります。

図2-1 単一イベントのあるインシデント

図は、インシデント属性とイベント属性の両方を使用してインシデントを管理する方法を示しています。図から、データベースDB1が停止し、「致命的」重大度のイベントが発生したことがわかります。イベントが新しく生成されるときには、所有権やステータスはありません。インシデントがオープンされ、手動で更新、または所有者、ステータスやその他の属性を設定する、自動化されたルールで更新できます。例では、所有者/管理者Scottが現在問題の解決作業を行っています。

インシデントはインシデント内のすべてのイベントの最悪の重大度を継承するため、インシデントの重大度は現在「致命的」です。この場合、インシデントに関連付けられているイベントは1つのみであるため、重大度は「致命的」です。

2.1.2.3 複数イベントから構成されるインシデント

関心の対象に複数のイベントが関連する場合があります。複数イベントを収容できるインシデントの機能により、複雑でより意味のある問題を監視および管理できます。

注意:
複数イベントのインシデントは、自動的に生成されません。

たとえば、管理対象システムの領域が枯渇した場合、表領域フルおよびファイルシステム・フルという、別々の複数イベントが生成されます。しかし、両方とも領域の枯渇に関連しています。また別のマシン・リソースの監視例として、CPU使用状況、メモリー使用状況およびスワップ使用状況のイベントの同時生成があります。詳細は、「インシデントの手動作成」を参照してください。これらのイベントは1つにまとめられ、管理対象ホストに非常に高い負荷がかかっていることを示す1つのインシデントになります。次の図は、この例を示しています。

図2-2 複数イベントのあるインシデント

インシデントはインシデント内のすべてのイベントの最悪の重大度を継承します。インシデント・サマリーは、このインシデントが関心の対象である理由(この場合はマシンの負荷が高い)を示します。このメッセージは、このインシデントを参照するすべての管理者にとって直感的なインジケータです。デフォルトでは、インシデント・サマリーはインシデントの最後のイベントのメッセージから取得されますが、このメッセージはインシデントを操作している管理者が変更できます。

管理者はマシン全体の負荷に関心があり、2つのイベントは両方ともホストの過負荷状況を表しているため、管理者Samは、この2つのメトリック・イベントに対して1つのインシデントを手動で作成しました。メモリーが一杯になり、消費されているCPUリソースが多すぎるため、管理者はアクションを実行する必要があります。現在の状態では、この条件はホストで実行されているアプリケーションに影響を与えます。

2.1.2.4 インシデントの作成方法

インシデントはルールおよびルール・セット(特定のイベントの発生時にその処理方法をインシデント・マネージャに伝えるユーザー定義の手順)により自動的に作成されることが最も一般的です。前述の例のように、インシデントは手動で作成することもできます。インシデントが発生すると、その重大度はインシデント内のすべてのイベントの最悪の重大度を継承します。最新のイベント・メッセージはデフォルトでインシデント・サマリーになります。Enterprise Manager 13c以上では、グループ化されたインシデントについてカスタマイズされたメッセージを定義することもできます。インシデントは手動で作成することもできます。詳細は、「インシデントの手動作成」を参照してください。

2.1.3 問題管理

問題管理には、インシデントの基礎となる根本原因の追跡を支援する機能が含まれます。インシデントで表される即時サービス中断が解決されると、問題の基礎となる根本原因の理解と解決に進むことができます。

Enterprise Manager 12cにおける問題は、診断インシデントおよび拡張診断リポジトリ(ADR)に格納される問題診断インシデント/問題に照準が絞られており、そのような問題は、ソフトウェアにクリティカルなエラーが発生したときにOracleソフトウェアにより自動的に生成されます。このため、問題は、すべてのOracleソフトウェア・インシデントの根本原因を表します。診断インシデントでは、根本原因に対処するため、診断インシデントの根本原因を表す問題オブジェクトが作成されます。問題は、ソフトウェアにおける個別のエラーを一意に識別する問題キーで識別されます。エラーは発生するたびに診断インシデントとなり、問題オブジェクトと関連付けられます。

Oracleソフトウェアに問題が発生した場合、オラクル社の推奨する問題解決の手続きは、サービス・リクエスト(SR)をオープンしてサポートに診断ログを送信してもらい、最終的にオラクル社からソリューションを提供することです。インシデントとして、Enterprise Managerは問題管理のためにすべての追跡、診断およびレポート機能を使用可能にします。インシデント・マネージャまたはターゲット/グループのホームページのいずれを使用するにしても、オープンしているすべてのインシデントおよび問題を表示すれば、管理対象ターゲットに実際に影響を与えている問題を簡単に判断できます。

問題を管理するには、サポート・ワークベンチを使用して、ADRで収集された診断詳細をまとめてSRをオープンできます。ユーザーはインシデント・マネージャで問題を管理する必要があります。サポート・ワークベンチ機能は、問題のコンテキストに応じて、インシデント・マネージャを介して(「ガイドされた解決」領域)使用できます。

2.1.4 ルール・セット

インシデント・ルールおよびルール・セットはイベント、インシデントおよび問題に関連するアクションを自動化します。重要なイベントに基づくインシデントの作成を自動化し、電子メールの送信やヘルプディスク・チケットのオープンなどの通知アクションを実行したり、インシデントの所有権、優先度またはエスカレーション・レベルなどのインシデント・ワークフロー・ライフサイクルの管理操作を実行できます。

以前のバージョンのEnterprise Managerでは、通知ルールを使用して、アクションの実行またはEnterprise Managerからの通知の受信(電子メールの送信、ページ、ヘルプディスク・チケットのオープン)を行う個々のターゲットと条件を選択しました。Enterprise Manager 13cでは、通知ルールの概念と機能は、インシデント・ルールとルール・セットに置き換えられました。

- ルール: ルールは、Enterprise Managerに対して、インシデント、イベントまたは問題が発生したときに、通知の実行などの特定のアクションの実行を指示します。ルールでは、通知のみではなく、インシデントの生成、インシデントや問題の更新などのアクションの実行をEnterprise Managerに指示することもできます。アクションには、条件的な性質も含まれます。たとえば、ルール・アクションを定義して、インシデントの重大度がクリティカルの場合にページを表示し、警告の場合には電子メールを送信するのみにできます。

- ルール・セット: インシデント・ルール・セットは、ターゲット(ホスト、データベース、グループ)、ジョブ、メトリック拡張、または自己更新などのオブジェクトの共通セットに適用され、基礎となるイベント、インシデントおよび問題管理のビジネス・プロセスを自動化する適切なアクションをとる、ルールのコレクションです。

運用では、ルール・セット内の各ルールは、ルール・セット自体と同様に指定された順序で実行されます。ルール・セットは指定された順序で実行されます。デフォルトでは、ルールおよびルール・セットの実行順序はどちらも作成された順序ですが、インシデント・ルールのUIから並替えが可能です。

次の図は、標準的なルール・セットの構造、および個々のルールがどのように異種のターゲット・グループに適用されるかを示しています。

図2-3 インシデント・ルール・セットの適用

この図は、ターゲット・グループに関係するすべてのルールを、1つのルール・セットにまとめることのできる様子を表しています(これがベスト・プラクティスでもあります)。前述の例では、PROD-GROUPという名前のグループは、ある会社の管理対象環境に存在するホスト、データベースおよびWebLogicサーバーから構成されています。このグループを管理する単一のルール・セットが作成されています。

ルール・セットは、実際のルールを含むのに加え、次の属性を持ちます。

- 名前: ルール・セットを説明する名前。

- 説明: ルール・セットの目的を示す簡単な説明。

- 適用先: ルール・セット内のすべてのルールを適用するオブジェクト。有効なルール・セットのオブジェクトは、ターゲット、ジョブ、メトリック拡張および自己更新です。

- 所有者: ルール・セットを作成したEnterprise Managerのユーザー。ルール・セットの所有者は、ルール・セットおよびルール・セット内のルールを更新または削除できます。

- 有効: そのルール・セットが、現在適用されているかどうか。

- タイプ: エンタープライズまたはプライベート。「ルール・セット・タイプ」を参照してください。

2.1.4.1 即時利用可能なルール・セット

Enterprise Managerは、一般的なシナリオに基づくインシデント作成やイベントのクリア用に即時利用可能なルール・セットを提供します。即時利用可能なルール・セットは編集も削除もできませんが、無効にすることができます。ベスト・プラクティスとして、即時利用可能なルール・セットの独自のコピーを作成し、即時利用可能なルール・セットに直接サスブクライブするのではなく、そのルール・セットのコピーにサブスクライブする必要があります。事実上、ルール・セットのコピーを作成し、適切なターゲットのグループ(管理グループが望ましい)を選択することによって企業のニーズに合うようターゲット基準を変更しています。

即時利用可能なルール・セット定義および実行するアクションは、Oracleによりいつでも変更される可能性があり、パッチ適用中またはソフトウェアのアップグレード中に適用されることに注意してください。

通常のEnterprise Manager管理者はルール・セットで次の操作を実行できます。

- サブスクライブ

- 電子メール通知をサブスクライブ

- サブスクライブ解除

- 電子メール通知をサブスクライブ解除

- 有効化

- 無効化

注意:
管理者はルール・セットにサブスクライブできますが、少なくとも「ターゲットの表示」権限のあるターゲットから通知を受信するのみです。

Enterprise Managerスーパー管理者にはルール・セットを並べ替えできる機能が追加されています。

エンタープライズ・ルール・セットは順次評価され、必要に応じて複数のパスを通過します。処理中のエンティティに変更があるとき(イベントに作成中のインシデントや、ルールのために変更中のインシデント優先度など)、一致がなくなるまですべてのルールを最初から再実行します。前のパスで一致したルールは、もう一致しません(無限ループを防ぐため)。

たとえば、新しいイベント、インシデントまたは問題が発生したときに、リストの最初のルール・セットがチェックされ、そのメンバー・ルールのいずれかが適用されるかどうかが判断され、それらのルールで指定されている適切なアクションが実行されます。2番目のルールがチェックされ、ルールが適用されるかが判断される、などと続きます。プライベート・ルール・セットは、すべてのエンタープライズ・ルール・セットの評価が完了してからのみ評価され、特定の順番はありません。

重要:
ルール・セットの順番はイベント、インシデントおよび問題の処理ワークフローを定義しているため、並べ替えるときは注意してください。システムへの影響を十分に理解せずにルール・セットを並べ替えると、発生するイベント、インシデントおよび問題に対して意図しないアクションが実行されてしまうことがあります。

2.1.4.2 ルール・セット・タイプ

ルール・セットには次の2つのタイプがあります。

- エンタープライズ: IT組織内のすべての操作手順の実装に使用します。サポートされるすべてのアクションを、このタイプのルール・セットに使用できます。ただし、このタイプのルール・セットはすべてのアクションを実行できるため、エンタープライズ・ルール・セットを作成できるユーザーには制限があります。
エンタープライズ・ルール・セットを作成または編集するには、管理者に「エンタープライズ・ルール・セット」リソースに対する「エンタープライズ・ルール・セットの作成」権限が付与されている必要があります。ただし、今後、ルール・セットの所有者が「エンタープライズ・ルール・セットの作成」システム権限を喪失しても、そのルール・セットを引き続き編集または削除できます。スーパー管理者はどのルール・セットも編集または削除できます。ルール・セットの最初の作成者が他の管理者にルール・セットを編集させる場合は、共同作成者を追加することで、共同作業するためにアクセスを共有する必要があります。エンタープライズ・ルール・セットはすべての管理者から参照できます。

- プライベート: 管理者が、標準のビジネス・プラクティスとしてではないが、なんらかの監視対象について通知される必要がある場合に使用します。プライベート・ルール・セットが実行できるアクションは、ルール・セット所有者への電子メールの送信のみです。管理者は「エンタープライズ・ルール・セットの作成」リソース権限が付与されているかどうかにかかわらず、プライベート・ルール・セットを作成できます。プライベート・ルール・セットはまれにのみ、または例外的な状況でのみ使用することをお薦めします。

ルール・セットがアクションを実行するときは、そのルール・セットの作成者の権限が使用されます。たとえば、ルール・セットの所有者および作成者は、通知を受け取るためには少なくとも「ターゲットの表示」権限が、インシデントを更新するためには少なくとも「ターゲット・イベントの管理」権限が必要です。例外はルール・セットが通知を送信するときです。この場合、送信先のユーザーの権限が使用されます。

2.1.4.3 ルール

ルールは、着信イベント、インシデントまたは問題に対するアクションを自動化するルール・セット内の手順です。ルールは着信インシデント/イベント/問題を操作するため、新しいルールを作成した場合、そのルールはすでに発生したインシデント/イベント/問題を遡って操作しません。

各ルールは次の2つの部分から構成されます。

- 基準: ルールが適用されるイベント/インシデント/問題。

- アクション: 指定したイベント、インシデントまたは問題に対する1つ以上の操作の順序付きセット。各アクションは、追加の条件に基づいて実行できます。

次の表に、ルールの基準とアクションがルールの適用を決定する方法を示します。このルール操作の例では、選択したイベントおよびインシデントで実行される3つのルールがあります。ルール・セット内で、ルールは指定された順序で実行されます。ルールの実行順序はいつでも変更可能です。デフォルトでは、ルールは作成された順番に実行されます。

表2-2 ルール操作

ルール名

実行順序

基準

アクション

条件

アクション

ルール1

1番目

警告またはクリティカル重大度のCPU使用率(%)、使用済表領域(%)メトリック・アラート・イベント

インシデントを作成します。

ルール2

2番目

警告またはクリティカル重大度のインシデント

重大度=クリティカルの場合

重大度=警告の場合

ページャによる通知

電子メールによる通知

ルール3

3番目

インシデントが6時間以上未確認

エスカレーション・レベルを1に設定

このルール操作の例では、ルール1は「CPU使用率」と使用済表領域の2つのメトリック・アラート・イベントに適用されます。これらのイベントが「警告」または「クリティカル」重大度しきい値レベルに達すると、インシデントが作成されます。

インシデントの重大度レベル(インシデントの重大度は最悪のイベントの重大度から継承されます)が「警告」に達すると、その1番目の条件に従ってルール2が適用され、Enterprise Managerにより電子メールが管理者に送信されます。インシデントの重大度レベルが「クリティカル」に達すると、ルール2の2番目の条件が適用され、Enterprise Managerによりページャが管理者に送信されます。

そのインシデントが6時間を超えてもオープンのまま残っている場合は、ルール3が適用され、インシデントのエスカレーション・レベルが「なし」から「1」にアップします。この時点で、Enterprise Managerはすべてのルール・セットおよびそのルールを最初から再び実行します。

2.1.4.3.1 ルール・アプリケーション

ルール・セット内の各ルールは、イベント、インシデントまたは問題に適用されます。それぞれに対し、次のようなルール適用条件を選択できます。

- ルールを着信イベントまたは更新されたイベントのみに適用

- ルールをクリティカルなイベントのみに適用。

ルールは、ルールの作成(または更新)時に選択された基準に従ってイベント、インシデントおよび問題に適用されます。次の状況で、ルールの適用に使用される手法を示します。

- ルールの1つが着信イベントへの応答で新しいインシデントを作成すると、Enterprise Managerはそれ以上イベントをルールおよびルール・セットを一致させるのを終了します。完了すると、Enterprise Managerは新しく作成したインシデントを最初からすべてのルール・セットと照合し、インシデント特有のルールが一致するかどうかを判断します。

- 着信イベントがすでにインシデントと関連付けられている場合(たとえば警告イベントがインシデントを作成してからクリティカル・イベントが同じ問題から生成される場合)、Enterprise Managerはすべての一致するルールをイベントに適用してから、すべてのルールをインシデントと照合します。

- ルールをインシデントに適用中に、インシデントが変更された(優先度の変更など)場合、Enterprise Managerはその時点でルールの適用を停止し、そのルールを最初からインシデントに再度適用します。インシデントを更新した条件付きアクションは、同じルール適用サイクルで再び一致することはありません。

2.1.4.3.2 ルール基準

次の表に、それぞれのタイプで選択可能な基準を示します。

表2-3 ルールの基準: イベント

基準

説明

Type

特定のイベント・タイプにルールを適用します。

Severity

特定のイベント重大度にルールを適用します。

カテゴリ

特定のイベント・カテゴリにルールを適用します。

ターゲット・タイプ

特定のターゲット・タイプにルールを適用します。

ターゲットのライフサイクル・ステータス

ターゲットの特定のライフサイクル・ステータスにルールを適用します。ライフサイクル・ステータスは、ターゲットの運用ステータスを示すターゲット・プロパティです。

インシデントと関連付け

通常、イベントはルールを介してインシデントと関連付けられます。「はい」または「いいえ」を指定します。

イベント名

特定の名前のイベントにルールを適用します。名前は、完全一致またはパターン一致のどちらでも指定できます。

原因分析の更新

根本原因分析(Root Cause Analysis: RCA)イベントの完了により、「根本原因」または「兆候」のいずれかとマークされたイベントにルールが適用されます。または、もはや兆候ではない場合は、ルールはRCAイベントに作用します。

関連インシデントの確認

インシデントが管理者によって確認されている場合、特定のインシデントと関連付けられているイベントにルールを適用します。「はい」または「いいえ」を指定します。

発生件数合計

重複するイベントで、イベントの発生件数合計が特定の数に達した場合にルールを適用します。

コメント追加済

管理者がコメントを追加したイベントにルールを適用します。

インシデントの場合、すべての新規または更新(あるいはその両方)のインシデント、または次の表に示す特定の基準に一致する新たに作成されたインシデントにルールを適用できます。

表2-4 ルールの基準: インシデント

基準

説明

インシデントを作成したルール

特定のルールによって生成されたインシデントにルールを適用します。

カテゴリ

特定のインシデント・カテゴリにルールを適用します。

ターゲット・タイプ

特定のターゲット・タイプにルールを適用します。

ターゲットのライフサイクル・ステータス

ターゲットの特定のライフサイクル・ステータスにルールを適用します。ライフサイクル・ステータスは、ターゲットの運用ステータスを示すターゲット・プロパティです。

Severity

特定のインシデント重大度にルールを適用します。

確認済

インシデントが管理者によって確認されている場合にルールを適用します。「はい」または「いいえ」を指定します。

owner

特定のインシデント所有者にルールを適用します。

優先度

選択した優先度と一致する優先度のインシデントにルールを適用します。

ステータス

選択したステータスと一致するステータスのインシデントにルールを適用します。

エスカレーション・レベル

選択したレベルと一致するエスカレーション・レベルのインシデントにルールを適用します。使用可能なエスカレーション・レベル: なし、レベル1、レベル2、レベル3、レベル4、レベル5。

チケットと関連付け

ヘルプデスク・チケットに関連付けられているインシデントにルールを適用します。「はい」または「いいえ」を指定します。

サービス・リクエストと関連付け

サービス・リクエストに関連付けられているインシデントにルールを適用します。「はい」または「いいえ」を指定します。

診断インシデント

診断インシデントにルールを適用します。「はい」または「いいえ」を指定します。

未割当て

新たに生成された所有者のないインシデントにルールを適用します。

コメント追加済

管理者がコメントを追加したインシデントにルールを適用します。

問題の場合、すべての新規または更新(あるいはその両方)の問題、または次の表に示す特定の基準に一致する新たに作成された問題にルールを適用できます。

表2-5 ルールの基準: 問題

基準

説明

問題キー

各問題には問題キーが含まれます。問題キーは問題を説明するテキスト文字列です。これには、エラー・コード(ORA600など)、場合によってはさらに1つ以上のエラー・パラメータが含まれます。

特定のキーまたは指定したパターン(ワイルドカード文字を使用します)に一致するキーを持つ問題にルールを適用できます。

カテゴリ

特定の問題カテゴリにルールを適用します。

ターゲット・タイプ

特定のターゲット・タイプにルールを適用します。

ターゲットのライフサイクル・ステータス

ターゲットの特定のライフサイクル・ステータスにルールを適用します。ライフサイクル・ステータスは、ターゲットの運用ステータスを示すターゲット・プロパティです。

確認済

確認されている問題にルールを適用します。

owner

特定の問題所有者にルールを適用します。

優先度

選択した優先度と一致する優先度の問題にルールを適用します。

ステータス

特定のステータスと一致するステータスの問題にルールを適用します。

エスカレーション・レベル

選択したレベルと一致するエスカレーション・レベルの問題にルールを適用します。使用可能なエスカレーション・レベル: なし、レベル1、レベル2、レベル3、レベル4、レベル5。

インシデント数

その問題に関連するインシデントの数が、指定した制限数に達した問題にルールを適用します。問題の所有者とオペレーション・マネージャには、電子メールで通知されます。

サービス・リクエストと関連付け

受信した問題がサービス・リクエストに関連付けられている場合にルールを適用します。「はい」または「いいえ」を指定します。

バグと関連付け

受信した問題が不具合に関連付けられている場合にルールを適用します。「はい」または「いいえ」を指定します。

未割当て

新たに生成された所有者のないインシデントにルールを適用します。

コメント追加済

管理者がコメントを追加した問題にルールを適用します。

2.1.4.3.3 ルール・アクション

それぞれのルールに応じて、Enterprise Managerで特定のアクションを定義できます。

ルール・セットで実行できるアクション・タイプの例をいくつか示します。

- イベントに基づくインシデントの作成。

- 電子メールの送信、ヘルプデスク・チケットの生成などの通知アクションの実行。

- 電子メール/PL/SQLメソッド/SNMPトラップを介したインシデント・ワークフロー通知の管理アクションの実行。たとえば、ターゲットの停止イベントが発生した場合、インシデントを作成し、そのインシデントについての電子メールを管理者Joeに送信します。2日後、まだそのインシデントがオープンしている場合は、エスカレーション・レベルを1に設定し、Joeの上司に電子メールを送信します。

次の表に、ルールの適用ごとに使用可能なアクションを要約しています。

表2-6 使用可能なルールのアクション

アクション

イベント

インシデント

問題

電子メール

はい

はい

はい

ページ

はい

はい

はい

高度な通知

SNMPトラップの送信

はい

いいえ

いいえ

OSコマンドの実行

はい

はい

はい

PL/SQLプロシージャの実行

はい

はい

はい

インシデントの作成

はい

いいえ

いいえ

ワークフロー属性の設定

はい

注意: イベント・ルール内で、関連付けられたインシデントのワークフロー属性も更新できます。

はい

はい

ヘルプデスク・チケットの作成

はい

注意: アクションは、最初にインシデントの作成、次にインシデントのチケットの作成により、間接的に実行されました。

はい

いいえ

注意:
Enterprise Managerのイベント・ルール・シミュレーション機能を使用することで、アクションを実際に実行することなく、ターゲットに対するルール・アクションをテストできます。詳細は「ルール・セットのテスト」を参照してください。

2.1.5 インシデント・マネージャ

インシデント・マネージャを使用すると、環境に影響するインシデントと問題を1か所で検索、表示、管理および解決できます。インシデント・マネージャを使用して、次のタスクを実行します。

- カスタム・ビューの使用によるインシデント、問題およびイベントのフィルタ処理

- ターゲット名、サマリー、ステータス、またはターゲットのライフサイクル・ステータスなどのプロパティによる特定のインシデントの検索

- インシデントの応答および処理

- 割当て、確認、ステータスの追跡、優先度付け、およびエスカレーションといったインシデントのライフサイクル管理

- インシデントの解決には、My Oracle Supportのナレッジ・ベースの記事へのアクセス(コンテキスト依存)、およびその他のオラクル社のドキュメントが役立ちます。

- インシデントをすばやく診断または解決するには、関連するEnterprise Manager機能へのコンテキスト依存の診断/アクション・リンクに直接アクセスします。

図2-4 インシデント・マネージャ

たとえば、オープン・インシデントがあるとします。インシデント・マネージャを使用して所有者と解決ステータスを追跡し、優先度を設定し、必要に応じてインシデントに注釈を追加して、共同作業環境で作業している他のユーザーと情報を共有できます。また、MOSから関連情報に直接アクセスし、問題の迅速な解決に役立つEnterprise Managerの他の領域にリンクできます。オープン・インシデントのドリルダウンによりこの情報にアクセスし、必要に応じて変更できます。

インシデントのコンテキストでのターゲット情報の表示

インシデントまたはイベントが発生したターゲットに関する情報を直接表示できます。表示される情報のタイプは、ターゲット・タイプに応じて異なります。

コンテキスト内ターゲット情報を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「監視」、「インシデント・マネージャ」の順に選択します。

2. 「インシデント・マネージャ」のUIからインシデントを選択します。インシデントに関する情報が表示されます。

3. 「一般」タブの「インシデントの詳細」領域で、ターゲットの横にある情報アイコン"i"をクリックします。インシデントに関するターゲット情報が表示されます。図2-5を参照

図2-5 インシデントのコンテキストでのターゲット情報

この方法でターゲット情報を表示できることで、イベントおよびインシデントが発生するターゲットに関するより多くの操作コンテキストが提供されます。さらにインシデントのライフサイクルをより効率的に管理できます。

Cloud Control Mobile

さらにモバイル・アプリケーションCloud Control Mobileも使用可能で、これにより、Enterprise Managerにリモートで接続するiDeviceを使用して出先でインシデントおよび問題を管理できます。

図2-6 Cloud Control Mobile

このモバイル・アプリケーションの詳細は、第43章「Enterprise Managerへのリモート・アクセス」を参照してください。

2.1.5.1 ビュー

ビューにより、関心のあるインシデントのみを分類して焦点を当てることができるので、インシデントを効率的に処理できます。ビューは、システムでインシデントおよび問題をフィルタリングするための検索基準のセットです。インシデント・マネージャでは、最も一般的なイベント、インシデントおよび検索の検索シナリオをカバーする事前定義済の標準ビューが用意されています。さらに、インシデント・マネージャでは、独自のカスタム・ビューを作成することもできます。カスタム・ビューは他のユーザーと共有できます。カスタム・ビューの作成の手順については、「カスタム・ビューの設定」を参照してください。カスタム・ビューの共有については、「カスタム・ビューの共有/共有解除」を参照してください。

2.1.6 要約

- イベント: Enterprise Managerにより検知されたターゲットでの重大な出来事の発生。
目標: 環境が確実に監視される。

- インシデント: 同じ問題に関する、重要なイベントのセット、または関連するイベントの組合せ。
目標: サービス中断が回避されるか、迅速に解決される。

- 問題: インシデントの基礎となる根本原因。現在、これは診断インシデントの基礎となる根本原因を表す、Oracleソフトウェアでのクリティカルなエラーを表しています。
目標: 問題の基礎となる根本原因を解決し、今後の問題の発生を防ぐ。

イベント、インシデント、および問題は連携して動作し、ITエコシステム全体を効果的かつ効率的に管理することができます。次の図に、これらが管理環境内でどのように動作するかを要約します。

図2-7 イベント/インシデント/問題のフロー

次の項ではイベント、インシデントおよび問題について詳細に説明します。

2.2 インシデント管理環境の設定

インシデントを使用して環境を監視および管理する前に、監視環境が適切に構成されていることを確認する必要があります。適切な構成は次のとおりです。

- 監視インフラストラクチャの設定

- 通知の設定

- 管理者および権限の設定

2.2.1 監視インフラストラクチャの設定

監視インフラストラクチャの設定の最初の手順は、監視の必要があり、そのためイベントのソースとなる条件を特定することです。無関係なイベントが過度に生成されるのを防ぎ、システムおよび管理者のオーバーヘッドを減少させるために、要件に基づいて、関心があり監視可能な対象を特定する必要があります。管理グループなどのEnterprise Manager機能を使用して、新しいターゲットが監視環境に追加されたときに、監視設定やコンプライアンス標準などの管理設定を自動的に適用できます。これにより、関心のある条件に対してのみイベントが発生するようにタスクが大幅に簡略化されます。詳細は、第6章「管理グループの使用」を参照してください。

例: 人事管理情報を含むデータベースを24時間使用可能にする必要があるとします。監視する条件の1つは、データベース・ターゲットが稼働中または停止のいずれであるかです。停止であれば、適切な担当者に通知し、できるだけ早く問題を解決してもらう必要があります。監視する条件にはその他に、パフォーマンスしきい値の違反、アプリケーション構成ファイルの変更、ジョブの失敗などがあります。イベントを使用して、これらのターゲットに直接関連する個別のターゲットおよび問題を監視および管理しています。たとえば、個別のデータベースの可用性、CPUおよびI/O負荷などの、個別のホストのしきい値違反を監視します。またはWebサービスのパフォーマンスも含まれる可能性があります。

通常、主に可用性やキー・パフォーマンス関連メトリックに関心がある場合は、デフォルトの監視テンプレートを使用し、特定のメトリックのみを収集し、それらのメトリックに対してのみイベントが発生するようにするには、別のテンプレート機能を使用する必要があります。

ジョブ・イベント: ジョブのステータスは、発行されたときから実行済まで、そのライフサイクルを通じて変更できます。各ジョブ・ステータスで、イベントを発生させ、ジョブのステータスを管理者に通知することができます。

一般的なルールとして、イベントは管理者の対応を必要とするジョブ・ステータス値に対してのみ生成される必要があります。これらのジョブ・ステータス値には、「失敗」または「停止中」などの「操作必須」および「問題」ステータス値が含まれます。しかし、不要なイベントでシステムがオーバーロードになるのを防ぐために、ジョブ・イベントは、デフォルトではターゲットに対して有効になっていません。そのため、ジョブに対してイベントを生成する場合には、次の操作を行う必要があります。

1. 適切なジョブ・ステータスを設定します。デフォルトの設定を使用することも、必要に応じて変更することもできます。

2. ジョブ関連のイベントを生成するターゲットのセットを指定します。
これらの操作はジョブ・イベント生成基準ページで行うことができます。「設定」メニューで「インシデント」、「ジョブ・イベント」の順に選択します。

2.2.1.1 ルール・セットの開発

インシデントのルールおよびルール・セットを作成する前の最初の手順は、組織のビジネス要求に応じていつインシデントが作成される必要があるかを戦略的に決定することです。考慮すべき重要な質問は次のとおりです。

1. 何のイベントでインシデントを作成する必要があるか。どのサービス中断がIT管理者により追跡され解決される必要があるか。

2. どの管理者が着信イベントまたはインシデントに対し通知される必要があるか。

3. イベントまたはインシデントが外部システム(ヘルプデスク・チケット・システムなど)へ転送されるか。

正確にビジネス要件が理解されたら、それをエンタープライズ・ルール・セットに変換します。次のガイドラインに従うと、システム・リソースを効率的に使用し、効率よく運用できます。

- ターゲット(ホストやデータベースなど)を操作するルール・セットの場合は、グループを使用してターゲットをルール・セットのより少ない数の監視エンティティに統合します。グループは、インシデント管理および応答を含む、同様の監視要件を持つターゲットで構成される必要があります。

- 同じターゲットのグループに適用されるすべてのルールは、1つのルール・セットに統合される必要があります。同じターゲットのグループに適用されるすべてのルールは、1つのルール・セットに統合される必要があります。1つのイベント・クラスに特有のイベントに対するルール、特定のイベント・クラスおよびターゲット・タイプのイベントに適用されるルール、またはそれらのターゲットのインシデントに適用されるルールを作成できます。

- ルール・セット内のルールの実行順序を活用します。ルール・セットとルール・セット内のルールは順次実行されます。そのため、ルールおよびルール・セットはその点に留意して順番を決めてください。

新規ルールを作成するとき、イベント、インシデントおよび問題のうち、どのオブジェクトにそのルールを適用するかを選択できます。次のルール使用のガイドラインは、どれを選択するかのガイドとして使用できます。

表2-7 ルール使用のガイドライン

ルール使用

アプリケーション

イベントに関するルール

Enterprise Managerで管理されているイベントのインシデントの作成。

イベントに関する通知の送信。

ヘルプデスクのアナリストによって管理されるインシデントのチケットを作成するには、イベントのインシデントを作成し、そのインシデントにチケットを作成します。

イベントをサード・パーティ管理システムに送信。

インシデントに関するルール

インシデント・ワークフロー操作の管理(所有者の割当て、優先度の設定、エスカレーション・レベル)を自動化し、通知を送信

インシデント条件に基づくチケットの作成。たとえば、インシデントがレベル2にエスカレートされた場合にチケットを作成します。

問題に関するルール

問題ワークフロー操作の管理(所有者の割当て、優先度の設定、エスカレーション・レベル)を自動化し、通知を送信

ルール・セットの例

次の例は、説明した実装ガイドラインの多くを示しています。すべてのターゲットは単一のグループに統合され、グループ・メンバーに適用されるすべてのルールは同じルール・セットに属し、ルールの実行順序が設定されています。この例では、次のようなターゲットから構成されるグループ(製品グループG)にルール・セットを適用します。

- DB1(データベース)

- Host1(ホスト)

- WLS1(WebLogic Server)

ルール・セット内のすべてのルールは、インシデント作成、通知およびエスカレーションの3種類のアクションを実行します。

例2-1 ルール・セットの例

- ルール・セットは、ターゲット: グループ・ターゲットGに適用されます。

- ルール・セットのルール:

1. 指定されたイベントでインシデントを作成するためのルール

2. インシデント発生時に通知を送信するルール

3. いくつかの条件に基づいてインシデントをエスカレーションするルール。たとえば、インシデントがオープンな時間の長さです。

ルール・セットのより詳細なビューでは、ガイドラインにどのように従ったかを確認できます。

例2-2 ルール・セットのより詳細な例

- 製品グループGのルール・セット

- ターゲット: 製品グループG

- ルール1: すべてのターゲット停止イベントのインシデントを作成します。

- ルール2: 重大度がクリティカルまたは警告の特定のデータベース、ホストおよびWebLogic Serverのメトリック・アラート・イベントのインシデントを作成します。

- ルール3: すべての問題ジョブ・イベントのインシデントを作成します。

- ルール4: すべてのクリティカル・インシデントについてページを送信します。すべての警告インシデントについて電子メールを送信します。

- ルール5: 致命的インシデントが12時間を超えてオープンされている場合は、エスカレーション・レベルを1に設定し、マネージャに電子メールを送信します。

この詳細ビューでは、すべてのグループ・メンバーに適用される5つのルールがあります。ルールの実行順序(ルール1からルール5)は、ルール・セット内の3種類のルール・アクション(ルール1から3)に対応します。

- ルール1-3: インシデントの作成

- ルール4: 通知

- ルール5: エスカレーション

ルールの実行順序をルール・アクション・カテゴリの進行状況と同期することで、実行効率が達成されます。この例に示すように、同じイベントのセットに対し重大度に基づき異なるアクションをとる条件付きアクションを使用することで、今後、複数のルールを変更する必要なく、イベント選択条件を変更することが容易になります。注意: これは、すべてのインシデント(ルール1から3)のアクション要件が同じであることを前提としています。

次の表は、この例における明示的なルール・セット操作を示しています。

表2-8 製品グループGのためのルール・セットの例

ルール名

実行順序

基準

アクション

条件

アクション

ルール・セット: 製品グループG内のターゲット

ルール1

1番目

DB1の停止

Host1の停止

WLS1の停止

インシデントを作成します。

ルール2

2番目

DB1

表領域フル(%)

注意: 警告およびクリティカルのしきい値は、ルールUIではなく、メトリックおよびポリシー設定で定義されます。

Host1

CPU使用率(%)

WLS1

ヒープ使用量(%)

重大度=警告の場合

重大度=クリティカルの場合

インシデントを作成します。

ルール3

3番目

DB1、Host1およびWLS1での、問題ジョブのステータス変更イベントの生成

インシデントを作成します。

ルール4

4番目

製品グループGのすべてのインシデント

重大度=警告

重大度=クリティカル

電子メールを送信します。

ページを送信します。

ルール5

5番目

12日を超えてインシデントがオープンのまま残存

ステータス=致命的

エスカレーション・レベルを「1」にアップします。

2.2.1.1.1 ルールを使用する前に

ルールを使用する前に、次の前提条件が設定されていることを確認してください。

- ユーザーのEnterprise Managerアカウントに通知プリファレンス(電子メールおよびスケジュール)が設定されていること。これはルールを作成および編集する管理者だけではなく、ルール・アクションの結果として通知されるユーザーにも必要です。

- コネクタ、チケットまたは拡張通知を使用する場合、これらはアクション・ページで使用する前に構成する必要があります。

- 電子メールの通知ができるように、SMTPゲートウェイが適切に構成されていること。

- ユーザーのEnterprise Managerアカウントに管理対象システムからのインシデントの管理に必要な適切な権限が付与されていること。

2.2.1.1.2 通知の設定

監視環境に対してどのイベントを発生させる必要があるかを決定した後、Enterprise Managerを電子メールおよびページを送信するように構成し、管理者用電子メール・アドレスを設定し、それらを電子メール/ページングとしてタグ付けすることで、企業の包括的な通知インフラストラクチャを構築する必要があります。さらに、組織のニーズに応じて、通知の設定に、OSスクリプト、PL/SQLプロシージャ、またはSNMPトラップのような、高度な通知方法の構成を含めることができます。Enterprise Managerの通知の詳細と設定手順については、第3章「通知の使用」を参照してください。

2.2.2 管理者および権限の設定

この手順には、適切な管理者の定義(セキュリティに対する適切な権限の割当てを含む)と、組織内で定義されたロールとドメイン所有権に基づく通知割当ての設定が含まれます。

ユーザー・アカウントの管理を実行するには、Enterprise Managerのホームページの「設定」をクリックし、「セキュリティ」、「管理者」の順に選択して管理者ページにアクセスします。

通常、インシデント管理に含まれる管理者には2つのタイプがあります。

- ビジネス・ルール・アーキテクト/アナリスト: 業務の動きを深く理解し、その知識を操作上のルールに変換する管理者。これらのルールがデプロイされると、ビジネス・アーキテクトは動的組織の知識を使用して、それらのルールを最新に維持します。
エンタープライズ・ルール・セットを作成または編集するには、ビジネス・アーキテクト/アナリストに「エンタープライズ・ルール・セット」リソースに対する「エンタープライズ・ルール・セットの作成」権限が付与されている必要があります。アーキテクト/アナリストは、特定のルール・セットの管理に責任を持つ別の管理者(「エンタープライズ・ルール・セットの作成」権限がある場合もない場合もあります)とルール・セットの所有権を共有できます。

- ITオペレータ/マネージャ: ITマネージャはインシデント割当ての毎日の管理に責任を負います。ITオペレータはインシデントに割り当てられ、その解決に責任を負います。

エンタープライズ・ルール・セットに必要な権限

ルール・セットの所有者として、管理者は次を実行できます。

- ルール・セットを更新または削除し、ルール・セット内のルールを追加、変更または削除します。

- ルール・セットの共同作成者を割り当てます。共同作成者は作成者と同じようにルール・セットを編集できます。ただし、ルール・セットを削除したり、別の共同作成者を追加することはできません。

- ルール・アクションがイベント、インシデントまたは問題の更新(優先度の変更やイベントのクリアなど)である場合、アクションが成功するのは、各イベント、インシデントまたは問題に対してこのアクションを実行する権限が所有者にある場合のみです。

- また、エンタープライズ・ルール・セットを作成する権限がユーザーに付与されている必要があります。

インシデントまたは問題のルールに更新アクション(優先度の変更など)がある場合、アクションが行われるのは、対応するインシデントまたは問題に対する管理権限が各ルール・セットの所有者にある場合のみです。

権限を付与するには、Enterprise Managerホームページ上の「設定」メニューから、「セキュリティ」、「管理者」の順に選択して管理者ページにアクセスします。リストから管理者を選択し、「編集」をクリックして、次の図に示すように管理者のプロパティ・ウィザードにアクセスします。

ユーザーへのイベント、インシデントおよび問題に対する権限の付与

インシデントを処理するために、関連するすべてのEnterprise Manager管理者アカウントにはインシデントの管理に必要な適切な権限が付与されている必要があります。イベント、インシデントおよび問題に対する権限は、次のルールに従い決定されます。

- イベントに対する権限は、基礎となるソース・オブジェクトに対する権限に基づいて計算されます。たとえば、イベントのターゲットを表示できる場合、イベントに対する表示権限が割り当てられます。

- インシデントに対する権限は、インシデント内のイベントに対する権限に基づいて計算されます。

- 同様に、問題に対する権限は、基礎となるインシデントに対する権限に基づいて計算されます。

ユーザーには、次の状況下でイベント、インシデントおよび問題に対する権限が付与されます。

イベントの場合、2つの権限がシステムで定義されています。

- イベントの表示権限を使用すると、イベントを表示し、イベントにコメントを追加できます。

- イベントの管理権限を使用すると、イベントのクローズ、イベントのインシデントの作成、イベントのチケットの作成など、イベントに対する更新アクションを実行できます。イベントをインシデントに関連付けることもできます。

重要:
インシデントの権限は基礎となるイベントから継承されます。

イベントが1つのターゲットのみに発生した場合(大部分のイベント・タイプはメトリック・アラート、可用性イベントまたはサービス・レベル合意などの複数のターゲットに発生します)、次の権限が必要です。

- イベントを表示するためのターゲットの「表示」。

- イベントを管理するための「ターゲット・イベントの管理」。
注意: これはオペレータのサブ権限です。

イベントがターゲットとジョブの両方で発生した場合、次の権限が必要です。

- ターゲットの「表示」およびイベントを表示するジョブの「表示」。

- ターゲットの「表示」およびイベントを管理するジョブの「完全」。

イベントが1つのジョブでのみ発生した場合、次の権限が必要です。

- イベントを表示するには、ジョブの「表示」。

- イベントを管理するには、ジョブの「完全」。

イベントがメトリック拡張で発生した場合、イベントを表示するメトリック拡張に「表示」権限が必要です。メトリック拡張で発生したイベントが情報なので(インシデント・マネージャに表示されない)、イベント管理権限はこの状況では適用されません。

イベントが自己更新で発生した場合、システム権限のみが必要です。自己更新イベントは完全に情報です。

インシデントの場合、2つの権限がシステムで定義されています。

- イベントの表示権限を使用すると、インシデントを表示し、インシデントにコメントを追加できます。

- インシデントの管理権限を使用すると、インシデントに対する更新アクションを実行できます。インシデントに対してサポートされている更新アクションには、インシデントの割当ておよび優先度付け、解決管理、イベントの手動クローズおよびインシデントのチケットの作成が含まれます。

インシデントが1つのイベントで構成されている場合、イベントを表示できるならばインシデントを表示することができ、イベントを管理できるならばインシデントを管理できます。

インシデントが複数のイベントで構成されている場合、少なくとも1つのイベントを表示できるならばインシデントを表示することができ、少なくとも1つのイベントを管理できるならばインシデントを管理できます。

問題の場合、2つの権限が定義されています。

- 問題の表示権限を使用すると、問題を表示し、問題にコメントを追加できます。

- 問題の管理権限を使用すると、問題に対する更新アクションを実行できます。問題に対してサポートされている更新アクションには、問題の割当ておよび優先度付け、解決管理、問題の手動クローズが含まれます。

Enterprise Manager 12cでは、問題は常に1つのターゲットと関連します。それで、管理者がターゲットの表示権限を持っている場合は問題の表示権限、管理者がターゲットのmanage_target_events権限を持っている場合は問題の管理権限が、関連付けられたイベントの管理権限を暗黙的に付与します。これが次に、問題内のインシデントの管理権限を付与します。

2.2.3 モニタリング権限

Enterprise Manager環境で管理者が実行できる監視機能は、そのユーザーに付与されている権限に依存します。管理対象のインフラストラクチャの整合性およびセキュリティを保持するには、特定のロールの必須権限のみ付与する必要があります。ユーザー・ロールに基づいて適切な権限レベルを付与するには、次のガイドラインを使用できます。

監視を設定する管理者

権限でロールを作成し、管理者に付与します。

- 共有アカウントではなく、個別のユーザー・アカウントを使用することをお薦めします。

- スーパー管理者を使用する場合は、sysmanを使用しないでください。

- 権限がターゲットに基づく場合は、ターゲットを含む権限伝播グループを作成し(または、要件を満たす場合は管理グループを使用し)、そのグループへの権限をロールに付与します。

イベント/インシデントに応答する管理者

- ロールを作成し、管理者に付与します。

- 関連するターゲットを含む権限伝播グループを作成し(または、要件を満たす場合は管理グループを使用し)、そのグループへの適切な権限をロールに付与します。

例: ロールDB_Adminsを作成し、関連データベースを含む権限伝播グループDB-groupに対する「ターゲット・イベントの管理」を付与します。その後、ロールDB_AdminsをDBAに付与します。

監視操作および必要な権限

Enterprise Managerは、Enterprise Managerで実行される操作をより詳細に制御できる細分化された権限をサポートしています。

次の表に、これらをサポートするために必要なEnterprise Managerでの様々なジョブ職責および対応する権限をいくつか示します。

次の表に、特定の監視職責を実施するために必要な権限レベルの概要を示します。

表2-9 監視操作および必要な権限

監視操作

必要な権限

監視設定

SMTPゲートウェイの構成(email)

スーパー管理者

拡張通知メソッドの作成(SNMPトラップなど)

スーパー管理者

イベントまたはチケッティング・コネクタの構成

スーパー管理者

ロールの作成

スーパー管理者

管理グループ階層の作成

完全な任意のターゲット

権限伝播グループの作成

管理グループ階層の編集

完全な任意のターゲット

権限伝播グループの作成(管理グループ階層のレベル内でグループ基準としてターゲット・プロパティ値を追加する場合)

管理グループ階層の削除

完全な任意のターゲット

「グループ管理」ページでの管理グループ階層全体の表示

任意のターゲットの表示

注意: グループの一部に対する権限のみを持つ管理者は、「ターゲット」 -> 「グループ」でアクセスできる「グループ」リスト・ページにあるグループのみ表示できます。

監視テンプレートの使用

新しい監視テンプレートを作成するために必要な権限はありません。ただし、監視テンプレートに修正処理が含まれている場合は、ジョブ・システムでの作成権限が必要です。

別のユーザーが作成したテンプレートを使用するための、特定の監視テンプレートでの表示(たとえば、監視テンプレートをテンプレート・コレクションに追加する場合など)

テンプレート・コレクションの使用

テンプレート・コレクションの作成(新しいテンプレート・コレクションを作成するため)、別のユーザーが作成したテンプレート・コレクションに対する表示/関連付けを行うための特定のテンプレート・コレクションの表示、任意のテンプレート・コレクションに対する表示/関連付けを行うためのテンプレート・コレクションの表示、別のユーザーが作成したテンプレート・コレクションを編集/削除するための特定のテンプレート・コレクションでのフル・テンプレート・コレクション

管理グループへのテンプレート・コレクションの関連付け

グループでのテンプレート・コレクション操作の管理(「ターゲット・コンプライアンスの管理」および「ターゲット・メトリックの管理」権限を含む)

テンプレート・コレクションでのテンプレート・コレクションの表示

管理グループでの操作

グループに対する権限の管理(他のユーザーへの権限付与など)

グループに対するグループ管理

ターゲット・プロパティの設定による管理グループへのターゲットの追加

ターゲットの構成(管理グループに追加するターゲット上)

グループと関連付けられたテンプレート・コレクションの手動での同期化の実行

グループでのテンプレート・コレクション操作の管理

管理グループのメンバーに対する操作

Enterprise Managerからのターゲットの削除

ターゲットに対するフル権限(フルにも次の権限が含まれます)

計画停止のためのブラックアウトの設定

監視設定の変更

監視構成の変更

ターゲットでのイベントおよびインシデントの管理

ターゲットの表示、イベントまたはインシデントの通知の受信

ターゲットに対して実行する演算子にも次の権限が含まれます。

- ターゲットに対するターゲットのブラックアウト

- ターゲットでのターゲット・メトリックの管理

- ターゲットでのターゲットの構成

- ターゲットでのターゲット・イベントの管理

- ターゲットでの表示

インシデント・ルール・セットの作成

エンタープライズ・ルール・セットの作成

ターゲットでのターゲット・イベントの管理(ルールがターゲットのインシデントを作成している場合)

ロールへの管理グループに対する権限付与

管理グループの作成者の場合、追加の権限は必要ありません。

ターゲットのプロパティ値の設定

ターゲットの構成

テンプレート・コレクションの一部である監視テンプレートの編集

監視テンプレートに対するフル権限

管理グループでのターゲット・メトリックの管理

特定のターゲットでの監視設定の変更

ターゲット・メトリックの管理

イベント、インシデントの電子メールの受信

ターゲットでの表示

ソース・オブジェクトでの表示(ジョブ・イベントのジョブでの表示など)

イベントのインシデントの作成

ターゲット・イベントの管理

インシデント管理操作(確認、インシデントの割当て、優先順位付け、エスカレーション・レベルの設定など)

ターゲット・イベントの管理

注意:
SYSMANは、Enterprise Managerインフラストラクチャのインストールおよび保守を目的としたシステム・アカウントです。スーパー管理者としてのEnterprise Managerへの管理者アクセスには使用しないでください。

2.2.4 ルール・セットの設定

ルール・セットは受信イベント、インシデントおよび問題、またはそれらの更新に応答して、アクションを自動化します。この項では、最も一般的なタスクと例について説明します。

- ルール・セットの作成

- ロールの作成によるインシデントの作成

- インシデントのエスカレーションを管理するルールの作成

- 問題をエスカレートするルールの作成

- ルール・セットのテスト

- ルールからの電子メールを受信するためのサブスクライブ

- プライベート・ルールに対する電子メールの受信

2.2.4.1 ルール・セットの作成

通常、ルール・セットを作成するには、次の手順を実行します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、既存のルール・セットを編集するか、または新しいルール・セットを作成します。新しいルール・セットの場合、ルールを適用するターゲットを最初に選択する必要があります。ルールはルール・セットのコンテキストで作成されます。

注意:
既存のルール・セットがない場合は、「ルール・セットの作成...」をクリックしてルール・セットを作成します。次に、ルール・セットの作成の一環としてルールを作成します。

ターゲット・ライフサイクル・ステータスに基づくルール・セットの範囲の絞り込み

新しいルール・セットの作成時に、ターゲットの「ライフサイクル・ステータス」値に基づいて、絞り込まれたターゲットのセットに、ルール・セットを適用することを選択できます。たとえば、「ライフサイクル・ステータス」が「ステージング」および「本番」のターゲットにのみ適用するだけの1つのルール・セットを作成できます。次の図に示すように、「ライフサイクル・ステータス」フィルタを設定することで、ルール・セットの範囲を決定します。

このフィルタを使用することで、その「ライフサイクル・ステータス」に基づくターゲット用のルールを作成できます。そのようなターゲットのみを含むグループを先に作成する必要はありません。

3. ルール・セットの編集ページの「ルール」タブで、「作成...」をクリックし、「作成するルールのタイプを選択」ポップアップ・ダイアログで作成するルールのタイプ(「イベント」、「インシデント」、「問題」)を選択します。「続行」をクリックします。

4. 新規ルールの作成ウィザードで、必要な情報を指定します。

5. ルールの定義が終了したら、「続行」をクリックし、ルールをルール・セットに追加します。「保存」をクリックし、ルール・セットに対して行った変更を保存します。

2.2.4.2 ロールの作成によるインシデントの作成

インシデントを作成するルールを作成するには、次の手順を実行します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. イベントを管理するルールが含まれる既存のルール・セットがあるかどうかを確認します。インシデント・ルール・ページで「検索」オプションを使用して、ルール/ルール・セットの名前、説明、ターゲット名またはターゲットのターゲット・タイプおよび関連ルール・セットを検索します。ターゲット名またはこのターゲットが属するグループ・ターゲット名で検索し、ターゲットを管理するルール・セットを見つけることができます。
注意: 既存のルール・セットがない場合は、「ルール・セットの作成」をクリックしてルール・セットを作成します。次に、ルール・セットの作成の一環としてルールを作成します。

3. 新規ルールを含むルール・セットを選択します。ルール・セットの編集ページの「ルール」タブで、「編集...」をクリックします。

1. 「作成...」をクリックします。

2. 「受信イベントおよびイベントの更新」を選択します。

3. 「続行」をクリックします。

新規ルールの作成ウィザードを使用してルール詳細を指定します。

1. ルールの適用先である「イベント・タイプ」(「メトリック・アラート」など)を選択します。(「メトリック・アラート」は、タイプ「ターゲット」のルール・セットに対して使用可能です)。注意: 1つのルールでは1つのイベント・タイプしか選択できません。一度選択すると、ルールの編集中は変更できません。
次に、「特定のメトリック」を選択することにより、メトリック・アラートを指定できます。メトリック・アラートを選択するための表が表示されます。「+」(追加)ボタンをクリックし、メトリック・セレクタを起動します。特定のメトリック・アラートの選択ページで、ターゲット・タイプ(「データベース・インスタンス」など)を選択します。関連するメトリックのリストが表示されます。興味のあるメトリックを選択します。「OK」をクリックします。

重大度および修正処理ステータスを選択することもできます。

2. 初期情報を指定した後、「次へ」をクリックします。「+」(追加)をクリックし、イベントのトリガー時に実行するアクションを追加します。アクションの1つとして「インシデントの作成」があります。
インシデントの作成の一環として、インシデントを特定のユーザーに割り当て、重要度を設定し、チケットを作成できます。すべての条件処理を追加した後、「続行」をクリックします。

3. アクションの追加ページのすべての情報を指定した後で、「次へ」をクリックしてルールの名前と説明を指定します。確認ページで、すべての情報が正しいことを確認します。修正するには「戻る」をクリックします。ルール・セットの編集(ルール・セットの作成)ページに戻るには「続行」をクリックします。

4. 「保存」をクリックし、ルール・セットおよびルールの変更がデータベースに保存されるようにします。

4. 前のステップで選択したメトリックでメトリック・アラート・イベントを生成し、ルールをテストします。

2.2.4.3 インシデントのエスカレーションを管理するルールの作成

インシデントのエスカレーションを管理するルールを作成する手順:

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデントを管理するルールが含まれる既存のルール・セットがあるかどうかを確認します。それをインシデントについての任意の既存ルール・セットに追加できます。
注意: 既存のルール・セットがない場合は、「ルール・セットの作成」をクリックしてルール・セットを作成します。次に、ルール・セットの作成の一環としてルールを作成します。

3. 新規ルールを含むルール・セットを選択します。ルール・セットの編集ページの「ルール」タブで、「編集」をクリックし、次の操作を行います。

1. 「作成...」をクリックします。

2. 「新たに作成されたインシデントおよびインシデントの更新」を選択します。

3. 「続行」をクリックします。

4. ここでは、デモ用として、エスカレーションは本番データベースに基づいています。
組織のポリシーに従って、エスカレーション・レベル1のインシデントになるとDBAマネージャに通知され、致命的なインシデントは48時間の間オープンされます。同様に、インシデントがレベル2にエスカレートし、重大度が致命的で、72時間の間オープンされている場合、DBAディレクタにページで通知されます。致命的インシデントが96時間後までオープンされたままだと、レベル3にエスカレートし、業務VPに通知されます。

新規ルールの作成ウィザードを使用してルール詳細を指定します。

1. ルールを設定して新しく作成したすべてのインシデントに適用する場合、またはインシデントが「致命的」重大度に更新されるときには、「特定のインシデント」オプションを選択し、条件に重大度が致命的」を追加します。

2. アクションの追加ページの「アクションの条件」リージョンで、「指定された条件に一致する場合のみアクションを実行」を選択します。
「インシデントは一定の時間オープンであり、特定の状態にあります(時間とオプションで式を選択)」を選択します。

時間に48時間を選択し、ステータスは「解決されていません」または「クローズ済」です。

3. 「通知」リージョンに、電子メールまたはページによって通知する管理者の名前を入力します。「続行」をクリックし、現在の条件とアクションのセットを保存します。

4. 手順bおよびcを繰り返して、DBAディレクタにページで通知します(こ「この状態での時間」は72時間、ステータスは「解決されていません」または「クローズ済」)。96時間以上オープンされている場合、エスカレーション・レベルを3に設定し、業務VPにページで通知します。

5. 追加されたアクション・セットを確認して、「次へ」をクリックします。「次へ」をクリックして「サマリー」画面に移動します。サマリー情報を確認し、「続行」をクリックしてルールを保存します。

5. 既存のエンタープライズ・ルールのシーケンスを確認し、新しく作成したルールをそのシーケンスに配置します。
ルール・セットの編集ページでdesired rule from the Rules表をクリックし、「アクション」メニューから「ルールの並替え」を選択して、ルール・セット内のルールの順序を変更してから、「保存」をクリックして、ルールの順序の変更を保存します。

シナリオの例

インシデントのエスカレーション・プロセスを簡略化するには、運用管理者が未解決のインシデントを、その期間に基づいてエスカレートするルールを次のように作成します。

- インシデントが30分間オープンの場合にはレベル1へ

- インシデントが1時間オープンの場合にはレベル2へ

- インシデントが90分間オープンの場合にはレベル3へ

組織のポリシーに従って、エスカレーション・レベル1になるとDBAマネージャに通知されます。同じように、DBAディレクタとオペレーションVPは、インシデントがそれぞれレベル2、レベル3にエスカレートすると呼び出されます。

そこで、運用管理者は前述のロジックと、通知要件を達成する個々のルールのEnterprise Manager管理者IDを入力します。Enterprise Manager管理者IDは、必要なターゲット権限と通知プリファレンス(つまり、電子メール・アドレスとスケジュール)を持つ各ユーザーを表します。

2.2.4.4 問題をエスカレートするルールの作成

1つの問題に付随して20を超えるインシデントが発生するような組織では、未解決の問題は、問題が発生したターゲットのターゲット・タイプに基づいて、適切な管理者に自動的に割り当てることが必要になります。

そこで、問題に伴うインシデントの件数を監視し、特定のターゲット・タイプを処理するのに適した管理者に通知する問題ルールを作成します。

問題の所有者とオペレーション・マネージャには、電子メールで通知されます。

問題をエスカレートするルールを作成する手順:

1. インシデント・ルール・ページにナビゲートします。
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、新規のルール・セットを作成(「ルール・セットの作成...」をクリック)するか既存のルール・セットを編集(ルール・セットをハイライトして「編集...」をクリック)します。ルールはルール・セットのコンテキストで作成されます。
注意: 既存のルール・セットがない場合は、「ルール・セットの作成」をクリックしてルール・セットを作成します。次に、ルール・セットの作成の一環としてルールを作成します。

3. ルール・セットの編集ページの「ルール」セクションで、「作成...」をクリックします。

4. 「作成するルールのタイプを選択」ダイアログで、「新たに作成された問題および問題の更新」を選択し、「続行」をクリックします。

5. 新規ルールの作成ページで、「特定の問題」を選択し、次の基準を追加します。
「属性名」は「インシデント数」、「演算子」は「次以上」、および「値」は「20」です。

「次」をクリックします。

6. アクションの追加ページのアクションの条件リージョンで、「常にアクションを実行」を選択します。ルールが条件を満たすときに実行するアクションは、次のとおりです。

- 「通知」リージョンで、問題の所有者およびオペレーション・マネージャに電子メールを送信します。

- 「問題の更新」リージョンの「割当て先」フィールドに、適切な管理者の電子メール・アドレスを入力します。

「続行」をクリックします。

7. ルール・サマリーを検討します。必要に応じて修正します。「続行」をクリックしてルール・セットの編集ページに戻り、「保存」をクリックして、ルール・セットを保存します。

2.2.4.5 ルール・セットのテスト

ルール・セットを開発する際、考えられるすべてのイベント条件に一致するルールを作成することが困難になる可能性があります。以前は、ルールをテストする唯一の方法は、監視対象の環境でイベントをトリガーし、イベントに一致するルールとルールが実行する操作を確認することでした。Enterprise Managerリリース12.1.0.4以上では、既存のイベントをシミュレートできるため、ルール・セットの開発フェーズでルール操作をテストでき、特定のイベント条件が発生するまで待機することはありません。ルールのシミュレーション機能によって、特定のイベントがルールでどのように実行されるかを確認できます。特定のイベントに一致するルールをすぐに確認し、どのような操作を実行するかを確認します。

注意:
ルールのシミュレート機能は、イベント・ルールでのみ使用できます。この機能でインシデント・ルールをテストすることはできません。

ルールをシミュレートするには:

この手順では、ルール・セットが作成済であることが前提になります。ルール・セットの作成の詳細は、「ルール・セットの作成」を参照してください。ルール・タイプが「受信イベントおよびイベントの更新」であることを確認します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。「インシデント・ルール - すべてのエンタープライズ・ルール」ページが表示されます。

2. 「ルールのシミュレート」をクリックします。「ルールのシミュレート」ダイアログが表示されます。

3. 一致するイベントを検索するために必要な検索パラメータを入力し、「検索」をクリックします。

4. 結果のリストからイベントを選択します。

5. 「シミュレーションの開始」をクリックします。イベントが新しく発生したかのように、ルールによってイベントが渡されます。ルールは、現在の通知構成に基づいてシミュレートされます(電子メール・アドレス、割り当てられた管理者のスケジュール、繰返し通知設定など)。
ターゲット名の変更: 特定の状況下では、ルール・ターゲットではないターゲットで、ルール基準に一致するイベントが発生する可能性があります。イベントは、テストを目的としているだけです。シミュレーション用に別のターゲットを使用するには、「ターゲット名の変更およびシミュレーションの開始」をクリックします。

結果が表示されます。

本番ターゲットに対するイベント・ルールのテスト: テスト・ターゲットに対してイベントを生成することもできますが、最終確認のために本番ターゲットで動作を確認したい場合もあるでしょう。本番ターゲットに対するイベント・ルールのテストを、ルール・アクション(電子メールの送信、SNMPトラップ、トラブル・チケットのオープン)を実行することなく安全に行うことができます。本番ターゲットに対しイベント・ルールをテストするには、「ターゲット名」を本番ターゲットに変更します。シミュレーションの実行中、Enterprise Managerによって実行されるアクションのリストが表示されます。ただし、実際にはこれらのアクションが本番ターゲットで実行されることはありません。

6. ルール操作が意図しないものの場合は、ルールを編集し、目的の操作が実行されるまで、ルールのシミュレーション・プロセスを繰り返します。予想または期待したとおりのシミュレーション結果を得るために、次のガイドラインを参考にしてください。
電子メールに関するルール・アクションが実行されない場合の対処は次のとおりです。

- 当該イベントを対象にして電子メールを送信するアクションを実行するルールが存在することを確認します。

- Enterprise Managerの管理者が電子メールの受信者として指定されている場合、管理者に電子メール・アドレスが与えられ、通知スケジュールが設定されていることを確認します。

- イベントのターゲットに対して、電子メールの受信者が少なくとも表示権限を持っていることを確認します。

- SMTPのゲートウェイ設定を確認し、さらに管理者で「電子メールのテスト」が実行済であることを確認します。

インシデントの作成やチケットのオープンのようなその他のルール・アクションが実行されない場合の対処は次のとおりです。

- 当該イベントを対象にして対応するアクション(インシデントの作成など)を実行するルールが存在することを確認します。

- ルール・セットがターゲットを対象にしていることを確認します。

- イベントのターゲットに対して、ルール・セット所有者が少なくともターゲットのイベント管理権限を持っていることを確認します。

- チケットのオープン、SNMPトラップの送信またはイベント・コネクタの呼出しのような通知に関して、これらがイベント・ルールのアクションとして指定されていることを確認します。

2.2.4.6 ルールからの電子メールを受信するためのサブスクライブ

DBAは、48時間以内に解決しないと自分の所有するインシデントがエスカレートすることを知っています。ルールによってインシデントがエスカレートされたとき、このDBAに通知する必要があります。インシデントをエスカレートするルールにサブスクライブすると、このDBAはルールによってインシデントがエスカレートされたとき常に通知を受けるようになります。

通知サブスクリプションを設定する前に、48時間以内に解決されなかったデータベースの高優先度インシデントをエスカレートするルールが存在していることを確認します。

次の手順を実行してください。

1. 「設定」メニューから、「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、該当するインシデントのエスカレーション・ルールを含むルール・セットをクリックし、「編集」をクリックします。ルールはルール・セットのコンテキストで作成されます。
注意: 既存のルール・セットがない場合は、「ルール・セットの作成」をクリックしてルール・セットを作成します。次に、ルール・セットの作成の一環としてルールを作成します。

3. ルール・セットの編集ページの「ルール」セクションで、変更するエスカレーション・ルールをハイライトして「編集」をクリックします。

4. アクションの追加ページに移動します。

5. インシデントをエスカレートするアクションを選択し、「編集」をクリックします。

6. 「通知」セクションで、「電子メールCc」リストにDBAを追加します。

7. 「続行」をクリックしてルール・セットの編集ページに戻り、「保存」をクリックします。

エンタープライズ・ルールを編集した結果、インシデントが48時間未解決のままになると、ルールによってエスカレーション・レベルが1とマークされます。インシデントのエスカレーションを通知する電子メールが、DBAに送信されます。

代替ルール・セット・サブスクリプション方法: インシデント・ルール: すべてのエンタープライズ・ルール・ページで、インシデント・ルール表のルールを選択します。「アクション」メニューで、「電子メール」、「自分をサブスクライブ」(または「管理者をサブスクライブ....」)の順に選択します。

2.2.4.7 プライベート・ルールに対する電子メールの受信

あるDBAが、管理しているデータベースに対してバックアップ・ジョブを設定しました。このジョブの一部として、DBAは「完了」のジョブ・ステータスに関する電子メール通知にサブスクライブしました。ルールを作成する前に、DBAがジョブの作成に必要な権限を持っていることを確認します。ジョブ権限の要件については、第10章「ジョブ・システムと修正処理の使用」を参照してください。

次の手順を実行してください。

1. ルール・ページに移動します。
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、既存のルール・セットを編集(ルール・セットをハイライトして「編集」をクリック)するか、新規ルール・セットを作成します。
注意: このルール・セットはプライベート・ルール・セットとして定義されている必要があります。

3. ルール・セットの編集ページの「ルール」タブで、「作成...」、「受信イベントおよびイベントの更新」の順に選択します。「続行」をクリックします。

4. イベントの選択ページで、「ジョブ・ステータスの変更」として「イベント・タイプ」を選択します。特定のジョブを選択するか、パターン(「バックアップ管理」など)を指定することにより、興味のあるジョブを選択します。
属性を追加することにより、別の基準を追加します(「ターゲット・タイプ」として「データベース・インスタンス」)。

5. 条件アクションを追加します。たとえば、イベントが満たす基準として「重大度」は「情報」、通知は「電子メールを送信」にします。

6. ルール・サマリーを検討します。必要に応じて修正します。「保存」をクリックします。

7. データベース・バックアップ・ジョブを作成し、ジョブが完了したときの電子メール通知にサブスクライブします。

ジョブが完了すると、そのジョブのジョブ完了状態を示す情報イベントが発行されます。新しく作成したルールは、受信ジョブ・イベントに一致しているとみなされ、電子メールがDBAに送信されます。

電子メールを受信したDBAはリンクをクリックし、Enterprise Managerコンソールでイベントの詳細セクションにアクセスできます。

2.3 インシデントの処理

データ・センターは、ビジネスの優先度に応じて協力しながらイベントおよびインシデントを管理できる作業手法に従います。Enterprise Managerには、この管理および自動化を実現するために次の機能が用意されています。

- 適切な管理者に対する通知の送信。

- インシデントおよびルールの作成。

- インシデントの初期所有権の割当て、および場合によってはシフト割当てまたは専門知識に基づいた所有権の委譲

- 解決ステータスの追跡

- 影響を受けるコンポーネントおよびインシデントの性質に基づいた優先度の割当て

- インシデントのエスカレート。

- My Oracle Supportのナレッジ記事へのアクセス

- Oracleソフトウェアの問題に関するサポートをリクエストするためのOracle Service Requestのオープン。

次の操作を実行することで、インシデントの解決情報を更新できます。

1. 「すべてのオープン・インシデント」ビューで、インシデントを選択します。

2. 詳細ページが表示されたら「一般」タブをクリックし、「管理」をクリックします。「管理」ダイアログが表示されます。

これで、優先順位を調整し、インシデントをエスカレートし、特定のITオペレータに割り当てることが可能になります。

インシデントの処理には次のステージが含まれます。

1. 処理が必要な事項の発見

2. インシデントの検索

3. カスタム・ビューの設定

4. 単純なインシデントへの応答および処理

5. 複数のインシデント、イベントおよび問題への一括応答

6. インシデントのワークロード分散の管理

7. インシデントの手動作成

2.3.1 処理が必要な事項の発見

Enterprise Managerには、処理が必要な事項を発見できるアクセス・ポイントが複数用意されています。インシデント管理の主な焦点は、インシデント・マネージャ・コンソールですが、Enterprise Managerにも、別の通知方法が用意されています。対応が必要な問題があることを通知する最も一般的な方法は電子メールです。しかし、インシデント情報は次の場所にもあります。

カスタム・ビュー(「カスタム・ビューの設定」を参照)

グループまたはシステム・ホームページ(第5章「グループの管理」参照)

ターゲット・ホームページ

インシデント・マネージャ(システムまたはターゲットのコンテキスト)

Enterprise Managerコンソール

2.3.2 インシデントの検索

インシデントの最終更新時間、ターゲット名、ターゲット・タイプまたはインシデント・ステータスなどの様々なインシデント属性に基づき、インシデントを検索できます。

1. インシデント・マネージャ・ページにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 左側の「表示」リージョンで、「検索」をクリックします。

1. 「検索」リージョンで、「タイプ」列を使用してインシデントを検索し、「インシデント」を選択します。

2. 「基準」リージョンで、適切な基準をすべて選択します。基準にフィールドを追加するには、「フィールドの追加」をクリックして適切なフィールドを選択します。

3. 適切な基準を指定した後、「結果取得」をクリックします。
インシデントのリストが求めているものと一致することを確認します。一致しない場合は、必要に応じて検索基準を変更します。

4. この表に関連付けられているすべての列を表示する場合には、「表示」メニューで「列」、「すべて表示」の順に選択します。

ターゲットのライフサイクル・ステータスによるインシデントの検索

高レベルのインシデント属性を使用した検索に加えて、個別のライフサイクル・ステータスに基づくさらに詳細な検索を実行することもできます。簡単に言うと、ライフサイクル・ステータスは、ターゲットの運用ステータスを示すターゲット・プロパティです。検索できるステータス・オプションは次のとおりです。

- すべて

- 基幹

- 本番

- ステージング

- テスト

- 開発

ライフサイクル・ステータスの詳細は、第2.4.10項「イベントの優先度付け」を参照してください。

ターゲットのライフサイクル・ステータスによりインシデントを検索するには、次の手順に従います。

1. インシデント・マネージャ・ページにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 左側の「表示」リージョンで、「検索」をクリックします。

3. 「検索」リージョンで「フィールドの追加」をクリックします。ポップアップ・メニューが表示されて、使用可能なライフサイクル・ステータスを示します。

4. 1つ以上のライフサイクル・ステータス・オプションを選択します。

5. 追加の検索基準を入力します。

6. 「結果取得」をクリックします。

2.3.3 カスタム・ビューの設定

インシデント・マネージャでも、焦点を当てる必要のあるインシデントや問題にすばやくアクセスできるカスタム・ビューを定義できます。たとえば、所有するすべてのクリティカル・データベース・インシデントを表示するビューを定義できます。関心のあるインシデント属性のみを表示するビュー・プリファレンスを指定および保存することで、Enterprise Managerで一致するインシデントのリストのみを表示します。

優先度1など、特定の属性を持つインシデントのみを検索できます。このビューにより、毎日の優先順位決定のために適切なインシデントに容易にアクセスできます。検索基準を「All priority 1 incidents for my targets」という名前のフィルタとして保存できます。このビューはすぐにUIで使用可能となり、ログインして特定のインシデントにアクセスするときに、いつでも使用できます。最後に使用したビューは、次にログインするときに使用されるデフォルトのビューになります。

次の手順を実行してください。

1. インシデント・マネージャ・ページにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 左側にある「マイ・ビュー」リージョンで、作成アイコン(+)をクリックします。

1. 「検索」リージョンで、「タイプ」列を使用してインシデントを検索し、「インシデント」を選択します。

2. 「基準」リージョンで、適切な基準をすべて選択します。基準にフィールドを追加するには、「フィールドの追加」をクリックして適切なフィールドを選択します。

3. 適切な基準を指定した後、「結果取得」をクリックします。
インシデントのリストが求めているものと一致することを確認します。一致しない場合は、必要に応じて検索基準を変更します。

4. この表に関連付けられているすべての列を表示する場合には、「表示」メニューで「列」、「すべて表示」の順に選択します。
表示する列のサブセットを選択と、それらを表示する順番を選択するには、「ビュー」メニューで、「列」、「列の管理」の順に選択します。表に追加できる列のリストを示すダイアログが表示されます。

5. 「ビューの作成」ボタンをクリックします。

6. ビュー名を入力します。このビューを他の管理者が使用する場合は、「共有」オプションをチェックします。

7. 「OK」をクリックして、ビューを保存します。

注意:
ビューの作成ダイアログでも、ビューを共有としてマークすることができます。詳細は、第2.3.4項「カスタム・ビューの共有/共有解除」を参照してください。

2.3.3.1 インシデント・ダッシュボード

インシデント・ダッシュボードにより、インシデントの分散方法を感覚的につかむなどのインシデント管理の様々な側面を追跡してモニターできます。特に、インシデント・ダッシュボードは、カスタム・ビューを使用してインシデント・セットの範囲を制限する別の方法(ビューごとに1つのダッシュボード)を示します。インシデントおよびインシデント分散パターンを解釈する直感的な方法を提供する他に、ダッシュボードはインシデント・ライフサイクル・アクション(承認、割当、コメントの追加など)に対する迅速で容易なアクセスを提供します。

次の図に、インシデント・ダッシュボードを示します。

図2-8 インシデント・ダッシュボード

インシデント・ダッシュボードの領域

インシデント・ダッシュボードの各部は3つのセクションに分かれています。

注意:
デフォルトでは、データは自動的に30秒ごとにリフレッシュされます。必要に応じて、リフレッシュ間隔を長くしたり短くしたりすることができます。

- 「サマリー」領域は次の数値を表示します。

- 「オープン」インシデント(過去1時間に作成されたインシデントを含む)。

- 「致命的」インシデント(過去1時間に作成されたか「致命的」に更新されたインシデントを含む)。

- 「エスカレート済」インシデント(過去1時間にエスカレーションされたインシデントを含む)。

- 「未割当て」インシデント。

- 「未確認」インシデント。

赤くハイライト表示されたインシデント・ダッシュボード要素は即時対応が必要です。サマリー番号をクリックすると、そのインシデント領域に関連するインシデントのみを表示できます。グラフおよびインシデント・リストに表示されたデータは必要に応じて変更されます。

- 「グラフ」は、現行のインシデント分散のわかりやすい表示および各インシデントの管理ステータスを提供します。グラフの一部をクリックすることで、インシデント・ダッシュボードに表示されているデータをそれらのインシデントのみにフィルタリングできます。

- 「インシデント・リスト」は、最終更新タイムスタンプで時系列の降順にオープンなインシデントを表示します。このリストから、インシデントに対するエスカレーション、優先度付け、承認、所有者の割当、コメントの追加などの必要なインシデント・ライフサイクル・アクションを実行できます。

インシデント・ダッシュボードの作成

オープンなインシデントのインシデント・ダッシュボードを作成するには、「インシデント・マネージャ」に移動し、インシデント表の上にあるページの左上部にある「ダッシュボード」ボタンをクリックします。

オープンなインシデント・ダッシュボードは便利ですが、さらに一般的なシナリオには、インシデント・ダッシュボードに関心のあるインシデントのデータのみを表示するカスタム・ビューの作成が含まれます。カスタム・ビューの作成の詳細は、「カスタム・ビューの設定」を参照してください。特定のビューのインシデント・ダッシュボードを表示するには、目的のビューをインシデント・マネージャUIの「マイ・ビュー」リストから選択し、「ダッシュボード」をクリックします。

インシデント・ダッシュボードのカスタマイズ

デフォルトのダッシュボードが要件に合わない場合、様々な方法でダッシュボードを変更できます。たとえば、デフォルトのグラフの削除、事前定義済グラフの追加、または既存グラフの変更(グラフのディメンションの変更や円グラフから棒グラフへの変更など)です。

インシデント・ダッシュボードをカスタマイズするには、「サマリー」セクションの上にある「カスタマイズ」をクリックします。変更後、「保存」をクリックして変更内容を保存します。

注意:
ビューの所有者およびスーパー管理者のみが、ビューのカスタマイズを作成または編集できます。ビューの所有権がない場合、ユーザーは自動リフレッシュの頻度とグラフ・タイプのみを変更できます。ただし、これらの変更は恒久的ではありません。

2.3.4 カスタム・ビューの共有/共有解除

独自のビューを作成すると、それらはプライベートになります(表示のみ可能)。Enterprise Managerリリース12.1.0.4以上では、他の管理者とプライベート・ビューを共有できます。ビューを共有すると、すべてのEnterprise Managerユーザーがそのビューを使用できるようになります。

前述のとおり、ビュー作成プロセスでビューを共有する機会があります。カスタム・ビューを作成済の場合は、いつでも共有が可能です。

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 「マイ・ビュー」リージョンから、「管理」アイコンをクリックします。

3. 「カスタム・ビューの管理」ダイアログから、カスタム・ビューを選択します。

4. 「共有」 (ビューがすでに共有されており、共有を解除する場合は「共有解除」)をクリックします。

5. 「はい」をクリックして、共有/共有解除操作を確定します。

2.3.5 単純なインシデントへの応答および処理

次に、考えられる1つのインシデント管理シナリオを順を追って説明します。

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. ビューを使用したインシデントのリストのフィルタリング。たとえば、「オープンなインシデントと問題」ビューを使用して、自分に割り当てられているインシデントおよび問題を確認します。次に、優先度に従ってリストをソートできます。

3. インシデントを選択して、インシデントを処理します。「一般」タブで「確認」をクリックし、自分がこのインシデントで作業中であることを示し、このインシデントの通知を繰り返し受信することを停止します。
インシデントの確認に加えて、次のようなその他のインシデント管理操作を実行できます。

- コメントの追加。

- インシデントの管理。インシデント管理オプションの詳細は、第2.3.6項「複数のインシデント、イベントおよび問題への一括応答」を参照してください。

- サマリーの編集。

- チケットの手動作成。

- インシデントの抑制/抑制解除。

- インシデントのクリア。

個々のインシデントを処理している間にも、新しいインシデントが発生する可能性があります。「リフレッシュ」アイコンをクリックしてインシデントのリストを更新してください。

4. インシデントに対する解決策がわからない場合には、インシデントのページで使用できる次の方法をいずれか、またはすべて使用してください。

- 「ガイドされた解決」リージョンを使用して、使用可能な任意の推奨、診断および解決リンクにアクセスします。

- My Oracle Supportのナレッジ・ベースで、インシデントに対する既知の解決策を確認します。

- 関連するイベントおよびインシデント・タブで、関連するインシデントを調べます。

5. 解決策が判明し、すぐに解決できる場合には、システムに付属しているツールを使用してインシデントを解決します。

6. 多くの場合、基礎となる原因が修正されると、インシデントは次の標準サイクルで解消されます。ただし、ログ・ベースのインシデントの場合はインシデントをクリアしてください。

または、ターゲットのホームページから特定のターゲットのインシデントを処理できます。「ターゲット」メニューから、「監視」、「インシデント・マネージャ」の順に選択し、そのターゲット(またはグループ)のインシデントにアクセスします。

2.3.6 複数のインシデント、イベントおよび問題への一括応答

複数のインシデントに同じ方法で応答する必要がある場合があります。たとえば、いくつかの本番データベースで表領域が不足している問題により、自分に割り当てられたインシデントのクラスタがあるとします。上司はその表領域を別の管理者が調達した記憶域システムに転送することを提案しています。この状況で、表領域のすべてのインシデントをカスタマイズされた解決状態の"Waiting for Hardware"に設定します。また、インシデントを別の管理者に割り当て、シナリオを説明するコメントを追加します。この状況で、これらのすべてのインシデントを個別にではなく一括で更新します。

インシデントに一括で応答するには、次の手順に従います。

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. ビューを使用して、インシデントのリストを処理するインシデントのサブセットへとフィルタします。たとえば、「オープンなインシデントと問題」ビューを使用して、自分に割り当てられているインシデントおよび問題を確認できます。次に、優先度に従ってリストをソートできます。

3. 応答するインシデントを選択します。[Ctrl]キーを押しながら個別のインシデントを選択することで、複数の項目を選択できます。または[Shift]キーを押しながら最初と最後のインシデントを選択することで、インシデントの連続したブロックを選択できます。

4. 「アクション」メニューで目的の応答アクションを選択します。

- 確認: インシデントを表示したことを示します。このオプションはまた、インシデントについての通知が繰り返し送信されることを停止します。これにより「確認」フラグが「はい」に設定され、自分がインシデントの所有者になります。

- 管理: インシデントに対し複数処理の応答を実行できます。

- 確認: インシデントが確認された場合、そのインシデントは暗黙的にそれを確認したユーザーに割り当てられます。ユーザーがインシデントを自分自身に割り当てた場合、そのインシデントは確認済とみなされます。一度確認済となったインシデントを未確認にはできません。確認することにより、そのインシデントについての通知が繰り返されることも停止します。

- 割当て先: インシデントをインシデントの所有権を持つ管理者に割り当てます。

- 優先度付け: インシデントの優先度レベルは、「なし」、「緊急」、「非常に高」、「高」、「中」、「低」の、そのまま使用できる優先度の値のいずれかを選択することで設定できます。

- インシデント・ステータス: インシデントの解決状態を、「調査中」、「解決」またはカスタム定義のステータスのいずれかを選択することで設定できます。

- エスカレーション・レベル: 管理者はエスカレーション・レベルを、デフォルト値の「なし」に加えてレベル1から5まで設定して、インシデントを更新できます。エスカレートされた問題は、エスカレーションを「なし」に設定することで、エスカレートを解除できます。適切なエスカレーション・レベルは作成したITプロシージャにより異なります。

- コメント: インシデントの所有者に伝える内容などのコメントを入力できます。

- 抑止: インシデントを抑止することで、対応する通知を停止し、即時使用可能なビューおよびデフォルトの合計(サマリー・リージョンに表示されるものなど)から削除します。抑止は、通常、インシデントに対するアクションを将来の時点まで遅らせて、その間、コンソールに表示しないようする場合に実行されます。管理者は抑止されたインシデントを、検索条件に「抑止」検索フィールドを含む、インシデントの検索の実行など、明示的にそれらを検索することにより表示できます。
インシデントは、次の条件のいずれかが満たされるまで抑止できます。

- 抑止が手動で削除されるまで

- 将来の指定した日付まで

- 重大度の状態が変更されるまで(インシデントのみ)

- クローズされるまで

- クリア: 管理者はインシデントまたは問題を手動でクリアできます。インシデントの場合、これは手動でクリアできるインシデントを含むインシデントにのみ適用されます。

- コメントの追加: ユーザーはインシデントおよびイベントにコメントを追加できます。コメントは他のユーザーと情報を共有するのに使用したり、実行しているアクションの追跡情報を提供するのに使用できます。コメントはクローズした問題にも追加できます。

注意:
シングル・アクションの「確認」および「クリア」ボタンは、インシデントのオープンや、複数のインシデントの選択に使用できます。

前述のアクションのいずれかが、選択したインシデントのサブセットにのみ適用される場合(たとえば、管理者が複数のインシデントを確認しようとし、そのうちの一部がすでに確認済の場合)、アクションは適用可能な場合にのみ実行されます。管理者にはアクションの成功または失敗が通知されます。管理者がこれらのアクションのいずれかを選択する場合、対応する注釈が今後の参照用に追加されます。

5. 「OK」をクリックします。プロセスのサマリーと確認のダイアログが表示されます。

6. 必要に応じて、インシデントの処理を続行します。

2.3.7 My Oracle Supportナレッジの検索

My Oracle Supportナレッジ・ページのエントリにインシデント・マネージャからアクセスするには、次の手順を実行します。

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 標準ビューの1つを選択します。「表示」表で適切なインシデントまたは問題を選択します。

3. 表示された「詳細」リージョンで、「My Oracle Supportのナレッジ」をクリックします。
My Oracle Support (MOS)ログイン資格証明がMOS優先資格証明として保存された場合、手動でログインする必要はありません。そうでない場合、My Oracle Supportにサインインする必要があります。MOSログイン情報を優先資格証明として保存するには、次を実行します。

MOS優先資格証明の設定: 「設定」メニューで、「セキュリティ」、「優先資格証明」の順に選択します。「My Oracle Support優先資格証明」リージョンで、「MOS資格証明の設定」をクリックします。

4. My Oracle Supportページで「ナレッジ」タブをクリックし、ナレッジ・ベースを参照します。
このページから公式なOracleドキュメントにアクセスできるだけでなく、検索文字列を変更してその他のナレッジ・ベースのエントリを探すこともできます。

2.3.8 サービス・リクエストのオープンの発行(問題のみ)

問題を解決するためにOracleサポートの支援が必要な場合があります。この手順はインシデントおよびイベントには関係ありません。

サービス・リクエスト(SR)を発行するには、次の手順を実行します。

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 問題を検索して発見するいずれかのビュー、またはカスタムのビューを使用します。表中の適切な問題を選択します。

3. 「サポート・ワークベンチ\: パッケージ診断」リンクをクリックします。

4. SRをオープンするワークフローを完了します。ワークフローの完了により、SRのドラフトが作成されます。

5. まだサインインしていない場合、My Oracle Supportにサインインします。

6. My Oracle Supportページで、「サービス・リクエスト」タブをクリックします。

7. 「SRの作成」ボタンをクリックします。

2.3.9 インシデントと問題の抑止

インシデントまたは問題を、すべてのオープン・インシデント・ページまたはすべてのオープンな問題ページのリストで非表示にすると便利なことがあります。たとえば、インシデントの処理を将来に日付まで(たとえばメンテナンス・ウィンドウまで)遅らせる必要があるとします。UIに表示しないために、インシデントを一時的に非表示にするか、または将来の日付まで抑止します。抑止されたインシデントを見つけるためには、「すべて表示」または「抑止されたイベントのみ表示」検索オプションのいずれかを使用してインシデントを明示的に検索する必要があります。抑止されたインシデントまたは問題の非表示を解除するためには、手動で抑止を解除する必要があります。

インシデントと問題を抑止するには:

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. すべてのオープン・インシデント・ビューまたはすべてのオープンな問題ビューを選択します。
適切なインシデントまたは問題を選択します。「一般」タブをクリックします。

3. 「詳細」リージョンが表示されたら、「詳細」タブをクリックして「抑止」を選択します。

4. 「抑止」ポップアップが開いたら、適切な抑止タイプを選択します。
必要に応じてコメントを追加します。

5. 「OK」をクリックします。

インシデントや問題を抑止解除するには、次の手順を実行します。

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 「検索」をクリックします。

3. 「抑止」メニューから、「抑止されたイベントのみ表示」を選択します。

4. 「結果取得」をクリックします。
抑止されたインシデントが表示されます。適切なインシデントまたは問題を選択します。

5. 「一般」タブをクリックします。

6. 「詳細」リージョンが表示されたら、「詳細」をクリックして「抑制解除」を選択します。

2.3.10 インシデントのワークロード分散の管理

インシデント・マネージャを使用すると、自分のチームで対応するインシデントおよび問題を管理できます。

次のタスクを実行します。

1. インシデント・マネージャにナビゲートします。
Enterprise Managerホームページ上の「エンタープライズ」メニューから、「監視」を選択し、「インシデント・マネージャ」を選択します。

2. 標準ビューまたはカスタム・ビューを使用して、自分のチームが担当するインシデントを識別します。未割当てで未確認のインシデントおよび問題に注目する必要があります。

3. インシデントのリストを確認します。これには、インシデントに割り当てられた担当者の確認、ステータス、進捗状況およびインシデントの所有者によるアクションの確認が含まれます。

4. 「インシデントの詳細」リージョンの「管理」ボタンをクリックし、必要に応じてコメントを追加し、優先度を変更し、インシデントを再割当てします。

シナリオの例

DBAマネージャは、インシデント・マネージャを使用して、チームが所有しているすべてのインシデントを表示し、すべてが適切に割り当てられていることを確認します。適切に割り当てられていない場合は、再度割当てを行い、適切に優先度を付けます。また、エスカレーションされたイベントのステータスと進捗状況を監視し、インシデントの所有者用に必要に応じてコメントを追加します。コンソールで、各インシデントがオープン状態であった期間を表示できます。割り当てられていないインシデントのリストも確認し、適切に割り当てます。

2.3.11 定期的なイベントの確認

オラクル社では、重要なイベントまたは関連イベントのグループに注意を集中するため、インシデントによる管理をお薦めします。生成されるイベントの多様性およびその数の多さのため、重要なイベントのすべてをインシデントでカバーすることは現実的ではありません。重要でありながら対応していないイベントを検索できるように、Enterprise Managerには「インシデントのないイベント」という標準のビューが用意されています。

次の手順を実行してください。

1. 「エンタープライズ」メニューから、「監視」、「インシデント・マネージャ」の順に選択します。

2. 「ビュー」リージョンで、「インシデントのないイベント」をクリックします。

3. 表から、目的とするイベントを選択します。イベントの詳細が表示されます。

4. 詳細の領域で、「詳細」を選択し、「インシデントの作成」または「インシデントにイベントを追加」のいずれかを選択します。

シナリオの例

Enterprise Managerの初期フェーズで、DBAマネージャは毎日、自身が管理しているデータベースでイベントを確認し、フィルタを設定してチケットまたはインシデントで追跡されていないイベントのみを表示します。そのようなイベントを参照して、どれも問題を追跡するインシデントが必要ないことを確認します。いずれかのイベントで問題を追跡するインシデントが必要と判断した場合には、このイベントに対して直接インシデントを作成します。

2.3.11.1 インシデントの手動作成

関心のあるイベントが発生し、それがどのルールでもカバーされておらず、そのイベントをインシデントに変換する場合は、次の手順に従います。

1. 使用可能なビューを使用し、関心のあるイベントを検索します。

2. 表中のイベントを選択します。

3. 「詳細」ドロップダウン・メニューから「インシデントの作成」を選択します。

4. インシデントの詳細を入力し、「OK」をクリックします。

5. そのインシデントを自分で処理することに決めた場合は、自身をインシデントの所有者として設定し、ステータスを「調査中」に更新します。

シナリオの例

オペレーション・ポリシーに従って、あるDBAマネージャはこのデータベースのクリティカルな問題すべてに対してインシデントを作成するルールを設定しています。残りの問題には、DBAのいずれかがイベント・レベルで優先順位を付けます。

DBAの1人が、本番データベースに対する「SQLレスポンス」イベント(インシデントには関連付けられていない)に関する電子メールを受信します。DBAは、電子メールのリンクをクリックしてイベントの詳細にアクセスします。イベントの詳細を確認します。これは追跡と解決が必要な問題であるため、DBAはインシデントをオープンし、問題の解決策を追跡します。インシデントのステータスを、「調査中」に設定します。

2.4 高度なトピック

次の項では、高度なアプリケーションまたは操作領域に関連するインシデント/イベント管理機能について説明します。

2.4.1 自動診断リポジトリ(ADR): インシデントのフラッド制御

ADRは、トレース、ダンプ、アラート・ログ、状態モニター・レポートなどデータベース診断データを格納するファイルベース・リポジトリです。ADRの統一されたディレクトリ構造および統一されたツール・セットにより、ユーザーおよびOracleサポートは、複数のインスタンスおよびOracle製品間の診断データの相関関係を確認して分析できます。

Enterprise Managerと同様、ADRは、問題を解決するためのインシデントを作成し、問題を追跡します。

- 問題はデータベースにおけるクリティカル・エラーです。クリティカル・エラーには、内部エラー(ORA-00600など)やその他の深刻なエラー(ORA-07445(オペレーティング・システム例外)またはORA-04031(共有プールのメモリー不足))が含まれます。

- インシデントとは、問題の1回の発生です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントにはタイムスタンプが付与され、ADRで追跡されます。インシデントが発生すると、ADRでは診断インシデント・アラートをEnterprise Managerに送信します。

2.4.1.1 インシデント・マネージャを使用したADR診断インシデントの処理

ADRに記録された各診断インシデントは、Enterprise Managerでもインシデントとして記録されるため、インシデント・マネージャからADR/Enterprise Managerのインシデントおよび問題の統一されたビューが提供されます。ADR診断インシデントの場合は、Enterprise Managerのサポート・ワークベンチにアクセスして、問題のパッケージ化、Oracleサポートへのサービス・リクエストの発行など、さらに処理を行うことができます。

2.4.1.2 インシデントのフラッド制御

Enterprise Managerリリース12.1.0.4より前では、インシデント・マネージャで1つの問題に対して記録される診断インシデントの数に制限はありませんでした。問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。問題が発生して早い段階で生成されたインシデントは有効ですが、特定の時点を過ぎると、過剰な診断データはほとんど価値がなく、問題の診断と解決の処理速度が低下する可能性があります。通常、診断の問題は長時間かかることが多く、一定期間に大量のインシデントが生成される可能性があります。また、管理対象の環境のサイズによっては、診断データが膨大なシステム・リソースを消費する場合もあります。

これらの理由から、Enterprise Managerは、インシデント・マネージャで特定の問題に対して発生する可能性のある診断インシデントの数にフラッド制御制限を適用します。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。

Enterprise Managerリリース12.1.0.4以上では、インシデント・マネージャの特定の問題に対して発生する可能性のある診断インシデントの数に2つの制限が適用されます。1つの問題は、問題キーと呼ばれる一意の問題シグネチャによって識別され、1つのターゲットに関連付けられます。

Enterprise Managerによる診断インシデントの制限

Enterprise Managerは、診断インシデントに2つの制限を適用します。

- いずれかの1時間について、Enterprise Managerは、指定したターゲットと問題キーの組合せに対し、最大で5つ(デフォルト値)の診断インシデントを記録します。

- いずれかの1日について、Enterprise Managerは、指定したターゲットと問題キーの組合せに対し、最大で25(デフォルト値)の診断インシデントを記録します。

いずれかの制限に到達すると、同じターゲット/問題キーの組合せの診断インシデントは、対応する時間または日を超えるまで記録されなくなります。新しい時間または日が始まると、診断インシデントの記録が開始されます。

注意:
時間および日の計算はUTC (またはGMT)をベースに行われます。

これらの診断インシデントの制限は、インシデント・マネージャにのみ適用され、基礎となっているADRには適用されません。ADRリポジトリでは、引き続きすべてのインシデントが記録されます。Enterprise Managerのサポート・ワークベンチを使用すると、いつでも問題のインシデントをすべて表示でき、適切な処理を行うことができます。

Enterprise Managerの診断インシデント制限は構成可能です。前述のとおり、これらの2つの制限のデフォルトは1時間に5つ、1日に25のインシデントに設定されています。これらのデフォルトは、すべての診断インシデントを追跡するというビジネス上の特別な理由がないかぎり、変更しないでください。

Enterprise Managerの診断インシデント制限の変更

診断制限を更新するには、次の例に示すとおり、適切な制限値を使用し、SYSMANユーザーでEnterprise Managerリポジトリに対して次のSQLを実行します。

例2-3 診断インシデント制限を変更するためのSQL

exec  EM_EVENT_UTIL.SET_ADR_INC_LIMITS(5,25);

次の例に示すPL/SQLは、現在の制限を出力します。

例2-4 現在の診断インシデント制限を出力するSQL

DECLARE
l_adr_hour_limit NUMBER;
l_adr_day_limit NUMBER;
BEGIN
em_event_util. GET_ADR_INC_LIMITS
(p_hourly_limit => l_adr_hour_limit,
p_daily_limit => l_adr_day_limit);
dbms_output.put_line(l_adr_hour_limit || '-' || l_adr_day_limit);
END;

重要:
Enterprise Managerのインシデント制限は、Oracle Database、Middleware and Fusion Applicationsなどの基礎となるアプリケーションによって適用される診断インシデント制限に追加されるものです。これらの制限は、各アプリケーションに固有です。詳細は、それぞれのアプリケーションのドキュメントを参照してください。

2.4.2 カスタム・インシデント・ステータスの定義

「インシデントの処理」で説明したとおり、主なインシデント・ワークフロー属性の1つは「ステータス」です。ほとんどの条件に対し、この事前定義済のステータス属性は十分です。しかし、監視および管理環境の独自性により、インシデント・ワークフローに特別なインシデント・ステータスが必要な場合があります。この必要性に対処するために、create_resolution_state EM CLI動詞を使用して、カスタム・ステータスを定義できます。

2.4.2.1 新しい解決状態の作成

emcli create_resolution_state
-label="Label for display"
-position="Display position"
[-applies_to="INC|PBLM"]

この動詞は、新規解決状態を作成して、インシデントまたは問題の状態を記述します。

重要:
このコマンドを実行できるのは、Enterprise Managerのスーパー管理者のみです。

新しい状態は常に、「新規」と「クローズ済」の状態の間に追加されます。-positionオプションを使用して、状態のリスト全体におけるこの状態の正確な位置を指定する必要があります。指定できる位置は、2と98の間です。

デフォルトでは、新しい状態はインシデントと問題の両方に適用されます。-applies_toオプションを使用して、状態をインシデントと問題のいずれかのみに適用する指定が可能です。

コマンドが正常に実行されると、成功メッセージが報告されます。変更が失敗すると、エラー・メッセージが報告されます。

例

次の例では、位置25でインシデントと問題の両方に適用する解決状態を追加します。

emcli create_resolution_state -label="Waiting for Ticket" -position=25

次の例では、位置35で問題のみに適用する解決状態を追加します。

emcli create_resolution_state -label="Waiting for SR" -position=35 -applies_to=PBLM

2.4.2.2 既存の解決状態の変更

modify_resolution_state動詞を使用して、既存の状態の表示ラベルと位置の両方を変更できます。

emcli modify_resolution_state
-label="old label of the state to be changed"
-new_label="New label for display"
-position="New display position"
[-applies_to=BOTH]

この動詞はインシデントまたは問題の状態を定義する既存の解決ステータスを変更します。create_resolution_state動詞と同じく、このコマンドを実行できるのはスーパー管理者のみです。

-applies_toオプションを使用して、状態がインシデントと問題の両方に適用されるように指定することができます。

例

次の例では、古いラベルWaiting for TTを持つ解決状態を新しいラベルWaiting for Ticketで更新します。必要に応じて、位置を25に変更します。

emcli modify_resolution_state -label="Waiting for TT" -new_label="Waiting for Ticket" -position=25

次の例では、古いラベルSR Waitingを持つ解決状態を新しいラベルWaiting for SRで更新します。必要に応じて、位置を35に変更します。状態をインシデントと問題に適用します。

emcli modify_resolution_state -label="SR Waiting" -new_label="Waiting for SR" -position=35 -applies_to=BOTH

2.4.3 メトリック・アラート・イベント・タイプのステートレス・アラートのクリア

「メトリック・アラート」イベント・タイプの場合、イベント(メトリック・アラート)はメトリックしきい値に基づいて発生します。これらのメトリック・アラートはステートフル・アラートと呼ばれます。監視対象システムの状態に関連付けられていないメトリック・アラート・イベント(たとえば、「スナップショットが古すぎます」または再開可能セッションが一時停止されました)の場合、これらのアラートはステートレス・アラートと呼ばれます。ステートレス・アラートは自動的にクリアされないので、手動でクリアする必要があります。clear_stateless_alerts EM CLI動詞を使用して、ステートレス・アラートの一括パージを実行できます。

注意:
多数のインシデントに対し、手動でインシデントを一括クリアできます。「複数のインシデント、イベントおよび問題への一括応答」を参照してください。

clear_stateless_alertsは指定したターゲットに関連付けられたステートレス・アラートをクリアします。管理エージェントはステートレス・アラートを自動的にクリアしないので、クリアは手動で実行する必要があります。ステートレス・アラートに関連付けられたメトリックの内部名を見つけるには、EM CLI get_metrics_for_stateless_alerts動詞を使用します。

形式

emcli clear_stateless_alerts -older_than=number_in_days -target_type=target_type -target_name=target_name [-include_members][-metric_internal_name=target_type_metric:metric_name:metric_column] [-unacknowledged_only][-ignore_notifications] [-preview][ ] indicates that the parameter is optional

オプション

- older_than
アラートの経過時間を日数で指定します。(現在オープンしているステートレス・アラートを対象とするには、0を指定します。)

- target_type
内部ターゲット・タイプの識別子(host、oracle_database、emrepなど)。

- target_name
ターゲットの名前。

- include_members
コンポジット・ターゲットに適用され、メンバーに属しているアラートも調査されます。

- metric_internal_name
クリーンアップされるメトリック。get_metrics_for_stateless_alerts verbを使用して、特定のターゲット・タイプでサポートされるメトリックの完全なリストを表示できます。

- unacknowledged_only
アラートが未確認の場合にのみ、それらのアラートを消去します。

- ignore_notifications
このオプションは、消去したアラートに関する通知を送信しない場合に使用します。これにより、通知サブシステムの負荷が軽減される可能性があります。

- ignore_notifications
このオプションは、消去したアラートに関する通知を送信しない場合に使用します。これにより、通知サブシステムの負荷が軽減される可能性があります。

- preview
ターゲットで消去されるアラートの数が表示されます。

例

次の例では、1週間より前の古いデータベース・アラート・ログから生成されるアラートを消去します。この例では、アラートの消去時に通知は送信されません。

emcli clear_stateless_alerts -older_than=7 -target_type=oracle_database -tar  get_name=database -metric_internal_name=oracle_database:alertLog:genericErrStack -ignore_notifications

2.4.4 手動でクリア可能なイベントの自動クリア

自動的にクリアされるイベント(CPU使用率)と、インシデント・マネージャのUIまたはルールによって手動でクリアする必要のあるイベント(ジョブ障害やログ・メトリックなど)があります。自動クリア・イベントは、元になる問題が解決されるとEnterprise Managerによって自動的にクリアされます。CPU使用率の場合、使用率が警告しきい値を下回ると、CPU使用率のイベントは自動的にクリアされます。ただし、手動でクリアする必要のあるイベントの場合は、ユーザーが介入し、インシデント/イベントを選択して「クリア」をクリックするか、またはイベント・ルールを作成してジョブを実行する(推奨)ことによって、インシデント・マネージャを使用してイベントをクリアする必要があります。

前述のとおり、イベント・ルールによって手動でクリア可能なイベントのクリアを自動化できます。Enterprise Managerでは、手動でクリア可能なイベント(ジョブ障害やADPイベント(7日間オープンされている))を自動的にクリアする、アウトオブボックス・ルールがいくつか提供されます。ただし、監視する環境のニーズをより的確に満たすために、独自のイベント・ルールを作成して、その環境に最もよく見られる手動でクリア可能なイベントを自動的にクリアすることをお薦めします。

ルールの作成プロセスでは、条件付きの処理を追加するときに「イベントのクリア」オプションを選択することによって、イベントが自動的にクリアされるように指定できます。

イベントがクリアされたときの通知

イベントのクリア処理は非同期操作であり、ルール・アクション(クリア)が開始されると、手動でクリア可能なイベントがクリアのためにキューにエンキューされますが、実際にはクリアされないことを意味します。つまり、ルールの実行時に送信された電子メール通知は、イベントがまだクリアされていないことを示します。非同期のクリアは、ルール・エンジン全体の処理負荷および処理時間を減らすことを目的としています。このイベントのクリア・ルールを、イベントがクリアされたときに通知されるようにサブスクライブしても、ほとんど意味がありません。イベントがクリアされたときに通知されるようにする場合は、新しいイベント・ルールを作成し、重大度を明示的に「クリア」に指定する必要があります。そうすることで、イベントが実際にクリアされたときに通知されるようになります。

2.4.5 ユーザー報告のイベント

ユーザーはEM CLI動詞publsh_eventを使用してイベントを手動で作成(公開)できます。ユーザー報告のイベントは、"User-reported event"クラスのイベントとして公開されます。ターゲットの管理権限のあるユーザーのみがターゲットに対するこれらのイベントを公開できます。公開が失敗すると、エラー・メッセージが報告されます。

「クリア」以外の重大度でイベントを公開した後で(後述)、適切な権限のあるエンド・ユーザーはUIからイベントを手動でクリアできます。または「クリア」の重大度レベルおよび同じ詳細を使用して新しいイベントを公開し、基礎となる状況のクリアを報告できます。

2.4.5.1 形式

emcli publish_event
-target_name="Target name"
-target_type="Target type internal name"
-message="Message for the event"
-severity="Severity level"
-name="event name"
[-key="sub component name"
-context="name1=value1;name2=value2;.."
-separator=context="alt. pair separator"
-subseparator=context="alt. name-value separator"]

[ ] indicates that the parameter is optional

2.4.5.2 オプション

- target_name
ターゲット名。

- target_type
ターゲット・タイプ名。

- message
イベントに関連付けるメッセージ。メッセージの長さは4000文字までです。

- 重大度
イベントに関連付ける、数値による重大度レベル。サポートされている重大度レベルの値は次のとおりです。

"CLEAR"

"MINOR_WARNING"

"WARNING"

"CRITICAL"

"FATAL"

- 名前
発行するイベントの名前。イベント名は128文字以下です。

イベントの性質がわかるようにします。たとえば、"ディスク使用率"、"プロセス停止"、"キュー数"などです。同じ連続のイベントについて異なる重大度を報告する場合にも、同じこの名前を繰り返す必要があります。"プロセスxyzが停止"のように、特定のイベントに関する具体的な情報を表す名前にはしないでください。イベントの対象となるターゲット内で特定のコンポーネントを識別するには、次に示す「キー」オプションを参照してください。

- キー
このイベントが関係するターゲット内のサブ・コンポーネントの名前。たとえば、ホスト上のディスク名、表領域の名前などを指定します。キーの長さは256文字までです。

- コンテキスト
任意のイベントについて発行できる追加のコンテキスト。name:valueという書式の一連の文字列で、複数の場合はセミコロンで区切ります。たとえば、ディスク上の領域の問題を報告するときには、ディスクの比率のサイズを報告すると便利な場合があります。デフォルトのセパレータ":"はsub-separatorオプションを使用して、ペア・セパレータ";"はseparatorオプションを使用して、それぞれオーバーライドできます。

コンテキスト名の長さは256文字までで、値は4000文字までです。

- セパレータ
デフォルトのセパレータ";"をオーバーライドするときに設定します。このオプションは通常は、名前や値に";"が含まれる場合に使用します。このオプションに"="は使用できません。

- サブセパレータ
名前と値のペアを区切るデフォルトのセパレータ":"をオーバーライドするときに設定します。このオプションは通常は、名前や値に":"が含まれる場合に使用します。このオプションに"="は使用できません。

2.4.5.3 例

例1

この例は、"my acme target"について、HDDのリストアに失敗したことと、その失敗がこのターゲット上の"Finance DB machine"というコンポーネントに関係していることを示す警告イベントを発行します。

emcli publish_event  -target_name="my acme target" -target_type="oracle_acme"
-name="HDD restore failed" -key="Finance DB machine" -message="HDD restoration
failed due to corrupt disk" -severity=WARNING

例2

この例は、"my acme target"について、HDDのリストアに失敗したことと、その失敗がこのターゲット上の"Finance DB machine"というコンポーネントに関係していることを示すマイナー警告イベントを発行します。関連するディスクのサイズと名前をデフォルトのセパレータで示す追加のコンテキストも指定しています。ディスク名で「\」をエスケープするために追加の"\"を使用していることに注意してください。

emcli publish_event  -target_name="my acme target" -target_type="oracle_acme"
-name="HDD restore failed" -key="Finance DB machine" -message="HDD restoration
failed due to corrupt disk" -severity=MINOR_WARNING -context="disk size":800GB\;"disk name":\\uddo0111245

例3

この例は、"my acme target"について、HDDのリストアに失敗したことと、その失敗がこのターゲット上の"Finance DB machine"というコンポーネントに関係していることを示すクリティカル・イベントを発行します。関連するディスクのサイズと名前を示す追加のコンテキストも指定しています。ディスクの名前に、デフォルトのセパレータである":"が使用されているため、別のセパレータを使用しています。

emcli publish_event  -target_name="my acme target" -target_type="oracle_acme"
-name="HDD restore failed" -key="Finance DB machine" -message="HDD restoration
failed due to corrupt disk" -severity=CRITICAL -context="disk size"^800GB\;"disk name"^\\sdd1245:2 -subseparator=context=^

2.4.6 追加のルール・アプリケーション

簡単な通知を超えた、より複雑なタスクを実行するようにルールを設定できます。次のタスクで、追加のルールの機能を説明します。

- イベントの重大度状態別に異なる通知を送信するルールの設定

- イベント・タイプに基づいて異なる管理者に通知するルールの作成

- インシデントのチケットを作成するルールの作成

- サード・パーティ・システムにSNMPトラップを送信するルールの作成

2.4.6.1 イベントの重大度状態別に異なる通知を送信するルールの設定

このタスクを実行する前に、クリティカルなメトリック・アラートが設定どおりに生成されるように、DBAが適切なしきい値を設定していることを確認します。

次に例を示します。

運用管理者が、本番データベース・グループのデータベースにクリティカルのメトリック・アラート・イベントが発生したときには特定のDBAを呼び出し、また同じターゲットについて警告のメトリック・アラート・イベントしたときにはDBAに電子メールを送信するというルールを設定します。このタスクは、データベースの新しいグループがデプロイされ、DBAがこのようなデータベースを管理する適切なルールを作成すると発生します。

適切なしきい値を設定するには、次のタスクを実行します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、ルール・セットをハイライトして「編集...」をクリックします。ルール・セットをハイライトして 「編集」 をクリックします(ルールはルール・セットのコンテキストで作成されます。新規に追加したターゲットを管理する既存のルール・セットがない場合は、ルール・セットを作成します。)

3. ルール・セットの編集ページで、「ルール」セクションを探します。「作成...」をクリックします。

4. 「作成するルールのタイプを選択」ダイアログで、「受信イベントおよびイベントの更新」を選択します。「続行」をクリックします。

5. 次のようにルールの詳細を入力します。

1. 「タイプ」については、「タイプ」として「メトリック・アラート」を選択します。

2. 基準のセクションで「重大度」を選択します。ドロップダウン・リストから、選択値として「クリティカル」および「警告」をクリックします。「次へ」をクリックします。

3. アクションの追加ページで、「+」(「追加」)をクリックします。
「インシデントの作成」セクションで、「インシデントの作成」を選択します。「続行」をクリックします。アクションの追加ページに新規のルールが表示されます。「次」をクリックします。

4. ルール名と説明を指定します。「次」をクリックします。

5. 確認ページで、設定が正しいことを確認し、「続行」をクリックします。ルールが正常に作成されたことを示すメッセージが表示されます。「OK」をクリックして、メッセージを閉じます。
次に、通知のアクションを実行するルールを作成する必要があります。

6. ルールの編集ページの「ルール」セクションで、「作成」をクリックします。

7. ルールのタイプに「新たに作成されたインシデントおよびインシデントの更新」を選択し、「続行」をクリックします。

8. 「特定のインシデント」をクリックします。

9. 「重大度」を選択し、ドロップダウン・リストから「クリティカル」および「警告」を選択します。「次へ」をクリックします。

10. アクションの追加ページで、「追加」をクリックします。条件付きアクション・ページが表示されます。

11. 「アクションの条件」セクションで、「指定された条件に一致する場合のみアクションを実行」を選択します。

12. 「インシデントは次の基準に一致」リストから「重大度」を選択し、ドロップダウン・リストから「クリティカル」を選択します。

13. 「通知」セクションの「ページ」フィールドにDBAを入力します。「続行」をクリックします。アクションの追加ページが表示されます。

14. 「追加」をクリックし、重大度が緊急用の新規アクションを作成します。

15. 「アクションの条件」セクションで、「指定された条件に一致する場合のみアクションを実行」を選択します。

16. 「インシデントは次の基準に一致」リストから「重大度」を選択し、ドロップダウン・リストから「警告」を選択します。

17. 「通知」セクションの「電子メール宛先」フィールドにDBAを入力します。「続行」をクリックします。アクションの追加ページに2つの条件付きアクションが表示されます。「次へ」をクリックします。

18. ルール名と説明を指定します。「次」をクリックします。

19. 確認ページで、ルールが正しく定義されていることを確認して「続行」をクリックします。ルール・セットの編集ページが表示されます。

20. 「保存」をクリックし、新たに定義したルールを保存します。

2.4.6.2 イベント・タイプに基づいて異なる管理者に通知するルールの作成

本番データベースのオペレーション・ポリシーに従って、アプリケーションの問題に関連するインシデントはアプリケーションDBAに通知され、システム・パラメータに関連するインシデントはシステムDBAに通知されるようにする必要があります。そこで、個々のインシデントを適切なDBAに割り当て、電子メールで通知するようにします。

ルールを設定する前に、次の前提条件が満たされていることを確認してください。

- クリティカルのメトリック・アラートが設定どおりに生成されるように、DBAが適切なしきい値を設定していること。

- そのようなすべてのイベントについてインシデントを作成するルールが設定されていること。

- グローバルSMTPゲートウェイ、電子メール・アドレス、各DBAのスケジュールなど、個々の通知設定が完了していること。

次の手順を実行してください。

1. インシデント・ルール・ページにナビゲートします。
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. 本番データベースからのイベントに一致するエンタープライズ・ルールのリストを検索します。

3. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、ルール・セットをハイライトして「編集...」をクリックします。
ルールはルール・セットのコンテキストで作成されます。既存のルール・セットがない場合、ルール・セットを作成します。

4. 「ルール・セットの編集」ページ(「ルール」タブ)で、データベースのメトリック・アラート・イベントに対してインシデントを作成するルールを選択します。「編集」をクリックします。

5. イベントの選択ページで「次へ」をクリックします。

6. 「アクションの追加」ページで、追加をクリックします。条件付きアクションの追加ページが表示されます。

7. 「通知」領域で、この特定のイベント・タイプに対して通知するDBAの電子メール・アドレスを入力し、「続行」をクリックして、アクションを追加します。アクションの追加ページに戻ります。「次へ」をクリックします。

8. 名前と説明の指定ページに、直感的なルールの名前と簡単な説明を入力します。

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

10. 確認ページで、「適用先」、「アクション」および「一般」情報が正しいかどうかを確認します。

11. 「続行」をクリックして、ルールを作成します。

12. 追加のルールを作成/編集して、イベント・タイプに応じた、別の追加の管理者通知を処理します。

13. ルールの概要を確認し、必要に応じて修正します。「保存」をクリックし、ルール・セットの変更を保存します。

2.4.6.3 インシデントのチケットを作成するルールの作成

お客様のITプロセスでインシデント解決にヘルプデスク・チケットの作成を必要とする場合は、ヘルプデスク・コネクタを使用してヘルプデスク・チケットとインシデントを関連付け、インシデントの作成時にEnterprise Managerで自動的にチケットをオープンします。インシデント・マネージャとヘルプデスク・システム間の通信は双方向なので、インシデント・マネージャ内からチケットのステータス変更を確認できます。Enterprise Managerでは、チケットからWebベースのサード・パーティ・コンソールに直接リンクして、チケットから直接コンテキスト内でコンソールを起動することもできます。

たとえば、組織の運用ポリシーに従い、本番データベースのすべてのクリティカル・インシデントは処置チケットを使用して追跡する必要があります。ルールは、データベースに対してクリティカル・インシデントが発生した場合に、処置チケットを作成するように設定されます。このようなインシデントが発生した場合、ルールによってチケットが生成され、インシデントがチケットに関連付けられ、インシデントの更新を後で参照できるように操作がログに記録されます。インシデントの詳細を表示しながら、DBAはチケットIDを確認し、添付されたURLリンクを使用して、チケットに関する詳細を取得するために処置にアクセスできます。

このタスクを実行する前に、次の前提条件が満たされていることを確認してください。

- 監視のサポートが設定されていること。

- チケットの処置コネクタが構成されていること。

次の手順を実行してください。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、適切なルール・セットを選択して「編集」をクリックします。ルール・セットをハイライトして 「編集」 をクリックします(ルールはルール・セットのコンテキストで作成されます。適切なルール・セットがない場合は、新規のルール・セットを作成します)。

3. チケットが生成されるインシデント条件に対応する適切なルールを選択し、「編集...」をクリックします。

4. 「次へ」をクリックしてアクションの追加ページに進みます。

5. 追加をクリックして条件付きアクションの追加ページにアクセスします。

1. このルールが対応するインシデントに対してチケットが生成されるように指定します。

2. 使用するチケットのテンプレートを指定します。

6. 「続行」をクリックし、アクションの追加ページに戻ります。

7. アクションの追加ページで、「次へ」をクリックします。

8. 「確認」ページで「続行」をクリックします。

9. 名前と説明の指定ページで、「次へ」をクリックします。

10. 「確認」ページで「続行」をクリックします。ルールが正常に変更されたことを表すメッセージが表示されます。「OK」をクリックして、メッセージを閉じます。

11. 手順3から10を繰り返して、適切なルールをすべて編集します。

12. 「保存」をクリックし、ルール・セットに対して行った変更を保存します。

2.4.6.4 サード・パーティ・システムにSNMPトラップを送信するルールの作成

第3章「通知の使用」に示したように、Enterprise Managerは、SNMPを介したサード・パーティ管理ツールとの統合をサポートしています。サード・パーティ・システムへのSNMPトラップの送信には、次の2つの処理手順があります。

手順1: SNMPトラップに基づく高度な通知メソッドを作成します。

手順2: SNMPトラップの通知メソッドを起動するインシデント・ルールを作成します。

次の手順は、SNMPトラップの通知メソッドが作成済であることを前提としています。SNMPトラップに基づく通知メソッドの作成手順については、「サード・パーティ・システムへのSNMPトラップの送信」を参照してください。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール: すべてのエンタープライズ・ルール・ページで「ルール・セットの作成...」をクリックします。

3. ルール・セットの「名前」、簡単な「説明」を入力し、ルールの「適用先」(ターゲット)ソース・オブジェクトのタイプを選択します。

4. 「ルール」タブをクリックした後、「作成...」をクリックします。

5. 「作成するルールのタイプを選択」ダイアログで、「受信イベントおよびイベントの更新」を選択し、「続行」をクリックします。

6. 新規ルールの作成: イベントの選択ページで、SNMPトラップを送信するイベントの条件を指定して、「次へ」をクリックします。

注意:
イベント・タイプごとに1つルールを作成する必要があります。たとえば、SNMPトラップを「ターゲット可用性」イベントおよび「メトリック・アラート」イベントに送信する場合、2つのルールを指定する必要があります。

7. 新規ルールの作成: アクションの追加ページで、「追加」をクリックします。条件付きアクションの追加ページが表示されます。

8. 「通知」セクションの「拡張通知」で、既存のSNMPトラップ通知メソッドを選択します。
SNMPトラップの通知メソッドの作成については、「サード・パーティ・システムへのSNMPトラップの送信」を参照してください。

9. 「続行」をクリックし、新規ルールの作成: アクションの追加ページに戻ります。

10. 「次へ」をクリックし、新規ルールの作成: 名前と説明の指定ページに移動します。

11. ルール名および簡潔な説明を指定して、「次へ」をクリックします。

12. ルール定義を確認し、「続行」をクリックしてルールをルール・セットに追加します。ルールがルール・セットに追加されたがまだ保存されていないことを表すメッセージが表示されます。「OK」をクリックして、メッセージを閉じます。

13. 「保存」をクリックしてルール・セットを保存します。確認メッセージが表示されます。「OK」をクリックして、メッセージを閉じます。

2.4.7 インシデント・ルールのエクスポートとインポート

組織内でEnterprise Managerインシデント管理のプラクティスを自動化するインシデント・ルール・セットを慎重に設計およびテストするには、多大な時間と労力を費やします。通常、ルール・セット作成の設計およびテストのフェーズは、個別のEnterprise Managerテスト環境で実行します。インシデント・マネージャのルール・セットのインポート/エクスポート機能により、開発環境から本番環境へのルール・セットの移動が簡易化されます。

テスト環境から本番環境へのルール・セットの移動に加えて、インポート/エクスポート機能を使用すると、障害時に安全にアーカイブできるよう、インシデント・ルールをバックアップすることもできます。さらに重要なのは、インポート/エクスポート機能により、Enterprise Manager環境間でのインシデント管理自動化プロセスを簡単に標準化できる点です。

2.4.7.1 Enterprise Managerコンソールを使用したルール・セットのエクスポート

インシデント・ルール・セットをエクスポートするには、次の手順を実行します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. 「インシデント・ルール - すべてのエンタープライズ・ルール」ページで、エクスポートする目的のルール・セットを選択します。

注意:
Oracleが提供する即時利用可能なルール・セットをエクスポートすることはできません。

3. 「エクスポート」をクリックします。ブラウザのファイル・ダイアログが表示され、ファイルを保存するか、または開くように求められます。ローカル・ディスクにファイルを保存します。デフォルトでは、ファイル名はルール・セットの名前に.xml拡張子を付けたものになります。

注意:
生成されたルール・セットXMLファイルは編集しないでください。

2.4.7.2 Enterprise Managerコンソールを使用したルール・セットのインポート

インシデント・ルール・セットをインポートするには、管理者に「エンタープライズ・ルール・セットの作成」権限が必要です。

インシデント・ルール・セットは、最初にインポートされる際にデフォルトで無効化されます。特定のターゲット選択用のターゲット名や電子メール通知用のユーザー名など、環境固有のパラメータを指定するには、インポートしたルール・セットを編集する必要があります。その後、ルール・セットを有効化する必要があります。

インシデント・ルール・セットをインポートするには、次の手順を実行します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. 「インポート」をクリックします。「ルール・セットのインポート」ダイアログが表示されます。

3. 「ルール・セットのインポート」ダイアログから、「ファイルの選択」をクリックします。「ファイルのアップロード」ダイアログが表示されます。

4. インシデント・ルール・セットXMLファイルを選択し、「開く」をクリックします。

5. 「OK」をクリックします。
名前にネーミングの競合が発生した場合は、次のいずれかを選択するように要求されます。

- 同じ名前でルール・セットをオーバーライドする

- 異なる名前でルール・セットを作成する

2.4.7.3 EM CLIを使用したルール・セットのインポート

EM CLIを使用して、数多くのルール・セットをインポート/エクスポートするスクリプトを記述できます。コマンドラインまたはスクリプトからインポート操作を実行するには、「エンタープライズ・ルール・セットの作成」権限が必要です。

ルール・セットは、Oracleによって提供される事前定義済の(即時利用可能な)ルール・セットを除き、エンタープライズ・ルール・セットのリストからインポートできます。

emcli import_incident_rule_set
-import_file=<XML file name along with the file path for the exported rule set earlier>
[-alt_rule_set_name=<rule set name>]

オプション

- import_file=<XML file name along with the file path for the exported rule set earlier>

- alt_rule_set_name=<rule set name>
オプションで、ルール・セットがすでに存在する場合に使用するエンタープライズ・ルール・セットの名前を指定できます。

例

emcli import_incident_rule_set -import_file="/tmp/TEST_RULESET.xml" -alt_rule_set_name=COPY_OF_TEST_RULESET

このコマンドにより、ルール・セットXMLとして指定されたTEST_RULESET.xmlからルール・セットがインポートされ、COPY_OF_TEST_RULESETとして名前が付けられます

2.4.7.4 EM CLIを使用したルール・セットのエクスポート

ルール・セットは、Oracleによって提供される事前定義済の(即時利用可能な)ルール・セットを除き、エンタープライズ・ルール・セットのリストからエクスポートできます。すべてのユーザーがエクスポート操作を実行できます。特別な権限は必要ありません。

emcli export_incident_rule_set
-rule_set_name=<rule set name>
[-rule_set_owner=<ruleset owner>]
-export_file=<XML file name along with the file path for the exported rule set>

オプション

- rule_set_name=<rule set name>
エンタープライズ・ルール・セットの名前。

- rule_set_owner=<ruleset owner>
オプションで指定できる、ルール・セットの所有者。

- export_file=<XML file name along with the file path for the exported rule set>
ファイル名がディレクトリとして指定されている場合、そのディレクトリ内のルール・セット名を含むファイルが作成されます。

例:

emcli export_incident_rule_set -rule_set_name=TEST_RULESET -rule_set_owner=sysman -export_file="/tmp/"

このコマンドにより、ルール・セットからTEST_RULESETという名前のルールセットがエクスポートされ、/tmp/TEST_RULESET.xmlに保存されます

2.4.8 イベントに対する修正処理の作成

Enterprise Managerリリース13.1より前のリリースでは、修正処理を関連付けられるのはメトリック・アラートのみでした。Enterprise Managerリリース13.1では、スクリプトベースの修正処理によって修正処理をイベント・ルールに関連付けることにより、イベントをトリガーできるようになりました。これにより、コンプライアンス標準の違反、メトリック・エラー、ターゲット可用性など、修正処理を使用できる状況が大幅に増加しました。修正処理をイベント・ルールに関連付けることにより、修正処理を自動的に実行できます。

また、インシデント・マネージャの「ガイドされた解決」領域のイベント詳細を使用して、手動で修正処理を開始することもできます。修正処理の詳細は、「修正処理の作成」を参照してください。

イベント・ルールでの修正処理

一致するイベントが発生するとトリガーされるイベント・ルールを作成する場合、事前定義された適切な修正処理を「修正処理ライブラリ」から選択できます。選択可能な修正処理は、ルールに選択されたイベント・タイプおよびターゲット・タイプに応じて異なります。

イベント・ルール・セットがエクスポートまたはインポートされると、関連付けられている修正処理もエクスポート/インポートされます。イベント・ルールのインポート/エクスポートの詳細は、「インシデント・ルールのエクスポートとインポート」を参照してください。

修正処理の作成

修正処理をイベント・ルールに関連付けるには、最初にその処理を修正処理ライブラリに追加する必要があります。ライブラリに修正処理を保存すると、イベント・ルールに修正処理を定義する際にはいつでも、保存した修正処理の定義を再利用できます。

1. 「エンタープライズ」メニューで「モニタリング」、「修正処理」の順に選択します。「修正処理ライブラリ」ページが表示されます。

2. 「ライブラリ修正処理の作成」ドロップダウンからジョブ・タイプを選択します。イベントについては、スクリプトを実行できるように、「OSコマンド」ジョブ・タイプを作成する必要があります。「OSコマンド」を選択して名前を指定し、「実行」をクリックします。「'OSコマンド'修正処理の作成」ページが表示されます。
修正処理の名前と簡単な説明またはイベント・タイプを指定します。

3. 「ターゲット・タイプ」ドロップダウン・メニューから、ターゲット・タイプを選択します。「パラメータ」タブをクリックします。

4. 「コマンド・タイプ」ドロップダウン・メニューから、「スクリプト」を選択します。

5. OSスクリプト・テキストを入力します。
スクリプトで使用可能なすべてのターゲットとイベントのプロパティが、右側の表にリストされます。

ヒント: インシデント・マネージャから「イベントの詳細」ページにアクセスする際に、「属性の内部値を表示します」をクリックすると、イベント属性の内部名および値を表示できます。これにより、修正処理のスクリプトを記述するときにアクセス可能な情報を判断できます。単に、ダイアログから情報をコピーしてテキスト・エディタに貼り付け、スクリプトの作成時に、属性のこのリストを参照します

重要:
イベント・コンテキスト・パラメータを使用する場合は、接頭辞にEVTCTXを付ける必要があります。

6. インタプリタを指定します。例: %perlbin%/perl

7. 終了後、「ライブラリに保存」をクリックします。「修正処理ライブラリ」ページが表示され、ライブラリ・リストに修正処理が表示されます。
この時点で、修正処理はドラフト・ステータスとなります。この段階では、修正処理をテストおよび変更できます。ただし、所有者のみが、インシデント・マネージャからCAを手動で実行してCAをテストできます。

修正処理をテストするには、イベント・ルールと一致するイベントを関連付けられている修正処理とともにトリガーし、処理が予測したものであるかを確認する必要があります。特に問題がなく、他の管理者が修正処理を使用する準備が整ったら、次のステップに進みます。

注意: 「'OSコマンド'修正処理の作成」ページの「アクセス」タブに、この修正処理へのアクセス権がある管理者およびロールが表示されます。必要に応じて、このタブから、この修正処理へのアクセス権を変更できます。

8. 「修正処理ライブラリ」ページに移動して修正処理を選択し、「公開」をクリックします。確認メッセージが表示されます。「はい」をクリックして、公開を確認します。

9. 優先資格証明の設定「設定」メニューから、「セキュリティ」を選択し、「優先資格証明」を選択します。「優先資格証明」ページが表示されます。ルールにリンクされた修正処理では、ルール・セット所有者の優先資格証明が使用されることに注意してください。

注意:
修正処理では、これらの資格証明を使用してシステムにアクセスし、アクション(この場合にはスクリプトの実行)を実行します。たとえば、修正処理が特定のホストを対象として実行される場合、ホストに資格証明を設定します。

10. まだ設定していない場合は、修正処理によってアクセスされるターゲット・タイプを選択して、「優先資格証明の管理」をクリックします。CAでアクションを実行する対象となる特定のターゲット・タイプについて、デフォルトの優先資格証明を定義する必要があります。ターゲット・タイプの「優先資格証明」ページが表示されます。「プリファレンス」タブで、「デフォルトの優先資格証明」リージョンに移動し、適用可能な資格証明を選択します。「設定」をクリックします。

重要:
優先資格証明の設定は必須であり、設定しない場合、修正処理は失敗します。

修正処理とイベント・ルールとの関連付け

イベントと関連付ける修正処理を作成すると、その修正処理を使用するイベント・ルールを作成できるようになります。ルールの条件付きアクションごとに関連付けることのできる修正処理は、1つのみです。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。「インシデント・ルール - すべてのエンタープライズ・ルール」ページが表示されます。

2. 「インシデント・ルール・セットの作成」をクリックします。「ルール・セットの作成」ページが表示されます。

3. ルール・セットの名前および説明を入力します。

4. 適切なターゲットを選択します。

5. 「ルール」セクションまでスクロールして、「作成...」をクリックします。ルールのタイプを選択ダイアログが表示されます。「受信イベントおよびイベントの更新」を選択して、「続行」をクリックします。ルール・セットの作成ウィザードが表示されます。

6. 「タイプ」ドロップダウン・メニューから、イベントのタイプを選択します。デフォルトでは、「メトリック・アラート」が選択されています。「コンプライアンス標準ルール違反」など、イベント・タイプのいずれかを選択します。「詳細な選択オプション」を展開し、イベント・ルールを適用する必要があるすべてのイベント・パラメータを設定します。

7. 「次へ」をクリックしてアクションの追加ページに進みます。

8. アクションの追加ページで、「追加」をクリックします。条件付きアクションの追加ページが表示されます。

9. 「修正処理の発行」セクションまでスクロールし、「訂正処理の選択」をクリックします。訂正処理を選択するダイアログが表示されます。

10. アタッチする修正処理を選択して、「OK」をクリックします。

重要:
ルールはバックグラウンドで実行されるため、資格証明の入力を求められることはなく、修正処理の実行には、ルール・セット所有者の優先資格証明が使用されます。

11. 「続行」をクリックします。メインの「アクションの追加」ページに戻ります。必要に応じて、さらにアクションの追加を続行します。

12. ルール・セット定義を完了し、「インシデント・ルール - すべてのエンタープライズ・ルール」ページにあるインシデント・ルール・セットのリストに、そのルール・セット定義が表示されることを確認します。

CAをテストするために、特定のルール違反を再作成する必要があります。

手動による修正処理の実行

現在のイベントを解決できる修正処理が修正処理ライブラリに存在することを把握している場合、その修正処理をライブラリから手動で実行できます。「イベントの詳細」ページの「ガイドされた解決」セクションにある「修正処理」領域に、「ライブラリから発行」リンクが表示されます。

「ライブラリから発行」をクリックして、「修正処理ライブラリ」ダイアログを表示します。このダイアログには、現在のイベント条件に適用される修正処理のみがリストされます。リストから修正処理を選択します。資格証明設定が表示されます。デフォルトでは、優先資格証明が表示されます。別の資格証明を使用することもできます。

設定後、「発行」をクリックします。「修正処理<CA名>は正常に発行されました。」ダイアログが表示されます。リンク「ここをクリックして実行の詳細を表示します。」をクリックして、ジョブ実行ページに移動します。ここで、ジョブ・ステータスおよび出力を表示できます。

2.4.9 1つのインシデントへの複数イベントの圧縮

インシデントは、対応するインシデント・ルールが定義されている場合に、イベントに対して作成されます。この状況では、複数のイベントによって複数のインシデントが生成されます。ただし、イベントが同じ問題に関連している場合、管理の容易性の見地から、複数のインシデントを生成するのではなく、単に1つのインシデントを生成する方が適切です。このことは、特に、同じ管理者がこれらの関連イベントを管理する場合に当てはまります。

Enterprise Manager 13c以上では、インテリジェントなインシデント圧縮により、複数のイベントを自動的に1つのインシデントにグループ化できます。次のような状況においては、複数のイベントを1つのインシデントとして処理するとメリットがあります。

- 特定のデータベースの表領域全体にわたる、すべての「使用されている表領域(%)」アラートが、自動的に1つのインシデントに統合されるようにする必要がある場合。

- 1つのターゲットについてのすべてのメトリック収集エラーが、自動的に1つのインシデントに統合されるようにする必要がある場合。

- 1つのWebLogicドメイン内の、すべてのSOAコンポジット・ターゲットの停止イベントが、自動的に1つのインシデントに統合されるようにする必要がある場合。

利便性のために、Enterprise Managerには、関連イベントを1つのインシデントに自動的に圧縮する即時利用可能なルールが用意されています。これらのルールは、イベントのグループ化が役立つ可能性のある、最も一般的な条件のいくつかに対処します。

- RACデータベース・インスタンスでのターゲット停止。

- ターゲットについてのメトリック収集エラー。

- ターゲット上のルールに関する構成標準違反。

イベント圧縮オプション

新しいインシデントを生成する新しいイベント・ルールを定義する場合(詳細は、「ルール・セットの作成」を参照)、「各イベントによって新しいインシデントが作成されます」または「イベントを1つのインシデントに圧縮します」の2つのオプションが提示されます。イベントを1つのインシデントにグループ化することを選択する場合、次の図に示すように、4つのグループ化オプションからいずれかを選択できます。

図2-9 イベント圧縮オプション

- 時間ウィンドウ別の圧縮(必須)
デフォルトでは、それぞれ1時間以内に発生したイベントが、1つのインシデントにグループ化されます。1時間ウィンドウ外部で発生するイベントの場合は、すべて新しいインシデントが1つ生成されます。デフォルトの時間ウィンドウの時間は変更できます。

- ターゲット別の圧縮
イベントはすべて、同じホストまたはデータベースについてのメトリック収集エラーなど、同じターゲットに関連します。

- カテゴリ別の圧縮
イベントは、「可用性」、「ビジネス」、「容量」、「構成」、「エラー」、「フォルト」、「ジョブ」、「負荷」、「パフォーマンス」、「セキュリティ」の一般的なカテゴリに従って、圧縮できます

イベントは、次の3つの異なる方法で分類できます。

- イベントが分類されていない場合、独自のインシデントが作成されます。

- 複数のカテゴリに分類されたイベントの場合、圧縮されたインシデントには、まったく同じカテゴリのセットが含まれます。たとえば、「構成」と「セキュリティ」のカテゴリを含むイベントは、「構成」と「セキュリティ」のカテゴリを含む、一致するその他のイベントとグループ化されます。

- 単一カテゴリを含むイベントは、まったく同じカテゴリを含むその他のイベントとグループ化されます。たとえば、「セキュリティ」カテゴリを含むイベントは、「セキュリティ」カテゴリを含むその他のイベントとのみグループ化されます。

- イベント名別の圧縮
イベントは、同じ名前のその他のイベントとグループ化されます。

例: メトリック・アラートの場合、メトリック名がイベント名になります。

ターゲットのグループ化基準

ターゲット別にイベントを圧縮することを選択した場合は、ターゲットのグループ化基準のいずれかを選択する必要があります。

図2-10 ターゲットのグループ化オプション

ターゲット別にグループ化する場合、次の基準を使用できます。

- ターゲット別

- 1つのターゲットに対するすべてのイベントが、1つのインシデントにグループ化されます
例: 1つのターゲットに対するすべてのメトリック収集エラーは、1つのインシデントにグループ化されます

- ターゲットのホスト別

- ホスト上にあるすべてのターゲットを対象としたすべてのイベントが、1つのインシデントにグループ化されます
例: ホスト上にあるすべてのターゲットに対するすべての「エージェント停止」イベントは、1つのインシデントにグループ化されます

- ターゲットの祖先別

- ターゲットの祖先は、親ターゲット、ターゲットの親の親またはさらに遠縁のエンティティにすることができます。祖先ツリーに従って、ターゲット・タイプが一致するなんらかの祖先を見つけます。
祖先の例は次のとおりです。

- RACインスタンスの祖先として、クラスタ・データベースが親、そのクラスタ・データベースを含むデータベース・システムが親の親になります。

- SOAコンポジットの祖先として、SOAインフラストラクチャ、SOAインフラ・クラスタ、WebLogicドメイン/ファームがあります

- トポロジをチェックして、ターゲットの親(コンポジットのメンバー)を確認します
例: 1つのWebLogicドメイン内にあるすべてのSOAコンポジット停止イベントは、1つのインシデントにグループ化されます。

- 汎用システム別:
同じ汎用システムのメンバーであるターゲットからのイベントをまとめてグループ化します。

例: アプリケーションについて独自のシステムを作成し、特定のシステムを1つの単位として管理するには、このシステムに関連するすべてのイベントをグループ化する必要があります。

警告:
ターゲットは、複数の汎用システムのメンバーにすることができます。このタイプのターゲット上でイベントが発生すると、新しいインシデントがこのイベント用に作成されます。この場合にはグループ化されません。

イベント圧縮の作成

1. 「設定」メニューで「インシデント」,、「インシデント・ルール」の順に選択します。「インシデント・ルール - すべてのエンタープライズ・ルール」ページが表示されます。

2. 「ルール・セットの作成」をクリックします。「ルール・セットの作成」ページが表示されます。名前およびなんらかの説明的な情報を入力します。

3. 「ターゲット」リージョンから、「すべてのターゲット」を選択します。

4. 「ルール」リージョンまでスクロールして、「作成...」をクリックします。「作成するルールのタイプを選択」ダイアログが表示されます。

5. 「受信イベントおよびイベントの更新」を選択して、「続行」をクリックします。ルール・セットの作成ウィザードが表示されます。

6. 「イベントの選択」ページで、イベント・タイプを選択します。たとえば、「ターゲット可用性」を選択します。

7. タイプ・ターゲット可用性の特定のイベントオプションを選択します。「タイプ・ターゲット可用性の選択したイベント」表が表示されます。「追加」をクリックします。「ターゲットの可用性イベントを選択」ダイアログが表示されます。

8. 「ターゲット・タイプ」ドロップダウン・メニューから、「すべてのターゲット・タイプ」を選択します。

9. 「可用性状態」リストから、「停止中」を選択します。次に、「OK」をクリックします。表に、ターゲット可用性イベントが表示されます。

10. 「次へ」をクリックしてアクションの追加ページに進みます。「新規ルールの作成: アクションの追加」リージョンが表示されます。

11. 「追加」をクリックします。「条件付きアクションの追加」ページが表示されます。

12. 「インシデントの作成」または「インシデントの更新」領域で、「インシデントの作成(関連付けられているインシデントがない場合)」を選択します。この選択の下に、「インシデントの作成」オプションが表示されます。

13. イベントを1つのインシデントに圧縮しますを選択します。イベント圧縮オプションが表示されます。

14. イベントの圧縮基準を展開して、「ターゲット」を選択します。ターゲット圧縮基準オプションが表示されます。必要なイベント圧縮基準を選択します。
たとえば、「イベントは、次のタイプの同じ祖先ターゲットを持つターゲットからです」を選択して、ドロップダウン・メニューから、「Oracle WebLogicドメイン」を選択します。

15. イベントの圧縮によって作成されるインシデントのメッセージを展開し、必要に応じてメッセージを変更します。

16. 「続行」をクリックし、「アクションの追加」表に戻ります。「アクション・サマリー」列に定義したイベント・グループ化アクションを表示できます。

17. 「次」をクリックします。「新規ルールの作成: 名前と説明の指定」が表示されます。デフォルトのルール名をそのまま使用することも、カスタム名を指定することもできます。オプションで、ルール説明を入力できます。

18. 「次へ」をクリックして、「確認」ページに進みます。前のページに戻って変更を行うには、「戻る」をクリックします。

19. ルールに問題がなければ、「確認」ページから、「続行」をクリックして「ルール・セットの作成」ページに戻ります。

20. 「保存」をクリックします。「インシデント・ルール - すべてのエンタープライズ・ルール」ページに戻ります。新しいイベント圧縮ルールが、表の最下部に表示されます。

重要:
ルールは順番に(上から下に)実行されるため、イベント圧縮ルールが最初に実行されようにする必要があります。
ルール実行順序を変更するために「ルール・セットの並替え…」をクリックすると、「ルール・セットの並替え」ダイアログが表示されます。新しいイベント・グループ化ルールを選択して、先頭に移動します。「OK」をクリックしてダイアログを閉じます。

順序付けが適切に完了したら、ルール・セットを使用できるようになります。

イベントの発生時には、インシデント・マネージャに移動して、イベント・グループ化結果を表示できます。「すべてのオープン・インシデント」をクリックします。イベント圧縮オプションを使用してルール・セットから生成された新しいインシデントをリストから選択し、インシデント詳細を表示します。これにより、複数のイベントがこの1つのインシデントで発生したことがわかります。イベント詳細の「一般」タブにある「イベント」リージョンに、発生してインシデントに圧縮されたすべてのイベントが、関連するグループとターゲットの情報とともに明示的にリストされます。グループ化されたイベントを含むインシデントを識別しやすくするために、「メンバー数」列を追加して、降順でソートできます。複数のメンバーを含むインシデントには、そのインシデントに対する複数のイベントが含まれます。

2.4.10 イベントの優先度付け

大企業では、システムの負荷が高いときに多くのインシデントとイベントが生成されると考えられます。ビジネスの優先度に従って、これらすべてをタイミングよく効率的な方法で処理する必要があります。どのイベント/インシデントを最初に解決する必要があるかを判断する効果的な優先度付けの方法が必要です。

どのイベント/インシデントの優先度が高いかを判断するために、Enterprise Managerは、ターゲットの「ライフサイクル・ステータス」と「インシデント・タイプ/イベント・タイプ」の2つのインシデント/イベント属性に基づく優先度付けプロトコルを使用します。ライフサイクル・ステータスは、ターゲットの運用ステータスを示すターゲット・プロパティです。ターゲットのライフサイクル・ステータスは、UIから設定/表示できます(ターゲットの「ターゲット設定」メニューから「プロパティ」を選択)。ターゲットのライフサイクル・ステータス・プロパティは、Enterprise Managerコマンドライン・インタフェース(EM CLI)のset_target_property_value動詞を使用して、複数のターゲットに対して同時に設定できます。

ターゲットの「ライフサイクル・ステータス」は、そのターゲットが監視のためにEnterprise Managerに追加されたときに設定されます。その時点で、ターゲットが属する優先度階層(最高レベルは「基幹」、最低レベルは「開発」)を決定します。

ターゲットのライフサイクル・ステータス

- 基幹(最高の優先度)

- 本番

- ステージング

- テスト

- 開発(最低の優先度)

インシデント/イベント・タイプ

- 可用性イベント(最高の優先度)

- 非情報イベント。

- 情報イベント

2.4.11 根本原因分析(RCA)とターゲットの停止イベント

根本原因分析(RCA)は、操作イベントを発生させた問題の根本原因を特定しようとします。Enterprise Manager Could Control 12.1.0.3から、インシデント・マネージャがターゲットの停止イベント上で自動的にRCAを実行するようになり、ターゲットの停止イベントが他のターゲットの停止イベントの原因または兆候であるかどうかが積極的に特定されるようになりました。ターゲットの停止イベントという用語は、ターゲットが停止していると検出されたときに発生するターゲット可用性イベントに特に関係します。

2.4.11.1 RCAの動作

RCAは、ターゲットの停止イベントが根本原因または兆候であるかどうかを特定する持続プロセスです。イベントの原因分析の更新属性が使用されて分析の結果が格納され、つまり、ターゲットの停止イベントが根本原因または兆候であるかどうかが特定されます。新しいターゲットの可用性イベントが入ってくると必ず、受信イベント上およびそれが関連付けられている既存のターゲットの停止イベント上でRCAが自動的に実行されます。分析に基づいて、受信イベントがターゲットの停止イベントである場合は原因分析の更新属性値が更新されます。変更がある場合は、関連するターゲットの停止イベントの原因分析の更新属性も更新されます。

関連ターゲットの特定に2つのタイプのターゲット関係、依存性および包含が使用されます。

あるターゲットが可用性に関して別のターゲットに依存する場合、それらの間に依存関係が存在します。たとえば、J2EEアプリケーション・ターゲットは、デプロイ先のWebLogic Serverターゲットに依存します。

原因分析の更新属性は、ターゲットの停止イベント(ターゲットの停止に関するターゲット可用性イベントなど)に対してのみ使用され、RCAプロセスによって次の値のいずれかを割り当てることができます。

- 兆候 -- ターゲットの停止イベントが別のターゲットの停止イベントによって引き起こされています。

- 原因 -- ターゲットの停止イベントが別のターゲットの停止イベントを引き起こし、他のターゲットの停止イベントの兆候ではありません。

- 根本原因 -- ターゲットの停止イベントが別のターゲットの停止イベントを引き起こし、他のターゲットの停止イベントの兆候ではありません。

- N/A - 根本原因分析はこのイベントには適用されません。根本原因分析は、ターゲットの停止イベントにのみ適用されます。

- 原因および兆候ではない - ターゲットの停止イベントは、他のターゲットの停止イベントの根本原因ではなく兆候でもありません。これは、インシデント・マネージャでダッシュ(-)と表示されます。

次のルールはRCAプロセスを説明しています。

- ルール1: 非コンテナ・ターゲット(メンバーを持たないターゲット)の停止イベントは、依存ターゲットが停止しており、他のターゲットの停止イベントの兆候ではない場合、原因としてマークされます。
次に例を示します。

- スタンドアロンWebLogic ServerにデプロイされたJ2EEアプリケーションがあるとします。J2EEアプリケーションとWebLogic Serverターゲットの両方が停止している場合、WebLogic Serverの停止イベントが、デプロイされているJ2EEアプリケーションに対する原因になります。

- Weblogicクラスタの一部である2つのWebLogic ServerにデプロイされているJ2EEアプリケーションがあるとします。1つのWebLogic ServerがそのJ2EEアプリケーションとともに停止している場合、そのWebLogic Serverの停止イベントは、J2EEアプリケーション・ターゲットの停止の原因になります。これはWebLogicクラスタが停止していないと仮定しています。

- ルール2: 非コンテナ・ターゲット(メンバーを持たないターゲット)の停止イベントは、それが依存するターゲットがダウンしているかそれを含むターゲットがダウンしている場合、兆候としてマークされます。
次に例を示します。

- スタンドアロンWebLogic ServerにデプロイされたJ2EEアプリケーションがあるとします。J2EEアプリケーションとWebLogic Serverターゲットの両方が停止している場合、J2EEアプリケーションの停止イベントは、停止しているWebLogic Serverの兆候になります。

- WebLogicクラスタの一部である2つのWebLogic Serverがあるとします。各WebLogic ServerにJ2EEアプリケーションがデプロイされています。Weblogicクラスタが停止している場合、両方のWebLogic Serverが停止していることを意味します。その結果、これらのサーバーにデプロイされるJ2EEアプリケーションも停止します。WebLogic Serverの停止イベントは、停止しているWeblogicクラスタの原因であるとマークされます。詳細は、ルール3を参照してください。

- クラスタ・データベース・ターゲットの一部である、2つのRACデータベース・インスタンス・ターゲットがあるとします。クラスタ・データベースが停止している場合、すべてのRACインスタンスも停止します。RACインスタンスの停止イベントは、停止しているクラスタ・データベースの原因としてマークされます。詳細は、ルール3を参照してください。

- ルール3: コンテナ・ターゲットの停止イベントは、すべてのメンバー・ターゲットが停止しており、それを含むターゲットが停止していない場合、兆候としてマークされます。
次に例を示します。

- スタンドアロンWebLogicクラスタの一部である2つのWebLogic Serverがあるとします。WebLogicクラスタの停止イベントは、両方のWebLogic Serverが停止している場合は兆候としてマークされます。

- クラスタ・データベース・ターゲットの一部である、2つのRACデータベース・インスタンス・ターゲットがあるとします。クラスタ・データベース・ターゲットの停止イベントは、両方のデータベース・インスタンスが停止している場合、兆候としてマークされます。

- ルール4: コンテナ・ターゲットの停止イベントは、それを含むターゲットが停止している場合、兆候としてマークされます。
例:

WebLogicドメイン・ターゲットの一部である、2つのWebLogicクラスタがあるとします。WebLogicドメインが停止している場合、WebLogicクラスタも停止していることを意味します。WebLogicクラスタ・ターゲットの停止イベントは、停止しているWebLogicドメインの原因です。WebLogicドメインの停止イベントは兆候としてマークされます。

2.4.11.2 インシデント・ルール・セットにおけるRCA結果の活用

前述のように、RCAは持続プロセスであり、新しいターゲットの停止イベントが受信されて処理される間に、ターゲットの停止イベントを原因、兆候またはいずれでもないとしてマークします。そのため、ターゲットの停止イベントは、受信されたときまたはその後RCAが追加のイベント情報を分析したときに、原因または兆候としてマークされる場合があります。

ターゲットの停止イベントはただちに解決する必要がある重要なイベントであるため、ほとんどのデータセンターでは、ターゲットの停止イベントのインシデントを自動的に作成します。これはお薦めのベスト・プラクティスであり、即時使用可能ルール・セットによって実装もされています。しかし、レスポンス・チームへの通知またはトラブル・チケットの作成に関しては、兆候インシデントの場合にそのようにすることは望ましくありません。一部のデータセンターでは、兆候イベントについてインシデントを作成しないことを選択する場合もあります。

そのため、RCAの結果は次のように活用できます。

1. 兆候以外のイベントについて通知またはチケットを作成します。
これは2つの方法で実施できます。

- 2つの別々のイベント・ルールを作成し、1つのイベント・ルールではすべての関連イベントのインシデントを作成するが、それ以上のアクションをとらない(通知やチケット作成は行わない)ようにし、もう1つのルールでは兆候以外のイベントのみについてインシデントを作成し、通知の送信およびチケットの作成を行うようにします。手順については、「兆候以外のイベントのインシデントの作成」を参照してください。

- ターゲットの停止イベントのすべてについてインシデントを作成するイベント・ルールを作成します。インシデント優先度を更新する別のルールを作成し、兆候以外のイベントから発生したインシデントについてのみ通知の送信およびチケットの作成を行うようにします。インシデント優先度が「緊急」に設定されると、顧客は、緊急優先度のインシデントに対する追加アクションを実行する追加のインシデント・ルールを作成することもできます。「兆候以外のイベントのインシデント優先度を更新するルールの作成」を参照してください。

2. 最初に原因と兆候のどちらでもないとマークされなかったイベントを待機した後にのみ、インシデントを作成します。
前述のように、RCAは、受信するターゲットの停止イベントが継続的に評価され、既存イベントの原因分析の状態が更新される反復プロセスです。最初に根本原因としてマークされたターゲットの停止イベントは、受信する他のターゲットの停止イベントに応じて、一定の時間(分)、根本原因のままである場合も根本原因ではなくなる場合もあります。元のターゲットの停止イベントが、後で兆候として分類されることがあります。

後で兆候イベントという結果になる可能性のあるイベントに対して、時期尚早にインシデントを作成しチケットをオープンすることがないように、次のようにルールを設定できます。

- 前述の手順ですでに定義したルールに加えて、追加のイベント・ルールを作成し、イベントに対するRCAが更新され、イベントが兆候としてマークされてインシデントの優先度が「低」に下げられることがRCAの更新によって示されるときに機能するようにします。これによって、チケットに対する更新も自動的に送信されます。これがお薦めの方法です。手順については、「遅延時間の概要」を参照してください。
または

- ターゲットの停止イベントが報告、分析され、それについてのアクション(インシデントの作成やインシデントの更新など)が実行される時間を見越すために、ルール・アクションに遅延を追加できます。これは、顧客が最小遅延(通常は5分)の後にアクションを実行する許容差を持つ場合に便利です。

3. 兆候以外のイベントに対してのみインシデントを作成します。
一部のデータセンターでは、兆候イベントについてインシデントを作成しないことを選択する場合があります。これは、原因としてマークされた、または原因と兆候のどちらでもないとマークされたイベントについてのみインシデントを作成するルールを変更することによって実施できます。手順については、「兆候以外のイベントのインシデントの作成」を参照してください。

この方法でも、最初に原因としてまたは原因と兆候のどちらでもないとマークされていたイベントが、追加情報を受け取ったときに兆候としてマークされる場合もあることに注意してください。顧客は、手順2の2番目のオプションと類似した方法を使用して、インシデントの作成に遅延を作成することができます。この場合でも、事前設定の遅延後に新しい情報が現れ、イベントが結局兆候としてマークされることもありえます。そのため、インシデント優先度を使用し、ワークフローを管理する1つの方法としてそれを使用する方法の使用をお薦めします。

2.4.11.3 インシデント・マネージャにおけるRCA結果の活用

RCAの結果を使用して、インシデント・マネージャで兆候以外のインシデントに焦点を当てることができます。これには、カスタム値を作成するときに原因分析の更新インシデント属性を使用することが含まれます。

1. 「エンタープライズ」メニューから、「監視」、「インシデント」の順に選択します。インシデント・マネージャ・ページが表示されます。

2. 「ビュー」リージョンから「作成」をクリックします。検索ページが表示されます。

3. 「フィールドの追加...」をクリックし、「原因分析の更新」を選択します。追加の検索基準として原因分析の更新が表示されます。

4. 選択可能な基準のリストから「兆候を表示しない」を選択します。これによって、「兆候」とマークされたインシデントが自動的に除外されます。兆候または根本原因としてマークされていないインシデントは、指定した他の基準に一致するかぎり含まれます。

5. 「ビューの作成」をクリックし、「ビュー名」を求められたら入力し、OKをクリックします。

インシデントの詳細におけるRCA結果の表示

根本原因または兆候であるインシデントは、インシデント・マネージャでインシデントの詳細の一部として目立つように識別されます。さらに、インシデントが兆候である場合、インシデントの根本原因を識別するために「原因」セクションが追加されます。同様に、インシデントが他のターゲットの停止インシデントを発生させた場合、影響されたターゲット(つまり、元のターゲットの停止の結果として停止している他のターゲット)を表示するために「影響されるターゲット」セクションも追加されます。次の図にインシデントの詳細を示します。

図2-11 根本原因であるインシデント

2.4.11.4 システム・ダッシュボードにおけるRCA結果の活用

システム・ダッシュボードで、RCA結果を使用して、インシデント表から兆候インシデントを除外し、根本原因であり他のターゲットの停止イベントによって発生したものではないインシデントに管理者が焦点を当てることができるようにすることができます。

兆候インシデントを除外する手順:

1. システム・ダッシュボードで、「インシデントと問題」表の左上隅からアクセスできる「ビュー」オプションをクリックします。

2. 「兆候の除外」オプションを選択します。かわりに「原因のみ」オプションを選択して、他のターゲットの停止インシデントの原因として識別されたターゲットの停止インシデントのみを表示することもできます。選択したオプションにかかわらず、兆候または根本原因としてマークされていないインシデントは表示されたままです。

2.4.11.5 兆候以外のイベントのインシデント優先度を更新するルールの作成

1. 兆候以外のイベントのみを選択するイベント・ルールを作成します。

2. アクションを追加するとき、選択した兆候以外のイベントに関連付けられているインシデントに設定する優先度を選択します。

2.4.11.6 兆候以外のイベントのインシデントの作成

インシデント生成のルール・セットを作成するインシデント・マネージャのRCA機能を活用できます。多数の兆候のターゲットの停止イベントが生成され、兆候以外のターゲットの停止イベントが少しだけである状況の監視では、兆候以外のイベントについてのみインシデントを生成し通知を送信するルール・セットを作成できます。

兆候以外のターゲットの停止イベントについてインシデントを作成するルール・セットを作成する手順:

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. 「ルール・セットの作成...」をクリックします。ルール・セットの作成の一部としてルールを作成します。

3. 新規ルールを含むルール・セットを選択します。ルール・セットの編集ページの「ルール」タブで、「編集」をクリックし、次の操作を行います。

1. 「作成...」をクリックします。

2. 「受信イベントおよびイベントの更新」を選択します。

3. 「続行」をクリックします。「新規ルールの作成 : イベントの選択」ダイアログが表示されます。

4. 「詳細な選択オプション」リージョンで、「原因分析の更新」を選択します。3つの原因イベント・オプションが表示されます。
イベントは原因としてマークされます: このターゲットに依存する他のターゲットが停止している場合、このターゲットの停止は原因とみなされます。

イベントは兆候としてマークされます: 依存するターゲットも停止している場合、停止中のターゲットは兆候とみなされます。

イベントは原因と兆候のどちらでもありません: ターゲットの停止は原因でも兆候でもありません。

1つ以上のオプションを選択することによって、余分なターゲットの停止イベントをフィルタ処理し、相互依存性のあるターゲットに関するターゲットの可用性イベントに焦点を当てることができます。兆候以外のイベントについてのみインシデントを作成するには、「イベントは原因としてマークされます」およびイベントは原因と兆候のどちらでもありませんを選択します。

「次」をクリックします。

5. 新規ルールの作成: アクションの追加ページで、「追加」をクリックします。条件付きアクションの追加ページが表示されます。

6. 「インシデントの作成またはインシデントの更新」リージョンで、「インシデントの作成」を選択します。

7. 残りの割当ておよび通知の詳細を指定して「続行」をクリックします。

8. 「ルール・セットの作成」ウィザード・ページの残りを完了します。ルール・セットの作成の詳細は、「ルール・セットの作成」を参照してください。

2.4.11.7 遅延時間の概要

前述のように、インシデント・マネージャのRCAは、受信するターゲットの停止イベントが継続的に評価され、原因分析の状態が更新される反復プロセスです。受信するターゲットの停止イベントに応じて、一定の時間(分)、根本原因は根本原因のままである場合も根本原因ではなくなる場合もあります。元のターゲットの停止イベントが、後で兆候として分類されることがあります。ターゲットの停止イベントが報告、分析され、それについてのアクション(インシデントの作成など)が実行される時間を見越すために、ルール・セットの作成時にイベント評価の遅延時間を定義できます。

前述の例では、ルールに遅延時間を設定せずに、兆候以外のイベントについてインシデントが作成されましたが、最終的に兆候になった兆候以外のイベントに作成されたインシデントが存在する可能性があります。

ルールに遅延時間を追加する手順:

1. 「ルール・セットの作成」ウィザードの「アクションの追加」ページから、「追加」または「編集」(既存のルールの変更)をクリックします。「条件付きアクションの追加」ページが表示されます。

2. 「アクションの条件」リージョンで、「指定された条件に一致する場合のみアクションを実行」を選択します。条件のリストが表示されます。

3. 「指定された期間の間オープン状態になっていたイベント」を選択します。

4. 必要な遅延時間を指定します。

5. 「続行」をクリックして、ウィザードの残りのステップを完了します。

2.5 Enterprise Manager 10/11gから12c以上への移行

Enterprise Manager 12c以上のインシデント管理機能では、12cの前から存在する即時利用可能なモニタリング設定を活用します。移行はシームレスで透過的です。たとえば、Enterprise Manager 10/11g監視システムが特定の監視条件に基づいて電子メールを送信する場合、中断なしでそれらの電子メールの受信を継続できます。ただし、12cの機能を利用するには、追加の移行タスクの実行が必要な場合があります。

重要:
12cより前に生成されたアラートも使用できます。たとえば、クリティカル・メトリック・アラートはクリティカル・インシデントとして使用可能です。

ルール

Enterprise Manger 12cに移行すると、既存のすべての通知ルールが自動的にルールに変換されます。技術的には、最初にイベント・ルールに変換され、各イベント・ルールに対してインシデントが自動的に作成されます。

一般に、イベント・ルールでは、どのイベントがインシデントになるかを定義できます。一方で、Enterprise Managerの強化された監視の柔軟性も利用できます。

ルールの移行の詳細は、次のドキュメントを参照してください。

- 付録Aの「Enterprise Manager Cloud Controlの通知の概要」、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』の通知ルールからルール・セットへの移行に関する項

- 『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』の第29章「ルールの更新」

権限の要件

エンタープライズ・ルール・セットおよびそれに含まれるルールの編集/作成には、リソース権限「エンタープライズ・ルール・セットの作成」が必要です。これに対する例外は、移行された通知ルールです。12cより前の通知ルールがイベント・ルールに移行されている場合、元の通知ルールの所有者は、「エンタープライズ・ルール・セットの作成」リソース権限を付与されていなくても自身のルールを編集できます。ただし、新規ルールを作成する場合は、「エンタープライズ・ルール・セットの作成」リソース権限が付与されている必要があります。Enterprise Managerのスーパー管理者は、デフォルトでルール・セットを編集および作成できます。

監視: 一般的なタスク

次の項で、インシデント/監視の設定および使用に関する一般的なタスクの操作例を示します。

- 「電子メール・ゲートウェイの設定」

- 「メトリック・アラートの電子メール送信」

- 「メトリック・アラートのSNMPトラップ送信」

- 「イベント・コネクタへのイベント送信」

- 「異なる期間での異なる電子メール・アドレスへの電子メール送信」

電子メール・ゲートウェイの設定

タスク

Enterprise Managerから管理者に電子メール通知を送信するには、組織内で利用可能な電子メール・ゲートウェイにアクセスする必要があります。次の手順で、指定した電子メール・ゲートウェイを使用するようにEnterprise Managerを構成します。

ユーザー・ロール

- Enterprise Manager管理者

前提条件

- ユーザーには、スーパー管理者権限が必要です。
詳細は、「通知用のメール・サーバーの設定」を参照してください。

次の手順を実行します。

1. 「設定」メニューから、「通知」、「通知メソッド」の順に選択します。

「通知メソッド」ページが表示されます。

2. 必要なパラメータを入力します。次に、有効なパラメータ値の例を示します。

- 送信メール(SMTP)サーバー - smtp01.example.com:587, smtp02.example.com

- ユーザー名 - myadmin

- パスワード - ******

- パスワードの確認 - ******

- 送信者ID - Enterprise Manager

- 送信者の電子メール・アドレス - mgmt_rep@example.com

- セキュアな接続を使用: いいえ: 電子メールは暗号化されません。SSL: 電子メールはSecure Sockets Layer protocolを使用して暗号化されます。使用可能な場合はTLS: メール・サーバーがTransport Layer Security(TLS)プロトコルをサポートしている場合、電子メールはTLSを使用して暗号化されます。サーバーがTLSをサポートしない場合、電子メールは自動的にプレーン・テキストで送信されます。

3. 指定した電子メール・ゲートウェイにEnterprise Managerが接続できることを確認します。「メール・サーバーのテスト」をクリックします。Enterprise Managerが成功/失敗メッセージを表示します。「OK」をクリックして、「通知メソッド」ページに戻ります。

4. Enterprise Managerが電子メール・ゲートウェイに正常に接続できることを確認したら、「適用」をクリックします。

これまでに実施したこと:

ここまでで、会社の電子メール・ゲートウェイを使用するようにEnterprise Managerを構成しました。Enterprise Managerは、管理対象の環境の状況を監視しながら、登録ユーザーに通知ができます。

次のステップ

「電子メール・アドレスの定義」

「通知スケジュールの設定」

「自分用の電子メールの設定」

「他の管理者のための電子メールの設定」

メトリック・アラートの電子メール送信

タスク

メトリック・アラートのしきい値に到達した時点で管理者に電子メールを送信するようにEnterprise Managerを構成します。この例では、CPU使用率が重大度「クリティカル」に到達してメトリック・アラートが発生したときに電子メール通知を送信します。

ユーザー・ロール

- ITオペレータ/マネージャ

- Enterprise Manager管理者

前提条件

- Enterprise Managerが管理者に電子メールを送信できるように電子メール・ゲートウェイを設定すること。
詳細は、「通知用のメール・サーバーの設定」を参照してください。

- CPU使用率のメトリックしきい値が設定されていること。

- ユーザーのEnterprise Managerアカウントに管理対象システムからのインシデントの管理に必要な適切な権限が付与されていること。
詳細は、「管理者および権限の設定」を参照してください。

- ユーザーのEnterprise Managerアカウントに通知プリファレンス(電子メールおよびスケジュール)が設定されていること。これはルールを作成および編集する管理者だけではなく、ルール・アクションの結果として通知されるユーザーにも必要です。
詳細は、「通知スケジュールの設定」を参照してください。

次の手順を実行します。

1. 「設定」メニューから、「インシデント」、「インシデント・ルール」の順に選択します。

2. 「ルール・セットの作成」をクリックします。

3. ルール・セットの名前および説明を入力します。

4. 「ターゲット」タブで、「ルール・セット所有者が表示できるすべてのターゲットです。」を選択します。

代替方法:
特定のターゲット/グループにルール・セットを適用します。
この例のすべてのターゲットにルール・セットを適用するように選択しましたが、特定のターゲットまたはグループにのみ適用することもできます。

手順は次のとおりです。

1. 「ターゲット」タブから、「特定のターゲット」を選択します。

2. 「追加」ドロップダウン・メニューから、「グループ」または「ターゲット」を選択します。

3. 「追加」をクリックします。ターゲットの選択ダイアログが表示されます。

4. ターゲット/グループの名前を検索するか、表から1つ選択します。

5. 対象のターゲット/グループを選択したら、「選択」をクリックします。ダイアログが閉じ、「特定のターゲット」リストにターゲットが表示されます。

5. 「ルール」タブで「作成」をクリックします。「作成するルールのタイプを選択」ダイアログが表示されます。

6. 「受信イベントおよびイベントの更新」を選択し、「続行」をクリックします。

7. 「イベント」ページで、ルールのアクションの基礎となるイベントの基準を設定します。この場合、ドロップダウン・リストから「メトリック・アラート」を選択します。

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

8. 「タイプ メトリック・アラートの特定のイベント」オプションを選択します。メトリック選択領域が表示されます。
この例では、CPU使用率が定義した「クリティカル」しきい値を大幅に超えた場合にのみ通知を送信します。

9. ドロップダウン・リストから重大度「クリティカル」を選択します。
「OK」をクリックします。

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

11. 「アクションの追加」にある「追加」をクリックして、ルールに適用するアクションを追加します。「通知」セクションで、通知を送信する電子メール・アドレスを入力します。「次」をクリックします。
複数の条件付きアクションを指定したり、追加した順番に順次(上から下に)評価できます。

代替方法:
メーリング・リストに電子メール通知を送信します。
電子メール・アドレスを指定する他に、定義済のEnterprise Manager管理者を指定できます。ユーザーのカテゴリ全体に通知するために、メール配信リストを指定することもできます。メーリング・リストを使用すると、個々のルール・セットを更新しなくても、通知の受信者を変更できます。

12. 「名称と説明の指定」ページに、ルールの名前と説明を入力します。「次へ」をクリックします。

13. 「確認」ページで詳細を確認し、「続行」をクリックします。

14. 「ルール・セットの作成」ページで「保存」をクリックします。

これまでに実施したこと:

ここまでで、CPU使用率が「クリティカル」メトリックしきい値に到達したとき、管理者の電子メールに通知を送信するという新しいルール・セットを作成しました。このルール・セットをサブスクラウブする手順の詳細は、「ルールからの電子メールを受信するためのサブスクライブ」を参照してください。

次のステップ

- 他の管理者のために電子メールの設定をする方法

- 電子メール・アドレスの追加/更新/削除、および通知スケジュールの定義

- 「単純なインシデントへの応答および処理」

メトリック・アラートのSNMPトラップ送信

タスク

SNMPトラップ経由でHPオープンビュー・コンソールにイベント情報(メトリック・アラートなど)を送信するようにEnterprise Managerを構成します。これには2つのフェーズがあります。

1. SNMPトラップを送信するための通知メソッドの作成

2. メトリック・アラートが発生したときにSNMPトラップを送信するインシデント・ルールの作成

ユーザー・ロール

- Enterprise Manager管理者

前提条件

- ユーザーには、スーパー管理者権限が必要です。
詳細は、「通知用のメール・サーバーの設定」を参照してください。

次の手順を実行します。

SNMPトラップに基づく通知メソッドの作成

1. 「設定」メニューから、「通知」、「通知メソッド」の順に選択します。

「通知メソッド」ページが表示されます。

2. 「追加」ドロップダウン・メニューから、「SNMPトラップ」を選択し、「実行」をクリックします。「SNMPトラップの追加」ページが表示されます。
SNMPマスター・エージェントが実行されているホスト(マシン)の名前およびその他の詳細を、次の図のように指定する必要があります。

次に、有効なパラメータ値の例を示します。

3. 「SNMPトラップのテスト」をクリックして、SNMPトラップ設定を検証します。Enterprise Managerが成功/失敗メッセージを表示します。「OK」をクリックして、「SNMPトラップの追加」ページに戻ります。

4. 「OK」をクリックして、「通知メソッド」ページに戻ります。

5. 「OK」をクリックして、新しいSNMPトラップ・ベースの通知メソッドを追加します。

メトリック・アラートが発生したときにSNMPトラップを送信するインシデント・ルールの作成

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

「インシデント・ルール - すべてのエンタープライズ・ルール」ページが表示されます。

2. 「インシデント・ルール: すべてのエンタープライズ・ルール」ページで「ルール・セットの作成...」をクリックします。「ルール・セットの作成」ページが表示されます。

3. ルール・セットの「名前」、簡単な「説明」を入力し、ルールの「適用先」(ターゲット)ソース・オブジェクトのタイプを選択します。

4. 「ルール」タブをクリックした後、「作成...」をクリックします。

5. 「作成するルールのタイプを選択」ダイアログで、「受信イベントおよびイベントの更新」を選択し、「続行」をクリックします。

6. 「イベント」ページで、ルールのアクションの基礎となるイベントの基準を設定します。この場合、ドロップダウン・リストから「メトリック・アラート」を選択します。

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

7. 「タイプ メトリック・アラートの特定のイベント」オプションを選択します。メトリック選択領域が表示されます。
この例では、CPU使用率が定義した「クリティカル」しきい値を大幅に超えた場合にのみ通知を送信します。

8. ドロップダウン・リストから重大度「クリティカル」を選択します。
「OK」をクリックします。

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

10. 新規ルールの作成: アクションの追加ページで、「追加」をクリックします。条件付きアクションの追加ページが表示されます。

11. 「通知」セクションの「拡張通知」で、既存のSNMPトラップ通知メソッドを選択します。
SNMPトラップの通知メソッドの作成については、「サード・パーティ・システムへのSNMPトラップの送信」を参照してください。

12. 「続行」をクリックし、新規ルールの作成: アクションの追加ページに戻ります。

13. 「次へ」をクリックし、新規ルールの作成: 名前と説明の指定ページに移動します。

14. ルール名および簡潔な説明を指定して、「次へ」をクリックします。

15. ルール定義を確認し、「続行」をクリックしてルールをルール・セットに追加します。ルールがルール・セットに追加されたがまだ保存されていないことを表すメッセージが表示されます。「OK」をクリックして、メッセージを閉じます。

16. 「保存」をクリックしてルール・セットを保存します。確認メッセージが表示されます。「OK」をクリックして、メッセージを閉じます。

これまでに実施したこと:

ここまでで、メトリック・アラート(%CPU使用率)が発生したときに、サード・パーティのシステムにSNMPトラップを送信するようにEnterprise Managerに指示するインシデント・ルール・セットを作成しました。

次のステップ

- 「ルールからの電子メールを受信するためのサブスクライブ」

- 「インシデントの検索」

イベント・コネクタへのイベント送信

タスク

コネクタを使用して、イベント情報をEnterprise ManagerからIBM Tivoli Netcool/OMNIbusに送信します。それには、IBM Tivoli Netcool/OMNIbus Connectorコネクタを起動するインシデント・ルールを作成する必要があります。

ユーザー・ロール

- システム管理者

- ITオペレータ

前提条件

- ユーザーには、「エンタープライズ・ルール・セットの作成」リソース権限と、少なくともイベントがNetcool/OMNIbusに転送されるターゲットに対する「表示」権限が必要です。
詳細は、「通知用のメール・サーバーの設定」を参照してください。

- IBM Tivoli Netcool/OMNIbusコネクタがインストール済で構成されている必要があります。
詳細は、Oracle® Enterprise Manager IBM Tivoli Netcool/OMNIbus Connectorのインストレーションおよび構成ガイドを参照してください。

次の手順を実行します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

「インシデント・ルール - すべてのエンタープライズ・ルール」ページが表示されます。

2. 「ルール・セットの作成」をクリックします。

3. ルール・セットの名前および説明を入力します。

4. 「ターゲット」タブで、「ルール・セット所有者が表示できるすべてのターゲットです。」を選択します。

特定のターゲット/グループにルール・セットを適用します。
この例のすべてのターゲットにルール・セットを適用するように選択しましたが、特定のターゲットまたはグループにのみ適用することもできます。
手順は次のとおりです。

1. 「ターゲット」タブから、「特定のターゲット」を選択します。

2. 「追加」ドロップダウン・メニューから、「グループ」または「ターゲット」を選択します。

3. 「追加」をクリックします。ターゲットの選択ダイアログが表示されます。

4. ターゲット/グループの名前を検索するか、表から1つ選択します。

5. 対象のターゲット/グループを選択したら、「選択」をクリックします。ダイアログが閉じ、「特定のターゲット」リストにターゲットが表示されます。

5. 「ルール」タブで「作成」をクリックします。「作成するルールのタイプを選択」ダイアログが表示されます。

6. 「受信イベントおよびイベントの更新」を選択し、「続行」をクリックします。

7. 「イベント」ページで、ルールのアクションの基礎となるイベントの基準を設定します。この場合、ドロップダウン・リストから「メトリック・アラート」を選択します。

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

8. 「タイプ メトリック・アラートの特定のイベント」オプションを選択します。メトリック選択領域が表示されます。
この例では、CPU使用率が定義した「クリティカル」しきい値を大幅に超えた場合にのみ通知を送信します。

9. ドロップダウン・リストから重大度「クリティカル」を選択します。
「OK」をクリックします。

10. 「次」をクリックします。アクションの追加ページが表示されます。

11. 「追加」をクリックします。条件付きアクションの追加ページが表示されます。

12. 「イベント・コネクタに転送」セクションにリストされている1つ以上のコネクタ・インスタンスを選択し、「>」ボタンをクリックして、コネクタを「選択したコネクタ」リストに追加してから、「続行」をクリックします。「アクションの追加」ページが再度表示され、新しい処理がリストされます。

13. 「次」をクリックします。「名前と説明の指定」ページが表示されます。

14. ルールの名前と説明を入力し、「次」をクリックします。確認ページが表示されます。

15. すべて正しく表示されたら、「続行」をクリックします。
ルールが正しいルール・セットに追加されたことを示す情報ポップアップが表示されます。新しく追加されたルールは、「保存」ボタンをクリックするまで保存されないことも示されます。

必要に応じて、「戻る」をクリックしてルールを修正することもできます。

これまでに実施したこと:

ここまでで、メトリック・アラートが発生したときにIBM Tivoli Netcool/OMNIbus Connectorコネクタを起動するルールを作成しました。

次のステップ

「ルールからの電子メールを受信するためのサブスクライブ」

異なる期間での異なる電子メール・アドレスへの電子メール送信

タスク

あなたの企業の世界各地にあるIT部門は24時間365日稼働しています。サポート業務は、時間によって世界中の異なるデータ・センターがローテーションで担当します。Enterprise Managerが電子メール通知を送信すると、稼働中(通常の出勤日)の管理者に送信され、時間によって送信先が変わります。

Enterprise Managerからの通知を処理する管理者は次の4つです。

- ADMIN_ASIA

- ADMIN_EU

- ADMIN_UK

- ADMIN_US

通知を、通常の稼働時間にある特定の管理者に送信します。

ユーザー・ロール

- システム管理者

- ITオペレータ

前提条件

- 電子メール・アドレスは、電子メール通知の送信先とするすべての管理者用に定義されています。
詳細は、「電子メール・アドレスの定義」を参照してください。

- スーパー管理者権限が必要です。

- 電子メール通知を受信するすべての管理者が定義済である必要があります。

次の手順を実行します。

1. 「設定」メニューから、「通知」、「通知スケジュール」の順に選択します。
通知スケジュール・ページが表示されます。

2. 編集する通知スケジュールを所有する管理者を指定し、「変更」をクリックします。選択された管理者の通知スケジュールが表示されます。使用可能な管理者のリストは、検索アイコン(拡大鏡)をクリックできます。

3. 「スケジュール定義の編集」をクリックします。スケジュール定義の編集: 期間ページが表示されます。デフォルトで「既存のスケジュールの編集」オプションが選択されます。必要に応じて、ローテーション・スケジュールを変更します。

4. 「続行」をクリックします。スケジュール定義の編集: 電子メール・アドレス・ページが表示されます。

5. スケジュール定義の編集: 電子メール・アドレス・ページ上の指示に従って、必要に応じて管理者の通知スケジュールを調整します。

6. 選択された管理者の通知スケジュールの変更が行われた後、「終了」をクリックします。通知スケジュール・ページに戻ります。

7. すべての4つの管理者の通知スケジュールが通常の仕事日と同期化するまで、各管理者に対してこのプロセス(手順2から6)を繰り返します。

これまでに実施したこと:

世界の別のタイムゾーンの管理者に割り当てられた作業時間中にのみアラート通知が送信される通知スケジュールを作成しました。

次のステップ

「ルールからの電子メールを受信するためのサブスクライブ」

3 通知の使用

通知システムによって、特定のインシデント、イベントまたは問題が発生したときにEnterprise Manager管理者に通知できます。

注意:
この章では、インシデント管理に精通していることを前提とします。インシデント管理を介したITインフラストラクチャの監視と管理の詳細は、第2章「インシデント管理の使用」を参照してください。

管理フレームワークの重要な部分として、通知は、特定のインシデント、イベントまたは問題の発生時にオペレーティング・システム・コマンド(スクリプトを含む)やPL/SQLプロシージャの実行などのアクションも実行できます。この機能により、ITプラクティスを自動化できます。たとえば、インシデント(データベースの動作(稼働/停止)ステータスの監視など)が発生したときに、通知システムによってOSスクリプトを介して社内のトラブル・チケットを自動的に開き、担当のITスタッフが適時に応答できるようにします。

また、Enterprise Managerの通知システムでは、Simple Network Management Protocol(SNMP)トラップを使用して、HP OpenViewなどのSNMP対応サード・パーティ・アプリケーションにEnterprise Managerで発行されたイベントのトラップを送信できます。一部の管理者は、特定のメトリックがしきい値を超えた時点でサード・パーティ・アプリケーションに通知を送信する場合があります。

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

- 通知の設定

- 電子メール以外の通知の拡張

- OSコマンドおよびスクリプトを使用した通知の送信

- PL/SQLプロシージャを使用した通知の送信

- サード・パーティ・システムへのSNMPトラップの送信

- 管理情報ベース(MIB)

- 修正処理ステータス変更情報の受渡し

- ジョブ実行ステータス情報の受渡し

- ユーザー定義のターゲット・プロパティの通知メソッドへの受渡し

- 通知に関するトラブルシューティング

- EMOMSプロパティ

- OSコマンドまたはスクリプトへのイベント、インシデント、問題情報の受渡し

- PL/SQLプロシージャへの情報の受渡し

3.1 通知の設定

すべてのEnterprise Manager管理者は、各自の電子メール通知を設定できます。スーパー管理者は、他のEnterprise Manager管理者の通知も設定できます。

3.1.1 通知用のメール・サーバーの設定

Enterprise Managerで電子メール通知の送信を行うには、あらかじめ、通知システムで使用する送信メール(SMTP)サーバーを指定する必要があります。設定後は、自分の電子メール通知を定義できます。スーパー管理者権限を持っている場合は、他のEnterprise Manager管理者の通知も定義できます。

送信メール(SMTP)サーバーは、「通知メソッド」ページで指定します。「通知メソッド」ページを表示するには、「設定」メニューから、「通知」、「メール・サーバー」の順に選択します。

注意:
Enterprise Managerの通知システムを構成するには、スーパー管理者権限が必要です。このような権限には、次のものがあります。

- SMTPサーバーの設定

- 通知メソッドの定義

- 通知電子メール形式のカスタマイズ

1つ以上の送信メール・サーバー名、(必要な場合は)メール・サーバー認証資格証明(「ユーザー名」、「パスワード」および「パスワードの確認」)、通知メッセージの送信者として表示する名前、および電子メール通知の送信に使用する電子メール・アドレスを指定します。送信者のメール・アドレスと呼ばれるこのアドレスは、指定する各メール・サーバー上で有効なアドレスである必要があります。電子メール通知の送信時に問題が発生した場合は、この電子メール・アドレスにメッセージが送信されます。例3-1は通知メソッド・エントリの例を示しています。

例3-1 メール・サーバーの設定

- 送信メール(SMTP)サーバー - smtp01.example.com:587, smtp02.example.com

- ユーザー名 - myadmin

- パスワード - ******

- パスワードの確認 - ******

- 送信者ID - Enterprise Manager

- 送信者の電子メール・アドレス - mgmt_rep@example.com

- セキュアな接続を使用: いいえ: 電子メールは暗号化されません。SSL: 電子メールはSecure Sockets Layer protocolを使用して暗号化されます。使用可能な場合はTLS: メール・サーバーがTransport Layer Security(TLS)プロトコルをサポートしている場合、電子メールはTLSを使用して暗号化されます。サーバーがTLSをサポートしない場合、電子メールは自動的にプレーン・テキストで送信されます。

注意:
このページで指定する電子メール・アドレスは、通知の送信先の電子メール・アドレスではありません。この電子メール・アドレス(通知の送信先)は「パスワード」および「電子メール」ページで指定する必要があります。「設定」メニューから、「プリファレンス」、「Enterprise Managerのパスワードおよび電子メール」の順に選択します。
標準的な使用方法として、各ユーザーは独自の電子メール・アドレスを持つ必要があります。

電子メール・サーバーの構成後、「メール・サーバーのテスト」をクリックして電子メール設定を検証します。「送信者の電子メール・アドレス」フィールドで指定した電子メール・アカウントで、電子メール・メッセージが受信されていることを確認する必要があります。

複数のメール・サーバーを定義すると、電子メール通知配信の信頼性が向上します。少なくとも1つの電子メール・サーバーが稼働している場合は、電子メール通知が配信されます。通知の負荷はOMSによって複数の電子メール・サーバーに分散され、20通の電子メールが送信された後でOMSがこれらのサーバーを切り替えます(サーバーは可用性に従って割り当てられます)。切替えは、oracle.sysman.core.notification.emails_per_connection emomsプロパティで制御されます。

SLB使用時のCloud ControlコンソールURLの設定

サーバー・ロード・バランサ(SLB)がOMSインスタンス用に構成された複数OMS環境がある場合、Enterprise Managerからの電子メールが、電子メールの発信元である特定のOMS URLではなく、SLB URLを介してEnterprise Managerコンソールにユーザーを向けるように、コンソールURLを更新する必要があります。

コンソールURLを変更する手順:

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。管理サービスとリポジトリ・ページが表示されます。

2. 管理サービスとリポジトリ・ページの「概要」セクションで、「コンソールURL」ラベルの「追加/編集」をクリックします。

コンソールURLページが表示されます。

3. コンソールURLをSLB URLに変更します。
次に例を示します。

http://www.example.com

https://www.example.com:4443.

パス(一般的に/em)は指定しないでください。

4. 「OK」をクリックします。

3.1.2 自分用の電子メールの設定

電子メールで通知を受信するには、「パスワード」および「電子メール」ページ(「設定」メニューから、「プリファレンス」、「Enterprise Managerのパスワードおよび電子メール」の順に選択)で自分の電子メール・アドレスを指定する必要があります。通知用の電子メール・アドレスを定義するのみでなく、電子メール・アドレスで使用する通知メッセージ形式(長い、短い、ページャ)を関連付けます。

電子メールを設定するには、次の3つの手順を実行します。

手順1: 電子メール・アドレスの定義。

手順2: 通知スケジュールの設定

手順3: 電子メールを受信するためのインシデント・ルールのサブスクライブ。

3.1.2.1 電子メール・アドレスの定義

電子メール・アドレスには最大128文字を使用できます。電子メール・アドレスの数の上限はありません。

電子メール・アドレスを追加するには:

1. 「ユーザー名」ドロップダウン・メニューから、「Enterprise Managerのパスワードおよび電子メール」を選択します。

2. 「行の追加」をクリックすると、新規の電子メール・エントリ・フィールドが「電子メール・アドレス」表に作成されます。

3. Enterprise Managerアカウントに関連付けられている電子メールを指定します。指定する電子メール・アドレスには、Enterprise Managerからのすべての電子メール通知が送信されます。
たとえば、user1@myco.comなどになります。

電子メール・アドレスの「電子メール・タイプ」(メッセージ形式)を選択します。「電子メール(長い形式)」では、詳細情報を含むHTML形式の電子メールが送信されます。例3-2は、長い書式を使用する一般的な通知を示します。

「電子メール(短い形式)」と「ページャ(短い形式)」(例3-3)は、構成可能な文字数に制限された短いテキストの電子メールを送信するため、電子メールをSMSメッセージまたはページャとして受信できます。メッセージの内容は、すべて件名またはすべて本文に入れるか、または表題と本文に分割して送信できます。

たとえば、最後のケースでは、件名には重大度タイプ(「クリティカル」など)とターゲット名が含まれます。本文には、重大度の発生時刻と重大度メッセージが含まれます。メッセージの長さは制限されているため、この情報の一部が切り捨てられることがあります。切り捨てられた場合、メッセージの最後は省略記号になります。「ページャ(短い形式)」アドレスは、インシデント・ルールでページャ機能をサポートするために使用されます。インシデント・ルールで、ルールの作成者は、一部のユーザーがクリティカルな問題のページャを受け取るように指定できます。

4. 「適用」をクリックして電子メール・アドレスを保存します。

例3-2 メトリック・アラート用の長い電子メール通知

Target type=Host Target name=machine6140830.example.com Message=Filesystem / has 54.39% available space, fallen below warning (60) or critical (30) threshold. Severity=Warning Event reported time=Apr 28, 2011 2:33:55 PM PDT Event Type=Metric Alert Event name=Filesystems:Filesystem Space Available (%) Metric Group=FilesystemsMetric=Filesystem Space Available (%)Metric value=54.39Key Value=/Key Column 1=Mount PointRule Name=NotifRuleSet1,Event rule1 Rule Owner=SYSMAN

例3-3 アラート用の短い書式の電子メール通知

Subject is :
EM:Unreachable Start:myhost
Body is :
Nov 16, 2006 2:02:19 PM EST:Agent is Unreachable (REASON = Connection refused)
but the host is UP

「電子メール(短い形式)」および「ページャ(短い形式)」形式の詳細

Enterprise Managerでは、ページングやSMSなどのメッセージ・サービスを直接はサポートしていませんが、かわりに外部のゲートウェイを使用し、電子メールからページへの変換などを実行しています。Enterprise Manager 12c以上では、通知システムで、ページまたは電子メールとして電子メール・アドレスを明示的にタグ付けできるようになりました。この2つの通知方法の明示的なシステムの違いにより、インシデント・ルールの複数アクション機能を利用できます。たとえば、電子メールとページの違いは、イベント重大度が警告の場合に電子メールを送信し、重大度がクリティカルの場合にページを表示する場合に必要です。この機能をサポートするために、短い形式の電子メールの省略バージョンを送信するページャ形式が使用可能になりました。

注意:
ページャを受け取るには、「インシデント・ルール」の「ページ通知」オプションに管理者を追加する必要があります。

3.1.2.2 通知スケジュールの設定

電子メール通知アドレスの定義後、通知スケジュールを定義する必要があります。たとえば、電子メール・アドレスがuser1@myco.com、user2@myco.comおよびuser3@myco.comの場合、通知スケジュールの各期間について、これらの電子メール・アドレスの中から1つ以上を選択して使用できます。ユーザー・プリファレンス(「Enterprise Managerのパスワードおよび電子メール」ページ)で指定した電子メール・アドレスのみを通知スケジュールで使用できます。

注意:
最初に電子メール・アドレスを入力すると、常時毎週の通知スケジュールが自動的に設定されます。監視要件に合わせてこのスケジュールを確認し、変更できます。

通知スケジュールとは、コール時スケジュール(Enterprise Managerにより通知の送信に使用される期間および電子メール・アドレス)を指定するときに使用する反復スケジュールです。各管理者には、通知スケジュールが1つのみ存在します。管理者に通知を送信する必要がある場合、Enterprise Managerにより管理者の通知スケジュールが参照され、使用する電子メール・アドレスが決定されます。スーパー管理者であるか、通常のEnterprise Manager管理者であるかによって、通知スケジュールを定義するプロセスは若干異なります。

通常のEnterprise Manager管理者が自分の通知スケジュールを定義する手順は、次のとおりです。

1. 「設定」メニューから、「通知」、「通知スケジュール」の順に選択します。

2. 「通知スケジュール」ページの指示に従い、電子メールを受け取る時刻を指定します。

3.1.2.3 インシデント・ルールの電子メールを受信するようにサブスクライブ

インシデント・ルールとは、インシデントを構成する特定のイベントについて通知を送信する基準を指定する、ユーザー定義のルールです。インシデント・ルール・セットは、名前が示すように、同じインシデントに関連付けられている1つ以上のルールから構成されます。

インシデント・ルールの作成時に、関心のあるターゲット、ルールを適用するイベントのタイプなどの基準を指定します。具体的に、指定されたルールでは、対象となる基準と、これらの通知の送信に使用する通知メソッド(電子メールなど)を指定できます。たとえば、データベースが停止した場合やデータベース・バックアップ・ジョブが失敗した場合に、電子メールが送信され、ログ・トラブル・チケット通知メソッドがコールされるようなルールを設定できます。または、ホストのCPUまたはメモリー使用率がクリティカル重大度に到達した場合に、SNMPトラップが他の管理コンソールに送信されるルールを定義することもできます。単一のルールで、特定の条件に基づく複数のアクションを実行できるという事実により、通知の柔軟性がさらに向上します。例: マシンのメモリー使用状況などの条件をモニタリングする場合、警告のインシデント重大度(メモリー使用率が80%)に対して管理者に電子メールを送信し、重大度がクリティカル(メモリー使用率が99%)の場合は管理者に即時にページを表示します。

すでに作成したルールをサブスクライブできます。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. インシデント・ルール - すべてのエンタープライズ・ルール・ページで、該当するインシデントのエスカレーション・ルールを含むルール・セットをクリックし、「編集」をクリックします。ルールはルール・セットのコンテキストで作成されます。
注意: 既存のルール・セットがない場合は、「ルール・セットの作成」をクリックしてルール・セットを作成します。次に、ルール・セットの作成の一環としてルールを作成します。

3. ルール・セットの編集ページの「ルール」セクションで、変更するエスカレーション・ルールをハイライトして「編集」をクリックします。

4. アクションの追加ページに移動します。

5. インシデントをエスカレートするアクションを選択し、「編集」をクリックします。

6. 「通知」セクションで、「電子メールCC」リストにDBAを追加します。

7. 「続行」をクリックしてルール・セットの編集ページに戻り、「保存」をクリックします。

即時利用可能なインシデント・ルール

Enterprise Managerには、最も一般的な監視条件に対応する次の2つのインシデント・ルール・セットが付属しています。

- すべてのターゲットのインシデント管理ルールセット

- 自己更新のイベント管理ルールセット

即時利用可能なインシデント・ルールで定義された条件が要件を満たす場合は、前の項で説明したサブスクライブ手順を使用して、ルールに定義されている条件の電子メール通知を受信するようにサブスクライブできます。

すべてのターゲットに設定されている即時利用可能なインシデント・ルールは、デフォルトで警告アラートの電子メールを生成しません。

独自のインシデント・ルールの作成

独自のカスタム・ルールを定義できます。次の手順では、スーパー管理者ではない管理者がインシデント・ルールを作成するプロセスを説明します。

独自のインシデント・ルールを作成する手順は、次のとおりです。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。
インシデント・ルール・ページが表示されます。このページから、新しいルールを追加できる新しいルール・セットを作成できます。または、必要な権限がある場合は、新しいルールを既存のルール・セットに追加できます。

2. 「ルール・セットの作成...」をクリックします。
ルール・セットの作成ページが表示されます。

3. 「名前」、「説明」およびルール・セットを適用する「ターゲット」を指定します。

4. 「ルール」タブをクリックし、「作成」をクリックします。

5. ルールを適用する着信インシデント、イベントまたは問題を選択します。詳細は、「ルール・セットの設定」を参照してください。

6. 「続行」をクリックします。
Enterprise Managerに、インシデント・ルールの作成ページが表示されます。各ページで、インシデント・ルールの作成に必要な情報を入力します。

7. ウィザードの指示に従ってルールを作成します。
ルールの定義が完了すると、ルール・セットの作成ページに戻ります。

8. 「保存」をクリックしてインシデント・ルール・セットを保存します。

3.1.3 他の管理者のための電子メールの設定

スーパー管理者権限を持っている場合は、他のEnterprise Manager管理者のために電子メール通知を設定できます。他のEnterprise Manager管理者のために電子メール通知を設定するには、次の手順を実行する必要があります。

手順1: 各管理者アカウントに電子メール・アドレスが関連付けられていることの確認

電子メール通知の送信宛先の各管理者は、有効な電子メール・アドレスを持っている必要があります。

1. 「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。

2. 管理者ごとに、電子メール・アドレスを定義します。これにより、指定されたすべての電子メール・アドレスを使用するこのユーザー向けに常時通知スケジュールが設定されます。デフォルトでは、これにより、タイプが電子メール(長い形式)に設定された電子メールIDが追加されます。ここでは「電子メール・タイプ」オプションを指定することはできません。

Enterprise Managerでは、管理者の通知スケジュールを編集する際に、管理者のアドレスも指定できます。

手順2: 管理者の通知スケジュールの定義

各管理者の電子メール通知アドレスを定義後、それぞれの通知スケジュールを定義する必要があります。初めて電子メール・アドレスを指定した際には、デフォルトの常時通知スケジュールが作成されますが、通知スケジュールの内容を再確認し、必要に応じて編集する必要があります。

1. 「設定」メニューから、「通知」、「通知スケジュール」の順に選択します。
垂直ナビゲーション・バーの「スケジュール」をクリックします(「通知」の下にあります)。「通知スケジュール」が表示されます。

2. 編集する通知スケジュールを所有する管理者を指定し、「変更」をクリックします。

3. 「スケジュール定義の編集」をクリックします。スケジュール定義の編集: 期間ページが表示されます。必要に応じて、ローテーション・スケジュールを変更します。

4. 「続行」をクリックします。「スケジュール定義の編集: 電子メール・アドレス」ページが表示されます。

5. 「スケジュール定義の編集: 電子メール・アドレス」ページ上の指示に従って、通知スケジュールを変更します。

6. 終了後、「終了」をクリックします。

7. 管理者ごとに、手順3から手順7までを繰り返します。

手順3: 管理者へのインシデント・ルールの割当て

通知スケジュールを設定後、指定した管理者ごとに適切なインシデント・ルールを割り当てる必要があります。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. 目的の「ルールセット」を選択し、「編集」をクリックします。

3. 「ルール」タブをクリックし、目的のルールを選択して「編集」をクリックします。

4. 「アクションの追加」をクリックし、目的のアクションを選択して「編集」をクリックします。

5. 「基本通知」リージョンの「電子メール宛先」または「電子メールCC」フィールドに管理者名を入力します。

6. 「続行」、「次へ」、「次へ」、「続行」の順にクリックし、最後に「保存」をクリックします。

3.1.4 電子メールのカスタマイズ

Enterprise Managerでは、スーパー管理者は、すべてのイベント、インシデント、問題、およびインストールされている特定のイベント・タイプに対して、グローバルな電子メール通知をカスタマイズできます。「デフォルト・イベント電子メール・テンプレート」をカスタマイズすることで、すべてのイベントのデフォルトの動作を変更できます。また、イベント・タイプのテンプレートをカスタマイズすることで、特定のイベント・タイプの動作をさらにカスタマイズできます。たとえば、メトリック・アラート・イベント・タイプのメトリック・アラート・イベント・テンプレートをカスタマイズできます。スーパー管理者は、簡単なスクリプトで事前定義済の基本要素(属性とラベル)を使用して様々な情報コンテンツを選択し、アラートの電子メールをカスタマイズできます。

電子メールをカスタマイズするには、次の操作を実行します。

1. 「設定」メニューから、「通知」、「電子メール形式のカスタマイズ」の順に選択します。

2. 「タイプ」および「形式」を選択します。

3. 「カスタマイズ」をクリックします。電子メール・テンプレートのカスタマイズ・ページが表示されます。

電子メール・テンプレートのカスタマイズ・ページから、Enterprise Managerが電子メール通知の生成に使用する電子メール・テンプレートの内容を変更できます。「電子メール・テンプレートの編集」ページからは、組込みのアシスタントやオンライン・ヘルプを利用して、スクリプトの書式設定、構文およびオプションに関する広範囲な情報を参照できます。

3.1.4.1 電子メールのカスタマイズのリファレンス

次のリファレンスでは、電子メールを定義するために使用される、疑似言語の語義およびコンポーネントの構文を簡潔に示します。疑似言語により、電子メール通知をカスタマイズするための単純な、ただし柔軟な方法が提供されます。次に、疑似言語の変換/制限のサマリーを示します。

- --で始まる個別の行を使用して、コメント(または任意の自由形式テキスト)を追加できます。コメントは、行の終わりに付加することもできます。

- 属性を使用できます。

- IF、ELSE、ENDIF制御構造を使用できます。ANDまたはORによって、複数の条件を使用することもできます。ネストされたIF文はサポートされていません。

- 書式設定の目的でスペースを挿入できます。実際の電子メールでは、行頭のスペースは無視されます。行頭にスペースを挿入するには、[SP]属性を使用します。

- エスケープするには/を使用し、属性名、演算子またはIF句を追加するには、[または]を使用します。

- HTMLはサポートされません。

予約語および予約演算子

次の表に、電子メール・スクリプトの変更で使用されるすべての予約語と予約演算子を示します。

表3-1 予約語および予約演算子

予約語および予約演算子

説明

IF、ELSIF、ENDIF、ELSE

IF-ELSE構造の中で使用されます。

AND、OR

ブール演算子 - IF-ELSE構造でのみ使用されます。

NULL

属性に関して、NULL値をチェック - IF-ELSE構造でのみ使用されます。

|

パイプ演算子 - 属性のリスト内で最初の非NULL値を示すのに使用されます。

次に例を示します。

METRIC_NAME|SEVERITY

EQ、NEQ

EqualおよびNot-Equal演算子 - NULL、STRING、NUMERIC値に適用できます。

/

エスケープ文字 - 予約語および予約演算子をエスケープするのに使用します。エスケープ文字は、それに続く文字が別の意味で解釈されることを表します。

[ , ]

区切り文字は、属性名とIF節の境界を決定します。

構文の要素

リテラル・テキスト

電子メールのコンテンツの一部としてテキストを指定できます。このテキストは電子メールに表示されますが、Oracle Management Services (OMS)の言語設定が変更されていると、翻訳はされません。たとえば、my Oracle Homeは、生成された電子メールの中では、my Oracle Homeと表示されます。

事前定義された属性

事前定義された属性/ラベルは、特定のコンテキストで実際の値に置き換えられます。事前定義された属性/ラベルを指定するには、次の構文を使用します。

[PREDEFINED_ATTR]

属性名は、大文字でも小文字でも構いません。構文解析のプロセスでは、大/小文字が区別されません。

一組の大カッコを使用して、事前定義された属性とリテラル・テキストとを区別します。たとえば、ジョブの電子メール通知の場合、実際のジョブ名は[EXECUTION_STATUS]で置き換えられます。メトリック・アラート通知の場合、[METIRC_COLUMN]は実際のメトリック列の名前で置換されます。

エスケープ文字/を使用して、単語を指定し、それらを事前定義されたラベル/属性として解釈されないようにできます。たとえば、/[NEW/]は、解釈される際、事前定義された属性である[NEW]とはみなされません。

演算子

EQ、NEQ - テキストおよび数値に使用します。

NULL: テキストおよび数値に使用します。

GT、LT、GE、LE - 数値に使用します。

制御構造

次の表に、使用可能なスクリプト制御構造を示します。

表3-2 制御構造

制御構造

説明

パイプ|

2つ以上の属性を|文字で区切ることができます。次に例を示します。

[METRIC_NAME|SEVERITY]

この例では、現在のアラート・コンテキスト内で使用可能な属性のみが実際の値に置換され、電子メールで使用されます。複数の属性が該当する場合、一番左の属性のみが使用されます。

IF

テキスト・ブロックが条件文になります。1レベルのIFおよびELSIFのみサポートされます。ネストされたIF構造はサポートされていません。

NULL値にEQ/NEQ演算子を使用すると、IFまたはELSIF評価ですべての属性が使用できます。他の演算子は、SEVERITYとREPEAT_COUNTでのみ使用可能です。

IFブロック内では、値を引用符" "で囲む必要があります。Enterprise Managerは、EQ、およびand、orなどその他のキーワードの位置に基づいて属性名およびその値を抽出します。次に例を示します。

[IF REPEAT_COUNT EQ ”1” AND SEVERITY EQ ”CRITICAL” THEN]

前述の文は、アラートの属性が次の条件に一致する場合に真になります。

- 属性名: REPEAT_COUNT

- 属性値: 1

- 属性名: SEVERITY

- 属性値: CRITICAL

IFブロックの例:

[IF EXECUTION_STATUS NEQ NULL]
[JOB_NAME_LABEL]=[EXECUTION_STATUS]
[JOB_OWNER_LABEL]=[JOB_OWNER]
[ENDIF]

[IF SEVERITY_CODE EQ CRITICAL ]
[MTRIC_NAME_LABEL]=[METRIC_GROUP]
[METRIC_VALUE_LABEL]=[METRIC_VALUE]
[TARGET_NAME_LABEL]=[TARGET_NAME]
[KEY_VALUES]
[ENDIF]

IFとELSEIFブロックの例:

[IF SEVERITY_CODE EQ CRITICAL]           statement1[ELSIF SEVERITY_CODE EQ WARNING]           statement2[ELSIF SEVERITY_CODE EQ CLEAR]           statement3[ELSE]           statement4[ENDIF]

コメント

1行のテキストの先頭に、ハイフンを2つ(--)付加することによって、スクリプトにコメントを追加できます。次に例を示します。

-- Code added on 8/3/2009     [IF REPEAT_COUNT NEQ NULL]     . . .

コメントは、テキスト行の最後にも配置できます。

[IF SEVERITY_SHORT EQ W] -- for Warning alert

カスタマイズの内容に含まれるHTMLタグ

HTMLタグの使用はサポートされません。

Enterprise Managerでは、電子メール・スクリプトを解析する際、HTMLタグに含まれる<および>の文字をエンコードした形式(&lt;および&gt;)に変換します。これにより、宛先のシステムでは、HTMLタグがHTMLとして扱われなくなります。

例

電子メールのカスタマイズ・テンプレート・スクリプトでは、次の3つの主要な演算子をサポートします。

- 比較演算子: EQ/NEQ/GT/LT/GE/LE論理演算子: AND/ORパイプライン演算子: |

3.1.5 繰返し通知の設定

繰返し通知を使用すると、インシデントが通知されるか、「繰返し通知の最大数」の値に到達するまで、繰り返し通知できます。Enterprise Managerでは、すべての通知メソッド(電子メール、OSコマンド、PL/SQLプロシージャおよびSNMPトラップ)向けの繰返し通知をサポートします。

繰返し通知のグローバル構成

通知メソッドで繰返し通知を(グローバルに)有効にするには、「通知メソッド」ページの「繰返し通知の送信」オプションを選択します。繰返し通知の最大回数の設定に加えて、通知送信の時間間隔も設定できます。

重要:
Oracleデータベース・バージョン10以上では、aq_tm_processes init.oraパラメータを変更しないことをお薦めします。ただし、このパラメータを変更する必要がある場合は、繰返し通知機能の値を1以上にする必要があります。Enterprise Managerリポジトリ・データベース・バージョンが9.2の場合は、aq_tm_processes init.oraパラメータを少なくとも1に設定して、繰返し通知の機能を有効化します。

インシデント・ルールを通じた繰返し通知の構成

通知メソッド・レベルでグローバルに繰返し通知を設定する場合、柔軟性が不十分な可能性があります。たとえば、イベント・タイプに基づいて異なる繰返し通知設定を使用する場合などが考えられます。Enterprise Managerでは、個別のインシデント・ルール・セットまたはルール・セット内の個別のルールに繰返し通知を設定することでこれを実現します。ルール・レベルで設定した繰返し通知は、通知メソッド・レベルで定義されたものより優先されます。

重要:
繰返し通知は、「繰返し通知の送信」オプションが「通知メソッド」ページで有効化されている場合のみ送信されます。

電子メール以外の繰返し通知

電子メール以外の繰返し通知(PL/SQL、OSコマンドおよびSNMPトラップの通知メソッド)では、各メソッドを有効にして繰返し通知をサポートする必要があります。新しい通知メソッドを追加、または既存のメソッドを編集する際に、「繰返し通知のサポート」オプションを選択できます。

3.2 電子メール以外の通知の拡張

通知メソッドは、通知が送信されるメカニズムです。Enterprise Managerスーパー管理者は、電子メール通知メソッドを構成することで電子メール通知を設定できます。多くの場合、これはOracle Management Serviceのインストールの一環としてすでに設定されています。

Enterprise Managerスーパー管理者は、他のカスタム通知メソッドを定義することもできます。たとえば、イベント通知をサード・パーティのトラブル・チケット・システムに転送することが必要な場合があります。サード・パーティのトラブル・チケット・システムへのAPIが使用可能であると想定した場合、カスタム通知メソッドを作成して、適切なAPIを持つカスタムOSスクリプトをコールできます。カスタム通知メソッドは、「トラブル・チケットのログ」など、ユーザーフレンドリな形式で名前を付けることができます。カスタム・メソッドが定義されると、管理者は、トラブル・チケット・システムにアラートを送信する必要があるたびに、「トラブル・チケットのログ」というグローバルに使用可能な通知を呼び出すのみで済みます。

カスタム通知メソッドは、カスタムOSスクリプトまたは任意のカスタムPL/SQLプロシージャに基づいて、またはSNMPトラップを送信することで定義できます。4番目のタイプの通知メソッド(Javaコールバック)は、Oracle内部機能をサポートするために存在し、Enterprise Manager管理者が作成または編集することはできません。

「OSコマンド」、「PL/SQL」および「SNMPトラップ」の通知メソッドを定義できるのはスーパー管理者のみです。ただし、Enterprise Managerの管理者は誰でも、(スーパー管理者が定義した)これらの通知メソッドをインシデント・ルールにアクションとして追加できます。

「通知メソッド」ページでは、次の内容を実行できます。

- インシデント・ルールを使用した電子メール通知を送信する場合の、送信メール・サーバーの設定

- OSおよびPL/SQLスクリプトとSNMPトラップを使用した、他のカスタム通知メソッドの作成。

- グローバルな繰返し通知の設定

3.3 OSコマンドおよびスクリプトを使用した通知の送信

通知システムは、インシデント・ルールがOSコマンド拡張通知アクションと一致した場合にカスタム・スクリプトを呼び出すことができます。カスタム・スクリプトは、環境変数を通じて、一致するイベント、インシデントおよび問題の通知を受信します。

環境変数の値の長さは、デフォルトで512文字に制限されています。デフォルト制限を変更するには、oracle.sysman.core.notification.oscmd.max_env_var_lengthという名前のemomsプロパティを構成します。

重要:
OSコマンドに基づく通知メソッドは、スーパー管理者権限を持つ管理者が構成する必要があります。

OSコマンド・スクリプトを実行すると、次のようになります。
通知を受信するために「sudo」などのOSコマンドを実行すると、コマンドにはOMSアカウントの読取り権限がないため失敗します。OMSアカウントには、通知を送信するためにOSコマンドに対する読取り権限が必要です。
権限の問題を解決するには、コマンドをOMS管理者アカウントが読取り可能なラッパー・スクリプトに埋め込みます。コマンドがラッパー・スクリプトに含まれたら、OSコマンドのかわりにこのスクリプトを指定します。

カスタム・スクリプトの登録

カスタム・スクリプトを使用するには、最初にそのスクリプトを通知システムに登録する必要があります。これは、次の4つの手順で実行します。

1. OSコマンドまたはスクリプトを定義します。

2. 各管理サービス・ホスト上にスクリプトをデプロイします。

3. OSコマンドまたはスクリプトを新規の通知メソッドとして登録します。

4. 通知メソッドをインシデント・ルールに割り当てます。

手順1: OSコマンドまたはスクリプトの定義

インシデント・ルールがOSコマンド拡張通知アクションと一致する場合に通知システムによってコールされるOSコマンドまたはスクリプトを指定できます。スクリプト本体で、インシデント、イベントまたは問題のコンテキスト情報、修正処理の実行ステータス、およびジョブ実行ステータスを使用できます。このコンテキスト情報をOSコマンド/スクリプトに渡すと、自動化されたレスポンス固有イベント条件をカスタマイズできます。たとえば、OSスクリプトで社内サポート用トラブル・チケット・システムに対するトラブル・チケットを開く場合、スクリプトに重大度レベル(クリティカル、警告など)を渡すことによって、該当する詳細とともにトラブル・チケットを開いて問題を提示できます。特定タイプの情報をOSコマンドまたはスクリプトに渡す方法の詳細は、次の各項を参照してください。

- OSコマンドまたはスクリプトへのイベント、インシデント、問題情報の受渡し

- OSコマンドまたはスクリプトへの修正処理実行ステータスの受渡し

- OSコマンドまたはスクリプトへのジョブ実行ステータスの受渡し

手順2: 各管理サービス・ホスト上へのスクリプトのデプロイ

管理リポジトリに接続する各管理サービス・ホスト・マシン上に、OSコマンドまたはスクリプトをデプロイする必要があります。OSコマンドは、管理サービスを開始したユーザーで実行されます。OSコマンドまたはスクリプトは、各管理サービス・ホスト・マシン上の同じ場所にデプロイする必要があります。

重要:
スクリプトとOSコマンドは、両方とも絶対パスを使用して指定する必要があります。たとえば、/u1/bin/logSeverity.shなどです。

このコマンドは、管理サービスを開始したユーザーによって実行されます。OSコマンドの実行中にエラーが発生した場合は、終了コード100を返すことで、OSコマンドへの通知の送信を再試行するように通知システムに指示できます。プロシージャの再試行は、最初は1分後に、次は2分後、3分後に、最後は30分後に行われます。これ以降、プロシージャの再試行は、通知が24時間経過するまで、30分ごとに行われます。その後、通知はパージされます。

例3-4に、管理サービスにより中断されることなくOSコマンドを実行できる期間を制御するemoms.propertiesのパラメータを示します。これによって、OSコマンドが過度に長い時間実行されるため他の通知の転送を妨げることが回避できます。デフォルトでは、コマンドは中断されるまで30秒間実行できます。oracle.sysman.core.notification.os_cmd_timeout emomsプロパティを構成して、デフォルトのタイムアウト値を変更できます。

例3-4 oracle.sysman.core.notification.os_cmd_timeout emomsプロパティの変更

emctl set property -name oracle.sysman.core.notification.os_cmd_timeout value 30

手順3: OSコマンドまたはスクリプトを新規の通知メソッドとして登録

このOSコマンドをインシデント・ルールでコールできる通知メソッドとして追加します。スーパー管理者としてログインします。「設定」メニューから、「通知」、「通知メソッド」の順に選択します。このページから、「OSコマンド」タイプに基づいて新しい通知を定義します。「OSコマンドおよびスクリプトを使用した通知の送信」を参照してください。

各OSコマンドの通知メソッドには次の情報が必要です。

- 名前

- 説明
他の管理者がこのメソッドの機能を理解できるようにするため、名前と説明は両方とも明快で直観的なものにします。

- OSコマンド

「OSコマンド」フィールドには、OSコマンドまたはスクリプトをフルパスで入力する必要があります(例: /u1/bin/myscript.sh)。複数の管理サービスを使用している環境では、管理サービスが存在する各マシン上のパスとまったく同じパスを入力します。フルパスの後にコマンドライン・パラメータを追加できます(例: /u1/bin/myscript.sh arg1 arg2)。

例3-5は、通知メソッドに必要な情報を示しています。

例3-5 OSコマンド通知メソッド

Name Trouble Ticketing
Description Notification method to log trouble ticket for a severity occurrence
OS Command /private/mozart/bin/logTicket.sh

注意:
システムごとに複数のOSコマンドが構成されている場合があります。

手順4: 通知メソッドのインシデント・ルールへの割当て。

既存のルールを編集(または新規のインスタンス・ルールを作成)後、メソッド・ページを表示できます。「設定」メニューから、「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール・ページから、使用可能なすべてのルール・セットにアクセスできます。

OSコマンドまたはスクリプトにイベント、インシデントおよび問題情報を渡す方法の詳細は、「OSコマンドまたはスクリプトへのイベント、インシデント、問題情報の受渡し」を参照してください。

3.3.1 スクリプト例

例3-6に示すOSスクリプトの例では、ログ・ファイルに環境変数エントリが付加されています。この例のスクリプトでは、ファイル・サーバーの重大度の発生が記録されます。ファイル・サーバーに接続できない場合、終了コード100が返され、Oracle Management Service通知システムで通知が再試行されます。

例3-6 OSコマンド・スクリプトの例

#!/bin/ksh

LOG_FILE=/net/myhost/logs/event.log
if test -f $LOG_FILE
then
echo $TARGET_NAME $MESSAGE $EVENT_REPORTED_TIME >> $LOG_FILE
else
exit 100
fi

例3-7には、oscmdNotify.logファイルにインシデントとイベントの両方のアラート情報を記録するOSスクリプトが示されています。ファイルは/net/myhost/logsディレクトリに保存されます。

例3-7 アラート・ロギング・スクリプト

#!/bin/sh#
LOG_FILE=/net/myhost/logs/oscmdNotify.log

echo '-------------' >> $LOG_FILE

echo 'issue_type=' $ISSUE_TYPE >> $LOG_FILE
echo 'notif_type=' $NOTIF_TYPE >> $LOG_FILE
echo 'message=' $MESSAGE >> $LOG_FILE
echo 'message_url'  = $MESSAGE_URL >>$LOG_FILE
echo 'severity=' $SEVERITY >> $LOG_FILE
echo 'severity_code'  = $SEVERITY_CODE >>$LOG_FILE
echo 'ruleset_name=' $RULESET_NAME >> $LOG_FILE
echo 'rule_name=' $RULE_NAME >> $LOG_FILE
echo 'rule_owner=' $RULE_OWNER >> $LOG_FILE
echo 'repeat_count=' $REPEAT_COUNT >> $LOG_FILE
echo 'categories_count'  = $CATEGORIES_COUNT >>$LOG_FILE
echo 'category_1'  = $CATEGORY_1 >>$LOG_FILE
echo 'category_2'  = $CATEGORY_2 >>$LOG_FILE
echo 'category_code_1'  = $CATEGORY_CODE_1 >>$LOG_FILE
echo 'category_code_2'  = $CATEGORY_CODE_2 >>$LOG_FILE
echo 'category_codes_count'  = $CATEGORY_CODES_COUNT >>$LOG_FILE

# event
if [ $ISSUE_TYPE -eq 1 ]
then
echo 'host_name=' $HOST_NAME >> $LOG_FILE
echo 'event_type=' $EVENT_TYPE >> $LOG_FILE
echo 'event_name=' $EVENT_NAME >> $LOG_FILE
echo 'event_occurrence_time=' $EVENT_OCCURRENCE_TIME >> $LOG_FILE
echo 'event_reported_time=' $EVENT_REPORTED_TIME >> $LOG_FILE
echo 'sequence_id=' $SEQUENCE_ID >> $LOG_FILE
echo 'event_type_attrs=' $EVENT_TYPE_ATTRS >> $LOG_FILE
echo 'source_obj_name=' $SOURCE_OBJ_NAME >> $LOG_FILE
echo 'source_obj_type=' $SOURCE_OBJ_TYPE >> $LOG_FILE
echo 'source_obj_owner=' $SOURCE_OBJ_OWNER >> $LOG_FILE
echo 'target_name'  = $TARGET_NAME >>$LOG_FILE
echo 'target_url'  = $TARGET_URL >>$LOG_FILE
echo 'target_owner=' $TARGET_OWNER >> $LOG_FILE
echo 'target_type=' $TARGET_TYPE >> $LOG_FILE
echo 'target_version=' $TARGET_VERSION >> $LOG_FILE
echo 'lifecycle_status=' $TARGET_LIFECYCLE_STATUS >> $LOG_FILE
echo 'assoc_incident_escalation_level'  = $ASSOC_INCIDENT_ESCALATION_LEVEL >>$LOG_FILE
echo 'assoc_incident_id'  = $ASSOC_INCIDENT_ID >>$LOG_FILE
echo 'assoc_incident_owner'  = $ASSOC_INCIDENT_OWNER >>$LOG_FILE
echo 'assoc_incident_acknowledged_by_owner'  = $ASSOC_INCIDENT_ACKNOWLEDGED_BY_OWNER >>$LOG_FILE
echo 'assoc_incident_acknowledged_details'  = $ASSOC_INCIDENT_ACKNOWLEDGED_DETAILS >>$LOG_FILE
echo 'assoc_incident_priority'  = $ASSOC_INCIDENT_PRIORITY >>$LOG_FILE
echo 'assoc_incident_status'  = $ASSOC_INCIDENT_STATUS >>$LOG_FILE
echo 'ca_job_status'  = $CA_JOB_STATUS >>$LOG_FILE
echo 'event_context_attrs'  = $EVENT_CONTEXT_ATTRS >>$LOG_FILE
echo 'last_updated_time'  = $LAST_UPDATED_TIME >>$LOG_FILE
echo 'sequence_id'  = $SEQUENCE_ID >>$LOG_FILE
echo 'test_date_attr_noref'  = $TEST_DATE_ATTR_NOREF >>$LOG_FILE
echo 'test_raw_attr_noref'  = $TEST_RAW_ATTR_NOREF >>$LOG_FILE
echo 'test_str_attr1'  = $TEST_STR_ATTR1 >>$LOG_FILE
echo 'test_str_attr2'  = $TEST_STR_ATTR2 >>$LOG_FILE
echo 'test_str_attr3'  = $TEST_STR_ATTR3 >>$LOG_FILE
echo 'test_str_attr4'  = $TEST_STR_ATTR4 >>$LOG_FILE
echo 'test_str_attr5'  = $TEST_STR_ATTR5 >>$LOG_FILE
echo 'test_str_attr_ref'  = $TEST_STR_ATTR_REF >>$LOG_FILE
echo 'total_occurrence_count'  = $TOTAL_OCCURRENCE_COUNT >>$LOG_FILE
fi

# incident
if [ $ISSUE_TYPE -eq 2 ]
then
echo 'action_msg=' $ACTION_MSG >> $LOG_FILE
echo 'incident_id=' $INCIDENT_ID >> $LOG_FILE
echo 'incident_creation_time=' $INCIDENT_CREATION_TIME >> $LOG_FILE
echo 'incident_owner=' $INCIDENT_OWNER >> $LOG_FILE
echo 'incident_acknowledged_by_owner'  = $INCIDENT_ACKNOWLEDGED_BY_OWNER >>$LOG_FILE
echo 'incident_status'  = $INCIDENT_STATUS >>$LOG_FILE
echo 'last_modified_by=' $LAST_MODIFIED_BY >> $LOG_FILE
echo 'last_updated_time=' $LAST_UPDATED_TIME >> $LOG_FILE
echo 'assoc_event_count=' $ASSOC_EVENT_COUNT >> $LOG_FILE
echo 'adr_incident_id=' $ADR_INCIDENT_ID >> $LOG_FILE
echo 'occurrence_count=' $OCCURRENCE_COUNT >> $LOG_FILE
echo 'escalated=' $ESCALATED >> $LOG_FILE
echo 'escalated_level=' $ESCALATED_LEVEL >> $LOG_FILE
echo 'priority=' $PRIORITY >> $LOG_FILE
echo 'priority_code'  = $PRIORITY_CODE >>$LOG_FILE
echo 'ticket_id=' $TICKET_ID >> $LOG_FILE
echo 'ticket_status=' $TICKET_STATUS >> $LOG_FILE
echo 'ticket_url=' $TICKET_ID_URL >> $LOG_FILE
echo 'total_duplicate_count=' $TOTAL_DUPLICATE_COUNT >> $LOG_FILE
echo 'source_count=' $EVENT_SOURCE_COUNT >> $LOG_FILE
echo 'event_source_1_host_name'  = $EVENT_SOURCE_1_HOST_NAME >>$LOG_FILE
echo 'event_source_1_target_guid'  = $EVENT_SOURCE_1_TARGET_GUID >>$LOG_FILE
echo 'event_source_1_target_name'  = $EVENT_SOURCE_1_TARGET_NAME >>$LOG_FILE
echo 'event_source_1_target_owner'  = $EVENT_SOURCE_1_TARGET_OWNER >>$LOG_FILE
echo 'event_source_1_target_type'  = $EVENT_SOURCE_1_TARGET_TYPE >>$LOG_FILE
echo 'event_source_1_target_url'  = $EVENT_SOURCE_1_TARGET_URL >>$LOG_FILE
echo 'event_source_1_target_lifecycle_status'  = $EVENT_SOURCE_1_TARGET_LIFECYCLE_STATUS >>$LOG_FILE
echo 'event_source_1_target_version'  = $EVENT_SOURCE_1_TARGET_VERSION >>$LOG_FILE
fi
exit 0

例3-8には、Enterprise Manager Cloud ControlからHP OpenViewコンソールにアラートを送信するスクリプトが示されています。メトリック・アラートがトリガーされるとEnterprise Manager Cloud Controlではアラートが表示されます。次にHP OpenViewスクリプトがコールされ、opcmsgを起動し、HP OpenView管理サーバーに情報を転送します。

例3-8 HP OpenViewスクリプト

/opt/OV/bin/OpC/opcmsg severity="$SEVERITY" app=OEM msg_grp=Oracle msg_text="$MESSAGE" object="$TARGET_NAME"

3.3.2 12cより前のOSコマンド・スクリプトの移行

この項では、13cより前のOSコマンド通知シェル環境変数を12c OSコマンド・シェル環境変数にマップする方法を説明します。

重要:
12cより前の通知ルールは、イベント・レベル・ルールにのみマップされます。インシデント・レベル・ルールへのマッピングは許可されていません。

注意:
ポリシー違反は、Enterprise Manager 12cリリース以上ではサポートされなくなりました。

3.3.2.1 メトリック・アラート・イベント・タイプの移行

次の表は、event_typeがmetric_alertの場合のOSコマンド・シェル環境変数のマッピングです。

表3-3 12cより前/13cのmetric_alert環境変数のマッピング

12cより前の環境変数

対応する13cの環境変数

ACKNOWLEDGED

ASSOC_INCIDENT_ACKNOWLEDGED_BY_OWNER

ACKNOWLEDGED_BY

ASSOC_INCIDENT_OWNER

CYCLE_GUID

CYCLE_GUID

HOST

HOST_NAME

KEY_VALUE

注意: 後述の詳細な説明を参照してください。

KEY_VALUE_NAME

注意: 後述の詳細な説明を参照してください。

MESSAGE

MESSAGE

METRIC

METRIC_COLUMN

NOTIF_TYPE

NOTIF_TYPE。第2.3.5項のマップを使用します。

REPEAT_COUNT

REPEAT_COUNT

RULE_NAME

RULESET_NAME

RULE_OWNER

RULE_OWNER

SEVERITY

SEVERITY

TARGET_NAME

TARGET_NAME

TARGET_TYPE

TARGET_TYPE

TIMESTAMP

EVENT_REPORTED_TIME

METRIC_VALUE

VALUE

VIOLATION_CONTEXT

EVENT_CONTEXT_ATTRS

VIOLATION_GUID

SEVERITY_GUID

POLICY_RULE

マッピングなし。Enterprise Manager 12cリリース以上では使用中止になりました。

KEY_VALUE_NAMEおよびKEY_VALUEを取得するには、次の手順を実行します。

- $NUM_KEYS変数がnullの場合、$KEY_VALUE_NAMEと$KEY_VALUEはnullです。

- $NUM_KEYSが1の場合
KEY_VALUE_NAME=$KEY_COLUMN_1

KEY_COLUMN_1_VALUE

- $NUM_KEYSが1より大きい場合
KEY_VALUE_NAME="$KEY_COLUMN_1;$KEY_COLUMN_2;..;KEY_COLUMN_x"

KEY_VALUE="$KEY_COLUMN_1_VALUE;$KEY_COLUMN_2_VALUE;..;KEY_COLUMN_x_VALUE "

xは$NUM_KEYSの値で、";"はセパレータです。

3.3.2.2 ターゲット可用性イベント・タイプの移行

次の表は、event_typeが"target_availability"の場合のOSコマンド・シェル環境変数のマッピングです。

表3-4 12cより前/12cのtarget_availability環境変数のマッピング

12cより前の環境変数

対応する13cの環境変数

TARGET_NAME

TARGET_NAME

TARGET_TYPE

TARGET_TYPE

METRIC

ステータス

CYCLE_GUID

CYCLE_GUID

VIOLATION_CONTEXT

EVENT_CONTEXT_ATTRS

SEVERITY

TARGET_STATUS

HOST

HOST_NAME

MESSAGE

MESSAGE

NOTIF_TYPE

NOTIF_TYPE。第2.3.5項のマップを使用します。

TIMESTAMP

EVENT_REPORTED_TIME

RULE_NAME

RULESET_NAME

RULE_OWNER

RULE_OWNER

REPEAT_COUNT

REPEAT_COUNT

KEY_VALUE

""

KEY_VALUE_NAME

""

3.3.2.3 ジョブ・ステータス変更イベント・タイプの移行

次の表は、event_typeがjob_status_changeの場合のOSコマンド・シェル環境変数のマッピングです。

表3-5 12cより前/13cのjos_status_change環境変数のマッピング

12cより前の環境変数

対応する13cの環境変数

JOB_NAME

SOURCE_OBJ_NAME

JOB_OWNER

SOURCE_OBJ_OWNER

JOB_TYPE

SOURCE_OBJ_SUB_TYPE

JOB_STATUS

EXECUTION_STATUS

NUM_TARGETS

$ TARGET_NAMEがnullでない場合は1、それ以外の場合は0

TARGET_NAME1

TARGET_NAME

TARGET_TYPE1

TARGET_TYPE

TIMESTAMP

EVENT_REPORTED_TIME

RULE_NAME

RULESET_NAME

RULE_OWNER

RULE_OWNER

3.3.2.4 修正処理関連のOSスクリプトの移行

修正処理の通知受信時の次の環境変数のマッピングは、「メトリック・アラート・イベント・タイプの移行」の項を参照してください。

KEY_VALUE

KEY_VALUE_NAME

METRIC

METRIC_VALUE

RULE_NAME

RULE_OWNER

SEVERITY

TIMESTAMP

VIOLATION_CONTEXT

他の環境変数のマッピングには、次のマップを使用します。

表3-6 12cより前/13cの修正処理環境変数のマッピング

12cより前の環境変数

対応する13cの環境変数

NUM_TARGETS

1

TARGET_NAME1

TARGET_NAME

TARGET_TYPE1

TARGET_TYPE

JOB_NAME

CA_JOB_NAME

JOB_OWNER

CA_JOB_OWNER

JOB_STATUS

CA_JOB_STATUS

JOB_TYPE

CA_JOB_TYPE

3.3.2.5 通知タイプのマッピング

表3-7 12cより前/13cのnotif_typeのマッピング

notif_type (13c)

notif_type(12cより前)

NOTIF_NORMAL

1

NOTIF_REPEAT

4

NOTIF_DURATION

9

NOTIF_RETRY

2

3.4 PL/SQLプロシージャを使用した通知の送信

ユーザー定義PL/SQLプロシージャは、一致するイベント、インシデントおよび問題の通知を受信できます。

注意:
Enterprise Managerをリリース12cより前から12cにアップグレードする場合、13cより前の既存のPL/SQL拡張通知メソッドが変更なしで機能を続けます。ただし、プロシージャを更新して新しいシグネチャを使用する必要があります。
Enterprise Manager 13cで作成された新しいPL/SQL拡張通知メソッドでは、次の項に記載されている新しいシグネチャを使用する必要があります。

PL/SQLプロシージャに基づく通知メソッドを定義するには、次の4つの手順を実行します。

3.4.1 PL/SQLベースの通知メソッドの定義

PL/SQLベースの通知メソッドの作成は、次の4つの手順で構成されます。

1. PL/SQLプロシージャを定義します。

2. 管理リポジトリ上にPL/SQLプロシージャを作成します。

3. PL/SQLプロシージャを新規の通知メソッドとして登録します。

4. 通知メソッドをインシデント・ルールに割り当てます。

手順1: PL/SQLプロシージャの定義

受け取られる通知のタイプに応じて、プロシージャには次のうち1つのシグネチャを含める必要があります。

イベントの場合:

PROCEDURE event_proc(event_msg IN gc$notif_event_msg)

インシデントの場合:

PROCEDURE incident_proc(incident_msg IN gc$notif_incident_msg)

問題の場合:

PROCEDURE problem_proc(problem_msg IN gc$notif_problem_msg)

注意:
ユーザーがインシデント・ルールの作成または編集時に通知メソッドを選択するには、スーパー管理者権限を持つ管理者が、PL/SQLプロシージャに基づく通知メソッドをあらかじめ構成しておく必要があります。

特定タイプの情報をスクリプトまたはPL/SQLプロシージャに渡す方法の詳細は、次の各項を参照してください。

PL/SQLプロシージャへの情報の受渡し

修正処理ステータス変更情報の受渡し

ジョブ実行ステータス情報の受渡し

手順2: 管理リポジトリ上でのPL/SQLプロシージャの作成。

次の指定プロシージャの1つを使用して、リポジトリ・データベースでPL/SQLプロシージャを作成します。

PROCEDURE event_proc(event_msg IN gc$notif_event_msg)

PROCEDURE incident_proc(incident_msg IN gc$notif_incident_msg)

PROCEDURE problem_proc(problem_msg IN gc$notif_problem_msg)

PL/SQLプロシージャは、(SYSMANなどの)リポジトリ所有者のデータベース・アカウントを使用してリポジトリ・データベース上に作成する必要があります。

プロシージャの実行時にエラーが発生した場合、エラー・コード-20000を使用するユーザー定義例外を返すことによって、通知システムでプロシージャへの通知の送信を再試行できます。このプロシージャは、最初は1分後に再試行され、その後は2分後、3分後と、パージされるポイントである1日後までこの再試行が続行されます。

手順3: PL/SQLプロシージャを新規の通知メソッドとして登録

スーパー管理者としてログインします。「設定」メニューから、「通知」、「通知メソッド」の順に選択して、通知メソッド・ページにアクセスします。このページから、PL/SQLプロシージャに基づく新規の通知を定義できます。第3.4項「PL/SQLプロシージャを使用した通知の送信」を参照してください。

スキーマ所有者、パッケージ名およびプロシージャ名を含む完全修飾名を必ず使用してください。プロシージャはリポジトリ所有者によって実行されるため、リポジトリ所有者にプロシージャの実行権限があります。

PL/SQLプロシージャに基づく通知メソッドを作成します。メソッドの定義には次の情報が必要です。

- 名前

- 説明

- PL/SQLプロシージャ

完全修飾プロシージャ名(OWNER.PKGNAME.PROCNAMEなど)を入力し、管理リポジトリの所有者がプロシージャの実行権限を持つようにする必要があります。

例3-9は必要な情報の例です。

例3-9 PL/SQLプロシージャで必要な情報

Name Open trouble ticket
Description Notification method to open a trouble ticket in the event
PLSQL Procedure ticket_sys.ticket_ops.open_ticket

図3-1に、Enterprise Manager UIからPL/SQLベースの通知メソッドを追加する方法を示します。

図3-1 PL/SQLプロシージャの追加

手順4: 通知メソッドのインシデント・ルールへの割当て。

既存のルールを編集(または新規のインシデント・ルールを作成)できます。「設定」メニューから、「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール・ページが表示されます。ここから、拡張通知メソッドに見つかった新しいPL/SQLプロシージャを指定するアクションをルールに追加できます。

Enterprise Manager環境には複数のPL/SQLベースのメソッドが構成されている場合があります。

インシデント、イベントおよび問題情報をPL/SQLプロシージャに渡す方法の詳細は、「PL/SQLプロシージャへの情報の受渡し」を参照してください。

例3-10 PL/SQLスクリプト

-- Assume log_table is created by following DDL
-- CREATE TABLE log_table (message VARCHAR2(4000)) ;
-- Define PL/SQL notification method for Events
CREATE OR REPLACE PROCEDURE log_table_notif_proc(s IN GC$NOTIF_EVENT_MSG)
IS
l_categories gc$category_string_array;
l_category_codes gc$category_string_array;
l_attrs gc$notif_event_attr_array;
l_ca_obj gc$notif_corrective_action_job;
BEGIN
INSERT INTO log_table VALUES ('notification_type: ' || s.msg_info.notification_type);
INSERT INTO log_table VALUES ('repeat_count: ' || s.msg_info.repeat_count);
INSERT INTO log_table VALUES ('ruleset_name: ' || s.msg_info.ruleset_name);
INSERT INTO log_table VALUES ('rule_name: ' || s.msg_info.rule_name);
INSERT INTO log_table VALUES ('rule_owner: ' || s.msg_info.rule_owner);
INSERT INTO log_table VALUES ('message: ' || s.msg_info.message);
INSERT INTO log_table VALUES ('message_url: ' || s.msg_info.message_url);
INSERT INTO log_table VALUES ('event_instance_guid: ' || s.event_payload.event_instance_guid);
INSERT INTO log_table VALUES ('event_type: ' || s.event_payload.event_type);
INSERT INTO log_table VALUES ('event_name: ' || s.event_payload.event_name);
INSERT INTO log_table VALUES ('event_msg: ' || s.event_payload.event_msg);
INSERT INTO log_table VALUES ('source_obj_type: ' || s.event_payload.source.source_type);
INSERT INTO log_table VALUES ('source_obj_name: ' || s.event_payload.source.source_name);
INSERT INTO log_table VALUES ('source_obj_url: ' || s.event_payload.source.source_url);
INSERT INTO log_table VALUES ('target_name: ' || s.event_payload.target.target_name);
INSERT INTO log_table VALUES ('target_url: ' || s.event_payload.target.target_url);
INSERT INTO log_table VALUES ('severity: ' || s.event_payload.severity);  INSERT INTO log_table VALUES ('severity_code: ' || s.event_payload.severity_code);
INSERT INTO log_table VALUES ('event_reported_date: ' || to_char(s.event_payload.reported_date, 'D MON DD HH24:MI:SS'));

l_categories := s.event_payload.categories;
IF l_categories IS NOT NULL
THEN
FOR c IN 1..l_categories.COUNT
LOOP
INSERT INTO log_table VALUES ('category ' || c || ' - ' || l_categories(c));
END LOOP;
END IF;

l_category_codes := s.event_payload.category_codes;
IF l_categories IS NOT NULL
THEN
FOR c IN 1..l_category_codes.COUNT
LOOP
INSERT INTO log_table VALUES ('category_code ' || c || ' - ' || l_category_codes(c));
END LOOP;
END IF;

l_attrs := s.event_payload.event_attrs;
IF l_attrs IS NOT NULL
THEN
FOR c IN 1..l_attrs.COUNT
LOOP
INSERT INTO log_table VALUES ('EV.ATTR name=' || l_attrs(c).name || ' value=' || l_attrs(c).value || ' nls_value=' || l_attrs(c).nls_value);    END LOOP;
END IF;

COMMIT ;
END ;
/

例3-11 表にイベントを記録するPL/SQLスクリプト

CREATE TABLE event_log (
notification_type      VARCHAR2(32),
repeat_count           NUMBER,
ruleset_name           VARCHAR2(256),
rule_owner             VARCHAR2(256),
rule_name              VARCHAR2(256),
message                VARCHAR2(4000),
message_url            VARCHAR2(4000),
event_instance_guid    RAW(16),
event_type             VARCHAR2(20),
event_name             VARCHAR2(512),
event_msg              VARCHAR2(4000),
categories             VARCHAR2(4000),
source_obj_type        VARCHAR2(120),
source_obj_name        VARCHAR2(256),
source_obj_url         VARCHAR2(4000),
severity               VARCHAR2(128),
severity_code          VARCHAR2(32),
target_name            VARCHAR2(256),
target_type            VARCHAR2(128),
target_url             VARCHAR2(4000),
host_name              VARCHAR2(256),
timezone               VARCHAR2(64),
occured                DATE,
ca_guid                RAW(16),
ca_name                VARCHAR2(128),
ca_owner               VARCHAR2(256),
ca_type                VARCHAR2(256),
ca_status              VARCHAR2(64),
ca_status_code         NUMBER,
ca_job_step_output     VARCHAR2(4000),
ca_execution_guid      RAW(16),
ca_stage_change_guid   RAW(16)
)
;

CREATE OR REPLACE PROCEDURE log_event(s IN GC$NOTIF_EVENT_MSG)
IS
l_categories gc$category_string_array;
l_ca_obj gc$notif_corrective_action_job;
l_categories_new VARCHAR2(1000);
BEGIN
-- save event categories
l_categories := s.event_payload.categories;
IF l_categories IS NOT NULL
THEN
FOR c IN 1..l_categories.COUNT
LOOP
l_categories_new := (l_categories_new|| c || ' - ' || l_categories(c)||',');
END LOOP;
END IF;

-- save event message
IF s.msg_info.notification_type = 'NOTIF_CA' AND s.event_payload.corrective_action IS NOT NULL
THEN
l_ca_obj := s.event_payload.corrective_action;
INSERT INTO event_log (notification_type, repeat_count, ruleset_name, rule_name, rule_owner, message, message_url, event_instance_guid, event_type, event_name, event_msg, categories, source_obj_type, source_obj_name, source_obj_url, severity, severity_code, target_name, target_type, target_url, host_name, timezone, occured, ca_guid, ca_name, ca_owner, ca_type, ca_status, ca_status_code, ca_job_step_output, ca_execution_guid, ca_stage_change_guid)
VALUES (s.msg_info.notification_type, s.msg_info.repeat_count, s.msg_info.ruleset_name, s.msg_info.rule_name,s.msg_info.rule_owner, s.msg_info.message, s.msg_info.message_url, s.event_payload.event_instance_guid, s.event_payload.event_type, s.event_payload.event_name, s.event_payload.event_msg, l_categories_new, s.event_payload.source.source_type, s.event_payload.source.source_name, s.event_payload.source.source_url, s.event_payload.severity, s.event_payload.severity_code, s.event_payload.target.target_name, s.event_payload.target.target_type, s.event_payload.target.target_url, s.event_payload.target.host_name, s.event_payload.target.target_timezone, s.event_payload.occurrence_date, l_ca_obj.JOB_GUID, l_ca_obj.JOB_NAME, l_ca_obj.JOB_OWNER, l_ca_obj.JOB_TYPE, l_ca_obj.JOB_STATUS, l_ca_obj.JOB_STATUS_CODE, l_ca_obj.JOB_STEP_OUTPUT, l_ca_obj.JOB_EXECUTION_GUID, l_ca_obj.JOB_STATE_CHANGE_GUID);   ELSE
INSERT INTO event_log (notification_type, repeat_count, ruleset_name, rule_name, rule_owner, message, message_url, event_instance_guid, event_type, event_name, event_msg, categories, source_obj_type, source_obj_name, source_obj_url, severity, severity_code, target_name, target_type, target_url, host_name, timezone, occured, ca_guid, ca_name, ca_owner, ca_type, ca_status, ca_status_code, ca_job_step_output, ca_execution_guid, ca_stage_change_guid)
VALUES (s.msg_info.notification_type, s.msg_info.repeat_count, s.msg_info.ruleset_name, s.msg_info.rule_name, s.msg_info.rule_owner, s.msg_info.message, s.msg_info.message_url, s.event_payload.event_instance_guid, s.event_payload.event_type, s.event_payload.event_name, s.event_payload.event_msg, l_categories_new, s.event_payload.source.source_type, s.event_payload.source.source_name, s.event_payload.source.source_url, s.event_payload.severity, s.event_payload.severity_code, s.event_payload.target.target_name, s.event_payload.target.target_type, s.event_payload.target.target_url, s.event_payload.target.host_name, s.event_payload.target.target_timezone, s.event_payload.occurrence_date, null,null,null,null,null,null,null,null,null);
END IF;
COMMIT;
END log_event;
/

例3-12 表にインシデントを記録するPL/SQLスクリプト

CREATE TABLE incident_log (
notification_type      VARCHAR2(32),
repeat_count           NUMBER,
ruleset_name           VARCHAR2(256),
rule_owner             VARCHAR2(256),
rule_name              VARCHAR2(256),
message                VARCHAR2(4000),
message_url            VARCHAR2(4000),
incident_id            VARCHAR2(128),
ticket_url             VARCHAR2(4000),
assoc_event_cnt        NUMBER,
severity               VARCHAR2(128),
severity_code          VARCHAR2(32),
priority               VARCHAR2(128),
priority_code          VARCHAR2(32),
status                 VARCHAR2(32),
categories             VARCHAR2(1000),
target_name            VARCHAR2(256),
target_type            VARCHAR2(128),
host_name              VARCHAR2(256),
timezone               VARCHAR2(64),
occured                DATE
)
;
CREATE OR REPLACE PROCEDURE log_incident(s IN GC$NOTIF_INCIDENT_MSG)
IS
l_src_info_array GC$NOTIF_SOURCE_INFO_ARRAY;
l_src_info  GC$NOTIF_SOURCE_INFO;
l_categories gc$category_string_array;
l_target_obj GC$NOTIF_TARGET;
l_target_name VARCHAR2(256);
l_target_type VARCHAR2(256);
l_target_timezone VARCHAR2(256);
l_hostname VARCHAR2(256);
l_categories_new VARCHAR2(1000);
BEGIN
-- Save Incident categories
IF l_categories IS NOT NULL
THEN
FOR c IN 1..l_categories.COUNT
LOOP
l_categories_new := (l_categories_new|| c || ' - ' || l_categories(c)||',');
END LOOP;
END IF;

-- GET target info
l_src_info_array := s.incident_payload.incident_attrs.source_info_arr;
IF l_src_info_array IS NOT NULL
THEN
FOR I IN 1..l_src_info_array.COUNT
LOOP
IF l_src_info_array(I).TARGET IS NOT NULL
THEN
l_target_name := l_src_info_array(I).TARGET.TARGET_NAME;
l_target_type := l_src_info_array(I).TARGET.TARGET_TYPE;
l_target_timezone := l_src_info_array(I).TARGET.TARGET_TIMEZONE;
l_hostname := l_src_info_array(I).TARGET.HOST_NAME;
END IF;
END LOOP;
END IF;

-- save Incident notification message    INSERT INTO incident_log(notification_type, repeat_count, ruleset_name, rule_owner, rule_name, message, message_url, incident_id, ticket_url, assoc_event_cnt, severity, severity_code, priority, priority_code, status, categories, target_name, target_type, host_name, timezone, occured)
VALUES (s.msg_info.notification_type, s.msg_info.repeat_count, s.msg_info.ruleset_name, s.msg_info.rule_owner, s.msg_info.rule_name, s.msg_info.message, s.msg_info.message_url, s.incident_payload.incident_attrs.id, s.incident_payload.ticket_url, s.incident_payload.assoc_event_count, s.incident_payload.incident_attrs.severity, s.incident_payload.incident_attrs.severity_code, s.incident_payload.incident_attrs.priority, s.incident_payload.incident_attrs.priority_code, s.incident_payload.incident_attrs.STATUS, l_categories_new, l_target_name, l_target_type, l_hostname,l_target_timezone, s.incident_payload.incident_attrs.creation_date);
COMMIT;
END log_incident;
/

例3-13 表に問題を記録するPL/SQLスクリプト

CREATE TABLE problem_log (
notification_type      VARCHAR2(32),
repeat_count           NUMBER,
ruleset_name           VARCHAR2(256),
rule_owner             VARCHAR2(256),
rule_name              VARCHAR2(256),
message                VARCHAR2(4000),
message_url            VARCHAR2(4000),
problem_key            VARCHAR2(850),
assoc_incident_cnt     NUMBER,
problem_id             NUMBER,
owner                  VARCHAR2(256),
severity               VARCHAR2(128),
severity_code          VARCHAR2(32),
priority               VARCHAR2(128),
priority_code          VARCHAR2(32),
status                 VARCHAR2(32),
categories             VARCHAR2(1000),
target_name            VARCHAR2(256),
target_type            VARCHAR2(128),
host_name              VARCHAR2(256),   timezone               VARCHAR2(64),
occured                DATE
)
;
CREATE OR REPLACE PROCEDURE log_problem(s IN GC$NOTIF_PROBLEM_MSG)
IS
l_src_info_array GC$NOTIF_SOURCE_INFO_ARRAY;
l_src_info  GC$NOTIF_SOURCE_INFO;
l_categories gc$category_string_array;
l_target_obj GC$NOTIF_TARGET;
l_target_name VARCHAR2(256);
l_target_type VARCHAR2(256);
l_target_timezone VARCHAR2(256);
l_hostname VARCHAR2(256);
l_categories_new VARCHAR2(1000);
BEGIN
-- Save Problem categories
l_categories := s.problem_payload.problem_attrs.categories;
IF l_categories IS NOT NULL
THEN
FOR c IN 1..l_categories.COUNT
LOOP
l_categories_new := (l_categories_new|| c || ' - ' || l_categories(c)||',');
END LOOP;
END IF;

-- GET target info
l_src_info_array := s.problem_payload.problem_attrs.source_info_arr;
IF l_src_info_array IS NOT NULL
THEN
FOR I IN 1..l_src_info_array.COUNT
LOOP
IF l_src_info_array(I).TARGET IS NOT NULL
THEN
l_target_name := l_src_info_array(I).TARGET.TARGET_NAME;
l_target_type := l_src_info_array(I).TARGET.TARGET_TYPE;
l_target_timezone := l_src_info_array(I).TARGET.TARGET_TIMEZONE;
l_hostname := l_src_info_array(I).TARGET.HOST_NAME;
END IF;
END LOOP;
END IF;

-- save Problem notification message
INSERT INTO problem_log(notification_type, repeat_count, ruleset_name, rule_owner, rule_name, message, message_url, problem_key, assoc_incident_cnt, problem_id, owner,  severity, severity_code, priority, priority_code, status, categories, target_name, target_type, host_name, timezone, occured)
VALUES (s.msg_info.notification_type, s.msg_info.repeat_count, s.msg_info.ruleset_name, s.msg_info.rule_owner, s.msg_info.rule_name, s.msg_info.message, s.msg_info.message_url, s.problem_payload.problem_key,            s.problem_payload.ASSOC_INCIDENT_COUNT, s.problem_payload.problem_attrs.id,            s.problem_payload.problem_attrs.owner, s.problem_payload.problem_attrs.severity,            s.problem_payload.problem_attrs.severity_code, s.problem_payload.problem_attrs.PRIORITY, s.problem_payload.problem_attrs.PRIORITY_CODE, s.problem_payload.problem_attrs.status, l_categories_new, l_target_name, l_target_type, l_hostname,l_target_timezone, s.problem_payload.problem_attrs.CREATION_DATE);
COMMIT;
END log_problem;
/

3.4.2 12cより前のPL/SQL拡張通知メソッドの移行

12cより前の通知をEnterprise Manager 12cのイベント通知にマップします。イベント・タイプmetric_alert、target_availabilityおよびjob_status_alertは、12cより前の通知機能に対応します。

注意:
ポリシー違反は、Enterprise Manager 12c以上では使用できなくなりました。

この項では、Enterprise Manager 13c PL/SQL通知ペイロードと12cより前のPL/SQL通知ペイロードのマッピングについて説明します。この情報を使用して、13c PL/SQL通知ペイロードを使用するように既存の12cより前のPL/SQLユーザー・コールバック・プロシージャを更新できます。ポリシー違反は13cリリースではサポートされなくなりました。

3.4.2.1 MGMT_NOTIFY_SEVERITYのマッピング

イベント・タイプがmetric_alertの場合

gc$notif_event_payload .event_type='metric_alert'の場合は次のマップを使用します。

表3-8 メトリック・アラートのマッピング

MGMT_NOTIFY_SEVERITY

13cの通知ペイロード

TARGET_NAME

gc$notif_target.target_name

TARGET_TYPE

gc$notif_target.target_type

TIMEZONE

gc$notif_target.target_timezone

HOST_NAME

gc$notif_target.host_name

MERTIC_NAME

gc$notif_event_attr_arrayのname='metric_guid_id'のgc$notif_event_attr.value。

METRIC_DESCRIPTION

gc$notif_event_attr_arrayのname='metric_description'のgc$notif_event_attr.value。

METRIC_COLUMN

gc$notif_event_attr_arrayのname='metric_column'のgc$notif_event_attr.value。

METRIC_VALUE

gc$notif_event_attr_arrayのname='value'のgc$notif_event_attr.value。

KEY_VALUE

gc$notif_event_attr_arrayのgc$notif_event_attr.name='num_keys'の値がnullではなく、0より大きい場合に、複数のキー・ベース・メトリックに適用されます。

後述の詳細な説明を参照してください。

KEY_VALUE_NAME

gc$notif_event_attr_arrayのgc$notif_event_attr.name='num_keys'の値がnullではなく、0より大きい場合に、複数のキー・ベース・メトリックに適用されます。

後述の詳細な説明を参照してください。

KEY_VALUE_GUID

gc$notif_event_attr_arrayのname='key_ value'のgc$notif_event_attr.value。

CTXT_LIST

gc$notif_event_context_array

COLLECTION_TIMESTAMP

gc$notif_event_payload. reported_date

SEVERITY_CODE

gc$notif_event_payload.severity_codeから導出されます。表3-9「重大度コードのマッピング」を参照してください。

MESSAGE

gc$notif_msg_info.message

SEVERITY_GUID

gc$notif_event_attr_arrayのname='severity_guid'のgc$notif_event_attr.value。

METRIC_GUID

gc$notif_event_attr_arrayのname='metric_guid'のgc$notif_event_attr.value。

TARGET_GUID

gc$notif_target.target_guid

RULE_OWNER

gc$notif_msg_info.rule_owner

RULE_NAME

gc$notif_msg_info.ruleset_name

次の例は、Enterprise Manager 13cの通知ペイロードから、類似した12cより前のKEY_VALUEおよびKEY_VALUE_NAMEを取得する方法を示しています。

例3-14 KEY_VALUEおよびKEY_VALUE_NAMEの抽出

-- Get the pre-12c KEY_VALUE and KEY_VALUE_NAME from an Enterprise Manager 13c
-- notification payload
-- parameters
--   IN Parameters:
--      event_msg : The event notification payload
--   OUT Parameters
--      key_value_name_out : the KEY_VALUE_NAME backward compitable to pre-12c
--                           notification payload
--      key_value_out      : the KEY_VALUE backward compitable to pre-12c
--                           notification payload
--
CREATE OR REPLACE PROCEDURE get_pre_12c_key_value(
event_msg IN GC$NOTIF_EVENT_MSG,
key_value_name_out OUT VARCHAR2,
key_value_out OUT VARCHAR2)
IS

l_key_columns MGMT_SHORT_STRING_ARRAY := MGMT_SHORT_STRING_ARRAY();
l_key_column_values MGMT_MEDIUM_STRING_ARRAY := MGMT_MEDIUM_STRING_ARRAY();
l_key_value VARCHAR2(1790) := NULL;
l_num_keys NUMBER := 0;
l_attrs gc$notif_event_attr_array;
l_key_value_name VARCHAR2(512);
BEGIN
l_attrs := event_msg.event_payload.event_attrs;
key_value_name_out := NULL;
key_value_out := NULL;

IF l_attrs IS NOT NULL AND
l_attrs.COUNT > 0
THEN
l_key_columns.extend(7);
l_key_column_values.extend(7);
FOR c IN 1..l_attrs.COUNT
LOOP
CASE l_attrs(c).name
WHEN 'num_keys' THEN
BEGIN
l_num_keys := to_number(l_attrs(c).value);
EXCEPTION
WHEN OTHERS THEN
-- should never happen, but guard against it l_num_keys := 0;
END;
WHEN 'key_value' THEN
l_key_value := substr(l_attrs(c).nls_value,1,1290);
WHEN 'key_column_1' THEN
l_key_columns(1) := substr(l_attrs(c).nls_value,1,64);
WHEN 'key_column_2' THEN
l_key_columns(2) := substr(l_attrs(c).nls_value,1,64);
WHEN 'key_column_3' THEN
l_key_columns(3) := substr(l_attrs(c).nls_value,1,64);
WHEN 'key_column_4' THEN
l_key_columns(4) := substr(l_attrs(c).nls_value,1,64);
WHEN 'key_column_5' THEN
l_key_columns(5) := substr(l_attrs(c).nls_value,1,64);
WHEN 'key_column_6' THEN
l_key_columns(6) := substr(l_attrs(c).nls_value,1,64);
WHEN 'key_column_7' THEN
l_key_columns(7) := substr(l_attrs(c).nls_value,1,64);
WHEN 'key_column_1_value' THEN
l_key_column_values(1) := substr(l_attrs(c).nls_value,1,256);
WHEN 'key_column_2_value' THEN
l_key_column_values(2) := substr(l_attrs(c).nls_value,1,256);
WHEN 'key_column_3_value' THEN
l_key_column_values(3) := substr(l_attrs(c).nls_value,1,256);
WHEN 'key_column_4_value' THEN
l_key_column_values(4) := substr(l_attrs(c).nls_value,1,256);
WHEN 'key_column_5_value' THEN
l_key_column_values(5) := substr(l_attrs(c).nls_value,1,256);
WHEN 'key_column_6_value' THEN
l_key_column_values(6) := substr(l_attrs(c).nls_value,1,256);
WHEN 'key_column_7_value' THEN
l_key_column_values(7) := substr(l_attrs(c).nls_value,1,256);
ELSE
NULL;
END CASE;
END LOOP;

-- get key_value and key_value_name when l_num_keys > 0

IF l_num_keys > 0
THEN
-- get key value name
IF l_key_columns IS NULL OR l_key_columns.COUNT = 0
THEN
key_value_name_out := NULL;
ELSE
l_key_value_name := NULL;
FOR i in l_key_columns.FIRST..l_num_keys
LOOP
IF i > 1
THEN
l_key_value_name := l_key_value_name || ';';
END IF;
l_key_value_name := l_key_value_name || l_key_columns(i);
END LOOP;
key_value_name_out := l_key_value_name;
END IF;
-- get key_value
IF l_num_keys = 1
THEN
key_value_out := l_key_value;
ELSE
l_key_value := NULL;
IF l_key_column_values IS NULL OR l_key_column_values.COUNT = 0
THEN
key_value_out := NULL;
ELSE
FOR i in l_key_column_values.FIRST..l_num_keys
LOOP
IF i > 1
THEN
l_key_value := l_key_value || ';';
END IF;
l_key_value := l_key_value || l_key_column_values(i);
END LOOP;
--  max length for key value in pre-12c = 1290
key_value_out := substr(l_key_value,1,1290);
END IF;
END IF;
END IF; -- l_num_keys > 0
END IF;  -- l_attrs IS NOT NULL
END get_pre_12c_key_value;
/

イベント・タイプがmetric_alertの場合:

イベント・タイプがmetric_alertの場合、重大度コードについて、13cから12cより前への次のマッピングを使用します。

表3-9 重大度コードのマッピング

13cの重大度コード

12cより前の重大度コード

GC_EVENT_RECEIVER.FATAL 32

MGMT_GLOBAL.G_SEVERITY_CRITICAL 25

GC_EVENT_RECEIVER.CRITICAL 16

MGMT_GLOBAL.G_SEVERITY_CRITICAL 25

GC_EVENT_RECEIVER.WARNING 8

MGMT_GLOBAL.G_SEVERITY_WARNING 20

GC_EVENT_RECEIVER.CLEAR 0

MGMT_GLOBAL.G_SEVERITY_CLEAR 15

イベント・タイプがtarget_availabilityの場合:

gc$notif_event_payload .event_type='target_availability'の場合は次のマップを使用します。

表3-10 ターゲット可用性のマッピング

MGMT_NOTIFY_SEVERITY

13cの通知ペイロード

TARGET_NAME

gc$notif_target.target_name

TARGET_TYPE

gc$notif_target.target_type

TIMEZONE

gc$notif_target.target_timezone

HOST_NAME

gc$notif_target.host_name

MERTIC_NAME

固定値"Response"を使用します。

METRIC_DESCRIPTION

NULL

METRIC_COLUMN

固定値"Status"を使用します。

METRIC_VALUE

gc$notif_event_attr_arrayのname='target_status'のgc$notif_event_attr.value。

KEY_VALUE

NULL

KEY_VALUE_NAME

NULL

KEY_VALUE_GUID

NULL

CTXT_LIST

gc$notif_event_context_array

COLLECTION_TIMESTAMP

gc$notif_event_payload. reported_date

SEVERITY_CODE

gc$notif_event_attr_arrayのname='avail_severity'のgc$notif_event_attr.value。

MESSAGE

gc$notif_msg_info.message

SEVERITY_GUID

gc$notif_event_attr_arrayのname='severity_guid'のgc$notif_event_attr.value。

METRIC_GUID

gc$notif_event_attr_arrayのname='metric_guid_id'のgc$notif_event_attr.value。

TARGET_GUID

gc$notif_target.target_guid

RULE_OWNER

gc$notif_msg_info.rule_owner

RULE_NAME

gc$notif_msg_info.ruleset_name

3.4.2.2 MGMT_NOTIFY_JOBのマッピング

gc$notif_event_payload .event_type='job_status_change'の場合は次のマップを使用します。

表3-11 ジョブ・ステータス変更のマッピング

MGMT_NOTIFY_JOB

13cの通知ペイロード

JOB_NAME

gc$notif_source.source_name

JOB_OWNER

gc$notif_source.source_owner

JOB_TYPE

gc$notif_source.source_sub_type

JOB_STATUS

gc$notif_event_attr_arrayのname='execution_status_code'のgc$notif_event_attr.value。

STATE_CHANGE_GUID

gc$notif_event_attr_arrayのname='state_change_guid'のgc$notif_event_attr.value。

JOB_GUID

gc$notif_source.source_guid

EXECUTION_ID

gc$notif_event_attr_arrayのname='execution_id'のgc$notif_event_attr.value。

TARGETS

gc$notif_target.target_name、gc$notif_target.target_type

RULE_OWNER

gc$notif_msg_info.rule_owner

RULE_NAME

gc$notif_msg_info.ruleset_name

OCCURRED_DATE

gc$notif_event_payload. reported_date

3.4.2.3 MGMT_NOTIFY_CORRECTIVE_ACTIONのマッピング

gc$notif_msg_info.notification_typeがNOTIF_CAに設定されている場合は、修正処理関連ペイロードが移入されます。

次の属性のマッピングについては、表3-8、「メトリック・アラートのマッピング」でMGMT_NOTIFY_SEVERITYオブジェクトに対して提供されているマッピング情報を使用してください。

MERTIC_NAME

METRIC_COLUMN

METRIC_VALUE

KEY_VALUE

KEY_VALUE_NAME

KEY_VALUE_GUID

CTXT_LIST

RULE_OWNER

RULE_NAME

OCCURRED_DATE

MGMT_NOTIFY_CORRECTIVE_ACTIONオブジェクトのジョブ関連属性のマッピングには、次のマップを使用します。

表3-12 修正処理のマッピング

MGMT_NOTIFY_CORRECTIVE_ACTION

13cの通知ペイロード

JOB_NAME

gc$ notif_corrective_action_job.job_name

JOB_OWNER

gc$ notif_corrective_action_job.job_owner

JOB_TYPE

gc$ notif_corrective_action_job.job_type

JOB_STATUS

gc$ notif_corrective_action_job.status_code

STATE_CHANGE_GUID

gc$ notif_corrective_action_job. job_state_change_guid

JOB_GUID

gc$ notif_corrective_action_job. job _guid

EXECUTION_ID

gc$ notif_corrective_action_job. job_execution_guid

OCCURRED_DATE

gc$ notif_corrective_action_job.occurred_date

TARGETS

ターゲットは1つまでです。関連付けられたターゲットには、gc$notif_target.target_name、gc$notif_target.target_typeの値を使用します。

3.5 サード・パーティ・システムへのSNMPトラップの送信

Enterprise Managerは、Simple Network Management Protocol (SNMP)を介したサード・パーティ管理ツールとの統合をサポートしています。たとえば、SNMPを使用して、選択済メトリックがしきい値を超えていることをサード・パーティ・アプリケーションに通知できます。

重要:
OMSによって送信されたトラップをサード・パーティ・システムで解釈するには、最初にomstrap.v1ファイルをサード・パーティのSNMPコンソールにロードする必要があります。このファイルおよびその場所の詳細は、「MIB定義」を参照してください。
Enterprise Manager 13cバージョンのMIBファイルは、10gおよび11gのMIBコンテンツを組み込んでおり、以前のEnterprise Managerのリリースとの下位互換性を保持しています。

Enterprise ManagerはSNMPバージョン1およびバージョン3の両方のトラップをサポートしています。トラップは、MIB定義(付録B「Enterprise Manager MIBの定義」)に説明されています。MIBの動作方法の詳細は、「管理情報ベース(MIB)」を参照してください。Enterprise Manager 13cを使用している場合、付録A「Enterprise Manager MIBの変数の解釈」および付録B「Enterprise Manager MIBの定義」を参照してください。12cより前のリリースのEnterprise Managerからアップグレードする場合、特定のリリースのマッピングについては、付録C「SNMPトラップのマッピング」を参照してください。

Enterprise Manager 13cでは、SNMPトラップはイベント通知に対してのみ配信されます。SNMPトラップ通知は、インシデントまたは問題に対してはサポートされません。

注意:
ユーザーがインシデント・ルールの作成または編集時に1つ以上のSNMPトラップ通知メソッドを選択するには、スーパー管理者権限を持つ管理者が、SNMPトラップに基づく通知メソッドをあらかじめ構成しておく必要があります。

3.5.1 SNMPバージョン1とSNMPバージョン3

SNMPバージョン3は、バージョン1と同じ基本アーキテクチャを共有していますが、SNMP管理およびセキュリティに多数の拡張機能を追加しています。Enterprise Managerに関する主な拡張機能は、認証とプライバシの両方、さらには認証とアクセス制御を提供する追加のセキュリティ・レベルに関連します。

ユーザーに基づくセキュリティ・レベル(USM)

USMは、SNMPメッセージの処理時にSNMPエンジンが従うセキュリティ関連プロシージャを定義します。Enterprise Manager SNMP V3サポートは、この追加されたSNMPメッセージ・レベルのセキュリティ拡張機能を利用して、セキュアなメッセージング環境を提供します。

USMは次の2つの主なセキュリティ脅威に対して保護します。

- 情報の変更: 変更の脅威とは、一部の認可されていないエンティティが、認可されているプリンシパルにかわって、オブジェクトの値の改ざんなどの認可されていない管理操作を有効にするような方法で、生成された送信中のSNMPメッセージを変更するような危険性です。

- マスカレード: マスカレードの脅威とは、一部のユーザーには認可されていない管理操作が、適切な認可を持つ別のユーザーのふりをすることによって試行されるような危険性です。

両方のSNMPバージョンで、SNMPトラップを使用してEnterprise Manager拡張通知を設定する基本的な方法は次のように同じままです。

1. SNMPトラップに基づく通知メソッドを定義します。

2. 通知メソッドをインシデント・ルールに割り当てます。

3.5.2 SNMP V3トラップ通知メソッドの操作

SNMP V3トラップ通知メソッドを定義するプロシージャは、V1の場合とは若干異なります。Enterprise Managerリリース12.1.0.4以降、SNMP V3トラップ通知メソッドに関する主要情報と構成機能は、個別のインタフェースにより統合されています。SNMP V3トラップのインタフェースを使用して、SNMP通知メソッドを作成し、SNMPトラップを送信するようにOMSを有効にし、SNMPトラップ通知のユーザー・セキュリティ設定を定義する処理を実行できます。

3.5.2.1 SNMPトラップ通知を送信するOMSの構成

SNMPトラップ通知メソッドを作成する前に、SNMPトラップ通知を処理するために環境で1つ以上のOMSを有効にする必要があります。SNMP V3の場合、OMSは、ネットワークにデプロイされたすべてのSNMPエージェントを監視しているSNMPマネージャにトラップを送信するSNMPエージェントとして機能します。

1. 「設定」メニューから、「通知」、「SNMPv3トラップ」の順に選択します。スタート・ガイド・ページが表示されます。このページには、サード・パーティのSNMPマネージャにトラップを送信するようにEnterprise Managerを構成するための高レベルのワークフローが記載されています。

2. 「構成」タブをクリックします。構成ページが表示されます。

3. 「OMS構成」領域で、有効にするOMSを選択します。

4. 必要に応じて、OMSごとに次を確認して変更を行います。

- OMSにはSNMPv3トラップのポートが必要です。デフォルト・ポートがOMSで使用できるかどうかを確認します。

- OMSにはトラップを送信するための一意のエンジンIDが必要です。デフォルトでは、ホスト名とポートから生成されます。

5. 「有効化」をクリックします。

3.5.2.2 SNMP V3トラップ通知メソッドの作成/編集

OMSがSNMPトラップ通知を送信するように有効にしたら、次の手順は、インシデント・ルールで使用できる通知メソッドの作成です。

1. 「設定」メニューから、「通知」、「SNMPv3トラップ」の順に選択します。スタート・ガイド・ページが表示されます。

注意:
既存の通知メソッドを編集する場合、「通知メソッド」領域から目的のメソッドを選択して「編集」をクリックします。

2. 「構成」タブをクリックします。構成ページが表示されます。

3. 「通知メソッド」領域から、「作成」をクリックします。SNMPv3トラップ: 通知メソッドの作成ページが表示されます。

4. 必要な通知メソッドの定義パラメータを入力します。注意: この時点で、繰返し通知を有効にできます。

5. ユーザー・セキュリティ・モデルの新しいエンティティを作成する場合、「ユーザー・セキュリティ・モデル」領域で、「新規作成」オプションが選択されていることを確認します。

1. 資格証明を一意に識別する「ユーザー名」を指定します。SNMP V3を使用すると、複数のユーザー名をSNMPエージェントおよびSNMPマネージャ・アプリケーションに設定できます。

2. ドロップダウン・メニューから「セキュリティ・レベル」を選択します。使用可能なパラメータは、セキュリティ・レベルに応じて使用可能になります。次の3つのレベルから選択します。
AuthPriv (認証 + プライバシ): 送信者のIDは、受信者によって確認される必要があります(認証)。SNMP V3メッセージは、送信者によって暗号化され、受信者によって復号化される必要があります(プライバシ)。

AuthNoPriv (認証のみ): 受信者は、メッセージを受け取る前に送信者のIDを認証する必要があります。

NoAuthNoPriv (セキュリティなし): 送信者のID確認もメッセージの暗号化も使用されません。

3. AuthPrivおよびAuthNoPrivセキュリティ・レベルの場合、目的の「認証プロトコル」を選択します。次の2つの認証プロトコルが使用可能です。
Secure Hash Algorithm(SHA)

メッセージ・ダイジェスト・アルゴリズム(MD5)

メッセージが認証されている場合、認証プロトコルを使用してメッセージ・ダイジェストを作成します。

プライバシ・プロトコル(AuthPrivセキュリティ・レベルに使用)がメッセージの暗号化/復号化に使用されます。USMはデータ暗号化規格(DES)を使用します。プライバシ・パスワードがプライバシ・プロトコルと組み合せて使用されます。暗号化/復号化が成功するためにSNMPエージェントとSNMPマネージャの両方のプライバシ・パスワードが一致する必要があります。

ユーザー・セキュリティ・モデル・エントリをすでに事前定義している場合、「既存のものを使用」オプションを選択し、ドロップダウン・メニューからUSMエントリのいずれかを選択します。ユーザー名別にUSMエントリがリストされます。

重要:
USM資格証明はOMSと外部トラップ受信者で同一であることを確認してください。一致しない場合、Enterprise ManagerはSNMPトラップをまだ送信しますが、トラップは受信されません。USM資格証明が無効の場合でもEnterprise ManagerはSNMPトラップを送信しますが、正しくない資格証明がSNMP受信者側で認証エラーになるためトラップは受信されません。このタイプの認証エラーは、Enterprise Managerコンソールからは見えません。

6. 必要な通知メソッドおよびUSMパラメータを入力したら、「保存」をクリックします。新しく作成された認証メソッドは構成ページの「通知メソッド」領域に表示されます。

注意:
SNMP V3トラップ通知メソッドを定義したら、ルールに追加する必要があります。手順は、「サード・パーティ・システムにSNMPトラップを送信するルールの作成」を参照してください。

3.5.2.3 ユーザー・セキュリティ・モデル・エントリの編集

USMエントリをいつでも追加できます。

1. 「設定」メニューから、「通知」、「SNMPv3トラップ」の順に選択します。

2. 「構成」タブをクリックします。

3. 「ユーザー・セキュリティ・モデル・エントリ」領域から、「作成」をクリックします。「ユーザー・セキュリティ・モデル・エントリ」ダイアログが表示されます。

4. 資格証明を一意に識別する「ユーザー名」を指定します。SNMP V3を使用すると、複数のユーザー名をSNMPエージェントおよびSNMPマネージャ・アプリケーションに設定できます。

5. ドロップダウン・メニューから「セキュリティ・レベル」を選択します。使用可能なパラメータは、セキュリティ・レベルに応じて使用可能になります。次の3つのレベルから選択します。
AuthPriv (認証 + プライバシ): 送信者のIDは、受信者によって確認される必要があります(認証)。SNMP V3メッセージは、送信者によって暗号化され、受信者によって復号化される必要があります(プライバシ)。

AuthNoPriv (認証のみ): 受信者は、メッセージを受け取る前に送信者のIDを認証する必要があります。

NoAuthNoPriv (セキュリティなし): 送信者のID確認もメッセージの暗号化も使用されません。

6. AuthPrivおよびAuthNoPrivセキュリティ・レベルの場合、目的の「認証プロトコル」を選択します。次の2つの認証プロトコルが使用可能です。
Secure Hash Algorithm(SHA)

メッセージ・ダイジェスト・アルゴリズム(MD5)

メッセージが認証されている場合、認証プロトコルを使用してメッセージ・ダイジェストを作成します。

プライバシ・プロトコル(AuthPrivセキュリティ・レベルに使用)がメッセージの暗号化/復号化に使用されます。USMはデータ暗号化規格(DES)を使用します。プライバシ・パスワードがプライバシ・プロトコルと組み合せて使用されます。暗号化/復号化が成功するためにSNMPエージェントとSNMPマネージャの両方のプライバシ・パスワードが一致する必要があります。

7. 「OK」をクリックします。
新しいUSMユーザー名が「ユーザー・セキュリティ・モデル・エントリ」表に表示されます。新しいSNMP V3トラップ通知メソッドの作成中、USMユーザー名はExisting Entriesドロップダウン・メニューから選択可能なオプションとして表示されます。

USMを編集した後、それを使用する通知メソッドを介して変更を確認する必要があります。

3.5.2.4 使用可能なSNMP V3トラップ通知メソッドの表示

使用可能なSNMP V3トラップ通知メソッドを表示するには、次の手順を実行します。

1. 「設定」メニューから、「通知」、「SNMPv3トラップ」の順に選択します。

2. 「構成」タブをクリックします。

3. 「通知メソッド」領域に既存のSNMP V3トラップ通知メソッドが表示されます。

3.5.2.5 SNMP V3トラップ通知メソッドの削除

使用可能なSNMP V3トラップ通知メソッドを削除するには、次の手順を実行します。

1. 「設定」メニューから、「通知」、「SNMPv3トラップ」の順に選択します。

2. 「構成」タブをクリックします。

3. 「通知メソッド」領域から、既存のSNMP V3トラップ通知メソッドを選択します。

4. 「削除」をクリックします。

3.5.3 SNMP V1トラップの作成

手順1: SNMPトラップに基づく新規の通知メソッドの定義

スーパー管理者としてEnterprise Managerにログインします。「設定」メニューから、「通知」、「スクリプトとSNMPv1トラップ」の順に選択します。

SNMPマスター・エージェントが実行されているホスト(マシン)の名前およびその他の詳細を、次の例のように指定する必要があります。示したように、SNMPホストがユーザーのSNMPトラップを受信します。

図3-2 SNMPトラップの必要情報

注意:
設定をテストするための「SNMPトラップのテスト」ボタンがあります。

メトリック重大度情報は、SNMPトラップ内で一連の変数として渡されます。

手順2: 通知メソッドのルールへの割当て

既存のルールを編集(または新規インシデント・ルールを作成)し、拡張通知メソッドをサブスクライブするアクションをルールに追加できます。SNMPトラップを使用したインシデント・ルールの設定手順については、「サード・パーティ・システムへSNMPトラップを送信するルールの作成」を参照してください。

SNMPトラップ実装のサンプル

このシナリオでは、送信されるSNMPトラップからの一意の問題を識別するとします。同じ問題に関連するすべてのイベントは同じイベント順序の一部であることに留意してください。各イベント順序には一意の識別番号があります。

イベント順序は、検出されてイベントが発生した時点から、解決されて対応するクリア・イベントが生成されるまでの、特定の問題の存続期間を表す関連イベントの順序です。たとえば、ホストのCPU使用率が80%を超えると警告のメトリック・アラート・イベントが発生します。これにより、「ホストのCPU使用率が通常レベルを超えた」という問題を表すイベント順序が開始します。CPU使用率が90%を超えると同じ問題に対して別のクリティカル・イベントが発生し、イベントが同じイベント順序に追加されます。しばらくして、CPU使用率が通常レベルに戻ると、クリア・イベントが発生します。この時点で、問題が解決され、イベント順序が終了します。

このシナリオでのSNMPトラップの送信を例3-15に示します。情報の各断片は、SNMPトラップに変数として組み込まれて送信されます。

例3-15 SNMPトラップ

**************V1 TRAP***[1]*****************
Community : public
Enterprise :1.3.6.1.4.1.111.15.2
Generic :6
Specific :3
TimeStamp :67809
Agent adress :10.240.36.109
1.3.6.1.4.1.111.15.3.1.1.2.1: NOTIF_NORMAL
1.3.6.1.4.1.111.15.3.1.1.3.1: CPU Utilization is 92.658%, crossed warning (80) or critical (90) threshold.
1.3.6.1.4.1.111.15.3.1.1.4.1: https://sampleserver.oracle.com:5416/em/redirect?pageType=sdk-core-event-console-detailEvent&issueID=C77AE9E578F00773E040F00A6D242F90
1.3.6.1.4.1.111.15.3.1.1.5.1: Critical
1.3.6.1.4.1.111.15.3.1.1.6.1: CRITICAL
1.3.6.1.4.1.111.15.3.1.1.7.1: 0
1.3.6.1.4.1.111.15.3.1.1.8.1:
1.3.6.1.4.1.111.15.3.1.1.9.1:
1.3.6.1.4.1.111.15.3.1.1.10.1: Aug 17, 2012 3:26:36 PM PDT
1.3.6.1.4.1.111.15.3.1.1.11.1: Capacity
1.3.6.1.4.1.111.15.3.1.1.12.1: Capacity
1.3.6.1.4.1.111.15.3.1.1.13.1: Metric Alert
1.3.6.1.4.1.111.15.3.1.1.14.1: Load:cpuUtil
1.3.6.1.4.1.111.15.3.1.1.15.1: 281
1.3.6.1.4.1.111.15.3.1.1.16.1:
1.3.6.1.4.1.111.15.3.1.1.17.1: No
1.3.6.1.4.1.111.15.3.1.1.18.1: New
1.3.6.1.4.1.111.15.3.1.1.19.1: None
1.3.6.1.4.1.111.15.3.1.1.20.1: 0
1.3.6.1.4.1.111.15.3.1.1.21.1: sampleserver.oracle.com
1.3.6.1.4.1.111.15.3.1.1.22.1: https://sampleserver.oracle.com:5416/em/redirect?pageType=TARGET_HOMEPAGE&targetName=sampleserver.oracle.com&targetType=host
1.3.6.1.4.1.111.15.3.1.1.23.1: Host
1.3.6.1.4.1.111.15.3.1.1.24.1: sampleserver.oracle.com
1.3.6.1.4.1.111.15.3.1.1.25.1: SYSMAN
1.3.6.1.4.1.111.15.3.1.1.26.1:
1.3.6.1.4.1.111.15.3.1.1.27.1: 5.8.0.0.0
1.3.6.1.4.1.111.15.3.1.1.28.1: Operating System=Linux, Platform=x86_64,
1.3.6.1.4.1.111.15.3.1.1.29.1:
1.3.6.1.4.1.111.15.3.1.1.30.1:
1.3.6.1.4.1.111.15.3.1.1.31.1:
1.3.6.1.4.1.111.15.3.1.1.32.1:
1.3.6.1.4.1.111.15.3.1.1.33.1:
1.3.6.1.4.1.111.15.3.1.1.34.1:
1.3.6.1.4.1.111.15.3.1.1.35.1:
1.3.6.1.4.1.111.15.3.1.1.36.1:
1.3.6.1.4.1.111.15.3.1.1.37.1:
1.3.6.1.4.1.111.15.3.1.1.38.1:
1.3.6.1.4.1.111.15.3.1.1.39.1: SnmpNotifRuleset
1.3.6.1.4.1.111.15.3.1.1.40.1: SnmpNotifRuleset,SnmpNotifEvent
1.3.6.1.4.1.111.15.3.1.1.41.1: SYSMAN
1.3.6.1.4.1.111.15.3.1.1.42.1: C77AE9E578F00773E040F00A6D242F90
1.3.6.1.4.1.111.15.3.1.1.43.1:
1.3.6.1.4.1.111.15.3.1.1.44.1:
1.3.6.1.4.1.111.15.3.1.1.45.1:
1.3.6.1.4.1.111.15.3.1.1.46.1: CPU Utilization is 92.658%, crossed warning (80) or critical (90) threshold., Incident created by rule (Name = Incident management Ruleset for all targets, Incident creation Rule for metric alerts.; Owner = <SYSTEM>).
1.3.6.1.4.1.111.15.3.1.1.61.1: Metric GUID=0C71A1AFAC2D7199013837DA35522C08
1.3.6.1.4.1.111.15.3.1.1.62.1: Severity GUID=C77AE9E578EC0773E040F00A6D242F90
1.3.6.1.4.1.111.15.3.1.1.63.1: Cycle GUID=C77AE9E578EC0773E040F00A6D242F90
1.3.6.1.4.1.111.15.3.1.1.64.1: Collection Name=LoadLinux
1.3.6.1.4.1.111.15.3.1.1.65.1: Metric Group=Load
1.3.6.1.4.1.111.15.3.1.1.66.1: Metric=CPU Utilization (%)
1.3.6.1.4.1.111.15.3.1.1.67.1: Metric Description=
1.3.6.1.4.1.111.15.3.1.1.68.1: Metric value=92.658
1.3.6.1.4.1.111.15.3.1.1.69.1: Key Value=
1.3.6.1.4.1.111.15.3.1.1.70.1:
1.3.6.1.4.1.111.15.3.1.1.71.1:
1.3.6.1.4.1.111.15.3.1.1.72.1:
1.3.6.1.4.1.111.15.3.1.1.73.1:
1.3.6.1.4.1.111.15.3.1.1.74.1:
1.3.6.1.4.1.111.15.3.1.1.75.1:
1.3.6.1.4.1.111.15.3.1.1.76.1:
1.3.6.1.4.1.111.15.3.1.1.77.1:
1.3.6.1.4.1.111.15.3.1.1.78.1:
1.3.6.1.4.1.111.15.3.1.1.79.1:
1.3.6.1.4.1.111.15.3.1.1.80.1:
1.3.6.1.4.1.111.15.3.1.1.81.1:
1.3.6.1.4.1.111.15.3.1.1.82.1:
1.3.6.1.4.1.111.15.3.1.1.83.1:
1.3.6.1.4.1.111.15.3.1.1.84.1: Number of keys=0
1.3.6.1.4.1.111.15.3.1.1.85.1:
**************END V1 TRAP******************

この例は、イベントのライフサイクル中のOIDの使用方法を示しています。ここで、あるイベントについて、そのイベントがオープン中は、イベント順序のOIDはイベント重大度が変更されても同じままです。

イベント順序のOIDは次のとおりです。

1.3.6.1.4.1.111.15.3.1.1.42.1: C77AE9E578F00773E040F00A6D242F90

イベントの重大度コードのOID:

1.3.6.1.4.1.111.15.3.1.1.6.1: CRITICAL

イベントがクリアされると、これらのOIDは同じイベント順序で異なる重大度コードを持つことを示します。

イベント順序のOIDは次のとおりです。

1.3.6.1.4.1.111.15.3.1.1.42.1: C77AE9E578F00773E040F00A6D242F90

イベントの重大度コードのOID:

1.3.6.1.4.1.111.15.3.1.1.6.1: CLEAR

SNMP OID値の長さは、デフォルトで2560バイトに制限されます。emomsプロパティoracle.sysman.core.notification.snmp.max_oid_lengthを構成してデフォルト制限を変更します。

3.5.4 SNMPトラップ: 以前のEnterprise Managerリリースから12c以上への移行

注意:
Enterprise Manager 12cより前のリリースから12c以上へアップグレードする場合、以前のリリースのEnterprise Manager (12cより前)を使用して定義されたSNMP拡張通知メソッドは、変更しなくても機能を続けます。

Enterprise Manager 11g以前では、次の2つのタイプのSNMPトラップがありました。

- アラート

- ジョブ・ステータス

Enterprise Manager 12c以上では、メトリック・アラート、ターゲット可用性、コンプライアンス標準違反、ジョブ・ステータス変更などの、すべての使用可能なイベント・タイプを網羅する、1つの包括的なSNMPトラップ・タイプになりました。12cより前から12cへのSNMPトラップ・マッピングの詳細は、付録C「SNMPトラップのマッピング」を参照してください。トラップは、古いEnterprise Manager MIB定義に準拠します。そのため、Enterprise Manager 12cより前のトラップは引き続き送信されます。詳細は、付録C「SNMPトラップのマッピング」を参照してください。

また、Enterprise Manager 12cでは、SNMPトラップのサイズは、すべてのイベント・タイプに対応し、より包括的な情報を提供するするために増加しました。デフォルトでは、SNMPパケットの最大サイズは5120バイトです。サード・パーティ・システムで受信できるSNMPトラップのサイズに制限がある場合、Enterprise Managerが送信するデフォルトのSNMPトラップのサイズを変更できます。デフォルトのパケット・サイズを変更するには、このemoms oracle.sysman.core.notification.snmp_packet_lengthパラメータを設定し、OMSをバウンスします。

注意:
SNMPトラップのパケット・サイズを制限する場合に、oracle.sysman.core.notification.snmp_packet_lengthパラメータを3072 bytes (3K)より低く設定しないことをお薦めします。

Enterprise Manager 12c MIBにはEnterprise Manager 12c以前のすべてのMIB定義が含まれます。そのため、サード・パーティ・システムにEnterprise Manager 12c MIBがあれば、Enterprise Manager 12c以前のサイトとEnterprise Manager 12cのサイトの両方からSNMPトラップを受信できます。リリース・マッピングの詳細は、付録C「SNMPトラップのマッピング」を参照してください。

3.6 管理情報ベース(MIB)

Enterprise Manager Cloud Controlは、サード・パーティのSNMP対応アプリケーションにSNMPトラップを送信できます。トラップ・コンテンツの詳細は、管理情報ベース(MIB)変数から取得できます。次の項では、Enterprise ManagerのMIB変数を詳しく説明します。

3.6.1 MIBについて

MIBはASN.1表記で記述されたテキスト・ファイルで、SNMPがアクセスできる情報を含む変数を説明します。MIBオブジェクトとも呼ばれるMIBに記述されている変数は、SNMPを使用して監視できるアイテムです。監視される要素ごとに1つのMIBがあります。各モノリシックまたはサブエージェントは、取得できる変数とその特性を調べるために、それぞれのMIBを調べます。この情報のMIBへのカプセル化により、マスター・エージェントは新しいサブエージェントを動的に登録できます。マスター・エージェントがサブエージェントについて知る必要のあるすべての情報が、そのMIBに含まれています。管理フレームワークと管理アプリケーションも、同じ目的でこれらのMIBを調べます。MIBは、標準(パブリックとも呼びます)または固有(プライベートまたはベンダーとも呼びます)のいずれかです。

変数の実際の値はMIB内にはなく、計測というプラットフォーム対応プロセスによって取得されます。すべてのSNMP通信は1つ以上のMIBオブジェクトを参照するため、MIBの概念は非常に重要です。実質的にはMIB変数およびその現在の値が、フレームワークに転送されます。

3.6.2 MIB定義

SNMP MIBファイルは次の場所にあります。

OMS_HOME/network/doc/omstrap.v1

注意:
omstrap.v1ファイルはSNMP V1とSNMP V3の両方と互換性があります。

ファイルomstrap.v1はOMS MIBです。

詳細は、付録A「Enterprise Manager MIBの変数の解釈」を参照してください。

omstrap.v1のハードコピーは、付録B「Enterprise Manager MIBの定義」で参照できます。

SNMP OID値の長さは、デフォルトで2560バイトに制限されます。emomsプロパティoracle.sysman.core.notification.snmp.max_oid_lengthを構成してデフォルト制限を変更します。

Enterprise Manager 12cでは、SNMPトラップはイベント通知に対してのみ配信されます。SNMPトラップ通知は、インシデントまたは問題に対してはサポートされません。

注意:
以前のバージョンのEnterprise Manager(12cより前)を使用して定義されたSNMP拡張通知メソッドは、変更しなくても機能を続けます。トラップは、古いEnterprise Manager MIB定義に準拠します。

3.6.3 MIB変数の説明の解釈

この項ではMIB変数の説明に使用される形式を説明します。SNMP MIB定義バージョン1のSTATUS要素は、このMIB変数の説明には含まれないので注意してください。OracleではすべてのMIB変数がCURRENTとして実装されるため、この値は変化しません。

3.6.3.1 変数名

構文

SNMP MIB定義バージョン1のSYNTAX要素にマップします。

最大アクセス

SNMP MIB定義バージョン1のMAX-ACCESS要素にマップします。

ステータス

SNMP MIB定義バージョン1のSTATUS要素にマップします。

説明

変数のファンクション、使用方法および正確な導出方法を説明します。(たとえば、変数は特定の構成ファイル・パラメータまたはパフォーマンス表フィールドから導出されます。)適切な場合は、MIB定義バージョン1のDESCRIPTION部分を組み込みます。

標準的な範囲

変数の論理的な範囲ではなく標準的な範囲を示します。たとえば、多くのMIB変数の整数値の論理的な上限は4294967295ですが、実際にインストールされたものの標準的な範囲はより小さくなります。その一方で、大規模データベースのいくつかの変数値が実際にはこの論理的限界(ラップアラウンド)を超える場合があります。変数値の標準的な範囲を0から1,000または1,000から30億に指定することによって、サード・パーティの開発者がその変数の最も便利なグラフィック表示を開発することができます。

重要度

標準的なインストールの監視時における変数の重要度を示します。重要度の段階は「高」、「中」、「低」または「通常は使用されない」です。DBAは、ある変数を他の変数よりも厳密に監視することが必要になります。ただしこのカテゴリに当てはまる変数は、アプリケーション、データベース・サイズおよびDBAの目的などに応じてインストールごとに異なる可能性があります。それでも、MIBの他の変数に対する変数の重要度を評価することによって、多くのDBAにとって最も関心のある変数に対し、サード・パーティの開発者が集中的に開発作業を行うことができます。

関連する変数

この変数に関連している、このMIBまたはOracleで実装済の他のMIBの変数を列記します。たとえば、この変数の値は別のMIB変数の値から導出されている可能性があります。また、この変数の値が別の変数の値と反比例している場合もあります。この情報を得ることによって、サード・パーティの開発者が関連するMIB変数の便利なグラフィック表示を開発できます。

推奨される表示方法

管理アプリケーションを使用しているDBAにとって最も役立つように、この変数を表示する方法(単純な値、ゲージまたはアラームとしてなど)を示します。

3.7 修正処理ステータス変更情報の受渡し

修正処理ステータス変更属性(新規ステータス、ジョブ名、ジョブ・タイプ、ルール所有者など)をPL/SQLプロシージャまたはOSコマンドやスクリプトに渡すことで、ステータス変更に対する自動レスポンスをカスタマイズできます。たとえば、クリティカルな修正処理の実行が失敗した場合に、OSスクリプトをコールして、社内サポート用トラブル・チケット・システムに対するトラブル・チケットを開くとします。この場合、ステータス(「問題」や「中断」など)をスクリプトに渡してトラブル・チケットを開き、問題を提示します。

3.7.1 OSコマンドまたはスクリプトへの修正処理実行ステータスの受渡し

通知システムは、システム環境変数を介してOSスクリプトまたは実行可能ファイルに情報を渡します。環境変数へのアクセスに使用される表記規則は、オペレーティング・システムによって異なります。

- UNIX: $ENV_VARIABLE

- MS Windows: %ENV_VARIABLE%

通知システムは、スクリプトをコールする前に次の環境変数を設定します。通知システムは、修正処理実行用の環境変数$NOTIF_TYPE = NOTIF_CAを設定します。スクリプトはスクリプト・ロジック内でこれらの変数の一部またはすべてを使用します。

次の表に、修正処理の環境変数をリストします。これらは、イベントに対して修正処理が完了したときに移入されます。

表3-13 修正処理環境変数

環境変数

説明

CA_JOB_STATUS

修正処理ジョブの実行ステータス。

CA_JOB_NAME

修正処理の名前。

CA_JOB_OWNER

修正処理の所有者。

CA_JOB_STEP_OUTPUT

値は修正処理の実行からのテキスト出力です。

CA_JOB_TYPE

修正処理ジョブのタイプ。

3.7.2 PL/SQLプロシージャへの修正処理実行ステータスの受渡し

通知システムは、修正処理のステータス変更情報をPL/SQLプロシージャPROCEDURE p(event_msg IN gc$notif_event_msg)に渡します。event_msg. msg_info. notification_typeがGC$NOTIFICATIONNOTIF_CAと等しい場合、インスタンスgc$notif_corrective_action_jobオブジェクトはevent_msg.event_payload. corrective_actionで定義されます。修正処理が実行されると、通知システムはインシデント・ルールに関連付けられているPL/SQLプロシージャをコールして、移入されたオブジェクトをプロシージャに渡します。これにより、プロシージャは渡されたオブジェクトのフィールドにアクセスできます。詳細は、表3-44「修正処理ジョブに固有の属性」を参照してください。

次のステータス・コードは、MGMT_NOTIFY_CORRECTIVE_ACTIONオブジェクトのjob_statusフィールドに使用可能な値です。

表3-14 修正処理ステータス・コード

名前

データタイプ

値

SCHEDULED_STATUS

NUMBER(2)

1

EXECUTING_STATUS

NUMBER(2)

2

ABORTED_STATUS

NUMBER(2)

3

FAILED_STATUS

NUMBER(2)

4

COMPLETED_STATUS

NUMBER(2)

5

SUSPENDED_STATUS

NUMBER(2)

6

AGENTDOWN_STATUS

NUMBER(2)

7

STOPPED_STATUS

NUMBER(2)

8

SUSPENDED_LOCK_STATUS

NUMBER(2)

9

SUSPENDED_EVENT_STATUS

NUMBER(2)

10

SUSPENDED_BLACKOUT_STATUS

NUMBER(2)

11

STOP_PENDING_STATUS

NUMBER(2)

12

SUSPEND_PENDING_STATUS

NUMBER(2)

13

INACTIVE_STATUS

NUMBER(2)

14

QUEUED_STATUS

NUMBER(2)

15

FAILED_RETRIED_STATUS

NUMBER(2)

16

WAITING_STATUS

NUMBER(2)

17

SKIPPED_STATUS

NUMBER(2)

18

REASSIGNED_STATUS

NUMBER(2)

20

3.8 ジョブ実行ステータス情報の受渡し

ジョブ・ステータス変更属性(新規ステータス、ジョブ名、ジョブ・タイプ、ルール所有者など)をPL/SQLプロシージャまたはOSコマンドやスクリプトに渡すことで、ステータス変更に対する自動レスポンスをカスタマイズできます。たとえば、クリティカルなジョブの実行が失敗した場合に、OSスクリプトをコールして、社内サポート用トラブル・チケット・システムに対するトラブル・チケットを開くとします。この場合、ステータス(「問題」や「中断」など)をスクリプトに渡してトラブル・チケットを開き、問題を提示します。ジョブ実行ステータス情報は、イベント・タイプの1つ(job_status_changeイベント)であり、第3.3項「OSコマンドおよびスクリプトを使用した通知の送信」および第3.4項「PL/SQLプロシージャを使用した通知の送信」で説明しているように、その内容はOSコマンドとPL/SQLペイロードにあります。

3.8.1 PL/SQLプロシージャへのジョブ実行ステータスの受渡し

通知システムは、event_typeがjob_status_changeと等しいevent_msg.event_payloadオブジェクトを介してPL/SQLプロシージャにジョブ・ステータス変更情報を渡します。このオブジェクトのインスタンスは、ステータス変更ごとに作成されます。ジョブがステータスを変更すると、通知システムはインシデント・ルールに関連付けられているPL/SQL p(event_msg IN gc$notif_event_msg)プロシージャをコールして、移入されたオブジェクトをプロシージャに渡します。これにより、プロシージャは渡されたevent_msg.event_payloadオブジェクトのフィールドにアクセスできます。

表3-15に、受渡し可能なすべての修正処理ステータス変更の属性を示します。

表3-15 ジョブ・ステータス属性

属性

データタイプ

属性情報

event_msg.event_payload.source.source_name

VARCHAR2(128)

ジョブの名前。

event_msg.event_payload.source.source_owner

VARCHAR2(256)

ジョブの所有者。

event_msg.event_payload.source.source_sub_type

VARCHAR2(32)

ジョブのタイプ。

event_attrs(i).name=' execution_status'のevent_msg.event_payload. event_attrs(i).value

NUMBER

ジョブの新しいステータス。

event_attrs(i).name='state_change_guid'のevent_msg.event_payload. event_attrs(i).value

RAW(16)

状態変更レコードのGUID。

event_msg.event_payload.source.source_guid

RAW(16)

ジョブの一意のID。

event_attrs(i).name=' execution_id'のevent_msg target.event_payload. event_attrs(i).value

RAW(16)

実行の一意のID。

event_msg.event_payload.target

gc$notif_target

ターゲット情報オブジェクト。

event_msg.msg_info.rule_owner

VARCHAR2(64)

通知の送信を誘発する通知ルールの名前。

event_msg.msg_info.rule_name

VARCHAR2(132)

通知の送信を誘発する通知ルールの所有者。

event_msg.event_payload. reported_date

DATE

ステータス変更が発生した日時。

ジョブのジョブ・ステータス変更が発生すると、通知システムはevent_attrs(i).name=' execution_status'のevent_msg.event_payload. event_attrs(i).valueオブジェクトのインスタンスを作成し、ステータス変更の値を移入します。次のステータス・コードは、MGMT_JOBSパッケージに定数として定義され、event_attrs(i).name=' execution_status'のevent_msg.event_payload. event_attrs(i).valueオブジェクトのjob_statusフィールドのステータス・タイプを判断するために使用できます。

表3-16 ジョブ・ステータス・コード

名前

データタイプ

値

SCHEDULED_STATUS

NUMBER(2)

1

EXECUTING_STATUS

NUMBER(2)

2

ABORTED_STATUS

NUMBER(2)

3

FAILED_STATUS

NUMBER(2)

4

COMPLETED_STATUS

NUMBER(2)

5

SUSPENDED_STATUS

NUMBER(2)

6

AGENTDOWN_STATUS

NUMBER(2)

7

STOPPED_STATUS

NUMBER(2)

8

SUSPENDED_LOCK_STATUS

NUMBER(2)

9

SUSPENDED_EVENT_STATUS

NUMBER(2)

10

SUSPENDED_BLACKOUT_STATUS

NUMBER(2)

11

STOP_PENDING_STATUS

NUMBER(2)

12

SUSPEND_PENDING_STATUS

NUMBER(2)

13

INACTIVE_STATUS

NUMBER(2)

14

QUEUED_STATUS

NUMBER(2)

15

FAILED_RETRIED_STATUS

NUMBER(2)

16

WAITING_STATUS

NUMBER(2)

17

SKIPPED_STATUS

NUMBER(2)

18

REASSIGNED_STATUS

NUMBER(2)

20

例3-16 ステータス・コード(Job)を使用するPL/SQLプロシージャ

CREATE  TABLE job_log (jobid RAW(16), status_code NUMBER(2), occured DATE);

CREATE OR REPLACE PROCEDURE LOG_JOB_STATUS_CHANGE(event_msg IN GC$NOTIF_EVENT_MSG)
IS
l_attrs gc$notif_event_attr_array;
exec_status_code NUMBER(2) := NULL;
occured_date DATE := NULL;
job_guid RAW(16) := NULL;

BEGIN
IF event_msg.event_payload.event_type = 'job_status_change'
THEN
l_attrs := event_msg.event_payload.event_attrs;
IF l_attrs IS NOT NULL
THEN
FOR i IN 1..l_attrs.COUNT
LOOP
IF l_attrs(i).name = 'exec_status_code'
THEN
exec_status_code := TO_NUMBER(l_attrs(i).value);
END IF;
END LOOP;
END IF;

occured_date := event_msg.event_payload.reported_date;
job_guid := event_msg.event_payload.source.source_guid;
-- Log all jobs' status
BEGIN
INSERT INTO job_log (jobid, status_code, occured)
VALUES (job_guid, exec_status_code, occured_date);
EXCEPTION
WHEN OTHERS
THEN
-- If there are any problems then get the notification retried
RAISE_APPLICATION_ERROR(-20000, 'Please retry');
END;
COMMIT;

ELSE
null; -- it is not a job_status_change event, ignore
END IF;
END LOG_JOB_STATUS_CHANGE;
/

3.8.2 OSコマンドまたはスクリプトへのジョブ実行ステータスの受渡し

通知システムは、システム環境変数を介してOSスクリプトまたは実行可能ファイルにジョブ実行ステータス情報を渡します。環境変数へのアクセスに使用される表記規則は、オペレーティング・システムによって異なります。

- UNIX: $ENV_VARIABLE

- MS Windows: %ENV_VARIABLE%

通知システムは、スクリプトをコールする前に次の環境変数を設定します。スクリプトはスクリプト・ロジック内でこれらの変数の一部またはすべてを使用します。

表3-17 環境変数

環境変数

説明

SOURCE_OBJ_NAME

ジョブの名前。

SOURCE_OBJ_OWNE

ジョブの所有者。

SOURCE_OBJ_SUB_TYPE

ジョブのタイプ。

EXEC_STATUS_CODE

ジョブのステータス。

EVENT_REPORTED_TIME

重大度が発生した時刻。

TARGET_NAME

ターゲットの名前。

TARGET_TYPE

ターゲットのタイプ。

RULE_NAME

重大度発生の原因となった通知ルールの名前。

RULE_OWNER

通知ルールを所有するEnterprise Manager管理者の名前。

3.9 ユーザー定義のターゲット・プロパティの通知メソッドへの受渡し

Enterprise Managerでは、ターゲットに固有の環境または使用コンテキスト情報の格納に使用できるターゲット・プロパティ(ターゲットのホームページからアクセス)を定義できます。ターゲット・プロパティ値はカスタム通知メソッドに渡され、そこで条件ロジックを使用して処理するか、チケット・システムなどのサード・パーティ・デバイスに追加のアラート情報として単純に渡すことができます。デフォルトでは、Enterprise Managerは定義されているすべてのターゲット・プロパティを通知メソッドに渡します。

注意:
短い電子メール書式が使用されている場合は、ターゲット・プロパティは通知メソッドに渡されません。

図3-3 ホスト・ターゲットのプロパティ

3.10 通知のリファレンス

この項には、次のリファレンス情報が含まれます。

- EMOMSプロパティ

- OSコマンドまたはスクリプトへのイベント、インシデント、問題情報の受渡し

- PL/SQLプロシージャへの情報の受渡し

- 通知に関するトラブルシューティング

3.10.1 EMOMSプロパティ

EMOMSプロパティを使用して、短い電子メールのサイズと形式を制御できます。次の表に、通知システムのemomsプロパティをリストします。

表3-18 通知のemomsプロパティ

プロパティ名

デフォルト値

説明

oracle.sysman.core.notification.emails_per_minute

250

1分当たりの電子メール配信制限。通知システムは、この値を使用して、1分当たりの電子メール配信の数を抑制します。顧客は、電子メール・サーバーをオーバーフローさせない必要がある場合には値を低く設定し、電子メール・サーバーが大量の電子メールを処理できる場合には高い値を設定する必要があります。

oracle.sysman.core.notification.cmds_per_minute

100

1分当たりのOSコマンド配信制限。通知システムは、この値を使用して、1分当たりのOSコマンド配信の数を抑制します。

oracle.sysman.core.notification.os_cmd_timeout

30

OSコマンド配信タイムアウト(秒単位)。この値は、OSプロセスがOSコマンド配信を実行できる時間の長さを示します。OSコマンド・スクリプトの実行の完了に長時間かかる場合は、この値を大きく設定します。

oracle.sysman.core.notification.plsql_per_minute

250

1分当たりのPL/SQL配信制限。通知システムは、この値を使用して、1分当たりのPL/SQL配信の数を抑制します。

em.notification.java_per_minute

500

1分当たりのJAVA配信制限。通知システムは、この値を使用して、1分当たりのJava配信の数を抑制します。

em.notification.ticket_per_minute

250

1分当たりのチケット配信制限。通知システムは、この値を使用して、1分当たりのチケット配信の数を抑制します。

oracle.sysman.core.notification.traps_per_minute

250

1分当たりのSNMP配信制限。通知システムは、この値を使用して、1分当たりのSNMPトラップの数を制御します。

oracle.sysman.core.notification.locale.plsql

OMSロケール

このプロパティは、詳細PL/SQL通知で配信されるロケールを指定します。顧客は、このプロパティを定義して、OMSがインストールされているデフォルト・ロケールを上書きできます。

有効なロケールは次のとおりです。

- en (英語)

- de (ドイツ語)

- es (スペイン語)

- fr (フランス語)

- it (イタリア語)

- ja (日本語)

- ko (韓国語)

- pt_br (ポルトガル語(ブラジル))

- zh_cn (簡体字中国語)

- zh_tw (繁体字中国語)

oracle.sysman.core.notification.locale.email

OMSロケール

このプロパティは、電子メールで配信されるロケールを指定します。顧客は、このプロパティを定義して、OMSがインストールされているデフォルト・ロケールを上書きできます。

有効なロケールは次のとおりです。

- en (英語)

- de (ドイツ語)

- es (スペイン語)

- fr (フランス語)

- it (イタリア語)

- ja (日本語)

- ko (韓国語)

- pt_br (ポルトガル語(ブラジル))

- zh_cn (簡体字中国語)

- zh_tw (繁体字中国語)

oracle.sysman.core.notification.locale.oscmd

OMSロケール

このプロパティは、OSコマンドで配信されるロケールを指定します。顧客は、このプロパティを定義して、OMSがインストールされているデフォルト・ロケールを上書きできます。

有効なロケールは次のとおりです。

- en (英語)

- de (ドイツ語)

- es (スペイン語)

- fr (フランス語)

- it (イタリア語)

- ja (日本語)

- ko (韓国語)

- pt_br (ポルトガル語(ブラジル))

- zh_cn (簡体字中国語)

- zh_tw (繁体字中国語)

oracle.sysman.core.notification.locale.snmp

OMSロケール

このプロパティは、SNMPトラップで配信されるロケールを指定します。顧客は、このプロパティを定義して、OMSがインストールされているデフォルト・ロケールを上書きできます。

有効なロケールは次のとおりです。

- en (英語)

- de (ドイツ語)

- es (スペイン語)

- fr (フランス語)

- it (イタリア語)

- ja (日本語)

- ko (韓国語)

- pt_br (ポルトガル語(ブラジル))

- zh_cn (簡体字中国語)

- zh_tw (繁体字中国語)

oracle.sysman.core.notification.oscmd.max_env_var_length

512

OS Common環境変数値の最大の長さ。

oracle.sysman.core.notification.snmp.max_oid_length

2560

SNMP OID値の最大の長さ。

oracle.sysman.core.notification.min_delivery_threads

6

初期のスレッド・プール内のアクティブ・スレッドの最小数およびシステムのアクティビティが少ないときに実行されているアクティブ・スレッドの数。大きい値を設定すると、より多くのシステム・リソースが使用され、より多くの通知が配信されます。

oracle.sysman.core.notification.max_delivery_threads

24

システムのアクティビティが多いときのスレッド・プール内のアクティブ・スレッドの最大数。この値は、em.notification.min_delivery_threadsより大きくする必要があります。大きい値を設定すると、より多くのシステム・リソースが使用され、より多くの通知が配信されます。

oracle.sysman.core.notification.short_format_length

>=1 (155)

短い電子メール形式の合計文字数のサイズ制限。顧客は、電子メールまたはページャのコンテンツ・サイズ制限に合わせて、このプロパティ値を変更する必要があります。短い形式の電子メールの通知では、電子メールの件名は最大80文字に制限されます。

oracle.sysman.core.notification.snmp_packet_length

<=1 (5120)

SNMPプロトコル・データ単位の最大サイズ。

oracle.sysman.core.notification.email_content_transfer_encoding

8-bit、7-bit(QP)、7-bit(BASE64)(8-bit)

電子メールをエンコードできる文字セット。Oracleでは、8-bit、7-bit(QP)、7-bit(BASE64)の3つの文字セットがサポートされます。

oracle.sysman.core.notification.emails_per_connection

>=1 (20)

次に使用可能な電子メール・ゲートウェイに切り替える前に、同じ電子メール・ゲートウェイに配信される電子メールの最大数(顧客が複数の電子メール・ゲートウェイを構成していると仮定した場合)。このプロパティは、電子メール・ゲートウェイのロード・バランシングに使用されます。

oracle.sysman.core.notification.short_format

both、subject、body (both)

件名と本文の両方、件名のみ、または本文のみで短い形式を使用します。

oracle.sysman.core.notification.send_prior_status_after_agent_unreachable_clears

TRUE

デフォルトでは、ターゲットのステータスが変更されていなくても、モニタリング・エージェントが使用不可ステータスでなくなるたびにターゲットのステータスを示す通知が送信されます。このemomsプロパティを使用して、重複するターゲット・ステータス通知を有効化(True)/無効化(False)します。

重複するターゲット・ステータス通知を無効化するには、このプロパティをFalseに設定します。

1. emctl set property oracle.sysman.core.notification.send_prior_status_after_agent_unreachable_clears -value false

2. OMSを再起動します。

重複するターゲット・ステータス通知を有効化するには、このプロパティをTrueに設定します。

1. emctl set property oracle.sysman.core.notification.send_prior_status_after_agent_unreachable_clears -value true

2. OMSを再起動します。

使用するデバイスでサポート可能な最大サイズと、メッセージを件名、本文、その両方のいずれの形式で送信するかを設定する必要があります。

emomsプロパティは、Enterprise Managerコマンドライン制御emctl get/set/delete/listプロパティ・コマンドを使用して変更できます。

注意:
次のコマンドは、変更を有効にするためにOMSの再起動を必要とします。

プロパティ・コマンドの取得

emctl get [-sysman_pwd "sysman password"]-name oracle.sysman.core.notification.short_format_length

プロパティ・コマンドの設定

emctl set  property -name oracle.sysman.core.notification.short_format_length -value 155

短い形式の電子メール用のEmomsプロパティ・エントリ

emctl set  property -name oracle.sysman.core.notification.short_format_length -value 155
emctl set property -name oracle.sysman.core.notification.short_format -value both

3.10.2 OSコマンドまたはスクリプトへのイベント、インシデント、問題情報の受渡し

通知システムは、システム環境変数を介してOSスクリプトまたは実行可能ファイルに情報を渡します。

環境変数へのアクセスに使用される表記規則は、オペレーティング・システムによって異なります。

- UNIX: $ENV_VARIABLE

- Windows: %ENV_VARIABLE%

通知システムは、スクリプトをコールする前に次の環境変数を設定します。スクリプトはスクリプト・ロジック内でこれらの変数の一部またはすべてを使用します。

3.10.2.1 イベント、インシデントおよび問題に共通の環境変数

表3-19 汎用的な環境変数

環境変数

説明

NOTIF_TYPE

通知のタイプと有効な値

NOTIF_NORMAL、

NOTIF_RETRY、

NOTIF_DURATION、

NOTIF_REPEAT、

NOTIF_CA、

NOTIF_RCA

REPEAT_COUNT

通知が送信された回数

(この通知より前)。

RULESET_NAME

この通知をトリガーしたルールセットの名前。

RULE_NAME

この通知をトリガーしたルールの名前。

RULE_OWNER

この通知をトリガーしたルールセットの所有者。

MESSAGE

イベント、インシデントまたは問題のメッセージ。

MESSAGE_URL

このメッセージのEMコンソールURL。

表3-20 カテゴリ関連の環境変数

環境変数

説明

CATEGORIES_COUNT

この通知内のカテゴリ数。1つのカテゴリがイベント、インシデントまたは問題に関連付けられている場合、この値は1です。イベント、インシデントまたは問題にカテゴリが関連付けられていない場合は0です。

CATEGORY_CODES_COUNT

この通知内のカテゴリ・コード数。

CATEGORY_n

カテゴリは、OMSサーバーで定義されているロケールに基づいて翻訳されます。接尾辞"_n"の有効値は1から$CATEGORIES_COUNTです。

CATEGORY_CODE_n

カテゴリのコード。接尾辞"_n"の有効値は1から$CATEGORY_CODES_COUNTです。

表3-21に、ユーザー定義ターゲット・プロパティに共通の環境変数を示します。これらは、(a)イベントに関連ターゲットがある場合、(b)インシデントまたは問題に単一のイベント・ソースと関連ターゲットがある場合に移入されます。

表3-21 ユーザー定義ターゲット・プロパティ環境変数

環境変数

説明

ORCL_GTP_COMMENT

コメント

ORCL_GTP_CONTACT

連絡先

ORCL_GTP_COST_CENTER

コストセンター

ORCL_GTP_DEPARTMENT

部門

ORCL_GTP_DEPLOYMENT_TYPE

デプロイ・タイプ

ORCL_GTP_LINE_OF_BUS

ライン・オブ・ビジネス

ORCL_GTP_LOCATION

場所

3.10.2.2 イベント通知固有の環境変数

表3-22 イベント通知固有の環境変数

環境変数

説明

EVENT_NAME

イベント名。

EVENT_REPORTED_TIME

イベントがレポートされた日付。

EVENT_SOURCE_COUNT

このイベントに関連付けられているソース数。

EVENT_TYPE

イベント・タイプ。

EVENT_OCCURRENCE_TIME

イベントの発生時刻。

EVENT_TYPE_ATTRS

イベント・タイプに固有の属性のリスト。

EVENT_CONTEXT_ATTRS

イベントのコンテキスト・データ。

LAST_UPDATED_TIME

最終更新時間

SEQUENCE_ID

一意のイベント順序識別子。イベント順序は、1つ以上のイベントで構成される場合があります。この順序のすべてのイベントは、同じイベント順序IDを持ちます。

SEVERITY

翻訳されたイベントの重大度。

SEVERITY_CODE

イベント重大度のコード。可能な値は次のとおりです。

FATAL、CRITICAL、WARNING、MINOR_WARNING、INFORMATIONALおよびCLEAR

ACTION_MSG

イベントを解決するために実行するアクションを説明するメッセージ。

TOTAL_OCCURRENCE_COUNT

重複発生の合計数

RCA_DETAILS

RCAがこのイベントに関連付けられているかどうか。

CURRENT_OCCURRENCE_COUNT

現在の収集期間におけるイベントの合計発生数。この属性は、重複解除済イベントにのみ適用されます。

CURRENT_FIRST_OCCUR_DATE

現在の収集期間においてイベントが最初に発生したときのタイムスタンプ。この属性は、重複解除済イベントにのみ適用されます。

CURRENT_LAST_OCCUR_DATE_DESC

現在の収集期間においてイベントが最後に発生したときのタイムスタンプ。この属性は、重複解除済イベントにのみ適用されます。

表3-23に、イベントに関連付けられているインシデントの環境変数を示します。これらは、イベントがインシデントに関連付けられている場合に移入されます。

表3-23 関連付けられているインシデント環境変数

環境変数

説明

ASSOC_INCIDENT_ACKNOWLEDGED_BY_OWNER

関連インシデントが所有者によって確認された場合はyesに設定します。

ASSOC_INCIDENT_ACKNOWLEDGED_DETAILS

関連インシデントの確認の詳細。例: No - 確認されていない場合。Yes By userName - 確認されている場合

ASSOC_INCIDENT_STATUS

関連インシデント・ステータス

ASSOC_INCIDENT_ID

関連インシデントID

ASSOC_INCIDENT_PRIORITY

関連インシデントの優先度。サポートされる値は、「緊急」、「非常に高」、「高」、「中」、「低」、「なし」です。

ASSOC_INCIDENT_OWNER

関連インシデントの所有者(存在する場合)。

ASSOC_INCIDENT_ESCALATION_LEVEL

関連インシデントのエスカレーション・レベルの値は0から5です。

表3-24に、ソース・オブジェクトに関連する共通の環境変数を示します。これらは、$SOURCE_OBJ_TYPEがTARGETでない場合に移入されます。

表3-24 ソース・オブジェクト関連の環境変数

環境変数

説明

SOURCE_OBJ_TYPE

ソース・オブジェクトのタイプ。例: JOB、TEMPLATE。

SOURCE_OBJ_NAME

ソース・オブジェクト名。

SOURCE_OBJ_NAME_URL

ソースのイベント・コンソールURL。

SOURCE_OBJ_SUB_TYPE

ソース・オブジェクトのサブタイプ。たとえば、ジョブ・ステータス変更イベントの基礎となるジョブ・タイプを提供します。

SOURCE_OBJ_OWNER

ソース・オブジェクトの所有者。

表3-25に、特定の問題に関連付けられた、ターゲットに共通の環境変数を示します。これらは、問題がターゲットに関連する場合に移入されます。

表3-25 ターゲット関連の環境変数

環境変数

説明

TARGET_NAME

ターゲットの名前

TARGET_TYPE

ターゲットのタイプ

TARGET_OWNER

ターゲットの所有者

HOST_NAME

ターゲットがデプロイされるホストの名前。

TARGET_URL

ターゲットのEnterprise ManagerコンソールURL。

TARGET_LIFECYCLE_STATUS

ターゲットのライフ・サイクル・ステータス。

有効な値: Production、Mission Critical、Stage、Test、Development。

定義されていない場合はnullです。

TARGET_VERSION

ターゲットのターゲット・バージョン

3.10.2.3 イベント・タイプに固有の環境変数

イベントは、複数のタイプに分類されます。たとえば、mertc_alertイベント・タイプはメトリック・アラートのモデル化に使用されます。SQL問合せを使用して、デプロイメントおよびイベント固有のペイロードのイベント・タイプをリストできます。次のSQLサンプルを使用して、Enterprise Managerに登録されているすべての内部イベント・タイプ名をリストできます。

Select event_class as event_type, upper(name) as env_var_name
from em_event_class_attrs
where notif_order != 0
and event_class is not null
union
select event_class as event_type, upper(name) || '_NLS' as env_var_name
from em_event_class_attrs
where notif_order != 0
and event_class is not null
and is_translated = 1
order by event_type, env_var_name;

各イベント・タイプに固有の環境変数ペイロードには、OSスクリプトを通じてアクセスできます。次の表に、最もクリティカルなイベント・タイプの通知属性をリストします。

表3-26 メトリック・アラート・イベント・タイプに固有の環境変数

環境変数

説明

COLL_NAME

メトリックを収集するコレクションの名前。

COLL_NAME_NLS

メトリックを収集するコレクションの翻訳された名前

KEY_COLUMN_X

キー列Xの内部名(Xは1から7の数値)。

KEY_COLUMN_X_NLS

キー列Xの翻訳された名前(Xは1から7の数値)。

KEY_COLUMN_X_VALUE

キー列Xの値(Xは1から7の数値)。

KEY_VALUE

メトリック・アラート・イベントに対応するメトリックの監視対象オブジェクト。

METRIC_COLUMN

メトリック列の名前

METRIC_COLUMN_NLS

メトリック列の翻訳された名前。

METRIC_DESCRIPTION

メトリックの簡単な説明。

METRIC_DESCRIPTION_NLS

メトリックの翻訳された簡単な説明。

METRIC_GROUP

メトリックの名前。

METRIC_GROUP_NLS

メトリックの翻訳された名前

NUM_KEYS

メトリック内のキー・メトリック列の数。

SEVERITY_GUID

このメトリック・アラートに関連付けられている重大度レコードのGUID。

CYCLE_GUID

メトリック・アラートが最初に生成されたときからクリアされるまでの、メトリック・アラート・サイクルの一意の識別子。

VALUE

イベントがトリガーされたときのメトリックの値。

表3-27 ターゲット可用性イベント・タイプに固有の環境変数

環境変数

説明

AVAIL_SEVERITY

ターゲットのステータスが現在の可用性ステータスに変更された要因である遷移重大度。

AVAIL_SEVERITYに指定できる値

- 15 (ターゲット起動)

- 25 (ターゲット停止)

- 115 (エージェント使用不可、クリア済)

- 125 (エージェント使用不可)

- 215 (ブラックアウト終了)

- 225 (ブラックアウト開始)

- 315 (収集エラー、クリア済)

- 325 (収集エラー)

- 425 (使用可能なビーコンなし)

- 515 (ステータス不明)

AVAIL_SUB_STATE

現在のステータスに対するターゲットのサブステータス。

CYCLE_GUID

メトリック・アラートが最初に生成されたときからクリアされるまでの、メトリック・アラート・サイクルの一意の識別子。

METRIC_GUID

レスポンス・メトリックのメトリックGUID。

SEVERITY_GUID

この可用性ステータスに関連付けられている重大度レコードのGUID。

TARGET_STATUS

ターゲットの現在の可用性のステータス。

TARGET_STATUS_NLS

ターゲットの翻訳された現在の可用性のステータス。

表3-28 ジョブ・ステータスの変更イベント・タイプに固有の環境変数

環境変数

説明

EXECUTION_ID

ジョブ実行の一意のID。

EXECUTION_LOG

実行された最後のステップのジョブ出力。

EXECUTION_STATUS

ジョブ実行の内部ステータス。

EXECUTION_STATUS_NLS

ジョブ実行の翻訳されたステータス。

EXEC_STATUS_CODE

ジョブ実行の実行ステータス・コード。可能な値は、表3-16「ジョブ・ステータス・コード」を参照してください。

STATE_CHANGE_GUID

最新ステータス変更の一意のID

SQL問合せを使用して、デプロイされているイベント・タイプと各イベント・タイプに固有のペイロードをリストできます。次のSQLを使用して、Enterprise Managerに登録されているすべての内部イベント・タイプ名をリストできます。

select class_name as event_type_name from em_event_class;

次のSQLは、metric_alertイベント・タイプに固有の環境変数をリストします。

select env_var_name
from
( Select event_class as event_type, upper(name) as env_var_name
from em_event_class_attrs
where notif_order != 0
and event_class is not null
union
select event_class as event_type, upper(name) || '_NLS' as env_var_name
from em_event_class_attrs
where notif_order != 0
and event_class is not null
and is_translated = 1)
where event_type = 'metric_alert';

Enterprise Managerコンソールから、イベント・タイプに固有の通知属性の説明を直接取得することもできます。

1. 「設定」メニューから、「通知」、「電子メール形式のカスタマイズ」の順に選択します。

2. イベント・タイプを選択します。

3. 「カスタマイズ」をクリックします。

4. 「事前定義済属性の表示」をクリックします。

接尾辞_NLSで終わる環境変数は、特定の属性の翻訳された値を提供します。たとえば、METRIC_COLUMN_NLS環境変数は、メトリック列属性の翻訳された値を提供します。翻訳された値は、OMSのロケールになります。

3.10.2.4 インシデント通知に固有の環境変数

表3-29 インシデント固有の環境変数

環境変数

説明

SEVERITY

翻訳されたインシデント重大度。有効な値: 「致命的」、「クリティカル」、「警告」、「情報」、「クリア」

SEVERITY_CODE

重大度のコード。

可能な値は次のとおりです。

FATAL、CRITICAL、WARNING、MINOR_WARNING、INFORMATIONALおよびCLEAR

INCIDENT_REPORTED_TIME

インシデント報告時間

INCIDENT_ACKNOWLEDGED_BY_OWNER

インシデントが所有者によって確認された場合はyesに設定します。

INCIDENT_ID

インシデントID

INCIDENT_OWNER

インシデント所有者

ASSOC_EVENT_COUNT

このインシデントに関連付けられているイベント数。

INCIDENT_STATUS

インシデント・ステータス。2つの内部修正解決ステータスがあります。

NEW

CLOSED

ユーザーはステータスを追加で定義できます。

ESCALATED

インシデントはエスカレートされます。

ESCALATED_LEVEL

インシデントのエスカレートされたレベル。

PRIORITY

インシデント優先度。翻訳された優先度名です。有効な値: 「緊急」、「非常に高」、「高」、「中」、「低」、「なし」

PRIOTITY_CODE

インシデント優先度コード

EMで定義されている内部値です。

PRIORITY_URGENT

PRIORITY_VERY_HIGH

PRIORITY_HIGH

PRIORITY_MEDIUM

PRIORITY_LOW

PRIORITY_NONE

TICKET_STATUS

外部チケットのステータス(存在する場合)。

TICKET_ID

外部チケットのID(存在する場合)。

LAST_UPDATED_TIME

インシデントの最終更新時間

ADR_INCIDENT_ID

自動診断リポジトリ(ADR)・インシデントID: ADRインシデントの一意の数値識別子。ADRインシデントは、問題の発生を示します。

ADR_IMPACT

自動診断リポジトリ(ADR)・インシデントの影響。

ADR_ECID

関連する自動診断リポジトリ(ADR)・インシデントに関連付けられた実行コンテキストID (ECID)。ECIDは、Oracleソフトウェア・スタックによって1回のコールにタグを付け、追跡するために使用するグローバルに一意の識別子です。スタックの複数の層にわたって発生する可能性のある問題を対応付けるために使用されます。

ASSOC_PROBLEM_KEY

自動診断リポジトリ(ADR)・インシデントに関連付けられた問題のキー。問題はOracle製品におけるクリティカルなエラーです。Problemのキーは、問題を説明するテキスト文字列です。エラー・コードと、場合によってはその他のエラー固有の値が含まれます。

表3-30に、インシデントが問題に関連付けられているときに関連する問題の環境変数を示します。

表3-30 インシデントが関連付けられている問題の環境変数

環境変数

説明

ASSOC_PROBLEM_ACKNOWLEDGED_BY_OWNER

この問題が所有者によって確認された場合はyesに設定します。

ASSOC_PROBLEM_STATUS

関連する問題のステータス

ASSOC_PROBLEM_ID

関連する問題のID

ASSOC_PROBLEM_PRIORITY

関連する問題の優先度

ASSOC_PROBLEM_OWNER

関連する問題の所有者(存在する場合)。

ASSOC_PROBLEM_ESCALATION_LEVEL

関連する問題のエスカレーション・レベルの値は0から5です。

3.10.2.5 問題通知に固有の環境変数

表3-31 問題に固有の環境変数

環境変数

説明

SEVERITY

翻訳された問題重大度。

SEVERITY_CODE

重大度のコード。

可能な値は次のとおりです。

FATAL、CRITICAL、WARNING、MINOR_WARNING、INFORMATIONALおよびCLEAR

PROBLEM_REPORTED_TIME

問題報告時間

PROBLEM_ACKNOWLEDGED_BY_OWNER

問題が所有者によって確認された場合はyesに設定します。

PROBLEM_ID

問題ID

PROBLEM_KEY

問題キー

PROBLEM_OWNER

問題所有者

ASSOC_INCIDENT_COUNT

この問題に関連付けられているインシデント数。

PROBLEM_STATUS

インシデント・ステータス。次のタイプです。

STATUS_NEW

STATUS_CLOSED

他の任意のユーザー定義ステータス。

ESCALATED

インシデントはエスカレートされます。エスカレートされている場合はYes、それ以外の場合はNoです。

ESCALATED_LEVEL

インシデントのエスカレートされたレベル。

PRIORITY

インシデント優先度。翻訳された優先度名です。

PRIOTITY_CODE

インシデント優先度コード

Enterprise Managerで定義されている内部値です。

PRIORITY_URGENT

PRIORITY_VERY_HIGH

PRIORITY_HIGH

PRIORITY_MEDIUM

PRIORITY_LOW

PRIORITY_NONE

LAST_UPDATED_TIME

最終更新時間

SR_ID

Oracleサービス・リクエストID(存在する場合)。

BUG_ID

OracleバグID(関連付けられているバグが存在する場合)。

3.10.2.6 インシデントおよび問題通知に共通の環境変数

インシデントまたは問題は、複数のイベント・ソースに関連付けることができます。イベント・ソースには、ターゲット、ソース・オブジェクトまたはその両方があります。

3.10.2.6.1 イベント・ソースに関連する環境変数

イベント・ソースの数は、EVENT_SOURCE_COUNT環境変数によって設定されます。EVENT_SOURCE_COUNT情報を使用して、関連する環境変数をループして複数のイベント・ソースに関する情報をフェッチするスクリプトを作成できます。すべてのイベント・ソースの環境変数にはEVENT_SOURCE_という接頭辞が付きます。ソース・オブジェクトの環境変数には、SOURCE_<attribute_name>という接尾辞が付きます。たとえば、EVENT_SOURCE_1_SOURCE_TYPEは、最初のイベント・ソースのソース・オブジェクト・タイプを提供します。ターゲットの環境変数には、TARGET_<attribute_name>という接尾辞が付きます。たとえば、EVENT_SOURCE_1_TARGET_NAMEは、最初のイベント・ソースのターゲット名を提供します。

次の表に、x番目のイベント・ソースのソース・オブジェクトの環境変数をリストします。

表3-32 x番目のイベント・ソースのソース・オブジェクト

環境変数

説明

EVENT_SOURCE_x_SOURCE_GUID

ソース・オブジェクトのGUID。

EVENT_SOURCE_x_SOURCE_TYPE

ソース・オブジェクト・タイプ

EVENT_SOURCE_x_SOURCE_NAME

ソース・オブジェクト名。

EVENT_SOURCE_x_SOURCE_OWNER

ソース・オブジェクトの所有者。

EVENT_SOURCE_x_SOURCE_SUB_TYPE

ソース・オブジェクトのサブタイプ。

EVENT_SOURCE_x_SOURCE_URL

EMコンソールへのソース・オブジェクトURL。

表3-33に、x番目のイベント・ソースのターゲットの環境変数を示します。

表3-33 x番目のイベント・ソースのターゲット

環境変数

説明

EVENT_SOURCE_x_TARGET_GUID

ターゲットGUID

EVENT_SOURCE_x_TARGET_NAME

ターゲット名。

EVENT_SOURCE_x_TARGET_OWNER

ターゲット所有者

EVENT_SOURCE_x_TARGET_VERSION

ターゲット・バージョン

EVENT_SOURCE_x_TARGET_LIFE_CYCLE_STATUS

ターゲットのライフ・サイクル・ステータス

EVENT_SOURCE_x_TARGET_TYPE

ターゲット・タイプ

EVENT_SOURCE_x_HOST_NAME

ターゲット・ホスト名

EVENT_SOURCE_x_TARGET_URL

EMコンソールへのターゲットURL。

3.10.3 PL/SQLプロシージャへの情報の受渡し

イベント、インシデントおよび問題情報(ペイロード)をPL/SQLプロシージャに渡すと、これらの条件に対する自動レスポンスをカスタマイズできます。3つの通知ペイロード・タイプすべてに、gc$notif_msg_infoという共通要素があります。これは、すべてのタイプの通知に適用される汎用情報を提供します。また、3つのペイロードそれぞれに、特定の問題タイプに固有のペイロードを提供する固有の要素が1つあります。

gc$notif_event_msg (イベント通知のペイロード)

gc$notif_event_msgには、イベント・ペイロード・オブジェクトとメッセージ情報オブジェクトの2つのオブジェクトが含まれます。

表3-34 イベント通知ペイロード

属性

データタイプ

属性情報

EVENT_PAYLOAD

gc$notif_event_payload

イベント通知ペイロード。詳細は、gc$notif_event_payloadタイプの定義を参照してください。

MSG_INFO

gc$notif_msg_info

通知メッセージ。詳細は、gc$notif_msg_infoの定義を参照してください。

gc$notif_incident_msg (インシデント通知のペイロード)

gc$notif_incident_msgタイプには、インシデント・ペイロードとメッセージ情報の2つのオブジェクトが含まれます。このオブジェクトは、インシデント通知メッセージの配信ペイロードを表し、インシデント通知に関連付けられているすべてのデータを含み、ユーザーのカスタムPL/SQLプロシージャでアクセスできます。

表3-35 インシデント通知ペイロード

属性

データタイプ

属性情報

INCIDENT_PAYLOAD

gc$notif_incident_payload

インシデント通知ペイロード。詳細は、gc$notif_incident_payloadタイプの定義を参照してください。

MSG_INFO

gc$notif_msg_info

エンベロープ・レベルの通知情報。詳細は、gc$notif_msg_infoタイプの定義を参照してください。

gc$notif_problem_msg (問題通知のペイロード)

このオブジェクトは、問題通知メッセージの配信ペイロードを表し、問題通知に関連付けられているすべてのデータを含み、ユーザーのカスタムPL/SQLプロシージャでアクセスできます。

表3-36 問題通知ペイロード

属性

データタイプ

属性情報

PROBLEM_PAYLOAD

gc$notif_problem_payload

問題通知ペイロード。詳細は、gc$notif_problem_payloadタイプの定義を参照してください。

MSG_INFO

gc$notif_msg_info

通知メッセージ。詳細は、gc$notif_msg_infoタイプの定義を参照してください。

gc$notif_msg_info (イベント/インシデント/問題に共通のペイロード)

このオブジェクトには、イベント、インシデントまたは問題配信ペイロードのnotification_type、ルール・セット、ルール名などの汎用通知情報が含まれます。

表3-37 イベント、インシデント、問題に共通のペイロード

属性

データタイプ

説明

NOTIFICATION_TYPE

VARCHAR2(32)

通知のタイプ。次のいずれかの値です。

GC$NOTIFICATION.NOTIF_NORMAL GC$NOTIFICATION.NOTIF_RETRY GC$NOTIFICATION.NOTIF_REPEAT GC$NOTIFICATION.NOTIF_DURATION

GC$NOTIFICATION.NOTIF_CA

GC$NOTIFICATION.NOTIF_RCA

REPEAT_COUNT

NUMBER

繰返し通知回数

RULESET_NAME

VARCHAR2(256)

通知をトリガーしたルール・セットの名前

RULE_NAME

VARCHAR2(256)

通知をトリガーしたルールの名前

RULE_OWNER

VARCHAR2(256)

ルール・セットを所有するEMユーザー

MESSAGE

VARCHAR2(4000)

イベント/インシデント/問題に関するメッセージ。

MESSAGE_URL

VARCHAR2(4000)

イベント/インシデント/問題の詳細を提供するEnterprise Managerコンソール・ページへのリンク。

gc$notif_event_payload (イベント通知に固有のペイロード)

このオブジェクトは、イベント通知に固有のペイロードを表します。

表3-38 イベント、インシデントおよび問題に共通のペイロード

属性

データタイプ

属性情報

EVENT_INSTANCE_GUID

RAW(16)

イベント・インスタンスのグローバル一意識別子。

EVENT_SEQUENCE_GUID

RAW(16)

イベント順序のグローバル一意識別子。

TARGET

gc$notif_target

関連ターゲット情報オブジェクト。詳細は、gc$notif_targetタイプの定義を参照してください。

SOURCE

gc$notif_source

ターゲットでない関連ソース情報オブジェクト。詳細は、gc$notif_sourceタイプの定義を参照してください。

EVENT_ATTRS

gc$notif_event_attr_array

イベントで指定された属性のリスト。詳細は、gc$notif_event_attrタイプの定義を参照してください。

CORRECTIVE_ACTION

gc$notif_corrective_action_job

修正処理ジョブの実行完了時にオプションで移入される修正処理情報。

EVENT_TYPE

VARCHAR2(20)

イベント・タイプ: 「メトリック・アラート」など。

EVENT_NAME

VARCHAR2(512)

イベント名。

EVENT_MSG

VARCHAR2(4000)

イベント・メッセージ。

REPORTED_DATE

DATE

イベントがレポートされた日付。

OCCURRENCE_DATE

DATE

イベント発生日。

SEVERITY

VARCHAR2(128)

イベントの重大度。翻訳された重大度名です。

SEVERITY_CODE

VARCHAR2(32)

イベントの重大度コード。Enterprise Managerで使用されている内部重大度名です。

ASSOC_INCIDENT

gc$notif_issue_summary

関連インシデントのサマリー。イベントがインシデントに関連付けられている場合に移入されます。詳細は、gc$notif_issue_summaryタイプの定義を参照してください。

ACTION_MSG

VARCHAR2(4000)

イベントを解決するために実行するアクションを説明するメッセージ。

RCA_DETAIL

VARCHAR2(4000)

根本原因分析の詳細。RCA詳細出力のサイズは、4000文字の長さに制限されます。

EVENT_CONTEXT_DATA

gc$notif_event_context_array

イベントのコンテキスト・データ。詳細は、gc$notif_event_contextタイプの定義を参照してください。

CATEGORIES

gc$category_string_array

イベントが属するカテゴリをリストします。カテゴリは、OMSサーバーで定義されているロケールに基づいて翻訳されます。通知システムは最大10個のカテゴリを送信します。

CATEGORY_CODES

gc$category_string_array

カテゴリのコード。配列のサイズは最大10です。

gc$notif_incident_payload (インシデント通知に固有のペイロード)

インシデント固有の属性、関連する問題およびチケット情報を含みます。

表3-39 インシデント通知ペイロード

属性

データタイプ

属性情報

INCIDENT_ATTRS

gc$notif_issue_attrs

インシデント固有の属性。詳細は、gc$notif_issue_attrsタイプの定義を参照してください。

ASSOC_EVENT_COUNT

NUMBER

このインシデントに関連付けられているイベントの総数。

TICKET_STATUS

VARCHAR2(64)

外部チケットのステータス(存在する場合)。

TICKET_ID

VARCHAR2(128)

外部チケットのID(存在する場合)。

TICKET_URL

VARCHAR2(4000)

外部チケットのURL(存在する場合)。

ASSOC_PROBLEM

gc$notif_issue_summary

関連付けられている問題がある場合、問題のサマリー。詳細は、gc$notif_issue_summaryタイプの定義を参照してください。

gc$notif_problem_payload (問題に固有のペイロード)

問題に固有の属性、キー、サービス・リクエスト(SR)およびバグ情報が含まれます。

表3-40 問題ペイロード

属性

データタイプ

属性情報

PROBLEM_ATTRS

gc$notif_issue_attrs

問題固有の属性。詳細は、gc$notif_issue_attrsタイプの定義を参照してください。

PROBLEM_KEY

VARCHAR2(850)

問題キー(生成されている場合)。

ASSOC_INCIDENT_COUNT

NUMBER

この問題に関連付けられているインシデント数。

SR_ID

VARCHAR2(64)

Oracleサービス・リクエストID(存在する場合)。

SR_URL

VARCHAR2(4000)

Oracleサービス・リクエストのURL(存在する場合)。

BUG_ID

VARCHAR2(64)

OracleバグID(関連付けられているバグが存在する場合)。

gc$notif_issue_attrs (インシデントと問題に共通のペイロード)

インシデントと問題に共通の詳細を提供します。関連付けられているID、重大度、優先度、ステータス、カテゴリ、所有者による確認、ソース情報などの詳細が含まれます。

表3-41 インシデントと問題に共通のペイロード

属性

データタイプ

属性情報

ID

NUMBER(16)

インシデントまたは問題のID。

SEVERITY

VARCHAR2(128)

問題の重大度。翻訳されています。

SEVERITY_CODE

VARCHAR2(32)

問題の重大度コード。可能な値は、重大度の降順に定義されています。

GC$EVENT.FATAL

GC$EVENT.CRITICAL

GC$EVENT.WARNING

GC$EVENT.MINOR_WARNING

GC$EVENT.INFORMATIONAL

GC$EVENT.CLEAR

PRIORITY

VARCHAR2(128)

問題の優先度。翻訳された優先度名です。

PRIORITY_CODE

VARCHAR2(32)

問題の優先度。EMで定義されている内部値です。可能な値は、優先度の降順に定義されています。

GC$EVENT.PRIORITY_URGENT GC$EVENT.PRIORITY_VERY_HIGH

GC$EVENT.PRIORITY_HIGH GC$EVENT.PRIORITY_MEDIUM

GC$EVENT.PRIORITY_LOW

GC$EVENT.PRIORITY_NONE

STATUS

VARCHAR2(32)

問題のステータス。有効な値は、次のとおりです。

GC$EVENT.STATUS_NEW

GC$EVENT.STATUS_CLOSED

他の任意のユーザー定義ステータス。

ESCALATION_LEVEL

NUMBER(1)

問題のエスカレーション・レベル。値は0から5です。

OWNER

VARCHAR(256)

問題の所有者。所有者が存在しない場合はNULLに設定します。

ACKNOWLEDGED_BY_OWNER

NUMBER(1)

この問題が所有者によって確認された場合は1に設定します。

CREATION_DATE

DATE

問題作成日。

CLOSED_DATE

DATE

問題がクローズされた日付。クローズされていない場合はnullです。

CATEGORIES

gc$category_string_array

イベントが属するカテゴリをリストします。カテゴリは、OMSサーバーで定義されているロケールに基づいて翻訳されます。通知システムは最大10個のカテゴリを送信します。

CATEGORY_CODES

gc$category_string_array

カテゴリのコード。通知システムは最大10個のカテゴリ・コードを送信します。

SOURCE_INFO_ARR

gc$notif_source_info_array

この問題に関連付けられているソース情報の配列。詳細は、$gcnotif_source_infoタイプの定義を参照してください。

LAST_MODIFIED_BY

VARCHAR2(256)

最終更新者。

LAST_UPDATED_DATE

DATE

最終更新日。

gc$notif_issue_summary (インシデントおよび問題ペイロードに共通)

それぞれイベント・ペイロード内の関連するインシデントのサマリー、またはインシデント・ペイロード内の関連する問題のサマリーを表します。

表3-42 ペイロード

属性

データタイプ

属性情報

ID

NUMBER

発行ID(インシデントIDまたは問題ID)。

SEVERITY

VARCHAR(128)

問題の重大度レベル。翻訳された重大度名です。

SEVERITY_CODE

VARCHAR2(32)

次のいずれかの値を持つ問題重大度コード。

GC$EVENT.FATAL

GC$EVENT.CRITICAL

GC$EVENT.WARNING

GC$EVENT.MINOR_WARNING

GC$EVENT.INFORMATIONAL

GC$EVENT.CLEAR

PRIORITY

VARCHAR2(128)

現在の優先度。翻訳された優先度名です。

PRIORITY_CODE

VARCHAR2(32)

次のいずれかの値を持つ問題優先度コード。GC$EVENT.PRIORITY_URGENT

GC$EVENT.PRIORITY_VERY_HIGH

GC$EVENT.PRIORITY_HIGH

GC$EVENT.PRIORITY_MEDIUM

GC$EVENT.PRIORITY_LOW

GC$EVENT.PRIORITY_NONE

STATUS

VARCHAR2(64)

問題のステータス。有効な値は、次のとおりです。

GC$EVENT.STATUS_NEW

GC$EVENT.STATUS_CLOSED

GC$EVENT.WIP(処理中)

GC$EVENT.RESOLVED

他の任意のユーザー定義ステータス

ESCALATION_LEVEL

VARCHAR2(2)

0から5の範囲の問題エスカレーション・レベル。デフォルトは0です。

OWNER

VARCHAR2(256)

問題の所有者。所有者が存在しない場合はNULLに設定します。

ACKNOWLEDGED_BY_OWNER

NUMBER(1)

この問題が所有者によって確認された場合は1に設定します。

gc$category_string_array

gc$category_string_arrayは、イベント、インシデントまたは問題が関連付けられているカテゴリを含む文字列配列です。通知システムは最大10カテゴリを提供します。

gc$notif_event_context_array

gc$notif_event_context_arrayは、イベント検出時に取得された追加の診断データに関する情報を提供します。通知システムは、取得したイベント・コンテキストから最大200個の要素を提供します。この配列の各要素のタイプは、gc$notif_event_contextです。

gc$notif_event_context: このオブジェクトは、診断値を含む可能性のある、イベントの生成時にソース・システムによって取得される追加のコンテキスト情報であるイベント・コンテキスト・データの詳細を表します。イベントのコンテキストは、キーと値のセット、およびデータ・タイプ(数値または文字列のみ)から構成される必要があります。

表3-43 イベント・コンテキスト・タイプ

属性

データタイプ

属性情報

NAME

VARCHAR2(256)

イベント・コンテキスト名。

TYPE

NUMBER(1)

格納される値のデータ・タイプ

(0) - 数値データの場合

(1) - 文字列データの場合。

VALUE

NUMBER

数値。

STRING_VALUE

VARCHAR2(4000)

文字列値。

gc$notif_corrective_action_job

修正処理ジョブの実行に関する情報を提供します。修正処理は、メトリック・アラートおよびターゲット可用性イベントでのみサポートされます。

表3-44 修正処理ジョブに固有の属性

属性

データタイプ

属性情報

JOB_GUID

RAW(16)

修正処理ジョブのグローバル一意識別子。

JOB_NAME

VARCHAR2(128)

値は修正処理の名前です。メトリック・アラートおよびターゲット可用性イベントに適用されます。

JOB_OWNER

VARCHAR2(256)

修正処理ジョブの所有者。

JOB_TYPE

VARCHAR2(256)

修正処理ジョブのタイプ。

JOB_STATUS

VARCHAR2(64)

修正処理ジョブの実行ステータス。

JOB_STATUS_CODE

NUMBER

修正処理ジョブの実行ステータス・コード。Enterprise Managerで定義されている内部値です。ステータス・コードの詳細は、表3-14「修正処理ステータス・コード」を参照してください。

JOB_STEP_OUTPUT

VARCHAR2(4000)

値は修正処理の実行からのテキスト出力です。これは最後の4000文字に切り捨てられます。

JOB_EXECUTION_GUID

RAW(16)

修正処理ジョブ実行のグローバル一意識別子。

JOB_STATE_CHANGE_GUID

RAW(16)

修正処理ジョブ変更のグローバル一意識別子。

OCCURRED_DATE

DATE

修正処理ジョブの発生日。

gc$notif_source_info_array

インシデントまたは問題に関連する可能性のある複数のソースへのアクセスを提供します。注意: 通知システムは、インシデントまたは問題に関連付けられている最大200のソースを提供します。

CREATE OR REPLACE TYPE gc$notif_source_info_array AS VARRAY(200) OF gc$notif_source_info;

gc$notif_source_info

ターゲットまたはソース、あるいはその両方を含むソース情報の参照に使用される通知ソース情報。

表3-45 ソース情報タイプ

属性

データタイプ

属性情報

TARGET

gc$notif_target

イベントがターゲットに関連する場合に移入されます。詳細は、gc$notif_targetタイプの定義を参照してください。

SOURCE

gc$notif_source

イベントが(ターゲットでない)ソースに関連する場合に移入されます。詳細は、gc$notif_sourceタイプの定義を参照してください。

gc$notif_source

ジョブ・ターゲット以外のソース・オブジェクトの参照に使用されます。

表3-46 ペイロード

属性

データタイプ

属性情報

SOURCE_GUID

RAW(16)

ソースのグローバル一意識別子。

SOURCE_TYPE

VARCHAR2(120)

TARGET、JOB、TEMPLATEなど、ソース・オブジェクトのタイプ。

SOURCE_NAME

VARCHAR2(256)

ソース・オブジェクト名。

SOURCE_OWNER

VARCHAR2(256)

ソース・オブジェクトの所有者。

SOURCE_SUB_TYPE

VARCHAR2(256)

ソース・オブジェクトのサブタイプ。たとえばTARGETでは、ホストやデータベースなどのターゲット・タイプになります。

SOURCE_URL

VARCHAR2(4000)

ソースのイベント・コンソールURL。

gc$notif_target

ターゲット情報オブジェクトは、ターゲット情報を提供するために使用されます。

表3-47 ターゲット情報

属性

データタイプ

属性情報

TARGET_GUID

RAW(16)

ターゲットのグローバル一意識別子。

TARGET_NAME

VARCHAR2(256)

ターゲットの名前。

TARGET_OWNER

VARCHAR2(256)

ターゲットの所有者。

TARGET_LIFECYCLE_STATUS

VARCHAR2(1024)

ターゲットのライフ・サイクル・ステータス。

TARGET_VERSION

VARCHAR2(64)

ターゲットのターゲット・バージョン。

TARGET_TYPE

VARCHAR2(128)

ターゲットのタイプ。

TARGET_TIMEZONE

VARCHAR2(64)

ターゲットの地域タイム・ゾーン。

HOST_NAME

VARCHAR2(256)

ターゲットがデプロイされるホストの名前。

TARGET_URL

VARCHAR2(4000)

ターゲットのEMコンソールURL。

UDTP_ARRAY

gc$notif_udtp_array

ユーザーが定義したターゲット・プロパティのリスト。ターゲットに関連付けられているイベントに対して移入されます。単一のソース(gc$notif_source_info)に関連付けられている場合に、インシデントと問題に対して移入されます。

gc$notif_udtp_array

最大サイズが20のgc$notif_udtpタイプの配列。

CREATE OR REPLACE TYPE gc$notif_udtp_array AS VARRAY(20) OF gc$notif_udtp;

gc$notif_udtp

ユーザー定義のターゲット・プロパティを参照するために使用されます。UDTPは、プロパティ・キー名とプロパティ値のセットで構成される必要があります。

表3-48 ペイロード

属性

データタイプ

属性情報

NAME

VARCHAR2(64)

プロパティの名前。

VALUE

VARCHAR2(1024)

プロパティ値。

LABEL

VARCHAR(256)

プロパティ・ラベル。

NLS_ID

VARCHAR(64)

プロパティのNLS ID

3.10.3.1 イベント・タイプに固有の通知ペイロード要素

gc$notif_event_attr_array

gc$notif_event_attrの配列は、イベント固有の属性を参照するために使用されます。配列の最大サイズは25です。配列の各要素は、gc$notif_event_attrタイプです(イベント・タイプ固有の属性を参照するために使用されます)。

表3-49 イベント属性タイプ

属性

データタイプ

属性情報

NAME

VARCHAR2(64)

イベント・タイプに固有の属性の内部名。

VALUE

VARCHAR2(4000)

値。

NLS_VALUE

VARCHAR2(4000)

属性の翻訳された値。

SQL問合せを使用して、デプロイされているイベント・タイプとそれぞれに固有のペイロードをリストできます。次のSQLを使用して、Enterprise Managerに登録されているすべての内部イベント・タイプ名をリストできます。

Select event_class as event_type, upper(name) as env_var_name
from em_event_class_attrs
where notif_order != 0
and event_class is not null
order by event_type, env_var_name;

属性名は、名前を比較に使用する前に大文字に変換しておく必要があります。

gc$notif_event_attr_arrayデータベース・タイプからアクセスできる各イベント・タイプに固有の属性変数のペイロードがあります。次の表に、最もクリティカルなイベント・タイプの通知属性をリストします。属性名は、名前を比較に使用する前に大文字に変換しておく必要があります。

表3-50 メトリック・アラート・イベント・タイプに固有の環境変数

環境変数

説明

COLL_NAME

メトリックを収集するコレクションの名前。

KEY_COLUMN_X

キー列Xの内部名(Xは1から7の数値)。

KEY_COLUMN_X_VALUE

キー列Xの値(Xは1から7の数値)。

KEY_VALUE

メトリック・アラート・イベントに対応するメトリックの監視対象オブジェクト。

METRIC_COLUMN

メトリック列の名前

METRIC_DESCRIPTION

メトリックの簡単な説明。

METRIC_GROUP

メトリックの名前。

NUM_KEYS

メトリック内のキー・メトリック列の数。

SEVERITY_GUID

このメトリック・アラートに関連付けられている重大度レコードのGUID。

VALUE

イベントがトリガーされたときのメトリックの値。

表3-51 ターゲット可用性イベント・タイプに固有の環境変数

環境変数

説明

AVAIL_SEVERITY

ターゲットのステータスが現在の可用性ステータスに変更された要因である遷移重大度(0-6)。

AVAIL_SEVERITYに指定できる値

- 0 (ターゲット停止)

- 1 (ターゲット起動)

- 2 (ターゲット・ステータスのエラー)

- 3 (エージェント停止)

- 4 (ターゲット使用不可)

- 5 (ターゲット・ブラックアウト)

- 6 (不明なターゲット・ステータス)

AVAIL_SUB_STATE

現在のステータスに対するターゲットのサブステータス。

CYCLE_GUID

メトリック・アラートが最初に生成されたときからクリアされるまでの、メトリック・アラート・サイクルの一意の識別子。

METRIC_GUID

レスポンス・メトリックのメトリックGUID。

SEVERITY_GUID

この可用性ステータスに関連付けられている重大度レコードのGUID。

TARGET_STATUS

ターゲットの現在の可用性のステータス。

表3-52 ジョブ・ステータスの変更イベント・タイプに固有の環境変数

環境変数

説明

EXECUTION_ID

ジョブ実行の一意のID。

EXECUTION_LOG

実行された最後のステップのジョブ出力。

EXECUTION_STATUS

ジョブ実行の内部ステータス。

EXEC_STATUS_CODE

ジョブ実行の実行ステータス・コード。可能な値は、表3-16「ジョブ・ステータス・コード」を参照してください。

STATE_CHANGE_GUID

最新ステータス変更の一意のID

例3-17 PL/SQLスクリプト: イベント・タイプのペイロード要素

-- log_table table is created by following DDL to demostrate how to access
-- event notification payload GC$NOTIF_EVENT_MSG.

CREATE TABLE log_table (message VARCHAR2(4000)) ;

-- Define PL/SQL notification method for Events
CREATE OR REPLACE PROCEDURE log_table_notif_proc(s IN GC$NOTIF_EVENT_MSG)
IS
l_categories gc$category_string_array;
l_category_codes gc$category_string_array;
l_attrs gc$notif_event_attr_array;
l_ca_obj gc$notif_corrective_action_job;
BEGIN
INSERT INTO log_table VALUES ('notification_type: ' || s.msg_info.notification_type);
INSERT INTO log_table VALUES ('repeat_count: ' || s.msg_info.repeat_count);
INSERT INTO log_table VALUES ('ruleset_name: ' || s.msg_info.ruleset_name);
INSERT INTO log_table VALUES ('rule_name: ' || s.msg_info.rule_name);
INSERT INTO log_table VALUES ('rule_owner: ' || s.msg_info.rule_owner);
INSERT INTO log_table VALUES ('message: ' || s.msg_info.message);
INSERT INTO log_table VALUES ('message_url: ' || s.msg_info.message_url);
INSERT INTO log_table VALUES ('event_instance_guid: ' || s.event_payload.event_instance_guid);
INSERT INTO log_table VALUES ('event_type: ' || s.event_payload.event_type);
INSERT INTO log_table VALUES ('event_name: ' || s.event_payload.event_name);
INSERT INTO log_table VALUES ('event_msg: ' || s.event_payload.event_msg);
INSERT INTO log_table VALUES ('source_obj_type: ' || s.event_payload.source.source_type);
INSERT INTO log_table VALUES ('source_obj_name: ' || s.event_payload.source.source_name);
INSERT INTO log_table VALUES ('source_obj_url: ' || s.event_payload.source.source_url);
INSERT INTO log_table VALUES ('target_name: ' || s.event_payload.target.target_name);
INSERT INTO log_table VALUES ('target_url: ' || s.event_payload.target.target_url);
INSERT INTO log_table VALUES ('severity: ' || s.event_payload.severity);
INSERT INTO log_table VALUES ('severity_code: ' || s.event_payload.severity_code);
INSERT INTO log_table VALUES ('event_reported_date: ' || to_char(s.event_payload.reported_date, 'D MON DD HH24:MI:SS'));

IF s.event_payload.target.TARGET_LIFECYCLE_STATUS IS NOT NULL
THEN
INSERT INTO log_table VALUES ('target lifecycle_status: ' || s.event_payload.target.TARGET_LIFECYCLE_STATUS);
END IF;

-- Following block illustrates the list of category codes to which the event
-- belongs.

l_category_codes := s.event_payload.category_codes;
IF l_categories IS NOT NULL
THEN
FOR c IN 1..l_category_codes.COUNT
LOOP
INSERT INTO log_table VALUES ('category_code ' || c || ' - ' || l_category_codes(c));
END LOOP;
END IF;

--
-- Each event type has a specific set of attributes modeled. Examples of
-- event types include metric_alert, target_availability, job_status_change.
-- Following block illustrates how to access the attributes for job_status change
-- event type
--
IF s.event_payload.event_type = 'job_staus_chage'
THEN
l_attrs := s.event_payload.event_attrs;
IF l_attrs IS NOT NULL
THEN
FOR c IN 1..l_attrs.COUNT
LOOP
INSERT INTO log_table VALUES ('EV.ATTR name=' || l_attrs(c).name || ' value=' || l_attrs(c).value || ' nls_value=' || l_attrs(c).nls_value);
END LOOP;
END IF;
END IF;

-- Following block illustrates how to access corrective action job's attributes  IF s.msg_info.notification_type = GC$NOTIFICATION.NOTIF_CA AND s.event_payload.corrective_action IS NOT NULL
THEN
l_ca_obj := s.event_payload.corrective_action;
INSERT INTO log_table VALUES ('CA JOB_GUID: ' || l_ca_obj.JOB_GUID);
INSERT INTO log_table VALUES ('CA JOB_NAME: ' || l_ca_obj.JOB_NAME);
INSERT INTO log_table VALUES ('CA JOB_OWNER: ' || l_ca_obj.JOB_OWNER);
INSERT INTO log_table VALUES ('CA JOB_TYPE: ' || l_ca_obj.JOB_TYPE);
INSERT INTO log_table VALUES ('CA JOB_STATUS: ' || l_ca_obj.JOB_STATUS);
INSERT INTO log_table VALUES ('CA JOB_STATUS_CODE: ' || l_ca_obj.JOB_STATUS_CODE);
INSERT INTO log_table VALUES ('CA JOB_STEP_OUTPUT: ' || l_ca_obj.JOB_STEP_OUTPUT);
INSERT INTO log_table VALUES ('CA JOB_EXECUTION_GUID: ' || l_ca_obj.JOB_EXECUTION_GUID);
INSERT INTO log_table VALUES ('CA JOB_STATE_CHANGE_GUID: ' || l_ca_obj.JOB_STATE_CHANGE_GUID);
INSERT INTO log_table VALUES ('CA OCCURRED_DATE: ' || l_ca_obj.OCCURRED_DATE);  END IF;

COMMIT ;
END ;
/

3.10.4 通知に関するトラブルシューティング

通知システムの動作は、Enterprise ManagerおよびITインフラストラクチャの様々なコンポーネントに依存しています。このため、通知障害には考えられる原因が多数あります。通知システムに関する問題を特定する際は、次のガイドラインおよび推奨事項を参考にしてください。

3.10.4.1 一般的な設定

通知問題を診断する最初の手順は、通知環境が適切に構成および定義されているか確認することです。

OSコマンド、PL/SQLおよびSNMPトラップ通知

「テスト」ボタンをクリックして、すべてのOSコマンド、PL/SQLおよびSNMPトラップの通知メソッドが有効であることを確認します。これによってテスト通知が送信され、OMSが通知メソッドを呼び出す際の問題が表示されます。メソッドがコールされたことを確認してください。たとえば、OSコマンドの通知によりログ・ファイルに情報が書き込まれるように設定した場合は、OSコマンドの通知によって情報がログ・ファイルに書き込まれていることを確認します。

電子メール通知

- 「設定」の「通知メソッド」ページで、電子メール・ゲートウェイが設定されていることを確認します。送信者の電子メール・アドレスは有効である必要があります。「テスト」ボタンをクリックすると、電子メールが送信者の電子メール・アドレスに送信されます。この電子メールが受信されることを確認します。「テスト」ボタンでは通知スケジュールはすべて無視されますので注意してください。

- 電子メール・アドレスが設定されていることを確認します。「テスト」ボタンをクリックすると、指定したアドレスに電子メールが送信されるため、この電子メールを受信したことを確認する必要があります。「テスト」ボタンでは通知スケジュールはすべて無視されますので注意してください。

- 電子メール・スケジュールが定義されていることを確認します。通知スケジュールが定義されていない場合、電子メールは送信されません。

- 対象となる状態と一致するインシデント・ルールが定義されていることを確認し、そのルールに電子メールおよび通知メソッドが割り当てられていることを確認します。

3.10.4.2 通知システムのエラー

通知問題に関連するアラートが発生した場合、次のものを確認して通知エラーを調べてください。

- 通知システム内の重大なエラーは、MGMT_SYSTEM_ERROR_LOG表にシステム・エラーとして記録されます。「設定」メニューから、「管理サービスとリポジトリ」を選択し、これらのエラーを表示します。

- 配信エラーがないか確認します。インシデント・マネージャから表示できます。「エンタープライズ」メニューから、「監視」、「インシデント・マネージャ」の順に選択します。この詳細情報に、通知が配信されなかった理由が示されます。

3.10.4.3 通知システムのトレース・メッセージ

通知システムは、sysman/log/emoms.trcファイル内にトレース・メッセージを生成できます。

トレースを構成するには、emctl set propertyコマンドを使用してlog4j.category.oracle.sysman.em.notificationプロパティのフラグを設定します。トレース・レベルはINFO、WARN、DEBUGに設定できます。次に例を示します。

emctl set property -name log4j.category.oracle.sysman.em.notification -value
DEBUG -module logging

注意: システムからSYSMANパスワードが要求されます。

トレース・メッセージには、em.notificationという文字列が含まれます。UNIX環境で作業している場合、grepコマンドを使用してemoms.trcおよびemoms_pbs.trcファイル内のメッセージを検索できます。次に例を示します。

grep em.notification emoms.trc emoms_pbs.trc

トレース・ファイル内の調べる箇所

emoms.trcファイル内の次のエントリが通知に関連しています。

通常起動のメッセージ

OMSが起動すると、次のようなタイプのメッセージが表示されます。

2011-08-17 13:50:29,458 [EventInitializer] INFO  em.notification init.167 - Short format maximum length is 155
2011-08-17 13:50:29,460 [EventInitializer] INFO  em.notification init.185 - Short format is set to both subject and body
2011-08-17 13:50:29,460 [EventInitializer] INFO  em.notification init.194 - Content-Transfer-Encoding is 8-bit
2011-08-17 13:50:29,460 [EventInitializer] DEBUG em.notification registerAdminMsgCallBack.272 - Registering notification system message call back
2011-08-17 13:50:29,461 [EventInitializer] DEBUG em.notification registerAdminMsgCallBack.276 - Notification system message callback is registered successfully
2011-08-17 13:50:29,713 [EventInitializer] DEBUG em.notification upgradeEmailTemplates.2629 - Enter upgradeEmailTemplates
2011-08-17 13:50:29,735 [EventInitializer] INFO  em.notification upgradeEmailTemplates.2687 - Email template upgrade is not required since no customized templates exist.
2011-08-17 13:49:28,739 [EventCoordinator] INFO  events.EventCoordinator logp.251 - Creating event worker thread pool: min = 4 max = 15
2011-08-17 13:49:28,791 [[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO emdrep.pingHBRecorder initReversePingThreadPool.937 - Creating thread pool for reverse ping : min = 10 max = 50
2011-08-17 13:49:28,797 [[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG emdrep.HostPingCoordinator logp.251 - Creating thread pool of worker thread  for host ping: min = 1 max = 10
2011-08-17 13:49:28,799 [[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG emdrep.HostPingCoordinator logp.251 - Creating thread pool for output of worker's  output for host ping: min = 2 max = 20
2011-08-17 13:49:30,327 [ConnectorCoordinator] INFO  connector.ConnectorPoolManager logp.251 - Creating Event thread pool: min = 3 max = 10
2011-08-17 13:51:48,152 [NotificationMgrThread] INFO  notification.pbs logp.251 - Creating thread pool: min = 6 max = 24
2011-08-17 13:51:48,152 [NotificationMgrThread] INFO  em.rca logp.251 - Creating RCA thread pool: min = 3 max = 20

通知配信のメッセージ

2006-11-08 03:18:45,387 [NotificationMgrThread] INFO  em.notification run.682 - Notification ready on EMAIL1

2006-11-08 03:18:46,006 [DeliveryThread-EMAIL1] INFO  em.notification run.114 - Deliver to SYSMAN/admin@myco.com

2006-11-08 03:18:47,006 [DeliveryThread-EMAIL1] INFO  em.notification run.227 - Notification handled for SYSMAN/admin@myco.com

通知システム・エラーのメッセージ

2011-08-17 14:02:23,905 [NotificationMgrThread] DEBUG notification.pbs logp.251 - Notification ready on EMAIL1
2011-08-17 14:02:23,911 [NotificationMgrThread] DEBUG notification.pbs logp.251 - Notification ready on PLSQL4
2011-08-17 14:02:23,915 [NotificationMgrThread] DEBUG notification.pbs logp.251 - Notification ready on OSCMD14
2011-08-17 14:02:19,057 [DeliveryThread-EMAIL1] INFO  notification.pbs logp.251 - Deliver to To: my.admin@myco.com; issue type: 1; notification type: 1
2011-08-17 14:02:19,120 [DeliveryThread-OSCMD14] INFO  notification.pbs logp.251 - Deliver to SYSMAN, OSCMD, 8; issue type: 1; notification type: 1
2011-08-17 14:02:19,346 [DeliveryThread-PLSQL4] INFO  notification.pbs logp.251 - Deliver to SYSMAN, LOG_JOB_STATUS_CHANGE, 9; issue type: 1; notification type: 1
2011-08-17 14:02:19,977 [DeliveryThread-PLSQL4] DEBUG notification.pbs logp.251 - Notification handled for SYSMAN, LOG_JOB_STATUS_CHANGE, 9
2011-08-17 14:02:20,464 [DeliveryThread-EMAIL1] DEBUG notification.pbs logp.251 - Notification handled for To: my.admin@myco.com
2011-08-17 14:02:20,921 [DeliveryThread-OSCMD14] DEBUG notification.pbs logp.251 - Notification handled for SYSMAN, OSCMD, 8

3.10.4.4 電子メールのエラー

SMTPゲートウェイが適切に設定されていない:

Failed to send email to my.admin@myco.com: For email notifications to be sent, your Super Administrator must configure an Outgoing Mail (SMTP) Server within Enterprise Manager. (SYSMAN, myrule)

無効なホスト名:

Failed to connect to gateway: badhost.oracle.com: Sending failed;
nested exception is:
javax.mail.MessagingException: Unknown SMTP     host: badhost.example.com;

無効な電子メール・アドレス:

Failed to connect to gateway: rgmemeasmtp.mycorp.com: Sending failed;
nested exception is:
javax.mail.MessagingException: 550 5.7.1        <smpemailtest_ie@example.com>... Access denied

電子メールのゲートウェイ構成が有効であるか確認する場合は、常に「テスト」ボタンを使用してください。送信者の電子メール・アドレスに電子メールが受信されることを確認してください

3.10.4.5 OSコマンドのエラー

OSコマンドまたはスクリプトを実行しようとすると、次のエラーが発生することがあります。「テスト」ボタンを使用して、OSコマンドの構成が有効であるか確認します。エラーが存在する場合、コンソールにそのエラーが表示されます。

パスが無効であるか、ファイルに対する読取り権限がない:

Could not find /bin/myscript (machineb10.oracle.com_Management_Service) (SYSMAN, myrule )

実行可能ファイルに対する実行権限がない:

Error calling /bin/myscript: java.io.IOException: /bin/myscript: cannot execute (machineb10.oracle.com_Management_Service) (SYSMAN, myrule )

OSコマンドの実行時間の超過によるタイムアウト:

Timeout occurred running /bin/myscript (machineb10.oracle.com_Management_Service) (SYSMAN, myrule )

メモリー不足のため、またはOMSマシン上で実行されているプロセスが多すぎるために発生したエラーは、適宜記録されます。

「テスト」ボタンを使用して、OSコマンドの構成が有効であるか確認します。

3.10.4.6 SNMPトラップのエラー

「テスト」ボタンを使用して、SNMPトラップの構成が有効であるか確認します。

SNMPトラップがサード・パーティのSNMPコンソールに到達できない場合でも、このことはUDP経由で送信されるため、OMSはエラーを報告しません。SNMPトラップがサード・パーティのSNMPコンソールに到達しようとしているときに問題が発生した場合、可能性のあるSNMPトラップの問題には、SNMPコンソールを実行しているマシンのホスト名、ポート、コミュニティが無効であるか、ファイアウォールの問題などのネットワークの問題が考えられます。

SNMPトラップ問題として他に考えられるのは、無効なホスト名、ポート、SNMPコンソールを実行しているマシンのコミュニティなどがあります。

3.10.4.7 PL/SQLエラー

PL/SQLプロシージャを実行しようとすると、次のエラーが発生することがあります。「テスト」ボタンを使用して、プロシージャが有効であるか確認します。エラーが存在する場合、コンソールにそのエラーが表示されます。

プロシージャ名が無効であるか、完全修飾名でない。(例: SCOTT.PKG.PROC)

Error calling PL/SQL procedure plsql_proc: ORA-06576: not a valid function or procedure name (SYSMAN, myrule)

プロシージャが適切なシグネチャでない。例: PROCEDURE event_proc(s IN GC$NOTIF_EVENT_MSG)

Error calling PL/SQL procedure plsql_proc: ORA-06553: PLS-306: wrong number or types of arguments in call to 'PLSQL_PROC' (SYSMAN, myrule)

プロシージャに不具合があり、例外が発生

Error calling PL/SQL procedure plsql_proc: ORA-06531: Reference to uninitialized collection (SYSMAN, myrule)

PL/SQL内でカーソルのリークがないように注意する必要があります。この状況が原因で例外が発生すると、配信は失敗し、Cloud Controlコンソールのアラートの「詳細」セクションにメッセージが表示されます。

PL/SQLの構成が有効であるか確認するときはいつでも、「テスト」ボタンを使用してください。

3.11 システム・ブロードキャスト

Enterprise Managerでは、即時に表示される重要なシステム・メッセージを、管理環境全体でEnterprise Managerコンソールにブロードキャストできます。これらのメッセージは、特定のユーザーまたはすべてのEnterprise Managerユーザーに送信できます。この機能は、管理対象インフラストラクチャの一部が更新された場合またはシステム緊急時に、Enterprise Managerが停止することをユーザーに通知する際に便利です。

重要:
スーパー管理者のみ、システム・ブロードキャストを送信できます。

システム・ブロードキャスト・プリファレンスの設定

システム・ブロードキャストを送信する前に、まずブロードキャスト・プリファレンスを設定する必要があります。

1. スーパー管理者としてEnterprise Managerにログインします。

2. <USERNAME>メニューから「プリファレンス」、「システム・ブロードキャスト」の順に選択します。System Broadcast User Preferences UIが表示されます。

注意:
「システム・ブロードキャストを表示する秒数」設定は、「スーパー管理者によって送信されたシステム・ブロードキャストを自動的に閉じません」オプションが無効になっている場合のみ動作します。

3. 必要なブロードキャスト・メッセージ・プリファレンスを選択して、「保存」をクリックします。
システム・ブロードキャスト・メッセージを送信する際には、これらのプリファレンスが使用されます。

システム・ブロードキャストの作成

プリファレンスを設定したら、EM CLI動詞end_system_broadcastを使用してシステム・ブロードキャスト・メッセージを送信します。

emcli send_system_broadcast
-toOption="ALL|SPECIFIC"
[-to="comma separated user names"]
[-messageType="INFO|CONF|WARN|ERROR|FATAL" (default is INFO)]
-message="message details"

オプション

- toOption
値ALLを入力して、Enterprise Managerコンソールにログインしているすべてのユーザーにブロードキャスト・メッセージを送信します。またはSPECIFICを入力して、-toで指定したユーザーにシステム・ブロードキャストを送信します。

- to
ブロードキャスト・メッセージを受信するユーザーのカンマ区切りリスト。このオプションは、-toOptionがSPECIFICに設定されている場合にのみ使用できます。

- messageType
システム・ブロードキャストのタイプ。次のいずれかのタイプを指定できます

- INFO (情報)

- CONF (確認)

- WARN (警告)

- ERROR

- FATAL

- message
システム・ブロードキャストで送信するメッセージ。メッセージの長さは最大200文字です。

例:

この例では、緊急パッチ適用操作を実行するために、1時間以内にEnterprise Managerを停止することを知らせる情報メッセージをブロードキャストします。

emcli send_system_broadcast -messageType="INFO" -toOption="ALL" -message="Enterprise Manager will be taken down in an hour for an emergency patch"

4 ブラックアウトと通知ブラックアウトの使用方法

この章の構成は、次のとおりです。

- ブラックアウトおよび通知ブラックアウト

- ブラックアウト/通知ブラックアウトの処理

- コマンドライン・ユーティリティを使用したブラックアウトの制御

- ブラックアウト・ベスト・エフォート

4.1 ブラックアウトおよび通知ブラックアウト

ブラックアウトおよび通知ブラックアウトを使用すると、メンテナンス期間中に様々なEnterprise Managerモニタリング機能を一時停止することができるため、ターゲット・メンテナンス・ウィンドウ中のモニタリングの精度の維持に役立ちます。たとえば、アップグレードやパッチ適用のためにターゲットを停止するときに、その停止時間が収集されるメトリック・データの一部として含められないようにしたり、サービス・レベル合意(SLA)に影響を及ぼさないようにする必要がある場合があります。

ブラックアウト/通知ブラックアウト機能は、Enterprise ManagerコンソールとEnterprise Managerコマンドライン・インタフェース(EMCLI)の両方から使用できます。

4.1.1 ブラックアウトについて

ユーザーはブラックアウトを使用することで、メンテナンス作業を実行するため1つ以上のターゲットへの監視を一時停止することができます。ブラックアウト(パッチ適用ブラックアウトとも呼ばれます)により、ブラックアウト期間にターゲットが変更されず、実際のターゲットに対するメンテナンス作業が影響を受けないことが保証されます。この期間、エージェントはターゲットに対してメトリック・データ収集を実行せず、ターゲットに対する通知は生成されません。デフォルトでは、ブラックアウトを使用して、ブラックアウト期間中にターゲットでEnterprise Managerジョブを実行できます。オプションで、ブラックアウト期間中のジョブ実行を阻止することもできます。

ブラックアウトは、1つ以上の個別のターゲット、異なるホスト上に存在する複数のターゲットのグループ、または1つのホスト上にあるすべてのターゲットを対象に定義できます。ブラックアウトは、即時実行または将来において実行、あるいは無期限に実行または特定期間実行後に停止のいずれかにスケジュールできます。ブラックアウトは必要に応じて作成でき、また定期的に実行するようスケジュールできます。実際のメンテナンス期間中にその作業を完了するのにより長い時間を必要とする(またはより短い時間で済む)ことがわかった場合、管理者は、現在有効なブラックアウトを簡単に延長(または停止)できます。ブラックアウト機能は、Enterprise ManagerコンソールとEnterprise Managerコマンドライン・インタフェース(EMCLI)の両方から利用できます。通常、ターゲットのブラックアウトを独自のメンテナンス・スクリプト内に組み込む管理者には、EMCLIが便利です。

ブラックアウト使用の理由

ブラックアウトを使用すると、正確な監視データを収集できます。たとえば、管理ターゲットでデータベース・バックアップやハードウェア・アップグレードなどの定期メンテナンスを実行する間は、データ収集を停止することが可能です。この間に監視を続行すると、収集されたデータには、通常の日常操作の結果にはみられない傾向とその他の監視情報が表示されます。ターゲットのパフォーマンスについて、より正確で長期にわたる実態を把握するには、ブラックアウトを使用してデータ分析から特殊な状況を排除する必要があります。

ブラックアウト・アクセス

ブラックアウトで選択されたすべてのターゲットに対して少なくともブラックアウト・ターゲット権限を持つEnterprise Manager管理者は、ブラックアウトを作成、編集、停止または削除できます。

管理者が選択したターゲット(ブラックアウトに直接追加されたターゲット)のすべてに対してブラックアウト・ターゲット権限以上の権限を持っている場合、依存ターゲットの一部またはすべてに対してブラックアウト・ターゲット権限がなくても、管理者はブラックアウトを編集、停止または削除できます。ブラックアウト・アクセスの詳細は、「ブラックアウト・ベスト・エフォート」を参照してください。

4.1.2 通知ブラックアウトについて

通知ブラックアウトでは、通知ブラックアウト期間中にターゲットでの通知のみが抑止されます。通知ブラックアウト中もエージェントはターゲットのモニタリングを継続し、OMSでは、ターゲットが現在通知ブラックアウト中であることを示す実際のターゲット・ステータスが表示されます。イベントは通知ブラックアウト中も通常どおり生成されます。イベント通知のみが抑制されます。

ターゲットが通知ブラックアウト中の期間は、ターゲットのサービス・レベル合意(SLA)の計算には使用されません。

ターゲットを通知ブラックアウトにするには、少なくともターゲットに対する「ブラックアウト・ターゲット」権限が必要です。

通知ブラックアウトには、次の2つのタイプがあります。

- メンテナン通知ブラックアウト: ターゲットは計画メンテナンス中であり、この期間、管理者は通知を受信したくないと考えています。ターゲットはメンテナンスのために意図的に停止しているため、可用性割合およびSLAの計算時に通知ブラックアウト期間を考慮する必要はありません。このシナリオでは、管理者はメンテナンス通知ブラックアウトを作成する必要があります。

- 通知のみ通知ブラックアウト: ターゲットで、サーバー・クラッシュなど予期しない停止時間が発生しています。管理者は問題にすでに気づいており、現在解決するために作業しているので、サーバーを修復している間、アラートを受信したくないと考えています。ただし、可用性割合計算では通知ブラックアウト期間の実際のターゲットのステータスを考慮し、それに応じてSLAを計算する必要があります。このシナリオでは、管理者は通知のみ通知ブラックアウトを作成する必要があります。

デフォルトでは、通知ブラックアウトが作成されると、それはメンテナンス通知ブラックアウトです(デフォルトで「メンテナンス中」オプションが選択され、管理者が、通常の通知のみ通知ブラックアウトを作成するには、「メンテナンス中ではありません。」オプションを選択する必要があります)。

通知ブラックアウトは、1つ以上の個別のターゲット、異なるホスト上に存在する複数のターゲットのグループ、または1つのホスト上にあるすべてのターゲットを対象に定義できます。通知ブラックアウトは、即座に実行するか将来実行するかをスケジュール可能であり、また、無期限に実行するか特定の期間の経過後に停止するかもスケジュールできます。通知ブラックアウトは、必要に応じて作成するか、定期的な間隔で実行するようスケジュールできます。実際のメンテナンス期間中にその作業を完了するのにより長い時間を必要とする(またはより短い時間で済む)ことがわかった場合、管理者は、現在有効な通知ブラックアウトを簡単に延長(または停止)できます。通知ブラックアウト機能は、Enterprise ManagerコンソールとEnterprise Managerコマンドライン・インタフェース(EMCLI)の両方から利用できます。通常、ターゲットのブラックアウトを独自のメンテナンス・スクリプト内に組み込む管理者には、EMCLIが便利です。

通知ブラックアウト・アクセス

通知ブラックアウトで選択されたすべてのターゲットに対して少なくとも「ブラックアウト・ターゲット」権限を持つEnterprise Manager管理者は、通知ブラックアウトを作成、編集、停止または削除できます。

管理者が選択したターゲット(通知ブラックアウトに直接追加されたターゲット)のすべてに対して「ブラックアウト・ターゲット」権限以上の権限を持っている場合、依存ターゲットの一部またはすべてに対して「ブラックアウト・ターゲット」権限がなくても、管理者は通知ブラックアウトを編集、停止または削除できます。

4.2 ブラックアウト/通知ブラックアウトの処理

ブラックアウトを使用すると、正確な監視データを収集できます。たとえば、管理ターゲットでデータベース・バックアップやハードウェア・アップグレードなどの定期メンテナンスを実行する間は、データ収集を停止することが可能です。この間に監視を続行すると、収集されたデータには、通常の日常操作の結果にはみられない傾向とその他の監視情報が表示されます。ターゲットのパフォーマンスについて、より正確で長期にわたる実態を把握するには、ブラックアウトを使用してデータ分析から特殊な状況を排除する必要があります。

4.2.1 ブラックアウト/通知ブラックアウトの作成

ブラックアウト/通知ブラックアウトを使用すると、1つ以上の管理対象ターゲットのモニタリングを一時停止できます。

ブラックアウト/通知ブラックアウトを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「モニタリング」、ブラックアウトおよび通知ブラックアウトの順に選択します。

2. 表で「作成」をクリックします。ブラックアウトおよび通知ブラックアウト選択ダイアログが表示されます。

3. ブラックアウトまたは通知ブラックアウトを選択し、「作成」をクリックします。ブラックアウト/通知ブラックアウトの作成ページが表示されます。
通知ブラックアウトの作成時に、「メンテナンス・ウィンドウ」オプションを介して通知ブラックアウトのタイプを指定することもできます。

- メンテナンス中です。ターゲットのダウンタイムは、可用性(%)計算から除外されます。

- メンテナンス中ではありません。ターゲットのダウンタイムは可用性(%)計算に影響を与えます。

4. 新しいブラックアウト/通知ブラックアウトの必要なパラメータを入力し、「発行」をクリックします。

4.2.2 ブラックアウト/通知ブラックアウトの編集

ブラックアウトを使用すると、1つ以上の管理ターゲットの監視を一時停止できます。

ブラックアウトを編集するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「モニタリング」、ブラックアウトおよび通知ブラックアウトの順に選択します。

2. 必要に応じて、「検索」および「表示」オプションを使用して、変更するブラックアウトをブラックアウト表に表示します。

3. 必要なブラックアウト/通知ブラックアウトを選択します。詳細が表示されます。「編集」をクリックします。ブラックアウト/通知ブラックアウトの編集ページが表示されます。

4. 必要な変更を行い、「発行」をクリックします。

注意: Enterprise Managerでは、すでに開始されているブラックアウトも編集できます。

4.2.3 ブラックアウト/通知ブラックアウトの表示

ブラックアウトの情報と現在のステータスを表示するには:

1. 「エンタープライズ」メニューから、「モニタリング」、ブラックアウトおよび通知ブラックアウトの順に選択します。

2. 必要に応じて、「検索」および「表示」オプションを使用して、表示するブラックアウトをブラックアウト表に表示できます。

3. 必要なブラックアウト/通知ブラックアウトを選択します。詳細が表示されます。

ターゲットのホームページからのブラックアウトの表示

ほとんどのターゲット・タイプでは、現在ブラックアウト/通知ブラックアウト状態にある任意のターゲットについて、ターゲットのホームページからブラックアウト/通知ブラックアウトの情報を表示できます。ブラックアウト/通知ブラックアウト・サマリー・リージョンには、そのターゲットに関連するブラックアウト/通知ブラックアウト・ステータス情報が表示されます。

グループおよびシステム・ターゲット管理ページからのブラックアウト/通知ブラックアウトの表示

グループおよびシステムでは、グループ/システムおよびそのメンバー・ターゲットのアクティブ/スケジュール済のブラックアウト/通知ブラックアウト数に関するブラックアウト/通知ブラックアウト情報を表示できます。

4.2.4 終了したブラックアウト/通知ブラックアウトのパージ

多数のターゲットを管理している場合、完了したブラックアウト/通知ブラックアウト数または管理者が終了したブラックアウト/通知ブラックアウト数が非常に大きくなる場合があります。これらの終了したブラックアウト/通知ブラックアウトを削除すると、現在のブラックアウト/通知ブラックアウトの検索性および表示性が向上します。

Enterprise Managerから終了したブラックアウト/通知ブラックアウトをパージするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「モニタリング」、「ブラックアウトとブラウンアウト」の順に選択します。

2. 検索基準を使用して必要なターゲットのフィルタリングを行います。

3. 「表示」ドロップダウン・メニューから、「履歴」を選択します。

4. 表で、削除する終了したブラックアウト/通知ブラックアウトを選択して、「削除」をクリックします。「ブラックアウトの削除」/ブラウンアウトの削除の確認ページが表示されます。

5. 「削除」をクリックしてパージ・プロセスを完了します。

4.3 コマンドライン・ユーティリティを使用したブラックアウトの制御

ブラックアウトは、Oracle Enterprise Manager 13c Cloud ControlコンソールまたはEnterprise Managerコマンドライン・ユーティリティ(emctl)から制御できます。ただし、コマンドラインでターゲットのブラックアウトを制御している場合は、同じブラックアウトをCloud Controlコンソールでは制御しないでください。同様に、Cloud Controlコンソールからターゲットのブラックアウトを制御している場合は、それらのブラックアウトをコマンドラインで制御しようとしないでください。

コマンドラインでは、次のブラックアウト機能を実行できます。

- 即時ブラックアウトの開始

- 即時ブラックアウトの停止

- 即時ブラックアウトのステータスの確認

注意:
コマンドラインでブラックアウトを開始すると、ブラックアウトされるターゲットに対して実行を予定されているEnterprise Managerジョブは、すべて予定どおりに実行されます。Cloud Controlコンソールを使用してブラックアウトを制御する場合は、オプションで、ブラックアウトされるターゲットに対してジョブが実行されないようにできます。

Enterprise Managerコマンドライン・ユーティリティを使用してブラックアウトを制御する手順は、次のとおりです。

1. ディレクトリを、AGENT_HOME/binディレクトリ(UNIX)または
AGENT_INSTANCE_HOME\binディレクトリ(Windows)に変更します。

2. 表4-1「ブラックアウト・コマンドのサマリー」に示す適切なコマンドを入力します。

注意:
ブラックアウトを開始する際、ブラックアウトの影響を受けるターゲットを指定する必要があります。ターゲットに対応する正しいターゲット名とターゲット・タイプを取得するには、第27章「EMCTLコマンドを使用したEnterprise Managerの管理」を参照してください。

表4-1 ブラックアウト・コマンドのサマリー

ブラックアウトの操作

コマンド

指定したターゲットまたはターゲット・リストに対して即時ブラックアウトを設定

emctl start blackout <Blackoutname>
[<Target_name>[:<Target_Type>]]....
[-d <Duration>]

後でブラックアウトの停止またはステータス確認を行うときに指定できるように、ブラックアウトには必ず一意の名前を使用してください。

-dオプションは、ブラックアウトの期間を指定するために使用します。期間は[days] hh:mmという書式で指定され、それぞれの意味は次のとおりです。

- daysは日数を示します(オプション)。

- hhは時間数を示します。

- mmは分数を示します。

ターゲットまたはターゲット・リストを指定しない場合、Enterprise Managerではローカル・ホスト・ターゲットがブラックアウトされます。リストを指定するか、-nodelevel引数を使用しないかぎり、ホスト上の監視対象ターゲットはすべてブラックアウトされません。

異なるターゲット・タイプの2つのターゲットが同じ名前を使用している場合は、ターゲットのターゲット・タイプを指定する必要があります。

即時ブラックアウトの停止

emctl stop blackout <Blackoutname>

ホスト上のすべてのターゲットに対して即時ブラックアウトを設定

emctl start blackout <Blackoutname> [-nodeLevel] [-d <Duration>]

-nodeLevelオプションは、ホスト上のすべてのターゲットに対してブラックアウトを指定するために使用します。つまり、管理エージェントのホスト自体を含め、管理エージェントが監視しているすべてのターゲットが対象となります。-nodeLevelオプションは、ブラックアウト名の後に続ける必要があります。-nodeLevelオプションの後にターゲットを指定した場合、そのリストは無視されます。

ブラックアウトのステータスの確認

emctl status blackout [<Target_name>[:<Target_Type>]]....

Enterprise Managerコマンドラインからのブラックアウトの制御について、より詳しく学ぶために、次の例を使用します。

- データベースdb1およびdb2とOracle Listener ldb2に対して、bk1というブラックアウトを開始する場合は、次のコマンドを入力します。

$PROMPT> emctl start blackout bk1 db1 db2 ldb2:oracle_listener -d 5 02:30

ブラックアウトがすぐに開始され、5日間と2時間30分の間、その状態が続きます。

- 管理対象ホスト上のすべてのブラックアウトのステータスを確認する場合:

$PROMPT> emctl status blackout

- ブラックアウトbk2をすぐに停止する場合:

$PROMPT> emctl stop blackout bk2

- ホスト上のすべてのターゲットに対して即時ブラックアウトbk3を開始する場合:

$PROMPT> emctl start blackout bk3 -nodeLevel

- データベースdb1に対して30分間の即時ブラックアウトbk3を開始する場合:

$PROMPT> emctl start blackout bk3 db1 -d 30

- データベースdb2に対して5時間の即時ブラックアウトbk3を開始する場合:

$PROMPT> emctl start blackout bk db2 -d 5:00

4.4 ブラックアウト・ベスト・エフォート

ブラックアウト・ベスト・エフォート機能を使用すると、グループやシステムなどの集合ターゲットで、ユーザーにそのターゲットのすべてのメンバーに対するブラックアウト・ターゲット(あるいはそれ以上の)権限がなくても、集合ターゲットに対してブラックアウトを作成できます。

Enterprise Manager管理者として、集合ターゲットに対するブラックアウト・ターゲット権限はあるが、そのメンバー・ターゲットまたは関連ターゲットに対するオペレータ権限がない場合を考えます。理想的には、この集合ターゲットに対して完全なブラックアウトを作成します。ブラックアウトを定義する際には、たとえブラックアウト・ターゲット権限がないメンバー・ターゲットであっても、任意のメンバー・ターゲットを選択できます。

ブラックアウトが実際に開始されるとき、Enterprise Managerでは各メンバー・ターゲットに対する権限をチェックし、管理者がブラックアウト・ターゲット(あるいはそれ以上の)権限を持つターゲットのみブラックアウトします。この自動権限チェックとターゲット・ブラックアウト選択が、集合ターゲットをブラックアウトする際のEnterprise Managerのベスト・エフォートです。

4.4.1 ブラックアウト・ベスト・エフォートを使用する状況

ブラックアウト・ベスト・エフォート機能は、グループ、ホスト、Application Server、Webアプリケーション、冗長性グループ、システムなど、集合タイプのターゲットに対してブラックアウトを作成するためのものです。

ブラックアウト作成者がブラックアウト・ターゲット権限(またはそれ以上)を持つすべてのターゲットが、ブラックアウトの作成/ブラックアウトの編集ウィザードの最初のステップで表示されます。作成者がブラックアウト定義に含める集合タイプのターゲットを選択すると、このブラックアウトは、デフォルトで完全なブラックアウトとなります。

「リスト」ボックスから適切な値を選択することで、ブラックアウトを現在のすべてのターゲットで実行するか、それとも選択したターゲットで実行するかを選択できます。「完全なブラックアウト」オプションが選択されている場合のみ、ブラックアウト・ベスト・エフォートは、作成者にブラックアウト・ターゲット権限(またはそれ以上)がないターゲットに対して作用します。

使用例

T1、T2およびT3 (すべてデータベース)の3つのターゲットがあるとします。グループG1には、これら3つのターゲットがすべて含まれています。

ユーザーU1は、T1、T2およびG1に対してオペレータ権限があります。T3に対しては表示権限があります。

ユーザーU1は、ターゲットG1に対してスケジュール済の完全なブラックアウトを作成します。スケジュール済とは、そのブラックアウトが後から開始されることを意味します。

ブラックアウト作成時に、「「ブラックアウト・ターゲット権限が必要」については、表の下のヒントを参照してください。」というヒントのテキストがターゲットT3の横に表示されます。

このブラックアウトの開始時には、それまでにユーザーU1がターゲットT3に対するOPERATOR権限を付与されていれば、ターゲットT3もブラックアウトされます。付与されていない場合は、ターゲットT1、T2およびG1のみがブラックアウトされます。

5 グループの管理

この章では、グループ管理の概要について説明しています。この章の内容は次のとおりです。

- グループの概要

- グループの管理

- 即時利用可能なレポートの使用

5.1 グループの概要

グループは、グローバル環境内のターゲットを論理的に編成、管理および監視するための効果的な方法です。グループごとに、独自のグループ・ホームページがあります。グループ・ホームページにはグループに関する最も重要な情報が表示され、詳細情報にドリルダウンできます。ホームページには、グループの全体のステータスと、グループのメンバーに対する現在の可用性、インシデント、パッチ推奨などのその他の情報が表示されます。

グループ管理タスク

Enterprise Managerを使用して、次のグループ管理機能を実行できます。

- 選択したグループの構成の編集、グループの削除を行い、管理グループの場合、テンプレート・コレクションの関連付けまたは関連付け解除を行います。

- システム・ダッシュボードでグループのステータスと状態を表示

- 特定のグループからドリルダウンして、そのメンバー・ターゲットを集合的に監視および管理します。

- グループのメンバーのメンバー・ステータスおよびオープンしているインシデントのロールアップを表示します。

- グループのすべてのターゲットにブラックアウトを適用。

- グループに対してジョブを実行

- レポートを実行

- 監視テンプレートを適用

- コンプライアンス標準の関連付け

グループの作成に加え、冗長性グループ、権限伝播グループ、動的グループなどの特定のタイプのグループも作成できます。次の各項では、様々なタイプのグループについて説明します。

5.1.1 グループの概要

グループにより、多数のターゲットを1つの論理単位として集合的に監視および管理できます。たとえば、エンタープライズ・アプリケーションを構成するすべてのデータベースを含むグループを定義し、別のグループはホスト・ファームのすべてのホストを含むように定義できます。その後、これらのグループを使用して、管理操作を実行できます。グループを作成するには、グループのメンバーを手動で選択し、追加できます。クラスタ・データベースなどの集約ターゲットを追加する場合、そのメンバー・ターゲットはすべてグループに自動的に追加されます。

グループには同じタイプのターゲット(すべての本番データベースなど)、または異なるタイプのターゲットで構成されるホスト上のすべてのターゲットを含めることができます。静的グループを互いの内側にネストできます。ターゲット・セレクタでグループ・メンバーを選択するとき、ターゲット・タイプとして「グループ」を選択するか、グループ作成のプロセスの一部として親グループを選択します。

システム・ターゲットがグループに追加される場合、自動的にそのメンバー・ターゲットが引き込まれます。これはWebLogic Serverなどのシステムが追加され、そのメンバーも引き込まれる通常のグループの場合であり、あるいはターゲット・タイプをOracle WebLogic Serverと指定する動的グループの場合は、WebLogic Serverのメンバーが動的グループ基準に一致していない場合でも引き込まれます。このシナリオでは、グループ操作(たとえば、ジョブの実行、ブラックアウトなど)はグループのすべてのメンバーに適用されます。

グループを構成した後、次のような様々な管理操作を実行できます。

- グループ内のターゲットのサマリー・ステータスを表示します。

- グループのメンバーのメンバー・ステータスおよびオープンしているインシデントのロールアップを表示します。

- クリティカル・パッチ・アドバイザのサマリーの表示

- 過去7日間の構成変更の表示

- ジョブの作成およびジョブ実行のステータスの表示

- ブラックアウトの作成および現在のブラックアウトのステータスの表示

5.1.2 権限伝播グループの概要

権限伝播グループにより、管理者はグループのメンバーに権限を伝播できます。グループに対する権限を管理者またはロールに付与し、同じ権限をグループの新しいメンバーに自動的に伝播することができます。たとえば、権限伝播グループに対するオペレータ権限を管理者に付与する場合、その管理者にはグループのメンバー・ターゲットや今後追加されるメンバーに対するオペレータ権限も付与されます。権限伝播グループには、各ターゲットや他の権限伝播グループを含めることができます。権限伝播グループに追加する集計も権限伝播であることが必要です。たとえば、権限伝播グループに追加するグループも権限伝播であることが必要です。

グループに対する権限はEnterprise Manager管理者またはロールに付与できます。Enterprise Manager管理者グループに権限を付与する場合は、ロールを使用します。

たとえば、権限伝播グループを作成し、管理者に付与される権限をロールに付与するとします。新しいターゲットを権限伝播グループに後から追加する場合、管理者はそのターゲットに対する権限を自動的に受け取ります。さらに、新しい管理者を雇用する場合、管理者がターゲットに対するすべての権限を自動で受けられるように、ロールをその管理者に付与するのみで構いません。

5.1.3 動的グループの概要

グループのメンバーシップ管理は、通常、手動で行うか、実質的に静的です。メンバーシップの手動での管理は、小さいデプロイメントには正しく機能しますが、新規ターゲットがシステムに頻繁に入ってくる大規模で動的な環境では、必ずしも正しく機能するわけではありません。メンバーが頻繁に追加されるグループは、グループに直接ターゲットを追加するのではなく、メンバーシップ基準により定義された方が容易に管理できます。メンバーシップ基準を一度定義すると、Enterprise Managerは自動的にターゲットを追加します。

動的グループは、メンバーシップがメンバーシップ基準によって決定されるグループです。動的グループの所有者は、動的グループの作成(または変更)時にメンバーシップ基準を指定し、グループ内のメンバーシップは、指定した基準によってのみ決定されます。動的グループのメンバーシップは直接変更できません。動的グループにはターゲットを直接追加できないからです。Enterprise Managerは、動的グループの作成時に、メンバーシップ基準に一致するターゲットを自動的に追加します。また、新規ターゲットが追加されるかターゲット・プロパティが変更され、ターゲットがグループのメンバーシップ基準に一致するとき、グループ・メンバーシップも更新されます。

静的グループは動的グループをメンバーとして含めることができますが、その逆はできないことに注意してください。静的グループを動的グループのメンバーとして含めることはできません。

動的グループの「メンバーシップ基準の定義」機能を使用して、グループ・メンバーシップの基準を定義します。基準を定義すると、基準によって選択されるターゲットは、グループ・ページの「メンバー」領域にある読取り専用の表に表示されます。動的グループは基準によって定義されるため、結果として非常に大きいグループとなる基準を、意図的にまたは意図せずに定義することがあります。

動的グループには、次の要件が適用されます。

- 動的グループは、静的グループ、他の動的グループ、または管理グループを含めることはできません。

- 管理グループは動的グループを含めることはできませんが、静的グループはメンバーとして動的グループを含めることができます。

- ORベースの基準はサポートされていません。基準ページで選択されたすべての基準は、ANDベースです。

- サポートされるプロパティは、グローバル・プロパティ、および、バージョン、プラットフォーム、ターゲット名、タイプなどの管理グループに特にサポートされているその他の属性に制限されます。特に、ユーザー定義のプロパティとその他のインスタンス・プロパティ、および構成データ要素は、基準としてサポートされていません。

- 動的グループを作成するには、「任意のターゲットの表示」および「任意のターゲットの追加」権限が必要です。

- 権限伝播の動的グループを作成するには、「完全な任意のターゲット」、「任意のターゲットの追加」、「権限伝播グループの作成」権限が必要です。

5.1.4 管理グループの概要

管理グループは、設定またはコンプライアンス標準の監視などの管理設定アプリケーションの自動化により、Enterprise Managerで管理するターゲットの設定プロセスを非常にシンプルにします。通常、この設定は、個々のターゲットに手動で、またはカスタム・スクリプトを使用して半自動で適用します。しかし、管理グループを定義することにより、Enterprise Managerで特定のターゲット・プロパティを使用してターゲットが適切な管理グループに振り分けられ、必要とされる監視および管理設定が自動的に適用されます。このレベルの自動化により、ターゲットの設定プロセスがシンプルになり、新規ターゲットがEnterprise Managerの管理下に追加されたときのデータセンターの拡張も簡単になります。

管理グループは、グループへの加入時に、監視およびその他の管理設定の適用を完全に自動化するために使用される特別なタイプのグループです。ターゲットがグループに追加される際、Enterprise Managerにより、監視テンプレート、コンプライアンス標準およびクラウド・ポリシーで構成されるテンプレート・コレクションを使用してその設定が適用されます。これにより、管理者の仲介は完全に必要なくなります。

管理グループとテンプレート・コレクションの使用について、ビデオの第1部を見るには、ここをクリックします。

管理グループとテンプレート・コレクションの使用について、ビデオの第2部を見るには、ここをクリックします。

5.1.5 使用するグループのタイプの選択

ターゲットを管理するために選択できる主要なグループ・タイプは、静的グループ/動的グループ(ユーザーが定義する1つ以上のグループ)と、管理グループ(テンプレートを使用して監視設定を自動化するグループ)の2つがあります。

どのタイプのグループを使用するかを決定する前に、グループの用途とその機能をよく検討する必要があります。

次の表に、管理グループと動的グループの使用場面について説明します。

表5-1 管理グループと動的グループの使用場面

グループのタイプ

主要目的

基準に基づくメンバーシップ

追加のメンバーシップ要件

権限伝播

管理グループ

監視テンプレートを自動適用します。

可(ターゲット・プロパティに基づく)

ターゲットは、最大1つの管理グループに属することができます。

可(常時)

動的グループ

あらゆるグループ操作を実行します。

可(ターゲット・プロパティに基づく)

ターゲットは、1つ以上のグループに属することができます。

ユーザー指定オプション

管理グループの主要目的は、設定の監視やコンプライアンス標準などの管理設定のアプリケーションを自動化することです。ターゲットがグループに追加されると、Enterprise Managerはテンプレートを使用して自動的にこれらの設定を適用し、管理操作の必要性を排除します。

これに対し、動的グループは、グループを構成するプロパティを定義することによって、グループのメンバーシップを定義できる単一ユニットとして多数のターゲットを管理するために使用できます。たとえば、動的グループを使用すると、様々なサポート・チーム用に管理されるターゲットを含む権限またはグループを作成して管理できます。

5.2 グループの管理

ターゲットをグループにまとめることで、Enterprise Managerはこれらのターゲットを1つのグループとして効率的に管理するための管理機能を提供します。グループ機能を使用して、次のことができます。

- グループ内のターゲットのサマリー・ステータスを表示します。

- 個別ではなくグループ全体についてインシデントを監視。

- グループの全体的なパフォーマンスを監視できます。

- グループ全体のジョブのスケジューリング、メンテナンス期間のグループのブラックアウトなどの管理タスクを実行できます。

また、コンソールをグループ管理のページに直接アクセスするようにカスタマイズできます。

Enterprise Managerの「ターゲット」メニューから「グループ」を選択すると、グループ・ページが表示されます。現在使用可能なグループを確認して、次のタスクを実行できます。

- 定義されているすべてのグループのリストを表示します。

- 既存のグループを検索します。また、後で使用するために検索基準を保存します。

- グループのメンバーのメンバー・ステータス・サマリーおよびインシデントのロールアップを表示します。

- グループ、動的グループまたは管理グループ階層の作成、選択したグループの構成の編集、グループの削除を行い、管理グループの場合、テンプレート・コレクションの関連付けまたは関連付け解除を行います。

- グループまたは権限伝播グループの追加、グループの削除、現在定義されているグループの構成の変更を行います。

- 特定のグループからドリルダウンして、そのメンバー・ターゲットを集合的に監視および管理します。

- 特定のグループのホームページのカスタマイズ

冗長システムおよび特に可用性が高いグループは、このグループ・ページからはアクセスできません。これらのグループはすべてのターゲット・ページからアクセスできます。または、冗長システムおよびその他のシステムはシステム・ページからアクセスできます。

5.2.1 グループの作成および編集

Enterprise Managerのグループを使用すると、管理者は分散ターゲットを論理的に編成して、効率的かつ効果的に管理と監視を行うことができます。

グループを作成するには、次の手順に従います。

1. Enterprise Managerコンソールから「ターゲット」、「グループ」の順に選択します。または、「設定」メニューから「ターゲットの追加」を選択し、メニュー・オプションを選択して特定のタイプのグループを追加します。

2. 「作成」をクリックして、作成するグループのタイプを選択します。ウィザードと同じように機能する一連のグループの作成ページが、Enterprise Managerコンソールに表示されます。

3. グループの作成ページの「一般」タブで、作成するグループの「名前」を入力します。これを権限伝播グループにする場合、「有効」をクリックして、「権限の伝播」オプションを有効にします。グループの「権限の伝播」を有効にした場合、グループで管理者またはロールに付与されているターゲット権限は、メンバー・ターゲットに伝播されます。権限伝播を行う通常のグループと同様、動的グループを伝播する権限を作成するには、「権限伝播グループの作成」権限が必要です。さらに、所有者がFULL TARGET権限を持つターゲットのみがメンバーになることができるため、権限の伝播を有効にするには、「完全な任意のターゲット」権限が必要で、任意のターゲットは基準に一致する可能性があり、システム全体へのFULL権限が必要です。通常の動的グループを作成するには、グループ所有者はメンバーシップ基準に一致する可能性があるターゲットを表示できる必要があるため、システム全体への「任意のターゲットの表示」権限が必要です。

4. 各ページを構成し、「OK」をクリックします。すべてのページを構成してから、「OK」をクリックする必要があります。これらの手順の詳細は、オンライン・ヘルプを参照してください。

グループを作成すると、グループ・ページからいつでも簡単にアクセスできます。

グループを編集して、グループを構成するターゲットの変更、または任意のターゲット・タイプの要約に使用するメトリックの変更ができます。グループを編集するには、次の手順に従います。

1. Enterprise Managerコンソールから「ターゲット」、「グループ」の順に選択します。

2. 編集するグループの「名前」をクリックします。

3. グループ表の上部にある「編集」をクリックします。

4. ページの構成を変更し、「OK」をクリックします。

5.2.2 動的グループの作成

動的グループの所有者は、動的グループの作成(または変更)時にメンバーシップ基準を指定し、グループ内のメンバーシップは、指定した基準によってのみ決定されます。動的グループ内のメンバーシップは、直接変更できません。Enterprise Managerは、動的グループの作成時に、メンバーシップ基準に一致するターゲットを自動的に追加します。また、新規ターゲットが追加されるかターゲット・プロパティが変更され、ターゲットがグループのメンバーシップ基準に一致するとき、グループ・メンバーシップも更新されます。

動的グループを作成するには、次の手順に従います。

1. グループ・ページから、「作成」をクリックし、ドロップダウン・リストから「動的グループ」を選択します。または、「設定」メニューから「ターゲットの追加」を選択し、「グループ」を選択します。

2. 動的グループの作成ページの「一般」タブで、作成する動的グループの名前を入力します。これを権限伝播動的グループにする場合、「有効」をクリックして、「権限の伝播」オプションを有効にします。グループの「権限の伝播」を有効にした場合、グループで管理者またはロールに付与されているターゲット権限は、メンバー・ターゲットに伝播されます。権限伝播を行う通常のグループと同様、動的グループを伝播する権限を作成するには、「権限伝播グループの作成」権限が必要です。さらに、所有者がFULL TARGET権限を持つターゲットのみがメンバーになることができるため、権限の伝播を有効にするには、「完全な任意のターゲット」権限が必要で、任意のターゲットは基準に一致する可能性があり、システム全体へのFULL権限が必要です。通常の動的グループを作成するには、グループ所有者はメンバーシップ基準に一致する可能性があるターゲットを表示できる必要があるため、システム全体への「任意のターゲットの表示」権限が必要です。
権限伝播グループ機能には、次の2つの権限があります。

- 権限伝播グループの作成
この権限アクティビティを使用すると、管理者は権限伝播グループを作成できます。この権限を持つ管理者は、伝播グループを作成し、他のユーザーにグループ管理アクティビティを委任できます。

- グループ管理
この権限を管理者またはロールに付与すると、グループに対するグループ管理者にすることができます。つまり、グループでの操作の実行や、グループでの権限を他の管理者と共有することなどが可能です。

グループ管理権限は、権限伝播グループと従来のグループのどちらにも使用できます。この権限が付与されると、権限を付与するスーパー管理者にならなくてもグループへの完全なアクセス権を他のEnterprise Managerユーザーに付与できます。

3. 「メンバーシップ基準の定義」セクションで、「メンバーシップ基準の定義」をクリックして、動的グループ・メンバーシップのビジネス基準を定義します。
グループに含めるターゲットのプロパティを追加または削除できる、メンバーシップ基準の定義ページが表示されます。グループ・メンバーは、移入された各ターゲット・プロパティ内の1つの値と一致している必要があります。「メンバー・プレビュー」セクションを使用して、基準に一致するターゲットのリストを確認します。「OK」をクリックして、一般ページに戻ります。

メンバーシップ基準の定義ページで少なくとも1つの基準を指定する必要があります。指定したホストまたはターゲット・プロパティで、少なくとも1つターゲット・タイプを指定しないと、動的グループを作成できません。動的グループには次の基準を使用します。

- ターゲット・タイプ

- 部門

- ホスト上

- ターゲット・バージョン

- ライフサイクル・ステータス

- オペレーティング・システム

- ライン・オブ・ビジネス

- プラットフォーム

- 場所

- CSI

- コストセンター

- 連絡先

- コメント

メンバーシップ基準の定義ページの「ターゲット・プロパティの 追加/削除」ボタンを使用して、プロパティを追加または削除できます。

4. 「タイムゾーン」を入力します。選択するタイムゾーンは、このグループでのジョブやブラックアウトなどのスケジュール操作に使用されます。グループ統計のグラフにも、このタイムゾーンが使用されます。

5. 「グラフ」タブをクリックします。動的グループのグラフページに表示するグラフを指定します。デフォルトでは、動的グループに含まれるターゲット・タイプでよく使用されるグラフが追加されます。

6. 「列」タブをクリックして、メンバー・ページおよびダッシュボードに表示される列および略語を追加します。

7. 「ダッシュボード」タブをクリックして、システム・ダッシュボードのパラメータを指定します。「システム・ダッシュボード」には、動的グループのメンバーに関連する現在のステータスおよびインシデント、コンプライアンス違反がグラフ形式で表示されます。

8. 「アクセス」タブをクリックします。アクセス・ページを使用して、グループに対するアクセス権限を管理します。「アクセス」ページで、Enterprise Managerロールにターゲット・アクセス権を付与し、Enterprise Manager管理者にターゲット・アクセス権を付与できます。

9. 「OK」をクリックして、動的グループを作成します。

5.2.3 権限伝播グループへのメンバーの追加

伝播グループに対して付与されるターゲット権限は、メンバー・ターゲットに伝播されます。管理者は、範囲が決められたターゲット・オブジェクトを別の管理者に付与し、被付与者は、メンバー・ターゲットに対する同じ権限を維持します。伝播グループは次の機能を管理します。

- 権限伝播グループの作成権限を持つ管理者は、伝播グループを作成できます。

- 伝播グループのメンバーとしてターゲットを追加するには、ターゲットに対する完全なターゲット権限が管理者に必要です。

権限伝播グループのメンバーとして非集計ターゲットを追加できます。Cloud Controlバージョン12cの集計ターゲットの場合、クラスタ・データベースとRACデータベースおよび他の伝播グループをメンバーとして追加できます。ただし、Cloud Controlバージョン12cでは、冗長性システム、システムおよびサービスなどのより多くの集計ターゲット・タイプをサポートしています。

グループ作成者以外の場合、グループにターゲットを追加するには、少なくともそのグループに対する完全なターゲット権限が必要です。

5.2.4 権限伝播グループへの従来のグループの変換

Enterprise Managerバージョン12cでは、指定したEM CLI動詞を使用して従来のグループを権限伝播グループに変換できます(逆も同様)。modify_group EM CLI動詞に次の2つの新しいパラメータが追加されています。

- privilege_propagation
グループの権限伝播動作を変更する場合に使用されます。このパラメータの可能な値はtrueまたはfalseになります。

- drop_existing_grants
このパラメータは、そのグループの既存の権限付与が、グループを権限伝播から通常に(または通常から権限伝播に)変換したときに、取り消されるかどうかを示します。このパラメータに指定できる値はyesまたはnoです。デフォルト値はyesです。

これらの同じ拡張機能がEM CLI動詞、modify_system、modify_redundancy_group、modify_aggregrate_serviceで実装されています。

次にEM CLI動詞を示します。

emcli modify_group
-name="name"
[-type=<group>]
[-add_targets="name1:type1;name2:type2;..."]...
[-delete_targets="name1:type1;name2:type2;..."]...
[-privilege_propagation = true/false]
[-drop_existing_grants = Yes/No]

この動詞とその他のEM CLI動詞の詳細は、EM CLIリファレンス・ガイドを参照してください。

5.2.5 グループの表示および管理

Enterprise Managerを使用すると、グループのメンバーの重要な情報をすばやく表示できるため、個々のメンバー・ターゲットに移動して可用性やパフォーマンスを確認する必要がありません。1つの画面でグループ全体を参照し、個々の詳細にドリルダウンできます。グループのホームページには次のセクションが含まれます。

- 「一般」セクション。所有者、グループ・タイプ、グループが権限伝播であるかどうかなど、グループに関する一般情報を表示します。権限伝播フィールドをクリックして、権限伝播を有効化または無効化するグループの編集ページにドリルダウンできます。

- 「ステータス」セクション。稼働中、停止中、不明の状態にあるメンバー・ターゲットの数が表示されます。ネストされたグループでは、このセグメントに、サブグループ全体での稼働中、停止中および不明な状態のターゲット数が表示されます。ステータスのロールアップ数は、全サブグループ間で一意のメンバー・ターゲットに基づいています。したがって、あるターゲットがサブグループに複数回出現する場合でも、そのターゲットはステータスのロールアップには1回しかカウントされません。

- 「インシデントと問題の概要」セクション。最近の期間に更新されたグループのメンバーに関するインシデントの概要が表示されます。最近の期間に更新された問題だけでなく、オープンな問題の数も表示されます。
ステータスにかかわらず、すべてのメンバー・ターゲットについてロールアップ情報が表示されます。ステータスのロールアップ数は、全サブグループ間で一意のメンバー・ターゲットに基づいています。したがって、あるターゲットがサブグループに複数回出現する場合でも、そのターゲットのアラートはアラートのロールアップに1回しかカウントされません。

「問題」列の数値をクリックしてインシデント・マネージャ・ページを表示し、使用環境内の例外および問題を検索、表示および管理します。インシデント・マネージャを使用することにより、未処理のインシデントおよび問題を追跡できます。

- 「コンプライアンス・サマリー」セクション。グループに定義された、コンプライアンス標準に対するグループのメンバーのコンプライアンスを表示します。このセクションでは、平均コンプライアンス・スコア(%)だけでなく、重大度(クリティカル、警告、マイナー警告)別の違反のロールアップも表示されます。

- 「ジョブ・アクティビティ」セクション。開始日が最近7日以内のグループ内のターゲットのジョブのサマリーを表示します。「表示」をクリックして、最新の実行またはすべての実行を表示できます。「表示」をクリックして、表に表示される列を選択および並替えするか、表のスクロールおよび拡張を調整します。

- 「ブラックアウト」セクション。現在のブラックアウトまたは保留中のブラックアウトに関する情報が表示されます。このセクションから、ブラックアウトを作成することもできます。

- 「パッチ推奨」セクション。企業に適用可能なOracleパッチ推奨を表示します。分類またはターゲット・タイプ別に、パッチ推奨を表示できます。
「すべての推奨」リンクをクリックすることによって、My Oracle Supportに移動して、すべての推奨を表示できます。

- 「インベントリおよび使用状況」セクション。組織全体のデプロイ(ホスト、データベース・インストールおよびFusion Middlewareインストールなど)または特定のターゲットのインベントリ・サマリーを表示します。異なるディメンションのコンテキストで、インベントリ・サマリー情報を表示することもできます。ここから「詳細を表示」をクリックして、インベントリおよび使用状況ページ表示できます。

- 「構成の変更」セクション。過去7日間のグループへの構成の変更数を表示します。数字をクリックして、変更に関する詳細情報を表示するページを表示できます。Enterprise Managerでは、グループ・ターゲットの構成情報を自動的に収集し、構成への変更は記録され、そのページから表示できます。

グループの表示

グループを表示するには、次の手順に従います。

1. Enterprise Managerコンソールから「ターゲット」、「グループ」の順に選択します。サマリー表にすべての定義済グループが表示されます。

2. 目的のグループをクリックしてそのホームページに移動します。

「表示方法」フィルタを使用して(ホームページの右上隅に配置)、ホームページの表示を特定のタイプのターゲットのメンバーに変更します。これを実行すると、「グループ」ホームページは、そのタイプのターゲットの情報のみを表示するようにリフレッシュされます。追加のリージョンが表示される場合があります。たとえば、DBAはグループ内のDatabaseターゲットに関する情報を特に表示するDatabaseフィルタに切り替える場合があります。

ホームページの各リージョンの右上隅の「アクション」アイコンをクリックすることで、そのリージョンをページの上や下に移動して、ホームページをパーソナライズできます。各リージョンの左上隅の矢印をクリックすることで、そのリージョンを拡大または縮小できます。

「グループ」メニューを使用して、グループに関する別の管理操作へナビゲートすることもできます。たとえば、「グループ」メニューの「メンバー」を選択して、グループのすべてのメンバーを表示できます。同様に、「グループ」メニューの「メンバーシップ履歴」を選択することで、グループのメンバーシップ履歴を表示できます。

5.2.6 グループ・チャートの概要

グループ・チャートで、グループの全体的なパフォーマンスを監視できます。グループ内のメンバーのタイプに基づく即時利用可能なパフォーマンス・チャートが提供されます。たとえば、データベースがグループの一部である場合、「待機時間(%)」のグラフには、最も高い待機時間のパーセント値を含むデータベースが表示されます。24時間以内、7日以内、31日以内のパフォーマンス情報を表示できます。このページには、独自のカスタム・チャートも追加できます。

5.2.7 グループ・メンバーの概要

Enterprise Managerでは、グループのメンバー・ターゲットの情報を要約できます。ここには、現在の可用性ステータス、オープンしているインシデントのロールアップ、コンプライアンス違反、グループのターゲット・タイプに基づく主要なパフォーマンス・メトリックの情報が表示されます。

すべてのメンバー・ターゲットの可用性と、相対的なパフォーマンスを視覚的に評価できます。一定の基準でメンバーをランク付けできます(たとえば、待機時間の割合の降順にデータベース・ターゲットを表示できます)。デフォルトの主要パフォーマンス・メトリックを選択したターゲットに基づいて表示できますが、グループの管理に重要な追加メトリックを組み込むようにカスタマイズできます。

「グループ」メニューの「メンバー」を選択して、グループのメンバーを表示できます。Enterprise Managerでは「メンバー」ページを表示し、そこで「すべてのメンバー」、「直接メンバー」、「間接メンバー」でフィルタしたメンバーの表を表示できます。直接メンバーはグループに直接追加されたターゲットです。間接メンバーは、直接メンバー・ターゲットのメンバーであり、親ターゲットがグループに追加されたために自動的にグループに含まれたターゲットです。このページにはグループをエクスポートまたは編集するオプションがあります。

同様に、「グループ」メニューの「メンバーシップ履歴」を選択することで、メンバーシップ履歴に関する情報にアクセスすることもできます。メンバーシップ履歴ページには、一定期間のグループ・メンバーシップの変更が表示されます。

5.2.8 グループ・ステータス履歴の表示

グループのステータス履歴を表示して、指定した期間におけるメンバーの可用性の履歴やすべてのグループ・メンバーの現在のステータスを表示できます。「グループ」メニューの「監視」を選択し、「ステータス履歴」を選択して、ステータス履歴ページにアクセスできます。

棒グラフには、「データの表示」ドロップダウン・リストから選択した期間における、グループ・メンバーの可用性の履歴が表示されます。色分けされたグラフは、「稼働中」、「停止中」、「ブラックアウト中」、「エージェント停止」、「メトリック収集エラー」、「ステータス保留」の各ステータスを示しています。24時間、7日間または31日間の期間を選択できます。

メンバーの現在のステータスを表示するには、グループステータス履歴の表示ページの「ステータス」アイコンをクリックして、可用性ページに移動します。このページには、過去24時間、7日間または31日間以内における、メンバーの現在および過去の可用性ステータスが表示されます。メンバーのホームページに移動するには、メンバーの 「名前」 をクリックします。このページを使用して、選択したメンバーのパフォーマンスの評価を開始できます。

5.2.9 システム・ダッシュボードとは

システム・ダッシュボードを使用すると、グループのステータス、インシデントやコンプライアンス違反の発生を前もって監視できます。色分けされたインタフェースでは、問題が強調表示されます。停止しているターゲットは赤、重大度がクリティカルのメトリックは赤い点線、警告のメトリックは黄色の点線、正常範囲内で作動しているメトリックは緑の点線で表示されます。

このような色の使用によって、あらゆるターゲットの問題領域をすぐに特定し、必要に応じて詳細を確認できます。グループのすべてのオープンしているインシデントのサマリーを提供するため、インシデント表も組み込まれています。表のインシデントは新しい順に並び、最新のインシデントが一番上に表示されていますが、表の任意の列をクリックして順序を変更することもできます。「メンバー・ターゲット」表の上部のバーの色は、インシデントの重大度レベルにより異なります。優先度は、警告からクリティカル、致命的へと高くなります。グループに少なくとも1つの致命的なインシデントがある(クリティカルまたは警告インシデントには関係なく)場合、上部のバーは濃い赤になります。グループに少なくとも1つのクリティカルなインシデントがある(警告インシデントには関係なく)場合、上部のバーは薄い赤になります。グループに警告インシデントしかない場合、上部のバーは黄色になります。グループにインシデンがない場合、上部のバーは無色のままです。

ダッシュボードは、ダッシュボードのカスタマイズ・ページで設定した「リフレッシュ頻度」に基づき、自動的にリフレッシュされます。

ダッシュボードは、ドリルダウンして詳細情報を表示できます。詳細を確認するには、ダッシュボードの次の項目をクリックします。

- ターゲットのホームページにアクセスする場合は、ターゲット名

- システム・ダッシュボードにアクセスする場合は、グループまたはシステム名

- メトリック詳細ページにアクセスする場合は、特定のメトリック列に対応するステータス・アイコン

- すべてのキー値の一覧があるメトリック・ページにアクセスする場合は、キー値のあるメトリックのステータス・アイコン

- グループのホームページにアクセスする場合は、ダッシュボード・ヘッダー

- すべてのインシデントまたはインシデントの特定のカテゴリに関するサマリー情報を表示する場合は、「インシデントと問題」表。

「カスタマイズ」をクリックしてダッシュボードのカスタマイズ・ページにアクセスします。このページでは、リフレッシュの頻度を変更し、ダッシュボードの上部に「メンバー・ターゲット」表のオプションを表示できます。個別のターゲットをすべて表示することも、ターゲット・タイプ別に表示することもできます。下部に「インシデントと問題」表を拡張または縮小するオプションもあります。「メンバー・ターゲット」表に表示される列を変更するには、「グループ」メニューで「ターゲット設定」を選択してアクセスできる、グループの編集ページの「列」タブに移動します。

「ターゲット・タイプ別グループ」モードでは、ダッシュボードに、グループまたはシステムにある特定のターゲット・タイプに基づくターゲットの情報が表示されます。表示されるステータスおよびインシデントは、そのターゲット・タイプのターゲットに対してロールアップされます。

ダッシュボート・ウィンドウを最小化しても、グループやシステムに関連したアラート情報は、Microsoft Windowsのツールバーに表示されたままです。

情報パブリッシャ・レポートを使用して、システム・ダッシュボードをEnterprise Managerユーザー以外にも使用できるようにすることができます。まず、レポートを作成し、システム監視ダッシュボードのレポート要素を含めます。レポート定義で、「Enterprise Managerにログインせずに表示可能」オプションを選択します。これが実行されると、「Enterprise Manager情報パブリッシャ・レポート」Webサイトから表示できます。

5.3 即時利用可能なレポートの使用

Enterprise Managerでは、レポート作成フレームワークの一部としてグループ用にいくつかの即時利用可能なレポート(情報パブリッシャと呼ばれる)を提供しています。このレポートでは、グループ内の全ホストのハードウェアおよびオペレーティング・システムのサマリーなど重要な管理情報が表示されます。また、グループの未処理のアラートおよびインシデントなどの監視情報も表示されます。

レポートには「グループ」メニューの「情報パブリッシャ・レポート」メニュー項目からアクセスできます。

関連項目:
第41章「情報パブリッシャの使用」

6 管理グループの使用

管理グループは、設定またはコンプライアンス標準の監視などの管理設定アプリケーションの自動化により、Enterprise Managerで管理するターゲットの設定プロセスを非常にシンプルにします。通常、この設定は、個々のターゲットに手動で、またはカスタム・スクリプトを使用して半自動で適用します。しかし、管理グループを定義することにより、Enterprise Managerで特定のターゲット・プロパティを使用してターゲットが適切な管理グループに振り分けられ、必要とされる監視および管理設定が自動的に適用されます。監視設定に対する変更は、管理グループ内の適切なターゲットに自動的に適用されます。このレベルの自動化により、ターゲットの設定プロセスがシンプルになり、新規ターゲットがEnterprise Managerの管理下に追加されたときのデータセンターの拡張も簡単になります。

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

- 管理グループとは

- 管理グループの計画

- 管理グループおよびテンプレート・コレクションの実装

- 管理グループの削除

説明用ビデオ:
管理グループおよびテンプレート・コレクションの使用に関するビデオ・チュートリアルは、次を参照してください。
管理グループおよびテンプレート・コレクションの使用 - パート1

https://apex.oracle.com/pls/apex/f?p=44785:24:6424795248965:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5732%2C24

管理グループおよびテンプレート・コレクションの使用 - パート2

https://apex.oracle.com/pls/apex/f?p=44785:24:15101831740469:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5733%2C24

6.1 管理グループとは

管理グループは、グループへの加入時に、ターゲットに対する監視およびその他の管理設定の適用を完全に自動化するために使用される特別なタイプのグループです。ターゲットがグループに追加される際、Enterprise Managerにより、監視テンプレート、コンプライアンス標準およびクラウド・ポリシーで構成されるテンプレート・コレクションを使用してその設定が適用されます。これにより、管理者の仲介は完全に必要なくなります。次の図に標準的な管理グループのワークフローを示します。

最初の手順として、ターゲットが最初に監視対象としてEnterprise Managerに追加されるときの、ターゲットの「ライフサイクル・ステータス」プロパティの設定があります。その時点で、ターゲットが属する優先度階層を決定します。最高のレベルは「基幹」で、最低のレベルは「開発」です。ターゲットのライフサイクル・ステータスの優先度には、次のようなレベルがあります。

- 基幹(最高の優先度)

- 本番

- ステージング

- テスト

- 開発(最低の優先度)

図の手順2に示すように、ライフサイクル・ステータスが設定されると、Enterprise Mangerはそれを使用してターゲットがどの管理グループに属するかを判断します。

同じターゲットに異なる監視設定が適用されないように、管理グループは、グループのメンバーシップに関して他の管理グループと相互排他的に設計されています。管理グループを使用して組織のターゲットを階層的に分類し、ターゲットは1つの管理グループに属することになります。このことは、Enterprise Managerデプロイメントにおいて管理グループの階層は1つのみであることも意味します。

たとえば、前述の図では、ProductionターゲットおよびTestターゲットの2つのサブグループから構成される管理グループの階層があり、各サブグループにはそれぞれの所有するテンプレート・コレクションがあります。この例では、Productionグループは監視テンプレートAの監視設定を継承し、Testグループのターゲットは監視テンプレートBの監視設定を継承しています。

6.1.1 管理グループの開発

管理グループを作成するには、「完全な任意のターゲット」および「権限伝播グループの作成」の両方のターゲット権限が必要です。

管理グループの開発は次の2段階で実行されます。

- 計画

- ターゲットの監視方法を反映するような方法でグループ階層を作成することにより、管理グループ階層を計画します。

- 階層内の管理グループに関連する管理設定を計画します。

- 管理設定: 監視設定、コンプライアンス標準設定、クラウド・ポリシー設定

- 監視設定の場合、追加メトリック設定を使用したり、階層内の下位のメトリック設定を上書きできます。

- コンプライアンス標準またはクラウド・ポリシーの場合、階層内の下位の追加ルール/ポリシーは追加方式です。

- 実装

- Enterprise Managerにグループ階層定義および管理設定を入力します。

- 管理グループ階層を作成します。

- 監視テンプレート、コンプライアンス標準、クラウド・ポリシーを選択し、これらをテンプレート・コレクションに追加します。

- テンプレート・コレクションを管理グループに関連付けます。

- ターゲット・プロパティに適切な値を割り当てて管理グループにターゲットを追加することにより、ターゲットが適切な管理グループに自動的に追加されるようにします。

6.2 管理グループの計画

管理におけるすべての決定と同じく、効果的な実装のためには計画と準備が重要です。管理グループについても同様です。

ステップ1: グループ階層の計画

Enterprise Managerのデプロイメントで保持できる管理グループ階層は1つのみで、これにより、管理グループのメンバー・ターゲットがただ1つの管理グループに直接属することが保証されます。これにより、1つのターゲットが異なる監視設定に関連付けられている複数の管理グループに属することで発生する、監視の競合を回避できます。

階層を定義するには、まず、Enterprise Managerに追加するすべてのターゲットからなる最高レベル(ルート)について考える必要があります。次に、監視方法に従ってターゲットを分割する方法について考えます。1つの方法で監視されるターゲットは1つのグループに存在し、別の方法で監視されるターゲットは別のグループに属します。たとえば、本番ターゲットが監視された方法とは別の方法でテスト・ターゲットが監視される場合があります。監視方法に詳細な違いがある場合は、個々のグループをさらに分類できます。たとえば本番ターゲットは、ライン・オブ・ビジネスを監視するために追加のメトリックがある場合があるため、サポートしているライン・オブ・ビジネスに基づいて詳細に分類される場合があります。最終的には、rootノード下のグループの階層を使用します。

各レベルのグループ化の定義に使用する属性および管理グループのメンバーシップ基準は、グローバル・ターゲット・プロパティおよびユーザー定義ターゲット・プロパティに基づきます。これらのターゲット・プロパティは、すべてのターゲットの属性となり、組織内での運用情報を指定します。たとえば、場所、それが属するライン・オブ・ビジネス、ライフサイクル・ステータスなどです。管理グループの定義に使用できるグローバル・ターゲット・プロパティは次のとおりです。

- ライフサイクル・ステータス

注意:
ターゲットの運用ステータスを表すため、「ライフサイクル・ステータス」ターゲット・プロパティが特に重要です。ライフサイクル・ステータスは、「基幹」、「本番」、「ステージング」、「テスト」および「開発」のいずれかです。

- 場所

- ライン・オブ・ビジネス

- 部門

- コストセンター

- 連絡先

- プラットフォーム

- オペレーティング・システム

- ターゲット・バージョン

- カスタマ・サポートID

- ターゲット・タイプ(許可されているがグローバル・ターゲット・プロパティではない)

EM CLI動詞のadd_target_propertyおよびset_target_property_valueを使用して、カスタムのユーザー定義ターゲット・プロパティを作成できます。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』ガイドを参照してください。

ターゲットは手動では管理グループに追加できません。そのかわりに、(グループのメンバーとする予定の)ターゲットのターゲット・プロパティを、管理グループで定義するメンバーシップ基準と一致するように設定します。ターゲット・プロパティが設定されていれば、Enterprise Managerにより、そのターゲットは自動的に適切な管理グループに追加されます。

ターゲット・プロパティのマスター・リスト

ターゲット・プロパティを管理グループ(および動的グループ)で使用するには、管理対象の環境内のすべてのユーザーが、一貫性のある共通の方法で指定する必要があります。また、特定のターゲット・プロパティ値に対して、定義可能なターゲット・プロパティ値のリストを制限することが必要になることがあります。Enterprise Managerでターゲット・プロパティのマスター・リストを定義することで、このことを実現できます。特定のターゲット・タイプのためのマスター・リストを定義すると、ターゲットのターゲット・プロパティ・ページで、テキスト・エントリ・フィールドのかわりに、事前定義済プロパティ値を含むドロップダウン・メニューが表示されます。マスター・プロパティ・リストは、次のEM CLI動詞を使用して管理します。

- use_master_list: 指定されたターゲット・プロパティに対して使用されるマスター・リストを有効または無効にします。

- add_to_property_master_list: 指定されたプロパティのマスター・リストにターゲット・プロパティ値を追加します。

- delete_from_property_master_list: 指定されたプロパティのマスター・リストから値を削除します。

- list_property_values: プロパティのマスター・リストの値をリストします

- list_targets_having_property_value: この指定されたプロパティ名の指定されたプロパティ値を持つすべてのターゲットをリストします。

- rename_targets_property_value: すべてのターゲットのプロパティの値を変更します。

マスター・リストの動詞の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』ガイドを参照してください。注意: ターゲット・プロパティのマスター・リストを定義および管理するには、スーパー管理者権限が必要です。

Enterprise Manager管理者とターゲット・プロパティ

Enterprise Manager管理者の作成時に、「連絡先」、「場所」、「説明」などのプロパティを関連付けることができます。ただし、そのプロファイルに関連付けることのできる追加のリソース割当てプロパティがあります。これらのプロパティは、次のとおりです。

- 部門

- コストセンター

- ライン・オブ・ビジネス

これらのプロパティは永続的であることに注意してください。つまり、管理者に関連付けられると、そのプロパティ(前述のターゲット・プロパティの一部をミラーリング)は、管理者により検出されるか作成されるターゲットに、自動的に渡されます。

例

次の管理グループ階層には、Root Administration Groupノードの下に、ProductionとTestという2つの管理グループが作成されています。本番ターゲットの監視設定はテスト・ターゲットの監視設定とは異なるためです。

この例では、グループのメンバーシップ基準は「ライフサイクル・ステータス」ターゲット・プロパティに基づいています。「ライフサイクル・ステータス」が「Production」のターゲットはProductionグループに所属し、「ライフサイクル・ステータス」が「Test」のターゲットはTestグループに所属します。このためライフサイクル・ステータスは、管理グループ階層の第1レベルを決めるターゲット・プロパティです。「ライフサイクル・ステータス」プロパティの値は、第1レベルの管理グループのメンバーシップ基準を決めます。本番グループには"Lifecycle Status = Production"、テスト・グループには"Lifecycle Status = Test'のメンバーシップ基準があります。

管理グループ階層のその他のレベルは、他のターゲット・プロパティに基づいて追加できます。通常、その他のレベルが追加されるのは、適用する必要があるその他の監視(または管理)設定がある場合です。これらは、管理グループのターゲットの様々なサブセットで異なる可能性があります。たとえば、Productionグループでは、Finance部門のターゲットとSales部門のターゲットのその他の監視設定が異なる可能性があります。その場合は、「ライン・オブ・ビジネス」ターゲット・プロパティ・レベルに基づくもう1つのレベルが追加されます。

次の表に、階層計画の練習問題の最終的な結果をまとめています。

ルート・レベル(1行目)

レベル1 ターゲット・プロパティ(2行目): ライフサイクル・ステータス

レベル2 ターゲット・プロパティ(3行目): ライン・オブ・ビジネス

ルート管理グループ

Production(本番)またはMission Critical(基幹)

Finance(会計)

Sales(販売)

Staging(ステージング)、Test(テスト)またはDevelopment(開発)

Finance(会計)

Sales(販売)

表の各セルがグループを表しています。各セルの値は、そのグループのメンバーシップ基準を定義するターゲット・プロパティの値を表しています。

グループのメンバーシップ基準は、1つ以上のターゲット・プロパティの値を基にすることが可能です。その場合は、ターゲット・プロパティがいずれかの値と一致するターゲットがグループに追加されます。たとえば、Productionグループの場合、ターゲットの「ライフサイクル・ステータス」が「本番」または「基幹」のいずれかであれば、そのターゲットはProductionグループに追加されます。

また、グループのメンバーシップ基準が累積的であることを覚えておいてください。たとえば、ProductionまたはMission Criticalグループの下にあるFinanceグループでは、グループに加える前に、ターゲットの「ライフサイクル・ステータス」に「本番」または「基幹」が設定され、かつ、「ライン・オブ・ビジネス」に「Finance」が設定されている必要があります。ターゲットの本番に設定されたライフサイクル・ステータス設定があっても、FinanceまたはSalesにライン・オブ・ビジネス設定がない場合、管理グループに追加されません。

この計画例では、できあがる管理グループ階層は次の図のようになります。

ターゲットは、そのプロパティ値が両方のレベルで基準と一致するとき、そしてそのときにのみ、階層の一部となるという点に注意することが重要です。ターゲットが「ライフサイクル・ステータス」と一致する値を持っていても、それのみでは、第1レベルの管理グループのメンバーとなることはありません。また、管理グループ階層のすべてのターゲットは最も低いレベルのグループに属しています。

ステップ2: ターゲット・プロパティの割当て

必要な管理グループ階層を設定したら、ターゲットが正しい管理グループに所属するように、各ターゲットのプロパティが正しく設定されていることを確認する必要があります。Enterprise Managerは、ターゲット・プロパティを使用して、適切な管理グループにターゲットを自動的に配置します。ユーザーが操作する必要はありません。Enterprise Managerにすでに追加されたターゲットに対し、コンソール経由またはEM CLI動詞set_target_property_valueを使用して、ターゲット・プロパティを設定することもできます。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。set_target_property_valueの実行時に、ターゲット・プロパティの以前の値は上書きされることに注意してください。階層を作成する前にターゲット・プロパティを設定した場合は、階層が作成された後でグループに追加されます。EM CLIを使用して設定されたプロパティを持つターゲットは、適切な管理グループに自動的に追加されます。ただしターゲット・プロパティは、管理グループ階層が作成された後で設定されます。

ターゲット数が少ない場合、Enterprise Managerコンソールで直接ターゲット・プロパティを変更できます。

1. Enterprise Managerのターゲット・オプションのメニューから、「ターゲット設定」、「プロパティ」の順に選択します。

2. ターゲット・プロパティ・ページで、「編集」をクリックしてプロパティ値を変更します。

管理グループ条件として使用される適切なターゲット・プロパティ値を指定するときには、ページ上部の指示に注意してください。

3. ターゲット・プロパティを設定したら、「OK」をクリックします。

ターゲットの数が多い場合は、Enterprise Managerコマンドライン・インタフェース(EM CLI)のset_target_property_value動詞を使用して一括更新を実行することをお薦めします。EM CLI動詞の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。

管理グループは権限伝播です。管理グループでユーザー(またはロール)に付与した権限は、管理グループのすべてのメンバーに対して自動的に適用されます。たとえば本番管理グループのOperator権限をユーザーまたはロールに付与すると、そのユーザーまたはロールは、その管理グループのすべてのターゲットで自動的にOperator権限を持つことになります。管理グループは常に権限伝播であるため、管理グループに追加される集約ターゲットにも権限伝播されるはずです。

注意:
集約ターゲットは、他のメンバー・ターゲットを含むターゲットです。たとえばクラスタ・データベース(RAC)は、RACインスタンスを持つ集約ターゲットです。

権限伝播グループは集計ターゲットのよい例です。詳細は、「グループの管理」を参照してください。

いつでも、「すべてのターゲット」ページを使用して、すべてのターゲットのプロパティを表示できます。ターゲット・プロパティを表示するには次のようにします。

1. 「ターゲット」メニューから「すべてのターゲット」を選択し、すべてのターゲット・ページを表示します。

2. 「ビュー」メニューから、「列」、「すべて表示」の順に選択します。

3. また、特定のターゲット・プロパティを表示する場合は、「列」を選択してから「他の列も表示」を選択します。

ステップ3: テンプレート・コレクションの作成準備

テンプレート・コレクションには、ターゲットを管理グループに追加する際に適用する監視設定およびその他の管理設定が含まれています。ターゲットの監視設定は監視テンプレートに定義されています。監視テンプレートはターゲット・タイプごとに定義されるため、管理グループ内の異なるターゲット・タイプのそれぞれに対して監視テンプレートを作成する必要があります。おそらく、複数の監視テンプレートを作成し、管理グループに適した監視設定を定義することになります。たとえば、本番データベース用のメトリック設定を定義するデータベースの監視テンプレートを作成し、それとは別に、本番ではないデータベース用の設定を定義する監視テンプレートを作成します。テンプレート・コレクションに追加されるその他の管理設定には、コンプライアンス標準およびクラウド・ポリシーがあります。テンプレート・コレクションに追加するエンティティのすべてがEnterprise Managerで正しく定義されていることを確認してから、テンプレート・コレクションに追加します。

次の図に示す階層のように、2つ以上のレベルで定義されている管理グループ階層の場合は、管理設定がどのように管理グループのターゲットに適用されるのかを理解することが重要です。

管理グループ階層内の各グループは、テンプレート・コレクション(監視テンプレート、コンプライアンス標準およびクラウド・ポリシーから構成される)と関連付けることができます。監視設定を含むテンプレート・コレクションをProductionグループと関連付けている場合、その監視設定はProductionの下にあるFinanceおよびSalesサブグループに適用されます。Productionの下のFinanceグループに追加の監視設定がある場合は、その追加の監視設定のみを定義した監視テンプレートを作成できます。(後で、この監視テンプレートは別のテンプレート・コレクションに追加し、Financeグループに関連付けます)。Finance Template Collectionからの監視設定は、Production Template Collectionからの監視設定と論理的に結合されます。2つのテンプレート・コレクションに重複するメトリック設定が存在する場合は、Finance Template Collectionからのメトリック設定が優先され、Financeグループ内のターゲットに適用されます。この優先度のルールは、メトリック設定の場合にのみ適用されます。コンプライアンス標準ルールおよびクラウド・ポリシーの場合には、2つのテンプレート・コレクションに重複するコンプライアンス標準ルールおよびクラウド・ポリシーが存在したとしても、そのすべてがFinanceグループ内のターゲットに適用されます。

計画と準備のステップがすべて完了したら、管理グループの作成を開始できます。

6.3 管理グループおよびテンプレート・コレクションの実装

準備作業が終了したら、管理グループ階層とテンプレート・コレクションを作成するための4つの手順からなるプロセスを開始できます。管理グループのユーザー・インタフェースは、各タブに各手順の実行に必要な操作が含まれており、作成プロセスを進められるように構成されています。

このプロセスには次の手順があります。

1. 管理グループ階層の作成

2. 監視テンプレートを作成します。

3. テンプレート・コレクションの作成

4. テンプレート・コレクションの管理グループへの関連付け

5. 選択した項目とのターゲットの同期化

次の図では、完成した管理グループ階層にテンプレート・コレクションが関連付けられています。Enterprise Managerは、これを使用してターゲット監視設定の適用を自動化します。

6.3.1 管理グループ階層の作成

次に示す4つの主要なタスクは、管理グループの作成プロセスをまとめたものです。タスクは、わかりやすいように、タブのページの順番に並べています。

重要:
管理グループ階層を作成するには、「完全な任意のターゲット」および「権限伝播グループの作成」の両方のターゲット権限が必要です。

タスク1: 管理グループおよびテンプレート・コレクション・ページにアクセスします。

タスク2: 階層を定義します。

「階層」タブから、自身のターゲットを管理する方法に適した管理グループ階層を定義します。第6.3.3項「階層の定義」を参照してください。

タスク3: テンプレート・コレクションを定義します。

「テンプレート・コレクション」タブから、ターゲットに適用する監視および管理設定を定義します。第6.3.4項「テンプレート・コレクションの定義」を参照してください。

タスク4: テンプレート・コレクションを管理グループと関連付けます。

「アソシエーション」タブから、監視および管理設定を適切な管理グループに結び付けます。第6.3.5項「テンプレート・コレクションと管理グループの関連付け」を参照してください。

6.3.2 管理グループのホームページへのアクセス

管理グループのすべての操作は管理グループのホームページで実行します。

「設定」メニューから、「ターゲットの追加」、「管理グループ」の順に選択します。管理グループのホームページが表示されます。

はじめにページで、関連情報を確認します。このページに記載されている情報は、この章で概説する手順を要約したものです。参考として、ターゲット・プロパティが表示できるEnterprise Managerのすべてのターゲット・ページをはじめ、適切な管理グループ機能へのリンクが記載されています。

6.3.3 階層の定義

このページで、それまでに計画しておいた組織の階層を反映する管理グループ階層を定義し、どのターゲット・プロパティをどの階層レベルに関連付けるかを定義します。

このページの左側には、「階層レベル」および「階層ノード」の2つの表があります。

「階層レベル」表では、管理グループの階層を定義するターゲット・プロパティを追加できます。「階層ノード」表では、「階層レベル」表にあるターゲット・プロパティに関連付ける値を定義できます。ターゲット・プロパティを選択すると、「階層ノード」表の関連プロパティの値が使用可能になり、追加/削除/マージ/分割できます。「階層ノード」表のそれぞれの行は、1つの管理グループに対応しています。「Short値」列には自動生成のグループ名に使用される省略値名が表示されます。

「階層レベル」表では、管理グループ階層の各レベルを定義するターゲット・プロパティを追加できます。「階層ノード」表では、「階層レベル」表にあるターゲット・プロパティに関連付ける値を定義できます。階層ノード表の各行は、そのレベルの管理グループ階層のノードまたはグループに対応します。階層レベル表のターゲット・プロパティを選択すると、「階層ノード」表の関連プロパティの値が使用可能になり、追加/削除/マージ/分割できます。どちらかの値が、対応する管理グループのメンバーシップ基準として使用する必要がある場合は、2つ以上の値をマージする必要があります。「Short値」列には自動生成のグループ名に使用される省略値名が表示されます。

階層レベルの追加

1. 管理グループ・ページの「階層」タブをクリックします。

2. 「階層レベル」表から、「追加」をクリックして使用可能なターゲット・プロパティの1つを選択します。プロパティ/レベルは、すべてのプロパティを同時に追加するのではなく、1つずつ追加する必要があります。

3. 階層レベル表で選択したターゲット・プロパティを使用して、階層ノード表に表示される値リストを確認します。階層ノード表のターゲット・プロパティの値です。
Enterprise Managerにより、ターゲット・プロパティのすべての既存の値が、すべてのターゲットから検索されて「階層ノード」表に表示されます。「ライフサイクル・ステータス」など、ターゲット・プロパティによっては事前定義済のプロパティ値が存在し、それが自動的に「階層ノード」表に表示されます。管理グループのメンバーシップ基準として使用されないターゲット・プロパティの値を選択して削除できます。ただし、まだ利用可能ではないが、管理グループのメンバーシップ基準として使用されるプロパティ値は、追加する必要があります。

プロパティ値の追加方法を次に示します。

4. 「階層ノード」表から、「追加」をクリックします。様々なターゲットから検索した既存の値を含む、関連プロパティの値の追加ダイアログが表示されます。必要な値を選択します。複数の値は、カンマ区切りリストを使用して指定できます。たとえば、San FranciscoとZurichのように複数の場所を追加するには、「場所」ターゲット・プロパティを「階層レベル」表に追加します。「場所」を選択し、「階層ノード」表で「追加」をクリックします。「階層ノードの値」ダイアログが表示されます。次の図に示すように、「San Francisco,Zurich」と入力します。

管理グループ階層の上限の拡張

管理グループ基準としてターゲット・プロパティをサポートできる値の数にはデフォルトの上限があります。この上限値に達したことを示す警告メッセージが表示された場合、OMSプロパティのadmin_groups_width_limitを使用して上限値を増やすことができます。ターゲット・プロパティをサポートする必要がある値の最大数を指定します。たとえば、管理グループ条件で使用されるターゲット・プロパティに30個までの値をサポートするには、(OMS emctlユーティリティを使用して) admin_groups_width_limitを次のように設定します:

emctl set property -name admin_groups_width_limit -value 30 -module emoms

また、管理グループ階層のルート・ノードの下にレベルを4つまで追加できます。さらにレベルを追加する必要がある場合、まずOMSのadmin_groups_height_limitプロパティを最大高さ制限まで変更する必要があります。たとえば、ルート・ノードの下にレベルが5つある管理グループ階層を作成する場合、(OMS emctlユーティリティを使用して) admin_groups_height_limitプロパティを次のように設定します:

emctl set property -name admin_groups_height_limit -value 5 -module emoms

これはグローバル・プロパティであり、任意のOMSのemctlユーティリティを使用して1回だけ設定する必要があります。これはまた動的プロパティであり、有効にするためにOMSを停止/再起動する必要がありません。

「OK」をクリックします。次の図に示すように、「プレビュー」ペインに、2つの場所「San Francisco」および「Zurich」がノードとして表示されます。

状況によっては、複数のプロパティ値を1つとして扱うと便利な場合があります。ターゲットは異なるターゲット・プロパティ値を持つ場合がありますが、同じ監視プロファイルおよび設定を持つために、同じ管理グループに属する必要があります。たとえば、「Lifecycle Status」プロパティに対して「本番」または「基幹」のように、値の組合せを必要とする場合は、それらをマージする(1つのノードに結合する)必要があります。

プロパティ値をマージする手順:

1. 「階層レベル」表から選択したプロパティのリストから、ターゲット・プロパティを選択します。関連するプロパティ値が表示されます。

2. [Shift]キーを押しながら必要な値をクリックして複数のプロパティ値を選択します。

3. 「マージ」をクリックします。

5. グループ階層が完成するまで階層レベルの追加を繰り返します。管理グループ階層に対して行う変更は、「プレビュー」ペインに動的に表示されます。

6. グループのタイムゾーンを設定します。

1. グループ名をクリックします。「管理グループの詳細」ダイアログが表示され、適切なタイムゾーンを選択できます。

管理グループのタイムゾーンは、グループ・チャートの表示や、グループのスケジュール操作にも使用されます。これはこのグループ下に作成できるすべてのサブグループのデフォルトのタイムゾーンでもあるため、サブグループを作成する前に、管理グループ階層の最上位レベルでタイムゾーンを指定する必要があります。子のサブグループを作成すると、親グループのタイムゾーンが使用されますが、ユーザーはいつでも子のサブグループを選択してタイムゾーンを変更することができます。

自動生成の名前も変更できます。

7. 「作成」をクリックして階層を定義します。

重要:
「作成」をクリックする前に、すべての階層を定義して確認します。

管理グループ階層を作成した後でも、今後組織のニーズが変更された場合に更新できます。たとえば、グループのメンバーシップ基準のプロパティ値を追加/削除して、特定レベルの追加管理グループを作成/削除します。前述の例を使用し、San FranciscoおよびZurichに加え、別の場所、たとえばNew YorkおよびBangaloreを追加するには、「階層ノード」表で「追加」をクリックし、次の図に示すように場所を追加します。管理グループ階層の変更の詳細は、「管理グループ階層の変更」を参照してください。

「更新」をクリックして変更を保存します。

6.3.4 テンプレート・コレクションの定義

テンプレート・コレクションは、管理グループ内のターゲットに適用するために集められた監視/管理設定です。複数の監視テンプレートを、またそれも管理グループに関連付けられているテンプレート・コレクションに追加できます。しかし、テンプレート・コレクション内の特定のターゲット・タイプのために保持できる監視テンプレートは1つのみです。監視テンプレートには、管理グループ内のターゲット用のメトリック設定の完全なセットを定義します。管理グループ内のそれぞれのターゲット・タイプごとに1つの監視テンプレートを作成します。たとえば、データベース用の1つのテンプレートとリスナー用の1つのテンプレートが含まれるテンプレート・コレクションは作成できますが、データベース用の2つのテンプレートが含まれるテンプレート・コレクションは作成できません。メンバー・ターゲットが管理グループに追加されると、テンプレートの監視および管理設定が自動的に適用されます。テンプレートは、ターゲットのすべてのメトリック設定を完全に置き換えます。このことは、テンプレートを適用するとターゲットのメトリック設定(しきい値、修正処理、収集スケジュール)が上書きされ、ターゲットに存在し、テンプレートには含まれないメトリックのしきい値は削除されることを意味します。しきい値を削除すると、このようなメトリックのアラート機能が使用できなくなります。メトリック・データは引続き収集されます。

テンプレート・コレクションは、3つのタイプの監視/管理設定カテゴリで構成される場合があります。

- 監視テンプレート(監視設定)

- コンプライアンス標準(コンプライアンス・ポリシー・ルール)

- クラウド・ポリシー(仮想マシンまたはスケール・アウト・クラスタを起動するタイミングの決定などのクラウド・ポリシー)

テンプレート・コレクションを作成する場合、Enterprise Managerに用意されているデフォルトの監視テンプレート、コンプライアンス標準またはクラウド・テンプレートを使用することも、独自に作成することもできます。詳細は、第7章「監視テンプレートの使用」を参照してください。

テンプレート・コレクションを作成するには:

1. 「テンプレート・コレクション」タブをクリックします。「テンプレート・コレクション」ページが表示されます。

2. 「作成」をクリックします。

3. 「名前」フィールドで、テンプレート・コレクション名を指定します。

4. 追加するテンプレート・コレクションのメンバー・タイプ(「監視テンプレート」、「コンプライアンス標準」、「クラウド・ポリシー」)をクリックします。必要な定義ページが表示されます。

5. 「追加」をクリックします。使用可能なテンプレート・エンティティのリストが表示されます。

6. テンプレート・コレクションに追加する必要があるテンプレート・エンティティを選択します。

7. 「OK」をクリックします。

8. 必要に応じて、テンプレート・エンティティ(「監視テンプレート」、「コンプライアンス標準」、「クラウド・ポリシー」)を続けて追加します。

9. 「保存」をクリックします。新しく定義したコレクションが「テンプレート・コレクション・ライブラリ」に表示されます。

10. 別のテンプレート・コレクションを作成するには、「作成」をクリックして、ステップ2から8までを繰り返します。必要なテンプレート・コレクションが作成できるまでこのプロセスを繰り返します。

注意:
既存のテンプレート・コレクションを編集する場合、「取消」をクリックすることにより、編集セッションで行った変更を元に戻すことができます。これにより、テンプレート・コレクションが最後に保存された状態に戻されます。

6.3.4.1 必要な権限

テンプレート・コレクションを作成するには、「テンプレート・コレクションの作成」リソース権限が必要です。監視テンプレートをテンプレート・コレクションに追加するには、少なくとも特定の監視テンプレートの「表示」権限か、または任意の監視テンプレートを表示し、それをテンプレート・コレクションに追加できる「監視テンプレートの表示」権限が必要です。次の表に、テンプレート・コレクションの作成に関連するすべてのEnterprise Manager操作に必要な権限を要約しています。

Enterprise Managerの操作

最小の権限要件

管理グループ階層を作成します。

完全な任意のターゲット
権限伝播グループの作成

監視テンプレートを作成します。

監視テンプレートの作成

テンプレート・コレクションを作成します。

テンプレート・コレクションを作成します(リソース権限)。
テンプレート・コレクションに追加する監視テンプレートの表示

または

任意の監視テンプレートを表示します(リソース権限)。

コンプライアンス標準の作成

コンプライアンス・エンティティの作成
コンプライアンス標準の表示には権限不要

クラウド・ポリシーの作成

任意のポリシーの作成
クラウド・ポリシーの表示

テンプレート・コレクションを管理グループに関連付けます。

特定のテンプレート・コレクションを表示します。
グループでターゲットメトリックを管理します。

オンデマンド同期化の実行

グループのOPERATORまたはターゲット・メトリックの管理。

グローバル同期スケジュールの定義

Enterprise Managerのスーパー管理者権限

ターゲットのターゲット・プロパティの値の設定(ターゲットの管理グループへの「参加」を許可する)。

特定のターゲットのターゲットの構成

管理グループ階層を削除します。

完全な任意のターゲット

6.3.4.2 修正処理の資格証明

修正処理は、メトリック・アラートに応答して実行される自動化タスクです。修正処理が監視テンプレートまたはテンプレート・コレクションの一部である場合、修正処理を実行するために必要な資格証明は、テンプレートの適用方法に応じて異なります。

次の2つの状況は、異なる資格証明要件を示します。

- 修正処理が、ターゲットに手動で適用される監視テンプレートの一部である場合。
修正処理では、実行時に次のいずれかを使用できます。

- テンプレートを適用するユーザーの優先資格証明
または

- ユーザー指定の名前付き資格証明

ユーザーは、テンプレートの適用操作中に目的の資格証明オプションを選択します。

- 修正処理が、管理グループに関連付けられたテンプレート・コレクション内の監視テンプレートの一部である場合。
修正処理が実行されると、テンプレート・コレクションを管理グループに関連付けているユーザーの優先資格証明が使用されます。

6.3.5 テンプレート・コレクションと管理グループの関連付け

1つ以上のテンプレート・コレクションを定義した後、階層内の管理グループにこれらを関連付ける必要があります。1つのテンプレート・コレクションを1つ以上の管理グループに関連付けることができます。原則として、テンプレート・コレクションは、そのテンプレート・コレクションがすべてのサブグループにあるターゲットにも適用されるように、階層の最高レベルにある適用可能な管理グループに関連付けます。

「アソシエーション」ページに、現在の管理グループの階層ダイアグラムが表示されます。階層内の各管理グループは1つのテンプレート・コレクションにのみ関連付けることができます。

6.3.5.1 管理グループへのテンプレート・コレクションの関連付け

注意:
すべての管理グループでの「表示」権限を持たないユーザーは、グループ・ページ(「ターゲット」メニューから「グループ」を選択)から関連付けおよび関連付けの解除を実行することもできます。

1. 「アソシエーション」タブをクリックします。アソシエーション・ページが表示されます。

2. 階層内の必要な管理グループを選択します。

3. テンプレート・コレクションの関連付けをクリックします。「テンプレート・コレクションの選択」ダイアログが表示されます。

4. 必要なテンプレート・コレクションを選択し、「選択」をクリックします。この操作により影響を受けるターゲットのリストが表示されます。操作を確認するか破棄します。

注意:
階層内のすべてのサブノードにより、選択したテンプレート・コレクションが継承されます。

5. テンプレート・コレクションが必要なグループに関連付けられるまでステップ1-3を繰り返します。

注意:
テンプレートがグループに適用される際、関連付けを行う管理者のターゲット権限が使用されます。管理者は、少なくともグループの「ターゲット・メトリックの管理」権限が必要です。

注意:
階層内の下位レベルで適用される監視テンプレートからの設定により、上位レベルから継承された設定が上書きされます。これは、コンプライアンス標準またはクラウド・ポリシーには適用されません。

6.3.5.2 管理グループの検索

管理グループのUIはナビゲートが容易ですが、管理グループ階層が非常に大きいために、個別のグループを見つけるのが難しい場合もあります。アソシエーション・ページの右上隅に、大きな階層で非常に簡単にグループを見つけることができる検索機能があります。

図6-1 管理グループの「検索」ダイアログ

特定の管理グループを検索するには、次の手順に従います。

1. 表示されていなければ「検索」インタフェースを展開します。

2. グループ名全体または一部を入力し、「検索」をクリックします。

図に示すとおり、検索条件に一致する管理グループのリストが検索結果に表示されます。リストのエントリをダブルクリックして管理グループを選択できます。次に、管理グループ階層の、ルート・ノードから選択したグループまでを垂直に切り取ったもの(サブセット)が表示されます。

図6-2 管理グループの検索: グラフ表示

管理グループ階層全体を復元するには、「クリア」をクリックします。

グループ名および検索

特定の管理グループの検索を効率的に実行するために、Enterprise Managerでの管理グループ名の作成方法を知っておくと役に立ちます。Enterprise Mangerでは管理グループ条件を使用して名前を生成します。たとえば、次の条件の管理グループがあるとします。

- ライフサイクル・ステータス: 「開発」または「基幹」

- 部門: DEV

- ライン・オブ・ビジネス: 会計またはHR

- 場所: バンガロール

Enterprise Managerは切り捨てられた略称に基づいてグループ名を組み立てます。この例では、生成されたグループ名はDC-DEV-FH-Bang-Grpです。

階層を構築すると、各値に関連する略称(階層ノード表のプロパティ値の横にあるShort値列)を変更できます。したがってShort値を指定でき、Enterprise Managerは、作成されたサブグループに新しい名前を付ける際にその値を使用します。

管理グループの設計フェーズでは、カスタム名を指定するオプションがあります。しかし、多数のグループがある場合、Enterprise Managerで一意の名前を生成する方が容易です。

6.3.5.3 グローバル同期スケジュールの設定

テンプレート・コレクション/管理グループの対応付けを適用するため、グローバル同期スケジュールを設定する必要があります。このスケジュールは、管理グループ内のターゲットにテンプレートを適用するような、同期化操作の実行に使用されます。同期スケジュールが設定されていない場合、管理グループにターゲットを追加すると、Enterprise Managerが関連するテンプレートを自動的に適用します。ただし後でテンプレートを変更すると、Enterprise Managerでは同期スケジュールに基づいてこれらを適用するのみで、そうでない場合は、これらの処理が保留されます。保留の同期操作がある場合、これらは同期スケジュールに基づいて、次に使用可能な日時にスケジュールされます。

重要:
デフォルトの設定がないため、同期スケジュールを設定する必要があります。週末など、ピーク以外の時間を指定できます。

同期スケジュールを設定する手順:

1. 「同期スケジュール」をクリックします。「同期スケジュール」ダイアログが表示されます。

2. 「編集」をクリックした後、保留の同期処理(たとえばテンプレート適用操作)を実行する日時を選択します。デフォルトでは、現在の日付と時刻が表示されます。

注意:
同期化操作の開始日および日単位の間隔を指定できます。保留中の同期化操作がある場合は常に、このスケジュールに基づく次に使用可能な日付にスケジュールされます。

3. 「保存」をクリックします。

6.3.5.4 テンプレート・コレクションが同期化されるタイミング

次の表は、管理グループ内のターゲットで、いつテンプレート・コレクションの同期化操作(適用操作など)が発生するのかをまとめています。

アクション

いつ同期化が発生するか

ターゲットが管理グループに追加される(ターゲット・プロパティの設定による)

管理グループへの加入により即時に発生します。

テンプレート・コレクションが管理グループに関連付けられる

管理グループ内のターゲットは、グローバル同期スケジュールでスケジュールされている次の日付に同期化されます。

テンプレート・コレクション内のいずれかのテンプレートに変更がある。

管理グループ内のターゲットは、グローバル同期スケジュールでスケジュールされている次の日付に同期化されます。

ターゲットが管理グループから削除される(ターゲット・プロパティの変更による)。

ターゲットの監視設定は変更されません。
コンプライアンス標準およびクラウド・ポリシーとターゲットの関連付けは解除されます。

即時に同期化操作が発生します。

テンプレート・コレクションと管理グループの関連付けが解除される。

管理グループのすべてのターゲットに対するターゲットの監視設定は変更されません。コンプライアンス標準およびクラウド・ポリシーとターゲットの関連付けは解除されます。
管理グループ内のターゲットは、グローバル同期スケジュールでスケジュールされている次の日付に同期化されます。

管理グループのホームページで、「同期ステータス」リージョンの「同期化の開始」ボタンをクリックして、ユーザーがオンデマンド同期化を実行する。

即時に同期化操作が発生します。

6.3.5.5 同期ステータスの表示

特定の管理グループの現在の同期ステータスは、グループのホームページから直接確認できます。

1. 階層内の管理グループを選択します。

2. 「グループ・ホームページに移動」をクリックします。

3. 「同期ステータス」リージョンで、監視テンプレート、コンプライアンス標準またはクラウド・ポリシーの同期(あるいはその両方)のステータス(「同期」、「保留中」または「失敗」)を表示できます。
「同期化の開始」をクリックすることにより、即時に同期化を開始できます。

6.3.5.6 グループ・メンバーのタイプと同期化

管理グループのメンバー・ターゲットには、直接および間接の2つのタイプがあります。

- 直接メンバー: 管理グループの条件に一致するターゲット・プロパティを持つグループ・メンバー。関連付けられたテンプレート・コレクションからの監視設定、コンプライアンス標準、クラウド・ポリシーが直接メンバーに適用されます。

- 間接メンバー: 管理グループ基準に一致しないターゲット・プロパティを持つターゲット。ただし、親ターゲットが管理グループの直接メンバーであるため、すでに管理グループに追加されています。これらのターゲットは、他のメンバー・ターゲットがあるため、集約ターゲットとして分類されています。そのようなターゲットがグループに追加されると(管理グループまたはその他のタイプのグループ)、集約ターゲットのすべてのメンバーもグループに追加されます。集約ターゲットの例は、Oracle WebLogic Serverです。グループに追加されると、そこにあるすべてのアプリケーション・デプロイメントのターゲットもグループに追加されます。間接グループのメンバーは、テンプレートの適用/同期操作に含まれません。

直接メンバーのみが「同期ステータス」リージョンのターゲット数に表示されます。

1. 階層ダイアグラムから、グループ名をクリックして、そのグループのホームページにアクセスします。この情報には、すべてのターゲットグループ・ページからアクセスできます。

2. 「グループ」メニューから、「メンバー」を選択します。メンバー・ページが表示されます。

6.3.5.7 システム・ターゲットおよび管理グループ

システム・ターゲットが管理グループ条件に一致するために管理グループに追加された場合、システム・ターゲットとその構成メンバーも追加されます。しかし、テンプレートが目的を適用する際は、管理グループ条件に一致する直接メンバーのみを操作します。テンプレート適用操作は、ターゲット・プロパティが管理グループの条件に一致しないメンバー・ターゲットでは実行されません。ジョブやブラックアウトなどの他のグループ操作はすべて、直接および間接のすべてのメンバーに適用されます。

6.3.5.8 テンプレート・コレクションとグループの関連付けの解除

管理グループからテンプレート・コレクションの関連付けを解除するには、次の手順に従います。

1. 「設定」メニューから、「ターゲットの追加」、「管理グループ」の順に選択します。管理グループのホームページが表示されます。

2. 「アソシエーション」タブをクリックして、管理グループの階層ダイアグラムを表示します。

3. 階層ダイアグラムから、削除するテンプレート・コレクションのある管理グループを選択します。必要に応じて「検索」オプションを使用して、管理グループを検索します。

4. テンプレート・コレクションの関連付けの解除をクリックします。この操作により影響を受けるターゲット数が表示されます。「続行」または「取消」をクリックします。

テンプレート・コレクションが即時削除されます。詳細は、第6.3.3項「階層の定義」の「テンプレート・コレクションが同期化されるタイミング」を参照してください。

6.3.5.9 集約(グループ管理)設定の表示

任意の管理グループについて、個別グループ・メンバーに関連付けられているテンプレート・コレクション・コンポーネント(監視テンプレート、コンプライアンス標準またはクラウド・ポリシーの同期(あるいはその両方))を簡単に表示できます。

注意:
監視テンプレートでは、ターゲットの設定は、異なるテンプレート・コレクションからの2つ以上の監視テンプレートの統合となります。

1. 「設定」メニューから、「ターゲットの追加」、「管理グループ」の順に選択します。管理グループのホームページが表示されます。

2. 「アソシエーション」タブをクリックして、管理グループの階層ダイアグラムを表示します。

3. 階層ダイアグラムから、必要な管理グループを選択します。

4. 「グループ管理設定の表示」をクリックします。
管理グループの詳細・ページが表示されます。

このページには、選択した管理グループのメンバーに適用される、監視テンプレート、コンプライアンス標準およびクラウド・ポリシーのすべての集計設定が表示されます(ターゲット・タイプごとにリストされます)。このページにはまた、グループ・メンバーの同期化ステータスも表示されます。

管理グループ階層の別のブランチを表示するように変更するには、ページの右上の領域の「ブランチの選択」をクリックします。この機能を使用して、別のターゲット・プロパティ値を選択することで、階層ブランチを表示できます。

6.3.5.10 管理グループ・ホームページの表示

通常グループと同じように、各管理グループには、同期ステータス、階層ビューアで選択されたグループ用の関連付けられたテンプレート・コレクション、ジョブ・アクティビティまたはクリティカル・パッチ・アドバイザなどのグループ・メンバー・ステータスまたはアクティビティ(あるいはその両方)の包括的概要を示すグループ・ホームページが関連付けられています。管理グループのホームページを表示するには、次の手順に従います。

1. 階層ダイアグラムから、管理グループを選択します。

2. 「グループ・ホームページに移動」をクリックします。その特定の管理グループのホームページが表示されます。

または、Enterprise Mangerの「ターゲット」メニューから「グループ」を選択します。その表から、グループの階層を開くことができます。

6.3.5.11 任意の管理グループの一部でないターゲットの識別

「アソシエーション」ページから、未割当てターゲット・レポートを生成することにより、任意の管理グループに属さないターゲットを確認できます。

1. 「アクション」メニューから、「未割当てのターゲット・レポート」を選択します。レポートには、任意の管理グループの一部でないすべてのターゲットがリストされます。管理グループ階層を定義するターゲット・プロパティの値が表示されます。

2. Viewメニューから、必要な情報のみを表示するカスタマイズ・オプションを選択します。

注意:
「権限伝播ではない集計」列は、ターゲットが権限伝播ではない集計かどうかを示します。このタイプのターゲットは、計画的に権限伝播である管理グループには追加できません。このため、管理グループに追加された集計ターゲットも権限伝播であることが必要です。集約ターゲット権限を伝播させるには、EM CLI verb modify_systemおよび-privilege_propagation=true optionを使用します。詳細は、Enterprise Managerコマンドラインのリファレンス・ガイドを参照してください。

このページでリストを確認し、管理グループに追加する必要のあるターゲットを把握できます。このページに表示されるターゲットの名前をクリックし、ターゲットのターゲット・プロパティを編集ページにアクセスしてターゲット・プロパティの値を変更できます。必要な変更を行って「OK」をクリックすると、未割当てのターゲット・ページに戻ります。

ターゲット・プロパティの変更の詳細は、「管理グループの計画」を参照してください。

3. ブラウザの「戻る」ボタンをクリックして「管理グループとテンプレート・コレクション」のホームページに戻ります。

6.4 管理グループ階層の変更

組織が静的であることはまれで、新しい取扱商品が追加されたり、組織の拡張によってグループが再編成されたりする場合があります。これらの変更に対応するために、既存の管理グループ階層を変更する必要があることがあります。

Enterprise Manager 12c リリース12.1.0.3から、階層全体を再構築しなくても管理グループ階層を変更できるようになりました。各階層レベルへのグループの追加、2つ以上のグループのマージ、または階層全体のレベルの追加/削除など、管理グループの変更を容易に実行できます。これらの操作はすべて、階層ページから実行できます。

重要:
管理グループ階層に変更を加えた後、「更新」をクリックして変更を保存してください。

6.4.1 新しい階層レベルの追加

新しい階層レベルの追加は、新しいターゲット・プロパティを管理グループ条件に追加することと同じです。このため、ターゲットが管理グループ階層の一部であり続けるためには、すべてのターゲットに対してこのターゲット・プロパティの値を設定する必要があります。新しく追加されたターゲット・プロパティまたは追加された階層レベルは、常に階層の最下位レベルとして追加されます。レベルとレベルの間に新しいレベルを挿入することはできません。

階層レベルを挿入するには、階層レベルを削除してから必要なレベルを追加します。レベルを削除するとその階層レベルに対応するグループも削除されるため、階層レベルを削除する前に慎重に検討してください。

新しいレベルを追加する順を追った説明は、第6.3.3項「階層の定義」の「階層レベルの追加」を参照してください。

6.4.2 階層レベルの削除

階層レベルの削除は、ターゲット・プロパティの削除と同じことであり、そのレベルのグループが削除されます。このため、階層レベルを削除したときに削除されるグループについて、特にこれらのグループがEnterprise Managerの他の機能領域で使用されているかどうか、慎重に検討してください。

階層レベルを削除する手順:

1. 管理グループ・ページの「階層」タブをクリックします。

2. 「階層レベル」表から、階層レベルを選択して「削除」をクリックします

3. 「更新」をクリックして変更を保存します。

それらのグループのいずれかに関連付けられたテンプレート・コレクションがある場合、削除されたグループのサブグループは関連付けられたテンプレート・コレクションから監視設定を取得していたため、サブグループの監視設定が影響を受けます。残りのテンプレート・コレクションを確認し、テンプレート・コレクションを適切な管理グループと再び関連付ける必要があります。

6.4.3 管理グループのマージ

2つ以上の管理グループをマージする場合、管理グループ階層定義で対応するターゲット・プロパティ条件をマージします。グループ・マージ操作は、マージするグループの1つを保持し、他のグループから保持するグループにターゲットを移動することで構成されます。ターゲットを移動すると、他のグループは削除されます。

対応するターゲット・プロパティ値を選択することによって、保持するグループを選択します。選択したターゲット・プロパティ値を条件の一部として含むグループは、保持されます。保持されるターゲット・プロパティ条件が複数のグループ(つまりサブグループを含むグループ)に対応する場合、ターゲットは最下位レベルの管理グループにのみ存在するため、ターゲットの移動は実際には最下位レベルの管理グループで発生します。上位レベルの管理グループの条件は、マージされた他のグループの条件を含むように更新されます。

グループをマージする手順:

1. 「階層レベル」表から選択したプロパティのリストから、ターゲット・プロパティを選択します。マージするグループに対応するターゲット・プロパティを選択します。

たとえば、<Devt-Group>を<Test or Stage Group>とマージするとします。階層で、これはターゲット・プロパティ「ライフサイクル・ステータス」と対応します。関連するプロパティ値が表示されます。

2. [Shift]または[Ctrl]キーを押しながら必要な値をクリックして、マージするグループに対応する複数のプロパティ値を選択します。

3. 「マージ」をクリックします。

「マージ値」ダイアログが表示されます。

もう一度説明しますが、メンバーシップ基準(ターゲット・プロパティ)をマージすることによって、管理グループおよびそのサブグループをマージしています。保持する管理グループを選択します。他のグループはそのグループにマージされます。

4. 保持するグループを選択し、保持するグループの既存の名前を使用するか新しい名前を使用するかを指定します。

重要:
保持するグループを決定する際、インシデント・ルール・セット、システム・ダッシュボード、ロールなどの大部分のグループ操作で使用するグループを選択することを考慮してください。これらのグループは保持され、他のマージされるグループのメンバーは保持されたグループに所属します。マージの後、保持されたグループのグループ操作は、他のマージされたグループのメンバーにも適用されるようになります。このようにすることによって、マージの影響が最小限に抑えられます。

5. 「OK」をクリックしてグループをマージします。

6. 「更新」をクリックして新しい階層を保存します。

例

管理グループは次で構成されます:

階層レベル

- ライフサイクル・ステータス

- ライン・オブ・ビジネス

階層ノード

- ライフサイクル・ステータス

- 開発

- Mission Critical(基幹)またはProduction(本番)

- Staging(ステージング)またはTest(テスト)

- ライン・オブ・ビジネス

- Online Store(オンライン・ストア)

- Sales(販売)

- Finance(会計)

次の図に管理グループ階層を示します。

監視設定が同じであるため、Mission Critical(基幹)またはProduction(本番)グループをStaging(ステージング)またはTest(テスト)グループにマージするかどうかを判断します。

「階層レベル」表から「ライフサイクル・ステータス」を選択します。

「階層ノード」表からMission Critical(基幹)またはProduction(本番)およびStaging(ステージング)またはTest(テスト)の両方を選択します。

「階層ノード」メニューから「マージ」を選択します。

「マージ値」ダイアログが表示されます。ここでは、保持されるグループの元の名前(Mission Critical(基幹)またはProduction(本番))を保持します。

マージを完了するために「OK」をクリックすると、結果の管理グループ階層が表示されます。Test-Salesグループのすべてのターゲットが、Prod-Salesグループに移動しました。Test-Salesグループは削除されました。Test-Financeグループのすべてのターゲットは、Prod-Financeグループに移動しました。Test-Financeグループは削除されました。

「更新」をクリックして変更を適用します。

6.4.4 管理グループの削除

管理グループ階層の全体を、または階層から個々の管理グループを削除できます。管理グループを削除すると、対応付けは削除されますが、ターゲットやテンプレート・コレクションは削除されません。保存されているすべてのメンバーシップ基準は削除されます。管理グループを削除すると、保存されているメンバーシップ基準もすべて削除されます。

管理グループ階層全体を削除するには、次の手順に従います。

1. 「設定」メニューから、「ターゲットの追加」、「管理グループ」の順に選択します。

2. 「階層」タブをクリックします。

3. 「削除」をクリックします。

階層から個別の管理グループを削除するには、次の手順に従います。

1. 「設定」メニューから、「ターゲットの追加」、「管理グループ」の順に選択します。

2. 「階層」タブをクリックします。

3. 「階層レベル」表から、削除する管理グループのある階層レベルに対応するターゲット・プロパティを選択します。

4. 「階層ノード」表から、削除する管理グループ(メンバーシップ基準のプロパティ値)を選択します。

5. ドロップダウン・メニューから「削除」を選択します。

6. 「更新」をクリックします。

7 監視テンプレートの使用

監視テンプレートは、監視設定とメトリックおよびコレクション設定を1回のみ指定し、多くのターゲットのグループに、必要に応じた回数適用できるようにすることで、多数のターゲットの監視の設定作業を簡略化します。

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

- 監視テンプレートについて

- 監視テンプレートの定義

- デフォルト・テンプレート(自動適用テンプレート)

- 監視テンプレートのリスト表示

- 監視テンプレートの作成

- 監視テンプレートの編集

- ターゲットへの監視テンプレートの適用

- ターゲットとの監視テンプレートの比較

- 情報パブリッシャを使用したメトリック設定の比較

7.1 監視テンプレートについて

監視テンプレートを使用すると、監視設定を一度指定してそれらを監視ターゲットに適用することで、エンタープライズ全体の監視設定を標準化できます。これらのテンプレートは、1つ以上のターゲットまたはグループを対象として保存、編集および適用できます。監視テンプレートは特定のターゲット・タイプに対して指定し、同じタイプのターゲットにのみ適用できます。たとえば、ある監視テンプレートをテスト・データベース用に定義し、別の監視テンプレートを本番データベース用に定義できます。

監視テンプレートでは、ターゲットを監視するために通常設定している次のようなすべてのEnterprise Managerパラメータを定義します。

- テンプレートを適用するターゲット・タイプ。

- メトリック(メトリック拡張を含む)、しきい値、メトリック収集スケジュールおよび修正処理。

監視テンプレートを定義すると、ターゲットに適用することができます。これは、手動でEnterprise Managerコンソールを使用してコマンドライン・インタフェース(EM CLI)経由か、または自動でテンプレート・コレクションを使用して、どちらかで行うことができます。詳細は、「テンプレート・コレクションの定義」を参照してください。どのターゲットでも、テンプレートによる上書きが不可能なメトリック設定を指定することで、カスタム監視設定を維持できます。

オラクル社認定テンプレート

ユーザーが作成するテンプレートの他に、オラクル社認定テンプレートもあります。これらのテンプレートには、特定の目的のために特定のセットのメトリックが含まれています。テンプレートの目的は、テンプレートに関連付けられた説明に示されています。

例: 「オラクル社認定 - SIデータベースのAQメトリックの有効化」というテンプレートには、単一インスタンス・データベース用のアドバンスト・キューイング関連のメトリックが含まれています。AQメトリックを使用する場合、このオラクル社認定テンプレートを使用できます。または、メトリック設定を独自のテンプレートにコピーできます。

7.2 監視テンプレートの定義

監視テンプレートでは、ターゲットを監視するために通常設定しているすべてのEnterprise Managerパラメータを定義します。テンプレートでは、次の項目を指定します。

- 名前: テンプレートの一意識別子。テンプレート名は、Enterprise Managerで定義されたすべてのテンプレート間でグローバルに一意である必要があります。

- 説明: テンプレートの目的を記述するテキスト(オプション)。

- ターゲット・タイプ: テンプレートを適用するターゲット・タイプ。

- 所有者: テンプレートを作成したEnterprise Manager管理者。

- メトリック: ターゲット・タイプのメトリック。監視テンプレートでは、ターゲット・タイプのすべてのメトリックのサブセットを指定できます。これらのメトリックを使用して、しきい値、収集スケジュールおよび修正処理の指定が可能です。

- 収集されたその他のアイテム: 環境に関するその他の収集された情報(メトリック以外)。

7.3 デフォルト・テンプレート(自動適用テンプレート)

状況によっては、デフォルトの監視設定では監視する環境のターゲットに適切でない場合があります。特定のターゲット・タイプのメトリックおよびコレクション設定に互換性がない場合、不要な/意図しないアラート通知が生成される可能性があります。Enterprise Managerでは、新しく追加されたターゲットに自動的に適用されるデフォルトの監視テンプレートを設定できるため、監視する環境に適した監視設定を適用できます。

注意:
デフォルトの監視テンプレートを定義するには、スーパー管理者権限が必要です。

7.4 監視テンプレートのリスト表示

すべての監視テンプレートのリストを表示するには、「エンタープライズ」メニューから「監視」、「監視テンプレート」の順に選択します。

監視テンプレート・ページには、すぐに使用できるテンプレートすべてと、少なくとも「表示」権限を持っているテンプレートが表示されます。Enterprise Managerスーパー管理者はすべてのテンプレートを表示できます。

図7-1 監視テンプレート

このページから監視テンプレート作成プロセスを開始できます。

7.5 監視テンプレートの作成

モニタリング・テンプレートでは、特定のターゲット・タイプのモニタリング設定を定義および保存できます。このようなことから、モニタリング・テンプレートの作成には特定のEnterprise Manager権限が必要です。

モニタリング・テンプレートの作成または表示(あるいはその両方)ができるよう、ユーザーやロールに対して付与できるリソース権限は次のように2つあります。

- モニタリング・テンプレートの作成
この権限によりモニタリング・テンプレートを作成することができます。

- 任意の監視テンプレートの表示
この権限により任意のモニタリング・テンプレートを表示することができます。

これらの権限は、任意のEnterprise Managerユーザーの「リソース権限」ページから付与するか、ロールを作成する際に付与することができます。

モニタリング・テンプレートは典型的なアクセス・モデルに従っています。すなわち、他のユーザーやロールに対してテンプレートへの完全なアクセス権または表示アクセス権を与えることができます。表示アクセス権があればモニタリング・テンプレートの表示および使用が可能です。完全なアクセス権があればモニタリング・テンプレートの表示、使用、編集および削除が可能です。テンプレートの所有者はテンプレートへのアクセス権を変更できます。

デフォルトでは、Enterprise Managerスーパー管理者はすべてのモニタリング・テンプレートへの完全なアクセス権を持っています。

監視テンプレートでは、特定のターゲット・タイプの監視設定を定義および保存できます。新規テンプレートを定義するには:

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. 「作成」をクリックします。Enterprise Managerには、特定のターゲットまたはターゲット・タイプのいずれかを選択するオプションがあります。テンプレート監視設定が、選択したターゲットまたはターゲット・タイプに応じて移入されます。「続行」をクリックします。

注意:
選択したターゲット・タイプが「Webアプリケーション」または「サービス」である場合、「オペレータ」権限を持っているターゲットしか選択できません。

3. 必要なテンプレート条件を、「一般」、「メトリックしきい値」および「収集されたその他のアイテム」タブに入力します。
「メトリックしきい値」タブで、監視テンプレート・メトリックを削除または追加できます。既存のメトリックを削除するには、1つ以上のメトリックを選択し、「テンプレートからのメトリックの削除」をクリックします。

メトリックを追加するには、「メトリックをテンプレートに追加」をクリックします。次の図のように、メトリックをテンプレートに追加ページが表示されます。

このページで、メトリックをテンプレートにコピーできる元のソースを選択できます。ソースには、特定のターゲット、その他の監視テンプレートまたはメトリック拡張が含まれます。注意: モニタリング・テンプレートにメトリックを追加するには、メトリック拡張のしきい値を定義する必要があります。

「続行」を1回クリックして、テンプレート・メトリックの変更を終了します。

4. 必要な情報の入力を終了したら、「OK」をクリックします。

7.6 監視テンプレートの編集

監視テンプレート・ページに、表示可能なすべてのテンプレートがリストされます。テンプレートを編集するには、「完全」アクセス権限が必要です。

監視テンプレートを編集するには:

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. 表から目的のテンプレートを選択します。

3. 「編集」をクリックします。

4. 変更が終了したら、「OK」をクリックします。

アクセスの他のユーザーとの共有

デフォルトでは、テンプレートの所有者(作成者)はそのテンプレートに「完全」アクセス権を持ち、Enterprise Managerのスーパー管理者はすべてのテンプレートに「完全」アクセス権を持ちます。テンプレートの所有者のみがそのテンプレートのアクセス権を変更できます。所有者としてユーザーは、そのテンプレートの「表示」(テンプレートの表示)または「完全」(テンプレートの編集または削除)アクセス権をユーザーまたはロールに付与できます。

7.7ターゲットへの監視テンプレートの適用

前述のように、監視テンプレートは同じターゲット・タイプの1つ以上のターゲット、またはグループなどのコンポジット・ターゲットに適用できます。コンポジット・ターゲットの場合、テンプレートは該当するタイプのすべてのメンバー・ターゲットに適用されます。テンプレートを手動またはEM CLI経由で適用した場合、テンプレートが適用されると、テンプレートを後で変更してもターゲットへの自動的な伝播は行われないため、影響するすべてのターゲットにテンプレートを再適用する必要があります。

管理グループとテンプレート・コレクション: 監視テンプレートの自動的な適用

新しいターゲットがEnterprise Manager環境に追加されるたびに、監視テンプレートは自動的に適用されます。自動化は管理グループおよびテンプレート・コレクションを介して実行されます。管理グループは、グループへの結合時にターゲットに対する監視設定の適用を完全に自動化するために使用される特別なタイプのグループです。ターゲットが管理グループに追加される際、Enterprise Managerにより、監視テンプレート、コンプライアンス標準およびクラウド・ポリシーで構成される関連テンプレート・コレクションから監視設定が適用されます。後で監視テンプレートが変更されると、Enterprise Managerは同期スケジュールに基づき、その変更を関連するターゲットに自動的に適用します。詳細は、「管理グループの使用」を参照してください。

7.7.1 監視テンプレートの適用

テンプレートを適用するには、少なくとも適用先ターゲットに対する「ターゲット・メトリックの管理」ターゲット権限が必要です。

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. 表から目的のテンプレートを選択します。

3. 「適用」をクリックします。

4. 目的の適用オプションおよびテンプレートを適用するターゲットを選択します。その他の情報は、第7.7.2項「監視テンプレートの適用オプション」を参照してください。

5. 「OK」をクリックします。

7.7.2 監視テンプレートの適用オプション

グループ、システムまたはクラスタなどの集合ターゲットを、適用先ターゲットとして選択できます。テンプレートは、グループ、システムまたはクラスタに現在存在する該当メンバーに適用されます。後から、グループに新規のメンバーが追加された場合は、それらの新規メンバーに対してテンプレートを再適用する必要があります。テンプレートの適用は、非同期ジョブとしてバックグラウンドで実行されるため、適用操作が実行された後、メインのテンプレート表の「保留中の適用操作」列の下のリンクをクリックすれば、まだ保留中の適用操作を確認できます。

監視テンプレートを適用すると、しきい値、比較演算子、修正処理などのメトリック設定が適用先ターゲットにコピーされます。また、収集頻度およびアップロード間隔などのメトリック収集スケジュールもターゲットにコピーされます。Enterprise Managerによってメトリック設定がテンプレートからターゲットに適用される方法は、適用オプションの選択によって決定します。

7.7.2.1 適用オプション

テンプレート適用オプションにより、テンプレートのメトリックおよびポリシー設定がターゲットに適用される方法を制御します。2つのテンプレート適用オプションが用意されています。

- テンプレートは、ターゲット内のすべてのメトリック設定を置換します。: テンプレートが適用されると、テンプレートに定義されているすべてのメトリックおよびポリシーがターゲットに適用されます。テンプレートに定義されていない既存のターゲット監視設定は無効になります。メトリックのしきい値はNULLまたは空白に設定されます。ポリシーは無効になります。これにより、現在の重大度および違反がクリアされ、これらのメトリックおよびポリシーからアラートが解消されます。

- テンプレートは、テンプレートとターゲットに共通のメトリックだけを上書きします。: テンプレートが適用されると、テンプレートとターゲットの両方に共通のメトリックおよびポリシーのみが更新されます。テンプレート内に存在しない既存のターゲットのメトリックおよびポリシーはそのままで影響を受けません。このオプションを選択すると、キー値設定を持つメトリックに対して追加のテンプレート適用オプションが使用可能になります。

7.7.2.2 キー値設定を持つメトリック

キー値設定を持つメトリックは、異なるしきい値で複数のオブジェクトを監視できるメトリックです。たとえば、「使用可能なファイルシステム領域(%)」メトリックは、マウント・ポイントごとに異なる警告およびクリティカルのしきい値を使用して、異なるマウント・ポイントを監視できます。

テンプレートに、キー値設定を持つメトリックが含まれる場合、このテンプレートをターゲットに適用する際に、3つのオプションのいずれかを選択できます。例として、テンプレートに次のメトリックがある場合を考えてください。

使用可能なファイルシステム領域(%)

マウント・ポイント

演算子

警告のしきい値

クリティカルのしきい値

/

≤

40

20

/private

≤

30

20

/private2

≤

20

20

/u1

≤

30

20

その他すべて

≤

25

15

ホスト・ターゲットには、異なる設定で同じメトリックがあります。

マウント・ポイント

演算子

警告のしきい値

クリティカルのしきい値

/

≤

30

10

/private

≤

25

15

/private2

≤

20

20

その他すべて

≤

25

15

次に各オプションの結果を示します。

1) テンプレートのすべてのキー値設定がターゲットに適用され、ターゲットにある追加のキー値設定は削除されません

このコピー・オプションを使用して、ターゲットにテンプレートを適用した場合、マウント・ポイント、/、/privateおよび/U1に対するテンプレート設定がすべて適用されます。テンプレートの対象ではないマウント・ポイントの既存のターゲット設定はそのままで影響を受けません。その結果、ターゲットでこのメトリックに対して適用される設定は、次のようになります。

マウント・ポイント

演算子

警告のしきい値

クリティカルのしきい値

/

≤

40

20

/private

≤

30

20

/u1

≤

30

20

2) テンプレートのすべてのキー値設定がターゲットに適用され、ターゲットにある追加のキー値設定は削除されます。

このコピー・オプションを使用して、ターゲットにテンプレートを適用した場合、すべてのテンプレート設定がターゲットに適用されます。ターゲット上にのみ存在するオブジェクト固有のしきい値設定は削除され、テンプレート内にのみ存在するオブジェクト固有のしきい値が、ターゲットに追加されます。したがって、ターゲットの最終設定は次のようになります。

マウント・ポイント

演算子

警告のしきい値

クリティカルのしきい値

/

≤

40

20

/private

≤

30

20

/u1

≤

30

20

その他すべて

≤

25

15

3) テンプレートとターゲットの両方に共通のキー値に対する設定のみがターゲットに適用されます

このコピー・オプションを使用して、ターゲットにテンプレートを適用した場合、共通のマウント・ポイント、/と/privateに対する設定のみが適用されます。その結果、ターゲットでこのメトリックに対して適用される設定は、次のようになります。

マウント・ポイント

演算子

警告のしきい値

クリティカルのしきい値

/

≤

40

20

/private

≤

30

20

/private2

≤

20

20

その他すべて

≤

25

15

7.8 ターゲットとの監視テンプレートの比較

適用先ターゲットに監視テンプレートを適用した際の影響を、必ず予測できるとはかぎりません。Enterprise Managerの監視テンプレート比較機能を使用すると、テンプレートの適用方法および適用時期の決定を簡略化できます。これにより、テンプレートに定義されているメトリックやコレクション設定が、適用先ターゲットの定義とどのように異なるかが一目でわかります。以前適用した監視設定に、まだターゲットが準拠しているかどうかを容易に判断できます。このテンプレート比較機能は、グループやシステムなどの集計ターゲットとともに使用すると特に便利です。たとえば、グループ・メンバーのメトリックやコレクション設定をテンプレートのものと簡単に比較し、テンプレートを適切に適用できます。

監視テンプレートとターゲットの比較を実行します。

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. 表から目的のテンプレートを選択します。

3. 「設定の比較」をクリックします。監視テンプレートの比較ページが表示されます。

4. 「追加」をクリックし、1つ以上の宛先ターゲットを追加します。「検索と選択」ダイアログが表示されます。

5. 1つ以上の宛先ターゲットを選択して「選択」をクリックします。選択したターゲットが宛先ターゲットのリストに追加されます。

6. 新しく追加された宛先ターゲットを選択して「続行」をクリックします。テンプレートの設定の比較ジョブが正常に発行されたことを示す確認メッセージが表示されます。

7. 「OK」をクリックして、ジョブ結果を表示します。注意: ジョブ実行の複雑度により、ジョブの完了に時間がかかる場合があります。

7.8.1テンプレートとターゲットのメトリックが異なると判断される場合

次に示すいずれかまたはすべての条件に当てはまる場合、メトリックは異なると判断されます(ターゲットでそのメトリックにテンプレートのオーバーライドが設定されていない場合)。

- 警告のしきい値設定が異なる場合。

- クリティカルのしきい値設定が異なる場合。

- 収集スケジュールが異なる場合。

- アップロード間隔が異なる場合。

- (メトリックの値がしきい値を超え続けた場合にアラートが発行される)発生数が異なる場合。

- ユーザー定義メトリックの場合は、上述の条件に加え、ユーザー定義メトリックの評価に使用されるOSコマンド/SQL文が異なる場合。この条件は、ユーザー定義のメトリック名および戻り型が同一である場合にのみ適用されます。

- 削除のマークが付いているメトリック拡張は、次のような場合にのみ、適用先ターゲットおよびテンプレートで異なると表示されます。

- 適用先ターゲットとテンプレートの両方に同じ名前のメトリック拡張が存在する場合。

- 適用先ターゲットとテンプレートの両方でメトリック拡張の戻り型(文字列および数値)が同じ場合。

- 適用先ターゲットとテンプレートの両方でメトリック型が同じ場合。

7.9 情報パブリッシャを使用したメトリック設定の比較

監視テンプレートの比較ユーザー・インタフェースを使用すると、監視テンプレートと適用先ターゲットのメトリックの違いを表示できますが、情報パブリッシャを使用してターゲットとテンプレートの違いを含むレポートを生成することもできます。情報パブリッシャのレポート機能を使用すると、メトリックの比較データをより柔軟に表示および分散できます。詳細は、「情報パブリッシャの使用」を参照してください。

レポート定義の作成

1. 「エンタープライズ」メニューから、「レポート」、「情報パブリッシャ・レポート」の順に選択します。

2. 「作成」をクリックします。「レポート定義を作成」ユーザー・インタフェースが表示されます。

3. 一般ページで、レポート名、ターゲットをどのように含めるか、ターゲット権限、レポート期間および表示オプションを指定します。

4. 要素ページで、「追加」をクリックして、要素の追加ページにアクセスします。

5. 「監視テンプレート比較」要素を選択して「続行」をクリックし、要素ページに戻ります。

6. レポート要素を追加したらパラメータ設定アイコンをクリックして、必須操作パラメータを指定します。このページでは、レポート・ヘッダーを指定し、複数のしきい値メトリックに対して監視テンプレート、適用先ターゲットおよびテンプレート適用設定の選択を行います。「続行」をクリックして、要素ページに戻ります。

7. 「レイアウト」をクリックして、レポートでの情報の配置を指定します。

8. 「プレビュー」をクリックして、レポートのデータおよび表示に満足するかどうかを確認します。

9. スケジュール・ページで、レポートをいつ生成するか、コピーを保存するか、または電子メールで送信するか(あるいはその両方を行うか)、保存コピーをどのようにパージするかを定義します。

10. アクセス・ページで、「追加」をクリックして、どのEnterprise Manager管理者またはロール(あるいはその両方)に生成されたレポートの表示を許可するかを指定します。さらに、GRANT_ANY_REPORT_VIEWERシステム権限がある場合は、このレポート定義を、資格証明のないユーザーにも、Enterprise ManagerレポートWebサイトを介してアクセス可能にすることができます。

11. 終了したら「OK」をクリックします。

12. レポート定義を検証します。指定したパラメータが競合する場合、検証エラーまたは警告が表示され、何に注意が必要かを知らせます。

13. レポート定義が正常に保存されると、「レポート定義」リストの、一般ページで指定した「カテゴリ」と「サブカテゴリ」の下に、このレポート定義が表示されます。

レポートの表示

1. 「レポート定義」リストでテンプレート比較レポート定義を見つけます。「検索」機能を使用して見つけることも、レポート定義のリストをフィルタ処理することもできます。

2. レポート定義のタイトルをクリックします。レポートに指定ターゲットがある場合、レポートはただちに生成されます。レポートに指定ターゲットがない場合は、ターゲットを選択するように要求されます。

レポートの自動生成のスケジュール

1. レポート定義を作成または編集します。

2. スケジュール・ページで、「スケジュール・レポート」オプションを選択します。

3. スケジュール・タイプを指定します。このページのスケジュール・パラメータは、選択したスケジュール・タイプに応じて変わります。

レポートの自動生成をスケジュールする際に、コピーを管理リポジトリに保存するか、またはレポートの電子メール版を指定した受信者に送信するか(あるいはその両方)のオプションがあります。

レポートがコピーを保存するようにスケジュールされている場合、スケジュールされたレポートが完了するたびに、コピーが保存されます。ユーザーがレポート・タイトルをクリックして保存コピーでレポートを表示する際、保存コピーの最新版がレンダリングされます。保存コピーの完全なリストを参照するには、レポートの最上部にある「保存されたコピー」リンクをクリックします。Enterprise Manager管理者は、レポート上の「リフレッシュ」アイコンをクリックすることで、レポートのコピーを要求に応じて生成できます。

7.10 監視テンプレートのエクスポートとインポート

移植性のため、管理テンプレートはXMLファイルにエクスポートでき、別のEnterprise Managerインストールにアクティブ・テンプレートとしてインポートできます。

重要:
テンプレートはEnterprise Manager 10gリリース2以上からエクスポートでき、Enterprise Manager 13cにインポートできます。

監視テンプレートのエクスポート

テンプレートをXMLファイルにエクスポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. 表から目的の監視テンプレートを選択します。

3. 「エクスポート」をクリックします。
注意: Enterprise Manager 11gまたはそれ以前のリリースを実行している場合、EM CLI export_template動詞を使用してエクスポート操作を実行できます。監視テンプレートに以前のEnterprise Managerリリース(12c以前)からのポリシー・ルールが含まれる場合、このリリースにはすでに存在しないポリシー・ルールなので、Enterprise Manager 12cにインポートされません。

監視テンプレートのインポート

XMLファイルからテンプレートをインポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. 「インポート」をクリックします。テンプレートのインポート・ページが表示されます。

3. インポートする監視テンプレートXMLファイルを指定します。

4. 「インポート」をクリックします。

7.11 Enterprise Managerのアップグレード: 監視テンプレートの比較

あるリリースのEnterprise Managerから次のリリースにアップグレードする際、異なるリリース用に作成された監視テンプレートを累積します。Enterprise Managerリリース12.1.0.4以上では、Enterprise Managerの様々なリリース用に作成されているテンプレートを表示できる、アップグレード後の監視テープレートの相違点を示すレポートを生成できます。監視テンプレートの相違点を示すレポートを生成するには、「設定」メニューから、「Cloud Controlの管理」、「アップグレード後のタスク」の順に選択します。

7.12 監視テンプレート適用履歴保存期間の変更

情報パブリッシャの事前定義済レポートを使用して、監視テンプレート適用履歴を表示できます。「エンタープライズ」メニューから、「レポート」、情報パブリッシャの順に選択します。情報パブリッシャ・ページで、「タイトル」テキスト・エントリ・フィールドに"template"と入力し、「実行」をクリックできます。事前定義済レポート「監視テンプレートの適用履歴(過去7日間)」がレポート・リストに表示されます。

デフォルトで、Enterprise Managerは監視テンプレート適用履歴を180日間保存します。必要ならば、監視要求に応じた値に保存期間を変更できます。保存期間を無期限にすることはできませんが、非常に長い期間に設定することはできます。Enterprise Managerでは保存期間を変更するために次のPL/SQL APIが用意されています。

mgmt_template_ui.modify_purge_policy(p_retention_days=><num_days>)

このプロシージャは、入力としてNUMBERを使用します(num_days)。

8 メトリック拡張の使用

メトリック拡張を使用すると、Oracleの監視機能を拡張してIT環境に固有の条件を監視できるようになります。これにより、環境の包括的な情報を把握できます。さらに、メトリック拡張では、他のモニタリング・ツールを使用してこの補足的な監視を提供するかわりに、データセンター全体でEnterprise Managerを単一の集中モニタリング・ツールとして使用することによって、IT組織の運用プロセスを簡略化できます。

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

- メトリック拡張とは

- メトリック拡張のライフサイクル

- メトリック拡張の使用

- アダプタ

- メトリック拡張へのユーザー定義メトリックの変換

- メトリック拡張のコマンドライン動詞

説明用ビデオ:
メトリック拡張の使用に関するビデオ・チュートリアルは、次を参照してください。
メトリック拡張パート1: メトリック拡張の作成

https://apex.oracle.com/pls/apex/f?p=44785:24:115515960475402:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5741%2C24

メトリック拡張パート2: メトリック拡張のデプロイ

https://apex.oracle.com/pls/apex/f?p=44785:24:15296555051584:::24:P24_CONTENT_ID%2CP24_PREV_PAGE:5742%2C24

8.1 メトリック拡張とは

メトリック拡張によって、どのタイプのターゲットでもメトリックを作成できます。ユーザー定義メトリック(以前のEnterprise Managerリリースで監視を拡張するために使用された)とは異なり、メトリック拡張では、次のような多数のターゲット・タイプに対して本格的なメトリックを作成できます。

- ホスト

- データベース

- Fusion Applications

- IBM Websphere

- Oracle Exadataデータベースおよびストレージ・サーバー

- Siebelコンポーネント

- Oracle Business Intelligenceコンポーネント

メトリック拡張は「メトリック拡張」ページで管理します。このページでは、すべてのメトリック拡張がリストされるだけでなく、メトリック拡張を作成、編集、インポート/エクスポートおよびデプロイできます。

メトリック拡張はOracle Integration Adapterに基づいています。アダプタは、特定のプロトコルを使用して、ターゲットに関するデータの収集手段を提供します。アダプタが使用できるかどうかは、メトリック拡張で監視するターゲットのタイプによって異なります。

メトリック拡張とユーザー定義メトリックの違い

Enterprise Managerの以前のリリースでは、ユーザー定義メトリックを使用して監視機能を拡張していましたが、制限がありました。OSスクリプトの実行によるポイント値の収集や、SQLによる少し複雑な値セット(オブジェクトごとに1つ)の収集を行うことができました。メトリック拡張とは異なり、ユーザー定義メトリックには次のような制限がありました。

- 統合の制限: OSまたはSQLのユーザー定義メトリックが、カスタム・スクリプトまたは必須の追加依存ファイルを実行する場合、ユーザーはそれらのファイルをターゲットのファイル・システムに手動で転送する必要がありました。

- 問合せプロトコルの適用制限: OSユーザー定義メトリックは、メトリックから複数の行を返して、サーバーの子オブジェクトをモデル化することができません(この機能はSQLユーザー定義メトリック専用です)。

- データ収集の制限: 正規のEnterprise Managerメトリックは、1つの問合せで複数のデータを収集でき、関連するデータをアラート・コンテキストに反映することができます。ただし、ユーザー定義のメトリックの場合は、複数のユーザー定義メトリックを作成することによって、データの複数のピースを収集する必要があります。データは個別に収集されているため、アラートの生成時に関連付けられたデータを参照することはできません。

- 問合せプロトコルの制限: ユーザー定義メトリックで使用できるのはOSプロトコルとSQLプロトコルのみです。メトリック拡張では、SNMPやJMXなど、その他のプロトコルも使用できます。

- ターゲット・アプリケーションの制限: ユーザー定義メトリックで作成できるのは、ホスト・ターゲットにはOSユーザー定義メトリック、データベース・ターゲットにはSQLユーザー定義メトリックのみです。その他のターゲット・タイプには対応していません。たとえば、ご使用の環境でWebLogicインスタンスに対してユーザー定義メトリックをデプロイしようとしても、それはホスト・ターゲット・タイプでもデータベース・ターゲット・タイプでもないため、デプロイできません。

メトリック拡張とユーザー定義メトリックの最も重要な違いは、メトリック拡張はユーザー定義メトリックとは異なり、Enterprise Managerに用意されているメトリックと同じ本格的なメトリックであるということです。これらは、Enterprise Manager提供のメトリックと同じく、Enterprise Managerのすべての監視機能で操作および公開できます。また、導入されるすべての新機能に自動的に適用されます。

8.2 メトリック拡張のライフサイクル

メトリック拡張の開発は、プログラミングによるカスタマイズでは常に必要となる次の3つのフェーズで構成されます。

- メトリック拡張の開発

- メトリック拡張のテスト

- メトリック拡張のデプロイおよび公開

メトリック拡張の開発

最初の手順では、監視要件を定義します。ここで、ターゲット・タイプ、収集する必要があるデータ、そのデータを収集するために使用できるメカニズム(アダプタ)、さらに資格証明の昇格が必要かどうかを決定します。これらの決定を行うと、メトリック拡張を開発する準備が整います。Enterprise Managerでは、順を追って作成プロセスを進められる直観的なユーザー・インタフェースが提供されます。

メトリック拡張ウィザードでは、自由に編集できる形式で、メトリック拡張の開発と調整を行うことができます。また、選択したターゲットに対してメトリック拡張を対話的にテストできることが重要です。専用のテスト環境にメトリック拡張をあらかじめデプロイする必要はありません。「テスト」ページで、リアルタイムのメトリック評価を実行して、スクリプトまたはメトリック拡張定義に構文エラーがないことを確認できます。

メトリック拡張の作業が終了したら、「終了」をクリックしてウィザードを終了します。新たに作成されたメトリック拡張が、「メトリック拡張ライブラリ」に表示され、ここで、さらに編集するためにメトリック拡張にアクセスしたり、複数のターゲットに対してテストできるデプロイ可能な下書きとして保存できます。

注意:
メトリック拡張を編集できるのは、ステータスが「編集可能」の場合のみです。メトリック拡張をデプロイ可能な下書きとして一度保存すると、新たに編集を加えるには新しいバージョンを作成する必要があります。

メトリック拡張のテスト

リアルタイム・ターゲット・テストで、予期していたデータがメトリック拡張から返されたら、メトリック拡張をターゲットに対してデプロイし、データ収集を開始することで、Enterprise Managerで堅牢性と実際の動作をテストすることができます。この時点では、メトリック拡張はまだプライベート(開発者のみがターゲットにデプロイ可能)ですが、動作の点ではOracleの即時利用可能なメトリックと同じです。この手順には、ライブラリでの編集可能なメトリック拡張の選択とデプロイ可能ドラフトの生成が含まれます。

ここで、「ターゲットにデプロイ」の操作を進めて、メトリック拡張を実際のターゲットにデプロイできます。ターゲットにデプロイすると、返されるメトリック・データを確認し、アラート通知をテストできます。前に説明したように、デプロイ可能な下書きを作成するとメトリック拡張の編集はできなくなります。新しいバージョンのメトリック拡張を作成する必要があります。

メトリック拡張のデプロイ

複数のメトリック拡張バージョンやターゲット・デプロイメントを使用して綿密にテストした後で、メトリック拡張を本番環境にデプロイできるようになります。この時点まで、メトリック拡張は作成者にしか表示されません。Enterprise Managerのすべての管理者がアクセスできるようにするには、公開する必要があります。「アクション」メニューから、「メトリック拡張の公開」を選択します。

メトリック拡張を公開したら、予定していた本番ターゲットにデプロイすることができます。少数のターゲットを監視している場合は、「ターゲットにデプロイ」メニュー・オプションを選択し、一度に1つずつターゲットを追加します。ターゲット数が多い場合は、監視テンプレートを使用してメトリック拡張をターゲットにデプロイします。メトリック拡張は、正規のメトリックと同じ方法で監視テンプレートに追加します。その後、監視テンプレートをターゲットにデプロイします。

注意:
公開していないメトリック拡張を監視テンプレートに追加することはできません。追加しようとすると、監視テンプレートのページに警告が表示され、そのメトリック拡張を削除しないと操作を続けることができません。

メトリック拡張の更新

Enterprise Managerリリース12.1.0.4以上では、Enterprise Managerの自己更新機能を使用してメトリック拡張を更新できます。詳細は、第21章「Cloud Controlの更新」を参照してください。

8.3 メトリック拡張の使用

ほとんどのメトリック拡張操作は、「メトリック拡張」ホームページで実行できます。公開された拡張の操作をこのUIの外部から実行する必要がある場合、Enterprise MangerによってEM CLI動詞も提供されており、アーカイブ・ファイルに対するメトリック拡張のインポート/エクスポートや従来のユーザー定義メトリックのメトリック拡張への移行などの操作を行うことができます。ここでは、UIの外部で実行するメトリック拡張の操作について説明します。

8.3.1 管理者権限の要件

メトリック拡張の作成、編集、表示、デプロイまたはアンデプロイを行うには、要件となる管理者権限が必要です。Enterprise Manager管理者に必要な権限は次のとおりです。

- メトリック拡張の作成: 次のシステム・レベルのアクセス件:
管理者がメトリック拡張を表示およびデプロイできます。

管理者が拡張を編集および削除できます。

- メトリック拡張の編集: 「メトリック拡張の作成」権限を持つユーザーが、特定のメトリック拡張の次のバージョンを編集および作成できます。メトリック拡張の作成者にはデフォルトでこの権限があります。この権限はメトリック拡張ごとに付与される必要があります。

- 完全なメトリック拡張: 「メトリック拡張の作成」権限を持つユーザーが、特定のメトリック拡張の新しいバージョンを編集および作成できます。

- メトリックの管理: ユーザーがターゲットに対して拡張をデプロイおよびアンデプロイできます。
注意: 「メトリックの管理」権限は、ターゲット単位で付与する必要があります。

8.3.2 「メトリック拡張の作成」権限の付与

「メトリック拡張の作成」権限を他の管理者に付与する手順:

1. 「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。

2. 権限を付与する管理者を選択します。

3. 「編集」をクリックします。

4. 「リソース権限」タブで、メトリック拡張リソース・タイプの「権限付与の管理」をクリックします。

5. 「リソース・タイプ権限」の下の「メトリック拡張の作成」チェック・ボックスを選択します。

6. 「続行」をクリックして変更内容を確認し、「確認」タブの「終了」をクリックします。

8.3.3 管理者権限の管理

別の管理者が作成したメトリック拡張を編集または削除するには、Enterprise Manager管理者に適切なアクセス権が付与されている必要があります。「編集」権限では、次のバージョンの拡張の編集および作成が可能です。「完全」権限では、前述の拡張の操作と削除が可能です。

既存のメトリック拡張に対する「編集」または「完全」アクセス権を、他の管理者に付与するには:

1. 「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。

2. アクセス権を付与する管理者を選択します。

3. 「編集」をクリックします。

4. 「リソース権限」に移動し、メトリック拡張リソース・タイプの「権限付与の管理」(鉛筆アイコン)をクリックします。

5. 「リソース権限」の下で、既存のメトリック拡張を検索して追加できます。権限を付与する対象のメトリック拡張を追加します。これにより、ユーザーがメトリック拡張の次のバージョンを編集および作成できるようになります。
このページで、管理者に「メトリック拡張の作成」権限を付与することもでき、それによりメトリック拡張のアクセスを管理できるようになります。詳細は、「メトリック拡張への管理者アクセスの管理」を参照してください。

6. これに加えて削除操作も必要な場合は、「リソース権限付与の管理」列の鉛筆アイコンをクリックし、表示されるページで「完全なメトリック拡張」権限を選択します。

7. 「続行」をクリックして変更内容を確認し、「確認」タブの「終了」をクリックします。

8.3.4 メトリック拡張への管理者アクセスの管理

一般に、管理者はIT環境内のターゲットの監視と管理の責任を共有します。そのため、メトリック拡張の作成と保守は、複数の管理者が関与する共同作業になります。メトリック拡張の管理者はメトリック拡張UIからアクセスを直接制御できます。

8.3.4.1 メトリック拡張の完全/編集権限の付与

メトリック拡張の所有者またはスーパー管理者は、次のアクションを実行し、メトリック拡張の完全/編集権限を別の管理者に割り当てます。

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 更新が必要なメトリック拡張を選択します。

3. 「アクション」メニューから、「アクセスの管理」を選択します。

4. 「追加」をクリックします。管理者を選択するダイアログ・ボックスが表示されます。管理者、ロール、またはその両方でリストをフィルタできます。

5. リストから1つ以上の管理者/ロールを選択します。

6. 「選択」をクリックします。選択した管理者/ロールがアクセス・リストに表示されます。
「権限」列にはデフォルトで「編集」が設定されています。ドロップダウン・メニューから「完全」を選択し、メトリック拡張の「完全」権限を割り当てます。

「編集」権限: 管理者はメトリック拡張を変更できますが削除はできません。

「完全」権限: 管理者はメトリック拡張を編集および削除もできます。ユーザーまたはロールに付与された権限は、メトリック拡張のすべてのバージョンに適用されます。

7. 「OK」をクリックします。

8.3.4.2 メトリック拡張のアクセス権限の取消し

メトリック拡張の所有者またはスーパー管理者は、次のアクションを実行し、別の管理者に割り当てられたメトリック拡張の権限を取り消します。

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 更新が必要なメトリック拡張を選択します。

3. 「アクション」メニューから、「アクセスの管理」を選択します。

4. リストから1つ以上の管理者/ロールを選択します。

5. 「削除」をクリックします。選択した管理者/ロールがアクセス・リストから削除されます。

6. 「OK」をクリックします。

Enterprise Managerは、メトリック拡張の所有権を、現在の所有者から、「メトリック拡張の作成」権限が付与されている別の管理者に転送することができます。

注意:
Enterprise Managerのスーパー管理者は、すべてのメトリック拡張に対する完全な管理上のアクセス権を持ちます(表示、編集および所有権の転送)。

前述のとおり、「アクセスの管理」は拡張の所有者またはEnterprise Managerのスーパー・ユーザーのみが可能です。所有権が転送されると、前の所有者は、所有権の転送前に明示的に付与されていないかぎり、メトリック拡張でのどんな管理権限もなくなります。「所有者の変更」オプションはユーザーにのみ使用可能で、ロールには使用できません。

「アクセスの管理」により、メトリック拡張の所有者またはスーパー管理者は別のEnterprise Managerユーザーまたはロールに、メトリック拡張の編集、変更、または削除の機能を付与できます。

8.3.4.3 メトリック拡張の所有権の転送

Enterprise Managerは、メトリック拡張の所有権を、現在の所有者から、「メトリック拡張の作成」権限が付与されている別の管理者に転送することができます。

注意:
Enterprise Managerのスーパー管理者は、すべてのメトリック拡張に対する完全な管理上のアクセス権を持ちます(表示、編集および所有権の転送)。

前述のとおり、「アクセスの管理」は拡張の所有者またはEnterprise Managerのスーパー・ユーザーのみが可能です。所有権が転送されると、前の所有者は、所有権の転送前に明示的に付与されていないかぎり、メトリック拡張でのどんな管理権限もなくなります。「所有者の変更」オプションはユーザーにのみ使用可能で、ロールには使用できません。

「アクセスの管理」により、メトリック拡張の所有者またはスーパー管理者は別のEnterprise Managerユーザーまたはロールに、メトリック拡張の編集、変更、または削除の機能を付与できます。

8.3.5 新しいメトリック拡張の作成

新しいメトリック拡張を作成するには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「作成」メニューから、「メトリック拡張」を選択します。メトリック拡張作成の権限があるかどうか確認され、作成プロセスが順を追って指示されます。

3. メトリック拡張名を決めます。名前(および表示名)はターゲット・タイプにおいて一意にする必要があります。

4. 汎用パラメータを入力します。
選択したアダプタ・タイプにより、メトリック拡張ウィザードの次のステップで指定する必要があるプロパティが定義されます。使用可能なアダプタ・タイプは、次のとおりです。

- OSコマンド・アダプタ - 単一列
指定されたOSコマンドを実行し、コマンド出力を単一値として返します。メトリックの結果は、1つの行と1つの列で構成される表です。

- OSコマンド・アダプタ - 複数値
指定されたOSコマンドを実行し、各コマンド出力行を別の値として返します。メトリックの結果は、複数の行と1つの列で構成される表です。

- OSコマンド・アダプタ - 複数列
指定されたOSコマンドを実行し、各コマンド出力行(ユーザー指定の文字列で区切られた)を複数値に解析します。メトリックの結果は、複数の行と複数の列で構成される表です。

- SQLアダプタ
カスタムSQL問合せまたは関数コールを単一インスタンス・データベースおよびReal Application Clusters(RAC)上のインスタンスに対して実行します。

- SNMP(Simple Network Management Protocol)アダプタ
Enterprise Manager管理エージェントは、メトリック・データとして使用されるManagement Information Base(MIB)変数情報をSNMPエージェントに問い合せることができます。

- JMX(Java Management Extensions)アダプタ
JMX対応のサーバーからJMX属性を取得し、これらの属性をメトリック表として返します。

ウィザードの「アダプタ」ページ(ステップ2)で必要となる、選択したアダプタに関する特定の情報は、「アダプタ」を参照してください。

注意:
メトリック拡張のアダプタを変更すると、前のアダプタのすべてのプロパティ(ステップ2)は消去されることに注意してください。

収集スケジュール

収集スケジュール・プロパティを使用して、メトリック・データを収集する頻度およびその使用方法(「アラートのみ」または「アラートおよび履歴の傾向」)を定義しました。

選択したターゲット・タイプに応じて、「拡張」オプションのリージョンが表示されます。このリージョンには、特定のターゲット可用性/アラート条件のもとでメトリック・データの収集を継続するかどうかを決定する1つまたは2つのオプションが(選択したターゲット・タイプに応じて)含まれる場合があります。オプションは次のとおりです。

- オプション1: ターゲットが停止している場合でもメトリック・データの収集を継続します。ホストが停止しているときはメトリック・データを収集できないため、このオプションはホスト・ターゲット・タイプを除くすべてのターゲット・タイプに表示されます。

- オプション2: 特定のターゲット・メトリックに対してアラート重大度が発生したときに、メトリック・データの収集を継続します。このメトリックで重大度が生成されたときに他のターゲット・メトリックに対するメトリック収集が停止されるように、このメトリックは定義されています(このメトリックにAltSkipCondition要素が定義されています)。このオプションのチェックボックスの上の説明テキストは、選択したターゲット・タイプに応じて異なります。
管理エージェントには、接続障害によるメトリック・エラーの生成を抑えるために、停止中であることが認識されているターゲットのメトリックの評価をスキップするロジックがあります。AltSkipCondition要素がそのターゲット・メトリックに対して定義されている場合、レスポンス・メトリックの評価でエラーが発生したときや、レスポンス:ステータス・メトリックにクリアされていない重大度があるときは、他のメトリックがスキップされます。メトリック収集がスキップされる、または発生しない状況が2つあります。

- ターゲットが停止中のとき(オプション1)。これは、レスポンス/ステータス・メトリックの重大度と同じです。

- ターゲットが稼働中であるが他のメトリックに重大度があるとき。このような状況を、Alt Skip (代替スキップ)状況と言います。

オプション2は、ターゲットのメトリックのいずれかにAltSkipConditionが定義されている場合に表示されます。たとえば、選択したターゲット・タイプが「Oracle WebLogicドメイン」の場合、このオプションは表示されませんが、選択したターゲット・タイプが「データベース・インスタンス」の場合は表示されます。

次の図に拡張収集スケジュール・オプションを示します。

5. 「列」ページで、アダプタから返されるデータを定義するメトリック列を追加します。列の順序は、アダプタがデータを返す順序と一致する必要があることに注意してください。

- 列型
列はキー列またはデータ列になります。キー列は表の行を一意に識別します。たとえば、従業員IDは従業員表の一意識別子です。データ列は、行内の一意でないすべてのデータです。たとえば、従業員の姓や名です。既存のデータ列に基づいて率およびデルタ・メトリック列も作成できます。後述の「率およびデルタ・メトリック列」を参照してください。

- 値の型
値の型は「Number」または「String」です。これによって、使用できるアラート比較演算子や、このメトリック列の収集データのEnterprise Managerでのレンダリング方法が決まります。

- アラートしきい値
「比較操作」、「警告」および「クリティカル」フィールドによって、アラートしきい値が定義されます。

- キー別のアラートしきい値
「比較操作」、「キー別の警告のしきい値」および「キー別のクリティカルのしきい値」フィールドを使用すると、表内の行ごとに異なるアラートしきい値を指定できます。このオプションが使用できるのは、キー列が定義されている場合です。たとえば、メトリックがCPU使用率を監視している場合は、CPUごとに違うアラートしきい値を指定できます。構文としては、キー列値のカンマ区切りリスト、=記号、アラートしきい値の順に指定します。異なる行の複数のしきい値は、セミコロン(;)で区切ります。たとえば、CPU使用率のメトリックのキー列値がcpu_idおよびcore_idで、procecessor1およびcore1に50%、processor2およびcore2に60%の警告のしきい値を追加する場合は、「procecessor1,core1=50;processor2,core2=60」と指定します。

- 手動でクリア可能なアラート

注意:
「手動でクリア可能なアラート」オプションを表示するために「拡張」リージョンを展開する必要があります。

このオプションを「true」に設定すると、アラートしきい値を下回ってもアラートが自動的にクリアされません。たとえば、メトリックがシステム・ログ・ファイル内のエラー数をカウントしているときに、アラートしきい値を50に設定すると、しきい値に到達したときにアラートが発生します。エラー件数が50未満になってもアラートは自動的にクリアされません。アラートは、ターゲットのホームページまたはインシデント・マネージャの「アラート」UIで手動でクリアする必要があります。

- アラート前の発生数
アラートしきい値に到達した場合の、アラートが発生する前の連続メトリック収集数。

- アラート・メッセージまたはクリア・メッセージ
アラートが発生またはクリアされたときに送信するメッセージ。使用できる変数は、%columnName%、%keyValue%、%value%、%warning_threshold%、%critical_threshold%です。

該当する列名を「%」で囲んで、別の列の値を取得することもできます。たとえば、cpu_usage列についてアラートを作成している場合、%core_temperature%を使用してcore_temperature列の値を取得できます。警告またはクリティカル・アラートについても同じアラート・メッセージまたはクリア・メッセージが使用されることに注意してください。

注意:
十分に検討して、すべてのキー列を追加してください。新しいバージョンのメトリック拡張では追加のキー列を作成できないためです。一度「デプロイ可能な下書きとして保存」をクリックすると、キー列は最終的に決定されます(列の表示名とアラートしきい値の編集は可能です)。新しいバージョンでも新たなデータ列を追加することはできます。また、既存のデータ列の一部のプロパティも後から変更できません。これには、「列型」、「値の型」、「比較演算子」(新しい演算子は追加できるが、既存の演算子は変更できない)および「手動でクリア可能なアラート」などが含まれます。

- メトリックのカテゴリ
この列が所属するメトリックのカテゴリ。

率およびデルタ・メトリック列

最後のメトリック収集からのデータの変更率または値の差異(デルタ)を測定する、既存のデータ列に基づく追加のメトリック列を作成できます。率/デルタ・メトリック定義は、メトリックの収集頻度が定期的である場合に使用できます。たとえば、10分ごとに収集される場合です。反対に、毎週月曜日および火曜日のみに計算されるメトリックは、データ・サンプリングの頻度が低すぎるため、率/デルタ・メトリックを持つことができません。

少なくとも1つのデータ列を作成すると、次の図に示すように3つの追加オプションが「追加」メニューに表示されます。

- 別のメトリック列に基づいてデルタ・メトリック列を追加します
例: 最後の収集後に使用された表領域の差異を知りたいとします。

デルタ計算:

現在のメトリック値 - 前のメトリック値

- 別のメトリック列に基づいて率(/分)メトリック列を追加します
例: 1時間ごとに収集される表領域列メトリックに基づいて1分ごとの平均表領域使用率を知りたいとします。

率(/分)計算:

現在のメトリック値 - 前のメトリック値/ 収集スケジュール

ここで収集スケジュールは分です。

- 別のメトリック列に基づいて率(/5分)メトリック列を追加します
例: たとえば1時間ごとに収集される表領域列に基づいて5分ごとの平均表領域使用率を知りたいとします。

率(/5分)計算:

[(現在のメトリック値 - 前のメトリック値)/ 収集スケジュール ] * 5

ここで収集スケジュールは分です。

率/デルタ・メトリック列を作成するには、表の既存のデータ列をクリックし、「追加」メニューから率/デルタ列オプションのいずれかを選択します。

6. 「資格証明」ページで、カスタム監視資格証明セットを使用してデフォルトの監視資格証明を上書きできます。デフォルトでは、メトリック拡張ウィザードは、Oracleの即時利用可能なメトリックで使用される既存の資格証明を特定のターゲット・タイプに対して選択します。たとえば、メトリック拡張がデータベース・ターゲットに対してdbsnmpユーザーを使用します。emcli create_credential_setコマンドによってカスタム監視資格証明セットを作成することで、既存の資格証明を上書きできます。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース・ガイド』を参照してください。一部のアダプタでは追加の資格証明が使用されることがあります。詳細は、「アダプタ」を参照してください。

7. 「テスト」ページから、使用可能なテスト・ターゲットを追加します。

8. 「テストの実行」をクリックしてメトリック拡張を検証します。ユーザーが指定したテスト・ターゲットに拡張がデプロイされ、リアルタイム収集が実行されます。その後、メトリック拡張は自動的にアンデプロイされます。結果およびエラー(ある場合)は「テスト結果」リージョンに追加されます。

9. メトリック拡張が予定のデータを返すようになるまで編集とテストを繰り返します。

10. 「終了」をクリックします。

8.3.6 新しいメトリック拡張の作成(類似作成)

既存のメトリック拡張に基づいて新しいメトリック拡張を作成するには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「メトリック拡張」ページで、アクセスできるメトリック拡張を決定します。このページには、メトリック拡張のリストが、ターゲット・タイプ、所有者、本番バージョン、デプロイ情報とともに表示されます。

3. 既存のメトリック拡張を選択します。

4. 「アクション」メニューから、「類似作成」を選択します。メトリック拡張作成の権限があるかどうか確認され、作成プロセスが順を追って指示されます。

5. 必要な変更を行います。

6. テスト・ページから、使用可能なテスト・ターゲットを追加します。

7. 「テストの実行」をクリックしてメトリック拡張を検証します。ユーザーが指定したテスト・ターゲットに拡張がデプロイされ、リアルタイム収集が実行されます。その後、メトリック拡張は自動的にアンデプロイされます。結果およびエラー(ある場合)は「テスト結果」リージョンに追加されます。

8. メトリック拡張が予定のデータを返すようになるまで編集とテストを繰り返します。

9. 「終了」をクリックします。

8.3.7 メトリック拡張の編集

既存のメトリック拡張を編集するには、編集しようとする拡張に対して編集権限が必要です。または、拡張の作成者であることが必要です。注意: メトリック拡張をデプロイ可能な下書きとして保存した後は、編集はできなくなり、新しいバージョンを作成することしかできません。

既存のメトリック拡張を編集するには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「メトリック拡張」ページで、アクセスできるメトリック拡張を決定します。このページには、メトリック拡張のリストが、ターゲット・タイプ、所有者、本番バージョン、デプロイ情報とともに表示されます。

3. 編集するメトリック拡張を選択します。

4. 「アクション」メニューから、「編集」を選択します。

5. 必要に応じてメトリック拡張を更新します。

6. テスト・ページから、使用可能なテスト・ターゲットを追加します。

7. 「テストの実行」をクリックしてメトリック拡張を検証します。ユーザーが指定したテスト・ターゲットに拡張がデプロイされ、リアルタイム収集が実行されます。その後、メトリック拡張は自動的にアンデプロイされます。結果およびエラー(ある場合)は「テスト結果」リージョンに追加されます。

8. メトリック拡張が予定のデータを返すようになるまで編集とテストを繰り返します。

9. 「終了」をクリックします。

8.3.8 既存のメトリック拡張の新バージョンの作成

既存のメトリック拡張の新バージョンを作成するには、新バージョンを作成しようとする拡張に対して編集権限が必要です。または、拡張の作成者であることが必要です。

既存のメトリック拡張の新バージョンを作成するには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. メトリック拡張ページから、使用可能なメトリック拡張を決定します。このページには、メトリック拡張のリストが、ターゲット・タイプ、所有者、本番バージョン、デプロイ情報とともに表示されます。

3. 新バージョンを作成するメトリック拡張を選択します。

4. 「アクション」メニューから、「次のバージョンの作成」を選択します。

5. 必要に応じてメトリック拡張を更新します。ターゲット・タイプと拡張名は編集できませんが、その他すべての一般プロパティは変更できます。メトリック列の変更には制約もあります。詳細は、「新しいメトリック拡張の作成」の「注意」を参照してください。

6. 「テスト」ページから、使用可能なテスト・ターゲットを追加します。

7. 「テストの実行」をクリックしてメトリック拡張を検証します。ユーザーが指定したテスト・ターゲットに拡張がデプロイされ、リアルタイム収集が実行されます。その後、メトリック拡張は自動的にアンデプロイされます。結果およびエラー(ある場合)は「テスト結果」リージョンに追加されます。

8. メトリック拡張が予定のデータを返すようになるまで編集とテストを繰り返します。

9. 「終了」をクリックします。

8.3.9 メトリック拡張のインポート

メトリック拡張は、ポータブルな自己完結型パッケージに変換できるので、メトリック拡張を他のEnterprise Managerインストール環境やストレージ/バックアップに移動することが可能です。このパッケージをメトリック拡張アーカイブ(MEA)ファイルと言います。

MEAはzipファイルで、メトリック拡張を構成するすべてのコンポーネント、すなわちメトリック・メタデータ、コレクション、関連するスクリプト/jarファイルがMEAに含まれています。1つのMEAファイルに含めることができるのは、1つのメトリック拡張のみです。メトリック拡張を元のEnterprise Managerインストール環境に追加するには、MEAからメトリック拡張をインポートする必要があります。

MEAファイルからメトリック拡張をインポートするには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「インポート」をクリックします。

3. ファイルの場所を参照し、MEAファイルを選択します。ターゲット・タイプとメトリック拡張名の組合せがすでにシステムで使用されているかどうかが、Enterprise Managerによってチェックされます。使用されていない場合、新しいメトリック拡張が作成されます。拡張名がすでに使用されている場合は、MEAの内容を使用して、既存の拡張の新バージョンの作成が試行されます。このためには、すべての既存メトリック拡張のメトリック列のスーパーセットがMEAに含まれることが必要です。メトリック拡張の名前を変更することもできます。

4. 「OK」をクリックすると、新しいメトリック拡張または既存のメトリック拡張の新バージョンが作成されます。

5. 「アクション」メニューから「編集」を選択して、エントリを確認します。

6. テスト・ページから、使用可能なテスト・ターゲットを追加します。

7. 「テストの実行」をクリックしてメトリック拡張を検証します。ユーザーが指定したテスト・ターゲットに拡張がデプロイされ、リアルタイム収集が実行されます。その後、メトリック拡張は自動的にアンデプロイされます。結果およびエラー(ある場合)は「テスト結果」リージョンに追加されます。

8. メトリック拡張が予定のデータを返すようになるまで編集とテストを繰り返します。

9. 「終了」をクリックします。

8.3.10 メトリック拡張のエクスポート

既存のメトリック拡張は、自己完結型のzipファイルとしてパッケージし、(エクスポートして)別の環境やバックアップ/ストレージに移動することができます。

既存のメトリック拡張をエクスポートするには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「メトリック拡張」ページで、アクセスできるメトリック拡張を決定します。このページには、メトリック拡張のリストが、ターゲット・タイプ、所有者、本番バージョン、デプロイ情報とともに表示されます。

3. エクスポートするメトリック拡張を選択します。

4. 「アクション」メニューから、「エクスポート」を選択します。作成されるMEAファイルの名前と場所を入力するように求められます。

5. パッケージの名前と場所を選択します。エクスポートが完了すると、確認ページが表示されます。
注意: エクスポートできるのは、本番、デプロイ可能な下書きおよび公開済のメトリック拡張バージョンのみです。

6. エクスポート・ファイルのダウンロードを確認します。

8.3.11 メトリック拡張の削除

メトリック拡張の削除は簡単に開始できます。ただし、実際に削除すると、Enterprise Managerによる処理が連鎖的に発生して、メトリック拡張がシステムから完全にパージされます。これには、オープンしているメトリック・アラートのクローズや、収集されたメトリック・データのパージが含まれます(最新のメトリック拡張バージョンが削除される場合)。

メトリック拡張バージョンを削除するには、すべてのターゲットからアンデプロイし、すべての監視テンプレート(ステータスが適用保留中のテンプレートを含む)から削除しておく必要があります。

メトリック拡張を削除するには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「メトリック拡張」ページで、アクセスできるメトリック拡張を決定します。このページには、メトリック拡張のリストが、ターゲット・タイプ、所有者、本番バージョン、デプロイ情報とともに表示されます。

3. 削除するメトリック拡張を選択します。

4. 「アクション」メニューから、「削除」を選択します。削除してよいかどうか、確認を求められます。

5. 削除を確定します。

8.3.12 ターゲットのグループへのメトリック拡張のデプロイ

メトリック拡張によってデータ収集を開始するには、メトリック拡張をターゲットにデプロイする必要があります。

1つ以上のターゲットにメトリック拡張をデプロイするには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「メトリック拡張」ページで、アクセスできるメトリック拡張を決定します。このページには、メトリック拡張のリストが、ターゲット・タイプ、所有者、本番バージョン、デプロイ情報とともに表示されます。

3. デプロイするメトリック拡張を選択します。

4. 「アクション」メニューから、「ターゲット・デプロイメントの管理」を選択します。ターゲット・デプロイメントの管理ページが開き、選択したメトリック拡張がすでにデプロイされているターゲットが表示されます。

5. 「メトリック拡張」ページに戻ります。

6. メトリック拡張を選択します。

7. 「アクション」メニューから、「ターゲットにデプロイ」を選択します。Enterprise Managerによって、「ターゲット・メトリックの管理」権限があるかどうかが判別され、権限を持つターゲットのみがターゲット・セレクタに表示されます。

8. メトリック拡張をデプロイするターゲットを追加し、「発行」をクリックします。メトリック拡張を各ターゲットにデプロイするジョブが発行されます。1つのデプロイ・リクエストごとに1つのジョブが発行されます。

9. 自動的に「保留中の操作」ページにリダイレクトされます。このページには、メトリック拡張デプロイ操作(現在スケジュール済の操作、実行中の操作、または失敗した操作)のリストが表示されます。デプロイ操作が完了すると、保留中の操作の表からエントリが削除されます。

8.3.13 メトリック拡張から電子メールを送信するためのインシデント・ルールの作成

管理者がEnterprise Managerで実行する最も一般的なタスクの1つに、メトリック・アラート条件が発生したときに電子メール通知を送信することがあります。特に、Enterprise Managerはインシデントとして定義されたアラート条件を監視します。特定のインシデントについて、インシデントが発生したときにどのような処理を行うかをEnterprise Managerに指示するインシデント・ルール・セットを作成します。この場合、メトリック拡張によって定義されたアラート条件で構成されるインシデントが発生すると、管理者に電子メールを送信するインシデント・ルールを作成する必要があります。メトリック・アラートについて電子メールを送信する手順については、「メトリック・アラートの電子メールの送信」を参照してください。

インシデント管理の詳細は、第2章「インシデント管理の使用」を参照してください。

8.3.14 ターゲットのグループにデプロイ済でバージョンの古いメトリック拡張の更新

最新のメトリック拡張バージョンが公開されると、そのメトリック拡張の古いデプロイ済インスタンスもすべて更新する必要が生じます。

ターゲットにデプロイされている古いバージョンの拡張メトリックを更新するには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「メトリック拡張」ページで、アクセスできるメトリック拡張を決定します。このページには、メトリック拡張のリストが、ターゲット・タイプ、所有者、本番バージョン、デプロイ情報とともに表示されます。

3. アップグレードするメトリック拡張を選択します。

4. 「アクション」メニューから、「ターゲット・デプロイメントの管理」を選択します。ターゲット・デプロイメントの管理ページが開き、選択したメトリック拡張がすでにデプロイされているターゲットのリストが表示されます。

5. メトリック拡張を更新するターゲットのリストを選択し、「アップグレード」をクリックします。選択したターゲットに最新の発行済メトリック拡張をデプロイするジョブが発行されます。1つのデプロイ・リクエストごとに1つのジョブが発行されます。

6. 自動的に「保留中の操作」ページにリダイレクトされます。このページには、メトリック拡張デプロイ操作(現在スケジュール済の操作、実行中の操作、または失敗した操作)のリストが表示されます。デプロイ操作が完了すると、保留中の操作の表からエントリが削除されます。

8.3.15 リポジトリ側メトリック拡張の作成

Enterprise Managerリリース12.1.0.4では、リポジトリ側メトリック拡張を作成できます。このタイプのメトリック拡張によって、SQLスクリプトを使用してEnterprise Managerリポジトリから情報を直接抽出し、リポジトリ側の拡張を実行するターゲットに対しアラートを発生させることができます。たとえば、リポジトリ側メトリック拡張を使用すると、ホスト・ターゲットに対しるアラートの数が5を超えたときにアラートを発生させることができます。また、そのホストでのCPU使用率が95%を超え、そのホストで実行しているプロセスの数が500を超えたときにアラートを発生させることもできます。リポジトリ側メトリック拡張によって、Enterprise Managerインフラストラクチャをより柔軟に監視することが可能になります。

リポジトリ側メトリックを作成するには:

1. 「エンタープライズ」メニューから、「監視」、「メトリック拡張」を選択します。

2. 「作成」メニューから、「リポジトリ側メトリック拡張」を選択します。メトリック拡張作成の権限があるかどうか確認され、作成プロセスが順を追って指示されます。

3. ターゲット・タイプとメトリック拡張名を決定します。名前(および表示名)はターゲット・タイプにおいて一意にする必要があります。

4. 汎用パラメータを入力します。
収集スケジュール

収集スケジュール・プロパティを使用して、メトリック・データを収集する頻度およびその使用方法(「アラートのみ」または「アラートおよび履歴の傾向」)を定義しました。

5. Enterprise Managerリポジトリに対して実行するSQL問合せを作成します。「SQL問合せ」ページに、問合せの明示的な開発手順と例が示されています。

「SQLの検証」をクリックして、問合せをテストします。

すでにSQLスクリプトがある場合は、「アップロード」をクリックすると、外部ファイルからSQLをロードできます。

6. 「列」ページから、SQL問合せで返された列を参照/編集できます。列は編集できますが、このページで列を追加または削除することはできません。

- 列型
列はキー列またはデータ列になります。キー列は表の行を一意に識別します。たとえば、従業員IDは従業員表の一意識別子です。データ列は、行内の一意でないすべてのデータです。たとえば、従業員の姓や名です。既存のデータ列に基づいて率およびデルタ・メトリック列も作成できます。後述の「率およびデルタ・メトリック列」を参照してください。

- 値の型
値の型は「Number」または「String」です。これによって、使用できるアラート比較演算子や、このメトリック列の収集データのEnterprise Managerでのレンダリング方法が決まります。

- アラートしきい値
「比較操作」、「警告」および「クリティカル」フィールドによって、アラートしきい値が定義されます。

- キー別のアラートしきい値
「比較操作」、「キー別の警告のしきい値」および「キー別のクリティカルのしきい値」フィールドを使用すると、表内の行ごとに異なるアラートしきい値を指定できます。このオプションが使用できるのは、キー列が定義されている場合です。たとえば、メトリックがCPU使用率を監視している場合は、CPUごとに違うアラートしきい値を指定できます。構文としては、キー列値のカンマ区切りリスト、=記号、アラートしきい値の順に指定します。異なる行の複数のしきい値は、セミコロン(;)で区切ります。たとえば、CPU使用率のメトリックのキー列値がcpu_idおよびcore_idで、procecessor1およびcore1に50%、processor2およびcore2に60%の警告のしきい値を追加する場合は、「procecessor1,core1=50;processor2,core2=60」と指定します。

- 手動でクリア可能なアラート

注意:
「手動でクリア可能なアラート」オプションを表示するために「拡張」リージョンを展開する必要があります。

このオプションを「true」に設定すると、アラートしきい値を下回ってもアラートが自動的にクリアされません。たとえば、メトリックがシステム・ログ・ファイル内のエラー数をカウントしているときに、アラートしきい値を50に設定すると、しきい値に到達したときにアラートが発生します。エラー件数が50未満になってもアラートは自動的にクリアされません。アラートは、ターゲットのホームページまたはインシデント・マネージャの「アラート」UIで手動でクリアする必要があります。

- アラート前の発生数
アラートしきい値に到達した場合の、アラートが発生する前の連続メトリック収集数。

- アラート・メッセージまたはクリア・メッセージ
アラートが発生またはクリアされたときに送信するメッセージ。使用できる変数は、%columnName%、%keyValue%、%value%、%warning_threshold%、%critical_threshold%です。

該当する列名を「%」で囲んで、別の列の値を取得することもできます。たとえば、cpu_usage列についてアラートを作成している場合、%core_temperature%を使用してcore_temperature列の値を取得できます。警告またはクリティカル・アラートについても同じアラート・メッセージまたはクリア・メッセージが使用されることに注意してください。

注意:
十分に検討して、すべてのキー列を追加してください。新しいバージョンのメトリック拡張では追加のキー列を作成できないためです。一度「デプロイ可能な下書きとして保存」をクリックすると、キー列は最終的に決定されます(列の表示名とアラートしきい値の編集は可能です)。新しいバージョンでも新たなデータ列を追加することはできます。また、既存のデータ列の一部のプロパティも後から変更できません。これには、「列型」、「値の型」、「比較演算子」(新しい演算子は追加できるが、既存の演算子は変更できない)および「手動でクリア可能なアラート」などが含まれます。

- メトリックのカテゴリ
この列が所属するメトリックのカテゴリ。

- 別のメトリック列に基づいてデルタ・メトリック列を追加します
例: 最後の収集後に使用された表領域の差異を知りたいとします。

デルタ計算:

現在のメトリック値 - 前のメトリック値

- 別のメトリック列に基づいて率(/分)メトリック列を追加します
例: 1時間ごとに収集される表領域列メトリックに基づいて1分ごとの平均表領域使用率を知りたいとします。

率(/分)計算:

現在のメトリック値 - 前のメトリック値/ 収集スケジュール

ここで収集スケジュールは分です。

- 別のメトリック列に基づいて率(/5分)メトリック列を追加します
例: たとえば1時間ごとに収集される表領域列に基づいて5分ごとの平均表領域使用率を知りたいとします。

率(/5分)計算:

[(現在のメトリック値 - 前のメトリック値)/ 収集スケジュール ] * 5

ここで収集スケジュールは分です。

率/デルタ・メトリック列を作成するには、表の既存のデータ列をクリックし、「追加」メニューから率/デルタ列オプションのいずれかを選択します。

7. 「テスト」ページから、使用可能なテスト・ターゲットを追加します。

8. 「テストの実行」をクリックしてメトリック拡張を検証します。ユーザーが指定したテスト・ターゲットに拡張がデプロイされ、リアルタイム収集が実行されます。その後、メトリック拡張は自動的にアンデプロイされます。結果およびエラー(ある場合)は「テスト結果」リージョンに追加されます。

9. メトリック拡張が予定のデータを返すようになるまで編集とテストを繰り返します。

10. 「終了」をクリックします。

8.4 アダプタ

Oracle Integration Adaptersには、包括的で使いやすい各種ターゲット・タイプとの監視接続性を備えています。このアダプタは、エンタープライズ・アプリケーションとの通信を可能にし、アプリケーション・データを標準に準拠したXMLに翻訳(またはこの逆)できます。

メトリック拡張のターゲット・タイプに応じて、UIで使用できるアダプタが決まります。たとえば、自動ストレージ管理ターゲット・タイプ用のメトリック拡張を作成する場合、3つのアダプタ(「OSコマンド - 単一列」、「OSコマンド - 複数列」および「SQL」)のみをUIから使用できます。

ターゲット・タイプの即時利用可能なメトリック定義は、ネイティブ・サポート対象のアダプタを定義し、そのようなアダプタのみがUIに表示されます。他のアダプタはそのターゲット・タイプでサポートされません。

すべてのアダプタのリストを次に示します。

- OSコマンド・アダプタ - 単一列

- OSコマンド・アダプタ - 複数値

- OSコマンド・アダプタ - 複数列

- SQLアダプタ

- SNMP(Simple Network Management Protocol)アダプタ

- JMXアダプタ

8.4.1 OSコマンド・アダプタ - 単一列

指定されたOSコマンドを実行し、コマンド出力を単一値として返します。メトリックの結果は、1つの行と1つの列で構成される表です。

基本プロパティ

完全なコマンドラインはコマンド + スクリプト + 引数として構成されます。

- コマンド - 実行するコマンド。たとえば、%perlBin%/perlなどです。完全なコマンドラインはコマンド + スクリプト + 引数として構成されます。

- スクリプト - コマンドに渡すスクリプト。たとえば、%scriptsDir%/myscript.plなどです。カスタム・ファイルをエージェントにアップロードでき、%scriptsDir%ディレクトリでアクセスできます。

- 引数 - コマンドに付加する追加の引数。

拡張プロパティ

- 入力プロパティ - 追加プロパティは、標準入力ストリームを介してコマンドに渡すことができます。これは通常は、他のユーザーに見られないようにするセキュア・コンテンツ(ユーザー名やパスワードなど)で使用されます。たとえば、次の入力プロパティを追加できます。
Name=targetName, Value=%NAME%

これは、コマンドが標準入力ストリームを介して"STDINtargetName=<target name>"として読み取ることができます。

- 環境変数 - 拡張プロパティは、コマンドで環境変数を介して使用できます。たとえば、Name=targetType, Value="%TYPE%"のような環境変数を追加できます。コマンドは、環境変数ENVtargetTypeを使用してターゲット・タイプにアクセスできます。

資格証明

- ホスト資格証明 - OSコマンドの起動に使用される資格証明。

- 資格証明の入力 - OSコマンドの標準入力ストリームに渡される追加の資格証明。

例1

ログ・ファイルの内容を読み取り、ターゲットへの参照を含むすべての行をダンプ出力します。

- アプローチ1 - grepコマンドを使用し、%NAME%パラメータを使用してターゲット名を指定します。
Command = /bin/grep %NAME% mytrace.log

- アプローチ2 - perlスクリプトを実行します。
Command = %perlBin%/perl

Script = %scriptsDir%/filterLog.pl

入力プロパティ

targetName = %NAME%

targetType = %TYPE%

filterLog.pl:

require "emd_common.pl";

my %stdinVars = get_stdinvars();
my $targetName = $stdinVars{"targetName"};
my $targetType = $stdinVars{"targetType"};
open (MYTRACE, mytrace.log);
foreach $line (<MYTRACE >)
{
# Do line-by-line processing
}

close (MYTRACE);

例2

Perlスクリプトからデータベース・インスタンスに接続し、HR.JOBSサンプル・スキーマ表を問い合せます。

- アプローチ1 - 入力プロパティを使用してターゲット・タイプ・プロパティから資格証明を渡します。
Command = %perlBin%/perl

Script = %scriptsDir%/connectDB.pl

入力プロパティ

EM_DB_USERNAME = %Username%

EM_DB_PASSWORD = %Password%

EM_DB_MACHINE = %MachineName%

EM_DB_PORT = %Port%

EM_DB_SID = %SID%

connectDB.pl

use DBI;
require "emd_common.pl";

my %stdinVars = get_stdinvars();
my $dbUsername = $stdinVars{"EM_DB_USERNAME"};
my $dbPassword = $stdinVars{"EM_DB_PASSWORD"};
my $dbMachine = $stdinVars{"EM_DB_MACHINE"};
my $dbPort = $stdinVars{"EM_DB_PORT"};
my $dbSID = $stdinVars{"EM_DB_SID"};

my $dbAddress = "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=$dbMachine)(Port=$dbPort))(CONNECT_DATA=(SID=$dbSID)))";

# Establish Target DB Connection
my $db = DBI->connect('dbi:Oracle:', "$dbUsername@".$dbAddress, "$dbPassword",
{PrintError => 0, RaiseError => 0, AutoCommit => 0})
or die (filterOraError("em_error=Could not connect to $dbUsername/$dbAddress: $DBI::errstr\n", $DBI::err));

my $query = "SELECT JOB_TITLE, MIN_SALARY FROM HR.JOBS";
my $st = $db->prepare($query);
$st->execute();

while ( my ($job_title, $min_sal) = $st->fetchrow_array() )
{
print "$job_title|$min_sal\n";
}

$db->disconnect
or warn "disconnect $DBI::errstr\n";

exit 0;

- アプローチ2 - 入力資格証明を使用して監視資格証明セットを渡します。
Command = %perlBin%/perl

Script = %scriptsDir%/connectDB.pl

入力資格証明:

dbCreds = MyCustomDBCreds

connectDB.pl

use DBI;

require "emd_common.pl";

my %stdinVars = get_stdinvars();
my $credType = getCredType("dbCred", \%stdinVars);
my %credProps = getCredProps("dbCreds", \%stdinVars);
my $dbUsername = $credProps{"DBUserName"};
my $dbPassword = $credProps{"DBPassword"};

例3

ホスト・ターゲットのカスタム監視資格証明セットを作成して使用し、監視資格証明をオーバーライドします。

ホスト・ターゲット・タイプのホスト資格証明の作成:

> emcli create_credential_set -set_name=myCustomCreds -target_type=host -auth_target_type=host -supported_cred_types=HostCreds -monitoring -description='My Custom Credentials'

メトリック拡張ウィザードの「資格証明」ページに移動し、ホスト資格証明の「資格証明セットの指定」を選択すると、ドロップ・ダウン・リストのオプションとしてカスタム資格証明が表示されます。

このステップでは、ホスト・ターゲット・タイプの監視資格証明セットが作成されるのみです。このメトリック拡張のデプロイ先の各ターゲットで資格証明を設定する必要があります。Enterprise Managerで、「設定」、「セキュリティ」、「監視資格証明」の順に選択して、資格証明を設定できます。または、コマンドラインから設定することもできます。

> emcli set_monitoring_credential -target_name=target1 -target_type=host -set_name=myCustomCreds -cred_type=HostCreds -auth_target_type=host -attributes='HostUserName:myusername;HostPassword:mypassword'

8.4.2 OSコマンド・アダプタ - 複数値

指定されたOSコマンドを実行し、各コマンド出力行を別の値として返します。メトリックの結果は、複数の行と1つの列で構成される表です。

たとえば、コマンド出力が次のようだとします。

em_result=out_x
em_result=out_y

この場合、3つの列にそれぞれ値1、2、3が移入されます。

基本プロパティ

- コマンド - 実行するコマンド。たとえば、%perlBin%/perlなどです。

- スクリプト - コマンドに渡すスクリプト。たとえば、%scriptsDir%/myscript.plなどです。カスタム・ファイルをエージェントにアップロードでき、%scriptsDir%ディレクトリでアクセスできます。

- 引数 - コマンドに付加する追加の引数。

- Starts With - メトリックの結果行の開始文字列。
例: コマンド出力が次のような場合:

em_result=4354
update
test

設定Starts With = em_resultは、em_resultで開始する行のみ解析されることを指定します。

拡張プロパティ

- 入力プロパティ - 追加プロパティは、標準入力ストリームを介してコマンドに渡すことができます。たとえば、Name=targetName, Value=%NAME%のような入力プロパティを追加できます。コマンドは、標準入力ストリームを介してこれをSTDINtargetName=<target name>と読み取ることができます。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

- 環境変数 - 拡張プロパティは、コマンドで環境変数を介して使用できます。たとえば、Name=targetType, Value="%TYPE%"のような環境変数を追加できます。コマンドは、環境変数ENVtargetTypeを使用してターゲット・タイプにアクセスできます。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

資格証明

- ホスト資格証明 - OSコマンドの起動に使用される資格証明。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

- 資格証明の入力 - OSコマンドの標準入力ストリームに渡される追加の資格証明。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

8.4.3 OSコマンド・アダプタ - 複数列

指定されたOSコマンドを実行し、各コマンド出力行(ユーザー指定の文字列で区切られた)を複数値に解析します。メトリックの結果は、複数の行と複数の列で構成される表です。

例: コマンド出力が次のような場合

em_result=1|2|3
em_result=4|5|6

デリミタが「|」に設定されていると、次のようにそれぞれが3つの列を含む2つの行になります。

1

2

3

4

5

6

基本プロパティ

完全なコマンドラインはコマンド + スクリプト + 引数として構成されます。

- コマンド - 実行するコマンド。たとえば、%perlBin%/perlなどです。

- スクリプト - コマンドに渡すスクリプト。たとえば、%scriptsDir%/myscript.plなどです。カスタム・ファイルをエージェントにアップロードでき、%scriptsDir%ディレクトリでアクセスできます。

- 引数 - 追加の引数。

- デリミタ - コマンド出力を区切るために使用する文字列。

- Starts With - メトリックの結果行の開始文字列。
例: コマンド出力が次のような場合

em_result=4354  out_x  out_y

設定Starts With = em_resultは、em_resultで開始する行のみ解析されることを指定します。

- 入力プロパティ - 追加プロパティは、標準入力ストリームを介してコマンドに渡すことができます。たとえば、Name=targetName, Value=%NAME%のような入力プロパティを追加できます。コマンドは、標準入力ストリームを介してこれをSTDINtargetName=<target name>と読み取ることができます。複数の入力プロパティを指定するには、各プロパティを1行ずつ入力します。

- 環境変数 - 拡張プロパティは、コマンドで環境変数を介して使用できます。たとえば、Name=targetType, Value="%TYPE%のような環境変数を追加できます。コマンドは、環境変数ENVtargetTypeを使用してターゲット・タイプにアクセスできます。

拡張プロパティ

- 入力プロパティ - 追加プロパティは、標準入力ストリームを介してコマンドに渡すことができます。たとえば、Name=targetName, Value=%NAME%のような入力プロパティを追加できます。コマンドは、標準入力ストリームを介してこれをSTDINtargetName=<target name>と読み取ることができます。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

- 環境変数 - 拡張プロパティは、コマンドで環境変数を介して使用できます。たとえば、Name=targetType, Value="%TYPE%のような環境変数を追加できます。コマンドは、環境変数ENVtargetTypeを使用してターゲット・タイプにアクセスできます。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

資格証明

- ホスト資格証明 - OSコマンドの起動に使用される資格証明。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

- 資格証明の入力 - OSコマンドの標準入力ストリームに渡される追加の資格証明。「OSコマンド・アダプタ - 単一列」の使用例を参照してください。

8.4.4 SQLアダプタ

サポートされているカスタムSQL問合せまたは関数コールを単一インスタンス・データベースおよびReal Application Clusters(RAC)上のインスタンスに対して実行します。

プロパティ

- SQL問合せ - 実行するSQL問合せ。通常のSQL文はセミコロンで終了しないでください。たとえば、SQL問合せ = "select a.ename, (select count(*) from emp p where p.mgr=a.empno) directs from emp a"のようにします。PL/SQL文もサポートされており、使用する場合は「アウト・パラメータの位置」および「アウト・パラメータ・タイプ」プロパティを移入する必要があります。

- SQL問合せファイル - SQL問合せファイル。「SQL問合せ」またはSQL問合せファイルの一方のみ使用する必要があります。たとえば、%scriptsDir%/myquery.sqlなどです。カスタム・ファイルをエージェントにアップロードでき、%scriptsDir%ディレクトリでアクセスできます。

- 結果の置換 - SQL問合せ結果を置換します。

- バインド変数 - 通常のSQL文で使用されるバインド変数をここで宣言します。たとえば、SQL問合せ = "select a.ename from emp a where a.mgr = :1"の場合は、バインド変数をName=1, Value=Bobとして宣言できます。

- アウト・パラメータの位置: PL/SQL出力で使用されるバインド変数。整数値のみを指定できます。
例: SQL問合せが次のような場合

DECLARE         l_output1 NUMBER;         l_output2 NUMBER;     BEGIN         .....         OPEN :1 FOR             SELECT l_output1, l_output2 FROM dual;     END;

アウト・パラメータの位置 = 1、アウト・パラメータ・タイプ = SQL_CURSORを設定できます。

- アウト・パラメータ・タイプ - PL/SQL出力パラメータのSQLタイプ。「アウト・パラメータの位置」のコメントを参照してください。

資格証明

- データベース資格証明 - データベースの接続に使用される資格証明。

例

データベース・ターゲットのカスタム監視資格証明セットを作成して使用し、監視資格証明をオーバーライドします。

データベース・ターゲット・タイプのホスト資格証明の作成:

> emcli create_credential_set -set_name=myCustomDBCreds -target_type=oracle_database -auth_target_type=oracle_database -supported_cred_types=DBCreds -monitoring -description='My Custom DB Credentials'

メトリック拡張ウィザードの「資格証明」ページに移動し、データベース資格証明の「資格証明セットの指定」を選択すると、ドロップ・ダウン・リストのオプションとしてカスタムDB資格証明が表示されます。

このステップでは、ホスト・ターゲット・タイプの監視資格証明セットが作成されるのみです。このメトリック拡張のデプロイ先の各ターゲットで資格証明を設定する必要があります。Enterprise Managerで、「設定」、「セキュリティ」、「監視資格証明」の順に選択して、資格証明を設定できます。また、Enterprise Managerコマンドライン・インタフェースを使用して実行することもできます。

> emcli set_monitoring_credential -target_name=db1 -target_type=oracle_database -set_name=myCustomDBCreds -cred_type=DBCreds -auth_target_type=oracle_database -attributes='DBUserName:myusername;DBPassword:mypassword'

8.4.5 SNMP(Simple Network Management Protocol)アダプタ

Enterprise Manager管理エージェントは、メトリック・データとして使用されるManagement Information Base(MIB)変数情報をSNMPエージェントに問い合せることができます。

基本プロパティ

- オブジェクト識別子(OID): オブジェクト識別子は、MIB階層内の管理対象オブジェクトを一意に識別します。1つ以上のOIDを指定できます。SNMPアダプタは、指定されたOIDのデータを収集します。たとえば、1.3.6.1.4.1.111.4.1.7.1.1と入力します。

拡張プロパティ

- デリミタ - OIDの属性に対して複数のOIDを指定する場合に使用するデリミタ値。デフォルト値はスペース、\nまたは\tです。

- 表データ - メトリックに対して予期される結果に複数の行があるかどうかを指定します。使用できる値は、TRUEまたはFALSEです。デフォルト値はFALSEです。

- V2タイプを含む - 指定したOIDのいずれかがSNMPV2データ・タイプかどうかを示します。使用できる値は、TRUEまたはFALSEです。デフォルト値は、FALSEです。たとえば、指定するOID値がcounter64型の場合、この属性をTRUEに設定します。

8.4.6 JMXアダプタ

JMX対応のサーバーからJMX属性を取得し、これらの属性をメトリック表として返します。

プロパティ

- Metric -- 属性を問い合せるMBean ObjectNameまたはObjectNameパターン。これはメトリック・メタデータとして指定されるため、インスタンス不可知である必要があります。MBean ObjectNameのインスタンス固有のキー・プロパティ(servernameなど)はワイルドカードで置換することが必要な場合があります。

- ColumnOrder -- メトリック内に存在する必要のある順序で並べられたJMX属性のセミコロン区切りリストです。

拡張プロパティ

- iIdentityCol -- JMX属性として使用可能でない場合に列として公開する必要のあるMBeanキー・プロパティ。次に例を示します。

com.myCompany:Name=myName,Dept=deptName, prop1=prop1Val, prop2=prop2Val

この例では、identityColをName;Deptとして設定すると、columnOrderプロパティで指定したJMX属性を表す列の横にNameとDeptを表す2つの追加のキー列が生成されます。

- AutoRowPrefix -- 自動生成された行に使用する接頭辞。メトリック・プロパティで指定されたMBean ObjectNameパターンが複数のMBeanに一致し、columnOrderで指定されたJMX属性のいずれもそれぞれ一意でない場合は、行が自動的に生成されます。ここで指定したautoRowIdは、作成される追加のキー列の接頭辞として使用されます。たとえば、メトリックが次のように定義されているとします。

com.myCompany:Type=CustomerOrder,* columnOrder

これは、次と同じです。

CustomerName;OrderNumber;DateShipped

また、注文が2つに分けて出荷される場合にCustomerName;OrderNumber;Amountが一意でない可能性があると想定した場合、autoRowIdを"ShipItem-"と設定すると、各行のメトリックの追加のキー列にShipItem-0、ShipItem-1、ShipItem-2...ShipItem-nが移入されます。

- メトリック・サービス -- 「True」または「False」。MetricServiceがターゲットのWeblogicドメインで有効になっているかどうかを示します。Oracle DMS MBeanを介して公開されるメトリックを収集する必要がある場合を除き、このプロパティは、メトリック拡張に対してほとんどの場合にfalse(選択解除)になります。MetricServiceがtrueに設定されている場合、基本プロパティmetricはMetricService表の名前になり、基本プロパティcolumnOrderはMetricService表の列名のセミコロン区切りリストになります。

注意:
JMXベースのメトリック拡張の作成例の詳細は、『Oracle® Enterprise Manager拡張性プログラマーズ・リファレンス』の「WebサービスおよびJMXを使用した監視」を参照してください。

8.5 メトリック拡張へのユーザー定義メトリックの変換

Enterprise Manager 12c以上のエージェントによってモニタリングされるターゲットでは、以前のユーザー定義メトリックおよびメトリック拡張がサポートされます。リリース12cよりも後では、メトリック拡張しかサポートされません。既存のユーザー定義メトリックがある場合、できるだけ早くメトリック拡張に移行して、管理環境内で監視の中断が起こらないようにすることをお薦めします。

ユーザー定義のメトリック定義のメトリック拡張への移行は自動的には行われないので、管理者が開始する必要があります。移行プロセスでは、ユーザー定義メトリック・メタデータをメトリック拡張メタデータに移行します。

注意:
収集したユーザー定義メトリック履歴データの移行はサポートされません。

ユーザー定義メトリックをメトリック拡張に移行して、メトリック拡張をターゲットに正常にデプロイしたら、ユーザー定義メトリックを無効にするか削除する必要があります。ユーザー定義メトリックの収集を無効にすると、メタデータ(ユーザー定義メトリックの定義)は残りますが、オープンしているすべてのアラートがクリアされ、メトリック・エラーが削除され、ユーザー定義メトリックはそれ以上収集されません。ユーザー定義メトリックを削除すると、メタデータと履歴データが削除され、オープン・アラートがクリアされ、メトリック・エラーが削除されます。

8.5.1 概要

ユーザー定義メトリック(UDM)からメトリック拡張(ME)への移行によって、既存のUDMが新規または既存のMEによって置き換えられます。移行プロセスの概念は、様々なターゲットに対して作成された同じ定義のUDMを1つのMEに統合することです。また、MEは複数のメトリック列をサポートするため、複数の関連するUDMを組み合せて1つのMEにすることが可能です。

この移行プロセスは次のステップで構成されています。

1. 移行する必要があるUDMを識別します。

2. 提供されているEM CLIコマンドを使用して、互換性のあるメトリック拡張を作成または選択します。

3. メトリック拡張をテストして公開します。

4. メトリック拡張を、元のUDMが含まれていたすべてのターゲットとテンプレートにデプロイします。既存の通知ルールもMEを参照するように更新します。

5. 元のUDMを削除します。古いUDMの履歴データとアラートにはUIから引き続きアクセスできますが、新しいMEはそれらを継承しないことに注意してください。

UDMが使用していた資格証明は、新たに作成されるMEには移行されないことに注意してください。ユーザー・インタフェースで、メトリック拡張で必要な資格証明セットを指定できます。MEがデフォルトの監視資格証明を使用しない場合は、関連するEM CLIコマンドを使用して、必要な資格証明を用意するために新しい資格証明セットを作成する必要があります。このセットは、メトリック拡張ウィザードの「資格証明」ページで使用できるようになります。

移行プロセスは、いくつかの移行セッションに分類されます。各セッションが1つ以上のUDMの移行を実行します。個々のセッションを移行するプロセスはタスクと呼ばれます。つまり、1つのセッションは1つ以上のタスクで構成されます。言い換えると、移行では1つのセッションを作成し、そのセッションの各タスクを完了するために必要な入力を提供します。ワークフローを通して、セッションとタスクのステータスを確認できます。

8.5.2 コマンド

このプロセスの様々な手順を完了するために多くのEM CLIコマンドが使用されます。コマンド定義の詳細を確認するには、EM CLI help <コマンド>オプションを使用してください。

- list_unconverted_udms - まだ移行前でセッションにも含まれないUDMのリストを表示します。

- create_udmmig_session - 1つまたは複数のUDMを移行するセッションを作成します。

- udmmig_summary - 進行中の移行セッションをリスト表示します。

- udmmig_session_details - 特定のセッションの詳細を表示します。

- udmmig_submit_metricpics - 新しいMEの作成または既存MEの使用のために、UDMとMEのマッピングを提供します。

- udmmig_retry_deploys - UDMが存在しているターゲットにMEをデプロイします。このコマンドが正常に実行するためには、MEをデプロイ可能な下書きにしておくか公開しておく必要があります。

- udmmig_request_udmdelete - UDMを削除し、移行プロセスを終了します。

使用例

次の問題を使用して、移行を説明するための単純なユースケースを示します。

1つのホスト(host1)を含むシステムがあり、ホストに対して1つのホストUDM(hostudm1)があるとします。目的は、このUDMに相当する新しいME(me1)を作成することです。コマンドのシーケンスは次のとおりです。

$ emcli list_unconverted_udms

-------------+----------------------+-----------+--------------------
Type         | Name                       | Metric    | UDM
-------------+----------------------+-----------+--------------------
host         | host1                             |UDM        | hostudm1

このコマンドは、この段階で、移行されていないUDMまたは移行プロセス中のUDMが1つのみあることを示します。次は、セッションの作成に進みます。

$ emcli create_udmmig_session -name=migration1 -desc="Convert UDMs for host target" -udm_choice=hostudm1 -target=host:host1

Migration session created - session id is 1

このコマンドによって、名前が「migration1」、説明が「convert UDMs for host target」の移行セッションが作成されます。udm_choiceフラグには、選択されているUDMを指定します。targetフラグには、ターゲット・タイプと、UDMが存在するターゲットを指定します。移行セッションはセッションIDで識別されます。現在のセッションのIDは1です。

$ emcli udmmig_summary

------+--------------+------------------+------+------+--------+------+--------
ID    | Name         | Description      |#Tgts |Todo  |#Tmpls  |Todo  |IncRules
------+--------------+------------------+------+------+--------+------+--------
1     |migration1    |Convert UDMS      |      | 1/1  |  0     | -/0  | -/0
------+--------------+------------------+------+------+--------+------+--------

このコマンドでは、現在進行中のすべての移行セッションのサマリーが表示されます。「Name」フィールドと「Description」フィールドでセッションが特定されます。その他の列には、メトリック拡張に変換されているUDMへの参照を含むターゲット、テンプレートおよびインシデント・ルールの数が示されます。「Todo」列には、まだアップグレードされていないUDMへの参照を含むターゲット、テンプレートおよびインシデント・ルールの数が示されます。移行セッションは時間をかけて進めることがあるため、このコマンドを使用して、セッションで完了した部分の概要を確認します。

$ emcli list_unconverted_udms

There are no unconverted udms

このUDMは移行セッションに含まれているため、未変換のUDMのリストにはもう表示されません。

$ emcli udmmig_session_details -session_id=1

Name: migration1
Desc: Convert UDMs for host target
Created: <date> <time>
UDM Pick: [hostudm1]
UDMs being converted:
----------+----------+---------+------+------------+---------+---------+-----
Type      |Name      |UDM      |#MC   |Metric      |Column   |DepS     |DelS
----------+----------+---------+------+------------+---------+---------+-----
host      |host1     |hostudm1 |  0   |            |         |WAIT     |WAIT
----------+----------+---------+------+------------+---------+---------+-----

このコマンドでは、1つの移行セッションのステータスが示されます。UDMの名前、UDMが存在するターゲットのタイプと名前がリストされます。さらに、UDMと一致するEMインスタンスに現在含まれるメトリック拡張も示されます。ユーザーは、既存の選択肢から1つを使用するか、まったく新しいメトリック拡張を作成するかを選択できます。

UDMのプロパティを照合して、互換性のあるメトリック拡張が検索されます。たとえば、ホストUDMの場合は、コマンド、スクリプトおよび引数のフィールドが同じメトリック拡張が検索されます。データベースUDMの場合は、一致するSQL問合せが検索されます。

また、「DepS」列は、UDMと一致したメトリック拡張が、そのUDMが定義されているターゲットにデプロイされたかどうかを示します。「DelS」列は、メトリック拡張がデプロイされた後でUDMが削除されたかどうかを示します。ユーザーが移行を進めるにつれて、この表は左から右に更新されます。削除ステータスの列が「complete」に設定されると、移行セッションは終了です。

$ emcli udmmig_submit_metricpicks -session_id=1 -input_file=metric_picks:filename

Successfully submitted metric picks for migration session

このコマンドは、UDMを置き換えるために、既存のメトリック拡張の使用または新規のメトリック拡張の作成をEnterprise Managerインスタンスに指示します。様々なオプションがファイル(コマンドに含まれるfilename)で提供されます。このファイルの内容を次に示します。

"host,host1,hostudm1,N,ME$me1,Usage"

ファイルの各行がUDMとMEのマッピングを表します。この行には、ターゲット・タイプ、ターゲット名、UDM名、メトリック拡張が新規(N)か既存(E)かを示すフラグ、メトリック拡張名(接頭辞ME$を付ける必要があります)、および列名が含まれます。

サポートされるUDMのタイプは次のとおりです。

- ホスト(host)

- データベース(oracle_database)

- RAC(rac_database)

ユーザーは、ファイルの収集項目の部分にデータ列の名前のみを指定できます。移行によって作成されるメトリック拡張には、UDMの構造を表す2つの列が必ず含まれます。1列のUDMの場合、1つ目の列は索引列で、もう1つの列はこのファイルに示された列名を使用します。2列のUDMの場合、MEの最初の列はキー列になり、2つ目の列では収集名が使用されます。

この段階でメトリック拡張は作成されており、メトリック拡張ライブラリに表示されます。

$ emcli udmmig_session_details -session_id=1

Name: migration1
Desc: Convert UDMs for host target
Created: <date> <time>
UDM Pick: [hostudm1]
Udms being converted:
----------+--------+---------+------+----------+------------+---------+-----
Type      |Name    |UDM      |#MC   |Metric    |Column      |DepS     |DelS
----------+--------+---------+------+----------+------------+---------+-----
host      |host1   |hostudm1 |   1  | ME$me1   | Usage      |WAIT     |WAIT
----------+--------+---------+------+----------+------------+---------+-----

#MC : There are 1 matches for udms in this session.
Use emcli udmmig_list_matches to list available matches

セッション詳細のコマンドによって、このUDMに相当するメトリック拡張が1つあること(MC列の値が1)と、メトリック拡張の名前がME$me1であることが示されます。この段階では、ライブラリのページでメトリック拡張をテストできます。テストが完了して、作成されたメトリック拡張に問題がなければ、デプロイすることができます。デプロイするためには、少なくとも、メトリック拡張をデプロイ可能な下書きとして保存する必要があります。

$ emcli udmmig_retry_deploys -session_id=1 -input_file=metric_tasks:filename2

Metric Deployments successfully submitted

メトリック拡張が公開されると、システムによってジョブがトリガーされ、UDMが存在していたすべてのターゲットにメトリック拡張が自動的にデプロイされます。この処理を手動で制御する必要がある場合には、前述のコマンドを使用すると必要なステップが実行されます。このコマンドは、ターゲット・マッピングに対するUDMを含むファイルが提供される点で、submit_metricpicksオプションに似ています。これは上のfilename2で参照されます。ファイルの内容は次のとおりです。

"host,host1,hostudm1"

ファイルの各行は、UDMと、UDMが存在するターゲット・タイプとターゲットのマッピングを示します。このコマンドが実行されると、メトリック拡張を様々なターゲットにデプロイするジョブが起動されます。ジョブはユーザー・インタフェースで追跡できます。

$ emcli udmmig_request_udmdelete -session_id=1 -input_file=metric_tasks:demo_tasks

Udm deletes successfully submitted

最後のコマンドでは、メトリック拡張に移行したUDMが削除されます。このコマンドは、コマンドの実行時に完了していたデプロイメントの数に応じて、部分的に終了することがあります。

$ emcli udmmig_session_details -session_id=1

Name: migration1
Desc: Convert UDMs for host target
Created: <date > <time>
Completed: <date > <time>
UDM Pick: [hostudm1]
Udms being converted:
--------+----------+---------+------+------------+------------+---------+-----
Type    |Name      |UDM      |#MC   |Metric      |Column      |DepS     |DelS
--------+----------+---------+------+------  ----+------------+---------+-----
host    |host1     |hostudm1 |  1   | ME$me1     | Usage      |COMP   |COMP
--------+----------+---------+------+------------+------------+---------+-----

#MC : There are 1 matches for udms in this session.
Use emcli udmmig_list_matches to list available matches

セッション詳細のコマンドによって、移行プロセスが実際に完了したことが示されます。

8.6 メトリック拡張のコマンドライン動詞

メトリック拡張は、UIの外部からEnterprise Managerコマンドライン・インタフェース(EM CLI)を使用して操作できます。動詞には次の2つのカテゴリがあります。

- メトリック拡張のための動詞

- export_metric_extension: メトリック拡張をアーカイブ・ファイルにエクスポートします。

- get_unused_metric_extensions: 使用されていないメトリック拡張のリストを取得します。

- import_metric_extension: メトリック拡張アーカイブ・ファイルをインポートします。

- publish_metric_extension: すべての管理者が使用できるようにメトリック拡張を公開します。

- save_metric_extension_draft: メトリック拡張のデプロイ可能な下書きを保存します。

- ユーザー定義メトリックを移行するための動詞

- abort_udmmig_session: ユーザー定義メトリック移行セッションを(一部)中断します。

- analyze_unconverted_udms: 変換されていないユーザー定義メトリックを分析します。

- create_udmmig_session: ユーザー定義メトリック移行セッションを作成します。

- list_unconverted_udms: 移行セッションにまだ含まれていないユーザー定義メトリックをリスト表示します。

- udmmig_list_matches: 特定のユーザー定義メトリック移行セッション内で、ユーザー定義メトリックごとに一致するメトリックをリスト表示します。

- udmmig_request_udmdelete: ターゲットからのユーザー定義メトリックの削除を要求します。

- udmmig_retry_deploys: ターゲットへのメトリック拡張のデプロイを再試行します。

- udmmig_session_details: 特定のユーザー定義メトリック移行セッションの詳細を取得します。

- udmmig_submit_metricpicks: セッションのユーザー定義メトリックを置換するメトリックを選択します。

- udmmig_summary: すべてのユーザー定義メトリック移行セッションのステータスのサマリーを表示します。

- udmmig_update_incrules: 置換のメトリック参照を含むようにユーザー定義メトリックのインシデント・ルールを更新します。

メトリック拡張のための動詞

emcli export_metric_extension
-file_name=<name of the metric extension archive>
-target_type=<target type of the metric extension>
-name=<name of the metric extension
-version=<version of the metric extension>

Description:
Export a metric extension archive file.

Options:
-file_name=<file name>
The name of the metric extension archive file to export into.
-target_type=<target type>
Target type of the metric extension.
-name=<name>
Name of the metric extension.
-version=<version>
Version of the metric extension to be exported.

emcli get_unused_metric_extensions

Description:
Get a  list of metric extensions that are deployed to agents but not attached to any targets.

emcli import_metric_extension
-file_name=<name of the metric extension archive>
-rename_as=<name of the metric extension to import as>

Description:
Import a metric extension archive file.

Options:
-file_name=<file name>
The name of the metric extension archive file to be imported.
-rename_as=<metric extension name>
Import the metric extension using the specified name, replacing the name given in the archive.

emcli publish_metric_extension
-target_type=<target type of the metric extension>
-name=<name of the metric extension
-version=<version of the metric extension>

Description:
Publish a metric extension for use by all administrators.
The metric extension must currently be a deployable draft.

Options:
-target_type=<target type>
Target type of the metric extension.
-name=<name>
Name of the metric extension.
-version=<version>
Version of the metric extension to be published.

emcli save_metric_extension_draft
-target_type=<target type of the metric extension>
-name=<name of the metric extension
-version=<version of the metric extension>

Description:
Save a deployable draft of a metric extension. The metric
extension must currently be in editable state. Once saved as
draft, the metric extension will no longer be editable.

Options:
-target_type=<target type>
Target type of the metric extension.
-name=<name>
Name of the metric extension.
-version=<version>
Version of the metric extension to be saved to draft.

ユーザー定義メトリックの動詞

emcli abort_udmmig_session
-session_id=<sessionId>
[-input_file=specific_tasks:<complete path to file>]

Description:
Abort the migration of user-defined metrics to MEs in a session

Options:
-session_id=<id of the session>
Specify the id that was returned at time of session created,
or from the output of udmmig_summary
[-input_file=specific_tasks:<complete file path>]
This optional parameter points at a file name that contains a
target, user-defined metric,
one per line in the following format:
<targetType>,<targetName>,<collection name>
Use targetType=Template to indicate a template
Use * for collection name to abort all user-defined metrics for a target

emcli analyze_unconverted_udms [-session_id=<sessionId>]

Description:
Analyze user-defined metrics and list unique user-defined metrics, any possible matches, and
templates that can apply these matching metric extensions
Options:
-session_id=<id of a session to be reanalyzed>
Not specifying a session id causes the creation of a analysis
session that contains all unconverted user-defined metrics. You can specify
this session id in future invocations to get fresh analysis.

emcli create_udmmig_session
-name=<name of the session>
-desc=<description of the session>
[-udm_choice=<specific udm to convert>]*
{-target=<type:name of the target to migrate> }*
| {-input_file=targetList:<complete path to file>};      {-template=<name of the template to update> }*
| {-input_file=templateList:<complete path to file>}
[-allUdms]

Description:
Creates a session to migrate user-defined metrics to metric extensions for targets.

Options:
-name=<session name>
The name of the migration session to be created.
-desc=<session session description>
A description of the migration session to be created.
-udm_choice=<udm name>
If the session should migrate specific user-defined metrics, specify them
Otherwise, all user-defined metrics will be migrated
-target=<type:name of target to migrate>
The type:name of the target to be updated.
Multiple values may be specified.
-input_file=targetList:<complete file path>
This takes a file name that contains a list of targets,
one per line in the following format:
<targetType>:<targetName>
-template=<name of template to migrate>
The name of the template to update.Multiple values may be specified
-input_file=templateList:<complete file path>
This takes a file name that contains a list of templates,
one name per line
-allUdms
This forces the session to contain all user-defined metrics from targets and
templates (default behavior just picks those not in a session)

emcli list_unconverted_udms [-templates_only]

Description:
Get the list of all user-defined metrics that are not yet in a migration session

Options:
-templates_only
Only lists unconverted user-defined metrics in templates.

emcli udmmig_list_matches
-session_id=<sessionId>

Description:
Lists the matching metrics per user-defined metric in a migration session
Options:
-session_id=<id of the session>
Specify the id that was returned at time of session created,
or from the output of udmmig_summary

emcli udmmig_request_udmdelete
-session_id=<sessionId>
-input_file=metric_tasks:<complete path to file>

Description:
Delete the user-defined metrics that have been replaced by Metric Extenions

Options:
-session_id=<id of the session>
Specify the id that was returned at time of session created,
or from the output of udmmig_summary
-input_file=metric_tasks:<complete file path>
This takes a file name that contains a target, user-defined metric,
one per line in the following format:
<targetType>,<targetName>,<collection name>

emcli udmmig_retry_deploys
-session_id=<sessionId>
-input_file=metric_tasks:<complete path to file>

Description:
Retry the deployment of metric extensions to a target

Options:
-session_id=<id of the session>
Specify the id that was returned at time of session created,
or from the output of udmmig_summary
-input_file=metric_tasks:<complete file path>
This takes a file name that contains a target, user-defined metric,
one per line in the following format:
<targetType>,<targetName>,<collection name>

emcli udmmig_submit_metricpicks
-session_id=<sessionId>
-input_file=metric_picks:<complete path to file>

Description:
Supply the metric picks to use to replace user-defined metrics per target in a session

Options:
-session_id=<id of the session>
Specify the id that was returned at time of session created,
or from the output of udmmig_summary
-input_file=metric_picks:<complete file path>
This takes a file name that contains a target, user-defined metric, metric pick,
one per line in the following format:
<targetType>,<targetName>,<collection name>,[N/E],<metric>,<column>
using N if a new metric should be created or E if an existing
metric is referenced.

emcli udmmig_summary
[-showAll]

Description:
Gets the summary details of all migration sessions in progress

Options:
-showAll
This prints out all sessions including those that are complete.
By default, only in-progress sessions are listed.

emcli udmmig_update_incrules
-session_id=<sessionId>
-input_file=udm_inc_rules:<complete path to file>

Description:
Update Incident Rules that reference user-defined metrics with a reference to
replacing metric extension.

Options:
-session_id=<id of the session>
Specify the id that was returned at time of session created,
or from the output of udmmig_summary
-input_file=udm_inc_rules:<complete file path>
This takes a file name that contains rule, user-defined metric, metric,
one per line in the following format:
<ruleset id>,<rule id>,<udm name>,<metric name>

9 高度なしきい値管理

定期的な(予測できる)間隔で、ターゲットに異なるワークロードが発生する監視状況があります。このような状況では、静的なアラートしきい値では正確な結果が得られません。たとえば、日中はオンライン・トランザクション処理(OLTP)を実行していて、夜間にバッチ処理を実行するデータベースの正確なアラートしきい値は異なります。同様に、平日と週末など、期間が異なれば、データベースのワークロードは変わります。これらの2つの状況で、しきい値が固定された静的な値であれば、間違ったアラート・レポートが生成される可能性があります。

高度なしきい値を使用すると、適応(自己調整)または時間ベース(静的)のアラートしきい値を定義し管理できます。

- 適応しきい値は、ターゲットの測定された動作(メトリック)からの統計計算に基づくしきい値です。

- 時間ベースのしきい値は、ユーザー定義のしきい値で、ターゲットの変化するワークロードに対処するために日/週の異なる時間で使用されます。

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

- 「高度なしきい値管理」ページへのアクセス

- 適応しきい値

- 時間ベースの静的しきい値

- 有効なメトリックしきい値の決定

9.1 「高度なしきい値管理」ページへのアクセス

高度なしきい値は、Enterprise Managerコンソールから管理します。「高度なしきい値管理」ページでは、時間ベースの静的しきい値と適応しきい値を作成できます。このページにアクセスするには、次の手順を実行します。

1. ターゲットのホームページ(ホストなど)から、メトリック・コレクションおよび設定ページに移動します。

2. 「関連リンク」リージョンから、「高度なしきい値管理」をクリックします。
「高度なしきい値管理」ページが表示されます。

9.2 適応しきい値

適応しきい値は、ターゲットのワークロード状態に適応するように静的に計算されたしきい値です。適応しきい値は、すべてのターゲット(エージェントおよびリポジトリの両方が監視するターゲット)に適用されます。

主要概念

適応しきい値の作成は、次の主要概念に基づきます。

- ベースライン期間
パフォーマンス評価を目的として、ベースライン期間は、システムの通常動作を特性付けるために使用される期間を表します。ベースライン期間のシステム動作を、別の期間に測定されたシステム動作と比較します。

ベースライン期間には、次の2つのタイプがあります。

- 変動ウィンドウ・ベースライン期間: 変動ウィンドウ・ベースライン期間は現在の日付より前の一定の日数として定義されます。この日数で構成されるウィンドウは、現在時刻とともに移動する変動期間を形成します。Enterprise Managerで変動ウィンドウ・ベースラインを定義するために使用できる日数は、次のとおりです。

- 7日

- 14日

- 21日

- 30日
例: 変動ウィンドウ・ベースラインを作成するときに、期間として7日の追跡期間を指定したと想定します。この状況では、直前の7日間が本日のすべてのメトリックを観測および比較するためのベースライン期間になります。明日になると、この参照期間から最も古い日が削除され、当日(つまり、翌日)が追加されます。

変動ウィンドウ・ベースラインを使用すると、現在のメトリック値を最近観測された履歴と比較できるので、時間経過に伴うシステムの変化にベースラインを合わせることができます。変動ウィンドウ・ベースラインは、予測可能なワークロード・サイクルを持つシステムに適しています。

注意:
Enterprise Managerによる変動ウィンドウ統計の計算は、日をサンプリングすることなく、毎日実行されます。

9.2.1 適応しきい値メトリックの登録

デフォルトでは、適応しきい値メトリックはすぐに使用できません。Enterprise Managerで使用できるようにするには、定義してシステムに追加(登録)する必要があります。すべてのメトリックに適応しきい値を割り当てられるわけではありません。適応しきい値メトリックは、次のカテゴリのいずれかに分類される必要があります。

- 負荷

- LoadType

- 使用率

- レスポンス

「高度なしきい値管理」ページから、適応しきい値メトリックを登録できます。

1. ターゲットのメニュー(この例では「Host」を使用)から、「モニタリング」を選択し、「メトリックと収集設定」を選択します。

2. 「関連リンク」領域で、「高度なしきい値管理」をクリックします。「高度なしきい値管理」ページが表示されます。

3. 「アクティブな適応設定の選択」メニューから、「変動ウィンドウ」を選択すると、その他のコントロールが表示され、適応しきい値を計算するために使用される、変動ウィンドウの「しきい値変更頻度」と「累積された追跡データ」を定義できます。

- しきい値変更頻度(ターゲットのタイムゾーン使用)

- なし: 過去のデータを使用して1セットのしきい値が計算されます。このしきい値のセットは1週間有効です。
日中と夜間との間、または終日を通して使用状況のパターンに変化がない場合は、「なし」を使用する必要があります。

- 日中/夜間単位: 過去のデータを使用して、しきい値の2つのセット(日中と夜間)が計算されます。日中のしきい値は前日の日中のデータを使用して計算され、夜間のしきい値は前日の夜間のデータを使用して計算されます。しきい値は、毎日毎晩変更されます。
日中の時間帯と夜間の時間帯との間に明確なパフォーマンスと使用状況の違いがある場合は、「日中/夜間単位」オプションを使用する必要があります。

- 平日/週末単位: 過去のデータを使用して、しきい値の2つのセット(平日と週末)が計算されます。平日のしきい値は、前の平日のデータを使用して計算されます。週末のしきい値は、前の週末のデータを使用して計算されます。しきい値は、平日の開始時と、週末の開始時に変更されます。

- 平日および週末当たりの日中/夜間単位: 過去のデータを使用して、しきい値の4つのセットが計算されます。平日の日中しきい値は、以前の平日の日中データを使用して計算され、平日の夜間しきい値は以前の平日の夜間データを使用して計算されます。週末の日中しきい値は、以前の週末の日中データを使用して計算され、週末の夜間しきい値は以前の週末の夜間データを使用して計算されます。しきい値は、毎日毎晩変更されます。
平日の日中(7a.m.から7p.m.)

週末の日中(7a.m.から7p.m.)

平日の夜間(7p.m.から7a.m.)

週末の夜間(7p.m.から7a.m.)

- 曜日単位: 曜日ごとに、7セットのしきい値が計算されます。しきい値は、前週の同じ曜日のデータを使用して計算されます。しきい値は、毎日変更されます。
「曜日単位」は、曜日ごとに使用状況が大きく異なる場合に使用する必要があります。

- 曜日当たりの日中/夜間単位: 各曜日の日中と夜間に対して、14セットのしきい値が計算されます。「日中」しきい値は前週の同じ曜日の日中データを使用して計算され、「夜間」しきい値は前週の同じ曜日の夜間データを使用して計算されます。しきい値は、各曜日の日中と夜間で変更されます。

- 累積された追跡データ
メトリック・データが収集される期間の合計時間です。7日、14日、21日および28日のいずれかを選択できます。通常は、データが多いほど正確なしきい値を計算できるため、大きい値を選択してください。

4. 「保存」をクリックして確定します。「適応メトリックの登録」リージョンで、「メトリックの登録」ボタンがアクティブになります。「メトリックの登録」をクリックします。「メトリック・セレクタ」ダイアログが表示されます。

5. 希望するメトリックを選択して、「OK」をクリックします。選択したメトリックがこのターゲットの適応設定に追加されることを伝える確認ダイアログが表示されます。「はい」をクリックして、アクションを確認します。選択したメトリックが、「適応メトリックの登録」リージョンに表示されます。

6. 適応メトリックとして登録した各メトリックは、しきい値を構成するために選択できます。メトリックを最初に登録したとき、デフォルトでは、Enterprise Managerによって「重大レベル」が有効化され、警告のしきい値が95パーセンタイル、クリティカルのしきい値が99パーセンタイルに設定されます。

9.2.2 適応しきい値の構成

適応メトリックを登録したら、次に、事前定義済しきい値が監視要件を満たさない場合に、しきい値を構成できます。

適応しきい値を構成するには、次の操作を行います。

1. 「適応メトリックの登録」リージョンから、構成するメトリックを選択して、「しきい値の一括構成」をクリックします。「しきい値の構成」ダイアログが表示されます。

2. しきい値のベースを指定するかどうかを次から選択します。
重大レベル: 重大レベルをベースにするしきい値では、統計的な関連性を使用して、現在の値が統計的異常値であるかどうかを判断します。アラートのために重大レベルを使用する一番の理由は、ユーザーがしきい値をただ設定するだけではなく、メトリック値の統計上の外れ値を検出しようとするためです。つまり、しきい値はパーセンタイルがベースになります。たとえば、重大レベルを警告しきい値に対して.95に設定すると、収集したメトリック値の5%がこの値の範囲外となり、この値を超える任意の現在値がアラートをトリガーするようにメトリックしきい値が設定されます。.98や.99など、より高い重大レベルを設定するほど、トリガーされるアラートは少なくなります。

最大パーセント: これらのタイプのしきい値では、選択された期間にわたって測定された最大値の指定されたパーセントに基づいて、しきい値が計算されます。現在値が指定した最大パーセント以上になると、最大パーセント・ベースのアラートが生成されます。たとえば、ある時間グループで1000の最大値が測定され、105が警告レベルとして指定されている場合、1050 (1000の105%は1050)を超える値はアラートを生成します。

平均パーセンテージ。時間のグループ化およびバケット処理に基づいて、しきい値の平均が計算され、一定期間および時間パーティションの間測定された値の平均に関連するメトリックしきい値を設定できます。平均値は100%です。

すべてのタイプのアラートに対して、アラートの生成に先立ってメトリックがしきい値を超えることが許容される回数を示す「発生」パラメータを指定できます。

しきい値のクリア: 選択したメトリックのしきい値がクリアされます。アラートは生成されません。メトリックのしきい値を設定する必要はないが、履歴データを削除したくない場合に、このオプションを使用してください。重要: メトリックを登録解除すると履歴データが削除されます。

選択したオプションに応じて、「警告」、「クリティカル」および「発生」の設定オプションは異なります。

計算された平均値に偏差を設定できます。

「不十分なデータに対するしきい値の処理」メニューでは、有効なメトリックしきい値を計算するために必要なデータが不十分である場合に、Enterprise Managerにより実行される適切なアクションを設定できます。「前のしきい値を保持」と「アラートの抑止」の2つのオプションが利用できます。

「最大許容しきい値」では、超えた場合にクリティカル・アラートが生成されるしきい値の上限を設定できます。最大値の25%未満になると、警告アラートが自動的に生成されます。

3. 「OK」をクリックして、変更を設定します。

9.2.3 適応しきい値が正しいことの確認

Enterprise Managerでは、適応しきい値設定を使用して正確なターゲット・ワークロードメトリックしきい値の一致が決定されますが、それでも、メトリック・サンプリング・スケジュールを実際のターゲット・ワークロードに一致させる必要があります。たとえば、変動ウィンドウ・ベースライン期間(「変動ウィンドウ・ベースライン期間」を参照)がターゲット・ワークロードに一致する必要があります。一部の状況では、実際のターゲット・ワークロードが不明で、適応しきい値の設定が問題となることがあります。

適応しきい値の有効性を確認するために、Enterprise Managerでは、様々な適応設定を使用してしきい値を分析し、設定が正しいかどうかを確認できます。

既存の適応しきい値を分析するには、次の操作を行います。

1. 「適応メトリックの登録」リージョンから、「しきい値の分析」をクリックします。

履歴メトリック・データのグラフ(各メトリックに1つ)を含む「しきい値の分析」ページが表示されます。

2. 適応しきい値パラメータを変更して、メトリックしきい値設定をターゲット・ワークロードに厳密に一致させます。次の適応メトリック・パラメータをテストできます。
しきい値変更頻度

しきい値のベース

メトリックの警告とクリティカルのしきい値

3. 「しきい値変更頻度」または個々のメトリックに対する変更が終了したら、「保存」をクリックして、新しいパラメータを設定します。

9.2.4 適応メトリックしきい値のテスト

適応メトリックしきい値は一定期間におけるデータの統計サンプリングを利用するので、しきい値の精度は、収集されたデータの量と質に依存します。このため、しきい値が有効になるためには、十分な量のメトリック・データを収集する必要があります。適応しきい値に登録されたメトリック用のデータが十分に収集されているかどうかを確認するには、「テスト・データの適合性」機能を使用します。

1. 「登録済の適応メトリック」リージョンで、「テスト・データの適合性」をクリックします。

Enterprise Managerにより適応しきい値メトリックが評価され、結果が「テスト・メトリック」ウィンドウに表示されます。

適応しきい値を計算するためのデータが十分に収集されていると、結果列に緑色のチェックが表示されます。データが十分に収集されていない場合は、赤色のxが結果列に表示されます。この状況を解決するには、累積追跡データ・ウィンドウを長くすることをお薦めします。また、メトリック・データを収集する頻度を増やすこともできます。

2. 結果の確認が終了したら、「保存してアクティブ化」をクリックします。

9.2.5 適応しきい値メトリックの登録解除

特定のメトリックが適応しきい値として必要なくなった場合、それらのメトリックをいつでも登録解除できます。適応しきい値メトリックを登録解除するには、次の操作を行います。

1. 「適応メトリックの登録」リージョンから、登録解除するメトリックを選択します。

2. 「登録解除」を選択します。ターゲットの適応設定からメトリックを削除する操作を続行するかを確認するダイアログが表示されます。

3. 「はい」をクリックします。

9.2.6 モニタリング・テンプレートを使用した適応しきい値の設定

モニタリング・テンプレートを使用して、環境内のターゲット間で幅広く適応しきい値を適用できます。たとえば、モニタリング・テンプレートを使用して、すべてのホスト・ターゲットのCPU使用率メトリックの適応しきい値設定を適用できます。

モニタリング・テンプレートを使用して適応しきい値を適用するには、次の手順を実行します。

1. 適応しきい値設定をすでに有効にしているターゲットからテンプレートを作成します。
「エンタープライズ」メニューから、「モニタリング」、「モニタリング・テンプレート」の順に選択します。モニタリング・テンプレート・ページが表示されます。

2. 「作成」をクリックします。モニタリング・テンプレートの作成: モニタリング設定のコピー・ページが表示されます。

3. すでに設定されている適応しきい値のターゲットを選択して、「続行」をクリックします。

4. テンプレートの名前を入力して、短い説明を入力します。「OK」をクリックします。

モニタリング・テンプレートを作成した後、他のテンプレートと同様に、テンプレートを表示または編集できます。テンプレートの適応メトリックを変更、追加または削除するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「モニタリング」、「モニタリング・テンプレート」の順に選択します。モニタリング・テンプレート・ページが表示されます。

2. モニタリング・テンプレート・ページで、リストから監視テンプレートを選択します。

3. 「アクション」メニューから、「詳細モニタリング設定の編集」を選択します。「適応設定」タブを選択した詳細モニタリング設定の編集ページが表示されます。

4. 必要な場合、適応メトリックを変更します。

9.3 時間ベースの静的しきい値

時間ベースの静的しきい値を使用すると、時間によって変化するワークロードに対応するために、様々な時間に使用する固有のしきい値を定義できます。時間ベースの静的しきい値は、特定のターゲットのワークロード・スケジュールが適切に把握されている場合、または指定するしきい値が明確である場合はいつでも使用できます。

9.3.1 時間ベースの静的しきい値の登録

メトリックを時間ベースの静的しきい値に登録するには、次の操作を行います。

1. ターゲットのメニュー(この例では「Host」を使用)から、「モニタリング」を選択し、「メトリックと収集設定」を選択します。

2. 「関連リンク」領域で、「高度なしきい値管理」をクリックします。「高度なしきい値管理」ページが表示されます。

3. 「時間ベースの静的設定」タブをクリックします。

4. 「しきい値変更頻度」を選択します。

5. 「メトリックの登録」をクリックします。

「メトリック・セレクタ」ダイアログが表示されます。

6. 希望するメトリックを選択して、「OK」をクリックします。
選択したメトリックが、「登録済のメトリック」表に表示されます。

7. 希望するメトリックしきい値を入力し、操作が終了したら、「保存」をクリックします。
複数のメトリックに対してしきい値を同時に設定する場合、更新するメトリックの「選択」ボックスを選択して、「しきい値の一括構成」をクリックします。「しきい値の構成」ダイアログが表示されます。

「警告」および「クリティカル」の新しいしきい値を入力して、「OK」をクリックします。既存のメトリックしきい値が上書きされることを伝える確認ダイアログが表示されます。「はい」をクリックします。

8. オプションで、「しきい値変更頻度」を変更することもできます。これを行うには、時間ベースの静的しきい値の設定ページで、「変更」をクリックします。「しきい値変更頻度の変更」ダイアログが表示され、新しい変更頻度を選択できます。新しい頻度を選択して、「OK」をクリックします。
「しきい値変更頻度」を変更するとすべての登録済のメトリックに影響が及ぶことを通知し、操作を続行するかを確認するダイアログが表示されます。「はい」をクリックして続行します。

9. 「保存」をクリックし、すべての変更がEnterprise Managerリポジトリに保存されたことを確認します。

9.3.2 時間ベースの静的しきい値の登録解除

時間ベースの静的しきい値メトリックが必要なくなった場合、それらのメトリックをターゲットから登録解除できます。

時間ベースの静的メトリックしきい値を登録解除するには、次の操作を行います。

1. 「時間ベースの静的しきい値」タブから、登録解除するメトリックを選択します。

2. 「削除」をクリックします。メトリック・エントリがリストから削除されます。

3. 「保存」をクリックして、変更をEnterprise Managerリポジトリに保存します。

9.4 有効なメトリックしきい値の確認

これまでにも説明しているように、静的しきい値は、OLTPトランザクションが実行されているウェアハウス・データベース・ターゲットで発生するワークロードの場合など、ターゲットで発生するワークロードの増減により予測されるパフォーマンス変化に対応していません。また、平日と週末、日中と夜間など、期間が異なれば、ワークロードも変わることがあります。これらのタイプのようにワークロードが大きく変化する場合、固定された静的メトリックしきい値を使用すると、誤ったメトリック・アラートやメトリック・アラートの過剰生成などの問題が発生する可能性があります。究極的には、監視ニーズに応じて、正確なメトリックしきい値を取得できる最善の方法を選択する必要があります。

10 ジョブ・システムと修正処理の使用

Enterprise Manager Cloud Controlのジョブ・システムでは、日常的に繰り返し行われる管理タスクを自動化し、環境内のコンポーネントを同期化することで、より効率的に管理できます。

この章では、次の項の手順に従うことでジョブ・システムの使用が容易になります。

- ジョブ・システムの目的および概要

- 事前の考慮事項

- ジョブの作成

- ジョブ・ステータスの表示と分析

- ジョブ・イベント基準の生成

- ジョブ・ステータス変更イベントのイベント・ルールの作成

- 診断ツールの使用

- 修正処理の作成

10.1 ジョブ・システムの目的および概要

Enterprise Managerジョブ・システムは、次の目的に役立ちます。

- バックアップ、クローニング、パッチ適用など、多くの管理タスクを自動化します。

- ユーザー独自のカスタムOSスクリプトやSQLスクリプトを使用した、固有のジョブを作成できます。

- 複数のタスクで構成される独自のマルチタスク・ジョブを作成できます。

- ジョブのスケジューリングを単一の堅牢なツールに環境を一元化します。

ジョブとは、頻繁に実行するタスクの自動化を定義するための作業の単位です。スケジュールの柔軟性は、ジョブの長所の1つです。ジョブは、すぐに開始したり、後の日時で開始したりするようにスケジュールできます。ジョブは、1回の実行または特定の間隔(月に3回など)での実行も可能です。

ジョブ・アクティビティ・ページ(図10–1)は、ジョブ・システムの中枢です。このページからは、次の操作が可能です。

- 既存のジョブ実行と個別ジョブ実行を検索します。「名前」、「所有者」、「ステータス」、「スケジュール開始」、「ジョブ・タイプ」、「ターゲット・タイプ」、「ターゲット名」などで絞り込みます。

- ジョブを作成します。

- ジョブ定義を表示または編集します。

- ジョブの類似作成、ライブラリへのコピー、一時停止、再開、停止、削除を行います。

- 結果の表示、ジョブ実行または個別ジョブ実行の編集、類似作成、一時停止、再開、再試行、停止および削除を行います。

図10-1 「ジョブ・アクティビティ」ページ

「エンタープライズ」メニューから「ジョブ・アクティビティ」ページにアクセスする他に、ターゲット・タイプのメニューから「ジョブ・アクティビティ」を選択して、すべてのターゲット・タイプのターゲット固有のメニューからこのページにアクセスすることもできます。このような別の場所からこのページにアクセスする場合、「ジョブ・アクティビティ」ページには、ジョブの一覧ではなく、特定のターゲットに関連するジョブのサブセットが表示されます。

10.1.1 「ジョブ・アクティビティ・サマリー」表ビューの変更

ジョブ実行を従来の表形式で表示するほか、Enterprise Managerではジョブ実行データをより有意義なものにする代替ビューを使用してジョブ実行を表示できます。たとえば、最も多くのリソースを使用しているジョブまたは最も実行時間の長いジョブを表示できます。

次の3つのジョブ・アクティビティ表示オプションがあります。

- リスト: 従来の表形式によるジョブ情報表示。

- 時系列: ジョブ実行を時系列でグラフィカルに表示します。指定された期間、最も多くのリソースを占有しているジョブ実行をすばやく特定できます。タイムラインをクリックすると、凡例エリアで実行されたジョブに関する詳細が表示されます。タイムラインをダブルクリックすると、ジョブ実行詳細のページに移動します。

- サマリー: 属性の選択した属性に基づいて、ジョブ実行のグラフィカルなロールアップを表示します。ロールアップ・ビューの任意のセルをクリックすると、検索をさらに絞り込み、さらに詳細にジョブの実行を分析する表ビューに移動します。

「サマリー」表ビューを変更するには:

1. 表の右にある「サマリー表示」ドロワー(眼鏡)をクリックします。

2. 表示タイプ(「リスト」、「時系列」または「サマリー」)を選択します。「サマリー」を選択した場合、選択可能なサマリー表示属性が表示されます。

10.1.2 ジョブ検索

利便性のために、頻繁に使用する特定のジョブを表示したりアクセスできるジョブ検索を定義できます。デフォルトでは、「ジョブ・アクティビティ」ページの最上部に定義済ジョブ検索が表示されます。

- 過去24時間以内の問題があるジョブ

- 過去24時間以内のジョブ実行アクティビティ

- 今後24時間以内に実行するようにスケジュールされているジョブ

- 現在ログインしているユーザーに属しているジョブ

10.1.2.1 ジョブ検索の保存

よく使用するジョブ検索を保存することで、関係するジョブ情報をすばやく表示できます。

保存済検索を作成するには:

1. 「使用可能な基準」領域で、検索に必要なパラメータを選択します。結果が「ジョブ・アクティビティ」表に即座に表示されます。

2. 選択した基準が表示されるツール・バーの「保存済検索」ボタンをクリックします。

3. 展開したドロワーから「作成」をクリックします。「保存済検索の作成」ダイアログが表示されます。

4. 検索の名前を入力します。

5. 保存済検索を表示する方法を選択します。「デフォルト・ジョブ・アクティビティ検索」オプションを選択すると、「ジョブ・アクティビティ」ページにアクセスするたびに検索が実行されます。「ジョブ・アクティビティ」ページの上部で「統計」を選択すると、「ジョブ・アクティビティ」ページの上部にあるデフォルトの保存済検索の1つとして保存済検索が表示されます。

6. 「OK」をクリックして検索を保存します。

7. 「実行」をクリックして検索を実行し、結果を表示します。

10.1.2.2 保存済ジョブ検索の編集

保存済ジョブ検索を編集するには:

1. 選択した基準が表示されるツール・バーの「保存済検索」ボタンをクリックします。

2. 展開したドロワーから目的の検索を選択して、「編集」をクリックします。「保存済検索の編集」ダイアログが表示されます。

3. 保存済検索を表示する方法を選択します。「デフォルト・ジョブ・アクティビティ検索」オプションを選択すると、「ジョブ・アクティビティ」ページにアクセスするたびに検索が実行されます。「ジョブ・アクティビティ」ページの上部で「統計」を選択すると、「ジョブ・アクティビティ」ページの上部にあるデフォルトの保存済検索の1つとして保存済検索が表示されます。

4. 保存済検索を表示する場所を選択します。

5. 「OK」をクリックして検索を保存します。

6. 「実行」をクリックして検索を実行し、結果を表示します。

10.1.2.3 保存済ジョブ検索のインポート

デフォルトでは、自分が作成した検索のみ表示できます。他の管理者が作成した検索を使用するために、検索をインポートできます。これらは、保存済検索のリストに表示されます。

保存済検索をインポートするには:

1. 選択した基準が表示されるツール・バーの「保存済検索」ボタンをクリックします。

2. 展開したドロワーから「インポート」をクリックします。ブラウザのスペースの制約により「インポート」ボタンが表示されない場合は、ドロワーの右端にある二重矢印をクリックします。「他の管理者から保存済検索をインポート」ダイアログが表示されます。

3. 探しているジョブに必要な検索条件を入力します(名前、所有者、条件名、条件値)。検索条件に一致するジョブが下に表示されます。

4. 目的のジョブを選択して、「インポート」をクリックします。ジョブが保存済検索のリストに表示されます。

5. 「実行」をクリックして新たにインポートした検索を実行し、結果を表示します。

10.1.3 個別ジョブ実行とジョブ実行について

次の各項では、それぞれの特性について説明します。

10.1.3.1 ジョブ実行

個別ジョブ実行は通常、特定のデータベースのパッチ・ジョブなど、単一のターゲットに関連付けられます。ただし、個別ジョブ実行は、必ずしもターゲットへ1対1で割り当てられているとはかぎりません。個別ジョブ実行によっては、ホストの比較など、複数のターゲットに対して実行される場合があります。複数のターゲットに対して実行されるジョブでは、すべてのターゲットを1回の実行で実行する場合と、各ターゲットに対して別々に実行する場合があります。

個別ジョブ実行は通常、特定のデータベースのパッチ・ジョブなど、単一のターゲットに関連付けられます。これらは1回の実行が1ターゲットのみであるため、単一ターゲット・ジョブと呼ばれます。ただし、個別ジョブ実行は、必ずしもターゲットへ1対1で割り当てられているとはかぎりません。個別ジョブ実行によっては、ホストの比較など、複数のターゲットに対して実行される場合があります。これらのジョブは、すべてのターゲットに対して1回のみ実行するため、単一実行ジョブと呼ばれます。複数のターゲットに対して実行されるジョブでは、単一実行ジョブか単一ターゲット・ジョブかによって、1回または多数のジョブが実行されます。わずかですが、ターゲットがないジョブもあります。これらのジョブは、ターゲットのないジョブと呼ばれ、1回の実行で実行されます。

複数のターゲットへジョブを発行する場合、ターゲットごとにジョブの個別実行ステータスを確認するのは大変な作業です。たとえば、複数のデータベースにバックアップ・ジョブを実行するとします。すべてのバックアップ・ジョブが成功したか、成功しなかった場合は、どのジョブが失敗したのかを確認する必要があります。このバックアップ・ジョブを毎週実行する場合は、毎週、どのバックアップが成功して、どのバックアップが失敗したかを把握する必要があります。

10.1.3.2 ジョブ実行

ジョブ・システムでは、ジョブ実行を表示して、その結果を簡単に知ることができます。ジョブ実行は、スケジュールした特定の日に実行されたすべての個別ジョブ実行の集合です。たとえば、3月5日にスケジュールされたジョブがある場合、ジョブ実行は3月5日になります。ジョブ実行を示す「ジョブ」表には、「成功」、「失敗」、「エラー」などの個別ジョブ実行のステータスのロールアップが表示されます。

10.1.4 個別ジョブ実行とジョブ実行の操作

ジョブ・システムでは、作成、編集、類似作成、削除などの標準的なジョブ操作のサポートに加えて、次の操作を実行できます。

- ジョブの一時停止:
個別ジョブ実行またはジョブ全体を一時停止できます。たとえば、必要なリソースを使用できなかった場合や、ジョブを延期する必要がある場合には、ジョブの中断が必要になる場合があります。

ジョブの繰返しがスケジュールされていても、スケジュールされた繰返し時間や1日の上限を過ぎて一時停止する場合、ジョブの実行は「スキップ」とマークされます。ジョブは、スケジュールされた時間に猶予期間を足した時間が過ぎた場合もスキップされます。

- ジョブの再開:
ジョブを一時停止すると、スケジュールされた個別ジョブ実行は、ジョブを再開するまで実行されません。

- すべての失敗した実行を1回のジョブ実行で再試行:
個々の実行またはジョブ全体を分析するときに、問題の原因を判別した後で、失敗した実行を再試行すると便利です。こうすると、失敗した実行のために新しいジョブを作成する必要性が少なくなります。「ジョブ・システム」で「再試行」操作を使用するとき、失敗した実行と再試行した実行の間のリンクがEnterprise Managerによって生成されます。これは、失敗した実行の原因を後から調べるために役立ちます。「ジョブ実行」ページには最新のエントリのみが表示されます。

ジョブ・システムでは、ジョブ実行に関して次の操作を行うことができます。

- 古いジョブ実行の削除

- ジョブ実行の停止

- すべての失敗した実行を1回のジョブ実行で再試行。正常に実行されると再試行されません。

関連項目:
個別ジョブ実行とジョブ実行の詳細は、Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。

10.2 事前の考慮事項

第10.3項「ジョブの作成」に示す手順情報に進む前に、次の項で説明するトピックに目を通すことをお薦めします。

- 管理者ロール

- スクリプトの作成

- ジョブ職責の共有

- グループに対するジョブの発行

10.2.1 管理者ロール

Enterprise Managerでは、次の管理者タイプが用意されています。

- 管理者 — ほとんどのジョブその他のアクティビティは、この通常のユーザー・タイプで開始されます。

- スーパー管理者 — スーパー管理者向けジョブの実行、ブラックアウトの作成、専用ターゲットという限られた使用状況はありますが、通常は使用しません。

- リポジトリ所有者(SYSMAN) — 特別なリポジトリ所有者ユーザーであるSYSMANは、前述の2つのタイプに示すタスクを所有したり実行することはほぼありません。このユーザーはサイトの設置などのような最上位のアクション向けに確保されています。

10.2.2 スクリプトの作成

事前定義済のジョブ・タスクに加え、OSスクリプトやSQLスクリプトに含めるコードを記述し、固有のジョブ・タスクを定義できます。これらのスクリプトの使用には、次のメリットがあります。

- これらのジョブの定義時に、ターゲット・プロパティを使用できます。

- これらのジョブの定義時に、ジョブ・ライブラリを使用できます。これにより、ジョブを共有でき、問題が発生したときに更新できます。ただし、更新を有効にするために、変済のライブラリ・ジョブを再発行する必要があります。

- 複数のターゲットに対してジョブを発行できます。

- 1つのグループに対してジョブを発行できます。ジョブは、自動的にグループ・メンバーシップの変更に対応します。

- ホスト・コマンドのジョブでは、クラスタに対してジョブを発行できます。

- SQLジョブでは、Real Application Clusterに対してジョブを発行できます。

10.2.3 ジョブ職責の共有

ジョブ職責の共有を許可するために、ジョブ・システムはジョブ権限を提供しています。これらのジョブ権限を使用し、他の管理者とジョブを共有できます。権限を使用し、次の操作を許可できます。

- ジョブの結果を確認する必要がある管理者にアクセス権を付与します。

- ジョブ定義の編集や、ジョブ実行の制御(一時停止、再開、停止)が必要な管理者に完全なアクセス権を付与します。

これらの権限を必要に応じて付与できます。

10.2.4 グループに対するジョブの発行

ジョブのターゲットとして、多数のターゲットを個々にリストするのではなく、グループを使用できます。ジョブに選択されたターゲット・タイプと一致するグループのすべてのメンバー・ターゲットは、ジョブを実行する際の実際のターゲットとして選択されます。グループのメンバーシップが変わった場合、それによってジョブの実際のターゲット・リストが変更されます。ジョブを繰り返す場合、そのジョブの反復(実行)ごとに、実行時のグループの一致するターゲットで実行されます。

ターゲット・タイプ選択のオーバーライド

グループに対するターゲット・タイプの選択をオーバーライドするには、targetType=<override_target_type>を入力ファイルのcreate_job動詞に設定します。たとえば、OSコマンド・ジョブのデフォルトのターゲット・タイプはホストです。データベースのグループに対してジョブを送信するには、次のように指定します。

target_list=my_db_group:composite
targetType=oracle_database

選択されたターゲット・タイプに一致しないグループのターゲットは無視されます。

関連項目:
第5章「グループの管理」

10.3 ジョブの作成

「ジョブ・アクティビティ」ページでジョブを作成する際には、最初にジョブ・タイプを選択します。これは、次の「ジョブ・タイプの選択」で説明します。最も一般的なジョブ・タイプは、OSコマンド・ジョブ、スクリプト・ジョブおよびマルチタスク・ジョブです。これらについて次の項で順に説明します。

- OSコマンド・ジョブの作成

- SQLスクリプト・ジョブの作成

- マルチタスク・ジョブの作成

10.3.1 ジョブ・タイプの選択

ジョブ・システムを使用する場合、「ジョブ・アクティビティ」ページの「ジョブの作成」をクリックし、ジョブ・タイプの選択ダイアログからジョブ・タイプを選択してジョブを作成できます。ジョブ・タイプの名前を検索するか、ターゲット・タイプを指定して、特定のジョブ・タイプを見つけることができます。

よく使用されるタイプは次のとおりです。

- OSコマンド - オペレーティング・システムのコマンドまたはスクリプトを実行します。

- SQLスクリプト - ユーザー定義のSQLまたはPL/SQLスクリプトを実行します。

- マルチタスク - マルチタスク・ジョブまたは修正処理の主な特性を指定します。マルチタスク・ジョブでは、各タスクが独立したジョブとして機能するタスクを定義することにより、コンポジット・ジョブを作成できます。タスクは、通常のジョブと似た方法で編集および定義します。

10.3.2 OSコマンド・ジョブの作成

オペレーティング・システムのコマンドまたはスクリプトを実行するには、このタイプのジョブを使用します。次に、OSコマンドを作成する場合のタスクやその従属手順について説明します。

タスク1   ジョブ作成の開始

1. 「エンタープライズ」メニューから「ジョブ」、「アクティビティ」の順に選択します。

2. 「ジョブの作成」をクリックします。ジョブ・タイプの選択ダイアログが表示されます。

3. 「OSコマンド」ジョブ・タイプを選択し、「選択」をクリックします。

タスク2   一般ジョブ情報の指定

「一般」プロパティ・ページで次の手順を実行します。

1. ジョブに必要な名前を指定し、ドロップダウンでターゲット・タイプを選択します。
ジョブに特定のタイプのターゲットを選択すると、その同じタイプのターゲットのみをジョブに追加できます。ターゲット・タイプを変更すると、「ターゲット」表に設定したターゲットと、そのジョブのパラメータおよび資格証明が表示されなくなります。

このジョブのターゲットとしてコンポジットを指定すると、ジョブは選択したターゲット・タイプのコンポジット内のターゲットに対してのみ実行されます。たとえば、ホストとグループのターゲット・タイプをターゲットとして指定すると、グループにホスト以外のターゲットがある場合でも、グループ内のホストに対してのみジョブが実行されます。同じターゲット・タイプのものであれば、ターゲット・リストにクラスタを含めることもできます。たとえば、ターゲット・タイプがホストの場合はホスト・クラスタが選択され、ターゲット・タイプがデータベースの場合はRACデータベースが選択されます。

2. 「追加」をクリックして、「検索と選択: ターゲット」ポップアップ・ウィンドウで1つ以上のターゲットを選択します。「ターゲット」表にターゲットが表示されます。

3. 「パラメータ」プロパティ・ページ・リンクをクリックします。

タスク3   パラメータの指定

「パラメータ」プロパティ・ページで次の手順を実行します。

1. 「コマンド・タイプ」ドロップダウンで「単一操作」または「スクリプト」のいずれかを選択します。
指定したコマンドやスクリプトは、ジョブのターゲット・リストに指定された各ターゲットに対して実行されます。管理エージェントは、各ターゲットに対してコマンドやスクリプトを実行します。

目的に応じて次のいずれかのオプションを選択できます。

- 特定のコマンドを実行する単一操作

- OSスクリプトを実行し、スクリプトを処理するインタプリタ(たとえば%perlbin%/perlまたは/bin/sh)をオプションで指定するためのスクリプト。

実行するコマンドを指定する場合で、すべてのホストではスクリプトをインストールおよび更新しない場合、単一のコマンドラインでは不十分なことがあります。この場合、「スクリプト」オプションを使用して、ジョブの一部としてスクリプト・テキストを指定することができます。

2. 目的に応じて、第10.3.2.1項「単一操作の指定」または第10.3.2.2項「スクリプトの指定」の手順に従ってください。

3. 「資格証明」プロパティ・ページ・リンクをクリックします。

注意:
OSコマンドは、指定したコマンド/インタプリタの実行をターゲット・ホストのシェルに依存します。*nixシステムでは
/bin/sh -c、Windowsシステムではcmd /cになります。指定したコマンド・ラインは、対応するシェルで解釈されます。

タスク4   資格証明の指定(オプション)

システム・デフォルトの優先資格証明を使用する場合、このページに入力する必要はありません。

「資格証明」プロパティ・ページでは、ターゲット・ホストに対してOSコマンド・ジョブを実行する際にOracle Management Serviceが使用する資格証明を指定できます。ジョブでは、選択したターゲットに対してジョブ発行者のホストベースの優先資格証明を使用することも、他の資格証明を指定して優先資格証明をオーバーライドすることも可能です。

優先資格証明がすでに設定されている場合、このページに入力する必要はありません。

ヒント:
優先資格証明は、ジョブが複数のターゲットで送信され、各ターゲットの認証に異なる資格証明を使用する必要がある場合に有用です。

- 優先資格証明を使用するには、次の手順を実行します。

1. 「優先資格証明」ラジオ・ボタン(デフォルト)を選択します。
OSコマンド・ジョブのターゲットがホストまたはホスト・グループの場合、優先ホスト資格証明が使用されます。これらは優先資格証明ページのホスト・ターゲットに指定され、データベースが存在するホストに対するホスト資格証明とは異なります。

2. 「ホスト資格証明」ドロップダウンで「通常ホスト資格証明」または「特権ホスト資格証明」のいずれかを選択します。
これらは、「優先資格証明」ページで指定します(このページは、「設定」メニューの「セキュリティ」、「優先資格証明の順に選択してアクセスします)。「優先資格証明」ページが表示されたら、「優先資格証明の管理」ボタンをクリックして資格証明を設定します。

- 名前付き資格証明を使用するには、次の手順を実行します。

1. 「名前付き資格証明」ラジオ・ボタンを選択して、データベースまたはホスト優先資格証明をオーバーライドします。
ドロップダウン・リストは、名前と値が一緒に保存されている事前に移入された資格証明のセットです。これらはターゲットにリンクしていませんが、タスクに資格証明と認証情報を提供するために使用できます。

- 他の資格証明を使用するには、次の手順を実行します。

1. 「新規資格証明」ラジオ・ボタンを選択して、定義済の優先資格証明をオーバーライドします。
資格証明の上書きはすべてのターゲットに適用されることに注意してください。これは名前付き資格証明にも該当します。

2. 実行権限として「sudo」または「PowerBroker」を選択します(オプション)。
sudoでは、特定のユーザー(またはユーザー・グループ)が一部(またはすべて)のコマンドをrootとして実行できるようになり、すべてのコマンドと引数のログが記録されます。PowerBrokerでは、アクセス制御と管理の容易性が得られ、すべてのタイプの権限アカウントを監査できます。

sudoまたはPowerBrokerの詳細を指定する場合、これはすべてのターゲットに適用可能である必要があります。このジョブを実行する全ホストに、sudoまたはPowerBrokerの設定が適用済であることが前提です。

これらの機能が現在有効になっていない場合、その設定についてはスーパー管理者に確認してください。

ヒント:
sudoの使用方法の詳細は、次の『Sudo Manual』を参照してください。

http://www.sudo.ws/sudo/man/1.7.4p6/sudo.man.html

PowerBrokerの使用方法の詳細は、次の『PowerBroker Desktops User Guide』を参照してください。

http://www.ubm-global.com/docs/powerbroker/PBWD_User_Guide_V5%200.pdf

タスク5   ジョブのスケジュール(オプション)

ジョブの発行直後にジョブを実行するデフォルト操作に進む場合、このページに入力する必要はありません。

1. 次のスケジュールのタイプを選択します。

- 1回(即時)
ジョブの発行前にスケジュールを設定しない場合、Enterprise Managerは、無期限の猶予期間でジョブをすぐに実行します。ジョブをすぐに実行する場合でも、様々な理由でジョブが開始できないとき(停電など)に備えて決まった猶予期間を指定できます。

猶予期間とは、スケジュールされたジョブを開始する際に最大許容遅延を定義する期間です。ジョブ・システムは、スケジュールされた時刻と、その時刻に猶予期間を足した時間と同じ時刻に、またはスケジュールされた時刻から猶予期間内に実行を開始できなかった場合、ジョブのステータスを「スキップ」に設定します。

- 1回(後で)

- カスタム・スケジュールの設定:
将来の指定した時間にジョブを実行するようにカスタム・スケジュールを設定できます。スケジュールにタイムゾーンを設定する場合、このタイムゾーンが指定した開始時間に達すると、ジョブはすべてのターゲットで同時に実行されます。各ターゲットのタイムゾーンを選択する場合、ジョブは管理対象ターゲットのタイムゾーンを使用してスケジュールされた時間で実行されます。選択したタイムゾーンは、ジョブに関する日時情報を「ジョブ・アクティビティ」ページ、「ジョブ実行」ページ、「ジョブ実行」ページなどに表示する場合に常に使用されます。

たとえば、合衆国西部(US太平洋時間)と合衆国東部(東部標準時間)にターゲットがあり、タイムゾーンがUS太平洋時間、開始時間が午後5時でスケジュールを指定した場合、ジョブは合衆国西部のターゲットに対して午後5時に実行され、同時に合衆国東部のターゲットに対して午後8時に実行されます。エージェントのタイムゾーンで午後5時を指定した場合、ジョブは同時に実行されません。合衆国東部のターゲットは3時間早く実行されます。

- 猶予期間の指定:
猶予期間は、ジョブが遅延した場合のジョブの直近の開始時間を制御します。ジョブが起動しない理由は多数ありますが、エージェントの停止またはブラックアウトがよくある理由です。デフォルトでは、ジョブは無期限の猶予期間でスケジュールされます。

ジョブは、猶予期間が終了する前ならいつでも起動できます。たとえば、猶予期間を1時間で午後1時にスケジュールされたジョブは、午後2時までならいつでも起動できますが、午後2時までに起動しなかった場合は、スキップ済とされます。

- 繰返し

- 繰返し間隔の定義:
ジョブの繰返し間隔を定義するには、「頻度タイプ(時間単位)」パラメータと「繰返し間隔(繰返し間隔)」パラメータを指定します。「繰返し期限」のオプションは次のとおりです。

終了の日時はどちらも最後の実行を決定します。たとえば、毎日午後6時に実行するジョブの場合は次のようになります。

このジョブの開始時間は、2010年6月1日の午後6時であり、
終了時間は2010年6月30日の午前4時です。

... 最後の実行は6月30日ではなく6月29日です。6月30日の終了時間は、毎日のジョブ実行時間よりも前になるためです。

- eart:
前述のスケジュール・タイプ1回の下にある猶予期間の説明を参照してください。

2. 「アクセス」プロパティ・ページ・リンクをクリックします。

タスク6   ジョブにアクセス可能なユーザーの指定(オプション)

ジョブを共有しないシステム・デフォルトを使用して進める場合、このページに入力する必要はありません。表には、ジョブに対して管理者とロールが持つアクセス権が表示されます。ジョブの「アクセス」ページで変更を加えることができるのはジョブ所有者(またはスーパー管理者)のみです。

1. 管理者およびロールのアクセス・レベルを変更するか、管理者およびロールを削除します。変更できる内容はユーザーの役割によって異なります。
ジョブ所有者の場合、次の操作を実行できます。

- 管理者やロールのアクセスを変更するには、表の「アクセス・レベル」列で「完全」または「表示」アクセス権限を選択します。

- 管理者やロールのジョブに対するすべてのアクセス権を削除するには、管理者またはロールの「削除」列のアイコンをクリックします。スーパー管理者権限を持つすべての管理者には、ジョブに対する表示アクセス権限があります。ロールにアクセス権限を提供する場合、ロールには完全なアクセス権限ではなく、表示アクセス権限のみを提供できます。プライベート・ロールの場合、完全なアクセス権限を付与することができます。

スーパー管理者の場合、次の操作を実行できます。

- Enterprise Managerの他の管理者またはロールに表示アクセス権限を付与します。

- すべての管理者のアクセス権限を無効にします。

注意:
所有者もスーパー・ユーザーも、スーパー・ユーザーの表示アクセス権限を取り消すことはできません。すべてのスーパー・ユーザーには表示アクセス権限があります。

アクセス・レベルの詳細は、第10.3.2.3項「アクセス・レベルのルール」を参照してください。

2. 「追加」をクリックして管理者とロールを追加します。「ジョブの作成」→「管理者およびロールの追加」ページが表示されます。

1. 「検索」セクションで「名前」と「タイプ」を指定し、「実行」をクリックします。名前やタイプを指定せずに「実行」をクリックすると、管理リポジトリのすべての管理者とロールが表に表示されます。
「名前」フィールドに指定した値では大文字/小文字は区別されません。文字列のどの場所にも*または%をワイルドカード文字として指定できます(ワイルドカード文字は文字列の最後に暗黙的に追加されます)。たとえば、「名前」フィールドに%naを指定した場合、ANA、ANA2、CHRISTINAなどの名前を検索結果として「結果」セクションに返すことができます。

2. 「結果」セクションで管理者またはロールを1つ以上選択して「選択」をクリックし、ジョブへのアクセス権を付与します。ジョブの作成: アクセス・ページまたはジョブの編集: アクセス・ページに戻ります。このページでは、管理者およびロールのアクセスを変更できます。

3. 通知ルールを定義します。
通知システム(ルール作成)を使用して、特定のジョブと通知ルールを簡単に関連付けることができます。Cloud Control通知システムでは、ジョブが次のいずれかの選択状態になるとジョブ所有者に電子メールを送信する通知ルールを定義できます。

- スケジュール

- 実行中

- 一時停止

- 成功

- 問題

- アクション必須

注意:
通知を指定する前に、電子メール・アカウントと通知プリファレンスを設定する必要があります。詳細は、第3章「通知の使用」を参照してください。

タスク7   ジョブ作成の終了

この時点で、ジョブを発行して実行するか、ジョブをジョブ・ライブラリに保存できます。

- ジョブの送信:
「発行」をクリックして、アクティブなジョブを実行するためにジョブ・システムに送信します。その後、「ジョブ・アクティビティ」メイン・ページでジョブの実行ステータスを表示します。ライブラリ・ジョブを作成している場合、「発行」ボタンによりジョブがライブラリに保存され、メインの「ジョブ・ライブラリ」ページに戻ります。このページで、その他のライブラリ・ジョブの編集または作成が可能です。

問題(パラメータや資格証明が見つからないなど)があるジョブを発行すると、エラーが表示され、アクティブなジョブを発行する前に問題を修正する必要があります。ライブラリ・ジョブの場合、不完全な仕様が許可されるため、エラーは発生しません。

注意:
アクセス権を変更せずに「発行」をクリックする場合、スーパー管理者のみがジョブを表示できます。

- ライブラリへのジョブの保存:
「ライブラリに保存」をクリックして、頻繁に使用されるジョブのリポジトリとしてのジョブ・ライブラリにジョブを保存します。他の管理者は、アクセス権限が提供される場合、ライブラリ・ジョブの共有や再利用が可能です。アクティブ・ジョブと同様に、特定の管理者に表示権限または完全なアクセス権限を付与できます。さらに、ジョブ・ライブラリを使用して次の内容を保存できます。

- ジョブの基本定義、さらにターゲットおよびその他のカスタム設定(ジョブ発行前に追加可能)。

- 自身で再利用、または他のユーザーと共有するためのジョブ。ジョブへの表示アクセス、または完全なアクセス権限を付与し、ジョブを共有できます。

- 後から再発行するクリティカル・ジョブ。または、問題が発生した場合に修正されたジョブ。

10.3.2.1 単一操作の指定

注意:
次の情報は、タスク3「パラメータの指定」の手順2に適用されます。

「コマンド」フィールドに完全なコマンドを入力します。次に例を示します。

/bin/df -k /private

単一操作の指定については次の点に注意してください。

- コマンドの一部として、シェル・コマンドを使用できます。プラットフォームのデフォルトのシェル(Linuxでは/bin/sh、Windowsではcmd/c)が使用されます。

ls -la /tmp > /tmp/foobar.out

- 2つの連続したシェル・コマンドを実行する必要がある場合、「コマンド」フィールドでシェルを起動し、「OSスクリプト」フィールドでコマンド自体を起動する必要があります。「コマンド」フィールドでは次のように指定します。

sleep 3; ls

- ジョブ・ステータスは、コマンドによって返された終了コードに依存します。コマンドの実行が0を返す場合、ジョブは「成功」のステータスを返します。その他の値を返す場合は、「失敗」のジョブ・ステータスを返します。

10.3.2.2 スクリプトの指定

注意:
次の情報は、タスク3「パラメータの指定」の手順2に適用されます。

「OSスクリプト」フィールドに指定する値が、コマンド・インタプリタでstdinとして使用されます。デフォルトは、Linuxの場合は/bin/shであり、Windowsの場合はcmd/cです。別のインタプリタでここの値をオーバーライドすることもできます。たとえば、%perlbin%/perlなどです。シェル・スクリプト・サイズは2GBまでに制限されています。

最大出力サイズを制御するには、MGMT_PARAMETERSのmgmt_job_output_size_limitパラメータを必要な制限に設定します。10KB未満の値や2GBよりも大きな値は無視されます。デフォルトの出力サイズは10MBです。

ジョブ・ステータスは、スクリプトの最後のコマンドによって返された終了コードに依存します。最後のコマンドの実行が0を返す場合、ジョブは「成功」のステータスを返します。その他の値を返す場合は、「失敗」のジョブ・ステータスを返します。適切な例外処理をスクリプトに実装して、適切な場合はゼロ以外の終了コードを返す必要があります。このようにすると、スクリプトが失敗したにもかかわらずジョブによって「成功」ステータスが報告されるという状況が回避されます。

スクリプトは次のいくつかの方法で実行できます。

- OSスクリプト - 「OSスクリプト」フィールドでスクリプトにパス名を指定します。次に例を示します。
「OSスクリプト」フィールド: /path/to/mycommand
「インタプリタ」フィールド:

- OSコマンドのリスト - LinuxまたはUNIXシステムの場合、次の例の標準シェル・コマンドの「インタプリタ」フィールドに入力する必要はありません。OSのデフォルトのシェル/bin/shまたはcmd/cが使用されます。

/usr/local/bin/myProg arg1 arg2
mkdir /home/$USER/mydir
cp /dir/to/cp/from/file.txt /home/$USER/mydir
/usr/local/bin/myProg2 /home/$USER/mydir/file.txt

シェルベースのジョブを発行する場合、使用する構文と選択するターゲットに注意してください。たとえば、このスクリプトはNTホストでは成功しません。

- インタプリタが必要なスクリプト - OSシェルがデフォルトで起動しますが、代替のインタプリタを指定してシェルを省略できます。たとえば、「OSスクリプト」フィールドにPerlスクリプトを指定し、「インタプリタ」フィールドにPerl実行可能ファイルの場所を指定するとPerlスクリプトを実行できます。
「OSスクリプト」フィールド: <Perlスクリプトのコマンドをここに入力>
「インタプリタ」フィールド: %perlbin%/perl

次の例は、特定のシェル構文に依存するコマンドのリストの実行方法を示しています。

setenv VAR1 value1
setenv VAR2 value2
/user/local/bin/myProg $VAR1 $VAR2

cshをインタプリタとして指定する必要があります。システム構成に応じて、「インタプリタ」フィールドに次の文字列を指定する必要があります。

/bin/csh

次の例に示すように、Windowsシェル・コマンドのリストにスクリプトを実行するオプションがあります。Windowsシステムの場合、デフォルトのシェルcmd/cが使用されます。

C:\programs\MyApp arg1 arg2
md C:\MyDir
copy C:\dir1x\copy\from\file.txt \home\$USER\mydir

10.3.2.3 アクセス・レベルのルール

注意:
次のルールは、タスク6「ジョブにアクセス可能なユーザーの指定(オプション)」に適用されます。

- スーパー管理者には、常にジョブに対する表示アクセス権限があります。

- ジョブを所有するEnterprise Manager管理者は、ジョブに対するアクセス権限を変更できます(スーパー管理者からの表示権限の取消しを除く)。

- ジョブに対して表示または完全アクセス・レベルを持つスーパー管理者は、新しいユーザーに表示(完全ではない)権限を付与できます。スーパー管理者は、通常のユーザーの完全権限および表示権限を取り消し、スーパー管理者の完全権限を取り消すこともできます。

- 完全アクセス・レベルを持つ通常のEnterprise Manager管理者は、ジョブに対するアクセス権限は変更できません。

- ジョブ所有者がジョブに対して類似作成操作を実行する場合、新しいジョブのすべてのアクセス権限は元のジョブと同じになります。ジョブ所有者が他の管理者の表示または完全ジョブ・アクセス権限を他の管理者に付与する場合、これらの管理者はそのジョブに対して類似作成操作を実行し、すべての管理者には新しく作成されたジョブに対する表示アクセス権限がデフォルトで保持されます。

10.3.3 SQLスクリプト・ジョブの作成

SQLスクリプト・ジョブを作成する基本プロセスは、第10.3.2項「OSコマンド・ジョブの作成」で説明するプロセスと同じです。次の項では、スクリプト・ジョブに固有の補足情報について説明します。

- ターゲットの指定

- パラメータ・ページのオプションの指定

- ホスト資格証明とデータベース資格証明の指定

- SQLスクリプト・ジョブからのエラー・コードの戻り

10.3.3.1 ターゲットの指定

SQLスクリプト・ジョブはデータベースとクラスタ・データベースのターゲット・タイプに対して実行できます。ジョブを実行するターゲットを選択するには、次の手順を実行します。

1. 「ターゲット」セクションで「追加」をクリックします。

2. ポップアップでデータベース・ターゲットを選択します。

選択内容が「ターゲット」表に表示されます。

注意:
クラスタ・ホストまたはRACデータベースの場合、データベース・インスタンスの数にかかわらず、ジョブがターゲットに対して実行されるのは一回のみです。そのため、RACクラスタのすべてのノードでジョブを実行することはできません。

10.3.3.2 パラメータ・ページのオプションの指定

SQLスクリプト・ジョブでは、「パラメータ」プロパティ・ページの「SQLスクリプト」フィールドで次の内容を指定できます。

- SQL*Plusでサポートされるディレクティブ

- SQLスクリプト自体の内容

- 完全修飾SQLスクリプト・ファイル。たとえば、次のようになります。

@/private/oracle/scripts/myscript.sql

スクリプト・ファイルがすべてのターゲットの適切な場所にインストールされていることを確認します。

- SQL*Plusでサポートされる構文を使用したPL/SQLスクリプト。たとえば、次のいずれかになります。

EXEC plsql_block;

または

DECLARE
local_date DATE;
BEGIN
SELECT SYSDATE INTO local_date FROM dual;
END;
/

「SQLスクリプト」フィールドのターゲット・プロパティを使用できます。このリストは「ターゲット・プロパティ」表に表示されます。ターゲット・プロパティの大文字と小文字は区別されます。SQL*Plusのオプション・パラメータを 「パラメータ」 フィールドに入力できます。

10.3.3.3 ホスト資格証明とデータベース資格証明の指定

「資格証明」プロパティ・ページで、ホスト資格証明とデータベース資格証明を指定します。管理エージェントは、ホスト資格証明を使用してSQL*Plus実行可能ファイルを起動し、データベース資格証明でターゲット・データベースに接続してSQLスクリプトを実行します。ジョブは、ホストとデータベースに対して優先資格証明を使用するか、優先資格証明よりも優先される他の資格証明を指定できます。

- 優先資格証明の使用:
SQLスクリプト・ジョブのターゲットに対して優先資格証明を使用する場合はこのオプションを選択します。ホストとデータベースの両方に使用される資格証明は、ドロップダウンで指定した資格証明になります。「通常データベース資格証明」を選択する場合、通常のデータベース優先資格証明が使用されます。「SYSDBAのデータベース資格証明」を選択する場合、SYSDBA優先資格証明が使用されます。どちらの場合も、データベース・ターゲットに関連付けられたホスト資格証明が使用されます。ジョブを実行するたびに、優先資格証明の現在の値が取得されます。

- 名前付き資格証明:
すべてのターゲットに対して優先資格証明を上書きする場合はこのオプションを選択し、すべてのターゲットでジョブが使用する名前付き資格証明を入力します。

多くのIT組織ではパスワードを定期的に変更することが求められます。このオプションを使用して、すべての優先資格証明のパスワードを変更できます。Enterprise Managerは実行時に資格証明の現在の値(ユーザー名およびパスワード)を使用するため、優先資格証明を使用するジョブおよび修正処理は新しく変更された値を自動的に取得します。また、名前付き資格証明は集中管理されます。名前付き資格証明の変更は、その資格証明を使用するすべてのジョブまたは修正処理に伝播されます。

修正処理の場合、優先資格証明を指定すると、Enterprise Managerは修正処理を編集した最後のEnterprise Managerユーザーの優先資格証明を使用します。このため、1番目のユーザーが最初に指定した修正処理を編集しようとする場合、Enterprise Managerでは、その修正処理に使用される資格証明を別のユーザーが指定する必要があります。

10.3.3.4 SQLスクリプト・ジョブからのエラー・コードの戻り

SQLスクリプト・ジョブは、内部的にSQL*Plusを使用して、ユーザーのSQLまたはPL/SQLスクリプトを実行します。SQL*Plusが0を返す場合、ジョブは「成功」のステータスを返します。その他の値を返す場合は、「失敗」のジョブ・ステータスを返します。デフォルトでは、SQLスクリプトを実行し、エラーが発生している場合でも、SQL*Plusが値0を返すために、ジョブ・ステータスが「成功」になることがあります。このようなジョブで「失敗」ステータスを返すには、SQL*PlusのEXITを使用してゼロ以外の値を返します。

次の例は、PL/SQLまたはSQLスクリプトから値を返す方法を示しています。これらは、SQL*Plusの戻り値として順番に使用されるため、適切なジョブ・ステータス(「成功」または「失敗」)を返す方法が示されます。EXITコードを返す場合の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

例1

WHENEVER SQLERROR EXIT SQL.SQLCODE
select column_does_not_exist from dual;

例2

-- SQL*Plus will NOT return an error for the next SELECT statement
SELECT COLUMN_DOES_NOT_EXIST FROM DUAL;

WHENEVER SQLERROR EXIT SQL.SQLCODE;
BEGIN
-- SQL*Plus will return an error at this point
SELECT COLUMN_DOES_NOT_EXIST FROM DUAL;
END;
/
WHENEVER SQLERROR CONTINUE;

例3

variable exit_code number;

BEGIN
DECLARE
local_empno number(5);
BEGIN
-- do some work which will raise exception: no_data_found
SELECT 123 INTO local_empno FROM sys.dual WHERE 1=2;
EXCEPTION
WHEN no_data_found THEN
:exit_code := 10;
WHEN others THEN
:exit_code := 2;
END;
END;
/
exit :exit_code;

10.3.4 マルチタスク・ジョブの作成

マルチタスク・ジョブを作成する基本プロセスは、第10.3.2項「OSコマンド・ジョブの作成」で説明するプロセスと同じです。次の項では、マルチタスク・ジョブに固有の補足情報について説明します。

- ジョブの機能

- マルチタスクのジョブのターゲットの設定

- ジョブへのタスクの追加

10.3.4.1 ジョブの機能

マルチタスクのジョブを使用し、1つ以上の別個のタスクから構成される複雑なジョブを作成できます。マルチタスクのジョブは同じタイプまたは異なるタイプのターゲットに対して実行できるため、同じタイプまたは異なるタイプの1つ以上のターゲットに対して非定型操作を実行できます。

ジョブ・システムのマルチタスク機能により、非常に複雑な操作を簡単に作成できます。すべてのタスクが単一のターゲットで実行されるマルチタスクのジョブを作成できます。各ジョブのジョブ・タイプが異なり、各タスクが別のターゲット・タイプで動作する複数のタスクで構成されるマルチタスクのジョブも作成できます。次に例を示します。

- タスク1(ジョブ・タイプはOSコマンド)はホスト1に対して動作します。

- タスク1が成功すると、タスク2(ジョブ・タイプはSQLスクリプト)をデータベース1およびデータベース2に対して実行します。

10.3.4.2 マルチタスクのジョブのターゲットの設定

マルチタスクのジョブは、タスクとして使用可能なジョブが定義されるターゲットに対して実行できます。すべてのジョブ・タイプをタスクとして使用できるわけではありません。

「一般」ページの「ターゲット」ドロップダウンでは、すべてのタスクに対する同じターゲット、または異なるタスクに対する別のターゲットに対してジョブを実行できます。マルチタスクのジョブの各タスクは完全なジョブとみなされるため、「すべてのタスクに対して同じターゲット」オプションを選択すると、ジョブが「一般」ページから実行されるすべてのターゲットを追加します。「異なるタスクに対して別のターゲット」オプションを選択した場合、各タスクの定義どおりにタスクが実行されるターゲット(および必要な資格証明)を指定します。

「ターゲット」ドロップダウンで選択した後、「ターゲット」セクションの「追加」をクリックしてジョブを実行するターゲットを選択します。

10.3.4.3 ジョブへのタスクの追加

「タスク」ページを使用して次の操作を実行できます。

- 各種ジョブ・タイプのタスクの追加、削除、編集

- タスク条件および依存ロジックの設定

- タスクのエラー処理の追加

「条件」オプションと「依存先」オプションを設定するには、少なくとも2つのタスクを定義する必要があります。タスク条件は、タスクが実行される状態を定義します。条件オプションは次のとおりです。

- 常時 - ジョブの実行のたびにタスクが実行されます。

- 成功時 - タスク実行は、別のタスクの実行が成功するかどうかに依存します。

- 失敗時 - タスク実行は、別のタスクの実行が失敗するかどうかに依存します。

エラー処理タスクは、多くの場合、ジョブの一部の状態を取り消すことができる「クリーンアップ」手順になります。マルチタスク・ジョブのタスクにエラーが発生した場合、エラー・ハンドラ・タスクが実行されます。エラーは深刻な失敗であり、通常はジョブ・システムがタスクを実行できません。通常、失敗は、タスクが実行したが正常に終了しなかったことを示します。エラー処理タスクによって、ジョブの実行ステータスが影響を受けることはありません。エラー処理に使用されるタスクのジョブ・タイプを指定するには、「タスク・タイプの選択」ページを使用します。

10.4 ジョブ・ステータスの表示と分析

すべてのジョブの集計ステータスの表示

ジョブの発行後、すべてのターゲットに対するすべての個別ジョブ実行は自動的にロールアップされ、「エンタープライズ・サマリー」ページで参照できるようになります。図10-2に、「エンタープライズ・サマリー」ページの下部にある「ジョブ」セクションを示します。

図10-2 「エンタープライズ・サマリー」ページのターゲット・ジョブのサマリー

この情報は、何百、何千というシステムに対しジョブを実行する場合には特に重要となります。失敗した個別ジョブ実行を特定することもできます。特定の個別実行に関連付けられた数字をクリックすると、ドリルダウンして失敗したジョブの詳細を参照できます。

特定のジョブの一般ステータスの表示

特定のジョブまたは送信済ジョブの一般ステータス情報を表示するには、図10-1に示すジョブ・アクティビティ・ページでジョブを検索します。

ジョブ実行のステータスの表示

単一実行または複数実行についての詳細情報を表示できます。単一実行には単一の手順と複数の手順があります。

実行のステータスを表示するには次の手順を実行します。

1. 「ジョブ・アクティビティ」ページで、対象のジョブの「名前」リンクをクリックします。「ジョブ実行」ページが表示されます。

2. ジョブ実行サマリーの表示以外に、特定のタスクをドリルダウンして詳細情報を表示できます。

拡張ビューへの切替え

Cloud Controlのバージョン12.1.0.4から、1つのページで複数のドリルダウンのビューを組み合せた、ジョブ実行のビューを起動できるようになりました。拡張ビューを有効化するには、次のコマンドを実行します。

emctl set property -name oracle.sysman.core.jobs.ui.useAdfExecutionUi -value true

標準ビューに戻すには、次のコマンドを実行します。

emctl set property -name oracle.sysman.core.jobs.ui.useAdfExecutionUi -value false

注意:
これらのコマンドはOMSの再起動を必要としません。

単一実行によるジョブ実行の拡張ステータスの表示

単一実行には単一の手順と複数の手順があります。単一実行のステータスを表示するには次の手順を実行します。

複数実行によるジョブ実行の拡張ステータスの表示

複数実行のステータスを表示するには次の手順を実行します。

1. 「ジョブ・アクティビティ」ページで、複数実行を含むジョブの「名前」リンクまたは「ステータス」リンクをクリックします。
「ジョブ実行」ページが表示されます。

2. 左側の表で、対象の実行をクリックします。
特定の実行の詳細がページの右側に表示されます。

10.5 ジョブ・イベント基準の生成

ジョブ・システムは、ジョブがその実行ステータスを変更したときにステータス変更イベントを発行し、これらのイベントは実行ステータスに基づいて異なる重大度を持ちます。

「ジョブ・イベント生成基準」ページ(図10-3)を使用して、ジョブ・イベント通知のターゲットを設定します。このページでは、イベントまたは通知を発生させる対象のジョブ、ターゲットまたはステータスを決定できます。これにより、ユーザーは有効なイベントのみを発生できます。このページで行う設定によって、ジョブの動作が変更されることはありません。インシデント・ルール・セットを使用してジョブ・イベントに関する通知を設定できます。

このページにアクセスするには、「設定」メニューから「インシデント」、「ジョブ・イベント」の順に選択します。

図10-3 「ジョブ・イベント生成基準」ページ

10.5.1 ジョブ・ステータス、ステータス重大度およびターゲットのないジョブのイベントの有効化

ジョブ・ステータスとターゲットのないジョブのイベントを有効化するには、次の手順を実行します。

1. イベントを生成するジョブ・ステータスを選択するために、スーパー管理者権限があることを確認します。

2. ターゲットを追加するためのターゲット表示権限を持つ管理者であることを確認します(スーパー管理者によって設定されたジョブ・ステータスに関して、このターゲットに対してイベントを生成します)。

3. スーパー管理者としてCloud Controlにログインします。

4. 「設定」メニューで「インシデント」、「ジョブ・イベント」の順に選択します。ジョブ・イベント生成基準ページが表示されます。

5. 「ジョブ・イベント生成基準」ページで次の手順を実行します。

1. 「ジョブ・ステータスのイベントを有効化します」リージョンで、イベントを発行するステータスを選択します。

2. 「ステータス重大度のイベントの有効化」リージョンで、クリティカル・ステータス、情報ステータス、またはその両方についてのイベントを有効にするかどうかを選択します。

3. ターゲットと関連付られていないジョブのイベントを作成する場合は、「ターゲットのないジョブのイベントを有効化します」セクションで「はい」を選択します。

4. 「ターゲットのイベント」セクションで「追加」をクリックし、ジョブ・イベントを有効にするターゲットを追加します。

6. 「適用」をクリックします。

10.5.2 ジョブ・ステータスのイベントを生成するためのターゲットの追加

ジョブ・ステータスを発行するイベントをスーパー管理者が選択したら、管理者はイベントを生成するためのターゲットを追加できます。ターゲットを追加して、ジョブ・ステータスのイベントを生成するには、次の手順を実行します。

1. スーパー管理者によって設定されたジョブ・ステータスに対して、イベントを生成するターゲットを追加するためのターゲット表示権限を持つ管理者であることを確認します。

2. 管理者としてCloud Controlにログインします。

3. 「設定」メニューで「インシデント」、「ジョブ・イベント」の順に選択します。ジョブ・イベント生成基準ページが表示されます。

4. 「ジョブ・イベント生成基準」ページで次の手順を実行します。

1. 「ジョブ・ステータスとターゲットのないジョブのイベント」セクションで、イベントを発行可能なステータスを確認できます。また、ターゲットのないジョブのフィルタに対してイベントが有効になっているかどうかも確認できます。

2. 「ターゲットのイベント」セクションで「追加」をクリックして、ジョブ・イベントを有効にするターゲットを追加します。「削除」をクリックすることで、ジョブ・イベントを有効にしないターゲットを削除することもできます。

注意:
「ターゲットのイベント」セクションで選択した設定はグローバルに適用されます。イベントのターゲットを追加または削除すると、他のEnterprise Managerユーザーにも影響します。

5. 「適用」をクリックします。

10.6 ジョブ・ステータス変更イベントのイベント・ルールの作成

Enterprise Managerでは、ルールを作成して、イベント、インシデントおよび問題に適用することができます。ルールが適用されるのは、新規作成または更新されたイベント、インシデントまたは問題が、ルールに定義された条件と一致するときです。ジョブ・ステータス変更イベントのイベント・ルールを作成する方法を次に説明します。

- ジョブのジョブ・ステータス変更イベント・ルールの作成

- ターゲットのジョブ・ステータス変更イベント・ルールの作成

10.6.1 ジョブのジョブ・ステータス変更イベント・ルールの作成

ジョブのジョブ・ステータス変更イベント・ルールを作成するには、次の手順を実行します。

1. 関連するジョブ・ステータスが有効になっていることと、必要なターゲットがジョブ・イベント生成基準に追加されていることを確認します。

2. ジョブ・ステータス変更イベントのイベント・ルールを作成するための管理者権限があることを確認します。

3. 管理者としてCloud Controlにログインします。

4. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール・ページが表示されます。

5. インシデント・ルール・ページで、「ルール・セットの作成」をクリックしてインシデントのルールを作成します。

6. 「名前」と「説明」を指定し、「有効」を選択してルール・セットを有効にします。すべてのEnterprise Managerにルールを設定する場合は、タイプとして「エンタープライズ」を選択します。特定のユーザーのみに対してルールを設定する場合は「プライベート」を選択します。「適用先」で「ジョブ」を選択します。

「ジョブ」タブで「追加」をクリックし、イベント・ルールを作成するジョブを追加します。

7. 「ジョブの追加」ダイアログ・ボックスで、「パターン別」でジョブを選択する場合は、「類似ジョブ名」を指定して「ジョブ・タイプ」を選択します。「類似ジョブ所有者」を指定します。「特定のジョブ」の選択では、ジョブを選択します。「OK」をクリックします。

8. 「ルール」タブで「作成」をクリックします。
表示される「作成するルールのタイプを選択」ダイアログ・ボックスで、作成するルール・セットに応じて次の項目から選択できます。

- 「受信イベントおよびイベントの更新」。通知を受信するか、ジョブ・ルールのインシデントを作成します。イベントに対して処理する場合(たとえば、ジョブ失敗などの受信イベントに対して、インシデントの作成やユーザーへの通知を行う場合)は、このオプションを選択します。

- 「新たに作成されたインシデントおよびインシデントの更新」。インシデントの生成対象のイベントに関連付けられたルールがなくても、通知を受信するか、インシデントのルールを作成します。作成済のインシデントまたは新規作成されるインシデントに対して処理する場合(たとえば、特定のグループfooに関連するすべてのインシデントを特定のユーザーに送るか、オープンしている期間が3日を超えたすべてのインシデントを昇格する場合)は、このオプションを選択します。

- 「新たに作成された問題および問題の更新」。問題が生成された対象のインシデントに関連するルールがなくても、通知を受信するか、問題のルールを作成します。このオプションはジョブには適用されません。

9. 「受信イベントおよびイベントの更新」を選択し、「新規ルールの作成: イベントの選択」ページで、次の手順を実行します。

1. 「選択基準」の「タイプ」を「ジョブ・ステータスの変更」にします。選択したジョブのすべてのジョブ・ステータス変更イベントに対して、アクションを実行する場合は、「タイプジョブ・ステータスの変更のすべてのイベント」を選択します。特定のジョブ・ステータスに対してのみアクションを実行する場合は、「タイプジョブ・ステータスの変更の特定のイベント」を選択します。「タイプジョブ・ステータスの変更の特定のイベント」を選択した場合は、ルールを作成するイベントのジョブ・ステータスを選択します。

2. 次の図に示されているように、ルールを設定するための他の基準を設定します。

10. インシデントに関連付けられたイベントに通知ルールがなくても、インシデントのためのルールを作成する場合は、「新たに作成されたインシデントおよびインシデントの更新」を選択します。「新規ルールの作成: インシデントの選択」ページで、次のいずれかを選択します。

- 「すべての新しいインシデントおよび更新されたインシデント」(新しいインシデントと更新されたインシデントすべてにルールを適用する場合)

- 「すべての新しいインシデント」(すべての新しいインシデントにルールを適用する場合)

- 「特定のインシデント」(インシデントの基準も選択)

11. 「新規ルールの作成: アクションの追加」ページで、「追加」をクリックしてアクションをルールに追加します。

12. 「条件付きアクションの追加」ページで、イベントがルールを満たしたときに実行するアクションを指定します。
「アクションの条件」セクションで次のいずれかを選択します。

- 「常にアクションを実行」(イベントに関係なくアクションを実行する場合)

- 「指定された条件に一致する場合のみアクションを実行」(特定の基準と一致するときにアクションを実行する場合)

イベントにアクションを追加するときは、次の項目を指定します。

- イベントのインシデントを作成して解決方法を管理および追跡するには、「インシデントの作成」を選択します。

- 「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。

- イベントを生成した問題が解決された後でイベントをクリアする場合は、「イベントのクリア」セクションで「完全にクリア」を選択します。

- イベント接続を構成している場合は、「イベント・コネクタに転送」セクションでイベントをサードパーティのイベント管理システムに送信できます。

インシデントにアクションを追加するときは、次の項目を指定します。

- 「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。

- 「インシデントの更新」セクションで、インシデントの発生時に優先順位を決定するための詳細を指定します。「割当て先」、「優先度の変更」、「ステータスの設定」および「エスカレート先」の詳細を指定します。

- チケット・デバイスを構成している場合は、「チケットの作成」セクションで、チケットを作成するための詳細を指定します。

「続行」をクリックします。

13. 名前と説明の指定ページで、イベント・ルールの「名前」と「説明」を指定します。「次」をクリックします。

14. 「確認」ページでイベント・ルールに選択した詳細を確認し、「続行」をクリックすると、このルールがルール・セットに追加されます。

15. 「ルール・セットの作成」ページで「保存」をクリックして、ルール・セットを保存します。

10.6.2 ターゲットのジョブ・ステータス変更イベント・ルールの作成

ターゲットのジョブ・ステータス変更イベント・ルールを作成するには、次の手順を実行します。

1. 関連するジョブ・ステータスが有効になっていることと、必要なターゲットがジョブ・イベント生成基準に追加されていることを確認します。

2. ジョブ・ステータス変更イベントのイベント・ルールを作成するための管理者権限があることを確認します。

3. 管理者としてCloud Controlにログインします。

4. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール・ページが表示されます。

5. インシデント・ルール・ページで、「ルール・セットの作成」をクリックしてインシデントのルールを作成します。

6. 「名前」と「説明」を指定し、「有効」を選択してルール・セットを有効にします。すべてのEnterprise Managerにルールを設定する場合は、タイプとして「エンタープライズ」を選択します。特定のユーザーのみに対してルールを設定する場合は「プライベート」を選択します。「適用先」で「ターゲット」を選択します。

「ターゲット」タブで次のいずれか1つを選択します。

- すべてのターゲットに適用する場合は、「すべてのターゲット」を選択します。「除外されたターゲット」セクションで「追加」をクリックし、ルール・セットから除外するターゲットを検索して選択します。「選択」をクリックします。

- ルール・セットを適用するターゲットのタイプを選択する場合は、「タイプのすべてのターゲット」を選択します。

- ターゲットを個々に指定する場合は、「特定のターゲット」を選択します。「グループ」または「ターゲット」のどちらを追加するかを選択して、グループまたはターゲットを追加し、「追加」をクリックして、ルール・セットを適用するターゲットを検索および選択します。「選択」をクリックします。「除外されたターゲット」セクションで「追加」をクリックし、ルール・セットから除外するターゲットを検索して選択します。「選択」をクリックします。

7. 「ルール」領域の「作成」をクリックします。

8. 「作成するルールのタイプを選択」ダイアログ・ボックスで、作成するルール・セットに応じて次の項目から選択します。

- 「受信イベントおよびイベントの更新」。通知を受信するか、ジョブ・ルールのインシデントを作成します。イベントに対して処理する場合(たとえば、ジョブ失敗などの受信イベントに対して、インシデントの作成やユーザーへの通知を行う場合)は、このオプションを選択します。

- 「新たに作成されたインシデントおよびインシデントの更新」。インシデントの生成対象のイベントに関連付けられたルールがなくても、通知を受信するか、インシデントのルールを作成します。作成済のインシデントまたは新規作成されるインシデントに対して処理する場合(たとえば、特定のグループfooに関連するすべてのインシデントを特定のユーザーに送るか、オープンしている期間が3日を超えたすべてのインシデントを昇格する場合)は、このオプションを選択します。

- 「新たに作成された問題および問題の更新」。問題が生成された対象のインシデントに関連するルールがなくても、通知を受信するか、問題のルールを作成します。このオプションはジョブには適用されません。

9. 「受信イベントおよびイベントの更新」を選択し、「新規ルールの作成: イベントの選択」ページで、次の手順を実行します。

- 「選択基準」の「タイプ」を「ジョブ・ステータスの変更」にします。選択したジョブのすべてのジョブ・ステータス変更イベントに対して、アクションを実行する場合は、「タイプジョブ・ステータスの変更のすべてのイベント」を選択します。特定のジョブ・ステータスに対してのみアクションを実行する場合は、「タイプジョブ・ステータスの変更の特定のイベント」を選択します。「タイプジョブ・ステータスの変更の特定のイベント」を選択した場合は、ルールを作成するイベントのジョブ・ステータスを選択します。

- この図のように、ルールを設定するための他の基準を設定します。

10. インシデントに関連付けられたイベントに通知ルールがなくても、インシデントのためのルールを作成する場合は、「新たに作成されたインシデントおよびインシデントの更新」を選択します。「新規ルールの作成: インシデントの選択」ページで、次のいずれかを選択します。

- 「すべての新しいインシデントおよび更新されたインシデント」(新しいインシデントと更新されたインシデントすべてにルールを適用する場合)。

- 「すべての新しいインシデント」(すべての新しいインシデントにルールを適用する場合)。

- 「特定のインシデント」(インシデントの基準も選択)。

11. 「新規ルールの作成: アクションの追加」ページで、「追加」をクリックしてアクションをルールに追加します。

12. 「条件付きアクションの追加」ページで、イベントがルールを満たしたときに実行するアクションを指定します。
「アクションの条件」セクションで次のいずれかを選択します。

- 「常にアクションを実行」(イベントに関係なくアクションを実行する場合)

- 「指定された条件に一致する場合のみアクションを実行」(特定の基準と一致するときにアクションを実行する場合)

イベントにアクションを追加するときは、次の項目を指定します。

- イベントのインシデントを作成して解決方法を管理および追跡するには、「インシデントの作成」を選択します。

- 「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。

- イベントを生成した問題が解決された後でイベントをクリアする場合は、「イベントのクリア」セクションで「完全にクリア」を選択します。

- イベント接続を構成している場合は、「イベント・コネクタに転送」セクションでイベントをサードパーティのイベント管理システムに送信できます。

インシデントにアクションを追加するときは、次の項目を指定します。

- 「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。

- 「インシデントの更新」セクションで、インシデントの発生時に優先順位を決定するための詳細を指定します。「割当て先」、「優先度の変更」、「ステータスの設定」および「エスカレート先」の詳細を指定します。

- チケット・デバイスを構成している場合は、「チケットの作成」セクションで、チケットを作成するための詳細を指定します。

「続行」をクリックします。

13. 名前と説明の指定ページで、イベント・ルールの「名前」と「説明」を指定します。「次」をクリックします。

14. 「確認」ページでイベント・ルールに選択した詳細を確認し、「続行」をクリックすると、このルールがルール・セットに追加されます。

15. 「ルール・セットの作成」ページで「保存」をクリックして、ルール・セットを保存します。

10.7 診断ツールの使用

次の各項では、ここに示す診断トピックのための手順について説明します。

- ジョブ・ロギングの有効化

- ジョブ・ロギングの表示

- 失敗したジョブのデバッグ

- 失敗したジョブに関連するインシデントの確認

- ジョブ・ステップで生成されるインシデントのパッケージ化

- リモート・ログ・ファイルの表示

- Cloud Control管理ツールによる問題の診断

10.7.1 ジョブ・ロギングの有効化

診断のために、オブジェクト・ロギングを有効化または無効化できます。

スケジュールされたジョブに関するジョブ・ロギングを有効化する手順は次のとおりです。

1. Cloud Controlコンソールの「エンタープライズ」メニューから「ジョブ」、「アクティビティ」の順に選択します。

2. 「上位アクティビティ」表で、記録するジョブの「名前」リンクをクリックします。

3. 表示された「実行」ページで、「アクション」メニューの「デバッグ」をクリックします。
「DEBUGレベルで正常にロギングが有効化されました」という確認メッセージが表示されます。

10.7.2 ジョブ・ロギングの表示

特定のジョブについてユーザーに表示可能なロギングがある場合は、次の手順を実行することでジョブ実行ログを表示できます。

1. 「上位アクティビティ」ページで、ログを表示するジョブの「名前」リンクをクリックします。「ジョブ実行」ページが表示されます。

2. ジョブ出力ログが表示されます

「ジョブ実行」ページの「ステータス」列に表示されるリンクをクリックし、「実行」ページの「ログ・レポート」をクリックすることで、次に示すとおり、「実行」ページからもジョブ・ロギングにアクセスできます。

ジョブ・ステップのログを表示するには、次の手順を実行します。

1. 「上位アクティビティ」ページで、ログを表示するジョブのリンクをクリックします。

2. 「ジョブ実行」表で、調べたいステップの「ステータス」列に表示されるリンクをクリックします。
ステップの「出力ログ」が表示されます。

10.7.3 失敗したジョブのデバッグ

実行に失敗し、事前にロギング・レベルとしてデバッグを設定していなかった場合、実行の再試行時にデバッグ・レベルの設定を選択できます。新規のジョブを実行する場合、「デバッグ」ボタンをクリックすることで、前もってデバッグ・レベルでのロギングを設定できます。オブジェクト・ロギング・フィールドには、ロギングがデバッグ・レベルで有効化されているかどうかが示されます。

失敗したジョブを検出した場合、次の手順を実行します。

1. 失敗したジョブ・ステップを表示します。

2. 失敗したステップの出力を確認します。すべてのステップのみでなく、特定のステップについても集計されたジョブ出力が表示されます。

3. 出力に失敗の理由が含まれない場合、ロギング出力を表示します。また、ジョブの実行時に発生したインシデントを確認することもできます。

4. 失敗の原因を確認し、問題を修正します。

5. デバッグ・モードを有効にしてから、ジョブを再発行します。
デバッグ・モードのチェック・ボックスが確認ページに表示されるのは、前回の実行がデバッグ・モードではなかった場合のみです。前回の実行がすでにデバッグ・モードであった場合、再試行の実行は自動的にデバッグ・モードになります。

10.7.4 失敗したジョブに関連するインシデントの確認

内部コード・エラー、深刻なスケーリングの問題、または他のEnterprise Managerの問題のために、ジョブが失敗する可能性があります。これらに関してインシデントまたはイベント証跡を調べることができます。たとえば、すべてのジョブ・ワーカーがスタックしたためにOMSがバウンスすると、多くのジョブが失敗します。ローダーで障害が発生した場合にも、一部のジョブが失敗します。

1. ジョブの時間枠内のインシデントまたはアラートを確認します。

- インシデントを確認するため、Cloud Controlコンソールの「エンタープライズ」メニューから「サマリー」を選択し、「エンタープライズ・サマリー」ページの「インシデント」セクションを表示します。
詳細は、「エンタープライズ」メニューから「監視」、「サポート・ワークベンチ」の順に選択します。

- アラートを確認するには

2. 関連するインシデントまたはイベント・データとともにサービス・リクエストを送信します。
特定のジョブに関するすべてのステップ出力、エラー出力、ロギング、リモート・ログ・ファイルおよびインシデント・ダンプ・ファイルが1つのインシデントについて取得されます。

- サービス・リクエストを送信するには、コンソールの「エンタープライズ」メニューから「My Oracle Support」を選択し、「サービス・リクエスト」を選択します。

- 技術的SRを作成するには、「サービス・リクエスト」ホームページの「SRの作成」をクリックします。問合せSRを作成するには、「問合せサービス・リクエスト」リージョンの一番上にある「「問合せ」SRの作成」をクリックするか、My Oracle Supportページの上部にある「問合せ」をクリックします。技術的サービス・リクエストを作成する場合、プロファイルに登録されているサポートIDに応じて、ハードウェアSRまたはソフトウェアSR (あるいはその両方)を作成できます。
サービス・リクエストの作成ウィザードでは、製品情報の指定プロセスを段階的に実行し、SRがOracleサポートにファイルされる際に、構成情報をSRに添付します。Oracleサポートに最新の正しいターゲット情報があるようにするには、「ステップ1: 問題」の「問題は何ですか。」セクションで、「構成」タブを選択してからターゲットを選択してください。

3. サポートから提供されるパッチを適用します。

- 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

- ログイン資格証明を指定し、「実行」をクリックします。

- このページの詳細は、オンライン・ヘルプを確認してください。

4. パッチが適用されたら、再度ジョブを送信してみます。

インシデントをパッケージングするか、インシデントを手動でトリガーするには、次の手順に従います。

1. サポート・ワークベンチにアクセスします。

2. ジョブ関連のすべてのダンプおよびログ・ファイルとともに同時期の他のデータを収集し、サポートに送るためにパッケージングします。

3. 関連するエラーを検索しながらサポート・ワークベンチでインシデント関連のデータを確認します。

4. サポートの介入なしで根本原因を特定できたら、ジョブを修正して再発行します。

10.7.5 ジョブ・ステップで生成されるインシデントのパッケージ化

インシデント(およびそこに含まれる問題)は、デフォルトではパッケージ化されていません。重要で関連性のある問題をサポート・ワークベンチでパッケージ化する必要があります。すべての問題をパッケージ化するか、または一部のみをパッケージ化するかを選択できます。

注意:
リモート・ログ・ファイルを使用するジョブがインシデントに含まれる場合、そのリモート・ログファイルは、パッケージ化の過程で自動的にインシデントに含められます。リモート・ログ・ファイルの詳細は、第10.7.6項「リモート・ログ・ファイルの表示」を参照してください。

ジョブ・ステップで生成されるインシデントをパッケージ化するには、次の手順に従います。

1. 「ログ・レポート」ページで、「インシデントID」リンクをクリックします。

2. サポート・ワークベンチの「インシデントの詳細」ページで「問題キー」リンクをクリックします。

3. サポート・ワークベンチの「問題の詳細」ページで、「問題のパッケージ化」リンクまたは次に示す「クイック・パッケージ」ボタンのいずれかをクリックし、「クイック・パッケージ」ウィザードとオンライン・ヘルプの手順に従います。

10.7.6 リモート・ログ・ファイルの表示

一部のジョブまたはProvisioning Adviser Framework (PAF)のプロシージャによって、DBCAやインストーラのような外部コマンドが実行されます。このようなコマンドによって、専用のログ・ファイルがシステムのローカルとこれらを実行したOracleホームに生成されます。

リモート・ログファイルを表示するには、次の手順に従います。

1. 「上位アクティビティ」ページで、ログを表示するジョブのリンクをクリックします。

2. 「ジョブ実行」表で、ジョブの「ログ・レポート」をクリックします。

3. 「ログ・レポート」ページで、「リモート・ログ・ファイル」リンクをクリックします。

4. ホスト資格証明を指定し、「OK」をクリックします。
リモート・ファイル・ビューアにファイルの内容が表示されます。

10.7.7 Cloud Control管理ツールによる問題の診断

コンソールのCloud Control管理部分は、ジョブ・システムの現在の状態を評価し、最適なパフォーマンスのための適切なアクションを判断できるように支援するいくつかのツールを提供します。これらのツールはすべてCloud Controlコンソールの「設定」メニューからアクセス可能です。

次の各項では、使用可能な各ツールについて説明します。

10.7.7.1 状態の概要

1. Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。

2. 「状態の概要」サブメニューを選択します。

「状態の概要」ページの「ジョブ・システム・ステータス」リージョンに、次の情報が表示されます。

- ステップ・スケジューラ・ステータス
ジョブ・ステップ・スケジューラは、実行準備ができているジョブ・ステップを処理します。ジョブ・ステップ・スケジューラが警告モードまたはエラー・モードで実行中であることがステータスに示される場合、ジョブ・システムは正常に機能していません。この場合、ジョブ・システムをフェイルオーバー・モードで実行することができ、ジョブ・ステップ・スケジューラによって定期的に実行されるタスクをジョブ・ディスパッチャ・プロセスが実行することもできます。ただしジョブ・システムは、本来の能力よりも低い状態で実行されている場合があるため、この状況の解決は有益です。

次のようなメッセージが表示される場合があります。

- ステップスケジューラのためのDBMS_SCHEDULERジョブが見つかりません
このメッセージは非常にまれであり、通常は潜在的に重大な問題を示します。ジョブが不注意または特別な処理によって削除された場合があります。

(パッチのインストール、たとえば、すべてのDBMS_SCHEDULERジョブを再利用する必要があります)。ここでは自動的な解決策はなく、ケース・バイ・ケースの対処が必要になります。

- ステータスのチェックが失敗しました
このようなことはほとんど発生しません。通常はエラー・メッセージが表示されます。このエラーがステータスを解釈できないことを示す場合は、自然に表示されなくなります。

- DBMS_SCHEDULERが無効です
環境で、すべてのDBMS_SCHEDULERジョブが無効になっています。インストールが進行中である場合を除き、発生しないはずです。DBMS_SCHEDULERプロセスを開始することで解決します。

- すべてのジョブ・キュー・プロセスが使用中です
DBMS_SCHEDULERプロセスがすべて使用されています。リポジトリRDBMSのパラメータjob_queue_processesを増やします。

- すべてのスレーブ・プロセスが使用中です
原因は前述の状況と同様です。この状況では、DBMS_SCHEDULERのMAX_JOB_SLAVE_PROCESSESを増やす必要があります。

- すべてのセッションが使用中です
DBMS_SCHEDULERに利用可能なRDBMSセッションがありません。RDBMSのPROCESSESを増やします。

- 遅延の理由が不明です
これは通常、前述の基準のいずれも満たさなかったために表示される、最も一般的な警告です。利用可能なワーカーよりも作業が多いために、ディスパッチャが過負荷であるだけの場合があります。この場合はバックログを確認します。この状況は自動的に解消されるはずですが、引続き残る場合は、ジョブ・システムに利用可能なワーカーの数がサイトで処理されたことのある負荷に対して不十分であることが考えられます。

- ジョブ・バックログ
ジョブ・バックログは、その予定時刻を過ぎてもまだ実行されていないジョブ・ステップの数を示します。この数が大きく、かつ長期間減少しない場合、ジョブ・システムは正常に機能していません。この状況は通常、ジョブ・エンジンのリソースが、システムまたはユーザー・アクティビティによるジョブの処理量を満たすことができない場合に発生します。

それらが長期間スタックされることによる特定ジョブの異常な処理のために、バックログが高くなる場合があります。スタック・ジョブのワーカー・スレッドに関する詳細は、次の手順を実行してください。

1. 「状態の概要」ページの「OMSとリポジトリ」メニューから「監視」、「診断メトリック」の順に選択します。

ジョブ・システムに長期間バックログがある場合、またはバックログを速く処理する場合、次のパラメータにemctl set propertyコマンドを設定できます。これらの設定は、より多くの負荷をサポートできる十分なデータベース・リソースがあることを前提としています。これらのパラメータは2 OMSノードのある大規模な構成で必要となる場合があります。

表10-1 大規模なジョブ・システムのバックログ設定

パラメータ

値

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のデータベースに設定するプロセスの増加が必要な場合があります。

10.7.7.2 リポジトリホームページ

1. Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。

2. 「リポジトリ」サブメニューを選択します。

「管理サービスとリポジトリ」ページの「リポジトリ・スケジューラ・ジョブ・ステータス」表に、ジョブ・システムのパージ・ステータスと次の実行スケジュールが表示されます。

10.7.7.3 管理サービスとリポジトリ: すべてのメトリック

「すべてのメトリック」ページへのアクセスには、2つのナビゲーション方法があります。

- 「設定」メニューから

- 「ターゲット」メニューから

「設定」メニューのナビゲーション

1. Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。

2. 「状態の概要」サブメニューを選択します。

3. 表示される「管理サービスとリポジトリ」ページで、「OMSとリポジトリ」メニューから「監視」を選択し、「すべてのメトリック」を選択します。

4. 左側ペインのDBMSジョブ・ステータスまでスクロールし、メトリックを選択します。

5. さらに下へスクロールし、「リポジトリ・ジョブ・スケジューラのパフォーマンス」を展開します。
利用可能なメトリックの定義は、次のとおりです。

- スケジューラが準備完了としてマークしたステップの平均数 — ジョブ・ステップ・スケジューラによって、実行の準備ができているとマークするように処理されたステップの平均数。通常、この数は、ある期間のジョブ・システムの負荷に依存します。

- 現在のジョブ・ステップ・バックログのクリアの推定時間 — 現在ジョブ・システムに流入する割合を想定してバックログをクリアするための推定時間。

- ジョブ・ステップ・バックログ — 予定時刻を過ぎてもまだ実行されていないジョブ・ステップの数。この数が大きく、かつ長期間減少しない場合、ジョブ・システムは正常に機能していません。この状況は通常、ジョブ・エンジンのリソースが、システムまたはユーザー・アクティビティによるジョブの処理量を満たすことができない場合に発生します。

- スケジューラがステップを準備完了としてマークする際の待機時間 — ジョブ・ステップ・スケジューラは、スケジュールされたステップを準備キューに移動します。このメトリックは、ステップを準備キューにマーキングする平均待機時間を示します。遅延が大きいということは、ジョブ・ステップ・スケジューラ・プロセスの機能が異常であることを示します。

- ジョブ・ステップ全体/秒 — ジョブ・システムが毎秒実行する平均ステップ数。

- スケジューラ・サイクル — dbmsスケジューラ・プロセスの頻度。1分間につき最低5サイクルを実行し、ジョブ・システムの負荷に応じて増やすことができます。数が少ない場合、通常はジョブ・ステップ・スケジューラ・プロセスでの問題を示します。

6. さらに下へスクロールし、「使用状況サマリー: ジョブ」のエントリを展開して、必要なメトリックを選択します。

「ターゲット」メニューのナビゲーション

1. Cloud Controlコンソールの「ターゲット」メニューから「すべてのターゲット」を選択します。

2. 「すべてのターゲット」ページの左側ペインで、下にスクロールして「内部」を展開し、「OMSとリポジトリ」を選択します。

3. 次のページの「OMSとリポジトリ」表のエントリをクリックします。

4. 表示される「状態の概要」ページの「OMSとリポジトリ」メニューから「監視」、「すべてのメトリック」の順に選択します。

10.7.7.4 OMSとリポジトリ: 診断メトリック

1. Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。

2. 「状態の概要」サブメニューを選択します。

3. 表示される「管理サービスとリポジトリ」ページで、「OMSとリポジトリ」メニューから「監視」を選択し、「診断メトリック」を選択します。

pbs_* メトリックは、ジョブ・システムでの問題の診断に適しています。スタック・ジョブ・システムのスレッドで詳細を調べる場合、またはジョブ・スレッドの使用状況の統計を詳細に調べて他のジョブの実行を妨げているアウトライアを判断する場合、この情報は有用です。

10.7.7.5 OMSとリポジトリ: チャート

1. Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。

2. 「状態の概要」サブメニューを選択します。

3. 表示される「管理サービスとリポジトリ」ページで、「OMSとリポジトリ」メニューから「監視」を選択し、「チャート」を選択します。

ジョブがステップを実行した場合、このページには、1秒当たりのアップロード・バックログ全体、ジョブ・ステップ・バックログ、ジョブ・ステップ全体についての履歴チャートが表示されます。

10.7.7.6 「管理サーバー」ページと「ジョブ・アクティビティ詳細」ページ

1. Cloud Controlコンソールの「ターゲット」メニューから「すべてのターゲット」を選択します。

2. グループ、システム、サービスの下の左側のペインで、「管理サーバー」をクリックします。

3. 「ターゲット名」表の「管理サーバー」をクリックします。
「ジョブ・システム」リージョンに、ジョブ・システムのスナップショットと処理された実行の詳細が表示されます。「最新のジョブ実行サマリー」表に、指定した期間内に実行される予定のユーザーの合計ジョブ実行、完了した件数、実行中の件数、完了も実行もされなかった実行の件数が表示されます。これは、様々なユーザー・ジョブがシステムで想定したとおりに実行されているかどうかの判断に役立ちます。

4. サマリー表の下の「詳細」リンクをクリックします。

5. 実行を開始したいタイミングについて、ドロップダウンで希望の時間枠を選択します。
ジョブとステータスが(ある場合は)表に表示されます。

6. 「ジョブ・ディスパッチャ」タブを選択します。
複数の管理サーバーが構成されている場合、ページに各管理サーバーのジョブ・ディスパッチャとスレッド・プールの使用率が表示されます。

- ディスパッチャ使用率(%) — ジョブ・ディスパッチャがジョブ・ステップを取得する頻度を測定します。利用率が高いということは、ジョブ・システムの負荷が高いことを示しています。

- スループット(ディスパッチされたステップ/分) — ディスパッチャによって1分当たりに処理される内部ステップ以外の平均ステップ数を示します。

- スレッド・プール使用率 — 各プールに構成された合計スレッド数、スレッド・プールで選択される1分当たりの平均ステップ、利用可能な平均スレッド数を示します。

10.7.7.7 ジョブ・システム・レポート

ジョブ・システムでは、診断レポートと使用状況レポートの両方を提供します。

診断レポート

1. Cloud Controlコンソールの「エンタープライズの設定」から「レポート」を選択します。

2. 「情報パブリッシャ・レポート」サブメニューを選択します。

3. 「タイトル」フィールドで「ジョブ」を検索し、「実行」をクリックします。

4. 表で「ジョブ・システム診断レポート」リンクをクリックします。

このレポートは、ジョブ・システムの状態の概要と、実行中ジョブまたはスケジュールされた時刻を過ぎていると考えられるジョブに関する診断情報を表示します。この情報は、通常、ジョブ・システムの問題を診断するOracleサポート・エンジニアにとって有用です。

使用状況レポート

このレポートを表示するには、手順4の「ジョブ使用状況レポート」リンクをクリックすることを除き、前述の手順に従います。

このレポートは、過去7日間のジョブ・システム使用状況の情報に関する概要を表示します。

10.8 修正処理の作成

修正処理を使用すると、メトリック・アラートおよびイベントに対する自動的なレスポンスを指定できます。修正処理により、メトリック・アラートに対して決められたレスポンスを自動的に実行できるため、時間を節約でき、エンド・ユーザーに対して顕著な影響が出る前に問題を処理できます。

修正処理にはジョブ・システムと共通する多くの機能があります。デフォルトでは、修正処理はメトリック・アラートがトリガーされたターゲット上で実行されます。この他の方法として修正処理を、各タスクが別のターゲットで実行されるような複数のタスクを含むように指定できます。修正処理の成功または失敗に対する通知を受け取ることもできます。

修正処理は、監視対象のターゲットに対する個々のメトリックについて定義します。次の各項では、修正処理の設定方法と、修正処理の実行の詳細を表示する手順について説明します。

- 資格証明の指定5

- メトリックに対する修正処理の作成

- ライブラリの修正処理の作成

- 修正処理のアクセスの指定

- 修正処理の通知の設定

- エージェント側のレスポンス処理の用意

- 修正処理の実行の詳細の表示

10.8.1 資格証明の指定

修正処理はターゲットのメトリックしきい値に関連付けられているため、修正処理を定義できるのは、そのターゲットに対してOPERATOR以上の権限を付与されている場合です。警告およびクリティカルのしきい値双方について、別々の修正処理を定義できます。修正処理は、特定のユーザーの資格証明を使用して実行する必要があります。そのため、修正処理を作成または変更する場合は、変更した処理を実行するための資格証明を常に指定する必要があります。

修正処理が管理グループに自動的に適用される監視テンプレート/テンプレート・コレクションの一部である場合、テンプレートを管理グループに関連付けているユーザーの優先資格証明が修正処理で使用されます。

10.8.2 メトリックに対する修正処理の作成

どのターゲットに関しても、「メトリックと収集設定」ページに、様々なメトリックの修正処理が設定されているかどうかが表示されます。メトリックごとに、「修正処理」列に、クリティカルまたは警告(あるいは両方)の重大度に対応する修正処理が設定されているかどうかが示されます。

1. 任意のターゲットのホームページ・メニューで、「監視」、「メトリックと収集設定」の順に選択します。「メトリックと収集設定」ページが表示されます。

ヒント:
たとえば、dadvmn0630.myco.comという名前のホストのホームページでは、「ホスト」メニュー→「監視」→「メトリックと収集設定」を選択します。

2. 特定のメトリックの鉛筆アイコンをクリックし、そのメトリックの「詳細設定の編集」ページにアクセスします。

3. 「修正処理」セクションで、修正処理を関連付ける対象のメトリック重大度(警告またはクリティカル)について「追加」をクリックします。

4. 「修正処理の追加」ページでタスク・タイプを選択し、「続行」をクリックします。

- ライブラリにある修正処理を使用する場合は、タスク・タイプとして「ライブラリから」を選択します。ライブラリ修正処理を使用すると、説明、パラメータおよび資格証明はライブラリ修正処理からコピーされます。新規の修正処理の名前は定義する必要があります。必要に応じて修正処理のパラメータを指定できます。

- ライブラリに格納する修正処理を作成する場合は、第10.8.3項「ライブラリの修正処理の作成」を参照してください。

- エージェント側のレスポンス処理を指定する場合は、「エージェント・レスポンス処理」をタスク・タイプとして選択します。詳細は、第10.8.6項「エージェント側のレスポンス処理の用意」を参照してください。

5. 「修正処理」ページで、ジョブを作成するときのように、「一般」、「パラメータ」および「資格証明」に入力します。

6. 「続行」をクリックして修正処理を保存して、「詳細設定の編集」ページに戻ると、修正処理が表示されます。

7. オプション: 修正処理の複数のインスタンスが同時に動作することがないように、「このメトリックに対する修正処理を1回のみ任意の時刻に実行することを許可」を有効にします。
このオプションでは、クリティカルまたは警告のいずれかの修正処理が実行中のときに、ある重大度がOracle Management Serviceにレポートされた場合、クリティカルと警告の両方の修正処理を実行しないことを指定します。このようなケースが発生するのは次の場合です。修正処理の実行が、修正対象のメトリックの収集間隔より長時間かかった場合、メトリック値はあるしきい値において前後(結果として、同一の修正処理が複数回実行される)するか、両方のしきい値を急速に上下(結果として、警告の修正処理がクリティカルの修正処理と重複する)します。

このオプションを選択しないと、前述した状況下で修正処理が複数回実行されます。管理者は、同時に実行される修正処理が競合しないようにする必要があります。

8. 修正処理の追加が終了したら、「続行」をクリックして「メトリックと収集設定」ページに戻ります。
このページの「修正処理」列に、メトリックに対して指定した修正処理が表示されます。表示される値:

- なし - このメトリックには修正処理が設定されていません。

- 警告 - このメトリックでは、警告アラートには修正処理が設定されていますが、クリティカル・アラートには設定されていません。

- クリティカル - このメトリックでは、クリティカル・アラートには修正処理が設定されていますが、警告アラートには設定されていません。

- 警告およびクリティカル - このメトリックでは、警告およびクリティカルの両方のアラートに修正処理が設定されています。メトリックにエージェント側のレスポンス処理が関連付けられている場合も、値は「警告およびクリティカル」になります。これは、クリティカルまたは警告のアラート重大度のいずれにも、必ずエージェント側のレスポンス処理がトリガーされるためです。

9. ステップ2以降のプロセスを続けてから、「メトリックと収集設定」ページで「OK」をクリックして修正アクションを保存し、ステップ1を開始したターゲット・ページに戻ります。

10.8.3 ライブラリの修正処理の作成

繰り返し使用する修正処理については、ライブラリの修正処理を定義できます。ライブラリに修正処理を保存すると、ターゲット・メトリックまたはポリシー・ルールの修正処理を定義する際に、保存した修正処理の定義を再利用できます。

1. 「エンタープライズ」メニューで「監視」、「修正処理」の順に選択します。「修正処理ライブラリ」ページが表示されます。

2. 「ライブラリ修正処理の作成」ドロップダウンでジョブ・タイプを選択し、「実行」をクリックします。

3. 第10.3項「ジョブの作成」でジョブを作成するときのように、「一般」、「パラメータ」および「資格証明」で修正処理を定義します。「アクセス」については、次のオプションの手順に進みます。

4. オプション: 「アクセス」を選択して、この修正処理に対する他のユーザーのアクセスを定義または変更します。
詳細は、第10.8.4項「修正処理のアクセスの指定」を参照してください。

5. 終了したら「ライブラリに保存」をクリックします。「修正処理ライブラリ」ページが再び表示されると、リストに修正処理が表示されます。
これで、この修正処理に基づいて別の修正処理を作成したり(「類似作成」ボタン)、この修正処理の編集または削除を行ったりすることができます。

このライブラリ・エントリを使用できるのは、メトリックの重大度について修正処理を定義するときです。「修正処理の追加」ページでタスク・タイプとして「ライブラリから」を選択してください。詳細は、第10.8.2項「メトリックに対する修正処理の作成」の手順4を参照してください。

10.8.4 修正処理のアクセスの指定

前の手順で説明したように、他のユーザーによる修正処理へのアクセスを決めることができます。修正処理を共有する予定がない場合、このページに入力する必要はありません。

10.8.4.1 アクセスの定義または変更

「アクセス」ページの表に、修正処理に対して管理者とロールが保持するアクセスが表示されます。修正処理の所有者(またはスーパー管理者)のみがこのページを変更できます。

修正処理の所有者は次の操作を実行できます。

- 「追加」をクリックし、次に表示されるページで適切なタイプを選択し、他の管理者およびロールを表に追加します。

- 管理者やロールのアクセスを変更するには、表の「アクセス・レベル」列で「完全」または「表示」アクセス権を選択します。

- 管理者またはロールについて「削除」列のアイコンをクリックし、管理者またはロールの修正処理に対するすべてのアクセスを削除します。スーパー管理者権限を持つすべての管理者には、修正処理に対する「表示」アクセス権があります。

ロールにアクセス権を提供する場合、ロールには完全なアクセス権ではなく、表示アクセス権のみを提供できます。

スーパー管理者の場合、次の操作を実行できます。

- Enterprise Managerの他の管理者またはロールに表示アクセス権限を付与します。

- すべての管理者のアクセス権限を無効にします。

注意:
新規ユーザーを作成している場合、そのユーザーが修正処理を作成するためにはCREATE_JOB権限を持つ必要があります。

10.8.4.2 アクセス・レベルのルール

アクセス・レベル・ルールを次に示します。

- スーパー管理者には、常にすべての修正処理に対する表示アクセス権限があります。

- 修正処理を所有するEnterprise Manager管理者は、修正処理に対するアクセス権限を変更できます(スーパー管理者からの表示権限の取消しを除く)。

- 修正処理に対して表示または完全アクセス・レベルを持つスーパー管理者は、新しいユーザーに表示(完全ではない)アクセス権限を付与できます。スーパー管理者は、通常のユーザーの完全アクセス権限および表示アクセス権限を取り消し、スーパー管理者の完全アクセス権限を取り消すこともできます。

- 完全アクセス・レベルを持つ通常のEnterprise Manager管理者は、修正処理に対するアクセス権限は変更できません。

- 修正処理の所有者が、ある修正処理について「類似作成」操作を実行する場合、新しい修正処理のすべてのアクセス権限は元の修正処理と同じになります。修正処理の所有者が、修正処理の表示または完全アクセス権限を他の管理者に付与し、それらの管理者のいずれかがその修正処理に対して類似作成操作を実行した場合、すべての管理者は新しく作成された修正処理に対する表示アクセス権限をデフォルトで保持します。

10.8.5 修正処理の通知の設定

修正処理はメトリックに関連付けられており、そのメトリックのアラートで起動します。ターゲットに対して表示以上の権限を持つEnterprise Manager管理者は、修正処理の成功または失敗の後で通知を受け取ることができます。

1つのインシデント・ルールには、アラートと修正処理の状態の任意の組合せが含まれます。インシデント・ルールによって選択されたメトリックおよびターゲットはすべて、同じアラートと修正処理の状態について通知されます。したがって、あるメトリックについては修正処理の成功または失敗に関する通知を希望し、別のメトリックについては失敗のみの通知を希望する場合、2つのインシデント・ルールを使用する必要があります。1つのインシデント・ルールに、修正処理が関連付けられていないメトリックの修正処理状態が含まれる場合があります。この場合、通知は送信されません。

注意:
ターゲットに対して適用されるインシデント・ルールの状態にかかわらず、エージェント側のレスポンス処理については通知を送信できません。

通知のインシデント・ルールを作成するには、次の手順を実行します。

1. 「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。

2. 「ルール・セットの作成」をクリックします。ルール・セットの作成ウィザードが表示されます。

3. 「ルール・セットの作成」ページの一番上で必要な情報を指定してから、「ターゲット」サブタブでターゲットの1つを選択し、「すべてのターゲットのタイプ」と「特定のターゲット」の選択に応じて必要な情報を指定します。

4. 「ルール」サブタブを選択し、「作成」をクリックします。

5. 表示されるポップアップで、デフォルトの「受信イベントおよびイベントの更新」を選択し、「続行」をクリックします。

6. 「イベントの選択」ページで、「タイプ」チェック。ボックスを選択し、「メトリック・アラート」を選択します。

7. 「タイプ・メトリック・アラートの特定のイベント」ラジオ・ボタンをクリックし、表示される表で「追加」をクリックします。

8. 表示されるポップアップで、「ターゲット・タイプ」を選択し、メトリックをフィルタ処理して選択し、重大度を選択します。次に、必要な修正処理ステータスを有効にします。「OK」をクリックします。

9. 「アクションの追加」ページで、「追加」をクリックします。

10. 「条件付きアクションの追加」ページの「基本通知」セクションで受信者を指定します。

11. ウィザードの最後の2ページの指示に従い、「続行」をクリックします。新しいルールが「ルール・セットの作成」ページに表示されます。

12. 「保存」をクリックしてこのルールを保存します。

1つまたは複数のルール・セットを作成したら、次のように通知メソッドを設定する必要があります。

1. 「設定」メニューで「通知」、「通知メソッド」の順に選択します。

2. 「通知メソッド」ページでは、「ヘルプ」、「Enterprise Managerヘルプ」の順に選択して、入力方法を確認してください。

10.8.6 エージェント側のレスポンス処理の用意

エージェント側のレスポンス処理では、アラートに応答する単純なコマンドが実行されます。メトリックで警告またはクリティカルのアラートが発せられると、管理エージェントで自動的に指定されたコマンドまたはスクリプトが実行されます(Oracle Management Service (OMS)との連携は必要ありません)。エージェントは、エージェント実行可能ファイルを所有するOSユーザーとしてこのコマンドまたはスクリプトを実行します。特定のターゲット・プロパティがエージェントのレスポンス処理スクリプトで使用される場合があります。

注意:
「エージェント側のレスポンス処理」ページを使用して、メトリックの警告またはクリティカルの重大度に達したときに実行される、単一コマンドライン処理を指定します。アラート・コンテキストが必要なタスクの場合は、より複雑なロジックを含めるか、成功または失敗時に通知を送信するように要求すると、エージェント側のレスポンス処理のかわりに修正処理が使用されます。

このページにアクセスするには、第10.8.2項「メトリックに対する修正処理の作成」の手順1から4に従います。

10.8.6.1 コマンドとスクリプトの指定

1つのコマンドの指定やスクリプトの実行も可能です。シェル・コマンド文字(>や<など)をレスポンス処理コマンドの一部として指定することはできません。これらの特別な文字タイプをレスポンス処理コマンドで指定する必要がある場合は、スクリプト内でその文字を使用してから、そのスクリプトをレスポンス処理コマンドで指定します。

スクリプトを使用する場合、必ず、エージェントが存在するホスト・マシン上にスクリプトをインストールするようにしてください。シェル・スクリプトを使用する場合、必ず、シェルを次のレスポンス処理コマンドラインで指定してください。

スクリプト/コマンド: /bin/csh myScript

もしくは、次のようなスクリプトの本体で指定してください。

スクリプト/コマンド: myScript

ここで、myScriptの内容は次のようになります。

!#/bin/csh<
<rest of script>

10.8.6.2 コマンドでのターゲット・プロパティの使用

コマンドでターゲット・プロパティを使用できます。「使用可能なターゲットのプロパティを表示」をクリックして、「スクリプト/コマンド」フィールドで使用できるターゲット・プロパティを表示します。使用可能なターゲット・プロパティのリストは、レスポンス処理を実行する対象のターゲットのタイプに応じて変わります。

ターゲット・プロパティをスクリプトまたはコマンドに対するコマンドライン引数として使用してから、これらのコマンドライン引数をスクリプトが参照するようにします。たとえば、%OracleHome%および%SID%のターゲット・プロパティを使用する場合、コマンドは次のようになります。

/bin/csh MyScript %OracleHome% %SID%

次に、ユーザーのスクリプトであるMyScriptがこれらのプロパティをコマンドライン引数として参照できます。次に例を示します。

IF $1 = 'u1/bin/OracleHome' THEN...

ターゲット・プロパティの大文字と小文字は区別されます。たとえば、管理エージェントのPerlインタプリタにアクセスする場合は、「スクリプト/コマンド」フィールドに%perlBin%/perl <my_perl_script>と指定できます。

10.8.6.3 拡張機能の使用

他のターゲット・プロパティは、OracleHome/sysman/admin/metadataディレクトリにあるターゲットのXMLファイルから入手できます。ここでOracleHomeというのは、ターゲットを監視中の管理エージェントのOracleホームを表します。XMLファイルで、DynamicProperties要素のPROP_LIST属性を検索して、ターゲットのtargets.xmlエントリには列記されていないプロパティのリストを取得します。

次の例は、hosts.xmlファイルからの引用です。

<InstanceProperties>
<DynamicProperties NAME="Config" FORMAT="ROW"
PROP_LIST="OS;Version;OS_patchlevel;Platform;Boottime;IP_address">
<ExecutionDescriptor>
<GetTable NAME="_OSConfig"/>
<GetView NAME="Config" FROM_TABLE="_OSConfig">
<ComputeColumn NAME="osName" EXPR="Linux" IS_VALUE="TRUE"/>
<Column NAME="osVersion"/>
<Column NAME="osPatchLevel"/>
<Column NAME="Platform"/>
<Column NAME="Boottime"/>
<Column NAME="IPAddress"/>
</GetView>
</ExecutionDescriptor>
</DynamicProperties>
<InstanceProperty NAME="Username" OPTIONAL="TRUE" CREDENTIAL="TRUE">
<ValidIf>
<CategoryProp NAME="OS" CHOICES="Linux"/>
</ValidIf>
<Display>
<Label NLSID="host_username_iprop">Username</Label>
</Display>
</InstanceProperty>
<InstanceProperty NAME="Password" OPTIONAL="TRUE" CREDENTIAL="TRUE">
<ValidIf>
<CategoryProp NAME="OS" CHOICES="Linux"/>
</ValidIf>
<Display>
<Label NLSID="host_password_iprop">Password</Label>
</Display>
</InstanceProperty>
</InstanceProperties>

10.8.7 修正処理の実行の詳細の表示

修正処理の実行結果を表示するには、2つの方法があります。

- インシデント・マネージャの方法

1. Enterprise Manager Cloud Controlコンソールの「Enterprise」メニューから、監視」、「インシデント・マネージャ」の順に選択します。

2. 「検索」アイコンをクリックし、タイプ・ドロップダウンから「イベント」を選択して「結果取得」をクリックします。

3. 検索結果の表で、関連するメッセージをダブルクリックします。
「修正処理履歴」表がページの下部に表示されます。

4. 履歴表で必要なメッセージを選択し、次に示す眼鏡アイコンをクリックします。

「修正処理の実行」ページに、修正処理、ステータス、開始時刻、終了時刻などの出力が表示されます。

- すべてのメトリックの方法

1. ターゲットのホームページで、「監視」、「すべてのメトリック」の順に選択します。

2. 左側のツリー・パネルから、必要なメトリックの名前をクリックします。
メトリック・アラートの行が、「メトリック・アラート履歴」表に表示されます。

3. 次に示す「詳細」列の眼鏡アイコンをクリックします。
「インシデント・マネージャイベントの詳細」ページが表示されます。

4. ページ下部の「修正処理履歴」表で、履歴表のメッセージを選択して眼鏡アイコンをクリックします。
「修正処理の実行」ページに、修正処理、ステータス、開始時刻、終了時刻などの出力が表示されます。

11 ターゲットに構成されたアクセス・ポイントのモニタリング

アクセス・ポイントは通信チャネルであり、これを使用して、ソフトウェアやハードウェア・デプロイメントをEnterprise Manager Cloud Controlでモニタリングします。これらはアップロード・ポイントであり、これを介してデータが収集され、Oracle Management Service (OMS)にアップロードされます。ほとんどのターゲットは単一のアクセス・ポイントですが、一部のターゲットには複数のアクセス・ポイントがあります。

この章では、アクセス・ポイントの概念およびマルチアクセス・ポイント・ターゲット(システム・インフラストラクチャ・サーバーやシステム・インフラストラクチャCiscoスイッチなど)に構成されたアクセス・ポイントのモニタリング方法について説明します。この章の具体的な内容は次のとおりです。

- アクセス・ポイントのモニタリングの概要

- ターゲットに構成されているアクセス・ポイント・リストの表示

- ターゲットに構成されたアクセス・ポイントの削除

- ターゲットの機能メトリック・マップの表示

- ターゲットにサポートされている様々な操作の最適なアクセス・ポイント・インプリメンタ(およびその履歴)の表示

- ターゲットに構成されたアクセス・ポイントのモニタリング・プロパティの変更または再構成

- ターゲットに構成されたアクセス・ポイントのモニタリング・プロパティの変更または再構成

- ターゲットに構成されたアクセス・ポイントを管理するためのEM CLI動詞

11.1 アクセス・ポイントのモニタリングの概要

アクセス・ポイントは通信チャネルであり、これを使用して、ソフトウェアやハードウェア・デプロイメントをEnterprise Manager Cloud Controlでモニタリングします。これらはアップロード・ポイントであり、これを介してメトリック・データが収集され、Oracle Management Serviceにアップロードされます。

通常、ソフトウェアのデプロイメントを検出して、Enterprise Manager Cloud Controlのターゲットとしてモニタリングするには、まず、ソフトウェアがデプロイされているホストにOracle Management Agent (管理エージェント)をインストールする必要があります。この場合、管理エージェントはソフトウェア・デプロイメントについてのデータを収集し、そのホスト上にあるソフトウェア・デプロイメントとの唯一の通信チャネルの役割を果たします。

ただし、一部のターゲットでは(たとえば、システム・インフラストラクチャ・サーバー、システム・インフラストラクチャCiscoスイッチ、システム・インフラストラクチャOracle InfiniBandスイッチおよびシステム・インフラストラクチャ・ラックなど)では、ターゲットに関するメトリック・データを収集する複数のアクセス・ポイントを持つことができます。アクセス・ポイントはハードウェアと統合されたチップ、ハードウェアにデプロイされたプラグインなども可能です。

特定のターゲット・タイプと対話するために使用される様々な管理インタフェースを区別するために、様々なアクセス・ポイント・タイプが使用され、通常各アクセス・ポイント・タイプには独自のメトリック実装およびターゲットに対する操作があります。

図11-1で、特定のマルチアクセス・ポイント・ターゲットについて、各アクセス・ポイントにメトリックのサブセットがどのように実装されるかを確認できます。メトリック名が赤色のアクセス・ポイントは、これらのメトリックのベスト・インプリメンタであることを示しています。メトリック名が青色のアクセス・ポイントは、これらのメトリックの2番目のベスト・インプリメンタであることを示しています。

図11-1 アクセス・ポイントの実装

Enterprise Manager Cloud Controlを使用すると、マルチアクセス・ポイント・ターゲットに構成されている、そのようなアクセス・ポイントのリストを表示できます。また、アクセス・ポイントの履歴ステータスや、アクセス・ポイントの機能マップ、特定タイプのメトリック・データの収集に最適なインプリメンタも表示できます。

注意:
マルチアクセス・ポイント・ターゲットが、明示的に、または、そのようなターゲットを含むグループがブラックアウトしていることでブラックアウトしている場合、マルチアクセス・ポイント・ターゲットとそのアクセス・ポイントはブラックアウトされ、Enterprise Manager Cloud Controlコンソールにおいて「ブラックアウト」ステータスに入ります。
他方、マルチアクセス・ポイント・ターゲットはブラックアウトしていないが、そのアクセス・ポイントがすべて、アクセス・ポイントをモニターしているすべての管理エージェント上での完全なホスト・ブラックアウトによってブラックアウトしている場合、そのターゲットのメトリック・データを収集できるアクセス・ポイントがないため、マルチアクセス・ポイント・ターゲットは「保留中」ステータスになります。これは特に、アクセス・ポイントが1つしかないマルチアクセス・ポイント・ターゲットの場合に当てはまります。1つのアクセス・ポイントだけがブラックアウトし、他のすべてのアクセス・ポイントがまだ利用できる場合は、他のアクセス・ポイントがメトリック・データを収集できるため、マルチアクセス・ポイント・ターゲットは引き続き稼働中と表示されます。

11.2 ターゲットに構成されているアクセス・ポイント・リストの表示

Enterprise Manager Cloud Controlを使用すると、マルチアクセス・ポイント・ターゲットに構成されているアクセス・ポイントのリストを表示できます。アクセス・ポイントは通信チャネルであり、これを使用して、ソフトウェアやハードウェア・デプロイメントをEnterprise Manager Cloud Controlでモニタリングします。これらはアップロード・ポイントであり、これを介してデータが収集され、Oracle Management Serviceにアップロードされます。

マルチアクセス・ポイント・ターゲットに構成されているアクセス・ポイントのリストを表示するには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. すべてのターゲット・ページで、マルチアクセス・ポイント・ターゲット(たとえば、システム・インフラストラクチャ・サーバー、システム・インフラストラクチャ・スイッチなど)を選択します。

3. ホームページのターゲット固有のメニューから、「モニタリング」、「アクセス・ポイント - 概要」の順に選択します。

4. アクセス・ポイント - 概要ページで、選択したマルチアクセス・ポイント・ターゲット用に構成されたアクセス・ポイントのリストを表示できます。

11.3 ターゲットに構成されているアクセス・ポイントの削除

Enterprise Manager Cloud Controlを使用すると、モニタリングに不要なアクセス・ポイントを削除できます。アクセス・ポイントは通信チャネルであり、これを使用して、ソフトウェアやハードウェア・デプロイメントをEnterprise Manager Cloud Controlでモニタリングします。これらはアップロード・ポイントであり、これを介してデータが収集され、Oracle Management Serviceにアップロードされます。

マルチアクセス・ポイント・ターゲットに構成されているアクセス・ポイントを削除するには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. すべてのターゲット・ページで、マルチアクセス・ポイント・ターゲット(たとえば、システム・インフラストラクチャ・サーバー、システム・インフラストラクチャ・スイッチなど)を選択します。

3. ホームページのターゲット固有のメニューから、「モニタリング」、「アクセス・ポイント - 概要」の順に選択します。

警告:

最後のアクセス・ポイントを削除すると、Enterprise Manager Cloud Controlからマルチアクセス・ポイント・ターゲットが削除されます。

4. アクセス・ポイント - 概要ページで、削除するアクセス・ポイントを選択して、「削除」をクリックします。

11.4 ターゲットの機能メトリック・マップの表示

Enterprise Manager Cloud Controlを使用すると、マルチアクセス・ポイント・ターゲットに構成されているアクセス・ポイントの機能マップを表示できます。アクセス・ポイントは通信チャネルであり、これを使用して、ソフトウェアやハードウェア・デプロイメントをEnterprise Manager Cloud Controlでモニタリングします。これらはアップロード・ポイントであり、これを介してデータが収集され、Oracle Management Serviceにアップロードされます。

アクセス・ポイントには、メトリック・データを収集する機能、またはターゲットにアクションを実行する機能のいずれかを設定できます。Enterprise Manager Cloud Controlでは、アクセス・ポイントの機能が表形式で表示されます。この機能マップを表示して、それぞれのアクセス・ポイントの効率のよい点を判断できます。

マルチアクセス・ポイント・ターゲットの機能メトリック・マップを表示するには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. すべてのターゲット・ページで、マルチアクセス・ポイント・ターゲット(たとえば、システム・インフラストラクチャ・サーバー、システム・インフラストラクチャ・スイッチなど)を選択します。

3. ホームページのターゲット固有のメニューから、「モニタリング」、「アクセス・ポイント - 現行の機能マップ」の順に選択します。

4. アクセス・ポイント - 現在の機能マップ・ページには、アクセス・ポイントのリストとそれぞれの機能が表示されます。詳細は、表11-1を参照してください。
「ベスト・インプリメンタのみ表示」を選択することで、どのアクセス・ポイントが、必要なメトリック・データの収集に最適なインプリメンタであるかも識別できます。

機能タイプや機能名で表をフィルタする場合は、「機能タイプ」および「機能名」ドロップダウン・リストを使用して、「検索」をクリックします。

表11-1は、現行の機能マップ表の列の説明です。

表11-1 機能マップ表の列の説明

列名

説明

アクセス・ポイント

マルチアクセス・ポイント・ターゲットに構成されているアクセス・ポイントの名前。

優先度

アクセス・ポイントのメトリック・データ収集機能の測定。優先度が最も高いアクセス・ポイントは、最初にメトリック・データを収集して、アップロードするものです。このアクセス・ポイントが利用できなくなると、優先度が次に高いアクセス・ポイントが引き継いで、メトリック・データを収集します。

機能タイプ

そのアクセス・ポイントがメトリック・データを収集できるか、ターゲットに対してアクションをとることができるか。可能な値は、「アクション」と「収集」です。

機能名

アクセス・ポイントが持っているメトリック収集機能またはアクション機能の名前。

現行のベスト・インプリメンタ

アクセス・ポイントが現行のベスト・インプリメンタであるかどうか。使用できる値は「Yes」または「No」です。

アクセス・ポイントには、メトリック・データを収集する機能、またはターゲットにアクションを実行する機能のいずれかを設定でき、2つ以上のアクセス・ポイントにそれらの機能を重複して設定できる場合もあります。特定のメトリックやアクションに最も適している場合、そのアクセス・ポイントを最適なインプリメンタと呼びます。

ステータス

アクセス・ポイントの層、およびそのアクセス・ポイントに対して収集機能が有効か無効か。

11.5 ターゲットでサポートされている様々な操作に最適なアクセス・ポイント・インプリメンタ(およびその履歴)の表示

Enterprise Manager Cloud Controlでは、アクセス・ポイントの機能が表形式で表示されるのみでなく、特定のメトリックまたはアクションに最適なインプリメンタまたは最もふさわしいとみなされたアクセス・ポイントがハイライト表示されます。

アクセス・ポイントは通信チャネルであり、これを使用して、ソフトウェアやハードウェア・デプロイメントをEnterprise Manager Cloud Controlでモニタリングします。これらはアップロード・ポイントであり、これを介してデータが収集され、Oracle Management Serviceにアップロードされます。アクセス・ポイントには、メトリック・データを収集する機能、またはターゲットにアクションを実行する機能のいずれかを設定でき、2つ以上のアクセス・ポイントにそれらの機能を重複して設定できる場合もあります。特定のメトリックやアクションに最も適している場合、そのアクセス・ポイントを最適なインプリメンタと呼びます。

最適なインプリメンタは、ターゲットの機能マップを変更するイベントが発生したときに決定されます。ターゲットの機能マップに影響を与えるイベントには、停止中のエージェント、停止中または破損しているアクセス・ポイント、異なる優先度をレポートしているアクセス・ポイントの機能メトリック、および新機能または削除された機能をレポートしている機能メトリックが含まれます。そのため、最適なインプリメンタと定義されているアクセス・ポイントをメトリックの収集に使用できない場合、Enterprise Manager Cloud Controlでは、次に最適なインプリメンタに自動的に切り換えて、同じメトリック・データを収集します。

マルチアクセス・ポイント・ターゲットに最適なアクセス・ポイント・インプリメンタを表示するには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. すべてのターゲット・ページで、マルチアクセス・ポイント・ターゲット(たとえば、システム・インフラストラクチャ・サーバー、システム・インフラストラクチャ・スイッチなど)を選択します。

3. ホームページのターゲット固有のメニューから、「モニタリング」、「アクセス・ポイント - 現行の機能マップ」の順に選択します。

4. アクセス・ポイント - 現在の機能マップ・ページには、アクセス・ポイントのリストとそれぞれの機能が表示されます。「ベスト・インプリメンタのみ表示」を選択します。リストをさらにフィルタし、最適なインプリメンタの履歴を表示するには、開始日付と終了日付を選択し、「検索」をクリックします。

11.6 ターゲットに構成されているアクセス・ポイントのモニタリング・プロパティの変更または再構成

Enterprise Manager Cloud Controlを使用すると、マルチアクセス・ポイント・ターゲットに構成されているアクセス・ポイントのリストを表示できます。アクセス・ポイントは通信チャネルであり、これを使用して、ソフトウェアやハードウェア・デプロイメントをEnterprise Manager Cloud Controlでモニタリングします。これらはアップロード・ポイントであり、これを介してデータが収集され、Oracle Management Serviceにアップロードされます。

マルチアクセス・ポイント・ターゲットの検出中、そのターゲットに構成されているアクセス・ポイントは、Enterprise Manager Cloud Controlに自動的に追加されてモニタリングされます。これらのアクセス・ポイントは、デフォルトのモニタリング構成プロパティで追加されます。ただし、必要な場合には、Enterprise Manager Cloud Controlへの追加後に、モニタリング・プロパティを変更または再構成することが可能です。

マルチアクセス・ポイント・ターゲットに構成されているアクセス・ポイントのモニタリング・プロパティを変更または再構成するには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. すべてのターゲット・ページで、マルチアクセス・ポイント・ターゲット(たとえば、システム・インフラストラクチャ・サーバー、システム・インフラストラクチャ・スイッチなど)を選択します。

3. ホーム・ページで、次のいずれかを実行します。

- ターゲット固有のメニューから、「モニタリング」、「アクセス・ポイント - 概要」の順に選択します。アクセス・ポイント - 概要ページで、モニタリング・プロパティを変更するアクセス・ポイントを選択して、「構成」をクリックします。

- ターゲット固有のメニューから「ターゲット設定」、「モニタリング構成」の順に選択します。

4. モニタリング構成ページの「アクセス・ポイント」ドロップダウン・リストで、適切なアクセス・ポイントが選択されていることを確認します。そうでない場合は、適切なアクセス・ポイントを選択します。

5. 「モニタリング・プロパティ」セクションで、プロパティを編集し、「保存」をクリックします。

11.7 ターゲットに構成されたアクセス・ポイントを管理するためのEM CLI動詞

表11-2に、ターゲットに構成されたアクセス・ポイントを管理するためのEM CLI動詞を示します。これらの動詞の詳細は、Oracle Enterprise Manager Cloud Controlコマンドライン・インタフェース・ガイドを参照してください。

表11-2 ターゲットに構成されたアクセス・ポイントを管理するためのEM CLI動詞

EM CLI動詞

説明

add_target

Enterprise Managerシステムにマルチアクセス・ポイント・ターゲットを追加します。

modify_target

Enterprise Managerシステム内にすでに存在するマルチアクセス・ポイント・ターゲットを変更します。

delete_target

マルチアクセス・ポイント・ターゲットを削除します。

get_accesspoints

ターゲットに構成されたアクセス・ポイントをリストします。

get_best_implementer

マルチアクセス・ポイント・ターゲットでサポートされている様々な操作に最適なアクセス・ポイント・インプリメンタをリストします。

set credentials

マルチアクセス・ポイント・ターゲットに構成されたアクセス・ポイントのモニタリング・プロパティを変更または再構成します。

12 Always-On Monitoring

Enterprise Manager Always-On Monitoringを使用すると、クリティカルなターゲット・ステータスとメトリック・アラートをモニタリングできます。このサービスはEnterprise Managerエージェントを介してクリティカル・ターゲットを継続的にモニタリングし、これらのイベントの電子メール通知を管理者に送信するように簡単に構成できます。

Always-On Monitoringはいつでも通知を送信するように構成できますが、アップグレードやパッチ適用などのメンテナンス操作のために、中央のEnterprise Managerサイトのダウンタイムが発生するときに特に役立ちます。

Always-On Monitoringは、モニタリングするターゲットの構成、および通知先や電子メールのゲートウェイ構成などの必須の通知データを再使用するために、Enterprise Managerと同期化されます。適切に構成および同期すると、サービスはEnterprise Managerエージェントからアラートを受信し、適切な管理者に電子メール通知を送信します。

この章の構成は、次のとおりです。

- ベスト・プラクティス

- Always-On Monitoringのインストール

- Always-On Monitoringの構成

- サービスの制御

- Always-On Monitoringの更新

- データ・メンテナンス

- Always-On Monitoring構成設定の制御

- パフォーマンス情報の取得

- 変更可能なAlways-On Monitoringのプロパティ

- 問題の診断

- 高可用性および障害時リカバリ

12.1 ベスト・プラクティス

Always-On Monitoringインスタンスは、Enterprise Managerが稼働中か停止中かに関係なく、常に実行することをお薦めします。Always-On Monitoringの通知をオフにすることによって、Enterprise Managerの稼働中にバックグラウンドで実行できます。計画されたものかどうかに関係なく、Enterprise Managerのダウンタイムの間に、emsctlコマンドを発行してAlways-On Monitoringの通知を再開できます。常にAlways-On Monitoringを実行する主な利点は、Enterprise Managerのインストールに加えられた変更が最新の状態に維持されることです。Always-On Monitoringは、定期的に同期ジョブを実行することによって、Enterprise Managerとの同期を維持します。このジョブはデフォルトでは24時間ごとに実行されますが、モニタリング対象の環境のニーズに合せてジョブの実行時間を変更できます。

バックグラウンドで定期的にAlways-On Monitoringを実行するのではなく、必要な場合にのみ実行することもできます。ただし、そのようにする場合は、Always-On MonitoringをEnterprise Manager OMSと同期することが必要になります。Enterprise Managerデプロイメントのサイズに応じて、同期してすべてのEnterprise Managerターゲットおよびメトリックに関する最新情報を取得するには10-15分かかることがあります。

重要:
Always-On MonitoringおよびEnterprise Managerは、Enterprise Managerが停止する前に同期する必要があります。

12.2 Always-On Monitoringのインストール

前提条件

Always-On Monitoringをインストールする前に、次の手順を実行する必要があります。

- Always-On Monitoringリポジトリを保持するOracle Databaseインスタンスのインストールまたは特定

- Always-On Monitoringリポジトリのユーザーの作成

- Enterprise ManagerリポジトリへのEMキーの保存

Javaの要件

- JAVAバージョン1.7がインストールされていることを確認します

- Always-On Monitoring (emscaを含む)が実行される環境にJDK7をインストールする必要があります。JAVA_HOME環境変数がJDK7の場所を指している必要があります。

12.2.1 Always-On Monitoringリポジトリ・データベースのインストール

Always-On Monitoringリポジトリを格納するOracle Databaseインスタンスをインストールまたは構成する必要があります。リポジトリのスキーマを個別に作成する必要があるため、スキーマに割り当てる必要がある領域と、領域の分類方法を判断することが重要になります。

Always-On Monitoringの目的はEnterprise Managerが停止しているときに継続的にモニタリングして通知を送信することであるため、Enterprise Managerリポジトリをアップグレードしているときや、予期せず停止したときにも、Always-On Monitoringが継続して実行されるように、Always-On Monitoringリポジトリ・データベースは、Always-On Monitoringスキーマを持つ別のOracleインスタンスとして、別のマシンにインストールする必要があります。

Enterprise Managerリポジトリと同様に、Always-On Monitoringが異なるインスタンスまたはマシンに存在する場合、Always-On Monitoringリポジトリをバンドル・パッチ10でOracle 12.1.0.2.0データベースにインストールする必要があります。

マルチテナント環境では、構成するプラガブル・データベース(PDB)のいずれかではなく、マルチテナント・コンテナ・データベース(CDB)にユーザーを作成する場合、接頭辞C##を付ける必要があります。

12.2.1.1 データベースのサイズ設定

データベースのサイズ設定および構成を行うときに考慮する要素は次のとおりです。

- UNDO表領域: SYNCプロセス、特に初回のSYNCを実行する場合、特にEnterprise ManagerインスタンスからAlways-On Monitoringに多数の行を転送するときにUNDO表領域が使用されます。

- TEMP表領域: 特に、データ移動プロセス中に索引が作成されたり、ソートが発生する場合に、SYNCプロセスでTEMP表領域も使用されます。

- Always-On Monitoring表領域: Always-On Monitoringに固有の表データおよび索引は、この表領域に格納されます。

- REDOログ: REDOログはSYNCの実行中に発生するチェックポイントの数を最小化するのに十分な大きさである必要があります。3 x 1 GBのREDOログ・ファイルを構成することをお薦めします。

- 特別なOracleパラメータ設定: Always-On Monitoringでは、特にAlways-On MonitoringスキーマがEnterprise Managerリポジトリ・データベースに移入される場合、Enterprise Managerリポジトリで使用されるパラメータを維持することが理想的です。SYNCおよびその他の主要なAlways-On Monitoring機能のテストによって、Enterprise Managerパラメータ設定がAlways-On Monitoringデータベースに対して適切であることが示されています。この事実は、異なるデータベース・インスタンスを構成するかどうかを考慮するために重要です。Enterprise Managerリポジトリの場合と同様、予期しないオプティマイザの問題を防止するために、Always-On Monitoringリポジトリに対して次のパラメータを設定する必要があります。

ALTER SYSTEM SET OPTIMIZER_ADAPTIVE_FEATURES=FALSE SCOPE=BOTH SID='*';

表1に、大規模なOPCデータベースに使用するAlways-On Monitoringスキーマでの、前述のコンポーネントのサイズ設定例を示します。これらの値は、Always-On MonitoringとEnterprise Managerの間での初回の完全同期後の表領域のサイズを表しています。また、REDOログ・ファイルはこれらの計算に含まれないことにも注意してください。

表12-1 Always-On Monitoring表領域の領域割当て

Always-On Monitoringリポジトリの領域消費

表領域名

使用済領域(MB)

空き領域(MB)

割当て合計(MB)

空き領域の割合(%)

TEMP

0

30,720

30,720

100%

EMS_TABLESPACE

6,430

44,797

51,200

87%

SYSAUX

1,385

85

1,470

6%

SYSTEM

896

4

900

0%

UNDOTBS1

84

30,636

30,720

100%

USERS

1

4

5

30%

合計

8.769

106,246

115,015

92%

この特定の構成では、必要なディスク領域の絶対最小値は、使用済表領域に基づいて9GBになりました。このスキーマで拡大のための領域を確保するには、新しいOracleインスタンスを作成する場合、Always-On Monitoringデータベース用の領域を120GB以上割り当てるように計画することをお薦めします。TEMP表領域とUNDO表領域は、TEMPまたはREDOの飽和の問題が発生しないよう、初回と後続の同期操作を処理するように構成されています。さらに、Always-On Monitoring表領域は、表領域の飽和による中断が発生しないようにサイズ設定されています。

現在の使用と将来の拡大に備えてAlways-On Monitoring表領域のサイズを正確に設定するには、次のことを理解することが重要です。

- Enterprise ManagerリポジトリからAlways-On Monitoringスキーマに、どの表のどのデータが転送されるか。

- 各表の転送される行数、表および索引の1行当たりのおおよそのバイト数。

表2は、Always-On Monitoringスキーマの表および索引のサブセットについて、行数、合計領域消費量および1行当たりのバイト数を示しています。

表12-2 Always-On Monitoringの表および索引領域の割当て

Always-On Monitoringの表および索引領域の割当ての例

owner

セグメント名

セグメント・タイプ

パーティション名

サイズ(MB)

行数

Always-On Monitoring

MGMT_TARGET_PROPERTIES

表

非パーティション化

1,472

15,408,952

Always-On Monitoring

MGMT_TARGET_PROPERTIES_IDX_02

索引

非パーティション化

1,152

15,215,316

Always-On Monitoring

MGMT_TARGET_PROPERTIES_PK

索引

非パーティション化

856

15,462,104

Always-On Monitoring

MGMT_TARGET_PROPERTIES_IDX_01

索引

非パーティション化

584

14,871,521

Always-On Monitoring

EM_MANAGEABLE_ENTITIES

表

非パーティション化

496

1,177,065

Always-On Monitoring

MGMT_TARGET_PROPERTIES_IDX_03

索引

非パーティション化

472

16,105,162

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_UK1

索引

非パーティション化

136

1,201,617

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_UK2

索引

非パーティション化

120

1,133,804

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX01

索引

非パーティション化

112

1,184,414

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX07

索引

非パーティション化

112

1,166,536

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX03

索引

非パーティション化

96

1,182,817

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX04

索引

非パーティション化

80

1,218,977

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX05

索引

非パーティション化

72

1,104,428

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX06

索引

非パーティション化

59

673,838

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX08

索引

非パーティション化

44

1,215,411

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_PK

索引

非パーティション化

41

1,172,101

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX09

索引

非パーティション化

40

1,192,236

Always-On Monitoring

EM_MANAGEABLE_ENTITIES_IDX02

索引

非パーティション化

37

1,178,410

Always-On Monitoring

EM_VIOLATIONS

表

非パーティション化

28

112,106

Always-On Monitoring

EM_METRIC_COLUMN_VER_PK

索引

非パーティション化

17

611,561

12.2.1.2 データベース文字セットの定義

Always-On MonitoringリポジトリがEnterprise Managerとは別のインスタンスにあるときに、Enterprise ManagerリポジトリからAlways-On Monitoringリポジトリに転送されるデータが、適切に格納および表現されることを確実にするには、2つのデータベース/インスタンス間で文字セットが一致していることを確認することが重要です。Enterprise Managerでは、NLS_CHARACTERSETがAL32UTF8として定義されます。

Oracleインストーラを使用して手動でAlways-On Monitoringインスタンスを設定する場合、インスタンスはデフォルトでWE8MSWIN1252になります。この時点で、適切な文字セットが開始からインストールされるよう、オプションのAL32UTF8がドロップ・ダウン・ボックスから選択されていることを確認します。

Enterprise Managerリポジトリで文字セットを特定するには、次の問合せを実行します。

SELECT * from nls_database_parameters where parameter='NLS_CHARACTERSET';

Always-On Monitoringリポジトリでもこの問合せを実行して、文字セットが一致していることを確認します。Always-On Monitoringリポジトリの文字セットが異なる場合は、Always-On Monitoringリポジトリの文字セットを変更してEnterprise Managerリポジトリのものと一致させることをお薦めします

--Shutdown and start the database in a restricted mode.
SHUTDOWN IMMEDIATE;
STARTUP RESTRICT;

--Set JOB_QUEUE_PROCESSES and AQ_TM_PROCESSES to its default value i.e.0
ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;

-- Set the required character set.
ALTER DATABASE CHARACTER SET AL32UTF8;

-- if the above fails:
ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8;

--Shutdown and restart the database in normal mode.
SHUTDOWN IMMEDIATE;
STARTUP;
/

12.2.2 Always-On Monitoringリポジトリ・ユーザーの作成

重要:
Always-On Monitoringリポジトリは、Enterprise Managerリポジトリ・データベース内に格納しないでください。Always-On Monitoringリポジトリを別のデータベースに格納すると、Enterprise Manager Repositoryが停止してもAlways-On Monitoringを実行できます。

Always-On Monitoringリポジトリとして使用するデータベースに接続してAlways-On Monitoringユーザーを作成し、そのユーザーに必要な権限を付与します。次に、このプロセスの例を示します。

SQL> create user ems identified by ems;
SQL> grant CREATE SESSION, ALTER SESSION, CREATE DATABASE LINK, CREATE MATERIALIZED VIEW, CREATE PROCEDURE, CREATE PUBLIC SYNONYM, CREATE ROLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE TABLE, CREATE TRIGGER, CREATE TYPE, CREATE VIEW, UNLIMITED TABLESPACE, SELECT ANY DICTIONARY to ems;
SQL> grant EXECUTE ON SYS.DBMS_CRYPTO to ems;
SQL> grant EXECUTE ON SYS.DBMS_AQADM to ems;
SQL> grant EXECUTE ON SYS.DBMS_AQ to ems;
SQL> grant EXECUTE ON SYS.DBMS_AQIN to ems;
SQL> grant EXECUTE on SYS.DBMS_LOCK to ems;
SQL> grant EXECUTE ON SYS.DBMS_SCHEDULER to ems;
SQL> grant create job to ems;

12.2.2.1 Always-On Monitoringスキーマ所有者への必要な権限の付与

Always-On Monitoringが適切に機能するには、Always-On Monitoringスキーマ所有者に適切な権限が必要です。次のサンプル・スクリプトは、Always-On Monitoringスキーマに必要なすべての権限の詳細を示しています。

grant CREATE SESSION,
ALTER SESSION,
CREATE DATABASE LINK,
CREATE MATERIALIZED VIEW,
CREATE PROCEDURE,
CREATE PUBLIC SYNONYM,
CREATE ROLE,
CREATE SEQUENCE,
CREATE SYNONYM,
CREATE TABLE,
CREATE TRIGGER,
CREATE TYPE,
CREATE VIEW,
UNLIMITED TABLESPACE,
SELECT ANY DICTIONARY to ems;
grant EXECUTE ON SYS.DBMS_CRYPTO to ems;
grant EXECUTE ON SYS.DBMS_AQADM to ems;
grant EXECUTE ON SYS.DBMS_AQ to ems;
grant EXECUTE ON SYS.DBMS_AQIN to ems;
grant EXECUTE on SYS.DBMS_LOCK to ems;
grant EXECUTE ON SYS.DBMS_SCHEDULER to ems;
grant create job to ems;

また、SQLコマンドラインから各grant文を実行することによって権限を付与することもできます。

SQL> grant CREATE SESSION, ALTER SESSION, CREATE DATABASE LINK, CREATE MATERIALIZED VIEW, CREATE PROCEDURE, CREATE PUBLIC SYNONYM, CREATE ROLE, CREATE SEQUENCE, CREATE SYNONYM, CREATE TABLE, CREATE TRIGGER, CREATE TYPE, CREATE VIEW, UNLIMITED TABLESPACE, SELECT ANY DICTIONARY to ems;
SQL> grant EXECUTE ON SYS.DBMS_CRYPTO to ems;
SQL> grant EXECUTE ON SYS.DBMS_AQADM to ems;
SQL> grant EXECUTE ON SYS.DBMS_AQ to ems;
SQL> grant EXECUTE ON SYS.DBMS_AQIN to ems;
SQL> grant EXECUTE on SYS.DBMS_LOCK to ems;
SQL> grant EXECUTE ON SYS.DBMS_SCHEDULER to ems;
SQL> grant create job to ems;

12.2.3 Always-On Monitoringのインストール

Always-On Monitoringは、Enterprise Managerソフトウェア・ディストリビューションとともに提供される自己完結型アプリケーション(sysman/emsディレクトリにある)で、Enterprise Managerの自己更新機能からも入手できます。いずれかのソースでAlways-On Monitoringのインストールzipファイル(ems_13.1.0.0.0.zip)を見つけ、Always-On Monitoringのインストール先として選択した場所に、そのファイルを置きます。

12.3 Always-On Monitoringの構成

Always-On Monitoringがインストールされると、Always-On Monitoring構成アシスタント・スクリプトを使用して、モニタリングするEnterprise Managerインストールと通信するようにサービスが構成されます。

Always-On Monitoringの構成手順は次のとおりです。

1. Always-On Monitoring構成アシスタント(EMSCA)の使用方法

2. Enterprise Managerでの電子メール・サーバーの構成

3. Enterprise Managerでの停止時連絡先の構成

4. Always-On MonitoringとEnterprise Managerの初回同期

5. Enterprise ManagerとAlways-On Monitoringの連動の構成

12.3.1 Always-On Monitoring構成アシスタント(EMSCA)の使用方法

Always-On Monitoring構成アシスタントは、Always-On Monitoringインストール・スクリプト・ディレクトリ下にあるスクリプトです。次の例は、環境変数EMS_HOMEを使用して参照される場所にAlways-On Monitoringがインストールされていることを前提としています。

$EMS_HOME/scriptsにある構成アシスタントを実行します。EMSCAはパラメータなしで起動でき、必要な情報を求めるプロンプトを表示します。構成が完了したら、後からEnterprise Managerの構成に使用するために、Always-On MonitoringアップロードURLを記録します。

例:

$ ./emsca
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Always-On Monitoring Repository Connection String : myserver:35074:semgc3
Create Always-On Monitoring Repository User [n] :
Always-On Monitoring Repository SYSDBA Username : sys
Always-On Monitoring Repository SYSDBA Password :
Always-On Monitoring Repository Username [ems] :
Always-On Monitoring Repository Password [ems] :
Enterprise Manager Repository Connection String : myserver:35074:semgc3
Enterprise Manager Repository Username : sysman
Enterprise Manager Repository Password :
Creating Always-On Monitoring repository user ems
Enter Enterprise Manager Middleware Home : $MW_HOME
Connecting to Always-On Monitoring repository.
Creating Always-On Monitoring repository schema
Creating repository storage for Targets data.
Creating repository storage for Alerts and Availability data.
Creating repository storage for Notification Metadata data.
Creating repository storage for Target Metric Metadata data.
Registering Always-On Monitoring instance
Always-On Monitoring Upload URL: https://myserver:8081/upload
Oracle PKI Tool : Version 12.1.3.0.0
Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved.

Certificate was added to keystore

Always-On Monitoringリポジトリを作成する場合は、次のコマンドを実行します。

$ ./emsca -createEmsDbUser=false
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Always-On Monitoring Repository Connection String : myserver:35074:semgc3
Always-On Monitoring Repository Username : ems
Always-On Monitoring Repository Password :
Enterprise Manager Repository Connection String : myserver:35074:semgc3
Enterprise Manager Repository Username : sysman
Enterprise Manager Repository Password :
Enter Enterprise Manager Middleware Home : $MW_HOME
Connecting to Always-On Monitoring repository.
Creating Always-On Monitoring repository schema
Creating repository storage for Targets data.
Creating repository storage for Alerts and Availability data.
Creating repository storage for Notification Metadata data.
Creating repository storage for Target Metric Metadata data.
Registering Always-On Monitoring instance
Always-On Monitoring Upload URL: https://myserver:8081/upload
Oracle PKI Tool : Version 12.1.3.0.0
Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved.

Certificate was added to keystore

必要な入力が含まれたレスポンス入力ファイルを使用して実行することもできます。次に、レスポンス入力ファイルの例を示します。

emsRepConnectString=localhost:1521:xe
emsRepUsername=ems
emsRepPassword=ems
emRepConnectString=mymachine.mycompany.com:15044:semgc3
emRepUsername=sysman
emRepPassword=sysman
#
emsPort=8081
http.protocol=http
#
#mw.home=$MW_HOME

注意:
mw.homeはデフォルトで、http.protocol=httpsを使用する場合にのみ必要です。emsPortはオプションで、Always-On Monitoringで使用するポートを指定できます。その他すべての値は必須です。

次の表に使用可能なEMSCAパラメータを示します。

表12-3 EMSCAパラメータ

EMSCAプロンプト

説明

Always-On Monitoringリポジトリ接続文字列

Always-On Monitoringリポジトリの検索に使用される接続文字列。有効なサービス記述子またはhost:port:sidの場合があります。

Always-On Monitoringリポジトリ・ユーザー名

Always-On Monitoringリポジトリに関連付けられたユーザー名。詳細は、「前提条件」を参照してください。

Always-On Monitoringリポジトリ・パスワード

Always-On Monitoringリポジトリ・ユーザーに関連付けられたパスワード。詳細は、「前提条件」を参照してください。

Enterprise Managerリポジトリ接続文字列

Enterprise Managerリポジトリの検索に使用される接続文字列。有効なサービス記述子またはhost:port:sidの場合があります。

Enterprise Managerリポジトリ・ユーザー名

Enterprise Manager SYSMANユーザーのユーザー名。

Enterprise Managerリポジトリ・パスワード

Enterprise Manager SYSMANユーザーのパスワード。

Enterprise Managerミドルウェア・ホーム

Enterprise Manager管理サービス(OMS)ミドルウェアがインストールされるミドルウェア・ホームへのパス。

注意: これは絶対パスである必要がありますが、環境変数を含むことができます。

ミドルウェア・ホームおよびその他のEnterprise Managerのインストール済コンポーネントの詳細は、『Oracle® Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

Enterprise ManagerリポジトリからのEMキーの削除

次のコマンドを実行してキーを削除します。

% emctl config emkey -remove_from_repos

Always-On Monitoringのアンインストール

次の例に示すように、必要に応じて、EMSCAを使用してAlways-On Monitoringをアンインストールできます。

$ ./emsca uninstall
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
---------------------------------------------------------------
Loading configuration from: /homedirectory/ems/conf/emsConfig.properties
Connecting to Always-On Monitoring repository.
Execute the following:
emctl delete property -name "oracle.sysman.core.events.ems.emsURL" -sysman_pwd <pwd> to unset the value of the property.
Uninstall completed.

12.3.2 Enterprise Managerでの電子メール・サーバーの構成

Always-On Monitoringが電子メール通知を送信する際、同期手順中にEnterprise Managerから取得する電子メール・サーバー構成を使用して送信します。Always-On Monitoringが適切に機能するには、Always-On Monitoringの同期を実行する前にEnterprise Managerで電子メール・サーバーを構成する必要があります。詳細は、「通知用のメール・サーバーの設定」を参照してください。

Enterprise Managerで電子メール・サーバー構成を変更した場合、Always-On Monitoringを再度同期して、更新された電子メール・サーバー構成を取得する必要があります。Always-On Monitoringの増分同期の実行については、後続の項を参照してください。

12.3.3 Enterprise Managerでの停止時連絡先の構成

Always-On MonitoringをEnterprise Managerと同期した後、モニタリング・サービスでは、OMSが停止したときに適切な管理者(停止時連絡先)に電子メール通知を送信できます。初めてAlways-On Monitoringを実行する前に、Enterprise Managerで停止時連絡先を構成する必要があります。Always-On Monitoringが通知を送信する停止時連絡先は、次のいずれかの形式にできます。

- グローバルな停止時連絡先

- ターゲット・プロパティに基づいたターゲット単位の停止時連絡先

- イベント・ルールに基づいたターゲット単位の停止時連絡先

電子メール・アドレスをグローバル形式とターゲット単位形式の両方に指定すると、すべての電子メール・アドレスが使用されます。

Enterprise Managerで停止時連絡先を変更した場合、Always-On Monitoringを再度同期して、更新された停止時連絡先構成を取得する必要があります。Always-On Monitoringの増分同期の実行手順は、後続の項を参照してください。

グローバルな停止時連絡先

グローバルな停止時連絡先は、Enterprise Managerサイトの単一のプロパティ・セットです。設定すると、すべてのターゲット・ステータス・イベントおよびすべてのターゲットのメトリック・アラームが、グローバルな停止時連絡先のプロパティで指定された受信者に送信されます。

% emcli set_oms_property -property_name='oracle.sysman.core.events.ems.downtimeContact'
-property_value='<email addresses>'

ターゲット・プロパティからのターゲット単位の停止時連絡先

これらの停止時連絡先の電子メール・アドレスは、各ターゲットの「停止時連絡先」ターゲット・プロパティで指定する必要があります。「停止時連絡先」ターゲット・プロパティを指定する方法は次の3つです。

- 各ターゲットで、ターゲットのホームページからアクセスできる「ターゲット・プロパティ」ページに移動します。ターゲット・ホームページの「ターゲット」メニューから、「ターゲット設定」を選択して「プロパティ」を選択します。「ターゲット・プロパティ」ページが表示されます。

「編集」をクリックして、「停止時連絡先」ターゲット・プロパティに電子メール・アドレスを指定します。カンマで区切ることによって、複数の電子メール・アドレスを指定できます。

- EM CLI set_target_property_value動詞を使用します。
emcli set_target_property_value -property_records="target_name:target_type:property_name:property_value"

例:

%./emcli set_target_property_value -property_records="myhost:host:Downtime Contact:John.Doe@mycompany.com"

set_target_property_value動詞の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』ガイドを参照してください。

- Enterprise Manager Cloud Controlのターゲット・ダウン・イベント・ルールの電子メール受信者を活用します。詳細は、次の項を参照してください。

イベント・ルールに基づいたターゲット単位の停止時連絡先

Always-On Monitoringは、各ターゲットの異なるユーザーに電子メール通知を送信することもできます。これらの連絡先は、ターゲットのイベント・ルールに基づいてEnterprise Managerで生成されます。このため、Enterprise Managerでイベント・ルールが変更された場合は、連絡先を再生成して増分同期を実行する必要があります。

イベント・ルール設定を活用することによって、「停止中」ステータスが選択された「ターゲット可用性」イベント・タイプに対するイベント・ルールの電子メール受信者に基づいて、停止時連絡先が生成されます。

注意:
停止時連絡先はターゲット可用性イベント・ルールのみを使用して生成されますが、Always-On Monitoringでは、ターゲット可用性とメトリックしきい値の両方のアラートの通知を送信します。

ターゲット可用性(ステータス停止中)イベント・ルールの受信者を確認および更新できます。これにより、EM CLIを使用するか、または停止時連絡先生成ジョブを発行することによって停止時連絡先のリストを生成できます。

EM CLIを使用した停止時連絡先の生成

EM CLIから、generate_downtime_contactコマンドを使用して、特定のターゲットの停止時連絡先を生成します。このコマンドは、特定のターゲットに影響するすべてのターゲット可用性ルールをシミュレートし、すべてのルールからの出力を含む電子メール・アドレス・リストを生成します。オプションの-setパラメータは、Always-On Monitoringの同期で連絡先を後で取得できるように、連絡先を保存します。

% emcli generate_downtime_contact -target_name=<name> -target_type=<type> -set

停止時連絡先のEnterprise Managerジョブの生成

% emcli create_job -input_file=property_file:<job_prop_file> -name="GenerateDowntimeContacts"

job_prop_fileは次の内容のプロパティ・ファイルを参照します。

# job type
type=CoreSetDowntimeContacts
# description
description=You job description
# target names, the list of target names
variable.target_names=host1,database2
# target types, the list of target types corresponding to the target list above
variable.target_types=host,oracle_database
# set on all targets, true to update contacts, false to print output but not save
variable.set_all_targets=true
# frequency to run job, refer to Enterprise Manager documentation for options
schedule.frequency=IMMEDIATE

注意:
EM CLIまたは停止時連絡先生成ジョブのいずれかによって停止時連絡先を生成するプロセスを実行すると、すぐにその連絡先をモニタリング・サービスで使用できるようになるわけではありません。これらの連絡先が更新されるたびに、別のAlways-On Monitoringの同期を実行する必要があります。

停止時連絡先によって取得されるアラートのタイプ

構成すると、Always-On Monitoringによって次の電子メール通知が送信されます。

- すべてのターゲット・ステータス・アラートおよびメトリック・アラート(クリティカル、警告およびクリア)。

- メトリック収集エラー(クリティカルおよびクリアの両方)。

ステータスがコンポーネント・メンバーのステータスに基づくグループやクラスタなどの集計ターゲットのターゲット・ステータス・アラートは、サポートされていません。かわりに、アラートは、これらの集計ターゲットの個々のメンバーに送信されます。

注意:
現在、サポートされている通知タイプは電子メール通知のみとなります。

電子メール受信者は、電子メール・アドレスにする必要があります。受信者は、グローバル・プロパティのdowntimeContactまたはターゲット単位の「停止時連絡先」を使用して指定されます。両方が指定されている場合、電子メールは指定されたすべての受信者に送信されます。

グローバル・プロパティdowntimeContactが指定されている場合、すべてのターゲットのすべてのアラートがグローバル・プロパティdowntimeContactで指定された受信者に送信されます。ターゲット単位のプロパティ「停止時連絡先」が指定されている場合は、そのターゲットのすべてのターゲット・ステータス・アラートとメトリック・アラートが、プロパティで指定された受信者に送信されます。

12.3.4 Always-On MonitoringとEnterprise Managerの初回同期

最初にAlways-On Monitoringを起動する前に、Always-On MonitoringとEnterprise Managerを同期する必要があります。同期によって、Enterprise Managerターゲットから通知構成と停止時連絡先がコピーされるため、Always-On Monitoringでアラートのモニタリングおよび電子メール通知の送信が可能になります。

Always-On MonitoringとEnterprise Managerの同期を実行するには、次の手順を実行します。

% $EMS_HOME/scripts/emsctl sync

Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Connecting to Always-On Monitoring repository.
Starting synchronization with Enterprise Manager.
Synchronizing with Enterprise Manager repository: sysman@myserver.myco.com:35074:semgc4
Synchronizing Targets data.
Synchronizing Alerts and Availability data.
Synchronizing Notification Metadata data.
Synchronizing Target Metric Metadata data.
Synchronization complete at : Thu Oct 22 06:50:56 PDT 2015

注意:
Enterprise Managerに変更を加えた場合、再度同期を実行する必要があります。たとえば、新しいホストまたはターゲットの追加、電子メール・サーバーの変更、停止時連絡先の変更を行った後、Always-On Monitoringで最新の構成を取得するには、増分同期が必要です。詳細は、「増分同期の手動実行」を参照してください。

12.3.5 Enterprise ManagerとAlways-On Monitoringの連動の構成

Always-On Monitoring構成の最後の手順として、Enterprise Managerを更新してサービスのアップロードURLを含めます。サービスの構成が正常に完了すると、Always-On Monitoring構成アシスタントによってアップロードURLが表示されます。Always-On Monitoring構成プロパティ・ファイルには、サービス向けに構成されたプロトコルおよびポートも含まれているため、アップロードURLは次の形式になります。

https://yourhostname:8081/upload

構成されたURLは、すべてのエージェント(既存エージェントおよび将来デプロイされるエージェントの両方)に送信されます。このため、構成を行う必要があるのは1回のみです。

HTTPSはAlways-On Monitoringのデフォルト・プロトコルで、デフォルト・ポートは8081です。構成値については、emscaまたはAlways-On Monitoring構成ファイルを参照してください。構成ファイルは次の場所にあります。

$EMS_HOME/conf/emsConfig.properties

Always-On Monitoringのアップロード場所を使用してEnterprise Managerを構成するには、Enterprise Managerから次のコマンドを実行する必要があります。

% emctl set property -name "oracle.sysman.core.events.ems.emsURL" -value "https://yourhostname:8081/upload" -sysman_pwd sysman

12.3.6 Enterprise ManagerでのAlways-On MonitoringアップロードURLの確認

次のコマンドを発行して、アップロードURLを特定できます。

%emsctl status

例:

$ ./emsctl status
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Always-On Monitoring Version : 13.1.0.0.0
Always-On Monitoring Home : /mycomputer/ems
Started At : December 4, 2015 8:07:12 AM PST
Last Repository Sync : December 4, 2015 8:06:10 AM PST
Upload URL : https://myserver:8081/upload
Always-On Monitoring Process ID : 28171
Always-On Monitoring Repository : myserver.myco.com:15044:sarview
Enterprise Manager Repository : myserver.myco.com:15044:sarview
Notifications Enabled : false
Total Downtime Contacts Configured : 1

emctl get propertyコマンドを使用して、OMSの設定を確認できます。

$AGENT_HOME/sysman/config/emd.proeprtiesを参照したり、EMS_URLを検索することによって、特定のエージェントの設定を確認できます。

12.4 EMキーの保存

Always-On Monitoringでは、Enterprise Managerリポジトリと同期して、Enterprise ManagerからSMTP (電子メール)ゲートウェイ構成情報を再使用できるようにするために、EMキーが必要です。

重要:
Always-On Monitoringを構成する前に、EmキーをEnterprise Managerリポジトリにコピーする必要があります。そうしないと、emscaの実行時にエラーが発生します。

Always-On Monitoringの構成が完了(emscaの実行が正常に完了)したら、すぐにEnterprise ManagerリポジトリからEMキーを削除します。注意: Always-On Monitoringを再起動する必要はありません。キーをリポジトリに格納するには、$MW_HOME/binディレクトリから次のemctlコマンドを実行します。$MW_HOMEはEnterprise Managerミドルウェア・ホーム・ディレクトリです。

% emctl config emkey -copy_to_repos

Always-On Monitoring構成が完了したら、次のコマンドを実行してキーを削除します。

% emctl config emkey -remove_from_repos

12.5 サービスの制御

Always-On Monitoringの起動:

% $EMS_HOME/scripts/emsctl start
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Starting Always-On Monitoring.
Notifications Enabled : false
Total Downtime Contacts Configured : 1
Always-On Monitoring is up.

通知の有効化/無効化

Always-On Monitoringの最初の構成では通知は無効で、新しいアラートを受信したときにサービスによって電子メールが送信されません。まず、電子メール通知を送信するためにAlways-On Monitoringを有効にする必要があります。Always-On Monitoring通知の有効化/無効化設定は、Always-On Monitoringの起動/停止中に持続します。enable_notificationコマンドは、増分同期を自動的に実行します。

% $EMS_HOME/scripts/emsctl enable_notification
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Notifications have been enabled. There are downtime contacts configured.
Connecting to Always-On Monitoring repository.
Starting synchronization with Enterprise Manager.
Synchronizing with Enterprise Manager repository: sysman@myserver.myco.com:35074:semgc4
Synchronizing Targets data.
Synchronizing Alerts and Availability data.
Synchronizing Notification Metadata data.
Synchronizing Target Metric Metadata data.
Synchronization complete at : Thu Oct 22 07:01:20 PDT 2015

同期を実行しない場合は、-nosyncオプションを追加します。

$EMS_HOME/scripts/emsctl enable_notification -nosync
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Notifications have been enabled. There are downtime contacts configured.

通知を無効にして、Always-On Monitoringは実行したままにするには、disable_notificationコマンドを使用します。

% $EMS_HOME/scripts/emsctl disable_notification
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Notifications have been disabled.

ステータスおよびログの取得

emsctl statusコマンドを使用して、Always-On Monitoringの操作ステータスを確認します。

例:

% $EMS_HOME/scripts/emsctl status

Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Always-On Monitoring Version : 13.1.0.0.0
Always-On Monitoring Home : /homedirectory/ems
Started At : October 22, 2015 6:53:30 AM PDT
Last Repository Sync : October 22, 2015 6:50:51 AM PDT
Upload URL : https://myserver:8081/upload
Always-On Monitoring Process ID : 563
Always-On Monitoring Repository : myserver.myco.com:35074:semgc4
Enterprise Manager Repository : sysman
Notifications Enabled : false

Always-On Monitoring is up.

Always-On Monitoringに対するPing

emsctl statusコマンドを実行する以外に、すべての動作の詳細をリストしないでAlways-On Monitoringサービスが稼働中であることを確認するのみの場合は、pingコマンドを発行することもできます。

例:

$EMS_HOME/scripts/emsctl ping

Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Always-On Monitoring is running

ログ・ファイル

ログ・ファイルは、稼働中に発生したAlways-On Monitoringイベントを記録し、次のように生成されます。

- emscaログ: emsca.err (エラーのみ)、emsca.log.0 (エラーを含むすべての出力が含まれるローテーションするログ・ファイル)。

- emsログ: ems.err (エラーのみ)、ems.log.0 (エラーを含むすべての出力が含まれるローテーションするログ・ファイル)。

これらのファイルは$EMS_HOME/logsディレクトリにあります。

ログ・レベルによって、ログ・ファイルに記録される情報のタイプおよび操作上の重大度が決定します。レベルは次のいずれかに設定できます。

- INFO: ログインやログアウトなどのAlways-On Monitoring操作イベントまたはAlways-On Monitoringのライフサイクルに関連するその他のイベント。

- DEBUG: Always-On Monitoringイベントのフローをトレースして特定の問題を分離するときに役立つと考えられる情報。

- WARN (デフォルト設定): 予期しない稼働中のAlways-On Monitoringイベント。これらのAlways-On Monitoringイベントは追跡する必要はありますが、管理者がすぐに介入する必要はない場合があります。

- ERROR: Always-On Monitoringの稼働中の不具合。

ログ・レベルを変更するには、$EMS_HOME/conf/emsConfig.propertiesにlogLevel=...プロパティを追加します。これは、現在のAlways-On Monitoringインスタンスにのみ適用されます。

重要:
ログ・レベルの変更を有効にするには、Always-On Monitoringをバウンスする必要があります。

サービスの停止

emsctl stopコマンドを使用して、Always-On Monitoringを停止します。

$EMS_HOME/scripts/emsctl stop
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
------------------------------------------------------------------
Shutting down Always-On Monitoring.
Always-On Monitoring is stopped.

12.5.1 Always-On Monitoringのコマンド

次のコマンドは、Always-On Monitoringの制御に使用されます。

Always-On Monitoringの制御

emsctl start

Always-On Monitoringを起動します。

emsctl stop

Always-On Monitoringを停止します。

emsctl enable_notification -nosync (オプション)

Always-On Monitoringが電子メール通知を送信できるようにします。デフォルトでは、電子メール通知を有効にすると増分同期が実行されます。Enterprise Manager OMSと同期しないようにするには、-nosyncオプションを指定します。

emsctl disable_notification

Always-On Monitoringが電子メール通知を送信しないようにします。

emsctl ping

Always-On Monitoringサービスにpingを発行して、稼働中か停止中か判断します。

emsctl sync

Always-On Monitoringターゲットおよび通知データをEnterprise Managerリポジトリと同期します。

emsctl status

Always-On Monitoringの操作ステータスに関連する情報を表示します。

emsctl getstats

現在のAlways-On Monitoringのパフォーマンス統計を表示します

emsctl list_properties

Always-On Monitoringの構成プロパティを表示します。

emsctl set_property -name=<property name> -value=<property value>

Always-On Monitoringの構成プロパティを設定します。構成プロパティの完全なリストは、「変更可能なAlways-On Monitoringのプロパティ」を参照してください。

emsctl unset_property -name=<property name>

既存のAlways-On Monitoringの構成プロパティを設定解除します。構成プロパティの完全なリストは、「変更可能なAlways-On Monitoringのプロパティ」を参照してください。

emsctl update_task -task_name=<SYNC|PURGE> -run_interval=<time in minutes between task executions>

同期やパージなどのAlways-On Monitoringタスクを実行する間隔を更新します。

emsctl set_em_repos_conn -username=<em username> -password=<em password> -connect_string=<em connect descriptor>

Enterprise Managerリポジトリ・データベースへの接続に使用されるユーザー名、パスワードおよび接続文字列を更新します。

emsctl set_ems_repos_conn -username=<ems username> -password=<ems password> -connect_string=<ems connect descriptor>

Always-On Monitoringリポジトリ・データベースへの接続に使用されるユーザー名、パスワードおよび接続文字列を更新します。

12.6 Always-On Monitoringの更新

Enterprise Manager OMSの通知機能を実行するために、Always-On Monitoringでは、ターゲット・モニタリングおよび管理者通知構成データをOMSと同期する必要があります。Always-On Monitoringをインストールすると完全同期が実行されます。その後に増分同期を実行して、Always-On Monitoringのモニタリング/通知構成を最新の状態にする必要があります。

Enterprise Managerで次の変更を行うには、Always-On Monitoringの増分同期が必要です。

- 新規ホスト(エージェント)の追加

- 新規ターゲットの追加

- 停止時連絡先の変更

- 管理者電子メール・アドレスの変更

- 電子メール・サーバー構成の変更

Always-On Monitoringは、24時間ごとに実行される増分同期ジョブによって自動的にEnterprise Managerとの同期を維持します。emsctl update_taskコマンドを使用して、同期間隔を変更できます。

$EMS_HOME/emsctl update_task -task_name=<SYNC|PURGE> -run_interval=<time in minutes between task executions>

増分同期は、emsctl syncコマンドで手動で実行できます。

増分同期の手動実行

syncコマンドを実行することによって、いつでもAlways-On Monitoringの増分同期を実行できます。

% $EMS_HOME/scripts/emsctl sync

手動の増分同期を実行するとき、Always-On Monitoringを停止する必要はありません。Always-On Monitoringが稼働しているか停止しているかに関係なく、SYNCコマンドを実行できます。

注意:
enable_notificationコマンドを実行すると、増分同期が自動的に実行されます。-nosyncオプションを指定することによって、同期しないようにすることができます。

12.7 データ・メンテナンス

Always-On Monitoringリポジトリには、履歴可用性データとメトリック違反データが含まれています。このデータは、6か月間(デフォルトの間隔)保持されます。6か月経過したデータはリポジトリから削除(パージ)されます。

データ・メンテナンスは次の設定で制御されます。

- パージ間隔- Always-On Monitoringリポジトリからデータをパージする頻度を決定します。

- パージ期間-パージ・プロセス中に保持するデータの量を決定します。

update_taskコマンドでパージ間隔を変更できます。

$EMS_HOME/scripts/emsctl update_task -task_name=PURGE -run_interval=<the number of minutes between purge runs>

set_propertyコマンドでパージ期間を変更できます。

$EMS_HOME/scripts/emsctl set_property -name=purge.Duration -value=<the number of minutes of data to keep>

12.8 Always-On Monitoring構成設定の制御

Always-On Monitoring構成設定では、環境内でどのようにAlways-On Monitoringデプロイメントを操作するかを定義します。次の設定が2箇所に保存されます。

- 内容: Always-On Monitoringの特定インスタンスに固有のプロパティ。
場所: $EMS_HOME/conf/emsConfig.properties

すべてのAlways-On Monitoringインスタンスによって共有されるプロパティは、Always-On Monitoringリポジトリに保存されます。

- 内容: Always-On MonitoringがリスニングするHTTPポートおよびLogLevel。
場所: $EMS_HOME/conf/emsConfig.properties

次のコマンドは、構成プロパティの確認および設定に使用されます。

すべてのプロパティとその値をリストするには、次のコマンドを実行します。

$EMS_HOME/scripts/emsctl list_properties

プロパティ値を設定するには、次のコマンドを実行します。

$EMS_HOME/scripts/emsctl set_property -name=<propertyname> -value=<propertyvalue>

プロパティ値を削除するには、次のコマンドを実行します。

$EMS_HOME/scripts/emsctl unset_property -name=<propertyname>

12.9 パフォーマンス情報の取得

ロードやスループットなどのAlways-On Monitoringパフォーマンス情報を確認することによって、Always-On Monitoringインストールが正常に実行されていることを確認できます。getstatsコマンドを使用して、Always-On Monitoringパフォーマンス統計を表示します。

$EMS_HOME/scripts/emsctl getstats

12.10 変更可能なAlways-On Monitoringのプロパティ

Always-On Monitoringでは、Always-On Monitoringデプロイメントの動作を定義する様々なプロパティを変更できます。次の表に、使用可能なAlways-On Monitoringのプロパティを示します。

表12-4 Always-On Monitoringのプロパティ

プロパティ名

説明

デフォルト値

値の範囲

connPool.initialSize

リポジトリ接続プールで作成されるAlways-On Monitoringリポジトリ接続の初期数

1

1-connPool.maxSize

connPool.maxSize

リポジトリ接続プールで作成されるAlways-On Monitoringリポジトリ接続の最大数

100

connPool.minSize – 500

connPool.minSize

拡大後にリポジトリ接続プールで維持されるAlways-On Monitoringリポジトリ接続の最小数

10

connPool.initialSize – connPool.maxSize

failover.heartbeatInterval

実行中のAlways-On Monitoringからその他のAlways-On Monitoringインスタンスに送信されるハートビート間の間隔(秒単位)

60

30 – 3600

http.idleTimeout

Always-On MonitoringのアイドルWebサーバー接続が解放および終了されるまでの時間(ミリ秒単位)

60000

10000 – 120000

http.maxThreads

Webサーバー接続プールで作成されるAlways-On Monitoring Webサーバー・スレッドの最大数

50

http.minThreads – 100

http.minThreads

Webサーバー接続プールで作成されるAlways-On Monitoring Webサーバー・スレッドの最小数

10

1 – http.maxThreads

nls.useSystemLocale

将来の使用のために予約済

false

notif.enabled

電子メール通知が有効かどうか。通常、emsctl enable_notificationを使用して送信されます

true

true/false

notif.senderAddress

Always-On Monitoringから送信される電子メールの送信者電子メール・アドレスをオーバーライドします。それ以外の場合、アドレスはEnterprise Manager電子メール・アドレスと同じになります

null

notif.senderName

Always-On Monitoringから送信される送信者電子メールのユーザー名をオーバーライドします。それ以外の場合、名前はEnterprise Manager電子メールの名前と同じになります

null

purge.Duration

これまでのすべてのAlways-On Monitoring表に保持されるデータ量(分単位)

259200

10080 – 0 (無限)

sync.allowIncrSync

将来の使用のために予約済

false

true/false

tasks.poolSize

バックグラウンドのタスク実行プールで使用するスレッド数

20

1-50

tasks.purgeRunInterval

データ・パージ・タスクのインスタンス間の間隔(分単位)

10080

3600 – 10080

tasks.syncRunInterval

増分同期タスクのインスタンス間の間隔(分単位)

1440

60 - 3600

12.11 問題の診断

堅牢かつ容易なインストールと構成を通して、Always-On Monitoringを使用するときに問題が発生する場合があります。一般的に、Always-On Monitoringの問題は次の3つのタイプに分類できます。

- Always-On Monitoringの起動の問題

- Always-On MonitoringとOMSの同期の問題

- 電子メールを受信できない

次の診断手順に従うことによって、Always-On Monitoringを使用するときに発生する問題の大半を解決できます。

1. ログ・ファイルをチェックします。

2. Enterprise ManagerでURLが設定されていることを確認します。

3. 管理エージェントでURLが設定されていることを確認します。

4. Always-On Monitoringが実行され、かつ通知が有効であることを確認します。

5. Enterprise ManagerおよびAlways-On Monitoringで停止時連絡先が指定されていることを確認します。

12.12 高可用性および障害時リカバリ

Always-On Monitoringの目的は、Enterprise Manager OMSが停止したときに確実にEnterprise Manager環境を継続してモニタリングすることです。ただし、Always-On Monitoringサービス自体は、Enterprise Managerの最大可用性アーキテクチャ(MAA)ガイドラインに準拠することによって高可用性を実現できます。Always-On Monitoringを可用性の高いサービスとして設定することによって、壊滅的なシステム障害が発生したとき、確実にターゲットのモニタリングを継続できます。

12.12.1 複数のAlways-On Monitoringインスタンスの実行

Always-On Monitoringを使用すると、Enterprise Managerが停止したときにアラートのモニタリングを継続できます。負荷分散/高可用性のための複数のインスタンスを実装することによって、Always-On Monitoringの高可用性を実現できます。

複数のAlways-On Monitoringインスタンスを追加すると、HAに関して次の利点があります。

- エージェントからアラートを受信および記録する処理を共有します。なんらかの理由でインスタンスが停止した場合、サーバー・ロード・バランサ(SLB)で、障害の発生していないインスタンスにそれらのリクエストをリダイレクトできます

- 通知を送信する処理を共有します。順序の理由から、1つのターゲットのすべての通知が1つのAlways-On Monitoringインスタンスに送信されます。そのAlways-On Monitoringインスタンスが停止した場合、そのキューに対する責任は別のインスタンスに移されます。

次の図は、一般的なAlways-On MonitoryingのHAデプロイメントを示しています。

図12-1 Always-On MonitoringのHAデプロイメント

12.12.1.1 複数インスタンスの共有構成ストレージ

Always-On Monitoring構成を各ノードのファイル・システムに保持するのではなく、すべてのインスタンスが共通の構成を共有できます。これにより、1つの場所にある単一の構成をすべてのインスタンスから変更したり読み取ることができるようになります。

プロパティを変更するには、次のEMSCTLコマンドを使用します。

- emsctl set_property

- emsctl unset_property

現在のプロパティ値のリストを取得するには、次のコマンドを使用します

- emsctl list_properties

1つのインスタンスでプロパティが変更されると、その他すべてのAlways-On Monitoringインスタンスが、値がリフレッシュされたことを伝えるJMS AQメッセージをリポジトリから受信します。

12.12.1.2 受信アラートを追跡するための通知キュー

アラートを受信する各Always-On Monitoringインスタンスは、アラートを保存して、16個のイベント通知キューのいずれかにエントリを記録します。これらの通知キューの所有権は、実行中のAlways-On Monitoringインスタンスに分散されます。

フェイルオーバー・システムは、Always-On Monitoringインスタンスが稼働(およびハートビート)していない場合に通知し、停止しているインスタンスから稼働している他のAlways-On Monitoringインスタンスに所有権を切り替えます。その後、フェイルオーバー・システムは、稼働しているすべてのインスタンスに変更を通知するJMS AQメッセージを送信します。

12.12.1.3 タスク・スケジューラ・システム

タスク・スケジューラ・システムは、Always-On Monitoringインスタンス間で共有される責任を記憶し、スケジュールに基づいて処理を実行するようインスタンスに促します。タスク・リクエストは、稼働していることが知られているAlways-On Monitoringインスタンスに送信されます。これにより、複数のインスタンスで同じ処理を実行しようとして競合する可能性が減少します。

12.12.1.4 SLBの構成

複数のAlways-On Monitoringインスタンスが存在する場合、これらのインスタンスへのトラフィックはSLBを介して送信されると予想されます。

単一インスタンスとして構成されたAlways-On MonitoringインスタンスにHAが追加された場合、SLBホスト名を持つ新しいコピーをAlways-On Monitoringインスタンスの証明書に再移入することが必要になります。13.1では、これはemsca経由で直接サポートされていないため、SLBが構成されてEMがSLBで再保護されたら、次の回避策でAlways-On Monitoringインスタンスを再保護する必要があります。

1. Always-On Monitoringインスタンスを停止します。

2. $EMS_HOME/conf/ディレクトリの内容をバックアップします

3. emsConfig.propertiesおよびemsConn.ora (例: cwallet.sso、ems.cert、ems.jks)を除き、$EMS_HOME/conf/ディレクトリのすべてのファイルを削除します

4. $EMS_HOME/scripts/emsKeystoreCreatorでスクリプトを実行します。

5. grep cwallet $EMS_HOME/scripts/emsKeystoreCreator
出力は次のようになります。

SSO HOME=/a/path/to/mwhome/upload/cwallet.sso

6. そのスクリプトのSSO_HOMEによって識別されたファイルを$EMS_HOME/confディレクトリにコピーします

7. Always-On Monitoringインスタンスを再起動します。

8. 構成済のすべてのAlways-On Monitoringインスタンスについて、手順1から7を繰り返します。

9. emctl set property、emsUrlプロパティが、新しく構成されたEMSアップロードURL設定をSLBで使用していることを確認します

emscaおよび/またはemsctlステータスに表示されるURLは、そのAlways-On MonitoringインスタンスのローカルURLです。HA構成では、このローカルURLはAlways-On Monitoring URLとして使用されず、SLBでAlways-On Monitoringプールを設定するために使用されます。各Always-On Monitoringインスタンスのホストおよびポートは、/upload PUT URLとともにプールでそのプールのターゲットとして使用されます。

SLBを構成する場合、モニタリングURLは/upload GET URLとなります。このURLは、文字列「Always On Monitoring is active」を返します。

注意:
Always-on Monitoringはバージョン11.4.x以降、F5でサポートされます。

12.12.2 Always-On Monitoringの障害時リカバリ

障害時リカバリ(DR)によって、サイト全体にわたる障害が発生したときにAlways-On Monitoring機能を別の場所に移すことができます。

既存の手順で、DRのためにEnterprise Managerサイトをスタンバイ状態にできます。これらの手順には、DataGuardと、セカンダリ・サイトからファイル・システム・コンテンツにリンクする機能を使用して、プライマリ・リポジトリ・データベースの内容をスタンバイ・サイトでミラー化することも含まれています。

同様の実装をAlways-On Monitoringインスタンスにも使用できます。Always-On MonitoringのDR設定は、アクティブ/パッシブです。つまり、プライマリ・サイトが停止した場合、仮想IPがスタンバイ・ノードにフェイルオーバーし、スタンバイAlways-On Monitoringインスタンスは、起動された後、(ファイル・システム共有および仮想IPによって)プライマリ・ノードとまったく同じように実行されます。要約すると、Always-On Monitoringリポジトリはスタンバイ・サイトで使用可能である必要があり、Always-On Monitoringインスタンスのファイル・システムはレプリケートされる必要があります。次の図は、Always-On Monitoringの一般的なDRデプロイメントを示しています。

図12-2 Always-On Monitoringの障害時リカバリ・デプロイメント

第II部

検出

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

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- データベース・ターゲットの検出および追加

- ミドルウェア・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

13 ホスト・ターゲットと非ホスト・ターゲットの検出および追加

Enterprise Manager Cloud Control (Cloud Control)を使用すると、GUIを豊富に備えた単一のコンソールを介して、ネットワーク全体でソフトウェア・デプロイメントを検出、昇格、追加および監視できます。この章では、検出および昇格の概念と、Cloud Controlを使用してこれらのタスクを実行する方法を説明します。

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

- ターゲットの検出および追加の概要

- ホスト・ターゲットの検出および追加

- 非ホスト・ターゲットの検出および追加

- Oracleホームの検出および昇格

- 削除済ターゲットの取得

13.1 ターゲットの検出および追加の概要

この項では、検出、昇格およびモニタリングの基本概念について説明します。これは、Enterprise Manager Cloud Controlを使用してターゲットの検出およびモニタリングを行う複数の方法の理解に役立ちます。この項の具体的な内容は次のとおりです。

- 検出の用語の理解

- ターゲット検出のオプション

- Enterprise Managerライフサイクルでの検出および監視

- 検出および監視プロセス

13.1.1 検出の用語の理解

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

- ターゲットおよび管理対象ターゲットとは

- 検出とは

- 昇格とは

13.1.1.1 ターゲットおよび管理対象ターゲットとは

ターゲットとは、Cloud Controlで管理およびモニタリング可能なホスト・マシン、データベース、Fusion Middlewareコンポーネント、サーバー・ターゲット(ハードウェア)などのエンティティです。

管理対象ターゲットとは、Cloud Controlによりアクティブに管理および監視されているエンティティです。

13.1.1.2 検出とは

検出は、使用環境で管理対象外のホストおよびターゲットを識別するプロセスを意味します。ホストおよびターゲットを自動的にまたは手動で検出できます。

図13-1に検出プロセスを示します。

図13-1 検出

13.1.1.3 昇格とは

昇格は、ネットワークで検出された管理対象外のホストおよびターゲットを、Cloud Controlで管理対象のホストおよびターゲットに変換し、効率よく監視および管理できるようにするプロセスを意味します。管理対象外ホストを管理対象ホストに変換するには管理エージェントをそれらのホストにデプロイする必要がありますが、それらのホストで動作している管理対象外ターゲットを管理対象ターゲットに変換する場合に必要となるのは、Cloud Controlでターゲットを管理可能なエンティティとして追加することだけで、ホストに追加のコンポーネントをデプロイする必要はありません。

図13-2に昇格プロセスを示します。

図13-2 昇格

13.1.2 ターゲット検出のオプション

ターゲットは次の方法のいずれかを使用して検出できます。

自動検出プロセス

ホストの検出で自動検出プロセスを使用すると、ホストで実行している管理エージェントを使用して、管理対象外ホストをスキャンするEnterprise Managerジョブを実行できます。その後、管理対象外ホストに管理エージェントをデプロイして、それらのホストを管理対象ホストに変換します。次に、これらの管理対象ホスト上でデータベースまたは他のデプロイ済のコンポーネントまたはアプリケーションを検索して、最終的に、これらのターゲットを管理対象ステータスに昇格します。

ターゲットの検出で自動検出プロセスを使用すると、ホスト上のターゲットを検索した後、Enterprise Managerを使用してそれらのターゲットを追加できます。

この手順を使用する利点は、新しいコンポーネントがインフラストラクチャに追加されたときに、定期的に、それらを見付けて管理された状態にできることです。

ガイド付き検出プロセス

ガイド付き検出プロセスを使用すると、管理対象となるターゲットを明示的に追加できます。検出ウィザードによりプロセスを通して手順が示され、必要な設定のほとんどはデフォルトで構成されます。

このプロセスを使用する利点は次のとおりです。

- 簡単にターゲットを検出できます。

- 自動検出が実行されていなくても、追加されたばかりの新規データベースを検出できます。

- 自動検出結果にはすでに存在するが、詳細が変更されている、非プロンプト・データベースを検出できます。ポートなどがあります。

- 検出が不要な場合に、管理エージェントで必要以上のリソース消費が行われないようになります。

宣言的プロセス

ターゲット・モニタリング・プロパティを宣言すると、ホスト名や場所、ターゲット名や場所および他の固有情報など、データベース・ターゲットを検出するために必要な詳細のすべてを手動で指定できます。このプロセスは、一般的に、自動検出プロセスおよびガイド付き検出プロセスが、追加する必要のあるターゲットを検出できなかった場合に使用されます。

13.1.3 Enterprise Managerライフサイクルでの検出および監視

図13-3に、Cloud Controlでのターゲットの検出および監視のライフサイクル・プロセスを示します。

図13-3 Enterprise Managerライフサイクルでの検出および監視

13.1.4 検出および監視プロセス

図13-4に、ターゲットの検出および監視プロセスの概要を示します。

図13-4 検出および監視プロセス

13.2 ホスト・ターゲットの検出および追加

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

- ホスト・ターゲットの自動検出の構成

- 手動のガイド付き検出プロセスを使用したホスト・ターゲットの追加

13.2.1 ホスト・ターゲットの自動検出の構成

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

- ホスト・ターゲットの自動検出の前提条件

- ホスト・ターゲットの自動検出の設定

13.2.1.1 ホスト・ターゲットの自動検出の前提条件

自動検出プロセスを使用してホスト・ターゲットを検出する前に、次の前提条件を確認します。

- 1つ以上のインストール済のCloud Control管理エージェントにより、IPスキャンが完了しています。IPスキャンは現在、次のプラットフォームにインストールされて実行中のCloud Control管理エージェントによってのみ実行できます。

- Linux (32ビットおよび64ビット)

- Solaris 11クラスタ(SPARCまたはx86-64) (Cloud Controlリリース12.1.0.2以降。)

- エージェント・インストールを実行するユーザーが、ASMDBAグループに属していることを確認します。

- Solarisシステムにインストールされた管理エージェントで自動ホスト検出(Nmapバイナリ)を実行するには、次の手順に従います。

1. Cloud Control 3.4.3以上をSolarisシステムにインストールします。

2. 管理エージェントの実行を停止します。

3. 管理エージェントを開始するのに使用するターミナル・セッションで次のコマンドを実行します。
bash-2.03$ LD_LIBRARY_PATH=<directory path of Cloud ControlCloud Control libraries>:$LD_LIBRARY_PATH

bash-2.03$ export LD_LIBRARY_PATH

注意:
これらの手順を実行することにより、管理エージェントの実行時に、NmapはCloud Controlライブラリを参照します。

4. 前の手順で使用したターミナル・セッションを使用して管理エージェントを開始します。

注意:
LD_LIBRARY_PATHを起動スクリプトに追加して、この設定がシステムの再起動後も保持されるようにします。

- 次のシステムで実行している管理エージェントでホストを検出するには、表13-1に示す前提条件を満たす必要があります。

表13-1 ホストの検出の前提条件

システム

前提条件

Solaris 11クラスタ(SPARCまたはx86-64)

インタフェースnet0に静的IPv4アドレスを作成します。

ipadm create-addr -T static -a local=X.X.X.X/YY net0/ZZ

ここで、X.X.X.Xは静的IPv4アドレスで、YYはサブ・ネットワーク・マスク、ZZはnet0インタフェースの特定のアイデンティティです。作成された静的アドレスはその後でnet0/ZZにより識別されます。

次に例を示します。

ipadm create-addr -T static -a local=10.134.108.101/24 net0/hh

SUSE Linux for System z(tm)

1. /etc/sysconfig/hardwareディレクトリにあるNICの構成ファイルに追加することで、QETH_OPTIONS='fake_ll=1'オプションを実行します。
構成ファイルの名前は、使用するNICに応じて変更されます。システムで使用している構成ファイルの名前は、システム管理者にお問合せください。

2. システムを再起動して変更を有効にします。

RedHat Linux for System z

1. /etc/sysconfig/network-scriptsディレクトリにあるNICの構成ファイルに追加することで、OPTIONS='fake_ll=1'オプションを実行します。
構成ファイルの名前は、使用するNICに応じて変更されます。システムで使用している構成ファイルの名前は、システム管理者にお問合せください。

2. /etc/modprobe.confファイル内の別名に次のコマンドが含まれていることを確認します。
alias eth0 geth

3. システムを再起動して変更を有効にします。

13.2.1.2 ホスト・ターゲットの自動検出の設定

IPスキャンを使用してホストを検出および構成するには、次の手順に従います。

注意:
ご使用のプラットフォームで自動ホスト検出が使用できない場合は、管理エージェントを手動でデプロイします。管理エージェントをデプロイするには、次のURLを参照してください。
http://docs.oracle.com/cd/E24628_01/install.121/e24089/install_agent_usng_rsp.htm">>http://docs.oracle.com/cd/E24628_01/install.121/e24089/install_agent_usng_rsp.htm

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の構成」の順に選択します。

2. 検出の設定ページの「ホストおよびOracle VM Manager」タブで、「作成」をクリックします。検出ジョブを作成しました。デフォルトでは、「名前」フィールドに、ジョブの作成日時を含むタイトルが移入されます。検出ジョブを編集し、検出を即時または後で実行するようスケジュールできます。

3. ネットワーク・スキャンの検出: 作成ページで「追加」をクリックします。ここで、ネットワーク・スキャンを実行する管理エージェントを選択します。デフォルトでOracle Management Serviceホストにインストールされる管理エージェントを選択するか、必要に応じて別のエージェントを選択できます。

ネットワーク全体がスキャンされるため、スキャンを実行する管理エージェント・ホストに権限委譲を設定する必要があります。ネットワーク・スキャンはrootとして実行されるため、ホスト資格証明(rootとして実行)またはSSHキー資格証明を使用します。

4. スキャン表の「IP範囲」でエージェントを選択し、スキャンするIP範囲を入力します。次のいずれかまたはすべてを指定できます。

- host1.example.com host3.example.comのように、それぞれをスペースで区切った1つ以上の絶対ホスト名

- それぞれをスペースで区切った1つ以上のIPアドレス

- 10.0.0-255.1-250のようなアドレスの範囲。IPアドレスとIP範囲は、10.0.0-255.1-250のようにカンマで区切る必要があります。

- 128.16.10.0/24のようなClassless Inter-Domain Routing(CIDR)表記

次のように、各値はスペースで区切ります。

host1.example.com 192.168.0.1 128.16.10.0/24 10.0.0-255.1-250,254

5. 指定したIP範囲内のスキャン対象ポートのデフォルト・リストが「ポートの構成」表にリストされます。これらは、リストされているOracleコンポーネントによって通常使用されるデフォルト・ポートです。
コンポーネントのポート値を変更するには、表でコンポーネントを選択し、値を適宜変更します。最大10個のポートまたはポート範囲、あるいはその両方を指定できます。

6. リストにコンポーネント・ポートをさらに追加する場合は、「追加」をクリックします。含めるサービスの名前を入力し、スキャンするポートまたはポート範囲を指定します。

7. 次の項目を指定します。

- 検出ジョブが実行されるスケジュール。ジョブは即時に開始できます。

- スキャンを実行する管理エージェントに設定されている資格証明。
説明しているように、スキャンを実行する管理エージェント・ホストに権限委譲を設定する必要があります。使用される名前付き資格証明は、ルートとして実行するように構成する必要があります。

「スキャンの保存と発行」をクリックします。

8. 「設定」メニューから検出されたターゲットを確認するには、「ターゲットの追加」、「自動検出の結果」の順に選択します。

9. 自動検出の結果ページで「ネットワーク・スキャンされたターゲット」タブを選択します。検出されたすべてのホストがリストされ、開いているポートと識別可能なサービス名が表示されます。ネットワークにデプロイされているOracleコンポーネントに関する知識に基づいて、検出された潜在的なターゲットのタイプを判断できます。

10. 表からホストを選択し、「昇格」をクリックしてホストを管理対象ターゲット・ステータスに昇格させます。ホスト・ターゲットの追加ウィザードが開きます。このウィザードを使用して、管理エージェントをホストにインストールします。

管理エージェントを管理対象外ホストにインストールすることで、管理対象外ホストが管理対象ターゲット・ステータスに昇格し、その結果ホストが管理対象ホストに変換されます。

注意:
管理対象外ホストを管理対象ホストに手動で変換するには、各ホストに管理エージェントを手動でインストールする必要があります。グラフィック・モードまたはサイレント・モードで管理エージェントをインストールできます。
グラフィック・モードでインストールする手順は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。サイレント・モードでインストールする手順は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

13.2.2 手動のガイド付き検出プロセスを使用したホスト・ターゲットの追加

手動でホスト・ターゲットを追加するには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている手順を参照してください。

13.3 非ホスト・ターゲットの検出および追加

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

- 非ホスト・ターゲットの自動検出の構成

- ガイド付き検出プロセスを使用した非ホスト・ターゲットの追加

- 宣言的プロセスを使用した非ホスト・ターゲットの追加

13.3.1 非ホスト・ターゲットの自動検出の構成

管理対象ホスト上のターゲットを検出するには、次の手順に従います。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の構成」の順に選択します。

2. 検出の設定ページの「ホスト上のターゲット」タブで、「検索」を展開してから、「エージェント・ホスト名」フィールドにターゲットを確認するホストのホスト名を入力します。ホストには管理エージェントがインストールされている必要があります。

3. ターゲットの検出(エージェントベース)ページで、「検索」を展開してから、「エージェント・ホスト名」フィールドにターゲットを確認するホストのホスト名を入力します。ホストには管理エージェントがインストールされている必要があります。

4. 特定の管理エージェントを検索するには、「検索」をクリックします。表にすべての管理エージェントがリストされ、検索するものに基づいてリストがフィルタされます。

5. 表のホストを選択し、「検出モジュール」をクリックします。

6. 検出モジュール・ページで、ホストで検出するターゲット・タイプを選択します。ホストで検出するターゲット・タイプを選択します。一部のターゲット・タイプには検索パラメータを指定する必要があります。パラメータを指定するには、「検出モジュール」列でターゲット・タイプを選択し、「パラメータの編集」をクリックします。

- Oracleクラスタおよび高可用性サービス: パラメータは不要です。

- Oracleデータベース、リスナーおよび自動ストレージ管理: クラスタウェア・ホームのパスを指定します。

- Oracleホームの検出: パラメータは不要です。

- Oracle Secure Backupドメイン: パラメータは不要です。

- Oracle Fusion Middleware:*("アスタリスク"文字)を指定してすべてのミドルウェア・ホームを検索するか、ホスト上の1つ以上のミドルウェア・ホームのパスをそれぞれカンマで区切って指定します。

終了したら、「OK」をクリックします。ターゲット検出がこのホストで構成されました。

7. 検出の設定ページの「ホスト上のターゲット」タブで、検出を実行するスケジュールを設定するホストを選択します。「収集スケジュール」をクリックして、「すべてのホスト」または「選択したホスト用」を選択します。「収集スケジュール」ダイアログ・ボックスで、選択したホストの収集を有効化または無効化します。収集を有効化した場合、収集の頻度を選択します。このスケジュールは、選択されているすべてのホストに適用されます。デフォルトでは、検出は24時間ごとに実行されます。「OK」をクリックします。

8. 検出を構成する追加ホストごとに、これらの手順を繰り返します。

9. 「新規に検出」をクリックしてターゲットを即時に検出します。検出はスケジュールされた間隔でも実行されます。

10. 「設定」メニューから検出されたターゲットを確認するには、「ターゲットの追加」、「自動検出の結果」の順に選択します。

11. 昇格させるターゲットを選択し、「昇格」をクリックします。昇格させるターゲット・タイプに固有のウィザードが開きます。必要な値を指定します。

12. 「エージェントベース・ターゲット」タブをクリックします。1つまたは複数のターゲットを選択して昇格できます。

13. 検出されたターゲットに対してオプションで「無視」をクリックできることに注意してください。ターゲットを無視すると、そのターゲットは管理しないターゲットのリストに入ります。
無視されたターゲットは「無視されたターゲット」タブに表示され、昇格または削除するまで管理対象外ターゲットしてCloud Controlに残ります。ターゲットを削除すると、次に検出が実行されたときに再検出されます。

14. ターゲット・タイプ・ホームページをチェックして、ターゲットがCloud Controlターゲットとして昇格されたことを確認します。ターゲットが正常に昇格された後、ターゲット・ホストにインストールされている管理エージェントは、ターゲット上でメトリック・データの収集を開始します。

注意:

- 検出されたターゲットを管理対象ステータスに昇格すると、そのターゲットに必要なプラグインが、ターゲットが検出されたホストを監視する管理エージェントに自動的にデプロイされます。プラグインをデプロイする際には、管理エージェントは保護されている必要があります。したがって、検出されたターゲットを管理対象ステータスに昇格する前に、管理エージェントが保護されていることを確認します。検出されたターゲットが管理対象ステータスに昇格した後、つまり必要なプラグインがデプロイされた後は、常に非保護でもかまいません。
管理エージェントの保護ステータスを確認し、必要に応じて保護するには、次の方法のいずれかを使用します。

- 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」をクリックします。目的の管理エージェントをクリックします。管理エージェントが保護されているかどうかを確認します。保護されていない場合、「エージェント」メニューから、「セキュア」をクリックして保護します。

- 次のコマンドを実行して、管理エージェントが保護されているかどうかを確認することがもできます。
<EMSTATE>/bin/emctl status agent

管理エージェントが保護されている場合、前のコマンドの出力に表示される管理エージェントのURLはHTTPS URLです。ただし、表示される管理エージェントのURLがHTTP URLの場合、次のコマンドを実行して、管理エージェントを保護します。

<EMSTATE>/bin/emctl secure agent

- Cloud Controlでは、一部のターゲット・タイプについてのみ複数ターゲットの同時昇格がサポートされます。また、ユーザーがクラスタをまたがってRACデータベースを選択することを回避するために、データベース・ターゲットの複数選択は無効になっています。これは、ユーザー誘導型の検出機能において、クラスタ内の複数ターゲットを同一セッションで検出できないことに類似しています。

13.3.2 ガイド付き検出プロセスを使用した非ホスト・ターゲットの追加

ガイド付きプロセスを使用して非ホスト・ターゲットを追加するには、次の手順を実行します。

注意:
ガイド付きプロセスを使用してターゲットを追加するときには、選択したターゲット・タイプに特有のスクリプトおよび自動化プロセスが実行されます。ガイド付きプロセスを実行するには、資格証明を入力する必要がある場合があります。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。ターゲットの手動追加ページが表示されます。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用した追加」を選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、「Exalogic Elastic Cloud」、「Oracleクラスタおよび高可用性サービス」、「システム・インフラストラクチャ・サーバーILOM」または「Oracle WebLogicドメイン」などのターゲット・タイプを選択します。「追加...」をクリックします。

4. ターゲット・タイプの選択後、ターゲットを手動で追加するプロセスをガイドする、ターゲット・タイプに固有のウィザードに従います。
確認後、ターゲットはCloud Controlの管理対象ターゲットになります。Cloud Controlでは、単に情報が承認され、可能な場合は入力されたデータの検証が実行されて、ターゲットの監視が開始されます。

注意:
非ホスト・ターゲットをCloud Controlに手動で追加すると、そのターゲットに必要なプラグインが、非ホスト・ターゲットが存在するホストを監視する管理エージェントに自動的にデプロイされます。プラグインをデプロイする際には、管理エージェントは保護されている必要があります。したがって、非ホスト・ターゲットをCloud Controlに手動で追加する前に、管理エージェントが保護されていることを確認します。ターゲットがCloud Controlに追加された後、つまり必要なプラグインがデプロイされた後は、常に非保護でもかまいません。
管理エージェントの保護ステータスを確認し、必要に応じて保護するには、次の方法のいずれかを使用します。

- 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」をクリックします。目的の管理エージェントをクリックします。管理エージェントが保護されているかどうかを確認します。保護されていない場合、「エージェント」メニューから、「セキュア」をクリックして保護します。

- 次のコマンドを実行して、管理エージェントが保護されているかどうかを確認することがもできます。
<EMSTATE>/bin/emctl status agent

管理エージェントが保護されている場合、前のコマンドの出力に表示される管理エージェントのURLはHTTPS URLです。ただし、表示される管理エージェントのURLがHTTP URLの場合、次のコマンドを実行して、管理エージェントを保護します。

<EMSTATE>/bin/emctl secure agent

13.3.3 宣言的プロセスを使用した非ホスト・ターゲットの追加

ターゲット監視プロパティを指定して管理対象ホスト上のターゲットを追加するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。ターゲットの手動追加ページが表示されます。

2. 「ターゲットの手動追加」ページで、「ターゲットを宣言的に追加」を選択します。

3. 「ターゲットを宣言的に追加」ダイアログ・ボックスで、「ADF Business Components for Java」、「クラスタ・データベース」または「Oracle HTTP Server」など、追加するターゲット・タイプを「ターゲット・タイプ」リストから選択します。

4. ターゲットの監視に使用する管理エージェントを指定するか、「検索」アイコンをクリックして管理エージェントを検索して選択します。「追加...」をクリックします。

5. ターゲット・タイプの選択後、ターゲットを手動で追加するプロセスをガイドする、ターゲット・タイプに固有のウィザードに従います。
確認後、ターゲットはCloud Controlの管理対象ターゲットになります。Cloud Controlでは、単に情報が承認され、可能な場合は入力されたデータの検証が実行されて、ターゲットの監視が開始されます。

注意:
非ホスト・ターゲットをCloud Controlに手動で追加すると、そのターゲットに必要なプラグインが、非ホスト・ターゲットが存在するホストを監視する管理エージェントに自動的にデプロイされます。プラグインをデプロイする際には、管理エージェントは保護されている必要があります。したがって、非ホスト・ターゲットをCloud Controlに手動で追加する前に、管理エージェントが保護されていることを確認します。ターゲットがCloud Controlに追加された後、つまり必要なプラグインがデプロイされた後は、常に非保護でもかまいません。
管理エージェントの保護ステータスを確認し、必要に応じて保護するには、次の方法のいずれかを使用します。

- 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」をクリックします。目的の管理エージェントをクリックします。管理エージェントが保護されているかどうかを確認します。保護されていない場合、「エージェント」メニューから、「セキュア」をクリックして保護します。

- 次のコマンドを実行して、管理エージェントが保護されているかどうかを確認することがもできます。
<EMSTATE>/bin/emctl status agent

管理エージェントが保護されている場合、前のコマンドの出力に表示される管理エージェントのURLはHTTPS URLです。ただし、表示される管理エージェントのURLがHTTP URLの場合、次のコマンドを実行して、管理エージェントを保護します。

<EMSTATE>/bin/emctl secure agent

13.4 Oracleホームの検出および昇格

Enterprise Managerによって提供されたデプロイメント・プロシージャ以外の方法でOracleソフトウェア・コンポーネントをデプロイすると、Oracleホームは自動的には検出されず、ターゲットとして昇格されません。Oracleホーム・ターゲットを手動で検出して昇格させる必要があります。

Oracleホーム・ターゲットを検出および昇格するには、次の手順に従います。

1. 「エンタープライズ」メニューから「ジョブ」、「アクティビティ」の順に選択します。

2. 「ジョブ・アクティビティ」ページで、表のドロップダウン・リストから「Oracleホーム昇格ターゲットの検出」を選択します。

「実行」をクリックします。

3. 「'Oracleホーム昇格ターゲットの検出'ジョブの作成」ページの「一般」タブで、検出の名前を指定します。
例: OHDiscovery

オプションで検出の説明を追加できます。

「追加」をクリックします。

4. 「検索と選択: ターゲット」ダイアログ・ボックスで、ターゲット・タイプの「ホスト」を選択してから、「すべて選択」をクリックしてリストされるすべてのホスト・ターゲットを選択します。
「選択」をクリックします。

5. 「'Oracleホーム昇格ターゲットの検出'ジョブの作成」ページで、選択したホスト・ターゲットが表に表示されます。

6. 「パラメータ」タブを選択した後、次のいずれかを実行します。

- 単一のOracleホームを検出するには、ホームへのパスを指定した後、管理エンティティとして「Oracleホーム」を選択します。

- インベントリのすべてのホームを検出するには、インベントリへのパスを指定した後、管理エンティティとして「インベントリ」を選択します。

- ミドルウェア・ホームのすべてのホームを検出するには、ミドルウェア・ホームへのパスを指定した後、管理エンティティとして「ミドルウェア・ホーム」を選択します。

7. 後で使用するためにジョブを保存するには、「ライブラリに保存」をクリックします。送信するには、「発行」をクリックします。検出が成功すると、「ジョブ・アクティビティ」ページに確認メッセージが表示されます。

注意:
パスを指定せずに検出ジョブを発行すると、ホスト全体の検出が実行されます。管理エージェントでホームが検出できるようにするには、管理エージェントが認識するインベントリに登録する必要があります。デフォルトのインベントリは中央インベントリで、UNIXシステムでは/etc/oraInst.locにあります。ここで登録されたホームは自動的に検出可能になります。
ホストに他のインベントリがある場合は、管理エージェントのインベントリ・リストに追加する必要があります。$EMSTATE/sysman/config/OUIinventories.addに1行追加する必要があります。

ここにインベントリが見つからない場合は、管理エージェントがその存在を認識していないことになり、そこに登録されたいずれのホームも検出されなくなります。

13.5 削除済ターゲットの取得

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

- 削除済ターゲット・タイプの取得

- 削除済ホストと対応する管理エージェント・ターゲットの取得

13.5.1 削除済ターゲット・タイプの取得

1つ以上のターゲット(データベース・ターゲット、WebLogicドメインまたは他のターゲットなど)を削除した場合、それらを取得して、Enterprise Manager Cloud Controlコンソールに再び追加できます。ターゲットが存在したホストで自動検出が構成されている場合、スケジュールされている次の自動検出操作でそれらのターゲットは自動的に検出されます。その後、自動検出されたターゲットを昇格して、コンソールに追加できます。ターゲットが存在したホストで自動検出が構成されていない場合、次の方法のいずれかを使用して、ターゲットを検出する必要があります。

- 第13.3.1項の説明に従って自動検出を有効にして、次にスケジュールされている自動検出操作でターゲットを自動的に検出および昇格します。

- 第13.3.2項の説明に従ってガイド付き検出プロセスを使用してターゲットを手動で検出し、検出したターゲットをコンソールに追加します。

- 第13.3.3項の説明に従って各ターゲットのターゲット監視プロパティを指定することによりターゲットを手動で検出し、検出したターゲットをコンソールに追加します。

- 次のEM CLI動詞を使用します。

$ emcli add_target
-name="name"
-type="type"
-host="hostname"
[-properties="pname1:pval1;pname2:pval2;..."]
[-separator=properties="sep_string"]
[-subseparator=properties="subsep_string"]
[-credentials="userpropname:username;pwdpropname:password;..."]
[-input_file="parameter_tag:file_path"]
[-display_name="display_name"]
[-groups="groupname1:grouptype1;groupname2:grouptype2;..."]
[-timezone_region="gmt_offset"]
[-monitor_mode="monitor_mode"]
[-instances="rac_database_instance_target_name1:target_type1;..."]
[-force]
[-timeout="time_in_seconds"]

[ ] indicates that the parameter is optional

詳細については、次のURLにアクセスしてください。

http://docs.oracle.com/cd/E24628_01/em.121/e17786/cli_verb_ref.htm#CACHFHCA

13.5.2 削除済ホストと対応する管理エージェント・ターゲットの取得

ホスト・ターゲットと対応する管理エージェント・ターゲットを削除すれば、それらの両方を取得できます。次の手順を実行します。

次のコマンドを対応するホストのエージェント・インスタンス・ホームから実行して、ホストおよび管理エージェントを検出して追加します。

$ emctl config agent addInternalTargets

ホストおよび管理エージェントを検出してコンソールに追加したら、そのホスト上の各ターゲットを監視対象ターゲットとしてコンソールに追加します。これを行うには、次のEM CLI動詞を実行します。

$ emcli add_target
-name="name"
-type="type"
-host="hostname"
[-properties="pname1:pval1;pname2:pval2;..."]
[-separator=properties="sep_string"]
[-subseparator=properties="subsep_string"]
[-credentials="userpropname:username;pwdpropname:password;..."]
[-input_file="parameter_tag:file_path"]
[-display_name="display_name"]
[-groups="groupname1:grouptype1;groupname2:grouptype2;..."]
[-timezone_region="gmt_offset"]
[-monitor_mode="monitor_mode"]
[-instances="rac_database_instance_target_name1:target_type1;..."]
[-force]
[-timeout="time_in_seconds"]

[ ] indicates that the parameter is optional

詳細については、次のURLにアクセスしてください。

http://docs.oracle.com/cd/E24628_01/em.121/e17786/cli_verb_ref.htm#CACHFHCA

14 データベース・ターゲットの検出および追加

この章では、データベース・ターゲットを検出および追加して、Enterprise Manager Cloud Controlで管理できるようにする方法について説明します。この章の具体的な内容は次のとおりです。

- データベース・ターゲットの自動検出の有効化

- コンテナ・データベース・ターゲットおよびプラガブル・データベース・ターゲットの検出および追加

- クラスタ・データベース・ターゲットの検出および追加

- 単一インスタンス・データベース・ターゲットの検出および追加

- クラスタ・ターゲットの検出および追加

- 単一インスタンス高可用性サービス・ターゲットの検出および追加

- クラスタの自動ストレージ管理ターゲットの検出および追加

- セキュアな監視のターゲット・データベースの構成

14.1 データベース・ターゲットの自動検出の有効化

データベース・ターゲットの自動検出は、デフォルトでは有効になっています。自動検出が無効になっている場合は、次の手順で有効にできます。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の構成」の順にクリックします。

2. 自動検出の構成ページの「エージェントベースの自動検出」表で、「Oracleデータベース、リスナーおよび自動ストレージ管理」を選択します。

3. ターゲットの検出の構成ページで、「ホストの追加」をクリックします。

4. 「ターゲットの検索と選択」ダイアログ・ボックスで、構成するターゲットを選択し、「選択」をクリックします。

5. 「パラメータの編集」をクリックすると、ターゲットのパラメータを編集できます。
「OK」をクリックします。

14.2 コンテナ・データベース・ターゲットおよびプラガブル・データベース・ターゲットの検出および追加

この項では、コンテナ・データベース(CDB)ターゲットおよびプラガブル・データベース(PDB)ターゲットをCloud Controlで検出、昇格および追加するための様々な方法を説明します。この項の具体的な内容は次のとおりです。

- 自動検出を使用したCDBターゲットおよびPDBターゲットの検出

- ガイド付き検出プロセスを使用したCDBターゲットおよびPDBターゲットの追加

- 宣言的プロセスを使用したCDBターゲットおよびPDBターゲットの追加

14.2.1 自動検出を使用したCDBターゲットおよびPDBターゲットの検出

データベースの自動検出は、デフォルトで有効になっています。自動検出が無効になっている場合は、「データベース・ターゲットの自動検出の有効化」で説明されている手順に従います。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

自動検出を使用してCDBターゲットおよびそれに関連付けられているPDBターゲットを昇格するには、次の手順を実行します。

注意:
デフォルトでは、CDBターゲットを昇格すると、それに関連付けられている検出済のすべてのPDBターゲットも昇格されます。また、デフォルトでは、Enterprise Managerは24時間ごとにバックグラウンド・ジョブを実行して、管理対象ホストに存在する、新しく作成されたPDBターゲットを自動的に検出して昇格します。このため、この項で説明してとおり、PDBターゲットを検出および昇格するために必要な操作は、関連付けられているCDBターゲットを検出して昇格するのみです。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順にクリックします。エージェントベース・ターゲットをクリックします。

2. 昇格するデータベース・インスタンス・ターゲットを検索して選択し、「昇格」をクリックします。

3. ターゲットの昇格: 結果ページの「データベース」セクションで、CDBターゲットを選択します。
デフォルトでは、昇格するためにCDBターゲットを選択すると、それに関連付けられている、検出済のすべてのPDBターゲットも昇格用に選択されます。昇格用に選択されたPDBターゲットのリストに対して追加または削除を行う必要がある場合、CDBターゲットを選択して「構成」をクリックします。

「プラガブル・データベース」タブを選択し、「追加」または「削除」をクリックします。「保存」をクリックします。

Enterprise Managerは24時間ごとにバックグラウンド・ジョブを実行して、管理対象ホストに存在する、新しく作成されたPDBターゲットを自動的に検出して昇格します。特定のCDBターゲットに関連付けられているPDBターゲットに対するEnterprise Managerによる自動昇格操作ではなく、手動による昇格操作を行う場合は、ターゲットの昇格: 結果ページでCDBターゲットを選択して「構成」をクリックします。「プラガブル・データベース」タブを選択し、「プラガブル・データベースの検出モード」で「手動」を選択します。「保存」をクリックします。

4. 選択したCDBターゲットの監視資格証明(ユーザー名、パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

5. 「テスト接続」をクリックし、指定した監視資格証明を使用してCDBターゲットへの接続をテストします。

6. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

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

8. 表示された情報を確認して、「発行」をクリックします。

14.2.2 ガイド付き検出プロセスを使用したCDBターゲットおよびPDBターゲットの追加

ガイド付き検出プロセスを使用してCDBターゲットおよびそれに関連付けられているPDBターゲットを追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用した追加」を選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、「Oracle Database」、「リスナー」および「自動ストレージ管理」を選択します。「追加...」をクリックします。

4. 「ガイド付きプロセスを使用してターゲットを追加(関連ターゲットも追加)」を選択します。「ターゲット・タイプ」で、「Oracleデータベース、リスナーおよび自動ストレージ管理」を選択します。「ガイド付きプロセスを使用した追加」をクリックします。

5. データベース検出: 検索基準ページの「ホストまたはクラスタの指定」でCDBホストを指定します。

選択したホストがクラスタのメンバーである場合、このページを使用して、PDBターゲットを、選択したホストでのみ検索するか、クラスタ内のすべてのホストで検索するかを指定することもできます。

「検索」アイコンをクリックすると、「ターゲットの選択」ダイアログ・ボックスが表示されます。ターゲット名を指定するかターゲット表からターゲットを選択します。「ステータス」列の「フィルタ」矢印をクリックし、検索をフィルタリングして、すべての停止中のターゲットまたは稼働中のターゲットを検索できます。

「構成検索」アイコンをクリックして検索を構成することもできます。CDBを選択してから、「選択」をクリックします。

選択した現在のホストでのみプラガブル・データベース・ターゲットを検索するか、ホスト・ターゲットがメンバーとして属しているクラスタ内のすべてのホスト上で検索するかを選択するオプションが表示されます。

このオプションにより、選択した現在のホストでのみPDBターゲットを検索する場合には、時間を節約することができます。

「検出オプション」セクションでは検出ヒントを指定できます。デフォルトの検出動作を変更するために、追加の検出オプションを指定できます。サポートされているヒントは、db_name、db_target_prefix、db_target_suffix、discovery_timeout <ホスト当たりの秒単位>およびno_db_domain.です。

次に例を示します。

db_name=PRODUCTS, discovery timeout=15。

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

7. データベース検出: 結果ページの「データベース」セクションで、CDBターゲットを選択します。
デフォルトでは、昇格するためにCDBターゲットを選択すると、それに関連付けられている、検出済のすべてのPDBターゲットも昇格用に選択されます。昇格用に選択されたPDBターゲットのリストに対して追加または削除を行う必要がある場合、CDBターゲットを選択して「構成」をクリックします。「プラガブル・データベース」タブを選択し、「追加」または「削除」をクリックします。「保存」をクリックします。

Enterprise Managerは24時間ごとにバックグラウンド・ジョブを実行して、管理対象ホストに存在する、新しく作成されたPDBターゲットを自動的に検出して昇格します。特定のCDBターゲットに関連付けられているPDBターゲットに対するEnterprise Managerによる自動昇格操作ではなく、手動による昇格操作を行う場合は、ターゲットの昇格: 結果ページでCDBターゲットを選択して「構成」をクリックします。「プラガブル・データベース」タブを選択し、「プラガブル・データベースの検出モード」で「手動」を選択します。「保存」をクリックします。

8. 選択したCDBターゲットの監視資格証明(ユーザー名、パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

9. 「テスト接続」をクリックし、指定した監視資格証明を使用してCDBターゲットへの接続をテストします。

10. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

複数のデータベースを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

12. 表示された情報を確認して、「発行」をクリックします。

14.2.3 宣言的プロセスを使用したCDBターゲットおよびPDBターゲットの追加

ターゲット・モニタリング・プロパティを指定してCDBターゲットおよびそれに関連付けられているPDBターゲットを追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ターゲットを宣言的に追加」を選択します。

3. 「ターゲットを宣言的に追加」ダイアログ・ボックスで、「プラガブル・データベース」を選択して、「追加...」をクリックします。
「監視エージェント」で、CDBホストに存在する管理エージェントを指定します。「手動追加」をクリックします。

4. 「プラガブル・データベースの追加: コンテナ・データベースの指定」ページで、CDBを指定するか、検索アイコンをクリックしてターゲットの追加先のCDBを選択します。
「続行」をクリックします。

5. プラガブル・データベースの追加: プロパティ・ページで、ターゲットの一意の名前、名前、デフォルト・サービス名および優先接続文字列を指定します。

「コンテナ・データベース」セクションを展開して、CDBのプロパティを検証します。

「テスト接続」をクリックし、指定した監視資格証明を使用してCDBターゲットへの接続をテストします。

「続行」をクリックします。

6. 各ページで必要な情報を指定し、「確認」ページに到達するまで「次」をクリックします。

7. 表示された情報を確認して、「発行」をクリックします。

14.3 クラスタ・データベース・ターゲットの検出および追加

この項では、クラスタ・データベース・ターゲットを検出および追加するための様々な方法について説明します。この項の具体的な内容は次のとおりです。

- 自動検出を使用したクラスタ・データベース・ターゲットの検出

- ガイド付き検出プロセスを使用したクラスタ・データベース・ターゲットの追加

- 宣言的プロセスを使用したクラスタ・データベース・ターゲットの追加

14.3.1 自動検出を使用したクラスタ・データベース・ターゲットの検出

データベースの自動検出は、デフォルトで有効になっています。自動検出が無効になっている場合は、「データベース・ターゲットの自動検出の有効化」で説明されている手順に従います。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

自動検出を使用してクラスタ・データベース・ターゲットを昇格するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順に選択します。
結果表の「エージェントベース・ターゲット」タブから、監視するために追加する検出済のクラスタ・データベース・ターゲットを選択し、「昇格」をクリックします。

2. ターゲットの昇格: 結果ページに、クラスタ上で検出されたデータベースが表示されます。データベースを選択します
ターゲットの昇格: 結果ページの「データベース」セクションの下にある、「クラスタ・データベース」セクションで、昇格するクラスタ・データベース・ターゲットを選択します。

デフォルトでは、昇格するためにクラスタ・データベース・ターゲットを選択すると、それに関連付けられている、検出済のすべてのデータベース・インスタンス・ターゲットも昇格用に選択されます。昇格用に選択したデータベース・インスタンス・ターゲットのリストに対して追加または削除を行う必要がある場合、クラスタ・データベース・ターゲットを選択して「構成」をクリックします。「インスタンス」タブを選択し、「追加」または「削除」をクリックします。「保存」をクリックします。

3. 「クラスタ・データベース」セクションで、選択したクラスタ・データベース・ターゲットの監視資格証明(監視ユーザー名、監視パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

4. 「テスト接続」をクリックし、指定した監視資格証明を使用してクラスタ・データベース・ターゲットへの接続をテストします。

5. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

6. 複数のデータベースを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

8. 表示された情報を確認して、「発行」をクリックします。

14.3.2 ガイド付き検出プロセスを使用したクラスタ・データベース・ターゲットの追加

ガイド付きプロセスを使用してクラスタ・データベース・ターゲットを追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用した追加」を選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、「Oracle Database」、「リスナー」および「自動ストレージ管理」を選択します。「追加...」をクリックします。

4. データベース検出: 検索基準ページで、クラスタ・データベース・ホストを指定するか、「ホストまたはクラスタの指定」検索アイコンをクリックしてクラスタを選択します。

選択したホストがクラスタのメンバーである場合、このページを使用して、データベース・ターゲットを、選択したホストでのみ検索するか、クラスタ内のすべてのホストで検索するかを指定することもできます。

「検索」アイコンをクリックすると、「ターゲットの選択」ダイアログ・ボックスが表示されます。ターゲット名を指定するかターゲット表からターゲットを選択します。「ステータス」列の「フィルタ」矢印をクリックし、検索をフィルタリングして、すべての停止中のターゲットまたは稼働中のターゲットを検索できます。

「構成検索」アイコンをクリックして検索を構成することもできます。ホスト・ターゲットを選択してから、「選択」をクリックします。

選択した現在のホストでのみクラスタ・データベース・ターゲットを検索するか、ホスト・ターゲットがメンバーとして属しているクラスタ内のすべてのホスト上で検索するかを選択するオプションが表示されます。

このオプションにより、選択した現在のホストでのみクラスタ・データベース・ターゲットを検索する場合には、時間を節約することができます。

「検出オプション」セクションでは検出ヒントを指定できます。デフォルトの検出動作を変更するために、追加の検出オプションを指定できます。サポートされているヒントは、db_name、db_target_prefix、db_target_suffix、discovery_timeout <ホスト当たりの秒単位>およびno_db_domain.です。

次に例を示します。

db_name=PRODUCTS, discovery timeout=15。

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

5. データベース検出: 結果ページの「データベース」セクションの下にある、「クラスタ・データベース」セクションで、追加するクラスタ・データベース・ターゲットを選択します。

デフォルトでは、昇格するためにクラスタ・データベース・ターゲットを選択すると、それに関連付けられている、検出済のすべてのデータベース・インスタンス・ターゲットも昇格用に選択されます。昇格用に選択したデータベース・インスタンス・ターゲットのリストに対して追加または削除を行う必要がある場合、クラスタ・データベース・ターゲットを選択して「構成」をクリックします。「インスタンス」タブを選択し、「追加」または「削除」をクリックします。「保存」をクリックします。

6. 選択したクラスタ・データベース・ターゲットの監視資格証明(ユーザー名、パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

7. 「テスト接続」をクリックし、指定した監視資格証明を使用してクラスタ・データベース・ターゲットへの接続をテストします。

8. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

複数のデータベースを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

10. 表示された情報を確認して、「発行」をクリックします。

14.3.3 宣言的プロセスを使用したクラスタ・データベース・ターゲットの追加

ターゲット・モニタリング・プロパティを指定してクラスタ・データベース・ターゲットを宣言的に追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ターゲットを宣言的に追加」を選択します。

3. 「ターゲットを宣言的に追加」ダイアログ・ボックスで、「クラスタ・データベース」を選択して、「追加...」をクリックします。

4. クラスタ・データベースの構成: プロパティ・ページで、クラスタ・データベース・ターゲットの名前とデータベース・システム名を指定します。次に、ターゲットのすべてのプロパティ(Oracleホームのパス、監視ユーザー名とパスワード、ロール、リスナー・マシンの名前、ポート、データベースSID、優先接続文字列)を指定します。

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

5. パッケージのインストール・ページ、資格証明ページおよびパラメータ・ページですべての必要な詳細情報を指定します。各ページで必要な情報を指定し、「確認」ページに到達するまで「次」をクリックします。

6. 表示された情報を確認して、「発行」をクリックします。

14.4 単一インスタンス・データベース・ターゲットの検出および追加

この項では、単一インスタンス・データベース・ターゲットを検出および追加するための様々な方法について説明します。この項の具体的な内容は次のとおりです。

- 自動検出を使用した単一インスタンス・データベース・ターゲットの検出

- ガイド付き検出プロセスを使用した単一インスタンス・データベース・ターゲットの追加

- 宣言的プロセスを使用した単一インスタンス・データベース・ターゲットの追加

14.4.1 自動検出を使用した単一インスタンス・データベース・ターゲットの検出

データベースの自動検出は、デフォルトで有効になっています。自動検出が無効になっている場合は、「データベース・ターゲットの自動検出の有効化」で説明されている手順に従います。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

単一インスタンス・データベース・ターゲットを昇格するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順に選択します。
結果表の「エージェントベース・ターゲット」タブから、監視するために追加する検出済の単一インスタンス・データベース・ターゲットを選択し、「昇格」をクリックします。

2. ターゲットの昇格: 結果ページに、データベースが表示されます。データベース・インスタンスを選択します。
ターゲットの昇格: 結果ページの「データベース」セクションの下にある、「単一インスタンス・データベース」セクションで、昇格する単一インスタンス・データベース・ターゲットを選択します。

3. 選択した単一インスタンス・データベース・ターゲットの監視資格証明(監視ユーザー名、監視パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

4. 「テスト接続」をクリックし、指定した監視資格証明を使用して単一インスタンス・データベース・ターゲットへの接続をテストします。

5. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

6. 複数のデータベースを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

8. 表示された情報を確認して、「発行」をクリックします。

14.4.2 ガイド付き検出プロセスを使用した単一インスタンス・データベース・ターゲットの追加

単一インスタンス・データベース・ターゲットを追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用した追加」を選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、「Oracle Database」、「リスナー」および「自動ストレージ管理」を選択します。「追加...」をクリックします。

4. データベース検出: 検索基準ページで、単一インスタンス・データベース・ホストを指定するか、「ホストまたはクラスタの指定」検索アイコンをクリックしてクラスタを選択します。

選択したホストがクラスタのメンバーである場合、このページを使用して、データベースを、選択したホストでのみ検索するか、クラスタ内のすべてのホストで検索するかを指定することもできます。

「検索」アイコンをクリックすると、「ターゲットの選択」ダイアログ・ボックスが表示されます。ターゲット名を指定するかターゲット表からターゲットを選択します。「ステータス」列の「フィルタ」矢印をクリックし、検索をフィルタリングして、すべての停止中のターゲットまたは稼働中のターゲットを検索できます。

「構成検索」アイコンをクリックして検索を構成することもできます。ホストを選択してから、「選択」をクリックします。

選択した現在のホストでのみデータベース・ターゲットを検索するか、ホスト・ターゲットがメンバーとして属しているクラスタ内のすべてのホスト上で検索するかを選択するオプションが表示されます。

このオプションにより、選択した現在のホストのみでデータベース・ターゲットを検索する場合には、時間を節約することができます。

「検出オプション」セクションでは検出ヒントを指定できます。デフォルトの検出動作を変更するために、追加の検出オプションを指定できます。サポートされているヒントは、db_name、db_target_prefix、db_target_suffix、discovery_timeout <ホスト当たりの秒単位>およびno_db_domain.です。

次に例を示します。

db_name=PRODUCTS, discovery timeout=15。

検出プロセスを続行するには、「次」をクリックします。

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

5. 「データベース検出: 結果」ページに、クラスタ上で検出されたデータベースが表示されます。データベースを選択します
「データベース検出: 結果」ページの「データベース」セクションの下にある、「単一インスタンス・データベース」セクションで、昇格する単一インスタンス・データベース・ターゲットを選択します。

6. 選択した単一インスタンス・データベース・ターゲットの監視資格証明(監視ユーザー名、監視パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

7. 「テスト接続」をクリックし、指定した監視資格証明を使用して単一インスタンス・データベース・ターゲットへの接続をテストします。

8. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

9. 複数のデータベースを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

11. 表示された情報を確認して、「発行」をクリックします。

14.4.3 宣言的プロセスを使用した単一インスタンス・データベース・ターゲットの追加

ターゲット・モニタリング・プロパティを指定して単一インスタンス・データベース・ターゲットを宣言的に追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ターゲットを宣言的に追加」を選択します。

3. 「ターゲットを宣言的に追加」ダイアログ・ボックスで、「データベース・インスタンス」選択します。

4. 「監視エージェント」フィールドで、データベースを監視している管理エージェントを選択します。

5. 「追加...」をクリックします。

6. データベース・インスタンスの構成: プロパティ・ページで、インスタンス・データベース・ターゲットの名前とデータベース・システム名を指定します。次に、ターゲットのすべてのプロパティ(Oracleホームのパス、監視ユーザー名とパスワード、ロール、リスナー・マシンの名前、ポート、データベースSID、優先接続文字列)を指定します。

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

7. パッケージのインストール・ページ、資格証明ページおよびパラメータ・ページですべての必要な詳細情報を指定します。各ページで必要な情報を指定し、「確認」ページに到達するまで「次」をクリックします。

8. 表示された情報を確認して、「発行」をクリックします。

14.5 クラスタ・ターゲットの検出および追加

この項では、クラスタ・ターゲットを検出および追加するための様々な方法について説明します。この項の具体的な内容は次のとおりです。

- 自動検出を使用したクラスタ・ターゲットの検出

- ガイド付き検出プロセスを使用したクラスタ・ターゲットの追加

- 宣言的プロセスを使用したクラスタ・ターゲットの追加

14.5.1 自動検出を使用したクラスタ・ターゲットの検出

データベースの自動検出は、デフォルトで有効になっています。自動検出が無効になっている場合は、「データベース・ターゲットの自動検出の有効化」で説明されている手順に従います。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

クラスタ・ターゲットを昇格するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順に選択します。
結果表の「エージェントベース・ターゲット」タブから、監視するために追加する検出済のクラスタ・ターゲットを選択し、「昇格」をクリックします。

2. ターゲットの昇格: 結果ページに、クラスタ上で検出されたホストが表示されます。昇格するホストを選択します。

注意:
ホストは1つのクラスタにのみ属します。特定のホストが表示されない場合、そのホストは別のクラスタに属している可能性があります。

ターゲットの昇格: 結果ページの「クラスタ」セクションで、昇格するクラスタ・ターゲットを選択します。

デフォルトでは、昇格するためにクラスタ・ターゲットを選択すると、それに関連付けられている、検出済のすべてのホストも昇格用に選択されます。昇格用に選択したホストのリストに対して追加または削除を行う必要がある場合、クラスタ・データベース・ターゲットを選択して「構成」をクリックします。「ホスト」タブを選択し、「追加」または「削除」をクリックします。「保存」をクリックします。

3. 「クラスタ」セクションで、選択したクラスタ・ターゲットの監視資格証明(監視ユーザー名、監視パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

4. 「テスト接続」をクリックし、指定した監視資格証明を使用してクラスタ・ターゲットへの接続をテストします。

5. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

6. 複数のデータベースを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

8. 表示された情報を確認して、「発行」をクリックします。

14.5.2 ガイド付き検出プロセスを使用したクラスタ・ターゲットの追加

ガイド付きプロセスを使用してクラスタ・ターゲットを追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用した追加」を選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、「Oracle Database」、「リスナー」および「自動ストレージ管理」を選択します。「追加...」をクリックします。

4. クラスタの検出: ホストの指定ページで、クラスタ・ホストを指定するか、「ホストまたはクラスタの指定」検索アイコンをクリックしてクラスタを選択します。

選択したホストがクラスタのメンバーである場合、このページを使用して、クラスタを、選択したホストでのみ検索するか、クラスタ内のすべてのホストで検索するかを指定することもできます。

「検索」アイコンをクリックすると、「ターゲットの選択」ダイアログ・ボックスが表示されます。ターゲット名を指定するかターゲット表からターゲットを選択します。「ステータス」列の「フィルタ」矢印をクリックし、検索をフィルタリングして、すべての停止中のターゲットまたは稼働中のターゲットを検索できます。

「構成検索」アイコンをクリックして検索を構成することもできます。CDBを選択してから、「選択」をクリックします。

選択した現在のホストでのみクラスタ・ターゲットを検索するか、ホスト・ターゲットがメンバーとして属しているクラスタ内のすべてのホスト上で検索するかを選択するオプションが表示されます。

このオプションにより、選択した現在のホストでのみクラスタ・ターゲットを検索する場合には、時間を節約することができます。

「検出オプション」セクションでは検出ヒントを指定できます。デフォルトの検出動作を変更するために、追加の検出オプションを指定できます。サポートされているヒントは、db_name、db_target_prefix、db_target_suffix、discovery_timeout <ホスト当たりの秒単位>およびno_db_domain.です。

次に例を示します。

db_name=PRODUCTS, discovery timeout=15。

検出プロセスを続行するには、「次」をクリックします。

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

5. クラスタの検出: 結果ページに、クラスタ上で検出されたホストが表示されます。追加するホストを選択します。

注意:
ホストは1つのクラスタにのみ属します。特定のホストが表示されない場合、そのホストは別のクラスタに属している可能性があります。

クラスタの検出: 結果ページの「クラスタ・ターゲットのプロパティ」セクションで、クラスタのプロパティを検証します。

ホストの追加または削除を行う必要がある場合、「クラスタ・ホストおよび高可用性サービス・ターゲット」セクションからホストを選択します。「追加」または「削除」をクリックします。

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

7. 表示された情報を確認して、「発行」をクリックします。

14.5.3 宣言的プロセスを使用したクラスタ・ターゲットの追加

ターゲット・モニタリング・プロパティを指定してクラスタ・ターゲットを宣言的に追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ターゲットを宣言的に追加」を選択します。

3. 「ターゲットを宣言的に追加」ダイアログ・ボックスで、「クラスタ」選択します。

4. 「監視エージェント」フィールドで、データベースを監視している管理エージェントを選択します。

5. 「追加...」をクリックします。

6. クラスタの検出: 結果ページで、ターゲット名、Oracleホーム、SCAN名、SCANポートおよびONSポートを指定します。

注意:
SCAN名、SCANポートおよびONSポートのプロパティは、クラスタウェアのバージョン11.2以上でのみ適用できます。

7. さらに多くのホスト・ターゲットおよび高可用性サービス・ターゲットをクラスタに追加できます。「追加」をクリックしたときに特定のホストが表示されない場合、そのホストはすでに別のクラスタに属している可能性があります。
ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。

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

8. 表示された情報を確認して、「発行」をクリックします。

14.6 単一インスタンス高可用性サービス・ターゲットの検出および追加

この項では、単一インスタンス高可用性サービス・ターゲットを検出および追加するための様々な方法について説明します。この項の具体的な内容は次のとおりです。

- 自動検出を使用した単一インスタンス高可用性サービス・ターゲットの検出

- ガイド付き検出プロセスを使用した単一インスタンス高可用性サービス・ターゲットの追加

- 宣言的プロセスを使用した単一インスタンス高可用性サービス・ターゲットの追加

14.6.1 自動検出を使用した単一インスタンス高可用性サービス・ターゲットの検出

データベースの自動検出は、デフォルトで有効になっています。自動検出が無効になっている場合は、「データベース・ターゲットの自動検出の有効化」で説明されている手順に従います。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

単一インスタンス高可用性サービス・ターゲットを昇格するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順に選択します。

注意:
結果がなにも表示されない場合は、ターゲットの自動検出が無効になっています。自動検出を有効にするには、「データベース・ターゲットの自動検出の有効化」を参照してください。

結果表の「エージェントベース・ターゲット」タブから、監視するために追加する検出済の単一インスタンス高可用性サービス・ターゲットを選択し、「昇格」をクリックします。

2. ターゲットの昇格: 結果ページに、検出された高可用性インスタンスが表示されます。データベースを選択します
ターゲットの昇格: 結果ページの「高可用性サービス」セクションで、昇格するSIHAターゲットを選択します。

3. 選択したSIHAターゲットの監視資格証明(監視ユーザー名、監視パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

4. 「テスト接続」をクリックし、指定した監視資格証明を使用してSIHAターゲットへの接続をテストします。

5. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

6. 複数のデータベースを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

8. 表示された情報を確認して、「発行」をクリックします。

14.6.2 ガイド付き検出プロセスを使用した単一インスタンス高可用性サービス・ターゲットの追加

ガイド付きプロセスを使用して単一インスタンス高可用性サービス・ターゲットを追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用した追加」を選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、「Oracle Database」、「リスナー」および「自動ストレージ管理」を選択します。「追加...」をクリックします。

4. クラスタの検出: ホストの指定ページで、単一インスタンス高可用性サービス・ホストを指定するか、「ホストまたはクラスタの指定」検索アイコンをクリックしてクラスタを選択します。

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

5. クラスタの検出: 結果ページに、検出されたホストが高可用性サービス・インスタンスが表示されます。
クラスタの検出: 結果ページの「高可用性サービス」セクションで、昇格する単一インスタンス高可用性サービス・ターゲットを選択します。

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

7. 表示された情報を確認して、「発行」をクリックします。

14.6.3 宣言的プロセスを使用した単一インスタンス高可用性サービス・ターゲットの追加

ターゲット・モニタリング・プロパティを指定して単一インスタンス高可用性サービス・ターゲットを宣言的に追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ターゲットを宣言的に追加」を選択します。

3. 「ターゲットを宣言的に追加」ダイアログ・ボックスで、「Oracle高可用性サービス」選択します。

4. 「監視エージェント」フィールドで、データベースを監視している管理エージェントを選択します。

5. 「追加...」をクリックします。

6. 高可用性サービス: 結果ページで、ターゲットの名前、OracleホームおよびONSポートを指定します。

ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。

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

7. 表示された情報を確認して、「発行」をクリックします。

14.7 クラスタの自動ストレージ管理ターゲットの検出および追加

この項では、ASMクラスタ・ターゲットを検出および追加するための様々な方法について説明します。この項の具体的な内容は次のとおりです。

- 自動検出を使用したクラスタASMターゲットの検出

- ガイド付き検出プロセスを使用したクラスタASMターゲットの追加

- 宣言的プロセスを使用したクラスタASMターゲットの追加

14.7.1 自動検出を使用したクラスタASMターゲットの検出

データベースの自動検出は、デフォルトで有効になっています。自動検出が無効になっている場合は、「データベース・ターゲットの自動検出の有効化」で説明されている手順に従います。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

自動検出を使用してクラスタ自動ストレージ管理ターゲットを昇格するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順に選択します。

注意:
結果がなにも表示されない場合は、ターゲットの自動検出が無効になっています。自動検出を有効にするには、「データベース・ターゲットの自動検出の有効化」を参照してください。

結果表の「エージェントベース・ターゲット」タブから、監視するために追加する検出済のクラスタASMターゲットを選択し、「昇格」をクリックします。

2. ターゲットの昇格: 結果ページに、クラスタASM上で検出されたターゲットが表示されます。
ターゲットの昇格: 結果ページの「クラスタASM」セクションで、昇格するターゲットを選択します。

デフォルトでは、昇格するためにクラスタASMターゲットを選択すると、それに関連付けられている、検出済のすべてのターゲットも昇格用に選択されます。昇格用に選択したターゲットのリストに対して追加または削除を行う必要がある場合、クラスタASMターゲットを選択して「構成」をクリックします。「インスタンス」タブを選択し、「追加」または「削除」をクリックします。「保存」をクリックします。

3. 「クラスタASM」セクションで、選択したクラスタ・ターゲットの監視資格証明(監視ユーザー名、監視パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

4. 「テスト接続」をクリックし、指定した監視資格証明を使用してクラスタASMターゲットへの接続をテストします。

5. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

6. 複数のターゲットを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

8. 表示された情報を確認して、「発行」をクリックします。

14.7.2 ガイド付き検出プロセスを使用したクラスタASMターゲットの追加

ガイド付きプロセスを使用してクラスタASMターゲットを追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用した追加」を選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、「Oracle Database」、「リスナー」および「自動ストレージ管理」を選択します。「追加...」をクリックします。

4. データベース検出: 検索基準ページで、クラスタASMホストを指定するか、「ホストまたはクラスタの指定」検索アイコンをクリックしてクラスタを選択します。

選択したホストがクラスタのメンバーである場合、このページを使用して、Automated Storage Managerを、選択したホストでのみ検索するか、クラスタ内のすべてのホストで検索するかを指定することもできます。

検索アイコンをクリックすると、「ターゲットの選択」ダイアログ・ボックスが表示されます。ターゲット名を指定するか、ターゲット表からターゲットを選択します。「ステータス」列の「フィルタ」矢印をクリックし、検索をフィルタリングして、すべての停止中のターゲットまたは稼働中のターゲットを検索できます。

「構成検索」アイコンをクリックして検索を構成することもできます。CDBを選択してから、「選択」をクリックします。

選択した現在のホストでのみASMターゲットを検索するか、ホスト・ターゲットがメンバーとして属しているクラスタ内のすべてのホスト上で検索するかを選択するオプションが表示されます。

このオプションにより、選択した現在のホストでのみASMターゲットを検索する場合には、時間を節約することができます。

「検出オプション」セクションでは検出ヒントを指定できます。デフォルトの検出動作を変更するために、追加の検出オプションを指定できます。サポートされているヒントは、db_name、db_target_prefix、db_target_suffix、discovery_timeout <ホスト当たりの秒単位>およびno_db_domain.です。

次に例を示します。

db_name=PRODUCTS, discovery timeout=15。

検出プロセスを続行するには、「次」をクリックします。

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

5. データベース検出: 結果ページに、クラスタASMターゲット上で検出されたターゲットが表示されます。
データベース検出: 結果ページの「クラスタASM」セクションで、昇格するターゲットを選択します。

デフォルトでは、昇格するためにクラスタASMターゲットを選択すると、それに関連付けられている、検出済のすべてのターゲットも昇格用に選択されます。昇格用に選択したターゲットのリストに対して追加または削除を行う必要がある場合、クラスタASMターゲットを選択して「構成」をクリックします。「インスタンス」タブを選択し、「追加」または「削除」をクリックします。「保存」をクリックします。

6. 「クラスタASM」セクションで、選択したクラスタ・ターゲットの監視資格証明(監視ユーザー名、監視パスワードおよびロール)を指定します。また、選択したターゲットをグループに追加する場合は、「グループ」の値を指定します。
「ロール」にNormalを指定した場合、ユーザー名にはdbsnmpを指定する必要があります。他のユーザー名は指定できません。ただし、「ロール」にSYSDBAを指定した場合は、任意のSYSDBAユーザーを指定できます。SYSDBAユーザーおよびdbsnmpユーザーのみが、ターゲット監視で必要な権限を持ちます。

7. 「テスト接続」をクリックし、指定した監視資格証明を使用してクラスタASMターゲットへの接続をテストします。

8. ターゲットの昇格: 結果ページで選択したすべてのターゲットに対してグローバル・ターゲット・プロパティを指定するには、「グローバル・ターゲットのプロパティの設定」をクリックし、必要なプロパティを指定して、「OK」をクリックします。
「ターゲットの昇格: 結果」ページで選択したすべてのターゲットに対して共通グループを指定するには、「ターゲットのグループの指定」をクリックし、グループを選択して、「選択」をクリックします。

9. 複数のターゲットを選択して、それらのすべてに同じ監視プロパティを設定するには、「一般的な監視資格証明の指定」を選択します。監視資格証明、監視パスワードおよびロールを入力します。「適用」をクリックします。

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

11. 表示された情報を確認して、「発行」をクリックします。

14.7.3 宣言的プロセスを使用したクラスタASMターゲットの追加

ターゲット・モニタリング・プロパティを指定してクラスタASMターゲットを宣言的に追加するには、次の手順を実行します。

注意:
データベース・システムはOracle Databaseの検出時に自動的に作成されます。システムは新しいターゲットおよびアソシエーション・モデル上に構築され、これを使用してデータベースの記憶域、接続性、高可用性を監視できます。これにより、データベースに依存しているアプリケーションの監視と管理も行えます。データベース・システム・トポロジを使用して、データベース・システム内の様々なエンティティ間の関係や外部依存性を確認できます。
データベース・システムには、プライマリ・データベースおよびリスナーや自動ストレージ管理などの関連ターゲットが含まれます。また、データベースがData Guard構成内にある場合は、スタンバイ・データベースおよびその関連ターゲットも含まれます。ただし、スタンバイ・データベースに対してデータベース・システムを作成することはできません。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ターゲットを宣言的に追加」を選択します。

3. 「ターゲットを宣言的に追加」ダイアログ・ボックスで、「クラスタASM」選択します。

4. 「監視エージェント」フィールドで、データベースを監視している管理エージェントを選択します。

5. 「追加...」をクリックします。

6. クラスタASMの構成: プロパティページで、クラスタASMの名前、Oracleホームのパス、ユーザー名とパスワード、ロール、クラスタ名およびサービス名を指定します。

注意:
「サービス名」は、クラスタASM接続を確立するために使用されます。クラスタASMがリスナーに登録しているサービス名の1つを指定する必要があります。

7. インスタンス、ASM IOサーバー・インスタンスおよびASMプロキシ・インスタンスを、対応するセクションで「追加」をクリックすることにより追加できます。
「テスト接続」をクリックし、指定した監視資格証明を使用してクラスタASMターゲットへの接続をテストします。

「OK」。

14.8 セキュアな監視のターゲット・データベースの構成

内容は次のとおりです。

- データベースのセキュアな監視について

- セキュアな監視のターゲット・データベースの構成

14.8.1 データベースのセキュアな監視について

Oracle Databaseでは、様々な暗号化アルゴリズムを使用して、Oracle Database Serverとクライアント間のネットワークを移動する情報を保護します。Enterprise Managerエージェントは、リアルタイム監視データを取得するためにTCPプロトコルを介してデータベース・ターゲットと通信します。また、Oracle Management Server (OMS)は、ターゲットを管理するためにネットワークを介してクリアテキストでデータベース・ターゲットと通信します。TCPはネットワークを介してクリアテキスト形式でデータを転送するため、誰でもデータにアクセスして変更できます。OMSと管理対象ターゲット間のデータ交換を保護するため、Enterprise Managerにより、TCPSプロトコルを使用してデータを暗号化して保護できます。

Enterprise Managerのセキュアな監視機能により、SSL(Secure Socket Layer)付きTCP/IPプロトコルを使用してセキュアなチャネルのOracle Databaseターゲットを監視できます。Enterprise Managerコンソールを使用して、TCPSポートで実行しているリスナー・プロセスを検出および監視することもできます。

ターゲット監視に使用できる次のオプションから選択できます。

- TCPを介したターゲット監視
この場合、Enterprise Managerは、TCPプロトコルを使用してターゲット監視用のターゲット・データベースに接続します。ターゲット・データベースとEnterprise Manager OMS間のデータ通信は、ネットワークを介してクリアテキスト形式で発生します。

- 信頼できる証明書を使用したサーバー認証を含むTCPSを介したターゲット監視
Enterprise Managerは、ターゲット監視にSecure Socket Layer(SSL)を介してターゲット・データベースTCPに接続します。この場合、クライアントは、サーバーの信頼できる証明書を使用してデータベース・サーバーを認証します。データは、Enterprise Managerと暗号化された形式のターゲット・データベース間のネットワークを介して通信します。

- Kerberosを使用したサーバー認証を含むTCPSを介したターゲットの監視
Enterprise Managerは、ターゲット監視にSecure Socket Layer(SSL)を介してターゲット・データベースTCPに接続します。この場合、クライアントは、Kerberos認証プロトコルを使用してデータベース・サーバーを認証します。データは、Enterprise Managerと暗号化された形式のターゲット・データベース間のネットワークを介して通信します。

ターゲット・データベースの検出中にセキュアな監視を有効化できます。また、「モニタリング構成」ページでターゲット・データベースのセキュアな監視設定を変更できます。

14.8.2 セキュアな監視のターゲット・データベースの構成

ターゲット・データベースの検出中か、検出後に選択したターゲット・データベースのセキュアな監視設定を変更して、セキュアな監視を有効化できます。検出したデータベース・ターゲットの設定を変更するには、次の手順に従います。

1. Enterprise Managerページの「ターゲット」メニューから、「データベース」を選択します。
「データベース」ページが表示されます。

2. 監視を構成するデータベースを選択します。
このデータベースの「データベース・ホーム」ページが表示されます。

3. 「Oracle Database」メニューで、「ターゲット設定」メニューから「モニタリング構成」を選択します。
「データベース・インスタンスの構成: プロパティ」ページが表示されます。

4. 「データベース・インスタンスの構成: プロパティ」ページで、「接続プロトコル」フィールドまでスクロールし、次のドロップダウン・メニューの選択内容のいずれかから選択します。

- TCP -- Enterprise Managerは、TCPプロトコルを使用してターゲット監視用のターゲット・データベースに接続します。ターゲット・データベースとEnterprise Manager OMS間のデータ通信は、ネットワークを介してクリアテキスト形式で発生します。

- TCPS -- Enterprise Managerは、ターゲット監視にSecure Socket Layer(SSL)を介してターゲット・データベースTCPに接続します。この場合、クライアントは、サーバーの信頼できる証明書を使用してデータベース・サーバーを認証します。データは、Enterprise Managerと暗号化された形式のターゲット・データベース間のネットワークを介して通信します。

- Kerberosを使用したサーバー認証を含むTCPS -- Enterprise Managerは、ターゲット監視にSecure Socket Layer(SSL)を介してターゲット・データベースTCPに接続します。この場合、クライアントは、Kerberos認証プロトコルを使用してデータベース・サーバーを認証します。データは、Enterprise Managerと暗号化された形式のターゲット・データベース間のネットワークを介して通信します。

5. オプションで、「接続テスト」をクリックして接続プロトコルの変更がデータベースの接続に影響を与えるかどうかを決定して、接続をテストできます。

6. 「次へ」をクリックして、「データベース・インスタンスの構成: 確認」ページに移動します。

7. 「発行」をクリックして変更を適用します。
データベース・ターゲットは選択したプロトコルを使用して接続します。

15 ミドルウェア・ターゲットの検出および追加

この章では、Fusion Middlewareターゲットを検出および追加して、Enterprise Manager Cloud Controlで管理できるようにする方法について説明します。この章の具体的な内容は次のとおりです。

- WebLogicドメインの検出および追加

- 新規または変更されたドメイン・メンバーの検出

- スタンドアロンOracle HTTP Serverの追加

- Exalyticsターゲットの追加

- ミドルウェア・ターゲットの削除

15.1 WebLogicドメインの検出および追加

この項では、WebLogicドメイン・ターゲットをCloud Controlで検出、昇格および追加するための様々な方法について説明します。この項の具体的な内容は次のとおりです。

- 自動検出を使用したWebLogicドメインの検出

- ガイド付き検出プロセスを使用したWebLogicドメインの追加

- EM CLIを使用した複数のWebLogicドメインの追加

15.1.1 自動検出を使用したWebLogicドメインの検出

WebLogicドメインを検出および昇格するには、次の手順を実行します。

注意: 自動検出機能は、Oracle WebLogicドメインのバージョン8.xではサポートされていません。

1. 「設定」メニューから、「ターゲットの追加」、「自動検出の構成」の順に選択します。

2. 「自動検出の構成」ページで、表の「Oracle Fusion Middleware」リンクを選択してOracle Fusion Middlewareの自動検出を構成するか、「ホストの検出の構成」列でアイコンをクリックして該当のOracle Fusion Middleware行を構成します。

3. 検出ジョブが実行されるスケジュールを日単位で設定します。このスケジュールは、選択されているすべてのホストに適用されます。デフォルトでは、ジョブは24時間ごとに実行されます。

4. 「ホストの追加」をクリックします。検出対象に追加するホスト・マシンを選択します。

5. 表内のホストを選択し、「パラメータの編集」をクリックして、ターゲットを検索するミドルウェア・ホームを指定します。ミドルウェア・ホームはOracle Fusion Middlewareの全製品の最上位のディレクトリで、Oracle WebLogicドメインのインストール時に作成されます。
*を入力してすべてのミドルウェア・ホームを検索するか、ホスト上にある1つ以上のミドルウェア・ホームのパスをそれぞれカンマで区切って指定します。

6. 画面の右側にある「OK」ボタンをクリックします。この時点で、自動検出は有効になり、スケジュールされた頻度で検出ジョブが実行されます。

7. 「設定」メニューから、「ターゲットの追加」、「自動検出の結果」の順にクリックします。

8. 「非ホスト・ターゲット」タブをクリックして、検出されたOracle Fusion Middlewareターゲットを表示します。

9. ターゲットを選択し、「昇格」をクリックします。
様々なタイプのターゲットが複数表示された場合は、「検索」を展開して目的のターゲット・タイプ(Oracle WebLogicドメインなど)を選択します。「検索」をクリックして、選択した検出済のターゲット・タイプを表示します。

10. 次のパラメータの値を指定するか受け入れます。

- 管理サーバー・ホスト
管理サーバーがインストールされて、管理対象ターゲットに昇格するOracle WebLogicドメインに対して動作するホスト名を入力します(myhost06.example.comなど)。

- ポート
WebLogic管理サーバーのポートを入力します。デフォルトは、7001です。

WebLogic管理サーバーがSecure Sockets Layer (SSL)プロトコルを使用して保護されている場合には、信頼できるキーストア・ファイルの場所を指定します。キーストアは、エンタープライズのキーと証明書を保持する保護されたデータベースです。「拡張パラメータ」を参照してください。

SSLで保護されたドメインの検出の詳細は、My Oracle Supportノート番号1093655.1のセクション「C」を参照してください。My Oracle Supportには、次のURLでアクセスできます。

http://support.oracle.com/CSP/ui/flash.html">>http://support.oracle.com/CSP/ui/flash.html

- WebLogic管理サーバーのユーザー名およびパスワードを入力します。
監視目的のみでターゲットを検出する場合は、監視ロールが付与されているユーザー名で実行できます。ターゲットの監視だけでなく、開始操作および停止操作も実行する場合は、オペレータ・ロールおよび管理者ロールが付与されているユーザー名を使用する必要があります。

注意: デフォルトのWebLogicユーザー名を入力した場合、アカウント・ロックの問題が生じる可能性があり、アカウント・パスワードは、ドメインやファームに対してEnterprise Manager監視資格証明を更新せずに変更されます。

- 一意のドメイン識別子。
「一意のドメイン識別子」を指定します。この値は、同じドメイン名を持つ環境内でファーム名を一意にするための接頭辞として使用されます。デフォルトでは、名前の先頭に「Farm」が付き、その後ろに2桁の数値が追加されます(例: Farm01)。

- エージェント
管理エージェントのホスト名(Fusion Middlewareターゲットの検出に使用)。

WebLogic管理サーバーのホストに管理エージェントが存在する場合は、その管理エージェントのホスト名がデフォルトで表示されます。ただし、Cloud Controlの管理対象ホスト上にある任意の管理エージェントを指定して、検出を実行できます。

注意: サポートされるすべての機能にアクセスするには、ドメイン内の各管理対象サーバーにローカルな管理エージェントを保持し、その管理エージェントを使用して該当のローカル・ホスト・マシン上のWebLogicドメインをモニタリングすることをお薦めします。リモート管理エージェントでWebLogicドメイン・ターゲットを管理できますが、ローカル管理エージェントをお薦めします。

ローカル管理エージェントがない場合、一部の機能がサポートされません。

- WebLogicドメインにパッチを適用するには、各WebLogic Serverマシンにローカル管理エージェントが必要です。

- WebLogicドメイン・ターゲットにOracle Support Workbenchを使用する場合、ターゲットにはローカル管理エージェントが必要です。

- クローニングでは、ソース管理サーバー・マシンでローカル管理エージェントが必要となり、すべての宛先マシンでローカル管理エージェントが必要になります。

拡張パラメータ

ターゲット・ドメインが保護されている場合には、「詳細」ノードを展開し、使用するプロトコルを「プロトコル」フィールドに指定します。デフォルト値はt3です。

Secure Sockets Layer (SSL)プロトコルを使用して保護されたドメインを検出する場合の詳細は、My Oracle Supportノート番号1093655.1のセクション「C」を参照してください。My Oracle Supportには、次のURLでアクセスできます。

https://support.oracle.com/CSP/ui/flash.html

- JMXプロトコル
管理サーバーへのJMX接続に使用されます。セキュアなドメインのJMXプロトコルの場合、t3sを使用します。WebLogicドメインでデモ証明書を使用している場合、この証明書は監視および検出エージェントに対して自動的に更新されます。カスタム証明書が使用される場合、証明書のインポート方法の詳細は、WebLogicドメインのモニタリングを参照してください。

- 停止したサーバーの検出
停止したサーバーを検出するには、このチェック・ボックスを使用します。Oracle Fusion MiddlewareのWebLogicドメイン・ターゲットをCloud Controlに追加する間に、停止状態で検出されるWebLogicドメイン・ターゲットを追加するかどうかを選択できるようになりました。これにより、管理および監視の一元化のためにCloud Controlに何を自動的に追加するかを制御できます。

停止したサーバーを監視するには、そのリスナー・アドレスを設定する必要があります。設定しない場合、これらのサーバーのホスト値はtemp-hostとなり、監視用のローカル・エージェントを決定できません。そのため、サーバーは常に停止状態で表示されます。

サーバーが起動すると、正しいホスト名の移入と監視を行うためにこのWebLogicドメインをリフレッシュする必要があります。

- JMXサービスURL
オプションで、WebLogic管理サーバーへのJMX接続を確立する際に使用するJava Managment Extensions(JMX)のサービスURLを指定します。次に例を示します。

service:jmx:t3://server.example.com:5555/jndi/WebLogic.management.mbeanservers.domainruntime

このURLを指定しない場合は、ホストのポートとプロトコルに基づいてEnterprise ManagerがサービスURLを決定します。このURLを指定する場合、管理サーバーのホストとポート情報を引き続き入力パラメータに指定する必要があります。

- アプリケーションのバージョンの検出
デフォルトでは、デプロイされたJava EEアプリケーションの各バージョンは、ターゲットとして検出されます。そのため、新しいバージョンごとに、新しいターゲットが検出されます。アプリケーションのアクティブ・バージョンのみ検出する場合、このチェック・ボックスの選択を解除します。

- 自動リフレッシュの有効化
このオプションにより、WebLogicドメインを24時間ごとにリフレッシュします。

- サービスURLにホスト名を使用
JMXのかわりにサービスURLにホスト名を指定できます。プライベート・ネットワークを使用しており、多くのホストが同じIPアドレスを使用している場合には、このオプションを使用することをお薦めします。

- 検出失敗のインシデントを作成
このオプションにより、検出が失敗した場合にOMSインシデントを作成します。インシデントは、サポート・ワークベンチ・ページから表示できます。

- 外部パラメータ
オプションで、JavaプロセスがWebLogic管理サーバーへの接続に使用するシステム・プロパティを、「パラメータ」フィールドに入力します。

空白で区切った名前/値ペアを指定します。各パラメータの先頭には-Dを付けます。次に例を示します。

-Dparam1=xxx -Dparam2=yyy -Dparam3=zzz

- 検出デバッグ・ファイル名
ミドルウェア関連ターゲットの追加中、またはドメイン・メンバーシップのリフレッシュ中に問題が発生した場合、追加のデバッグ情報を使用してすばやく問題を診断し、解決できます。このファイルは、検出エージェントのログ・ディレクトリに作成されます。

11. 「続行」をクリックします。ドメイン内のFusion Middlewareのターゲットがすべて検出されます。

12. 「ターゲットの検索中」ダイアログで「閉じる」をクリックすると、検出されたターゲットに管理エージェントが自動的に割り当てられます。
エージェントの割当てページには、検出されたFusion Middlewareの各ターゲットと、それぞれに割り当てられた管理エージェントがリストされます。エージェントは、自動的に次のように割り当てられます。

- 検出されたターゲット・ホスト上にローカルの管理エージェントがインストールされている場合は、そのエージェントが割り当てられます。

- ホスト上でローカルの管理エージェントを検出できない場合、「ターゲット」ページで指定されたエージェントが割り当てられます。

管理エージェントを特定のターゲットに手動で割り当てることもできます。

13. 「ターゲットの追加」をクリックすると、エージェントの割当てページにリストされたとおりに管理エージェントが割り当てられます。
エージェントにターゲットを保存中処理ウィンドウが表示され、追加されて正常に保存されたターゲットの合計数が示されます。また、追加できなかったターゲットの数も示されます。

14. 完了したら、処理ウィンドウで「閉じる」をクリックします。結果ページに、ターゲットとエージェントの割当てが表示されます。

15. 終了したら、「OK」をクリックします。ターゲットが表示されて管理されるようになるまで、遅延がある場合もあります。ターゲットの監視に使用するエージェントはすべて稼働している必要があります。

注意:
最初にミドルウェア・ターゲットを検出した後は、検出されたターゲットの監視および管理に関するベスト・プラクティスを習得することをお薦めします。ターゲット・ホームページから「ターゲット管理のベスト・プラクティス」ページに移動するには、「WebLogicドメイン」メニューを選択し、「ターゲット管理のベスト・プラクティス」を選択します。このページには、Fusion Middlewareドメインのベスト・プラクティス項目がリストされます。

15.1.2 ガイド付き検出プロセスを使用したWebLogicドメインの追加

Oracle WebLogicドメインおよびその各コンポーネントは、Cloud Controlを使用して検出できます。ウィザードによって、ガイド付き検出プロセス全体の手順が示されます。

注意:
Fusion Middleware 13cの検出では、動的サーバー、CAM (Common Administration Model)管理コンポーネントおよびドメイン・アプリケーションと呼ばれる新しいターゲット・タイプも検出されます。
ドメイン・アプリケーションは、ドメインへのターゲットのデプロイメントを表します。

Fusion Middleware 12cの検出では、Cloud ControlがFusion Middleware WebLogicドメインを検出する場合、WebLogicドメインでデプロイされる各Java EEアプリケーションのドメイン・アプリケーション・ターゲットを作成します。任意の数のサーバーにデプロイされるJava EEアプリケーションの場合、1つのドメイン・アプリケーション・ターゲットのみ検出されます。

注意:
WebLogic Domainを検出するには、管理エージェントでJMX接続を行う必要があるため、管理サーバーが稼働中である必要があります。管理サーバーが停止している場合、検出は行われません。
その後、WebLogic Domainを監視する場合、管理サーバーが稼働中である必要はありません。

ガイド付きプロセスを使用してWebLogicドメインを追加するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ガイド付きプロセスを使用した追加」オプションを選択します。

3. 「ガイド付きプロセスを使用した追加」ダイアログ・ボックスで、ターゲット・タイプとして「Oracle Fusion Middleware/WebLogicドメイン」を選択します。

4. 「追加」をクリックします。

5. 次のパラメータの値を指定するか受け入れます。

- 管理サーバー・ホスト
管理サーバーがインストールされて、管理対象ターゲットに昇格するOracle WebLogicドメインに対して動作するホスト名を入力します(myhost06.example.comなど)。

- ポート
WebLogic管理サーバーのポートを入力します。デフォルトは7001です。

WebLogic管理サーバーがSecure Sockets Layer (SSL)プロトコルを使用して保護されている場合には、信頼できるキーストア・ファイルの場所を指定します。キーストアは、エンタープライズのキーと証明書を保持する保護されたデータベースです。「拡張パラメータ」を参照してください。

Secure Sockets Layer (SSL)プロトコルを使用して保護されたドメインを検出する場合の詳細は、My Oracle Supportノート番号1093655.1のセクション「C」を参照してください。My Oracle Supportには、次のURLでアクセスできます。

https://support.oracle.com/CSP/ui/flash.html

- WebLogic管理サーバーのユーザー名およびパスワードを入力します。
監視目的のみでターゲットを検出する場合は、監視ロールが付与されているユーザー名で実行できます。ターゲットの監視だけでなく、開始操作および停止操作も実行する場合は、オペレータ・ロールおよび管理者ロールが付与されているユーザー名を使用する必要があります。

- 一意のドメイン識別子。
「一意のドメイン識別子」を指定します。この値は、同じドメイン名を持つ環境内でファーム名を一意にするための接頭辞として使用されます。デフォルトでは、名前の先頭に「Farm」が付き、その後ろに2桁の数値が追加されます(例: Farm01)。

- エージェント
Fusion Middlewareターゲットの検出に使用される管理エージェントのホスト名。管理エージェントがWebLogic管理サーバー・ホストに存在する場合、この管理エージェントのホスト名がデフォルトで提供されます。ただし、Cloud Controlの管理対象ホスト上にある任意の管理エージェントを指定して、検出を実行できます。

注意: サポートされるすべての機能にアクセスするには、ドメイン内の各管理対象サーバーにローカルな管理エージェントを保持し、その管理エージェントを使用して該当のローカル・ホスト・マシン上のWebLogicドメインをモニタリングすることをお薦めします。リモート管理エージェントでWebLogicドメイン・ターゲットを管理できますが、ローカル管理エージェントをお薦めします。

ローカル管理エージェントがない場合、一部の機能がサポートされません。

- WebLogicドメインにパッチを適用するには、各WebLogicドメイン・マシンにローカル管理エージェントが必要です。

- WebLogicドメイン・ターゲットにOracle Support Workbenchを使用する場合、ターゲットにはローカル管理エージェントが必要です。

- クローニングでは、ソース管理サーバー・マシンでローカル管理エージェントが必要となり、すべての宛先マシンでローカル管理エージェントが必要になります。

拡張パラメータ

ターゲット・ドメインが保護されている場合には、「詳細」ノードを展開し、使用するプロトコルを「プロトコル」フィールドに指定します。デフォルト値はt3です。

Secure Sockets Layer (SSL)プロトコルを使用して保護されたドメインを検出する場合の詳細は、My Oracle Supportノート番号1093655.1のセクション「C」を参照してください。My Oracle Supportには、次のURLでアクセスできます。

https://support.oracle.com/CSP/ui/flash.html

- JMXプロトコル
管理サーバーへのJMX接続に使用されます。セキュアなドメインのJMXプロトコルの場合、t3sを使用します。WebLogicドメインでデモ証明書を使用している場合、この証明書は監視および検出エージェントに対して自動的に更新されます。

- 停止したサーバーの検出
停止したサーバーを検出するには、このチェック・ボックスを使用します。Oracle Fusion MiddlewareのWebLogicドメイン・ターゲットをCloud Controlに追加する間に、停止状態で検出されるWebLogicドメイン・ターゲットを追加するかどうかを選択できるようになりました。これにより、管理および監視の一元化のためにCloud Controlに何を自動的に追加するかを制御できます。

停止したサーバーを監視するには、そのリスナー・アドレスを設定する必要があります。設定しない場合、これらのサーバーのホスト値はtemp-hostとなり、監視用のローカル・エージェントを決定できません。そのため、サーバーは常に停止状態で表示されます。

サーバーが起動すると、正しいホスト名の移入と監視を行うためにこのWebLogicドメインをリフレッシュする必要があります。

- アプリケーションのバージョンの検出
デフォルトでは、デプロイされたJava EEアプリケーションの各バージョンは、ターゲットとして検出されます。そのため、新しいバージョンごとに、新しいターゲットが検出されます。アプリケーションのアクティブ・バージョンのみ検出する場合、このチェック・ボックスの選択を解除します。

- JMXサービスURL
オプションで、WebLogic管理サーバーへのJMX接続を確立する際に使用するJava Managment Extensions(JMX)のサービスURLを指定します。次に例を示します。

service:jmx:t3://server.example.com:5555/jndi/WebLogic.management.mbeanservers.domainruntime

値を指定しない場合は、ホストのポートとプロトコルに基づいてEnterprise ManagerがサービスURLを決定します。このURLを指定する場合、管理サーバーのホストとポート情報を引き続き入力パラメータに指定する必要があります。

- アプリケーションのバージョンの検出
デフォルトでは、デプロイされたJava EEアプリケーションの各バージョンは、ターゲットとして検出されます。そのため、新しいバージョンごとに、新しいターゲットが検出されます。アプリケーションのアクティブ・バージョンのみ検出する場合、このチェック・ボックスの選択を解除します。

- 自動リフレッシュの有効化
このオプションにより、WebLogicドメインを24時間ごとにリフレッシュします。

- サービスURLにホスト名を使用
JMXのかわりにサービスURLにホスト名を指定できます。プライベート・ネットワークを使用しており、多くのホストが同じIPアドレスを使用している場合には、このオプションを使用することをお薦めします。

- 検出失敗のインシデントを作成
このオプションにより、検出が失敗した場合にOMSインシデントを作成します。インシデントは、サポート・ワークベンチ・ページから表示できます。

- 外部パラメータ
オプションで、JavaプロセスがWebLogic管理サーバーへの接続に使用するシステム・プロパティを、「パラメータ」フィールドに入力します。

空白で区切った名前/値ペアを指定します。各パラメータの先頭には-Dを付けます。次に例を示します。

-Dparam1=xxx -Dparam2=yyy -Dparam3=zzz

- 検出デバッグ・ファイル名
ミドルウェア関連ターゲットの追加中、またはドメイン・メンバーシップのリフレッシュ中に問題が発生した場合、追加のデバッグ情報を使用してすばやく問題を診断し、解決できます。

6. 「続行」をクリックします。ドメイン内のFusion Middlewareのターゲットがすべて検出されます。

7. 「ターゲットの検索中」ダイアログで「閉じる」をクリックすると、検出されたターゲットに管理エージェントが自動的に割り当てられます。
エージェントの割当てページには、検出されたFusion Middlewareの各ターゲットと、それぞれに割り当てられた管理エージェントがリストされます。エージェントは、自動的に次のように割り当てられます。

- 検出されたターゲット・ホスト上にローカルの管理エージェントがインストールされている場合は、そのエージェントが割り当てられます。

- ホスト上でローカルの管理エージェントを検出できない場合、「ターゲット」ページで指定されたエージェントが割り当てられます。

管理エージェントを特定のターゲットに手動で割り当てることもできます。

8. 「ターゲットの追加」をクリックすると、エージェントの割当てページにリストされたとおりに管理エージェントが割り当てられます。
エージェントにターゲットを保存中処理ウィンドウが表示され、追加されて正常に保存されたターゲットの合計数が示されます。また、追加できなかったターゲットの数も示されます。

9. 完了したら、処理ウィンドウで「閉じる」をクリックします。結果ページに、ターゲットとエージェントの割当てが表示されます。

10. 終了したら、「OK」をクリックします。ターゲットが表示されて管理されるようになるまで、遅延がある場合もあります。ターゲットの監視に使用するエージェントはすべて稼働している必要があります。

注意:
最初にミドルウェア・ターゲットを検出した後は、検出されたターゲットの監視および管理に関するベスト・プラクティスを習得することをお薦めします。ターゲット・ホームページから「ターゲット管理のベスト・プラクティス」ページに移動するには、「WebLogicドメイン」メニューを選択し、「ターゲット管理のベスト・プラクティス」を選択します。このページには、Fusion Middlewareドメインのベスト・プラクティス項目がリストされます。

15.1.3 EM CLIを使用した複数のWebLogicドメインの追加

Cloud Controlを使用して複数のWebLogicドメインを管理する場合は、Enterprise Managerコマンドライン・インタフェース(EM CLI)のdiscover_wls動詞を使用すると、検出ウィザードで1つずつ検出せずに、すべてまとめて検出できます。

discover_wls動詞を使用して、WebLogicドメインのバージョン7.x、8.x、9.xおよび10.xを検出できます。この動詞は、各ドメインの検出に必要な情報が含まれているdomain_discovery_fileという名前のファイルを読み取ります。

discover_wls動詞の使用方法の手順は、『Oracle Enterprise Managerコマンドライン・インタフェース』マニュアルを参照してください。

15.2 新規または変更されたドメイン・メンバーの検出

一般的なエンタープライズの場合、Oracle WebLogicドメインが一定のままであることはありません。むしろ、新しいJava EEアプリケーションがデプロイされる、WebLogicドメイン・インスタンスが作成または削除される、クラスタが追加されるなど、ドメインのメンバーシップは常に変化しています。

デフォルトでは、Cloud Controlは、管理対象ターゲットとして構成されているOracle WebLogicドメインの変更を自動的に認識しません。ただし、アプリケーションは新規または変更されたドメイン・メンバーを検出および取り込む機能を備えています。

内容は次のとおりです。

- 新規ドメイン・メンバーの自動検出を有効化

- 新規または変更されたドメイン・メンバーの手動チェック

15.2.1 新規ドメイン・メンバーの自動検出の有効化

「WebLogicドメインのリフレッシュ」という名前で事前定義されているCloud Controlジョブを有効にすると、新しいドメイン・メンバーを自動的に検出し、管理対象ターゲットとして追加することができます。

注意:
リフレッシュ操作を実行する場合は、必ず管理サーバーを起動し、JMXを使用して検出エージェントと管理サーバーを接続できるようにしておく必要があります。

1. 「ターゲット」メニューから「ミドルウェア」を選択します。

2. ミドルウェア・ホームページで、ジョブを有効にするWebLogicドメインをクリックします。

3. ページの「一般」リージョンで、「WebLogicドメインがリフレッシュされました」プロパティの隣にあるタイムスタンプのリンクをクリックします。「WebLogicドメインのリフレッシュ」ダイアログが開きます。

4. 「WebLogicドメインのリフレッシュ」ダイアログで「自動リフレッシュの有効化」ボックスを選択し、「OK」をクリックします。

ジョブを有効にすると、デフォルトでは24時間ごとに新しいドメイン・メンバーがチェックされます。実行頻度などのジョブ設定を変更するには:

1. 「ジョブ」タブをクリックします。

2. ジョブ・アクティビティ・ページで、ジョブのタイトルをクリックします。

3. 「編集」をクリックします。

15.2.2 新規または変更されたドメイン・メンバーの手動チェック

Cloud Controlを使用すると、新規または変更されたメンバーを定期的にチェックできます。

1. 「ターゲット」メニューから「ミドルウェア」を選択します。

2. リフレッシュする(「ミドルウェア」ホームページでジョブを有効にする)WebLogicドメインをクリックします。

3. 「ファーム」または「WebLogicドメイン」メニューから「WebLogicドメインのリフレッシュ」を選択します。「WebLogicドメインのリフレッシュ」ダイアログが開きます。

4. 「ターゲットの追加/更新」をクリックします。管理エージェントは、管理サーバーに接続することでリフレッシュします。リフレッシュを行うには、管理サーバーを起動する必要があります。「確認」ページで「閉じる」をクリックします。ドメイン内の新規および変更されたターゲットが検索されます。
WebLogicのj2eeaserverやj2eeappなど、ドメインのエンティティがWebLogicドメインから削除されても、それらはEnterprise Managerに表示されたままになります。これらのターゲットの履歴データが不要な場合は、「ターゲットの削除」をクリックします。ドメインから削除できる不要なターゲットが表示されます。

5. 「検出デバッグ・ファイル名」オプション
ミドルウェア関連ターゲットの追加中、またはドメイン・メンバーシップのリフレッシュ中に問題が発生した場合、追加のデバッグ情報を使用してすばやく問題を診断し、解決できます。このファイルは、検出エージェントのログ・ディレクトリに作成されます。

6. 「エージェントの割当て」ページには、検出されたFusion Middlewareターゲットと、それぞれに割り当てられた管理エージェントが表示されます。「ターゲットの追加」をクリックすると、エージェントの割当てページにリストされたとおりに管理エージェントが割り当てられます。
エージェントは、自動的に次のように割り当てられます。

- ローカル・エージェントをターゲット・ホストで検出できた場合、そのエージェントが割り当てられます。

- ホスト上でローカル・エージェントを検出できない場合、「ターゲット」ページで指定されたエージェントが割り当てられます。

エージェントを特定のターゲットに手動で割り当てることもできます。

このページでは、「選択検出」のオプションも提供されます。このオプションを使用すると、新しいターゲット・タイプのみの検出を無効にできます。

ドメインのグローバル・プロパティ(「連絡先」、「コスト・センター」、「ライフサイクル・ステータス」など)を変更することもできます。

7. 「エージェントにターゲットを保存中」処理ウィンドウが表示され、追加されて正常に保存されたターゲットの合計数が示されます。また、追加できなかったターゲットの数も示されます。

8. 完了したら、処理ウィンドウで「閉じる」をクリックします。「結果」ページには、「ターゲット詳細の表示」と「WebLogicドメインのグローバル・プロパティの表示」のオプションが表示されます。「ターゲット詳細の表示」ページには、ターゲットとエージェントの割当てが表示されます。
注意: 削除されたターゲットがあった場合、「WebLogicドメインのリフレッシュ」ページに戻り、「ターゲットの削除」をクリックして管理リポジトリのターゲットと履歴情報を削除できます。「ミドルウェア・ターゲットの削除」を参照してください。

9. 終了したら、「OK」をクリックします。ターゲットが表示されて管理されるようになるまで、遅延がある場合もあります。ターゲットの監視に使用するエージェントはすべて稼働している必要があります。
検出が終了したら、ドメインを監視する前に、ドメインの監視資格証明を設定する必要があります。これを行うには、WebLogicドメインのホームページで、「WebLogicドメイン」メニューから、「ターゲット設定」を選択し、「モニタリング資格証明」をクリックします。

15.3 スタンドアロンOracle HTTP Serverの追加

スタンドアロンのOracle HTTP Serverを追加するには、次の手順を実行します。

- 前提条件の確認

- ガイド付き検出プロセスを使用したスタンドアロンのOracle HTTP Serverの追加

注意:
スタンドアロンのOracle HTTP Serverを検出および管理する方法に関するデモを表示するには、次のURLにアクセスし、ビデオの開始をクリックします。このデモで説明する検出は、Enterprise Manager Cloud Control 12cリリース2 (12.1.0.3)およびOracle Fusion Middleware Plug-in 12.1.0.5に基づきます。
http://apex.oracle.com/pls/apex/f?p=44785:24:0::::P24_CONTENT_ID,P24_PREV_PAGE:8529,1">>http://apex.oracle.com/pls/apex/f?p=44785:24:0::::P24_CONTENT_ID,P24_PREV_PAGE:8529,1

15.3.1 前提条件の確認

スタンドアロンのOracle HTTP Serverを検出する前に、次の前提条件を確認します。

- スタンドアロンのOracle HTTP Serverが稼働しているホスト上にOracle Management Agent (管理エージェント)がインストールされていることを確認します。管理エージェントをインストールする手順は、Enterprise Managerドキュメント・ライブラリにある『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

- 検出しようとしているスタンドアロンのOracle HTTP Serverが次のリリースのいずれかであることを確認します: 11.1.1.1、11.1.1.2、11.1.1.3、11.1.1.4、11.1.1.5、11.1.1.6、11.1.1.7、12.1.2。

15.3.2 ガイド付き検出プロセスを使用したスタンドアロンのOracle HTTP Serverの追加

スタンドアロンのOracle HTTP Serverを追加するには、次の手順を実行します。

注意:
この方法を使用すると、スタンドアロンのOracle HTTP Serverのみを追加できます。管理対象のOracle HTTP Serverを追加するには、WLS検出ウィザードを使用します。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、ガイド付きプロセスを使用して追加(関連ターゲットも追加)を選択します。

3. 「ターゲット・タイプ」リストでスタンドアロンのOracle HTTP Serverを選択します。

4. 「ガイド付きプロセスを使用した追加」をクリックします。

5. スタンドアロンのOracle HTTP Serverの追加ページで、次の詳細情報を指定して、「ターゲットの追加」をクリックします。

要素

説明

Oracle HTTP Serverホスト

検索アイコンをクリックして、スタンドアロンのOracle HTTP Serverが稼働しているホストを検索して選択します。「検索と選択: ターゲット」ダイアログで、ホストを検索して選択し、「選択」をクリックします。
例: example.com

エージェントURL

スタンドアロンのOracle HTTP Serverが稼働しているホスト上にインストールされている管理エージェントのURL。スタンドアロンのOracle HTTP Serverのホストを選択するとデフォルトで自動的に表示されます。
例: https://example.com:1838/emd/main/

Oracle HTTP Serverポート

Oracle HTTP Serverポートを指定します。Oracle HTTP Serverポートは検証されていません。正しい値を指定する必要があります。

ターゲット名

Enterprise Manager Cloud ControlでスタンドアロンのOracle HTTP Serverターゲットの追加およびモニターに使用する名前を指定します。
例: Standalone_OHS1

スタンドアロンのOracle HTTP Serverを検出して、Enterprise Manager Cloud Controlに追加したら、「ターゲット」メニューから「すべてのターゲット」を選択します。すべてのターゲット・ページの「ターゲット名の検索」フィールドに、検出して追加したスタンドアロンのOracle HTTP Serverターゲットの名前を入力し、[Enter]を押します。Enterprise Manager Cloud Controlによって、スタンドアロンのOracle HTTP Serverのホームページが表示されます。ここでは、検出と追加の際に指定したターゲット名が使用されます。

Oracleホーム

検索アイコンをクリックして、スタンドアロンのOracle HTTP Serverのホストにログインし、スタンドアロンのOracle HTTP Serverが稼働しているOracleホームを選択します。
例: /u01/software/oracle/Standalone_OHS1

構成パス

検索アイコンをクリックして、スタンドアロンのOracle HTTP Serverのホストにログインし、httpd.confファイルを選択します。このフィールドの値は、原則としてhttpd.confファイルへの絶対ディレクトリ・パスを指定する必要があります。
例: /u01/software/oracle/Standalone_OHS1/Oracle_WT1/instances/instance1/config/OHS/ohs1/httpd.conf

バージョン

ターゲットのバージョンを選択します。11.xターゲットを選択した場合、「OHSプロセス所有者の資格証明」を指定するか、使用可能なOHSプロセス所有者/SSHキーの資格証明のリストから選択する必要があります。12cターゲットを選択した場合、「ノード・マネージャ資格証明」を指定する必要があります。

OHSプロセス所有者の資格証明

(このフィールドは、スタンドアロンのOracle HTTP Server 11.xターゲットの検出専用です)
OHSプロセス所有者の資格証明を指定します。これらの資格証明はオプションで、ターゲットのメトリックを収集する際に必要です。これらの資格証明は、ターゲットのモニタリング資格証明として格納され、モニタリング資格証明ページから更新可能です。

SSHキー資格証明を使用するには、「セキュリティ」タブにアクセスし、「資格証明」を選択し、名前付き資格証明ページに移動して、SSHホスト資格証明を作成します。

ノード・マネージャのユーザー名

(このフィールドは、スタンドアロンのOracle HTTP Server 12c (12.1.2)を検出するためのものです)
ノード・マネージャのユーザー名を指定します。

ノード・マネージャ・パスワード

(このフィールドは、スタンドアロンのOracle HTTP Server 12c (12.1.2)を検出するためのものです)
ノード・マネージャのパスワードを指定します。

15.4 Exalyticsターゲットの追加

WebLogicドメイン、Oracle BI Foundation 11g、Oracle TimesTen (インメモリー・データベース)などのExalyticsで実行されているOracle Fusion Middlewareコンポーネントを管理および監視するには、それらのコンポーネントを含むExalyticsマシンがCloud Controlによってまず検出される必要があります。

Exalyticsシステムは1台以上のExalyticsマシンで構成されています。マシンは物理マシンであることも、仮想マシンであることも、その両方が混在していることもあります。

検出されると、Exalytics Machineとその内部のコンポーネントは、管理対象ターゲットというステータスに昇格され、Cloud Controlでターゲットを監視するために必要なデータを収集できます。

Exalyticsマシンで稼働しているOBIEE、Times TenおよびWebLogicなどの関連するターゲットを、それらのコンポーネントの各フローに従って、検出する必要があります。Exalyticsターゲットが検出済の場合、関連するターゲットは、それらが検出されたときにExalyticsターゲットに関連付けられます。Exalyticsターゲットが検出されていない場合、関連付けはExalyticsターゲットが検出されたときに発生します。

Exalyticsターゲットを追加するには、次の手順を実行します。

- 前提条件の確認

- ガイド付き検出プロセスを使用したExalyticsシステム・ターゲットの追加

15.4.1 前提条件の確認

Exalyticsマシン・ターゲットを追加するには、次の前提条件を満たす必要があります。

- ターゲットを検出する管理エージェントを物理Exalyticsマシン(ホスト)にデプロイする必要があります。
仮想マシンを検出するには、少なくとも1つの仮想Exalyticsに実行されている管理エージェントがあることを確認してください。管理エージェントは、仮想ExalyticsデプロイメントのVMゲスト部分の1つ上に存在する必要があります。ただし、監視対象となるコンポーネントを含むすべての仮想マシンに、管理エージェントをデプロイする必要があります。

- Exalyticsマシンを識別するには、ExalyticsマシンIDを含むコンテキスト情報ファイルがあることを確認してください。

- 仮想Exalyticsマシン用のILOMを検出および監視するには、VMゲストにIMPITOOLをインストールする必要があります。IMPITOOLをインストールするには、次の手順を実行します。

1. VMゲストのオペレーティングシステムと互換性のある最新のHardware Management Packをダウンロードします。Hardware Management Packをダウンロードする手順は、http://www.oracle.com/technetwork/server-storage/servermgmt/downloads/index.html">>http://www.oracle.com/technetwork/server-storage/servermgmt/downloads/index.htmlから入手できます。

2. ダウンロードしたzipファイルからIMPITOOLパッケージ抽出して、VMゲストのオペレーティング・システムにインストールします。

15.4.2 ガイド付き検出プロセスを使用したExalyticsシステム・ターゲットの追加

ExalyticsシステムでExalyticsシステム・ターゲットを追加するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」を選択し、次に「ターゲットの手動追加」を選択します。

2. 「ターゲットの手動追加」ページで、ガイド付きプロセスを使用して追加(関連ターゲットも追加)を選択します。

3. 「ターゲット・タイプ」ドロップダウン・リストから「Exalyticsシステム」を選択し、「ガイド付きプロセスを使用した追加」をクリックします。

4. Exalyticsシステムの検出ページで、Exalyticsシステムの名前を指定して、マシンの追加をクリックします。

5. 次の詳細を指定します。

- マシン名
Oracle Exalyticsマシン・ターゲットの一意を指定します。

- エージェント
Oracle Exalytics Machine検出プロセスに使用する管理エージェントを指定または選択します。

- デプロイメント・タイプ
物理ターゲットまたは仮想ターゲットのどちらを検出するかに応じて、「物理」または「仮想」を選択します。

- ホスト名(仮想ターゲットのみ)
Oracle Virtual Serverを実行しているホスト名またはIPアドレスを入力します。

- ユーザー名とパスワード
物理Exalyticsマシンの場合は、imageinfoコマンドを実行する権限を有するルート・ユーザーの資格証明を指定します。

仮想Exalyticsマシンの場合は、Oracle Virtual Server (OVS)にログインするための資格証明を指定します。ユーザーはimageinfoコマンドを実行する権限を持っている必要があります。

- ILOM資格証明
ILOMのIPアドレスまたはホスト名、ルート・ユーザーのILOMユーザー名およびILOMパスワードを指定します。

注意:
「ILOM資格証明」はオプションです。ILOM資格証明を追加しないと、ILOMターゲットは検出されません。
ILOMターゲットは、「Exalyticsシステムのリフレッシュ」オプションを使用して後で追加できます。

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

6. 「確認」ボックスが表示されます。「OK」をクリックします。

注意:
「ターゲットの追加」をクリックして、管理可能なエンティティとしてターゲットを保存します。

15.5 ミドルウェア・ターゲットの削除

管理リポジトリからミドルウェア・ターゲットを削除するには、次の手順を実行します。

- WebLogicドメインから削除されるターゲット(WebLogic Server、クラスタ、アプリケーション(汎用およびカスタムの両方)、その他のシステム・コンポーネントなど)を特定します。

- 製品から削除された可能性のあるターゲットのリストを示します。ただし、Enterprise Managerは、これらのターゲットが削除されたかどうかを判断できません。このようなターゲットの場合、削除する必要があるかどうかを決定し、削除するものをマーク付けします。

- 重複したターゲットを表示します。たとえば、同じアプリケーション・デプロイメントでカスタム・ターゲットと汎用ターゲットがある場合、削除可能な汎用ターゲットが表示されます。

- 同じアプリケーションで新しいバージョンが存在する場合、それよりも古いバージョンのアプリケーション・デプロイメントで削除可能なものを表示します。

- 停止したサーバーをすべてリストします。これらのサーバーをブラックアウトするか削除するかを決定できます。

16 システム・インフラストラクチャ・ターゲットの検出、昇格および追加

この章では、Cloud Controlを使用してシステム・インフラストラクチャ・ターゲットを検出、昇格および追加する方法について説明します。この章の内容は次のとおりです。

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加について

- オペレーティング・システムの検出および昇格

- Oracle Solarisゾーンの検出および昇格

- Oracle VM Server for SPARCの検出および昇格

- サーバーの検出および昇格

- Oracle SuperClusterの検出および昇格

- PDUの検出および昇格

- Oracle ZFS Storageの検出および昇格

- ファブリックの検出

- システム・インフラストラクチャ・ターゲットの検出および昇格の関連リソース

16.1 システム・インフラストラクチャ・ターゲットの検出、昇格および追加について

Cloud Controlを使用すると、Oracle VM Server for SPARC、Oracle Solarisゾーン、Oracle SuperCluster、サーバー、オペレーティング・システム、ストレージ、ネットワーク、ラック、電力配分装置(PDU)などの、様々なシステム・インフラストラクチャ・ターゲットをモニタリングできます。システム・インフラストラクチャ・ターゲットを追加する手順は、ほとんどのターゲットについて同じです。ただし、いくつかのターゲットには特別な手順が必要です。

完全に管理されている場合、システム・インフラストラクチャ・ターゲットはモニタリング可能であり、Oracle SolarisやLinuxのオペレーティング・システム、仮想化されたオペレーティング・システム(ゾーン)や仮想マシン(論理ドメイン)、サーバー、記憶域アプライアンス、ホストの記憶域、ネットワーク・リソースなどのスタックの下半分について、エンタープライズ全体のビューを提供します。

注意:
ILOMサーバーまたは仮想化ターゲットをモニタリングするには、sudo権限を持つEMエージェントをデプロイするか、または手動でroot.shスクリプトをインストールして実行します。
モニタリングするには、root.shスクリプトを実行して、nmrバイナリをインストールする必要があります。sudo権限を持つEMエージェントをデプロイするとき、root.shスクリプトが実行されます。

検出されたすべてのターゲットのモニタリングを開始するためにかかる時間は、環境、構成およびゲスト数に応じて異なります。仮想化ターゲットの場合、仮想化プラットフォームの「サマリー」ダッシュレットに、モニタリングされているゲストの合計数が表示されます。プラットフォーム上で、ゲストが検出され、構成されているものの、まだモニタリングされていない場合は、アイコンと、モニタリングが保留されているゲストの数が、ダッシュレットに表示されます。たとえば、図16-1では、ホスト上に63のゲストが構成されており、これらのゲストのうち16がまだモニタリングされていません。すべてのゲストがモニタリングされている場合、ダッシュレットにアイコンは表示されません。

図16-1 モニタリング対象のゲスト数が表示された「サマリー」ダッシュレット

16.2 オペレーティング・システムの検出および昇格

Oracle SolarisおよびLinuxのオペレーティング・システムは、ホスト検出と昇格プロセスの一環として検出および昇格されます。ホスト・ターゲットの検出、昇格およびその手順の詳細は、「ホスト・ターゲットと非ホスト・ターゲットの検出および追加」を参照してください。

16.3 Oracle Solarisゾーンの検出および昇格

Oracle Solarisゾーンの検出および昇格は、ホスト検出に依存します。グローバル・ゾーン上のホストが昇格されると、ゾーンの検出とモニタリングがトリガーされます。

注意:
サポートされているすべてのOracle Solaris Zoneモニタリングを活用するには、グローバル・ゾーン上のOracle Solarisリリースは、Oracle Solaris 10 Update 11以降である必要があります。
ゾーン・ターゲットを検出およびモニタリングするには、sudo権限を持つEMエージェントをデプロイするか、または、手動でroot.shスクリプトをインストールして実行します。

ホストがゾーン内にある場合は、仮想サーバー・ターゲットを追加する前に、グローバル・ゾーンを検出する必要があります。この仮想サーバーに関連付けられている仮想プラットフォームが存在しないことを示すメッセージが表示された場合は、仮想サーバーのグローバル・ゾーンを検出し、管理対象ターゲットとして追加します。

Oracle Solarisゾーンは、次のターゲット表示名で表示されます。

- 仮想化プラットフォーム: <Oracle Solarisグローバル・ゾーンのOSホスト名> (Solarisゾーン仮想プラットフォーム)

- 仮想サーバー: <Oracle Solarisゾーン名>

検出されたOracle Solarisゾーンの表示名は、CLIを使用して変更できます。たとえば、仮想化プラットフォーム表示名を変更するには、次を実行します。

emcli modify_target -name="Virtual Platform Target Name" -type="oracle_si_virtual_platform_map" -display_name="New Display Name"

仮想サーバー表示名を変更するには、次を実行します。

emcli modify_target -name="Virtual Server Target Name" -type="oracle_si_virtual_server_map" -display_name="New Display Name"

ホストの検出、昇格およびホストを追加する手順の詳細は、「ホスト・ターゲットと非ホスト・ターゲットの検出および追加」を参照してください。

16.4 Oracle VM Server for SPARCの検出および昇格

Oracle VM Server for SPARCの検出および昇格は、ホスト検出に依存します。制御ドメイン上のホストが昇格されると、これにより、その他のドメインの検出とモニタリングがトリガーされます。

注意:
ターゲットを検出およびモニタリングするには、sudo権限を持つEMエージェントをデプロイするか、または手動でroot.shスクリプトをインストールして実行します。

エージェントが制御ドメインまたは論理ドメインのOSにデプロイされると、ILOMサーバー、仮想プラットフォーム、仮想サーバーなどの関連ターゲットが自動的に昇格されます。

ホストが論理ドメイン内にある場合は、仮想サーバー・ターゲットを追加する前に、制御ドメインを検出する必要があります。この仮想サーバーに関連付けられている仮想プラットフォームがないことを示すメッセージが表示された場合は、仮想サーバーのプライマリ・ドメインを検出し、管理対象ターゲットとして追加します。

Oracle VM Server for SPARCを検出および追加するには、次の前提条件を満たす必要があります。

- 制御ドメイン上のOracle Solarisリリースは、Oracle Solaris 11.1以上である必要があります。

- Oracle VM Server for SPARCソフトウェアは、バージョン3.1以上である必要があります。

- Enterprise Managerエージェントをインストールおよび実行するために使用するユーザーに権限がない場合は、そのユーザーにsolaris.ldoms.readとsolaris.ldoms.ldmpowerの認可を付与し、LDoms Power Mgmt監視性権限プロファイルを割り当てる必要があります。次に例を示します。

/usr/sbin/usermod -A solaris.ldoms.read,solaris.ldoms.ldmpower oracle
/usr/sbin/usermod -P 'LDoms Power Mgmt Observability' oracle

システムまたは制御ドメイン上の大量のリソースが他のソフトウェアによって消費されている場合は、ターゲットの検出およびモニタリングに時間がかかることがあります。

Oracle VM Server for SPARCは、次のターゲット表示名で表示されます。

- 仮想化プラットフォーム: <制御ドメインのOSホスト名> (OVM SPARC仮想プラットフォーム)

- 仮想サーバー: <ドメイン名>

検出されたOracle VM Server for SPARCの表示名は、CLIを使用して変更できます。たとえば、仮想化プラットフォーム表示名を変更するには、次を実行します。

emcli modify_target -name="Virtual Platform Target Name" -type="oracle_si_virtual_platform_map" -display_name="New Display Name"

仮想サーバー表示名を変更するには、次を実行します。

emcli modify_target -name="Virtual Server Target Name" -type="oracle_si_virtual_server_map" -display_name="New Display Name"

ホストの検出、昇格およびホストを昇格する手順の詳細は、「ホスト・ターゲットと非ホスト・ターゲットの検出および追加」を参照してください。

16.5 サーバーの検出および昇格

サーバーの検出および追加は、個別に実行することも、ホスト検出の一環として実行することもできます。ホストが昇格されると、そのホストをサポートするサーバーの検出および自動昇格がトリガーされます。ホストの検出、昇格およびホストを昇格する手順の詳細は、「ホスト・ターゲットと非ホスト・ターゲットの検出および追加」を参照してください。

ILOMサーバーを検出および昇格するには、次を参照してください。

- ユーザー・インタフェースを使用したILOMサーバーの検出

- コマンドライン・インタフェースを使用したILOMサーバーの検出

ILOMサーバーを検出後、表示名を変更するには、「検出されたILOMサーバーの表示名の変更」を参照してください。

注意:
ターゲットを自動昇格するには、sudo権限を持つEMエージェントをデプロイするか、または手動でroot.shスクリプトをインストールして実行します。
ILOMがホストの前に検出され、HMPパッケージがホスト上にインストールされている場合、システム・インフラストラクチャ・サーバーはILOMサーバー名で表示されます。それ以外の場合は、システム・インフラストラクチャ・サーバーは、<ホスト名>/serverという名前で表示されます。

一部のサーバーでは、パフォーマンスを向上させるために、ファームウェアのバージョンを最小にすることが推奨されます。

注意:
SPARC M6-32サーバーでは、システム・ファームウェア9.4.2.E以上をお薦めします。

16.5.1 ユーザー・インタフェースを使用したILOMサーバーの検出

ILOMサーバーを検出するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」を選択します。

2. 「ターゲットの手動追加」をクリックします。

3. 「ガイド付きプロセスを使用して非ホスト・ターゲットを追加」に表示される「ガイド付きプロセスを使用した追加」をクリックします。
「ガイド付きプロセスを使用した追加」ウィンドウが、ガイドされた検出および検出済ターゲット・タイプのリストとともに表示されます。

4. 「ガイド付きプロセスを使用した追加」ウィンドウのリストから、「システム・インフラストラクチャ・サーバーILOM」を選択して、「追加」をクリックします。

5. ターゲットの場合、次の詳細を入力します。

1. ターゲット名: ILOMサーバーの名前を入力します。

2. サーバーILOM DNS名またはIPアドレス: サーバーDNS名またはIPアドレスを入力します。

6. モニタリング・エージェントの場合、次の詳細を入力します。

1. モニタリング・エージェントEMD URLを入力します。

2. (オプション): バックアップ・エージェントEMD URLを入力します。

7. 「モニタリング資格証明」には、次のSSHモニタリング資格証明を入力します。

1. 「ILOM SSH資格証明」として、資格証明タイプを選択します。

2. 「ユーザー名」フィールドにrootユーザー名を入力します。

3. 「パスワード」および「パスワードの確認」の各フィールドにrootパスワードを入力します。

8. 「追加」をクリックします。

ターゲットが正常に追加された場合には、確認ウィンドウが表示されます。

16.5.2 コマンドライン・インタフェースを使用したILOMサーバーの検出

サーバーを検出するには、emcliコマンドライン・ツールを使用します。コマンドを発行する前に、コマンドライン・インタフェースを構成する必要があります。詳細を確認するには、「設定」メニューをクリックしてから、「コマンドライン・インタフェース」をクリックします。ダウンロードおよびデプロイの手順に従います。

emcliを使用してサーバーを検出するには、次の手順を実行します。

1. OMSを実行中のホスト上で、コマンドラインを開きます。

2. コマンドemcli login –username=<自分のユーザー名>を使用して、emcliにログインします。

3. 要求されたら、パスワードを入力します。

4. コマンドemcli syncを実行します。

5. emcli add_targetコマンドを使用して次のオプションを定義し、新しいサーバーを検出します。

- -name=Enterprise Manager内に表示するサーバーの名前

- -type=oracle_si_server_map

- -host=モニタリング対象のサーバー・ターゲットを検出するホスト名

- -access point name=EM内に表示するアクセス・ポイント名

- -access_point_type=oracle_si_server_ilom

- -properties=検出で使用するkey:ILOM IPアドレス。たとえば、-properties='dispatch.url=ilom-ssh://<ILOM_IP_ADDRESS>'となります。

- -subseparator=サブセパレータ文字列を含むプロパティ(たとえば、キーと値のペア間のセパレータとして=を使用できます)。または、区切る必要のあるプロパティ(キーと値のペア)が複数存在する場合には、-separatorオプションを使用することもできます。

- -monitoring_cred=検索対象のサーバーILOMの資格証明

例16-1 ILOMサーバーを検出するCLIコマンドの例

次のコマンドでは、ILOMサーバーを検出および管理し、ホスト名を設定して、アクセス・ポイント名とタイプを定義し、モニタリング・プロパティと資格証明を指定します。

emcli add_target -name=<TARGET_NAME> -type=oracle_si_server_map -host=<AGENT_HOST_NAME> -access_point_name='<ACCESS_POINT_NAME>' -access_point_type='oracle_si_server_ilom' -properties='dispatch.url=ilom-ssh://<ILOM_IP_ADDRESS>' -subseparator=properties='=' -monitoring_cred='ilom_creds_set;oracle_si_server_ilom;ilom_creds;username:<ROOT_USER>;password:<ROOT_PWD>' -monitoring_cred='ssh_creds_set;oracle_si_server_ilom;ssh_creds;username:<ROOT_USER>;userpass:<ROOT_PWD>'

16.5.3 検出されたILOMサーバーの表示名の変更

CLIを使用して、検出されたサーバーの表示名を変更するには、emcliコマンドを実行してターゲット名を変更します。次に例を示します。

emcli modify_target -name="Server Target Name" -type="oracle_si_server_map" -display_name="New Display Name"

16.6 Oracle SuperClusterの検出および昇格

検出プロセスを開始する前に、スムーズな検出のために実行する必要のあるチェックがいくつかあります。

16.6.1 前提条件

スムーズな検出に必要なシステムの適切な構成を自動的に確認するために、検出事前チェック・スクリプトを使用できます。

Oracle Enterprise Manager 13c上でOracle SuperCluster検出を行うと、ソフトウェア設定時の構成の不一致のために問題が発生することがあります。検出事前チェック・スクリプトは、共通する構成上の問題のほとんどを解決するのに役立ちます。Oracle SuperCluster検出の前にこのスクリプトを実行して、出力を確認してから、Oracle Enterprise Managerでの検出を続行します。

最適な検索結果を得るには、スクリプトを実行してすべての問題(無視できるものもあります)を解決し、プロセスを正常に終了します。

スクリプトは、Enterprise Managerエージェントのバンドルに含まれています。

16.6.2 検出事前チェック・スクリプトの取得

次のいずれかの方法を使用してスクリプトを取得できます。:

1. システム・インフラストラクチャのプラグイン13.1.1.0.0をエージェントにデプロイした後、その一部として含まれる次のスクリプトにアクセスします。
<エージェント・インストール・ディレクトリ>/plugins/oracle.sysman.si.discovery.plugin_13.1.1.0.0/discover/sscDiscoveryPreCheck.pl

2. My Oracle Supportで、最新バージョンの前提条件スクリプトを確認します。
My Oracle Supportからダウンロードしたスクリプトを実行する場合は、必ずEnterprise Managerエージェントのバンドルがデプロイされている計算ノード(CDOM)上で実行するようにしてください。

16.6.3 検出事前チェック・スクリプトの実行

スクリプトを実行するには、次のコマンドを入力します。

- $ cd <エージェント・インストール・ディレクトリ>/plugins/oracle.sysman.si.discovery.plugin_13.1.1.0.0/discover

- $ perl ./sscDiscoveryPrecheck.pl

オプション・パラメータのヘルプを確認するには、次のコマンドを入力します。

- $ perl ./sscDiscoveryPrecheck.pl --help

スクリプトを実行すると、様々な入力を要求されます。スクリプトにより、すべての組込みチェックが実行され、重要なメッセージが標準出力で表示されます。詳細情報はログ・ファイルに格納され、実行エラーをデバッグするために使用できます。

検出事前チェック・スクリプトにより、次のチェックが実行されます。

- 実行環境およびネットワーク

- ネットワーク構成(IP、ホスト名の有効性、ping)

- ハードウェアのモニタリング資格証明(オプション)

- 詳細なハードウェアまたはソフトウェアのチェック(資格証明が必要な場合があります)

- モニタリングするtargetsExadataセル管理のILOMバージョン、およびセル・サーバーのバージョンとステータスが適切かどうか

- PDUファームウェア・バージョン、トラップおよびNMSテーブル可用性

- Oracle SuperClusterバージョン

- IPMIツール・バージョン

16.6.4 Oracle SuperCluster検出に必要な資格証明

Oracle SuperClusterの検出に必要な資格証明は、次のとおりです。

表16-1 SSC検出の資格証明

ターゲット・タイプ

資格証明

システム・インフラストラクチャ・サーバー

ILOMモニタリング資格証明

システム・インフラストラクチャ・インフィニバンド・スイッチ

ILOMモニタリング資格証明、SNMP資格証明

システム・インフラストラクチャCISCOスイッチ

CiscoスイッチIOS資格証明、SNMP資格証明

システム・インフラストラクチャZFS記憶域アプライアンス・コントローラ

ZFS SAストレージ・コントローラSSH資格証明

システム・インフラストラクチャPDU

HTTPモニタリング資格証明、SNMP資格証明

Oracle Exadata Storage Server

Exadata権限付きの資格証明、SNMPコミュニティ文字列。これにより、SNMPサブスクリプションを使用できますが、使用できるのは1回のみです。モニタリングには、より低い権限を持つ他の資格証明を使用します。

ホスト

エージェント・ホスト・ユーザー資格証明。この資格証明には、ストレージ・セルへのパスワードなしのアクセスを設定する必要があります。

16.6.5 手動での前提条件の検証

個々のOracle SuperClusterシステムにおける計算ノードおよびExadataセルのホスト名に、一意の接頭辞が付いていることを確認してください。

16.6.6 Oracle SuperCluster検出

ターゲットの管理には、複数のEnterprise Managerエージェントを使用することをお薦めします。Oracle Supercluster検出プロセスの前にエージェントをデプロイします。Enterprise Managerエージェントは、管理する予定の仮想化プラットフォームごとにデプロイする必要があります。

図16-2は、Oracle SuperCluster検出のワークフローを示したものです。

図16-2 Oracle SuperCluster検出のワークフロー

Oracle SuperClusterシステムを検出するには、次の手順を実行します。

1. Enterprise Managerにログインします。

2. 「設定」で、「ターゲットの追加」、「ターゲットの手動追加」の順にクリックします。

3. 「概要」セクションで、「ガイド付きプロセスを使用したターゲットの追加」をクリックします。

4. 「ガイド付きプロセスを使用した追加」画面で、「Oracle SuperCluster」までスクロールして、「追加」をクリックします。Oracle SuperCluster検出ウィザードが開きます。

5. 概要ウィザードによって、Oracle Enterprise ManagerでOracle SuperClusterを検出するために必要な手順が示されます。検出プロセスを続行するには、「次」をクリックします。

注意:
ガイド付き検出プロセスでは、Oracle Enterprise Managerエージェントが計算ノードにすでにデプロイされているとみなします。計算ノード上の仮想化スタックをモニタリングするには、Enterprise Managerエージェントがデプロイされている必要があります。

注意:
DBドメイン上で実行されるデータベース・インスタンスをモニタリングする場合は、データベースがインストールされているすべてのゾーンおよびゲストLDOM上に、Enterprise Managerエージェントをインストールする必要があります。

6. 「検出入力」画面で、必要な情報を入力します。

1. 「エージェントEMD URL」フィールドで、検索アイコンをクリックして、エージェントを選択します。

注意:
エージェントは、Oracle SuperClusterインフィニバンド・スイッチのいずれかと同じネットワーク上にある必要があります。

2. 「プライマリ・ドメインのホスト名」フィールドで、Oracle SuperClusterシステムの設定時にOneCommand実行に使用されたプライマリ・ドメインのホスト名を指定します。

注意:
このドメインは、システム・ターゲットの検出に使用されます。これは1回かぎりの操作です。検出では、特権ユーザー(root)資格証明を使用して、システムの詳細およびOneCommandディレクトリ(/opt/oracle.SupportTools/onecommand)内のcatalog.xmlファイルまたはdatabasemachine.xmlファイルを検出する必要があります。

3. 「資格証明」フィールドで、「新規」を選択して資格証明を作成します。

- 既存の資格証明をすでに持っている場合は、「名前付き」をクリックします。

4. 「ユーザー名」フィールドに、root権限を持つユーザーの名前を入力します。

5. 「パスワード」フィールドに、計算ノードのパスワードを入力します。

6. 後で使用するために資格証明を保存するには、「別名で保存」をクリックします。

7. 「インフィニバンド・スイッチ・ホスト名」フィールドに、インフィニバンド・スイッチのDNS名またはIPアドレスを入力します。

8. 「資格証明」フィールドで、「新規」を選択して資格証明を作成します。

- 既存の資格証明をすでに持っている場合は、「名前付き」をクリックします。

9. 「ユーザー名」フィールドに、インフィニバンド・スイッチのILOMに接続するためのユーザー名を入力します。

10. 「パスワード」フィールドに、インフィニバンド・スイッチILOMのパスワードを入力します。

11. 「実行権限」フィールドで、「なし」を選択します。

- 後で使用するために資格証明を保存するには、「別名で保存」をクリックします。

12. (オプション)接続をテストするには、「接続テスト」をクリックします。

7. 「次へ」をクリックして次の手順に進みます。Oracle SuperCluster検出プロセスが開始されます。検出が完了すると、確認ウィンドウに検出されたターゲット数が表示されます。ウィンドウを閉じるには、「閉じる」をクリックします。

8. 検出の前提条件の画面が開きます。検出の基本情報が表示されます。検出プロセスで警告およびエラーが発生したら、それも表示されます。「次へ」をクリックして続行します。

注意:
エラーが発生した場合は、エラーを修正してから次のステップに進むことができます。警告の表示後に続行するには、警告を慎重に読んで理解します。

9. 「検出されたターゲット」画面に、Oracle SuperClusterシステムで検出されたすべてのターゲットがリストされます。すべてのターゲットがデフォルトで選択されます。「管理対象」列は、ターゲットがEnterprise Managerによってすでに検出、管理されているかどうかを示します。検出およびモニタリングの対象としないターゲットの選択を解除します。

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

11. 「モニタリング・エージェント」画面では、以前の手順で選択したターゲットに、モニタリングおよびバックアップのエージェントを割り当てることができます。検出ウィザードは、最高のパフォーマンスと信頼性を求めて、使用できるエージェントを自動的に割り当てます。Enterprise Managerでまだ管理されていないターゲットについては、必要に応じて、デフォルトのエージェント以外のエージェントを手動で選択できます。「次へ」をクリックします。

注意:
エージェントは同じネットワーク上にあり、ターゲットに到達できる必要があります。

12. 「モニタリング資格証明」画面に、ターゲットをモニターするために使用される資格証明がリストされます。情報がないターゲットのモニタリング資格証明を変更または指定するには、「編集」をクリックします。「次へ」をクリックします。

注意:
インフィニバンド・ネットワーク・スイッチを検出するには、rootのユーザー名とパスワードを使用します。

注意:
「モニタリング・エージェント・ホスト」セクションで、指定のホストでEMエージェントを実行しているユーザーのユーザー名とパスワードを入力します。

注意:
同じターゲット・タイプのすべてのターゲットに同じ資格証明を使用するには、すべてに使用オプションを選択します。

13. システム・レビューの画面で、システム情報を検討します。
「テスト接続」をクリックして、選択されたすべてのターゲットについて指定された資格証明が適切かどうかを確認します。

14. 「ターゲットの昇格」をクリックして、ターゲットを作成および管理します。これが完了するまで数分かかる場合があります。プロセス中に発生したエラーは、すべて通知されます。1つ以上のエラーがある場合、ターゲットは作成されません。すべてのエラーを修正して、検出を再実行します。プロセスがエラーなしで完了すると、ターゲットが管理され、Oracle SuperClusterシステムに、そのターゲットがすべて表示されます。

注意:
Oracle SuperCluster検出ウィザードでは、ハードウェア・ターゲットが検出されなかった場合、任意の画面に戻って入力データを修正したり、問題のあるハードウェアの選択を解除したりした後、検出に戻ることができます。システムの不足しているターゲットを検出するために、後で検出を再実行できます。

16.7 PDUの検出および昇格

モニタリング・エージェントのバックアップを使用する計画がある場合は、PDU検出を実行する前に、PDUのNMSテーブルおよびTrap Hosts Setupテーブルに、モニタリング・エージェント用の空の行とバックアップ・エージェント用の空のスロットが含まれていることを確認します。

16.7.1 PDU v1 NMSテーブルおよびTrap Hosts Setupテーブルの確認

PDU v1上のNMSテーブルおよびTrap Hosts Setupテーブルを確認して変更するには、PDUユーザー・インタフェースで次の手順を実行します。

1. WebブラウザでPDU管理インタフェースを開きます。

2. PDUユーザー・インタフェースで、「ネット構成」をクリックします。

3. 自分のユーザー名とパスワードでログインします。

4. NMS表を探し、PDUをモニターするEMエージェントのIPアドレス用に十分な空のスロットがあることを確認します。

- 空のスロットの「IPアドレス」フィールドには値0.0.0.0が、「コミュニティ文字列」フィールドには空の文字列が含まれます。

5. 空のスロットが不足している場合は、「IPアドレス」フィールドに値0.0.0.0を入力し、「コミュニティ文字列」フィールドは空にします。

6. 「発行」をクリックします。

7. 同じページでTrap Hosts Setupテーブルを探し、PDUをモニタリングするEMエージェントのIPアドレス用に十分な空のスロットがあることを確認します。

- 空のスロットの「IPアドレス」フィールドには値0.0.0.0が、「コミュニティ文字列」フィールドには空の文字列が含まれます。

8. 空のスロットが不足している場合は、「IPアドレス」フィールドに値0.0.0.0を入力し、「コミュニティ文字列」フィールドは空にします。

9. 「発行」をクリックします。

10. PDUインタフェースからログアウトします。

16.7.2 PDU v2 NMSテーブルおよびTrap Hosts Setupテーブルの確認

PDU v2上のNMSテーブルおよびTrap Hosts Setupテーブルを確認して変更するには、PDUユーザー・インタフェースで次の手順を実行します。

1. WebブラウザでPDU管理インタフェースを開きます。

2. PDUユーザー・インタフェースで、「ネット構成」をクリックします。

3. 自分のユーザー名とパスワードでログインします。

4. SNMPアクセス・タブをクリックします。

5. NMS (SNMP v1/v2)テーブルで、PDUをモニタリングするEMエージェントのIPアドレス用に十分な空のスロットがあることを確認します。

- 空のスロットは、「有効化」チェック・ボックスの選択が解除されているスロットのことです。

6. 空のスロットが不足している場合は、「有効化」チェック・ボックスの選択を解除します。

7. 「発行」をクリックします。

8. 「SNMPトラップ」タブをクリックします。

9. トラップ・リモート・ホスト設定テーブルで、PDUをモニタリングするEMエージェントのIPアドレス用に十分な空のスロットがあることを確認します。

- 空のスロットは、「有効化」チェック・ボックスの選択が解除されているスロットのことです。

10. 空のスロットが不足している場合は、「有効化」チェック・ボックスの選択を解除します。

11. 「発行」をクリックします。

12. PDUインタフェースからログアウトします。

16.7.3 Enterprise ManagerでのPDU検出

PDUを検出するには、次の手順を実行します。

1. Enterprise Managerにログインします。

2. 「設定」で、「ターゲットの追加」、「ターゲットの手動追加」の順にクリックします。

3. 「概要」セクションで、「ガイド付きプロセスを使用したターゲットの追加」をクリックします。

4. 「ガイド付きプロセスを使用した追加」画面で、「システム・インフラストラクチャPDU」までスクロールして、「追加」をクリックします。

5. システム・インフラストラクチャPDU検出の画面で、必要な情報を入力します。

1. 「ターゲット名」フィールドに、ターゲットの名前を入力します。

2. 「PDU DNS名またはIPアドレス」フィールドで、PDUのIPアドレスまたはDNS名を入力します。

3. 「モニタリング・エージェントEMD URL」フィールドで、検索アイコンをクリックし、モニタリング・エージェントを選択します。エージェントは、ネットワーク経由でPDUと通信できる必要があります。
(オプション) PDUについて、モニタリング・エージェントのバックアップを選択できます。「バックアップ・エージェントEMD URL」フィールドで、検索アイコンをクリックし、モニタリング・エージェントを選択します。エージェントは、ネットワーク経由でPDUと通信できる必要があります。

注意:
プライマリ・エージェントが使用不可であるか、メンテナンス状態にある場合は、ターゲットのモニタリングおよびそのメトリックの収集にバックアップ・エージェントが使用されます。

4. 「HTTPモニタリング資格証明」セクションに、PDU管理インタフェースの資格証明を入力します。

- 「資格証明のタイプ」フィールドで、SNMPV1資格証明オプションを選択します。

注意:
現在、PDUモニタリングではSNMPv1資格証明のみがサポートされています。

- SNMPプロトコルを使用してPDUと通信するために使用する、SNMPコミュニティ文字列を入力します。
エージェントIPアドレスおよびコミュニティ文字列は、PDUが検出されると、PDUのNMSテーブルおよびTrap Hosts Setupテーブルに追加されます。

5. (オプション)「プロパティ」セクションはデフォルトで移入されます。SNMPポートとタイムアウトの設定を変更する場合は、ポートとタイムアウト値を入力します。

6. 画面の右隅にある「テスト接続」ボタンを使用して、入力されたすべての値、PDUの使用可能性および構成の妥当性をテストすることを強くお薦めします。テスト接続が正常に完了すると、引き続きターゲットを追加できます。

7. 画面の右上隅の「追加」をクリックします。ジョブが正常に実行されると、PDUが検出され、「ターゲットの手動追加」画面が表示されます。PDUターゲットのランディング・ページを開いて表示する前にデータをロードすると、数分かかることがあります。

16.7.4 コマンドライン・インタフェースを使用したPDUの検出

emcliコマンドライン・ツールを使用して、電力配分装置を検出できます。

emcliを使用してPDUを検出するには、次の手順を実行します。

1. OMSを実行中のホスト上で、コマンドラインを開きます。

2. コマンドemcli login –username=<自分のユーザー名>を使用して、emcliにログインします。

3. 要求されたら、パスワードを入力します。

4. コマンドemcli syncを実行します。

5. 次のコマンドを使用して、新しいPDUを検出します。
emcli add_target \

-name='Name of you PDU' \

-type=oracle_si_pdu \

-host="Host on which the deployed agent is used to monitor the PDU" \

-subseparator=properties='=' \

-separator=properties=';' \

-properties='dispatch.url=http://PDU IP or DNS name' \

-monitoring_cred='http;oracle_si_pdu;http;username:PDU admin user username;password:PDU admin user password' \

-monitoring_cred='snmp_v1v2_v3;oracle_si_pdu;SNMPV1Creds;COMMUNITY:SNMP community string'

emcli add_targetコマンドで、次のように設定します。

- Name of your PDUは、使用するPDUの名前に置き換えます。

- ホストには、ポートなしのモニタリング・エージェントEMD URL (つまり、エージェントがデプロイされているホストのホスト名のことで、このエージェントはネットワーク経由でPDUと通信できる必要があります)を設定します。

- PDU IP or DNS nameは、PDUのIPアドレスまたはDNS名で置き換えます。

- PDU admin user usernameは、PDU Web管理インタフェースを使用してPDUを管理可能な管理ユーザーのユーザー名で置き換えます。

- PDU admin user passwordは、PDU Web管理インタフェースを使用してPDUを管理可能な管理ユーザーのパスワードで置き換えます。

- SNMP community stringは、SNMPプロトコルを使用してPDUと通信するために使用するSNMPコミュニティ文字列で置き換えます。

次に、汎用PDUを作成するサンプル・コマンドを示します。

emcli add_target \

-name=pdu.example.com \

-type=oracle_si_pdu \

-host=host.example.com \

-subseparator=properties='=' \

-separator=properties=';' \

-properties='dispatch.url=http://pdu.example.com'\

-monitoring_cred='http;oracle_si_pdu;http;username:admin;password:password123' \

-monitoring_cred='snmp_v1v2_v3;oracle_si_pdu;SNMPV1Creds;COMMUNITY:public'

16.8 Oracle ZFS Storageの検出および昇格

この項では、Oracle ZFS Storage ApplianceターゲットおよびOracle ZFS Storage Applianceクラスタの手動記憶域検出プロシージャについて説明します。

ZFS記憶域サーバー・ターゲットは、AKCLIとREST/WebSvcの2つのアクセス・ポイントをサポートする、マルチアクセス・ポイント(MAP)・ターゲットです。検出ユーザー・インタフェースではAKCLIアクセス・ポイントのみがサポートされます。ただし、REST/WebSvcアクセス・ポイントは、EMCLIを使用して追加できます。REST/WebSvcアクセス・ポイントを追加すると、AKCLIによってサポートされないメトリック以外のほとんどのメトリックを実装できます。REST/WebSvcとAKCLIの両方のアクセス・ポイントを使用できますが、REST/WebSvcアクセス・ポイントからのメトリックのみがアップロードされます。REST/WebSvcアクセス・ポイントを追加するには、次のコマンドを使用できます。

emcli add_target -name=<name> -type=oracle_si_zfssa_storage_server -host=<emagent name>
-access_point_name=<any name> -access_point_type='oracle_si_zfssa_storage_server_websvc'
-properties='dispatch.url=https://<applianceURL>:215/api/' -subseparator=properties='='
-monitoring_cred='ZfssaHttpCredentialSet;oracle_si_zfssa_storage_server_websvc;AliasCredential;Alias:root;Password:<password>'

次のフローチャートは、Oracle ZFS Storage Applianceを検出する手順を視覚化したものです。

図16-3 Oracle ZFS Storage Applianceの検出

16.8.1 Oracle ZFS Storage Applianceの検出

Oracle ZFS Storage Applianceを検出するには、次の手順を実行します。

1. 「設定」メニューから、「ターゲットの追加」を選択します。

2. 「ターゲットの手動追加」をクリックします。

3. 「ガイド付きプロセスを使用して非ホスト・ターゲットを追加」に表示される「ガイド付きプロセスを使用した追加」をクリックします。
「ガイド付きプロセスを使用した追加」ウィンドウが、ガイドされた検出および検出済ターゲット・タイプのリストとともに表示されます。

4. 「ガイド付きプロセスを使用した追加」ウィンドウのリストから「システム・インフラストラクチャZFS記憶域アプライアンス・コントローラ」を選択します。

5. 「追加」をクリックします。

6. ターゲットの場合、次の詳細を入力します。

1. ターゲット名を入力します。

2. ZFSストレージ・サーバーのDNS名またはIPアドレスを入力します。

7. モニタリング・エージェントの場合、次の詳細を入力します。

1. モニタリング・エージェントEMD URLを入力します。

2. (オプション): バックアップ・エージェントEMD URLを入力します。

8. モニタリング資格証明の場合、次の詳細を入力します。

1. 「SSH資格証明」として資格証明タイプを選択します。

2. ユーザー名とパスワードをそれぞれのフィールドに入力します。

3. 「パスワードの確認」フィールドにパスワードを再度入力します。

4. (オプション): ロール名、ロール・パスワードを入力して、ロール・パスワードの確認フィールドでパスワードを再度入力します。

9. 「追加」をクリックします。

16.8.1.1 Oracle ZFS Storage Applianceのターゲット・メンバー

検出ウィザードを使用してOracle ZFS Storage Appliance Controllerターゲットを追加すると、次のターゲット・メンバーは自動的に昇格されます。

- ZFS記憶域サーバー
ターゲット・タイプ: Oracle ZFS Storage Server

- ディスクシェルフ
ターゲット・タイプ: ZFSディスク・シェルフ記憶域

16.8.1.2 Oracle ZFS Storage Applianceクラスタのターゲット・メンバー

クラスタ・ノードとして設定されたZFS Storage Applianceノードを2つ追加すると、ZFS Storage Appliance Clusterは自動検出されます。

次のターゲットは、2つのZFS記憶域サーバーにクラスタ構成設定がある場合に追加されます。

- ZFS記憶域サーバー
ターゲット・タイプ: Oracle ZFS Storage Server

- ディスクシェルフ
ターゲット・タイプ: ZFSディスク・シェルフ記憶域

- ZFS Storage Applianceクラスタ
ターゲット・タイプ: Oracle ZFS Storage Server - クラスタ

16.9 ファブリックの検出

Enterprise Managerでは、イーサネット・ファブリックとインフィニバンド・ファブリックを検出および管理します。ネットワーク・スイッチによって、そのポート、データリンクおよびファブリックへのネットワークが提供されます。

- インフィニバンド・ネットワーク・スイッチの検出

- イーサネット・ネットワーク・スイッチの検出

- コマンドラインを使用したスイッチの検出

検出後、第32章「ネットワークの管理」の手順に従って、これらのファブリックのコンポーネントを管理したり、それらの属性やメトリックを表示できます。

16.9.1 インフィニバンド・ネットワーク・スイッチの検出

1. 「設定」メニューで、「ターゲットの追加」を選択します。

2. 「ターゲットの手動追加」をクリックします。

3. ガイド付きプロセスを使用して非ホスト・ターゲットを追加セクションで、「ガイド付きプロセスを使用した追加」をクリックします。

4. 「システム・インフラストラクチャOracle InfiniBandスイッチ」までスクロールして、「追加...」ボタンをクリックします。

図16-4 インフィニバンド・スイッチのターゲット・タイプ

5. 「ターゲット」セクションで、新しいターゲットの名前とそのDNS名またはIPアドレスを入力します。

図16-5 インフィニバンド・スイッチの検出の仕様

6. 「モニタリング・エージェント」セクションで、モニタリング・システムのURLとバックアップ・システムのURLを入力します。

7. 「ILOM SSHモニタリング資格証明」セクションで、資格証明のタイプを選択し、ユーザー名とパスワードを入力します。資格証明を使用すると、Enterprise Managerでスイッチのサービス・プロセッサをモニターできるようになります。

注意:
インフィニバンド・ネットワーク・スイッチを検出するには、rootのユーザー名とパスワードを使用します。

8. 「SNMPモニタリング資格証明」セクションで、Enterprise Managerがハードウェア・コンポーネントのモニタリングに使用するSNMPバージョン番号を指定します。バージョン2cがデフォルト・バージョンで、コミュニティ文字列のみ必要です。バージョン3では、ユーザー名、8文字のパスワード、および暗号化タイプが必要です。「ファブリックのパフォーマンスについて」で説明しているとおり、バージョン1はサポートされていますが、推奨されていません。

9. 「プロパティ」セクションで、デフォルトのポート番号とタイムアウト間隔を受け入れるか、これらを変更できます。

10. 「グローバル・プロパティ」セクションで、Oracle Customer Support Identifier (CSI)などの、特定地域向けの値を指定できます。

11. ウィンドウの上部にある「追加」をクリックします。

16.9.2 イーサネット・ネットワーク・スイッチの検出

1. 「設定」メニューで、「ターゲットの追加」を選択します。

2. 「ターゲットの手動追加」をクリックします。

3. ガイド付きプロセスを使用して非ホスト・ターゲットを追加セクションで、「ガイド付きプロセスを使用した追加」をクリックします。

4. 「システム・インフラストラクチャCiscoスイッチ」までスクロールして、「追加...」ボタンをクリックします。

図16-6 Ciscoイーサネット・スイッチのターゲット・タイプ

5. 「ターゲット」セクションで、新しいターゲットの名前を入力し、そのDNS名またはIPアドレスを指定します。

図16-7 Ciscoイーサネット・スイッチの検出の仕様

6. 「モニタリング・エージェント」セクションで、モニタリング・システムのURLとバックアップ・システムのURLを入力します。

7. 「CiscoスイッチIOSモニタリング資格証明」セクションで、資格証明のタイプを指定し、ユーザー名とパスワードを入力します。また、Cisco EXECパスワードを入力します。資格証明を使用すると、Enterprise Managerでスイッチのサービス・プロセッサをモニターできるようになります。

8. 「SNMPモニタリング資格証明」セクションで、Enterprise Managerが使用するSNMPバージョン番号を指定して、ハードウェア・コンポーネントをモニターします。バージョン3では、ユーザー名、8文字のパスワード、および暗号化タイプが必要です。「ファブリックのパフォーマンスについて」で説明しているとおり、バージョン1はサポートされていますが、推奨されていません。

9. 「プロパティ」セクションで、ポート番号とタイムアウト間隔など、デフォルト構成の詳細を変更できます。

10. 「グローバル・プロパティ」セクションで、Oracle Customer Support Identifier (CSI)などの、特定地域向けの値を指定できます。

11. ウィンドウの上部にある「追加」をクリックします。

16.9.3 コマンドラインを使用したスイッチの検出

次の例では、コマンドライン・インタフェースを使用して、ネットワーク・スイッチを検出および管理します。コマンドを発行する前に、コマンドライン・インタフェースを構成する必要があります。詳細を確認するには、「設定」メニューをクリックしてから、「コマンドライン・インタフェース」をクリックします。ダウンロードおよびデプロイの手順に従います。

例16-2 SNMPバージョン3を使用したインフィニバンド・スイッチを検出するコマンド

次のコマンドでは、MY_SWITCHという名前のインフィニバンド・スイッチを検出および管理し、SNMPバージョンをバージョン3に設定します。

emcli add_target -name=MY_SWITCH -type=oracle_si_netswitch -host=AGENT_HOST -access_point_name=MY_SWITCH -access_point_type=oracle_si_switch_oracle_ib -properties='dispatch.url=ilom-ssh://MY_SWITCH_IP_ADDR' -subseparator=properties='=' -monitoring_cred='ilom_creds_set;oracle_si_switch_oracle_ib;ilom_creds;username:PRIV_USER;password:PASSWORD' -monitoring_cred='snmp_v1v2_v3;oracle_si_switch_oracle_ib ;SNMPV3Creds;authUser:PRINCIPAL;authPwd:AUTHCRED;authProtocol:MD5;privPwd:PRIV_CREDS'

例16-3 SNMPバージョン3を使用したCiscoイーサネット・スイッチを検出するコマンド

次のコマンドでは、MY_SWITCHという名前のCiscoイーサネット・スイッチを検出および管理し、SNMPバージョンをバージョン3に設定します。

emcli add_target -name=MY_SWITCH -type=oracle_si_netswitch -host=AGENT_HOST -access_point_name=MY_SWITCH -access_point_type=oracle_si_switch_cisco_ios -properties='dispatch.url=ios-ssh://MY_SWITCH_IP_ADDR' -subseparator=properties='=' -monitoring_cred='cisco_creds_set;oracle_si_switch_cisco_ios;cisco_creds;username:PRIV_USER;userpass:USER_PASSWORD;privpass:PRIV_PASSWORD' -monitoring_cred='snmp_v1v2_v3;oracle_si_switch_cisco_ios;SNMPV3Creds;authUser:PRINCIPAL;authPwd:AUTHCRED;authProtocol:MD5;privPwd:PRIV_CREDS'

例16-4 SNMPバージョン1を使用したインフィニバンド・スイッチを検出するコマンド

次のコマンドでは、MY_SWITCHという名前のインフィニバンド・スイッチを検出および管理し、SNMPバージョンをバージョン1に設定して、SNMPプロパティの時間間隔を変更します。

emcli add_target -name=MY_SWITCH -type=oracle_si_netswitch -host=AGENT_HOST -access_point_name=MY_SWITCH -access_point_type=oracle_si_switch_oracle_ib -properties='dispatch.url=ilom-ssh://MY_SWITCH_IP_ADDR;SNMPTimeout=180' -subseparator=properties='='-monitoring_cred='ilom_creds_set;oracle_si_switch_oracle_ib;ilom_creds;username:PRIV_USER;password:PASSWORD' -monitoring_cred='snmp_v1v2_v3;oracle_si_switch_oracle_ib;SNMPV1Creds;COMMUNITY:<COMMUNITY>'

16.10 システム・インフラストラクチャ・ターゲットの検出および昇格の関連リソース

詳細は、次を参照してください:

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの処理

- 記憶域の管理

- ネットワークの管理

第III部

Hybrid Cloud Management

この部では、Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)で新たに加わったHybrid Cloud Management機能について説明します。次の章で構成されます。

- Hybrid Cloud Managementの有効化

- Hybrid CloudへのJVMDのデプロイ

17 Hybrid Cloud Managementの有効化

Enterprise Manager Cloud Controlは、オンプレミス・デプロイメントとOracle Cloudデプロイメントの両方のモニタリングと管理をすべて同じ管理コンソールから実行するための単一のガラス・ペインを提供するようになりました。Hybrid Cloudエージェントを、Oracle Cloudサービスを実行しているOracle Cloud仮想ホストにデプロイすることで、Oracle Cloudターゲットをその他のターゲットと同じように管理することができます。管理エージェントとオンプレミスOracle Management Serviceインスタンスとの間の通信は、外部からの干渉に対して保護されています。Enterprise Managerは、アーキテクチャが強化されたことに加え、トンネリングをサポートする外部HTTPプロキシの追加使用をサポートします。このプロキシを構成して、ゲートウェイ・エージェントがOracle Cloudに接続するようにできます。

この章の項目は次のとおりです。

- サポートされていない機能のリスト

- Hybrid Cloud Managementに関する用語の概要

- Hybrid Cloud Managementの開始

- Hybrid Cloudアーキテクチャと通信の概要

- Hybrid Cloud Gatewayエージェントを構成するための前提条件

- Hybrid Cloud Gatewayエージェントとしての管理エージェントの構成

- Hybrid Cloud Gatewayエージェントを有効化してOracle Cloudと通信するための外部プロキシの構成

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

- Hybrid Cloudエージェントのインストール

- Hybrid Cloud GatewayエージェントおよびHybrid Cloudエージェントのアップグレード

- Hybrid Cloud Managementの追加タスクの実行

- Hybrid CloudエージェントとHybrid Cloud Gatewayエージェントへのパッチの適用

- Oracle Cloudターゲットの検出および監視

- Hybrid Cloud Managementに関するよくある質問

17.1 サポートされていない機能のリスト

表17-1に、Hybrid Cloud Managementで現在サポートされていない機能を示します。

表17-1 Hybrid Cloud Managementでサポートされていない機能

ターゲット

サポートされていない機能

WebLogic

オンプレミス・ドメインのOracle Cloudへのクローニング。

データベース

自動ワークロード・リポジトリ・ウェアハウス

Oracle Cloudデータベースからの収集。

SQLパフォーマンス・アナライザ

- データベース・クラウド・サービス・インスタンスへのリモートからの試行。

- デプロイメント・プロシージャを使用したワークロード・アーティファクト(取得ファイル/STS)のOracle Cloudへのコピー。回避策として手動でコピーします。

- データベース・クラウド・サービス・インスタンスへのActive Data Guardのサポート(データベース・リンクが必要)。

データベース・リプレイ

デプロイメント・プロシージャを使用したワークロード・アーティファクト(取得ファイル/STS)のOracle Cloudへのコピー。回避策としてアーティファクトを手動でコピーします。

データベースのプロビジョニング

例外は既存のOracle Cloud Container Database (CDB)インスタンスに対するプラガブル・データベース(PDB)の操作(作成、接続、切断、削除)。

再編成されたオブジェクト

再編成されたオブジェクト。

変更管理

データの同期。

データベース・クローニング

Oracle Cloud上のホスト間。

Data Guard

Oracle Cloud上のスタンバイ・データベースの管理。

Oracle Exadata Cloud

- Oracle Exadataのハードウェアおよびハイパーバイザのモニタリング、構成の設定。

- パッチ適用とアップグレード。

- バックアップおよびリストア。

- Oracle Cloudにおけるデータベース・サービスのプロビジョニング。

Enterprise Manager

- エージェント:
- 手動によるデプロイ。

- バディ・エージェント。

- ターゲットの再配置。

- Oracle Cloud上のソフトウェア・ライブラリ。

- サード・パーティの証明書。

- Oracle Cloudターゲットのサポート・ワークベンチ。

17.2 Hybrid Cloud Managementに関する用語の概要

次の用語は、Hybrid Cloud Managementについて説明する際に、一般的に使用されています。

- Hybrid Cloudエージェント: Oracle Cloud仮想ホストにデプロイされた管理エージェントで、これによって、プライベート・ネットワークにデプロイされているEnterprise Manager Cloud ControlがOracle Cloudターゲットをモニターおよび管理できます。

- Hybrid Cloud Gatewayエージェント: Oracle Cloud仮想ホストと、プライベート・ネットワークにデプロイされたOMS (オンプレミスCloud Control OMS)間の通信チャネルを提供する管理エージェント。

- Hybrid Cloud Gatewayプロキシ: Hybrid Cloudエージェント各々の構成要素としてデプロイされているプロキシ・プロセスで、これによってHybrid Cloud GatewayエージェントがHybrid Cloudエージェントと通信できます。常にHybrid Cloud Gatewayエージェントによって起動されます。

17.3 Hybrid Cloud Managementの開始

Hybrid Cloud Management機能の使用を開始する手順は次のとおりです。

1. オンプレミスのOMSがバージョン13cであり、少なくとも1つの13cの管理エージェントがエンタープライズ内に存在することを確認します。
オンプレミスのOMSが古いバージョンの場合、OMSをバージョン13cにアップグレードしてください。この方法の詳細は、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

バージョン13cの管理エージェントがエンタープライズ内に少なくとも1つ存在するようにするには、バージョン13cの管理エージェントを新たにデプロイするか、旧バージョンの既存の管理エージェントをバージョン13cにアップグレードしてください。

バージョン13cの管理エージェントを新たにデプロイする方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。旧バージョンの既存管理エージェントをバージョン13cにアップグレードする方法の詳細は、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

注意:
最初に、以前のバージョンの管理エージェントを13cにアップグレードしてから、Hybrid Cloud Gatewayエージェントとして動作するように構成することを強くお薦めします。このようにすると、スタック全体が13cに配置されます。ただし、以前のバージョンをアップグレードしない場合は、そのバージョンを引き続き使用し、Hybrid Cloud Gatewayエージェントとして動作するように構成できます。ただし、この場合、以前のバージョン12cリリース5 (12.1.0.5)のみがサポートされます。その他すべての以前のバージョンは、12cリリース5 (12.1.0.5) または13cのいずれかにアップグレードする必要があります。

2. エンタープライズ内にHybrid Cloud Gatewayエージェントとして動作する13c管理エージェントを1つ以上構成し、これにより、Oracle Cloud仮想ホストとオンプレミスのOMSの間にSSHベースの通信チャネルを提供します。
高可用性を保証するため、Hybrid Cloud Gatewayエージェントとして動作する13cの管理エージェントを複数構成することをお薦めします。詳細は、17.11.1項を参照してください。

3. Hybrid Cloud GatewayエージェントおよびオンプレミスOMSとOracle Cloudターゲットとの間で通信ができていることを確認します。
Hybrid Cloud GatewayエージェントとOracle Cloudターゲットとの間で直接通信ができていない場合は、通信のための外部プロキシを構成します。この方法の詳細は、第17.7項を参照してください。

オンプレミスOMSでは、Oracle Cloudターゲットとの通信にMy Oracle Support (MOS)プロキシが使用されます。エンタープライズ内に構成されたMOSプロキシがSSHトンネリングをサポートすることを確認するか、SSHトンネリングをサポートするMOSプロキシを新たに構成します。

4. ホスト・ターゲットの追加ウィザードまたはEM CLIを使用して、管理エージェントをOracle Cloud仮想ホストにデプロイします。Enterprise ManagerでOracle Cloudターゲットを管理できるようにしているのが、Hybrid Cloudエージェントと呼ばれるこれらの管理エージェントです。Hybrid Cloudエージェントをデプロイするプロセスの中で、各々のHybrid Cloudエージェントと、オンプレミスOMSとの通信に使用されるHybrid Cloud Gatewayエージェントとを関連付けます。

17.4 Hybrid Cloudアーキテクチャと通信の概要

Hybrid Cloudエージェントと通信するためのプロキシ・プロセスであるHybrid Cloud Gatewayプロキシが、Hybrid Cloud Gatewayエージェントによって、各々のHybrid Cloudエージェントに対し起動されます。その後、Hybrid Cloudエージェントから送られてくる通信内容は、Hybrid Cloud Gatewayエージェントによって、Oracle Cloudターゲットを管理しているオンプレミスOMSへ転送され、そのレスポンスも同様にして送り返されます。オンプレミスOMSはこのように、Oracle Cloudとの直接的な通信からは切り離されています。

オンプレミスOMSとHybrid Cloudエージェントとの通信はSSH経由で行われますが、このときOracle Cloudに対してEMCTLディスパッチャが使用されます。オンプレミスOMSからの通信内容はEMCTLディスパッチャによってHybrid Cloudエージェントへ転送され、Hybrid Cloudエージェントからのレスポンスは同様にしてオンプレミスOMSへと送り返されます。

図17-1は、オンプレミスOMSからHybrid Cloudエージェントへの、EMCTLディスパッチャを使用した通信を図示したものです。

図17-1 オンプレミスOMSからHybrid Cloudエージェントへの、EMCTLディスパッチャを使用した通信

Hybrid CloudエージェントはオンプレミスOMSと通信するために、Oracle CloudではHybrid Cloud Gatewayプロキシを使用し、オンプレミス側ではHybrid Cloud Gatewayエージェントを使用します。Hybrid CloudエージェントからのHTTPSリクエストはHybrid Cloud Gatewayプロキシで受信され、SSHを通してHybrid Cloud Gatewayエージェントへと送り出されます。リクエストはHybrid Cloud GatewayエージェントによってオンプレミスOMSに転送され、オンプレミスOMSからのレスポンスは同様にしてHybrid Cloud Gatewayプロキシへと送り返されます。レスポンスはさらに、Hybrid Cloud GatewayプロキシによってHybrid Cloudエージェントへと送り返されます。

図17-2は、Hybrid CloudエージェントからオンプレミスOMSへのHybrid Cloud Gatewayプロキシを経由した通信を図示したものです。

図17-2 Hybrid CloudエージェントからオンプレミスOMSへのHybrid Cloud Gatewayプロキシを経由した通信

注意:
Hybrid Cloud Gatewayエージェントでは、ゲートウェイ・プロキシへの接続が稼働していることを確認するためにモニタリングします。そのため、Hybrid Cloudエージェントの仮想マシンが、なんらかのメンテナンス・アクティビティやネットワークの停止などが原因でアクセス不可になるか停止した場合は、仮想マシンがアクセス可能になった時点で、Hybrid Cloud Gatewayエージェントにより、ゲートウェイ・プロキシが自動的に再起動されます。ただし、Hybrid Cloud Gatewayエージェントによるゲートウェイ・プロキシ・プロセスの開始にかかる時間は数秒から数分となり、実際にかかる時間は、仮想マシンがアクセスできなかった期間によって異なります。
この目的のために、Hybrid Cloud Gatewayプロキシを手動で再起動する必要はありません。ただし、それでもそのようにする場合は、次の手順を実行します。

1. 必要な仮想マシン詳細を取得するまで、設定内のすべてのHybrid Cloud Gatewayエージェントについて次のコマンドを実行し、oracle_hybridcloud_connectionターゲットの名前を識別します。
Unixプラットフォームの場合:

emctl config agent listtargets | grep <desired_virtual_machine_IP>

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

emctl.bat config agent listtargets | findstr <desired_virtual_machine_IP>

2. 手順1で見つかったHybrid Cloud GatewayエージェントでOracle_hybridcloud_connectionターゲット・インスタンスの動的プロパティをリロードします。
emctl reload agent dynamicproperties <oracle_hybridcloud_connection_target_name>:oracle_hybridcloud_connection

オンプレミスOMSでは、Oracle Cloudにデプロイされたターゲットとの通信は、SSHポート・フォワード(SSHトンネリング)を使用して行われます。図17-3にこれを示します。

図17-3 オンプレミスOMSからOracle Cloudターゲットに対する通信

17.5 Hybrid Cloud Gatewayエージェントを構成するための前提条件

の管理エージェントを構成してHybrid Cloud Gatewayエージェントとして動作させる前に、次の前提条件が満たされているようにしてください。

- CPU、RAMおよびハード・ディスク領域の要件を満たしていること。
Hybrid Cloud Gatewayエージェントに必要なCPU、RAMおよびハード・ディスク領域の要件は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されています。

なお、Hybrid Cloud Gatewayエージェントと通常の管理エージェントのハードウェア要件は同じです。

- (推奨事項) の任意の管理エージェントをHybrid Cloud Gatewayエージェントとして指定することができますが、ベスト・プラクティスとしては、モニターしているターゲットの数がごく少ない管理エージェントを選択することをお薦めします。こうすることで、Hybrid Cloud Gatewayエージェントのパフォーマンスを安定させることができます。
さらに、セントラル・エージェントはHybrid Cloud Gatewayエージェントとして指定しないことをお薦めします。ターゲットが多数存在するエンタープライズでは、セントラル・エージェントを指定すると、OMSとリソース上の競合を起こす可能性があります。

- 管理エージェントをデプロイするために必要な前提条件として『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている条件が満たされていること。

- Hybrid Cloud Gatewayエージェントはどのオペレーティング・システムで構成してもかまいませんが、Hybrid CloudエージェントはOracle Linux x86-64オペレーティング・システム上にのみデプロイしてください。

17.6 Hybrid Cloud Gatewayエージェントとしての管理エージェントの構成

既存の13cの管理エージェントをHybrid Cloud Gatewayエージェントとして構成するには、次の手順を実行します。

注意:
既存の、以前のバージョンの管理エージェントを使用して、Hybrid Cloud Gatewayエージェントとして動作するように構成できます。ただし、最初に、以前のバージョンの管理エージェントを13cにアップグレードしてから、Hybrid Cloud Gatewayエージェントとして動作するように構成することを強くお薦めします。このようにすると、スタック全体が13cに配置されます。

1. EM CLIにSYSMANユーザーとしてログインします。このとき、OMSホームにデフォルトで使用可能になっているEM CLIインストールからログインすることも、その他のホストに設定されているEM CLIインストールからログインすることもできます。

$<emcli_install_location>/bin/emcli login -username=sysman

EM CLIはデフォルトでオンプレミスOMSホストに設定されています(EM CLIのインストール場所はOMSホームです)。したがって、EM CLIをオンプレミスOMSホストから実行することにした場合、追加の手順は必要ありません。これが推奨オプションです。

たとえば、OMSホームで使用可能になっているEM CLIインストールからログインする場合は、次のコマンドを実行します。

/u01/software/em13c/oraclehome/bin/emcli login -username=sysman

オンプレミスOMSが実行されていないホストにあるカスタムな場所からEM CLIを実行することにした場合、まずそのホストでEM CLIを設定する必要があります。この方法の詳細は、Oracle Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

2. 選択した管理エージェントをHybrid Cloud Gatewayエージェントとして動作するように指定します。そのためには、次のEM CLI動詞をOMSホームから、またはEM CLIが設定されているその他のホストから実行します。

$<emcli_install_location>/bin/emcli register_hybridgateway_agent -hybridgateway_agent_list="<list_of_hybrid_cloud_gateway_agents>"

たとえば、OMSホームから実行する場合は次のコマンドを実行します。

/u01/software/em13c/oraclehome/bin/emcli register_hybridgateway_agent -hybridgateway_agent_list="abc.example.com:3873 def.example.com:3873"

なお、-hybridgateway_agent_listには複数の管理エージェント(ホスト名とポートの組合せ)を指定できます。管理エージェントには完全修飾名を指定し、スペースを使用して管理エージェント名を区切ります。

3. 管理エージェントがHybrid Cloud Gatewayエージェントとして構成されていることを確認します。これを行えるのは、第17.9.1項の説明に従ってHybrid Cloudエージェントをインストールしているときのみです。
Hybrid Cloudエージェントのインストール中には、Hybrid Cloudエージェントが通信できるHybrid Cloud Gatewayエージェントを選択する必要があります。この目的のために、「オプションの詳細」セクションのインストールの詳細ページで、「Hybrid Cloudエージェントの構成」を選択して検索アイコン(拡大鏡のアイコン)をクリックすると、オンプレミスの管理エージェントを変換して構成したHybrid Cloud Gatewayエージェントが表示されます。

17.7 Hybrid Cloud Gatewayエージェントを有効化してOracle Cloudと通信するための外部プロキシの構成

セキュリティ上の理由から、Hybrid CloudエージェントとHybrid Cloud Gatewayエージェントの間に、外部プロキシを構成することも可能です。ただし、サポートされるのはトンネリングをサポートするプロキシ(SOCK4、SOCK5、HTTPなど)のみです。

外部プロキシを、Hybrid CloudエージェントとHybrid Cloud Gatewayエージェントとの間に構成するには、次の手順に従います。

1. プロキシ・サーバーを設定します。HTTP、SOCKS4およびSOCKS5のプロキシ・サーバーがサポートされています。プロキシ・サーバーがトンネリングをサポートしていることを確認してください。

2. 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。

3. 外部プロキシを構成しようとしているHybrid Cloud Gatewayエージェントの名前を検索し、クリックします。

4. 「エージェント」メニューから「プロパティ」を選択します。

5. 「表示」で、「基本プロパティ」を選択します。externalProxyPortで、Oracle Cloudへ接続する際に使用すべき通信ポートを指定します。
「適用」をクリックします。

6. 「表示」で、「拡張プロパティ」を選択します。「ランタイム設定セクションを展開します。externalProxyHostでプロキシのホスト名を指定します。externalProxyTypeで、通信の際にプロキシでHTTP、SOCKS4またはSOCKS5のいずれが使用されるのかを選択します。
設定しているプロキシ・サーバーがユーザー名とパスワードの認証を必要とする場合は、externalProxyUsernameおよびexternalProxyPasswordに値を指定します。

7. 「適用」をクリックします。

8. 外部プロキシがSSHトンネルを通して認証手続きを問題なく行えることを確認します。これを行うには、次のコマンドを実行します。
ssh -l <user> -o "ProxyCommand /usr/bin/nc -X connect -x <proxy host>:<proxy port> %h %p" <host> <command>

17.8 Hybrid Cloudエージェントをインストールするための前提条件

Hybrid Cloudエージェントをデプロイする前に、次の前提条件が満たされているようにしてください。

- CPU、RAMおよびハード・ディスク領域の要件を満たしていること。
Hybrid Cloudエージェントに必要なCPU、RAMおよびハード・ディスク領域の要件は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されています。

- 少なくとも1つの管理エージェントをHybrid Cloud Gatewayエージェントとして動作するように構成します。Hybrid Cloud Gatewayエージェントによって、Oracle Cloud仮想ホストとオンプレミスOMSとの間の通信チャネルが提供されます。
バージョン13cの管理エージェントを構成してHybrid Cloud Gatewayエージェントとして動作させる方法の詳細は、第17.6項を参照してください。

- 接続先であるOracle Cloud仮想ホスト(Hybrid Cloudエージェントをインストールしようとしている仮想ホスト)のポート22がオープンになっており、さらにSSHデーモン・プロセスが実行中であること。接続先である仮想ホストでSSHデーモン・プロセスが実行中であるかどうかを確認するためには、仮想ホストから次のコマンドを実行します。

ps –ef | grep sshd

- 接続先であるOracle Cloud仮想ホストの各々で、ポート1748、または1830から1848までの範囲にある少なくとも1つのポートが空いていること。
デフォルトでは、ポート1748がCloud ControlによってHybrid Cloud Gatewayプロキシ・ポートとして使用されます。ポート1748が空いていない場合には、1830から1848までの範囲にある空きポートが使用されます。

- SSH公開鍵認証を使用する名前付き資格証明を少なくとも1つ設定してあること。
次のことに注意してください。

- Hybrid Cloudエージェントのデプロイでサポートされているのは、SSH公開鍵認証を使用する名前付き資格証明のみです。ユーザー名とパスワードのみを使用する名前付き資格証明はサポートされていません。

- Hybrid Cloudエージェントのデプロイの際に、ロックされたユーザー・アカウント(no direct loginが設定されているユーザー・アカウント)や、権限委任プロバイダを使用することはサポートされていません。

- パスフレーズを指定したSSHキーはサポートされていません。

SSH公開鍵認証を使用する名前付き資格証明を設定するには、SSHキー・セットを持っている必要があります。すでにSSHキー・セットを持っている場合には、「ステップ2: SSHキーのEnterprise Managerへのアップロード」へ進んでください。SSHキー・セットを持っていない場合には、「ステップ1: SSHキーの生成」に示す手順を実行してから「ステップ2: SSHキーのEnterprise Managerへのアップロード」へと進んでください。

ステップ1: SSHキーの生成

1. Oracle Cloud仮想ホストに任意のユーザーでログインします。

2. 次のコマンドを実行します。

cd $HOME/.ssh

3. 次のコマンドを実行します。

ssh-keygen -N "" -b 2048 -t rsa -f id_rsa -C "<my_comment>"

ここで<my_comment>は、SSHキーを識別できるようにするためのコメントまたはフレーズを表します。

id_rsaおよびid_rsa.pubという2つのファイルが.sshディレクトリに作成されます。

4. id_rsa.pubファイルの内容を、authorized_keysファイルの末尾に追加します。それには、次のコマンドを実行します。

cat id_rsa.pub >> authorized_keys

ステップ2: SSHキーのEnterprise Managerへのアップロード

1. 「設定」メニューから、「セキュリティ」、「名前付き資格証明」の順に選択します。「作成」をクリックします。「資格証明名」には資格証明の名前を指定し、「資格証明のタイプ」には「SSHキー資格証明」を選択し、「有効範囲」には「グローバル」を選択します。

2. ステップ1で作成した秘密SSH鍵をアップロードします。「資格証明プロパティ」セクションで「秘密鍵のアップロード」フィールドの値として秘密SSH鍵の場所を指定します。「保存」をクリックします。

3. ステップ1で作成した公開SSH鍵をアップロードします。「資格証明プロパティ」セクションで「公開鍵のアップロード」フィールドの値として公開SSH鍵の場所を指定します。「保存」をクリックします。

- Hybrid Cloudエージェントのインストール・ユーザーがroot.shスクリプトを実行するためのroot権限を持っていること。Hybrid Cloudエージェントのインストール・ユーザーがroot権限を持っていない場合は、デプロイ作業後、必ずすべての接続先仮想ホストでroot.shスクリプトを手動で実行してください。

- オンプレミス管理エージェントをデプロイするために必要な前提条件として『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている条件が満たされていること。

- Hybrid CloudエージェントはOracle Linux x86-64オペレーティング・システム上にデプロイしてください。Hybrid Cloud Gatewayエージェントはすべてのオペレーティング・システムでサポートされていますが、Hybrid CloudエージェントはOracle Linux x86-64オペレーティング・システム上でのみサポートされています。

- Hybrid Cloudエージェントを仮想ホストにインストールするには、仮想ホストのローカル・ファイル・システムにインストールするのではく、外部のストレージ・デバイスを使用してマウントを作成し、そこにHybrid Cloudエージェントをインストールします。そうしないと、仮想ホストを停止、起動または再起動するたびに起動ボリュームに格納されているデータがすべて失われます。

- 仮想マシン(VM)ネットワークまたはホスト構成設定のドメイン名を変更していないことを確認します。Hybrid CloudエージェントをOracle Public CloudでホストされたVMのみに使用する必要があります。したがって、VMドメイン名を変更して、Oracle Public Cloud以外でホストされたVMに反映すると、Hybrid Cloudエージェントは失敗します。
検証するには、VMにログインしてhostname -dコマンドを実行し、出力にoracle.comまたはoraclecloud.internalのいずれかが含まれていることを確認します。その他のドメイン名が出力された場合は、それをリストから削除します。

また、次のコマンドを実行して、出力にoracle.comまたはoraclecloud.internalのいずれかが含まれていることを確認します。その他のドメイン名が出力された場合は、それをリストから削除します。

cat /etc/sysconfig/network

cat /etc/resolv.conf

cat /etc/hosts

17.9 Hybrid Cloudエージェントのインストール

この項ではHybrid Cloudエージェントをインストールする次の方法について説明します。

- ホスト・ターゲットの追加ウィザードを使用したHybrid Cloudエージェントのインストール

- EM CLIを使用したHybrid Cloudエージェントのインストール

注意:
Hybrid CloudエージェントはSSHブリッジを介してオンプレミスOMSに接続しているため、サイレント・エージェント・インストールなどの手動デプロイメントはHybrid Cloudエージェントにはサポートされていません。「ホスト・ターゲットの追加」ウィザードまたはEM CLI以外の方法でHybrid Cloudエージェントをデプロイすることはできません。
Hybrid CloudエージェントはOracle Linux x86-64オペレーティング・システム上にのみデプロイできます。Hybrid Cloud Gatewayエージェントはすべてのオペレーティング・システムでサポートされていますが、Hybrid CloudエージェントはOracle Linux x86-64オペレーティング・システム上でのみサポートされています。

17.9.1 ホスト・ターゲットの追加ウィザードを使用したHybrid Cloudエージェントのインストール

ホスト・ターゲットの追加ウィザード使用してHybrid Cloudエージェントをインストールするには、次の手順に従います。

1. Cloud Controlで、「設定」メニューから、「ターゲットの追加」を選択し、「ターゲットの手動追加」をクリックします。「ターゲットの手動追加」ページで、「ホスト・ターゲットの追加」を選択し、「ホストの追加」をクリックします。

2. ホストとプラットフォーム・ページで、次を実行します。

1. このセッションに割り当てられたデフォルトの名前のままにするか、選択した一意の名前を入力します。入力するカスタム名は直観的な名前にすることができ、必ずしもデフォルトの名前と同じフォーマットにする必要はありません。たとえば、add_host_hybrid_cloud_operation_1のようにします

2. 「追加」をクリックしてIPアドレスを入力し、Hybrid CloudエージェントをインストールしようとしているOracle Cloud仮想ホストのプラットフォームを選択します。Oracle Cloudサービスを実行している各々の仮想ホストのIPアドレスはOracleによって割り当てられていたものです。

注意:

- Hybrid Cloudエージェントのデプロイは、Linux x86-64プラットフォームでのみサポートされています。

- IPアドレスは、1行につき1つのみ入力する必要があります。カンマで区切った複数のアドレスの入力は、サポートされていません。

もう1つの方法として、「ファイルからロード」をクリックしてファイルに格納されたIPアドレスを追加することもできます。

すべての仮想ホストに対し、プラットフォームをLinux x86-64として指定します。これを行うには、最初の仮想ホストのプラットフォームをLinux x86-64として指定し、次に「プラットフォーム」リストから、「すべてのホストで同一」を選択します。

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

3. 「インストールの詳細」ページで、次のようにします。

1. 「デプロイメント・タイプ」セクションで、新規エージェント・インストールを選択します。

2. 表から、共通のプラットフォーム名でグループ化された仮想ホストを示す最初の行を選択します。

3. 「インストールの詳細」セクションで、ステップ3の(b)で選択した仮想ホストに共通するインストールの詳細を指定します。「インストールのベース・ディレクトリ」に、Hybrid Cloudエージェントのソフトウェア・バイナリ、セキュリティ・ファイルおよびインベントリ・ファイルをコピーするOracle Cloud仮想ホスト上のベース・ディレクトリへの絶対パスを入力します。
たとえば、/u01/app/Oracle/などです。

入力するパスが存在しない場合は、アプリケーションによって、指定したパスにディレクトリが作成され、Hybrid Cloudエージェント・ソフトウェア・バイナリ、セキュリティ・ファイルおよびインベントリ・ファイルがそこにコピーされます。

4. 「インスタンス・ディレクトリ」で、デフォルトのインスタンス・ディレクトリの場所のままにするか、すべてのHybrid Cloudエージェント関連の構成ファイルを格納できるディレクトリを選択し、そこへの絶対パスを入力します。
たとえば、/u01/app/Oracle/agent_instなどです。

カスタムの場所を入力する場合、そのディレクトリに書込み権限があることを確認してください。インストールのベース・ディレクトリ内にインスタンス・ディレクトリを保持することをお薦めします。

入力したパスが存在しない場合は、指定されたパスにディレクトリが作成され、Hybrid Cloudエージェントに関連するすべての構成ファイルがその場所にコピーされます。

5. 「名前付き資格証明」で、オンプレミスOMSと接続先Oracle Cloud仮想ホストとの間のSSH接続を設定するとき、および各々のOracle Cloud仮想ホスト上にHybrid Cloudエージェントをインストールするときに使用する名前付き資格証明を選択します。
SSH公開鍵認証を使用する名前付き資格証明以外は指定しないでください。パスワード・ベースの認証はサポートされていません。また、ロックされたユーザー・アカウントを使用したHybrid Cloudエージェントのデプロイ(権限委任プロバイダを使用してロックされたユーザー・アカウントへの切替え)もサポートされていないことに注意してください。

SSH公開鍵を使用した名前付き資格証明の作成方法は、第17.8項を参照してください。

6. 「権限委任設定」では、デフォルトの値を使用します。Hybrid Cloudエージェントのデプロイでは、権限委任プロバイダおよびロックされたアカウントはサポートされていません。
Hybrid Cloudエージェントのインストール・ユーザーがroot権限を持っている場合、接続先仮想ホストではroot.shがデプロイ後に自動実行されます。そうでない場合は、デプロイ後に各接続先仮想ホスト上でroot.shを手動で実行してください。

7. 「ポート」で、Hybrid Cloudエージェントの通信用に割り当てられたデフォルトのポート(3872)のままにするか、選択したポートを入力します。
入力するカスタム・ポートはビジー状態ではない必要があります。不明な場合、このフィールドを空白にしておくことができます。Cloud Controlによって、1830 - 1849の範囲から最初の使用可能な空きポートが自動的に割り当てられます。

8. Hybrid Cloudエージェントのデプロイの前または後に実行するスクリプトがある場合には、「オプションの詳細」で、実行するスクリプトがある場所の絶対パスを入力します。サポートされているのはシェル・スクリプトのみであり、インストール前スクリプトまたはインストール後スクリプトを1つのみ指定できることに注意してください。
スクリプトをrootとして実行するには、「Rootとして実行」を選択します。スクリプトがオンプレミスOMSが実行されているホストにあり、Hybrid Cloudエージェントをインストールしようとする仮想ホスト上にはない場合、「OMSのスクリプト」を選択します。この場合、スクリプトはオンプレミスOMSホストから接続先仮想ホストにコピーされてから、接続先仮想ホストで実行されます。

9. 追加で指定するパラメータがある場合、「オプションの詳細」セクションの「追加パラメータ」で、追加パラメータを空白区切りのリストで入力します。
たとえば、インベントリ・ポインタの場所ファイルを指定する場合、-invPtrLocの後ろにファイルの場所への絶対パスを入力します。ただし、このパラメータはUNIXプラットフォームでのみサポートされ、Microsoft Windowsプラットフォームではサポートされないことに注意してください。

10. 「オプションの詳細」セクションで「Hybrid Cloudエージェントの構成」を選択し、Hybrid Cloudエージェントが通信すべき相手となるHybrid Cloud Gatewayエージェントの詳細を指定します。
「Hybrid Cloud Gatewayエージェント」で、Hybrid Cloudエージェントの通信相手となるHybrid Cloud Gatewayエージェントとして使用するエンタープライズ内の管理エージェントを指定します。拡大鏡アイコンをクリックし、表示されたリストの中からHybrid Cloud Gatewayエージェントを1つ選択します(稼働中のHybrid Cloud Gatewayエージェントのみが表示されます)。

このフィールドには、Hybrid Cloud Gatewayとしてすでに指定されている管理エージェントのみを指定できることに注意してください。特定の管理エージェントをHybrid Cloud Gatewayエージェントとして指定する方法は、第17.6項を参照してください。

「Hybrid Cloud Gatewayプロキシ・ポート」で、Hybrid CloudエージェントとHybrid Cloud Gatewayプロキシとの間の通信に使用されるポートを指定します。値を指定しなかった場合はポート1748が使用され、ポート1748が空いていない場合はポート1830から1848の間で空いているポートが使用されます。

11. 表にある他のすべての行に対して、ステップ3の(b)からステップ3の(j)までを繰り返します。

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

4. 「確認」ページで、インストールに指定した詳細を確認し、詳細に問題がない場合、「エージェントのデプロイ」をクリックして、Hybrid Cloudエージェントをインストールします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

「エージェントのデプロイ」をクリックして、デプロイメント・セッションを送信すると、エージェント・デプロイ詳細ページが自動的に表示され、デプロイメント・セッションの進行を監視できます。このページで実行できるタスクを理解するには、「ヘルプ」をクリックします。

5. Oracle CloudにHybrid Cloudエージェントがデプロイされたことを確認するために、「設定」メニューから「Cloud Controlの管理」を選択し、「エージェント」を選択します。Hybrid Cloudエージェントの名前を検索し、クリックしてそのホーム・ページにアクセスします。Hybrid Cloudエージェント・ターゲット名の横に、「Oracle Cloudで実行中」およびクラウド・アイコンが表示されます。

注意:
Hybrid Cloudエージェントでは、次の機能はサポートされていないか、一部サポートされています。

- バディ・エージェント

- 管理エージェントから管理エージェントへの通信

- 分散ソフトウェア・ライブラリ

- ターゲットの再配置

- サード・パーティの管理エージェント証明書に対するサポート

- サポート・ワークベンチ

関連項目:
Oracle Cloud仮想ホストにHybrid Cloudエージェントがデプロイされている場合、同じ仮想ホストに他のHybrid Cloudエージェントをデプロイすることはできますか。

17.9.2 EM CLIを使用したHybrid Cloudエージェントのインストール

EM CLIを使用してHybrid Cloudエージェントをインストールするには、次の手順に従います。

1. 次のEM CLIのインストールの場所にある/binディレクトリからEM CLIにログインします。

$<emcli_install_location>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

EM CLIはデフォルトでオンプレミスOMSホストに設定されています(EM CLIのインストール場所はOMSホームです)。したがって、EM CLIをオンプレミスOMSホストから実行することにした場合、追加の手順は必要ありません。これが推奨オプションです。

オンプレミスOMSが実行されていないホストにあるカスタムな場所からEM CLIを実行することにした場合、まずそのホストでEM CLIを設定する必要があります。この方法の詳細は、Oracle Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

2. list_add_host_platforms動詞を実行して、Hybrid Cloudエージェント・ソフトウェアを自己更新で使用可能なプラットフォームのリストを取得します。

$<emcli_install_location>/bin/emcli list_add_host_platforms
[-all]
[-noheader]
[-script | -format]

[ ]内のパラメータはオプションであることに注意してください。

たとえば、$<emcli_install_location>/bin/emcli list_add_host_platforms -allとなります

特定のプラットフォーム用の管理エージェント・ソフトウェアが入手できない場合は、自己更新を使用してソフトウェアをダウンロードおよび適用してください。管理エージェントのダウンロードおよび適用方法の詳細は、『Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

list_add_host_platforms動詞に関する構文や使用法の詳細を表示するには、次のコマンドを実行します。

$<emcli_install_location>/bin/emcli help list_add_host_platforms

3. Hybrid Cloudエージェントを選択したOracle Public Cloud仮想ホストへ、1つのデプロイメント・フェーズから次へと連続してデプロイメントを実行するローリング方式でデプロイするときは、次を$OMS_HOME/sysman/prov/agentpush/agentpush.propertiesファイルへ指定します。
oracle.sysman.prov.agentpush.continueIgnoringFailedHost=true

4. submit_add_host動詞を実行して-configure_hybrid_cloud_agent、-hybrid_cloud_gateway_agentおよび-hybrid_cloud_gateway_proxy_portオプションを指定し、ホストの追加セッションの発行およびHybrid Cloudエージェントのインストールを行います。

$<emcli_install_location>/bin/emcli submit_add_host
-host_names=<list_of_hosts>
-platform=<platform_ID>
-installation_base_directory=<install_directory_of_agent>
-credential_name=<named_credential_for_agent_install>
-configure_hybrid_cloud_agent
-hybrid_cloud_gateway_agent=<hybrid_cloud_gateway_agent_name>
[-hybrid_cloud_gateway_proxy_port=<hybrid_cloud_gateway_proxy_port>]
[-credential_owner=<named_credential_owner>]
[-instance_directory=<agent_instance_directory>]
[-port=<agent_port>]
[-session_name=<add_host_session_name>]
[-deployment_type=<type_of_agent_deployment>]
[-privilege_delegation_setting=<privilege_delegation>]
[-additional_parameters=<additional_params_for_install>]
[-source_agent=<source_agent_for_cloned_agent_install>]
[-master_agent=<master_agent_for_shared_agent_install>]
[-properties_file=<properties_file_having_inputs>]
[-preinstallation_script=<pre_install_script>]
[-preinstallation_script_on_oms]
[-preinstallation_script_run_as_root]
[-postinstallation_script=<post_install_script>]
[-postinstallation_script_on_oms]
[-postinstallation_script_run_as_root]
[-wait_for_completion]

[ ]内のパラメータはオプションであることに注意してください。

たとえば、$<emcli_install_location>/bin/emcli submit_add_host -host_names=opc1.example.com -platform=226 -installation_base_directory=/opt/agent -credential_name=oracle -configure_hybrid_cloud_agent -hybrid_cloud_gateway_agent=abc.example.com -hybrid_cloud_gateway_proxy_port=1748となります

この例では、Hybrid Cloudエージェントを、Oracle Public Cloud仮想ホストopc1.example.comにプラットフォームID226で、ディレクトリ/opt/agent,内に、名前付き資格証明oracleを使用してインストールします。デプロイされたHybrid Cloudエージェントは、abc.example.comをHybrid Cloud Gatewayとして使用し、ポート1748を使用してHybrid Cloud Gatewayプロキシと通信します。

submit_add_host動詞に関する構文や使用法の詳細を表示するには、次のコマンドを実行します。

$<emcli_install_location>/bin/emcli help submit_add_host

関連項目:
Oracle Cloud仮想ホストにHybrid Cloudエージェントがデプロイされている場合、同じ仮想ホストに他のHybrid Cloudエージェントをデプロイすることはできますか。

17.10 Hybrid Cloud GatewayエージェントおよびHybrid Cloudエージェントのアップグレード

Hybrid Cloud GatewayエージェントまたはHybrid Cloudエージェントをアップグレードする手順は、オンプレミスEnterprise Manager環境で、あらゆる標準的なスタンドアロンの管理エージェントをアップグレードする手順と同じです。手順については、『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

17.11 Hybrid Cloud Managementの追加タスクの実行

この項ではHybrid Cloud Managementの追加タスクについて説明します。内容は次のとおりです。

- 高可用性確保のためのHybrid Cloudエージェントの構成(推奨)

- Hybrid Cloud Gatewayエージェントの無効化

- Hybrid Cloud GatewayエージェントとHybrid Cloudエージェントとの関連付けの解除

- Hybrid Cloudエージェントの廃止

17.11.1 高可用性確保のためのHybrid Cloudエージェントの構成(推奨)

Hybrid Cloudエージェントをデプロイすると、デフォルトではこれに対して単一のHybrid Cloud Gatewayが関連付けられます。Hybrid Cloudエージェントは、そのライフサイクルを通じてHybrid Cloud Gatewayエージェントに依存して、収集したモニタリング・データをオンプレミスのCloud Control OMSに転送しています。したがって、Hybrid Cloud Gatewayエージェントが停止していたりアクセスできなかったりすると、Hybrid Cloudエージェントのモニタリング・データがオンプレミスOMSに届かなくなります。そこで、Hybrid Cloudエージェントから複数のHybrid Cloud Gatewayエージェントが使用できるようにして、モニタリング・データのロスが発生する可能性を抑えることをお薦めします。

Hybrid Cloudエージェントをデプロイする際、最初に選択したHybrid Cloud GatewayエージェントがプライマリHybrid Cloud Gatewayエージェントになります。デプロイされたHybrid Cloudエージェントから追加のHybrid Cloud Gatewayエージェントを使用できるようにすると、追加されたHybrid Cloud GatewayエージェントはセカンダリHybrid Cloud Gatewayエージェントになります。このようにすれば、Hybrid CloudエージェントのプライマリHybrid Cloud Gatewayエージェントが停止したりアクセスできなくなったりした場合には、いずれかのセカンダリHybrid Cloud Gatewayエージェントが後を引き継ぎます。引き継いだセカンダリHybrid Cloud Gatewayエージェントが停止したりアクセスできなくなったりした場合には、次に使用可能なセカンダリHybrid Cloud Gatewayエージェントが後を引き継ぎます。

図17-4は、Hybrid CloudエージェントからオンプレミスOMSへ複数のHybrid Cloud Gatewayエージェントを経由して行われる通信を図示したものです。

図17-4 Hybrid CloudエージェントからオンプレミスOMSへ高可用性確保のため複数のHybrid Cloud Gatewayエージェントを経由して行われる通信

Hybrid Cloudエージェントが高可用性を確保するよう構成するには、1つ以上のセカンダリHybrid Cloud Gatewayエージェントを各Hybrid Cloudエージェントに関連付けます。次の手順を実行します。

1. 次のEM CLIのインストールの場所にある/binディレクトリからEM CLIにログインします。

$<emcli_install_location>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

EM CLIはデフォルトでオンプレミスOMSホストに設定されています(EM CLIのインストール場所はOMSホームです)。したがって、EM CLIをオンプレミスOMSホストから実行することにした場合、追加の手順は必要ありません。これが推奨オプションです。

オンプレミスOMSが実行されていないホストにあるカスタムな場所からEM CLIを実行することにした場合、まずそのホストでEM CLIを設定する必要があります。この方法の詳細は、Oracle Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

2. Hybrid Cloudエージェントに1つ以上のセカンダリHybrid Cloud Gateway Agentを関連付けます。

$<emcli_install_location>/bin/emcli add_hybridgateway_for_hybrid_agent
-hybrid_agent_name="<hybrid_cloud_agent1>:<port> <hybrid_cloud_agent2>:<port> <hybrid_cloud_agentN>:<port>" -hybridgateway_agent_list="<secondary_hybrid_cloud_gateway_agent>:<port>"

たとえば、emcli add_hybridgateway_for_hybrid_agent -hybrid_agent_name="abc.example.com:1831 def.example.com:3872" -hybridgateway_agent_list="secondary1.example.com:1831"のようにします

関連項目:
高可用性を得るために複数のHybrid Cloud Gatewayエージェントを構成した状態で、Hybrid Cloud Gatewayエージェントのうち1つにパッチを適用したところ、モニタリングが他のHybrid Cloud Gatewayエージェントに切り替わりました。最初のHybrid Cloud Gatewayエージェントをパッチ適用後に起動すれば、Hybrid Cloudエージェントをモニターするようになるのでしょうか。
Hybrid Cloud Gatewayエージェントを追加した後になって接続を再分配するにはどうすればよいですか。再構成が必要ですか。

17.11.2 Hybrid Cloud Gatewayエージェントの無効化

Hybrid Cloud Gatewayエージェントのゲートウェイ機能を無効化して、Hybrid Cloud Gatewayエージェントを再び通常の管理エージェントのように動作させ、Hybrid CloudエージェントからオンプレミスOMSへの通信が転送されるのを止めるには、次の手順に従います。

1. 次のEM CLIのインストールの場所にある/binディレクトリからEM CLIにログインします。

$<emcli_install_location>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

EM CLIはデフォルトでオンプレミスOMSホストに設定されています(EM CLIのインストール場所はOMSホームです)。したがって、EM CLIをオンプレミスOMSホストから実行することにした場合、追加の手順は必要ありません。これが推奨オプションです。

オンプレミスOMSが実行されていないホストにあるカスタムな場所からEM CLIを実行することにした場合、まずそのホストでEM CLIを設定する必要があります。この方法の詳細は、Oracle Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

2. Hybrid Cloud Gatewayエージェントのゲートウェイ機能を無効化します。

$<emcli_install_location>/bin/emcli deregister_hybridgateway_agent -hybridgateway_agent_list="<hybrid_cloud_gateway_agent1>:<port> <hybrid_cloud_gateway_agent2>:<port> <hybrid_cloud_gateway_agentN>:<port>"

たとえば、emcli deregister_hybridgateway_agent -hybridgateway_agent_list="abc.example.com:3873 def.example.com:3873"のようにします

このとき、-hybridgateway_agent_listには複数のHybrid Cloud Gatewayエージェントを指定できます。各々のHybrid Cloud Gatewayエージェントは完全修飾名で指定し、各エージェント名の間はスペース1個で区切ってください。

17.11.3 Hybrid Cloud GatewayエージェントとHybrid Cloudエージェントとの関連付けの解除

Hybrid Cloud GatewayエージェントとHybrid Cloudエージェントとの関連付けを解除して、以降はHybrid CloudエージェントがHybrid Cloud GatewayエージェントおよびオンプレミスOMSと通信しないようにするには、次の手順に従います。

1. 次のEM CLIのインストールの場所にある/binディレクトリからEM CLIにログインします。

$<emcli_install_location>/bin/emcli login -username=<user_name>

このコマンドを実行すると、EM CLIによってパスワードが求められます。指定したユーザー名のパスワードを入力します。

EM CLIはデフォルトでオンプレミスOMSホストに設定されています(EM CLIのインストール場所はOMSホームです)。したがって、EM CLIをオンプレミスOMSホストから実行することにした場合、追加の手順は必要ありません。これが推奨オプションです。

オンプレミスOMSが実行されていないホストにあるカスタムな場所からEM CLIを実行することにした場合、まずそのホストでEM CLIを設定する必要があります。この方法の詳細は、Oracle Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

2. Hybrid CloudエージェントとHybrid Cloud Gatewayエージェントとの関連付けを解除します。

$<emcli_install_location>/bin/emcli delete_hybridgateway_for_hybrid_agent
-hybrid_agent_name="<hybrid_cloud_agent1>:<port> <hybrid_cloud_agent2>:<port> <hybrid_cloud_agentN>:<port>" -hybridgateway_agent_list="<hybrid_cloud_gateway_agent_to_disassociate>:<port>"

たとえば、emcli delete_hybridgateway_for_hybrid_agent -hybrid_agent_name="abc.example.com:1831 def.example.com:3872" -hybridgateway_agent_list="gateway1.example.com"のようにします

関連項目:
関連付けられているHybrid CloudエージェントをアンインストールせずにHybrid Cloud Gatewayエージェントのアンインストールと構成解除を行えますか。

17.11.4 Hybrid Cloudエージェントの廃止

Hybrid Cloudエージェントを廃止するには、次の手順に従います。

1. Hybrid Cloudエージェントを停止します。

2. Hybrid Cloudエージェントのエージェント・ホームページで、「エージェント」メニューから「ターゲット設定」を選択し、さらに「エージェント廃止」を選択します。

関連項目:
関連付けられているHybrid CloudエージェントをアンインストールせずにHybrid Cloud Gatewayエージェントのアンインストールと構成解除を行えますか。

17.12Hybrid CloudエージェントとHybrid Cloud Gatewayエージェントへのパッチの適用

パッチ計画を使用してHybrid CloudエージェントとHybrid Cloud Gatewayエージェントにパッチを適用できます。パッチ計画はグループとして展開されるべき1つ以上のパッチからなる統合化された計画です。パッチ適用プロシージャは、通常の管理エージェント、Hybrid CloudエージェントおよびHybrid Cloud Gatewayエージェントのいずれに対しても同じになっています。

警告:
2015年6月の最初の週より前にOracle Cloudで作成されたデータベース・インスタンスは、通常、2015年1月にリリースされたデータベース・パッチセット(Jan DB PSU).に基づいています。そのようなデータベース・インスタンスに2015年4月にリリースされたデータベース・パッチセット(Apr DB PSU)を適用する場合、前提条件として、パッチセット更新を適用する前に、次のファイルを作成し、絶対パスをHybrid Cloudエージェントが使用可能なディレクトリに追加します。
/var/opt/oracle/patch/files_to_save.ora

前述の手順を実行しないと、データベース・パッチ適用のプロセスの一部として/u01/app/oracle内のHybrid Cloudエージェントが自動的に/u01/app.ORG/oracleに移動します。この場合、ディレクトリを手動でコピーして元の場所に戻す必要があります。この問題を回避し、手動で作業する手間を防ぐために、前述の手順を実行し、指示されたファイルを作成してHybrid Cloudエージェントの場所をファイルに追加することをお薦めします。

Oracle Cloud仮想ホスト上のHybrid Cloudエージェントにパッチを適用するには、次の手順に従います。

1. 適用しようとしているパッチがエージェント・ホームのsbinディレクトリにアクセスする場合は、最初にパッチにあるReadMeファイルで概説されている指示に従います。

2. Oracle Enterprise Manager Cloud Controlライフサイクル管理ガイドに概説されている指示に従ってHybrid Cloudエージェントにパッチを適用します。パッチ適用プロシージャは、通常の管理エージェントおよびHybrid Cloudエージェントのいずれに対しても同じになっています。

Hybrid Cloud Gatewayエージェントにパッチを適用するには、Oracle Enterprise Manager Cloud Controlライフサイクル管理ガイドに概説されている指示に従ってください。

関連項目:
高可用性を得るために複数のHybrid Cloud Gatewayエージェントを構成した状態で、Hybrid Cloud Gatewayエージェントのうち1つにパッチを適用したところ、モニタリングが他のHybrid Cloud Gatewayエージェントに切り替わりました。最初のHybrid Cloud Gatewayエージェントをパッチ適用後に起動すれば、Hybrid Cloudエージェントをモニターするようになるのでしょうか。

17.13 Oracle Cloudターゲットの検出および監視

Hybrid Cloud Gatewayエージェントがオンプレミス環境にデプロイされ、Hybrid CloudエージェントがOracle Cloud環境にデプロイされると、Oracle Cloud仮想ホストはEnterprise Manager Cloud Controlで管理可能ターゲットになります。これらの管理可能な仮想ホストで実行されるターゲットを検出および監視するには、『Oracle Enterprise Manager Cloud Control管理者ガイド』で説明されている手順に従います。Oracle Cloud仮想ホストで実行されるターゲットを検出および昇格する手順は、オンプレミス環境の通常のホストで実行中のターゲットを検出および監視する手順と同様です。

ただし、WebLogic JCSのようなFMWドメインをOracle Cloud仮想ホストで検出するには、パブリックIPアドレスおよびポート9001(これらの管理サーバーでデフォルトで構成されるカスタムt3チャネルを表します)を使用します。

17.14 Hybrid Cloud Managementに関するよくある質問

この項では、Hybrid Cloud Managementに関連した次のようなよくある質問への回答を示します。

- Oracle Cloud仮想ホストにHybrid Cloudエージェントがデプロイされている場合、同じ仮想ホストに他のHybrid Cloudエージェントをデプロイすることはできますか。

- 関連付けられているHybrid CloudエージェントをアンインストールせずにHybrid Cloud Gatewayエージェントのアンインストールと構成解除を行えますか。

- 他に何もアンインストールせずにHybrid Cloud Gatewayエージェントを他のホストに再配置するにはどうすればよいですか。

- Hybrid Cloud Gatewayエージェントを追加した後になって接続を再分配するにはどうすればよいですか。再構成が必要ですか。

- Oracle Cloud PortalからOracle PaaSインスタンスを廃止した後、Hybrid CloudエージェントおよびEnterprise Manager Cloud Controlコンソールの関連ターゲットに対し行う必要があることは何ですか。

- Oracle CloudでSSHキーを変更した場合、Enterprise Managerでは何をすればよいですか。

- Hybrid Cloud Gatewayエージェントの数を決めるための指標は何ですか。Hybrid Cloud Gatewayエージェントが過負荷になっていることを示す兆候は何ですか。

- 高可用性を得るために複数のHybrid Cloud Gatewayエージェントを構成した状態で、Hybrid Cloud Gatewayエージェントのうち1つにパッチを適用したところ、モニタリングが他のHybrid Cloud Gatewayエージェントに切り替わりました。最初のHybrid Cloud Gatewayエージェントをパッチ適用後に起動すれば、Hybrid Cloudエージェントをモニターするようになるのでしょうか。

- Hybrid CloudエージェントおよびOracle Cloudのターゲットでのユーザーに対する制限は何ですか。

- どんなオペレーティング・システムにHybrid CloudエージェントおよびHybrid Cloud Gatewayエージェントをデプロイできますか。

17.14.1 Oracle Cloud仮想ホストにHybrid Cloudエージェントがデプロイされている場合、同じ仮想ホストに他のHybrid Cloudエージェントをデプロイすることはできますか。

はい、できます。ただし、すでにOracle Cloud仮想ホスト上に存在するHybrid Cloudエージェントをまず廃止してから、他のHybrid Cloudエージェントをデプロイしてください。

すでにOracle Cloud仮想ホスト上に存在するHybrid Cloudエージェントを廃止するには、次の手順に従います。

1. Hybrid Cloudエージェントのエージェント・ホームページで、「エージェント」メニューから「ターゲット設定」を選択し、さらに「エージェント廃止」を選択します。

2. Hybrid Cloudエージェントを第17.9項の説明に従って新たにデプロイします。

17.14.2 関連付けられているHybrid CloudエージェントをアンインストールせずにHybrid Cloud Gatewayエージェントのアンインストールと構成解除を行えますか。

いいえ、できません。まず、すでにOracle Cloud仮想ホスト上に存在するHybrid Cloudエージェントを廃止する必要があります。Hybrid Cloudエージェントを廃止すると、関連付けられているHybrid Cloud Gatewayエージェントは自動的に削除されます。

Hybrid Cloud Gatewayエージェントが1つのみであるときに、これをアンインストールする場合は、次の手順に従います。

1. Hybrid Cloudエージェントを停止します。

2. Hybrid Cloudエージェントのエージェント・ホームページで、「エージェント」メニューから「ターゲット設定」を選択し、さらに「エージェント廃止」を選択します。

Hybrid Cloud Gatewayエージェントが複数存在するときに、プライマリHybrid Cloud Gatewayエージェントをアンインストールする場合は、次の手順に従います。

1. プライマリHybrid Cloud Gatewayエージェントを終了します。これにより、Hybrid Cloudエージェントからの通信は自動的にセカンダリHybrid Cloud Gatewayエージェントにリダイレクトされます。

2. プライマリHybrid Cloud Gatewayエージェントをアンインストールします。

注意:
プライマリHybrid Cloud Gatewayエージェントと関連付けられているHybrid Cloudエージェントの構成を解除する必要はありません。必要なのは、ステップ(1)の説明に従ってプライマリHybrid Cloud Gatewayエージェントを停止することのみです。
ステップ(2)の実行後は、セカンダリHybrid Cloud GatewayエージェントがプライマリHybrid Cloud Gatewayエージェントとして動作します。

ステップ(2)でアンインストールしたHybrid Cloud Gatewayエージェントを復帰させても、セカンダリHybrid Cloud Gatewayエージェントになるだけです。

関連項目:
他に何もアンインストールせずにHybrid Cloud Gatewayエージェントを他のホストに再配置するにはどうすればよいですか。

17.14.3 他に何もアンインストールせずにHybrid Cloud Gatewayエージェントを他のホストに再配置するにはどうすればよいですか。

Hybrid Cloud Gatewayエージェントをあるホストから他のホストに再配置することはできません。再配置ロジックはHybrid Cloud Gatewayエージェントでモニターされているターゲットのためのものであって、Hybrid Cloud Gatewayエージェントのためのものではないからです。

17.14.4 Hybrid Cloud Gatewayエージェントを追加した後になって接続を再分配するにはどうすればよいですか。再構成が必要ですか。

はい、Hybrid Cloud Gatewayエージェントを新たに追加した後になって接続を再分配することは可能です。ただし、これを自動的行う方法はありません。手動で接続の再分配を行う必要があります。

たとえば、Hybrid Cloud Gatewayエージェントが1つと、これに関連付けられたHybrid Cloudエージェントが複数ある場合、ここでHybrid Cloud Gatewayエージェントをもう1つデプロイすると、接続を2つのゲートウェイの間で再分配することができます。

次の手順を実行します。

1. プライマリHybrid Cloud GatewayエージェントのHybrid Cloudエージェントに対するゲートウェイ機能を停止します。これを行うには、次のコマンドを実行します。このコマンドにより、OMSがプライマリ・ゲートウェイからセカンダリ・ゲートウェイに切替わります。
emcli delete_hybridgateway_for_hybrid_agent -hybrid_agent_name="<hybrid_agent_name>:<port>" -hybridgateway_agent_list="<primary_gateway_agent>:<port>"

2. 古いプライマリ・ゲートウェイをHybrid Cloudエージェントに再度追加します。これを行うには、次のコマンドを実行します。このコマンドは、古いプライマリ・ゲートウェイをセカンダリ・ゲートウェイとしてHybrid Cloudエージェントにリストアします。
emcli add_hybridgateway_for_hybrid_agent -hybrid_agent_name="<hybrid_agent_name>:<port>" -hybridgateway_agent_list="<old_primary_gateway_agent>:<port>"

17.14.5 Oracle Cloud PortalからOracle PaaSインスタンスを廃止した後、Hybrid CloudエージェントおよびEnterprise Manager Cloud Controlコンソールの関連ターゲットに対し行う必要があることは何ですか。

Oracle PaaSインスタンスがOracle Cloudから廃止されると、Hybrid Cloudエージェントはアクセス不可の状態に置かれることになります。Enterprise Manager Cloud ControlコンソールからHybrid Cloudエージェントをクリーン・アップするには、次の手順に従います。

1. Enterprise Manager Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択し、「エージェント」を選択します。

2. コンソールからクリーン・アップするHybrid Cloudエージェントの名前をクリックします。

3. エージェント・ホームページで、「エージェント」メニューから「ターゲット設定」を選択し、さらに「エージェント廃止」をクリックします。

4. 削除するターゲットを選択し、「発行」をクリックします。

17.14.6 Oracle CloudでSSHキーを変更した場合、Enterprise Managerでは何をすればよいですか。

新しいSSHキーを使用してモニタリング資格証明を更新し、新たにデプロイが行われる際にすべてのHybrid Cloudエージェントが資格証明を自動的に保持できるようにします。新しいキーが保存されると、それ以降SSHトンネリングではHybrid Cloudエージェントとの通信にその新しいキーが使用されます。

モニタリング資格証明を更新するには、次の手順に従います。

1. Enterprise Manager Cloud Controlコンソールの「設定」メニューから「セキュリティ」を選択し、「モニタリング資格証明」を選択します。

2. 「モニタリング資格証明」ページで、表の「Hybrid Cloud接続」をクリックします。

3. Hybrid Cloud接続モニタリング資格証明ページで、新しいSSHキーに更新するターゲット名を選択し「資格証明の設定」をクリックします。

4. 「モニタリング資格証明の入力」で新しいSSH秘密鍵とSSH公開鍵を入力し「保存」をクリックします。

17.14.7 Hybrid Cloud Gatewayエージェントの数を決めるための指標は何ですか。Hybrid Cloud Gatewayエージェントが過負荷になっていることを示す兆候は何ですか。

現在のところ、利用できる統計はありません。Hybrid Cloud Gatewayエージェントの負荷を評価するためにはEM診断キットのようなユーティリティを継続的に使用してください。

17.14.8 高可用性を得るために複数のHybrid Cloud Gatewayエージェントを構成した状態で、Hybrid Cloud Gatewayエージェントのうち1つにパッチを適用したところ、モニタリングが他のHybrid Cloud Gatewayエージェントに切り替わりました。最初のHybrid Cloud Gatewayエージェントをパッチ適用後に起動すれば、Hybrid Cloudエージェントをモニターするようになるのでしょうか。

いいえ。プライマリHybrid Cloud Gatewayエージェントが切り替わるのは、プライマリHybrid Cloud Gatewayエージェントが停止したときのみです。

Hybrid Cloudエージェントを指定して関連付けられているHybrid Cloud Gatewayエージェントの一覧を表示するには、次の問合せを実行します。

SELECT emd_url FROM MGMT_TARGETS

WHERE target_name LIKE '%PAAS_AGENT_NAME%' AND

target_type='oracle_hybridcloud_connection'

17.14.9 Hybrid CloudエージェントおよびOracle Cloudのターゲットでのユーザーに対する制限は何ですか。

そのような形での制限はありません。Hybrid Cloudエージェントのインストール・ユーザーがOracle Cloudターゲットのインストール・ユーザーと異なっても構いません。しかし、両者は同じプライマリ・オペレーティング・システム・グループに属している必要があります。そうなっていないと、検出は失敗します。

たとえば、Hybrid Cloudエージェントのインストール・ユーザーがopcで、Oracle Cloudターゲットのインストール・ユーザーがoracleであることは可能です。しかし、どちらのユーザーもoinstallという同じオペレーティング・システムに属している必要があります。

さらに、ユーザーにはsudoアクセス権が必要です。そうでない場合、エージェントのデプロイの際、手順の1つとしてroot.shスクリプトを手動で実行する必要があります。

17.14.10 どんなオペレーティング・システムにHybrid CloudエージェントおよびHybrid Cloud Gatewayエージェントをデプロイできますか。

Hybrid Cloud Gatewayエージェントはどのオペレーティング・システムでデプロイできますが、Hybrid CloudエージェントはOracle Linux x86-64オペレーティング・システム上にのみデプロイしてください。

18 Hybrid CloudへのJVMDのデプロイ

この章では、Hybrid Cloud環境でのJava Virtual Machine Diagnostics (JVMD)エージェントのデプロイ方法について説明します。内容は次のとおりです。

- Hybrid CloudへのJVMDデプロイの概要

- Oracle Cloud仮想ホストにJVMDエージェントをデプロイするための前提条件

- Oracle Cloud仮想ホストへのJVMDエージェントのデプロイ

- Hybrid Cloud Gatewayエージェントに対するデフォルトJVMDエンド・ポイントの変更

- Oracle Cloud仮想ホストへのJVMDエージェントのデプロイ終了後

18.1 Hybrid CloudへのJVMDデプロイの概要

Enterprise Manager Cloud Controlでは、Hybrid Cloud Managementにより、オンプレミスのEnterprise Manager Cloud Controlインスタンスで特定のOracle Cloudターゲットをモニタリングできます。この機能により、Enterprise Manager Cloud ControlではOracle Cloud仮想ホストにJVMDエージェントをデプロイして、オンプレミスにデプロイされているJVMDエンジンにレポートできます。これにより、オンプレミスCloud Controlインスタンスを使用し、Oracle Cloud JVMターゲットのモニターおよびOracle CloudにデプロイされたJavaアプリケーションのパフォーマンス問題の診断を行うことができます。

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

Oracle Cloud仮想ホストにデプロイされたJVMDエージェントとオンプレミスJVMDエンジンとの間の通信は、Hybrid Cloud GatewayプロキシおよびHybrid Cloud Gatewayエージェントを経由して行われます。JVMDエージェントからの通信は、Hybrid Cloud GatewayプロキシによってオンプレミスHybrid Cloud Gatewayエージェントへ転送され、さらに今度はそのGatewayエージェントによってJVMDエンジンへと転送され、またJVMDエンジンからのメッセージはJVMDエージェントへと返されます。逆向きの通信も同じ経路をたどります。つまり、JVMDエンジンからの通信は、Hybrid Cloud GatewayエージェントによってHybrid Cloud Gatewayプロキシへ転送され、今度はそのGatewayプロキシによってJVMDエージェントへと転送されます。

なお、クロス層機能を除きJVMDのすべての機能がHybrid Cloud環境でサポートされています。

18.2 Oracle Cloud仮想ホストにJVMDエージェントをデプロイするための前提条件

JVMDエージェントをOracle Cloud仮想ホストにデプロイする前に、次の前提条件を満たしていることを確認してください。

- JVMDエージェントをデプロイしようとしているOracle Cloud仮想ホスト上にHybrid Cloudエージェントをデプロイします。
Oracle Cloudターゲット上にHybrid Cloudエージェントをデプロイする方法は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- オンプレミスJVMDエージェントをデプロイするための前提条件を満たします。前提条件については『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されています。

18.3 Oracle Cloud仮想ホストへのJVMDエージェントのデプロイ

Oracle Cloud仮想ホスト上にJVMDエージェントをデプロイするには、次の手順に従います。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. アプリケーション・パフォーマンス管理ページの「アプリケーション・パフォーマンス管理エージェント」セクションで、「診断エージェントの管理」をクリックします。

3. 「操作」で、「デプロイ」が選択されていることを確認します。
「表示」メニューから「すべてを開く」を選択すると、検出されたすべてのWebLogic管理サーバーおよび管理対象サーバー(検出されたすべてのWebLogicドメインの一部)のターゲット名、ターゲット・タイプ、ターゲット・ホスト、ターゲット・ステータス、プラットフォームなどを参照できます。

JVMDエージェントのデプロイ先となる、WebLogic管理対象サーバーを選択します。「次へ」をクリックします。

4. ターゲットの資格証明ページで、WebLogicドメインごとに「Oracle WebLogic管理サーバー・ホストの資格証明」および「Oracle WebLogicドメインの資格証明」の値を指定し、「適用」をクリックします。
「次へ」をクリックします。

5. Oracle Cloud仮想ホストにJVMDエージェントをデプロイするために、「ハイブリッド・モードの構成」を選択し、Hybrid Cloud Gatewayプロキシとして使用するホストとポートを指定します。「ハイブリッド・モードの構成」を選択すると、使用可能なJVMDエンジンの値は自動的に「その他」に設定されます。なぜなら、JVMDエージェントはHybrid Cloud Gatewayプロキシに接続され、さらにこのGatewayプロキシがHybrid Cloud Gatewayエージェントを経由してJVMDエンジンに接続されるからです。
デフォルトでは、Oracle Cloud仮想ホストにデプロイされたすべてのJVMDエージェントからのレポートは事実上、デフォルト・エンド・ポイントとしてマークされたJVMDエンジンへ送られます。

エンタープライズ内にデプロイされているHybrid Cloud Gatewayエージェントすべてに対するデフォルトのJVMDエンドポイントを表示するには、「アプリケーション・パフォーマンス管理」ページで、「JVM診断エンジン」を選択し、続いて「構成」をクリックします。「ハイブリッド・ゲートウェイの構成」タブを選択します。デフォルトのJVMDエンド・ポイントが表示されます。エンタープライズ内にデプロイされているHybrid Cloud Gatewayエージェントに対するデフォルトのJVMDエンド・ポイントを変更する方法は、第18.4項を参照してください。

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

6. 確認ページですべての情報を確認し、「デプロイ」をクリックします。
JVMDエージェントのデプロイメントが正常に終了したら、「アプリケーション・パフォーマンス管理」ページに移動して「アプリケーション・パフォーマンス管理エージェント」セクションを表示することで、そのデプロイメントを確認できます。

18.4 Hybrid Cloud Gatewayエージェントに対するデフォルトJVMDエンド・ポイントの変更

デプロイされたHybrid Cloud JVMDエージェントとオンプレミスJVMDエンジンとの間の通信には、Hybrid Cloud Gatewayエージェントが使用されます。デフォルトで13c OMSでデプロイされたJVMDエンジンが、エンタープライズ内にデプロイされているHybrid Cloud Gatewayエージェントすべてに対するデフォルトのエンド・ポイントとしてマークされます。つまり事実上、デプロイされたHybrid Cloud JVMDエージェントからのレポートはデフォルト・エンド・ポイントとしてマークされたJVMDエンジンへ送られます。デフォルト・エンド・ポイントを他のJVMDエンジン、またはエンタープライズ内に構成されているロード・バランサに変更するには、次の手順に従います。

1. 「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。

2. 「JVM診断エンジン」を選択し、「構成」をクリックします。

3. 「ハイブリッド・ゲートウェイの構成」タブを選択します。「JVMDデフォルト・エンド・ポイントURL」に対して表示されている編集アイコンをクリックします。

4. デフォルト・エンド・ポイントを、使用する環境内に構成されているロード・バランサに変更する場合は、「ロード・バランサURL」を選択し、必要な値を指定します。他の(デフォルト・エンド・ポイント以外の)JVMDエンジンをデフォルト・エンド・ポイントに設定する場合は、「JVMDエンジン」を選択し、ドロップダウン・リストから目的のJVMDエンジンを選択します。

注意:
通常は、エンタープライズ内にデプロイされるHybrid Cloud GatewayエージェントはすべてJVMDに対応するよう構成され、デフォルトのJVMDエンド・ポイントと関連付けられます。デフォルトのJVMDエンド・ポイントと関連付けられていないHybrid Cloud Gatewayエージェントがある場合には、デフォルト・エンド・ポイントを「ハイブリッド・ゲートウェイ」セクションに表示されるリストから選択し、「更新」をクリックします。

18.5 Oracle Cloud仮想ホストへのJVMDエージェントのデプロイ終了後

Oracle Cloud仮想ホストへのJVMDエージェントのデプロイ終了後に、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の説明に従ってデプロイを検証してください。

第IV部

Cloud Controlの管理

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

- Enterprise Managerの管理

- 管理リポジトリのメンテナンスおよびトラブルシューティング

- Cloud Controlの更新

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

- プラグインの管理

- Oracle Management Serviceとリポジトリへのパッチ適用

- Oracle Management Agentへのパッチ適用

- Cloud Controlのパーソナライズ

- EMCTLコマンドを使用したEnterprise Managerの管理

- Enterprise Managerのログ・ファイルの検索および構成

- サービスの構成および使用

- Enterprise ManagerのSNMPサポートの概要

19 Enterprise Managerの管理

Enterprise Managerは様々なOracle製品とOracle以外の製品に対して、幅広い監視機能と管理機能を提供します。Enterprise Managerは異機種間ITインフラストラクチャの管理に使用され、ITリソースの状態の監視および管理に不可欠な役割を果します。そのため、Enterprise Manager自体も最高効率で動作している必要があります。

Enterprise Managerインストールの管理のために、Enterprise Managerコンソールから各種の高度な自己監視および診断機能を使用できます。これらの機能は、Enterprise Mangerの様々なコンポーネントの理解および監視、Enterprise Mangerで提供されるサービスの品質の監視/測定、失敗の迅速な診断、およびエージェントの容易な管理を支援するために設計されています。

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

- 概要: Managerの管理

- 状態の概要

- リポジトリ

- 管理エージェントの制御と構成

- 管理サーバー

19.1 概要: Managerの管理

Enterprise ManagerはITインフラストラクチャを管理する単一のエンティティとして機能しますが、実際には複数のコンポーネントで成り立っており、これらが連携して機能的な見地から完全な管理フレームワークを提供しています。Enterprise Managerの主要コンポーネントはすべて、1つのシステムにまとめられています。Enterprise Managerの機能をモデル化するために、一連の特別なサービスが作成されています(システムに基づいて)。

管理機能

- Enterprise Managerのすべての主要コンポーネントとその現在のステータスを確認できる、トポロジ・ビュー。

- Enterprise Managerの全体的な状態を表示するダッシュボード。

- Enterprise Managerコンソールからの、エージェントの直接かつ完全な制御。次の機能があります。

- エージェント構成プロパティの表示/編集。

- エージェント構成履歴の表示、および他のエージェントとの結果の比較。

- エージェント制御操作の実行(起動/停止/保護)。

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

19.2 状態の概要

「状態の概要」には、OMSおよびリポジトリおよびパフォーマンスの包括的な概要が示され、それによりEnteprise Manager環境の全体的な状態を表示することができます。

「状態の概要」へのアクセス

「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。

Enterprise Managerの主要な領域がすべて表示されます。

- 概要: 管理エージェント、Weblogic管理サーバー、「監視ターゲットの合計数」、「管理者数」、およびサーバー・ロード・バランサ(SLB)のアップロードおよびコンソールURL(SLBが構成されている場合)などのアクティブな管理サービスの主要な情報が示されます。構成されると、SLBアップロードおよびコンソールURLも表示されます。

- リポジトリの詳細: 管理リポジトリおよびデータベースが配置されているホストについての物理情報を表示します。データベースのホームページで詳細な情報にドリルダウンして、管理操作を実行できます。

- ジョブ・システム・ステータス: Enterprise Managerジョブ・サービスの主要な操作パラメータを表示します。詳細な情報が必要な場合は、ステータス・アイコンをクリックするとEnterprise Managerジョブ・サービスのホームページにドリルダウンできます。

- コンソール・アクティビティ: 分当たりの平均リクエスト数およびそのリクエストの処理に必要な平均時間により、Enterprise Managerコンソールに全体的な負荷を表示します。

- アラート: 記録されたメトリック・エラーおよびアラートがトリガーされた時期の詳細を表示します。インシデント・マネージャへのコンテキスト内リンクも表示されます。

- パフォーマンス・チャート: 「アップロード速度およびアップロード・バックログ」、「バックオフ・リクエスト」、「通知バックログ」。任意のチャートにドリルダウンして、詳細なメトリック情報を表示できます。

このページから、「OMSとリポジトリ」メニューを使用して、すべての監視および管理操作を実行できます。

注意:
診断メトリック・ページは、OMSを使用して問題を診断しているときにOracleサポートにより使用されることを目的としています。このページは、「OMSとリポジトリ」メニューから「監視」、「診断メトリック」の順に選択することでアクセスできます。

19.2.1 Enterprise Managerのトポロジとチャートの表示

Enterprise Managerのトポロジ・ページには、Enterprise Managerインフラストラクチャ・コンポーネントとそれらのアソシエーションがグラフィカルに表示されます。階層の各ノードには、メンバー・タイプ、配置されているホスト、インシデント数(ある場合)についての重要情報が表示されます。各ノードのインシデント・アイコンが開いて、階層内の各ノードの現行ステータスのグローバル・ビューが表示されます。

注意:
Enterprise Managerリポジトリ・データベースをトポロジ・ページに表示するには、まずデータベースを手動で検出する必要があります。データベースのメトリック・データ(データベース時間(センチ秒))をチャートに表示するためにも、手動による検出が必要です。

Enterprise Managerトポロジへのアクセス

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」を選択します。

2. 「OMSとリポジトリ」メニューでクリックし、このページから実行できる使用可能な操作を表示します。

3. 「メンバー」、「トポロジ」の順に選択します。

Enterprise Managerのチャート

Enterprise Managerのチャート・ページには、Enterprise Managerの全体的な状態を示す主要領域を表す8つのチャートが表示されます。これらは、「ロードを保留中の全ファイル - エージェント」、「ジョブ・ステップ・バックログ」、「ジョブ・ステップ・スループット(/秒)」、「リクエスト処理時間(ミリ秒)」、「データベース時間(センチ秒)」、「CPU使用率 %」、「ページインされたページ/秒」、「ページアウトしたページ/秒」です。過去24時間、過去7日間または過去31日間のデータを表示できます。

Enterprise Managerのチャートへのアクセス

1. 「設定」メニューから、「Cloud Controlの管理」、「状態の概要」の順に選択します。

2. 「OMSとリポジトリ」メニューでクリックし、このページから実行できる使用可能な操作を表示します。

3. 「監視」、「チャート」の順に選択します。

19.2.2 Enterprise Managerのページ・パフォーマンスの確認

ページ・パフォーマンス監視と診断機能を使用すると、Oracleサポートに連絡することなく、Enterprise Managerページのパフォーマンス問題を特定して診断できます。

重要:
Enterprise Managerページ・パフォーマンス・トレース機能には、エージェント・バージョン12.1.0.4以上が必要です。
「管理サービスとリポジトリ」ターゲットを監視しているエージェントのバージョンが12.1.0.4以上の場合にのみ、このページのチャートと表にデータが表示されます。Enterprise Manager 12.1.0.4にアップグレードした場合、「管理サービスとリポジトリ」ターゲットおよび関連するターゲットの最新監視機能にアクセスするために、管理サービス(OMS)マシンのエージェントも12.1.0.4にアップグレードする必要があります。

エージェントのアップグレードの詳細は、『Oracle® Enterprise Manager Cloud Controlアップグレード・ガイド』を参照してください。

ページ・パフォーマンス監視と診断機能にアクセスするには、次の手順を実行します。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「状態の概要」または「リポジトリ」を選択します。

2. 「OMSとリポジトリ」メニューから、「監視」を選択し、「ページ・パフォーマンス」を選択します。ページ・パフォーマンス・ページが表示されます。

概要

「概要」タブは、Enterprise Managerの全体的なページ・パフォーマンスの詳細を示します。

チャートには、ページ・アクセスおよびセッション、現在のページ・アクセスおよびセッションのOMSでの分散、および過去24時間のページ・パフォーマンスの全体統計が表示されます。各OMSのページ・パフォーマンスの詳細および使用可能なリポジトリの詳細があります。

「全体統計」表は、リポジトリ、OMS、ネットワークに費やされた時間の内訳、ページ・アクセス数、過去24時間のページ別の最大所要時間を示します。

ページ・レベル・パフォーマンス

「ページ・レベル・パフォーマンス」タブは、過去24時間にアクセスされたページのリストを示します。

このページは、リポジトリとOMSとネットワークに費やされた時間の内訳も、ページごとに線グラフで表示します。

パフォーマンス関係付け

「パフォーマンス関係付け」タブは、パフォーマンスの傾向を関係付けることができるページ・パフォーマンスのグラフを表示します。

このタブは、ページ・アクセスおよびセッション、ページ処理時間、SQL/PLSQL実行および平均アクティブ・セッションの詳細を示します。

症状診断

症状診断は、全体的な処理時間と個々のページの時間の両方に対して実行できます。症状診断は、全体的なページ処理時間の設定メトリックしきい値を超えた場合にトリガーされます。診断は、全体的なページ・パフォーマンスのしきい値を超えた場合に「全体統計」セクションの「概要」タブのアイコンを使用してアクセスされます。

個々のページでは、ページ・パフォーマンスのメトリックしきい値を超えた場合に、表の「現在の重大度」列に症状診断アイコンが表示されます。

アイコンが「全体統計」セクションに表示された場合、これはEnterprise Managerページの全体的なパフォーマンスが過去10分間に、しきい値を超えたことを示します。アイコンをクリックすると、診断の詳細が示されている別のタブが表示されます。診断は、全体的なページ・パフォーマンスがメトリックしきい値を超えた根本原因、診断により推定された結果、および全体的なページ・パフォーマンス問題を分析するために実行されたチェックを示します。

チェックは、データベース・レベル、中間層レベルおよびブラウザ/ネットワーク・レベルで実行され、システムのどの部分が問題の原因であるかを特定します。各チェックが分析され、上位の原因として識別されたチェックは、結果として報告されます。その後、最上位の結果はパフォーマンス問題の根本原因として報告されます。

ターゲット可用性症状診断:

症状診断は、エージェントの可用性に対しても実行できます。エージェント・ターゲットが使用不可または保留中である場合、アイコンがエージェント・リスト・ページおよびエージェント・ホームページに表示されます。

アイコンをクリックすると、診断の詳細が示されている別のタブが表示されます。診断は、エージェントが使用不可/保留状態になった根本原因、診断から推定された結果、およびエージェントの可用性問題を分析するために実行されたチェックを示します。

問題を診断するために実行されるチェックは、次の内容で構成されます。

- 管理サービスとエージェント間の通信が成功しているかどうか

- エージェントが管理サービスと通信したかどうか

- 原因がリポジトリから推定できるかどうか

- エージェント側からチェックを実行することで、さらなる原因が推定できるかどうか(OMSとエージェント間の通信が存在するかどうか)

各チェックが分析され、上位の原因として識別されたチェックは、結果として報告されます。その後、最上位の結果はパフォーマンス問題の根本原因として報告されます。

図19-1 エージェントの症状診断

注意:
OMSとエージェント間の通信を確立できない場合、診断は、管理リポジトリで利用可能なデータに基づく結果を報告しますが、これは問題の実際の原因ではないことがあります。

症状診断機能は、ステータス・アイコンをクリックすることで、使用不可または保留中であるターゲットの・すべてのターゲット・ページでも使用できます。

19.3 リポジトリ

リポジトリ・ページでは、Enterprise Managerのメンテナンスおよび監視機能の一部を処理するリポジトリDBMSのジョブについてのステータスおよびパフォーマンスの概要がわかります。これらのDBMSのジョブは管理リポジトリ内で実行されるため、ユーザーの入力を必要としません。「リポジトリの詳細」とリポジトリ収集のバックログを示すチャートが表示されます。「スケジューラのステータス」領域には、スケジューラのステータスとジョブ・キュー・プロセス数が示されます。

リポジトリ情報へのアクセス

「設定」メニューから、「Cloud Controlの管理」を選択し、「リポジトリ」を選択します。

3つのタブが表示され、リポジトリ属性の包括的なビュー、パフォーマンス、および前提条件の操作パラメータへのアクセスが提供されます。

- 「リポジトリ」タブ

- 「メトリック」タブ

- 「スキーマ」タブ

19.3.1 「リポジトリ」タブ

「リポジトリ」タブは、リポジトリ固有の監視の包括的なスナップショットを示します。

リポジトリの詳細

「リポジトリの詳細」領域は、Enterprise Managerリポジトリの高レベルのデータベース情報を示します。この領域から、「管理サービスのリポジトリ・セッション」の詳細の数をクリックし、イベント・システム、コンソール、ジョブ・システム、またはコネクタ・フレームワークなどの、個別のEnterprise Managerサブコンポーネントごとの、リポジトリ接続の正確な数を表示できます。

図19-2 サブコンポーネントごとのリポジトリ・セッション

インシデントと問題

「インシデントと問題」領域は、リポジトリ・データベースに関連するすべてのインシデントと問題を表示します。インシデントまたは問題の詳細については、「サマリー」リンクをクリックして、インシデント・マネージャの問題にアクセスできます。

図19-3 インシデント/問題の情報へのアクセス

インスタンスの初期化パラメータ・コンプライアンス

この領域は、現在の初期化パラメータ設定、推奨標準、および現在のパラメータ値がこれらの標準値に準拠しているかどうかを表示します。

図19-4 初期化パラメータ・コンプライアンス

RAC環境でリポジトリを実行している場合、この領域で、特定のインスタンスの初期化パラメータ・コンプライアンスを表示するために個々のデータベース・インスタンスを選択することもできます。

リポジトリ・スケジューラ・ジョブ・ステータス

「リポジトリ・スケジューラ・ジョブ・ステータス」領域には、ステータス、期間、次のスケジュール実行時間など、DBMSジョブの詳細が表示されます。

図19-5 「リポジトリ・スケジューラ・ジョブ・ステータス」領域

ジョブの「ステータス」が停止している場合、「ジョブの再起動」をクリックして、ジョブを再度実行できます。

実行時にリポジトリ・パフォーマンスを低下させる可能性がある、より多くのリソースを必要とする高コストのジョブの場合、編集アイコン(鉛筆)が「編集」列に表示されます。アイコンをクリックすると、次の実行時間を再スケジュールできるダイアログが表示されます。

図19-6 ジョブの再スケジュール・ダイアログ

リポジトリ収集パフォーマンス

「リポジトリ収集パフォーマンス」領域は、リポジトリ収集のパフォーマンスに関する情報を示します。各データは、収集ワーカーと呼ばれるリポジトリ・データベース内のバックグラウンドDBMSジョブによって収集されます。

図19-7 「リポジトリ収集パフォーマンス」領域

リポジトリのメトリックは、長期実行と短期実行のメトリックに分類されます。これらはタスク・クラス(短期タスク・クラスと長期タスク・クラス)と呼ばれます。いくつかの収集ワーカーは短期タスク・クラスを処理し、別のいくつかの収集ワーカーは長期タスク・クラスを処理します。「リポジトリ収集パフォーマンス」メトリックは、各タスク・クラスのリポジトリ・メトリック収集のパフォーマンス・データを測定します。このメトリックは、リポジトリ・メトリックの1つであるため、収集ワーカーによって収集されます。

短時間実行収集ワーカーと長時間実行収集ワーカーの間で選択できます。短時間実行ワーカーを表示する場合、「構成」をクリックして短時間ワーカー設定を変更できます。

図19-8 短時間ワーカー構成ダイアログ

「保存」をクリックすると、ワーカー構成を変更するためにジョブを発行します。このため、変更は即時に行われるのではなく、有効になるには1分ほどかかることがあります。

凡例の項目をクリックすると、問題の分析、メトリック詳細またはターゲット・ホームにドリルダウンできます。

図19-9 収集パフォーマンス情報

メトリック・データ・ロールアップ・パフォーマンス

この領域は、ロールアップされているデータの量(ロールアップされたレコード数)と一定期間の速度(スループット/分)をグラフィック表示することでロールアップ・パフォーマンスを示します。

図19-10 「メトリック・データ・ロールアップ・パフォーマンス」領域

「ロールアップされたレコード数」および「スループット/分」のグラフは、さらにターゲットが追加されると、時間の経過とともに増加を示すことがありますが、日次ベースでは、かなりのレベルのままであるはずです。大きい急上昇は、エージェントがOMSに対して適切に通信していないことを示す場合があります。

「構成」をクリックすると、起動するロールアップアップ・ワーカー・スレッドの数を変更できます。

19.3.2 「メトリック」タブ

「メトリック」タブでは、主なリポジトリ・パフォーマンス測定値をグラフィカルにロールアップできます。内容は次のとおりです。

- 過去30日間の上位25位のメトリック・データ・ロード・ターゲット・タイプ

- 過去30日間の上位10位のデータ・ロード・メトリック

- 過去30日間のメトリック・アラート/日

- 過去30日間の上位10個のメトリック収集エラー

グラフでは、ドリルダウンして、より詳細な情報にアクセスできます。

過去30日間の上位25位のメトリック・データ・ロード・ターゲット・タイプ

図19-11 過去30日間の上位25位のメトリック・データ・ロード・ターゲット・タイプ

特定のターゲット・タイプのメトリックのみを表示する場合、グラフ内の特定のメトリック・ターゲット・タイプ領域をクリックします。新しいグラフで、その特定のターゲット・タイプのメトリックのみが表示されます。メトリックまたはターゲット別に結果をグループ化することもできます。

図19-12 単一ターゲット・タイプの上位25位のメトリック・データ・ロード

すべてのターゲット・タイプを含む元のグラフに戻るには、「クリア」をクリックします。

過去30日間の上位10位のデータ・ロード・メトリック

図19-13 メトリック・データ・ロード量

過去30日間の上位10個のメトリック収集エラー

図19-14

過去30日間のメトリック・アラート/日

「過去30日間のメトリック・アラート/日」は、一定期間のオープン、クローズ、バックログのメトリック・アラートの数をグラフィカルに表示します。期間を絞り込む場合は、「ズーム」をクリックします。

図19-15 メトリック・アラート/日

19.3.3 「スキーマ」タブ

「スキーマ」タブは、リポジトリ・データベース・スキーマに関する物理属性およびパフォーマンス・データを示します。内容は次のとおりです。

- 表領域増加率
特定の表領域MGMT_TABLESPACE, MGMT_ECM_DEPOT_TS、またはMGMT_AD4J_TSを選択できます。大きい表/索引の上位20個も表示されます。

- リポジトリの未使用の領域を含む上位20個の表

- ポリシーのパージ

- パーティション保存

19.4 管理エージェントの制御と構成

Enterprise Manager Cloud Control 12cより、管理エージェントの制御をEnterprise Managerコンソールから直接実行できます。これにより、監視環境内のすべての管理エージェントを一元的に比較、構成および制御できます。

19.4.1 Cloud Controlエージェントの管理ページ

エージェント・ページには、監視環境内のすべての管理エージェントが示されます。このページには、構成ミスのあるエージェント、ブロックされたエージェント、アップグレード可能なエージェントと不可能なエージェントの両方も含まれています。

エージェント・ページへのアクセス

「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。

構成ミスのあるエージェントおよびブロックされたエージェント

構成ミスのあるエージェントとは、構成またはデータが無効であるため、ハートビートの実行やOracle Management Service (OMS)へのデータのアップロードが不可能なエージェントです。エージェントの構成ミス・アラートは、次のメトリックによってトリガーされます。

- 連続したメタデータ・アップロード失敗数

- 連続したping失敗数

- 連続した重要度アップロード失敗数

- OMSエージェントの時間誤差

エージェント・ハートビートまたはアップロード・リクエストが連続して失敗し、問題を適時に解決できない場合は、エージェントを手動でブロックして、OMSが過負荷にならないようにすることができます。エージェントをブロックすると、OMSはブロックされた管理エージェントからのすべてのハートビートまたはアップロード・リクエストを拒否します。しかし、ブロックされたエージェントが監視データの収集を続行しても、アラートまたはメトリック・データはOMSにアップロードできません。エージェントの構成の問題が解決したら、手動でエージェントのブロックを解除して、通常の操作を再開します。

注意:
エージェントのブロックを解除する前に、エージェントの構成ミスに関するすべての問題が解決されていることを確認してください。

このページから、エージェントのアップグレード・プロセスを開始することもできます。エージェントのアップグレードの詳細は、「複数の管理エージェントのアップグレード」を参照してください。

19.4.2 エージェント・ホームページ

「エージェント」ホームページには、1つのエージェントの詳細が表示されます。このページでは、詳細情報にドリルダウンすることもできます。エージェント・ホームページにアクセスするには、エージェント・リスト・ページから目的のエージェントをクリックするか、すべてのターゲット・ページからこのページを選択します。

- 「サマリー」領域には、ステータスや可用性など、エージェントの主要情報の詳細が表示されます。「管理サービスとの相互作用」領域には、OMSとエージェント、メトリック拡張、エージェントにデプロイされた管理プラグイン間の通信の詳細が表示されます。

- 「ステータス」領域には、再起動の回数、エージェントが現在実行しているアクションなど、エージェントのステータスの詳細が表示されます。

- 「パフォーマンス」、「使用状況」および「リソース使用量」の各チャートには、エージェントの詳細がグラフィック形式で表示されます。

- 「インシデント」領域には、エージェントに記録されたインシデントが一覧表示されます。

- 「監視」領域には、エージェントに監視されているターゲットの詳細が表示されます。この領域のターゲットを、「すべて」、「破損」、「アップロードしていません」でフィルタできます。「監視」セクション内の個別のタブには、「メトリックの問題」および「上位の収集」が表示されます。

19.4.3 単一エージェントの制御

単一エージェントの制御操作は、そのエージェントの「エージェント」ホームページで実行できます。

1. 目的の「エージェント」ホームページに移動します。

2. 「エージェント」ドロップダウン・メニューから「制御」を選択してから、いずれかの制御操作(起動/停止または再起動)を選択します。

注意:
エージェントの制御操作を実行するには、少なくともオペレータ権限を持っている必要があります。

前述の制御メニュー・オプションを選択する際、ユーザーの資格証明をリクエストするポップアップ・ダイアログが表示されます。これらの操作には、エージェントを所有するOSユーザーの資格証明、またはエージェント所有者のSUDOまたはPowerBroker権限を持つユーザーの資格証明が必要です。この時点で、以前に保存済のユーザー名/パスワード、優先または名前付き資格証明から選択できます。新しい資格証明のセットを選択して、それを将来使用するために優先資格証明または名前付き資格証明として保存することもできます。

認証されると、選択した制御操作が開始され、ポップアップ・ダイアログを閉じた後も続行されます。ポップアップ・ダイアログに、タスクの失敗/成功のメッセージが表示されます。

「セキュア」/「再保護」/「非保護」の各オプションを選択する場合は、必要な登録パスワードを入力する必要があります。

サーバー・ロード・バランサを使用したときのエージェントの制御

サーバー・ロード・バランサ(SLB)を使用したマルチOMS環境でエージェントの保護/再保護オプションを選択すると、エージェントは管理者の介入なしに自動的にSLBに対して保護/再保護されます。

19.4.4 単一管理エージェントの構成

単一エージェントの構成操作は、「エージェント」ホームページから実行できます。「エージェント」ページにアクセスする手順:

1. 目的の「エージェント」ホームページに移動します。

2. 「エージェント」ドロップダウン・メニューから「プロパティ」を選択します。

注意:
エージェントの構成操作を実行するには、少なくとも構成権限を持っている必要があります。

図19-16 エージェントの「プロパティ」ページ

このページのプロパティをフィルタ処理して、「すべてのプロパティ」、「基本プロパティ」または「拡張プロパティ」を表示できます。「基本プロパティ」は、プロパティとその値の簡易な名前と値の組合せです。「拡張プロパティ」も名前と値の組合せですが、カテゴリにまとめることもできます。既存のプロパティを変更してカスタム・プロパティを設定するには、少なくとも構成権限を持っている必要があります。

19.4.5 複数管理エージェントの制御

複数の管理エージェントの制御操作を実行するために、Enterprise Managerではジョブ・システムを使用して繰返しタスクを自動化しています。このため、複数の管理エージェントを単一のアクションで制御するジョブ権限を持っている必要があります。アクセスする手順:

1. 「設定」メニューから、「Cloud Controlの管理」、「エージェント」の順に選択します。エージェント・ページが表示されます。

2. リストから複数の管理エージェントを選択します。

3. いずれかの制御操作ボタン(「起動」/「停止」/「再起動」/「セキュア」/「再保護」/「非保護」)をクリックします。

いずれかの制御操作をクリックすると、ジョブ作成ウィザードが表示されます。このウィザードで新規ジョブをスケジュールして、選択したエージェントに対してアクションを実行できます。

ジョブ・ページでは、「一般」タブの「ターゲット」セクションで、選択した管理エージェントを表示できます。「追加」ボタンをクリックして、管理エージェントを追加できます。必要に応じて、「パラメータ」タブで操作のパラメータを指定します。「資格証明」タブでは資格証明を指定する必要があり、以前に保存済のユーザー名/パスワード、優先または名前付き資格証明から選択できます。新しい資格証明のセットを選択して、それを将来使用するために優先資格証明または名前付き資格証明として保存することもできます。ジョブをただちに開始することも、後で実行するようジョブをスケジュールすることもできます。この時点で、ジョブの開始時間、頻度、終了時間を指定して、繰返しジョブを作成することもできます。

「アクセス」タブには、管理者の詳細およびジョブに対して持っているアクセス・レベルが表示されます。必要な権限を持っている場合は、新しい管理者を追加したり、アクセス・レベルを「表示」または「完全」に変更できます。

注意:
十分な権限がない管理者でも、これらの制御操作のジョブをスケジュールできますが、その場合、ジョブは正常に完了しません。

19.4.6 複数のエージェントの制御

複数エージェントの制御操作と同様に、複数エージェントでも同じ方法でエージェント構成を実行できます。これにより、企業全体でのエージェント構成の標準化が非常に容易になります。エージェントのプロパティにアクセスする手順:

1. 「設定」メニューから、「Cloud Controlの管理」、「エージェント」の順に選択します。エージェント・ページが表示されます。

2. リストから複数の管理エージェントを選択します。

3. 「プロパティ」をクリックします。複数エージェント操作と同様に、構成はジョブ・システムを使用して実装されます。

図19-17 エージェントの「プロパティ」ページ

ジョブ・ページでは、「一般」タブの「ターゲット」セクションで、選択した管理エージェントを表示できます。必要に応じて、「追加」ボタンをクリックして管理エージェントを追加できます。「パラメータ」タブで、変更する特定のパラメータ・セットの変更値を入力します。選択したエージェントのカスタム・プロパティを設定することもできます。エージェントのプロパティの変更には、資格証明は必要ありません。

「アクセス」タブには、管理者の詳細およびジョブに対して持っているアクセス・レベルが表示されます。必要な権限を持っている場合は、新しい管理者を追加したり、アクセス・レベルを「表示」または「完全」に変更できます。

図19-18 複数エージェントの構成: ジョブ・アクセス

19.4.7 複数の管理エージェントのアップグレード

現在のEnterprise Manager Cloud Control 12cリリースにアップグレードする場合、ターゲットのOracle Management Agent (管理エージェント)ではなく、Oracle Management Service (OMS)を現在のリリースにアップグレードします。管理エージェントを一括アップグレードするには、エージェントのアップグレード・ページにアクセスします。このページにアクセスするには、次の手順を実行します。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」を選択します。

2. 「アップグレード可能」をクリックし、アップグレードする管理エージェントを選択します。

3. 「アップグレード」をクリックします。

または、エージェントのアップグレード・ページにアクセスするには、「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェントのアップグレード」を選択します。管理エージェントのアップグレードの詳細は、「Oracle Management Agentのアップグレード」を参照してください。

19.5 管理サーバー

管理サーバーは、複数のEnterprise Manager管理サービスで構成されるコンポジット・ターゲットです。.

管理サーバー・ページには、管理サービス、そのステータス、インシデント、ローダー・スループット、CPU使用率、およびJVMメモリー使用量メトリックのリストが表示されます。さらに、表示される管理サービスは、「標準モード」、コンソール限定、PBS限定、および「スタンバイ」管理サービスでフィルタできます。

管理サーバー・ページへのアクセス

「設定」メニューから、「Cloud Controlの管理」、「管理サービス」の順に選択します。

このページは、次のセクションで構成されます。

- サマリー: WebLogic管理サーバーおよびロード・バランサに関する高レベルの情報を表示します。

- ジョブ・システム: 過去の期間(過去30分間、1時間、2時間など)のジョブのステータスに関する情報を表示します。

- サーバー: 管理サーバーの個々の管理サービスに関する情報を表示します。

- ローダー: ローダー・サブシステム・パフォーマンス全体に関する洞察を表示します。
次のように主に3つのグラフがあります。

- スループット(秒ごとに処理された行): ローダーによるファイルの処理率(秒ごとに処理された行)を示します。

- 処理されたファイルとバックオフ: 処理されたファイルの数とローダーによるバックオフ(拒否)を示します。注意: 一貫性のあるバックオフが生成される場合は、Oracleサポートに連絡する必要があります。

- %使用容量: 現在のローダーCPU使用率を示します。ローダーが一貫して85%以上の容量で動作する場合は、Oracleサポートに連絡して、システム容量を増やす必要があるかどうかを確認してください。

ローダー統計の詳細なIPレポートを表示するには、グラフの下にある「ローダー統計」リンクをクリックします。

- インシデント: これは、管理サービスをホストする個々のターゲットに対して発生したインシデントと問題を表示します。

20 管理リポジトリのメンテナンスおよびトラブルシューティング

この項では、適切に実行する管理リポジトリを維持するためのメンテナンスおよびトラブルシューティングの技法について説明します。

この章では特に、次の項について説明します。

- 管理リポジトリのデプロイメント・ガイドライン

- 管理リポジトリのデータ保持ポリシー

- 管理リポジトリの削除および再作成

- 管理リポジトリの作成エラーのトラブルシューティング

- クロス・プラットフォームのEnterprise Managerリポジトリの移行

20.1 管理リポジトリのデプロイメント・ガイドライン

管理データがセキュアで信頼性があり、常に利用可能になるようにするには、管理リポジトリをデプロイする際に次の設定と構成のガイドラインを検討します。

- RAID対応論理ボリューム・マネージャ(Logical Volume Manager: LVM)またはハードウェアRAIDを、管理リポジトリが存在するシステムにインストールします。最低でもオペレーティング・システムでディスクのミラーリングとストリッピングをサポートする必要があります。管理リポジトリのすべてのデータ・ファイルをある程度の冗長構成で構成します。

- Real Application Clustersを使用して、管理リポジトリに最高レベルの可用性を提供します。

- Enterprise Managerを使用して、本番環境でのエラーや可用性の問題を管理者に知らせる場合、必ずCloud Controlコンポーネントを同じレベルの可用性で構成してください。最低でも、Oracle Data Guardを使用して管理リポジトリ・データベースをミラーリングすることを検討します。データ損失をゼロにするようにData Guardを構成します。使用環境やニーズに基づいて、最大可用性または最大保護を選択します。

関連項目:
Oracle Database高可用性のアーキテクチャおよびベスト・プラクティス
『Oracle Data Guard概要および管理』

- アーカイブ・ログを有効にして、本番環境でEnterprise Managerの実装を稼働する前に包括的なバックアップ戦略を整えることを強くお薦めします。バックアップ戦略には、必要に応じてアーカイブ・バックアップと、増分バックアップと全体バックアップの両方を含めてください。

関連項目:
管理リポジトリに必要なデータベース初期化パラメータの詳細は、Oracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイド

- オラクル社は、Enterprise Manager Cloud ControlリポジトリでSQL計画管理(SQL計画ベースラインおよび取得)を使用しないことをお薦めします。固有の問題のためにそれを使用する必要がある場合は、使用後すぐに停止してください。SQL計画管理を使用すると、未検証計画を使用したSQLパフォーマンスの大幅な低下や、SQL計画管理の取得とEnterprise ManagerセキュリティVPDの間のデッドロックなど、Enterprise Manager Cloud Controlリポジトリの問題が発生する可能性があります。

- リポジトリ・データベースと、ORAエラーに関する監査エントリの監査を有効化すると、Enterprise Managerアプリケーション・ログ(emoms.trc、MGMT_SYSTEM_ERROR_LOG表、リポジトリ・データベースのalert.logなど)にエラー・メッセージがレポートされない場合、これらは無視されます。
このような場合のエラーは無害です。

- リポジトリに対して実行する必要がある、通常のメンテナンス・アクティビティの一覧を表示するには、『Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の「Enterprise Managerデプロイメントのサイジング」を参照してください。

- Enterprise Managerのユーザー・インタフェースを使用してリポジトリ・データベースのアクティビティを監視するには、第19章「Enterprise Managerの管理」を参照してください。

20.2 管理リポジトリのデータ保持ポリシー

Enterprise Managerの各種コンポーネントを構成し、そのコンポーネントが効率的に実行している場合、Oracle Management Serviceは、管理対象ホストで実行している管理エージェントから大量のRAWデータを収集し、そのデータを管理リポジトリにロードします。このデータは、後でCloud Controlコンソールで集計、編成、表示されるRAW情報です。

Oracle Management Serviceが管理リポジトリに情報をロードすると、Enterprise Managerは時間の経過とともにデータを集約してパージします。

次の項で説明する内容です。

- 管理リポジトリでのデータのメンテナンスに使用される集計とパージのデフォルトのポリシー。

- データが集計されて管理リポジトリからパージされるまでのデータの保持時間の変更方法。

20.2.1 管理リポジトリの集計とパージのデフォルトのポリシー

Enterprise Managerは、時単位および日単位でメトリック・データを集計することで、問合せパフォーマンスを高めて管理リポジトリのサイズを最小限に抑えます。データを集計する前に、各データ・ポイントがRAWメトリック・データ表に保存されます。1日に1度、前日のRAWメトリック・データがロールアップまたは集計されて、1時間および1日単位の表にまとめられます。これらの毎時および日次レコードには、毎時および日次のメトリック・データの平均、最小、最大および標準偏差が含まれます。

Enterprise Managerがデータを集計すると、データはパージ対象とみなされます。データは一定の期間が経過してから実際にパージされます。この期間を保存時間と言います。

RAWデータの挿入量が最大の場合、デフォルトの保存時間は最短になり、7日に設定されます。その結果、データが1時間単位のレコードに集計されてから7日が経過すると、RAWデータ・ポイントがパージの対象となります。

注意:
このデータ保持ポリシーは、JVMDおよびADPデータでは異なります。

毎時集計されたメトリック・データ・レコードは、31日後にパージされます。最大レベルの集計(1日)は、12か月間保持されます(約365日)。

表20-1にデフォルトのデータ保持ポリシーをまとめています。

表20-1 デフォルトのリポジトリ・パージ・ポリシー

集計レベル

保存時間

Rawメトリック・データ

7日

毎時の集計メトリック・データ

31日

日次の集計メトリック・データ

24か月

アプリケーション・パフォーマンス管理を構成して有効にしている場合、Enterprise Managerはレスポンス時間データも収集、保存、集計、パージします。レスポンス時間データは、メトリック・データに使用されるものと同様のポリシーを使用してパージされます。表20-2にアプリケーション・パフォーマンス管理のパージ・ポリシーを示します。

表20-2 アプリケーション・パフォーマンス管理データのデフォルトのリポジトリ・パージ・ポリシー

集計レベル

保存時間

RAWレスポンス時間データ

24時間

1時間の集計レスポンス時間データ

7日

1時間の分散レスポンス時間データ

24時間

1日の集計レスポンス時間データ

31日

1日の分散集計レスポンス時間データ

31日

重大度データをデフォルトの期間(6か月)保存しない場合、およびEVENTSパージ・ポリシー用の保存期間を短縮する場合は、次のコマンドを使用します。

em_purge.modify_purge_policy_group('EVENTS',NULL,*l_new_purge_hours*);

このコマンドは、そのグループに関連付けられているすべてのパージ・ポリシーに影響を与えるパージ・ポリシー・グループのみを変更します。パージ・ポリシーがパージ・グループに関連付けられている場合、保存期間はグループの保存期間になります。パージ・ポリシー(パージ・ポリシー・グループに関連付けられている)の保存が変更された場合、保存はパージ・ポリシー・グループではなくパージ・ポリシーから決定されます。

個々のパージ・ポリシーを変更するには、次のコマンドを使用します。

em_purge.modify_purge_policy(
p_policy_name     IN VARCHAR2,
p_retention_hours IN NUMBER
)

「設定」メニューから「Cloud Controlの管理」、「リポジトリ」の順に選択して、パージ・ポリシーおよびパーティション保存値を変更できます。このページで「スキーマ」タブを選択し、「パージ・ポリシー」セクション(「変更」をクリック)または「パーティション保存」セクションで必要な変更を加えます。

デフォルトでは、イベント情報は分割されて6か月の履歴データが管理されます。前述の手順を使用して、デフォルトの保存期間を変更することができます。重大度データは、イベント・データのパージ・ポリシーに関連付けられ、適宜調整されます。

このデータのパージによって影響を受ける、修正された表は、次のように示されます。

EM_EVENT_SEQUENCES
EM_EVENT_RAW
EM_EVENT_MSGS
EM_EVENT_CONTEXT
EM_EVENT_ANNOTATIONS
EM_EVENTS_INCIDENT
EM_ISSUES_INTERNAL
EM_ISSUES_MSG
EM_ISSUES_ANNOTATIONS
EM_INCIDENT_ISSUE
EM_PROBLEM_ISSUE
EM_INCIDENTS_PROBLEM

次の一覧は、Enterprise Managerでサポートされる様々なイベント・タイプのデータを保存する表の動的なセットです。新しいイベント・タイプまたはサポートされないイベント・タイプが追加または削除されると、このリストは時間の経過に伴って変化します。

EM_EV_CS_RULE_VIOLATION
EM_EV_CS_SCORE
EM_EV_JOB_STATUS_CHANGE
EM_EV_METRIC_ALERT
EM_EV_METRIC_ERROR
EM_EV_MEXT_UPDATE
EM_EV_MNTR_DISRUPTION
EM_EV_SELFUPDATE
EM_EV_SLA_ALERT
EM_EV_TARGET_AVAILABILITY
EM_EV_USER_REPORTED
EM_EV_ADP_ALERT
EM_EV_APM_KPI_ALERT
EM_EV_JVMDIAG_ALERT
EM_EV_HA_EVENT

20.2.2 その他の管理データに関する管理リポジトリの集計およびパージのデフォルトのポリシー

メトリック・データとアプリケーション・パフォーマンス監視データ以外に、その他のタイプのEnterprise Managerデータが時間の経過とともに管理リポジトリに蓄積されます。

たとえば、ターゲットの最後の可用性レコードも管理リポジトリに無期限で残るため、ターゲットの最後の既知の状態が保存されます。

20.2.3 集計およびパージのデフォルトのポリシーの変更

Enterprise Managerの集計およびパージのデフォルトのポリシーは、管理リポジトリに対して最大パフォーマンスと最小ディスク領域の要件を実現し、分析に最も利用可能なデータを提供するように設計されました。そのため、パフォーマンスを改善したり、使用可能なディスク領域を増やしたりするためにこれらのポリシーを変更する必要はありません。

ただし、Enterprise Manager以外のデータ分析ツールを使用してRAWデータや集計データを抽出または確認する場合、管理リポジトリで使用可能なRAWデータや集計データの量を増やすことができます。これを行うには、RAWデータや集計データの保存時間を増やします。

Enterprise Managerリポジトリの中心的なメトリック・データ表のデフォルトの保持時間を変更するために、PL/SQL APIが提供されています。表20-3は、3つの表でそれぞれ保持されるデフォルトのパーティション数、および各表のパーティションのサイズを示しています。APIでは、保持されるパーティション数のみを変更できます。

表20-3 中心的なEMメトリック・データ表および管理リポジトリでのデフォルトのデータ保持

表名

保持されるパーティション

パーティション・サイズ

EM_METRIC _VALUES

7

日

EM_METRIC_VALUES_HOURLY

32

日

EM_METRIC_VALUES_DAILY

24

月

前述の表の保持期間を変更するには、次のコマンドを実行します。

SQL> execute gc_interval_partition_mgr.set_retention('SYSMAN', <table name>, <number of partitions to retain>);

<table name>を前述の表の名前に置き換えます。APIでは、保持されるパーティション数のみを変更できます。

たとえば、表EM_METRIC_VALUESのデフォルトの保持期間を7パーティションから14パーティションに変更するには、次の手順に従います。

1. SQL*Plusを使用してSYSMANユーザーとしてリポジトリ・データベースに接続します。

2. 保持期間の現在の値を確認します。

SQL> select table_name, partitions_retained
from em_int_partitioned_tables
where table_name in ('EM_METRIC_VALUES','EM_METRIC_VALUES_HOURLY','EM_METRIC_VALUES_DAILY');

TABLE_NAME                 PARTITIONS_RETAINED
-------------------------  -------------------
EM_METRIC_VALUES                             7
EM_METRIC_VALUES_HOURLY                     32
EM_METRIC_VALUES_DAILY                      24

3. 表EM_METRIC_VALUESのデフォルトの保持期間を7パーティションから14パーティションに変更するには、次のコマンドを実行します。
SQL> execute gc_interval_partition_mgr.set_retention('SYSMAN', 'EM_METRIC_VALUES', 14);

4. 保持期間が変更されたことを確認します。

SQL> select table_name, partitions_retained
from em_int_partitioned_tables
where table_name in ('EM_METRIC_VALUES','EM_METRIC_VALUES_HOURLY','EM_METRIC_VALUES_DAILY');

TABLE_NAME                PARTITIONS_RETAINED
------------------------- -------------------
EM_METRIC_VALUES                           14
EM_METRIC_VALUES_HOURLY                    32
EM_METRIC_VALUES_DAILY                     24

20.2.4 ジョブ履歴の保存時間の変更方法

Enterprise Manager Cloud Controlには、30日が経過した古い完了済ジョブの詳細をすべて削除するデフォルトのパージ・ポリシーがあります。この項では、このデフォルトのパージ・ポリシーの変更について詳しく説明します。

完了済ジョブ履歴の実際のパージは、リポジトリ・データベースで一日に1回実行されるDBMS_SCHEDULERジョブで実装されます。ジョブが実行されると、現在の時刻(リポジトリ・データベースのsysdateの値)よりも「n」日古い完了済ジョブを検索し、これらのジョブを削除します。値「n」はデフォルトでは30日に設定されています。

デフォルトのパージ・ポリシーはEnterprise Managerコンソールでは変更できませんが、SQL*Plusを使用して変更できます。

このパージ・ポリシーを変更するには、次の手順を実行します。

1. リポジトリ・データベースにSQL*Plus経由でSYSMANユーザーとしてログインします。

2. 次のコマンドを使用してパージ・ポリシーの現在の値を確認します。
SQL> select * from mgmt_job_purge_policies;

POLICY_NAME                      TIME_FRAME
-------------------------------- ----------
SYSPURGE_POLICY                          30
REFRESHFROMMETALINKPURGEPOLICY            7
FIXINVENTORYPURGEPOLICY                   7
OPATCHPATCHUPDATE_PAPURGEPOLICY           7

ジョブ削除を行うパージ・ポリシーをSYSPURGE_POLICYと言います。前述のように、デフォルト値は30日に設定されています。

3. この期間を変更するには、ポリシーを削除して別の時間枠でポリシーを再作成する必要があります。
SQL> execute MGMT_JOBS.drop_purge_policy('SYSPURGE_POLICY');

PL/SQL procedure successfully completed.

SQL> execute MGMT_JOBS.register_purge_policy('SYSPURGE_POLICY', 60, null);

PL/SQL procedure successfully completed.

SQL> COMMIT;

Commit complete.

SQL> select * from mgmt_job_purge_policies;

POLICY_NAME                      TIME_FRAME
-------------------------------- ----------
SYSPURGE_POLICY                          60
....

前述のコマンドにより、保存時間が60日に増えています。要件に応じて、時間枠を30日より少なくすることもできます。

次にパージ・ジョブが実行される時間を確認できます。パージが実行される実際の時間は5 AMリポジトリ時間に設定されており、次の手順で確認できます。

1. SYSMANアカウントを使用してリポジトリ・データベースにログインします。

2. 次のコマンドを実行します。

SQL> select job_name,
to_char(last_start_date, 'DD-MON-YY HH24:MI:SS') last_run,
to_char(next_run_date,   'DD-MON-YY HH24:MI:SS') next_run
from all_scheduler_jobs
where job_name ='EM_JOB_PURGE_POLICIES';

JOB_NAME              LAST_RUN           NEXT_RUN
--------------------- ------------------ ------------------
EM_JOB_PURGE_POLICIES                    07-SEP-11 05:00:00

次の手順を実行して、Enterprise Managerコンソールでスケジュールを確認することもできます。

1. 「設定」メニューから、「管理サービス」、「リポジトリ」の順に選択します。

2. 「リポジトリ操作」タブをクリックします。

3. リストで、ジョブのパージの次のスケジュール実行と最後のスケジュール実行に関する情報を探します。

ジョブのパージの次のスケジュール実行時間には、保持期間のカットオフ時間は示されません。カットオフ時間は、ジョブ・パージ実行時にパージ・ポリシーによって決定されます。

20.2.5 DBMS_SCHEDULERのトラブルシューティング

Enterprise Managerでは、データベース・スケジューラ(dbms_scheduler)を使用してリポジトリ内の各種プロセスを実行します。dbms_schedulerが停止されている場合、または操作するための十分なリソースがない場合、Enterprise Managerのプロセスは実行されないか遅延します。次に、dbms_schedulerの正常な実行を妨げる可能性のある、一般的な原因を示します。

ジョブ・キュー・プロセス

dbms_schedulerは、実行するジョブごとに別個のジョブ・キュー・プロセスを使用します。これらのプロセスの最大数は、データベース・パラメータjob_queue_processesによって制御されます。
すべてのプロセスが使用中の場合、新しいジョブは開始されません。

次の問合せは、現在実行中のジョブ数を返します。

SQL> SELECT count(*)
FROM dba_scheduler_running_jobs;

数がjob_queue_processesの設定に近い場合、Enterprise Managerのdbms_schedulerジョブは開始できません(時間どおりに)。実行中のdbms_schedulerジョブのいずれかがスタックかどうかを判断して、Job_queue_processesの設定を引き上げることを検討してください。

ジョブ・スレーブ・プロセス

dbms_schedulerは、dbms_schedulerプロパティMAX_JOB_SLAVE_PROCESSESの設定にも依存します。実行中のdbms_schedulerジョブ数がこの設定を超える場合、新しいジョブは開始されません。この属性は、次の問合せを使用して確認できます。

SQL> SELECT value
FROM dba_scheduler_global_attribute
WHERE attribute_name='MAX_JOB_SLAVE_PROCESSES';

数が実行中のdbms_schedulerジョブと等しい場合、実行中のdbms_schedulerジョブのいずれかがスタックかどうかを判断して、この属性の調整方法についてdbms_schedulerのドキュメントを参照してください。

DBMS_SCHEDULERプログラムの無効化

dbms_schedulerには、データベースでこの機能を無効化するように設定できる属性があります。設定されている場合、Enterprise Managerのdbms_schedulerジョブは実行されません。この属性が(間違って)設定されているかどうかを確認するには、次の問合せを実行します。

SQL> SELECT *
FROM dba_scheduler_global_attribute
WHERE attribute_name = 'SCHEDULER_DISABLED';

行が戻された場合、dbms_schedulerは無効化されています。
dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');を実行します。

この属性の削除方法については、dbms_schedulerのドキュメントを参照してください。

データベース・セッションが多すぎる

各dbms_schedulerジョブには、2つのデータベース・セッションが必要です。これ以上セッションを使用できない場合、Enterprise Managerのdbms_schedulerジョブは実行されません。次の2つの問合せは、セッションの最大許容数および現在アクティブなセッション数を取得します。

SQL> SELECT value
FROM v$parameter
WHERE name='sessions';

SQL> SELECT count(*)FROM v$session;

現在のセッション数が最大数に近づいた場合、セッションのいずれかがスタックかどうかを判断して、セッションの最大数を引き上げる方法についてOracle Databaseのドキュメントを参照してください。

また、セッション数の最高水位標は、この問題が過去に要因があることを示している場合もあります。

SQL> select *
from v$resource_limit
where resource_name = 'sessions' ;

MAX_UTILIZATION列がセッションの最大数に近い値を示す場合、Enterprise Managerの一部のdbms_schedulerジョブが過去に実行されなかった(時間とおりに)ことを説明している可能性があります。

メモリー不足

使用できるメモリーが不足している場合、データベースで新規ジョブ・キュー・プロセスを生成できないことがあります。データベース・アラート・ファイルのjobqスレーブ・プロセスを生成できませんと(空きメモリー = 0.00M)というメッセージの組合せは、この問題を示している可能性があります。このメモリーに関する問題を詳細に診断する方法については、Oracle Databaseのドキュメントを参照してください。

20.3 管理リポジトリの削除および再作成

この項では、Enterprise Managerのインストール後に既存のデータベースから管理リポジトリを削除し、管理リポジトリを再作成する作業について説明します。

dropコマンドからのリカバリはないため、このアクションは、Enterprise Managerサイトを廃止した場合にのみ該当することに注意する必要があります。

20.3.1 管理リポジトリの削除

管理リポジトリを再作成するには、最初に管理リポジトリ・データベースからEnterprise Managerスキーマを削除します。このタスクを行うには、RepManagerスクリプトに-action drop引数を使用します。これについては、次の手順で説明します。

データベースから管理リポジトリを削除するには、次の手順を実行します。

1. 管理サービスをインストールおよびデプロイしたミドルウェア・ホームの次のディレクトリで、RepManagerスクリプトを見つけます。

ORACLE_HOME/sysman/admin/emdrep/bin

注意:
Repmanagerスクリプトのデータベース・バージョンは使用しないでください。すべてのコンポーネントを削除するわけではないので、再インストールが失敗します。
また、RepManagerはリポジトリを削除する唯一の方法であるため、削除が正常に完了するまではOMSホームを削除しないでください。

2. コマンド・プロンプトで次のコマンドを入力します。

$PROMPT> RepManager repository_host repository_port repository_SID
-sys_password password_for_sys_account -action drop

この構文例では次のようになります。

- repository_hostは、管理リポジトリ・データベースが配置されるマシン名です。

- repository_portは、管理リポジトリ・データベースのリスナー・ポート・アドレスです(通常は1521)。

- repository_SIDは、管理リポジトリ・データベースのシステムIDです。

- password_for_sys_accountは、データベースのSYSユーザーのパスワードです。たとえば、change_on_installなどです。

- -action dropは、管理リポジトリ、MDS、OPSS、APMおよびスキーマを削除することを示します。dropを使用する場合、コマンドは管理リポジトリのみを削除します。

注意:
dropコマンドはBIスキーマ(SYSMAN_BIPLATFORM)を削除します(存在する場合)。

あるいは、接続記述子を使用して、RepManagerコマンドラインでデータベースを特定することもできます。接続記述子は、標準のOracleデータベース構文を使用してデータベースのホスト、ポート、名前を特定します。

たとえば、接続記述子を次のように使用して管理リポジトリを作成できます。

$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=host1)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=servicename)))"
-sys_password efkl34lmn -action drop

関連項目:
接続記述子を使用したデータベースへの接続の詳細は、『Oracle Enterprise Managerライセンス情報』の接続の確立およびネットワークのテストに関する項。

20.3.2 管理リポジトリの再作成

管理リポジトリを作成するには、Enterprise Managerのインストール時に管理リポジトリを作成する方法がお薦めです。これはOracle Universal Installerを使用して行います。

関連項目:
Enterprise Managerのインストールの詳細は、Oracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイド。

リポジトリが削除されると、RepManager createコマンドを使用してリポジトリを単独で作ることはできません。コマンドはリポジトリ・データベース内に必要なすべてのユーザーを作成するわけではありません。リポジトリを作成するには、Cloud Controlを完全に再インストールする必要があります。

定期的にリポジトリをバックアップすることにより、推奨されるベスト・プラクティスに従っている場合、次のうちのいずれかに該当するかぎり、リポジトリのバックアップを使用できます。

- プライマリOMSホームが完全である

- プライマリOMSのエクスポート/構成がある

- プライマリOMSのファイル・システムのバックアップがある。

20.3.2.1 接続記述子を使用した管理リポジトリ・データベースの特定

接続記述子を使用してRepManagerコマンドラインでデータベースを指定できます。接続記述子は、標準のOracleデータベース構文を使用してデータベースのホスト、ポート、名前を特定します。

たとえば、接続記述子を次のように使用して管理リポジトリを作成できます。

$PROMPT> ./RepManager -connect "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=host1)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=servicename)))"
-sys_password efkl34lmn -action create

関連項目:
接続記述子を使用したデータベースへの接続の詳細は、『Oracle Enterprise Managerライセンス情報』の接続の確立およびネットワークのテストに関する項。

接続文字列の使用により、アドレス・リストを接続文字列の一部として指定できます。次の例は、RepManagerコマンドラインの一部として2つのリスナーで構成されるアドレス・リストの指定方法を示しています。一方のホストのリスナーが使用できなくなると、もう一方のリスナーが引き続き受信リクエストを受け入れることができます。

$PROMPT> ./RepManager -connect "(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521)
(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)
(CONNECT_DATA=(SERVICE_NAME=servicename)))"
-sys_password efkl34lmn -action create

関連項目:
Oracle Database高可用性のアーキテクチャおよびベスト・プラクティス
Oracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイド

20.4 管理リポジトリの作成エラーのトラブルシューティング

Oracle Universal Installerは、インストール・プロセスの最後に構成手順を使用して管理リポジトリを作成します。リポジトリ構成ツールが失敗した場合、構成ツール・ウィンドウに表示される正確なエラー・メッセージを書き留め、それ以外の構成ツールが終了するまで待機してUniversal Installerを終了し、次の項を使用して問題を解決します。

20.4.1 管理リポジトリの作成時に発生するパッケージ本体が存在しないエラー

管理リポジトリの作成が中断した場合、後から管理リポジトリを作成または削除しようとすると次のエラーが表示されます。

SQL> ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-04068: existing state of packages has been discarded
ORA-04067: not executed, package body "SYSMAN.MGMT_USER" does not exist
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at "SYSMAN.SETEMUSERCONTEXT", line 5
ORA-06512: at "SYSMAN.CLEAR_EMCONTEXT_ON_LOGOFF", line 4
ORA-06512: at line 4

この問題を修正するには、「管理リポジトリを作成するための一般的なトラブルシューティング技法」を参照してください。

20.4.2 管理リポジトリの作成時に発生するサーバー接続ハング・エラー

管理リポジトリ・データベースに接続しようとする際に次のようなエラーが発生する場合、サポートされていないリリースのOracle Databaseが使用されている可能性があります。

Server Connection Hung

問題を修正するには、Oracle Enterprise Manager Cloud Controlインストレーションおよび基本構成ガイドの説明に従って、サポートされているリリースにデータベースをアップグレードします。

20.4.3 管理リポジトリを作成するための一般的なトラブルシューティング技法

管理リポジトリの作成時にエラーが発生した場合、RepManagerスクリプトに-drop引数を指定して実行し、リポジトリを削除します。

関連項目:
第20.3.1「管理リポジトリの削除」

RepManagerスクリプトでリポジトリが正常に削除された場合、管理リポジトリの作成を再試行します。

なんらかの理由でRepManager -action drop/dropが失敗した場合、次の手順を実行します。

1. バンドル・パッチを12c OMSホームに適用します。この手順は、12.1.0.1 OMSにのみ該当します。手順については、My Oracle Supportノート1393173.1: Enterprise Manager Cloud Controlバンドル・パッチ1および12.1.0.2プラグインのインストール手順を参照してください。

2. OMSを停止し、すべてのWLS / OMSプロセスがOMSホームで停止されたことを確認します。

cd <ORACLE_HOME>/bin
emctl stop oms -all

注意:
管理サーバーも同様に停止するように、-allオプションを使用する必要があります。

実行中のWLS / OMSプロセスがないことを確認します。

$ ps -ef | grep EMGC
$ ps -ef | grep java

3. "Repmanager drop"コマンドを使用してリポジトリ・オブジェクトを削除します。

cd <ORACLE_HOME>/sysman/admin/emdrep/bin
RepManager <database hostname> <database listener port> <database sid> -action drop -dbUser sys -dbPassword <sys user password> -dbRole sysdba -mwHome <Middleware Home> -mwOraHome <Middleware Home> -oracleHome <OMS Home>

次に例を示します。

RepManager repomachine.domain 1521 orcl -action drop -dbUser sys -dbPassword oracle123 -dbRole sysdba -mwHome /home/oracle/Middleware
-mwOraHome /home/oracle/Middleware -oracleHome /home/oracle/Middleware/oms

4. リポジトリ・データベースにsysまたはDBAユーザーとしてログインし、すべてのリポジトリ・オブジェクトが削除されたことを確認します。

SQL> select username,account_status from dba_users where username in ('SYSMAN', 'SYSMAN_MDS','MGMT_VIEW','SYSMAN_BIPLATFORM','SYSMAN_APM','BIP','SYSMAN_OPSS','SYSMAN_RO') ;

SQL> select owner,synonym_name from dba_synonyms where table_owner in ('SYSMAN', 'SYSMAN_MDS','MGMT_VIEW','SYSMAN_BIPLATFORM','SYSMAN_APM','BIP','SYSMAN_OPSS','SYSMAN_RO') ;

SQL> select tablespace_name from dba_tablespaces where tablespace_name like 'MGMT%';

SQL> select comp_name from SCHEMA_VERSION_REGISTRY;

前述の問合せはどれも行を戻す必要はありません。前述の問合せのいずれかで行が戻された場合は、OracleサポートとSRを作成します。

注意:
前述のソリューションはOMSが実行中の場合に適用できます。OMSホームが使用できないか、損傷している場合は、OracleサポートとSRを作成します。

20.5 クロス・プラットフォームのEnterprise Managerリポジトリの移行

Enterprise Managerリポジトリをサーバー間およびクロス・プラットフォームで移行するためのユーザー要件があります。

Enterprise Managerリポジトリ移行プロセスは、データベース移行の場合と完全に同じではありません。Enterprise Managerリポジトリ移行の場合、Enterprise Managerに固有のデータ、オプション、前提条件に注意してリポジトリを移動する必要があります。Enterprise ManagerとOracleデータベースの両方の観点からデータの整合性が維持されることを確認する必要があります。

このためには、最短時間で最大効率が得られる、正常で信頼性の高いリポジトリの移行を行うためにエンド・ユーザーが従うプロセスを定義する必要があります。

移行の全体の戦略は次の内容によって異なります。

- ソース・データベースとターゲット・データベースのバージョン

- リポジトリのデータ/サイズの量

- 移行する実際のデータ(選択移行/完全移行)

ソースとターゲットがリリース12c以外の場合、クロス・プラットフォームでデータを移行する方法はエクスポート/インポートのみになります。

クロス・プラットフォームのトランスポータブル表領域、データ・ポンプ、エクスポート/インポートのオプションの詳細は、Oracle Technology Network(OTN)または『Oracle Database管理者ガイド』を参照してください。

20.5.1 一般的な前提条件

次に、リポジトリを移行するための一般的な前提条件を示します。

- ソースとターゲットのデータベースは、同じ文字セットを使用し、同じリリースにします。

- ソース・データベースとターゲット・データベースのプラットフォームは同じエンディアン形式である必要があります。

- ターゲットのデータベースは、Oracle Enterprise Managerインストレーション・ガイドに示されたEnterprise Managerリポジトリのソフトウェア要件について言及されたすべての前提条件を満たす必要があります。

- ソースとターゲットのデータベースが10gR2およびそれ以上のrdbmsバージョンにある場合、その他の前提条件を満たしているならば、クロス・プラットフォーム・リポジトリ移行に、クロス・プラットフォーム・トランスポータブル・データベース移行を使用できます。

- 同じ名前の表領域がすでにあるターゲット・データベースに表領域をトランスポートすることはできません。ただし、トランスポート操作前に、トランスポートする表領域またはトランスポート先の表領域の名前を変更できます。

- トランスポータブル表領域セットを別のプラットフォームのOracle Databaseにプラグインするには、両方のデータベースの互換性を最低でもリリース10.0に設定する必要があります。

- ほとんどのプラットフォーム(ただしすべてではない)は、クロス・プラットフォームの表領域トランスポートがサポートされています。V$TRANSPORTABLE_PLATFORMビューに問合せを実行して、サポートされるプラットフォームを確認したり、そのプラットフォームIDやエンディアン形式(バイト順序)を判断したりすることができます。

- ソースと移行先のホストでは、Enterprise Managerの管理エージェントが実行され、移行するインスタンスのために構成されている必要があります。

- ターゲット・データベースにEnterprise Managerリポジトリがインストールされている場合、ターゲット・データベースに関連する手順を行う前に、RepManagerを使用してEMリポジトリを最初に削除する必要があります。

20.5.2 手法

次の項では、リポジトリ移行の2つの手順について説明します。

- クロス・プラットフォーム・トランスポータブル・データベースの使用方法

- フィジカル・スタンバイを使用した移行

20.5.2.1 クロス・プラットフォーム・トランスポータブル・データベースの使用方法

Oracleのトランスポータブル・データベース機能では、Oracleデータベース間でユーザー表領域をすばやく移動できます。この方法は、データベース間で大量データを移動するのに最も効率的です。クロス・プラットフォーム・トランスポータブル・データベースを使用すると、プラットフォーム間で表領域をトランスポートできます。

クロス・プラットフォームのトランスポータブル・データベースでは、プラットフォームから別のプラットフォームにデータベースを移行できます(データ・ポンプまたはインポート/エクスポートで使用)。次のトランスポータブル・データベースを使用した移行手順は、同じエンディアンのプラットフォーム間での移行に使用できます。

1. v$db_transportable_platformから宛先プラットフォームで移行が可能かどうかを確認します。
SQL> select platform_name from v$db_transportable_platform;

次のリストのようなプラットフォームのリストが表示されます。

Microsoft Windows IA (32-bit)
Linux IA (32-bit)
HP Tru64 UNIX
Linux IA (64-bit)
HP Open VMS
Microsoft Windows IA (64-bit)
Linux x86 64-bit
Microsoft Windows x86 64-bit
Solaris Operating System (x86)
HP IA Open VMS
Solaris Operating System (x86-64)

2. 外部表およびファイルがデータベースに存在することを確認します。

SQL> set serveroutput on
SQL> declare x boolean;
2  begin x := dbms_tdb.check_external;
3  end;
4  /

結果は次のように出力されます。

The following external tables exist in the database:
SH.SALES_TRANSACTIONS_EXT
The following directories exist in the database:
SYS.SUBDIR, SYS.SS_OE_XMLDIR, SYS.MEDIA_DIR, SYS.LOG_FILE_DIR,
SYS.DATA_FILE_DIR, SYS.XMLDIR, SYS.DATA_PUMP_DIR, SYS.ORACLE_OCM_CONFIG_DIR
The following BFILEs exist in the database:
PM.PRINT_MEDIA

次のコマンドを入力します。

SQL> select directory_path from dba_directories;

結果は次のように出力されます。

DIRECTORY_PATH
--------------------------------------------------------------------------------
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/order_entry//2002/Sep
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/order_entry/
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/log/
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/sales_history/
/ade/b/1191423112/oracle/rdbms/xml
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media/
/home/oracle/app/oracle/admin/orcl/dpdump/
/home/oracle/app/oracle/product/11.2.0/dbhome_1/ccr/state

8 rows selected.

次のコマンドを入力します。

SQL> select directory_path||'/'||location External_file_path from dba_directories a, dba_external_locations b where a.directory_name=b.directory_name;

結果は次のように出力されます。

EXTERNAL_FILE_PATH
----------------------------------------------------------------------------
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/sales_history//sale1v3.dat

次のコマンドを入力します。

SQL> @tgt_get_bfile_dirs.sql

結果は次のように出力されます。

The following directories contain external files for BFILE columns
Copy the files within these directories to the same path on the target system

/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media/

There are 1 directories, 4 total BFILEs

SQL> @tgt_get_bfiles.sql
External files for BFILE column AD_GRAPHIC in table PM.PRINT_MEDIA
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//monitor.jpg
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//mousepad.jpg
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//keyboard.jpg
/home/oracle/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media//modem.jpg

3. OMSを停止します。
emctl stop oms -all

次のSQLコマンドを入力します。

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 1473089536 bytes
Fixed Size                  1336596 bytes
Variable Size            1124076268 bytes
Database Buffers          335544320 bytes
Redo Buffers               12132352 bytes
Database mounted.

4. データベースを読取り専用モードでオープンします。
SQL> alter database open read only;

次のSQLコマンドを入力します。

SQL> set serveroutput on
SQL> declare
2  retcode boolean;
3  begin
4  retcode := dbms_tdb.check_db('Linux IA (64-bit)',dbms_tdb.skip_none);
5  end;
6  /

SQL> declare
2  retcode boolean;
3  begin
4  retcode := dbms_tdb.check_db('Linux x86 64-bit',dbms_tdb.skip_none);
5  end;
6  /

PL/SQL procedure successfully completed.

5. RMAN変換スクリプトを生成します。

[oracle]$ ./rman
Recovery Manager: Release 11.2.0.1.0 - Production on Fri dd-mm-yy 12:10:29 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
RMAN> connect target /
connected to target database: ORCL (DBID=1308105793)
RMAN> convert database on target platform
2> convert script '/tmp/convert_mydb.rman'
3> transport script '/tmp/transport_mydb.sql'
4> new database 'mydb'
5> format '/tmp/mydb%U'
6> db_file_name_convert '/home/oracle/app/oracle/oradata/mydb/','/tmp';

Starting conversion at source at dd-mm-yy
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=135 device type=DISK

External table SH.SALES_TRANSACTIONS_EXT found in the database

Directory SYS.SUBDIR found in the database
Directory SYS.SS_OE_XMLDIR found in the database
Directory SYS.MEDIA_DIR found in the database
Directory SYS.LOG_FILE_DIR found in the database
Directory SYS.DATA_FILE_DIR found in the database
Directory SYS.XMLDIR found in the database
Directory SYS.DATA_PUMP_DIR found in the database
Directory SYS.ORACLE_OCM_CONFIG_DIR found in the database

BFILE PM.PRINT_MEDIA found in the database

User SYS with SYSDBA and SYSOPER privilege found in password file
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00001 name=/home/oracle/app/oracle/oradata/orcl/system01.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00002 name=/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00007 name=/home/oracle/app/oracle/oradata/orcl/mgmt.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00003 name=/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00008 name=/home/oracle/app/oracle/oradata/orcl/mgmt_ad4j.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00005 name=/home/oracle/app/oracle/oradata/orcl/example01.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00006 name=/home/oracle/app/oracle/oradata/orcl/mgmt_depot.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile file number=00004 name=/home/oracle/app/oracle/oradata/orcl/users01.dbf
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
Edit init.ora file /tmp/init_mydb00nbs6dl_1_0.ora. This PFILE will be used to create the database on the target platform
Run RMAN script /tmp/convert_mydb.rman on target platform to convert datafiles
Run SQL script /tmp/transport_mydb.sql on the target platform to create database
To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform
To change the internal database identifier, use DBNEWID Utility
Finished conversion at source at dd-mm-yy

6. 必要なファイルはすべて一時的な場所にコピーし、ターゲット・マシンにマウントします。

convert_mydb.rman
init_mydb.ora
transport_mydb.sql (and other data files listed in rman script [convert_mydb.rman] and redolog files)

7. 手順5で生成したスクリプトをターゲット・マシンで実行します。
RMANスクリプトにはデータファイルの変換コマンドが含まれています。SQLスクリプトには、コントロール・ファイルの作成、オブジェクトの無効化、オブジェクトの再コンパイルが含まれます。ターゲット・マシンで、次を実行します。

RMAN> connect target /

RMAN> @/home/oracle/migrate/convert_mydb.rman

8. データベースが稼働中で、リスナーに登録されていることを確認します。
RMAN> STARTUP NOMOUNT PFILE = '/home/oracle/migrate/init_mydb00nbs6dl_1_0.ora'; database is already started

9. OMSを開始して、管理サーバーが起動中であることを確認します。
[oracle]$ ./emctl status oms

[oracle]$ ./emctl start oms

10. OMSを停止します。
[oracle]$ ./emctl stop oms

11. リポジトリ・データベース接続の詳細を更新します。
[oracle]$ ./emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=evildead.idc.oracle.com)(PORT=1521)))(CONNECT_DATA=(SID=mydb)))" -repos_user SYSMAN -repos_pwd Oracle123

この環境にOracle Management Serviceが複数ある場合は、それらすべてでこのstore_repos_detailsコマンドを実行します。

12. OMSを再起動します。
[oracle]$ ./emctl start oms

[oracle]$ ./emctl status oms

Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.4.0
Copyright (c) 1996, 2013 Oracle Corporation.  All rights reserved.
WebTier is Up
Oracle Management Server is Up

13. 管理サービスとリポジトリ・ターゲットを再配置します。

20.5.2.2 フィジカル・スタンバイを使用した移行

次の手順で、フィジカル・スタンバイを使用してリポジトリを移行するのに使用できるプロセスについて説明します。この方法は、ソースとターゲットのプラットフォームがサポートされる場合に使用できます。サポートされるプラットフォームの組合せの詳細は、My Oracle Supportノート:413484.1を参照してください。

1. データベースORACLE_HOMEをターゲット・マシンにインストールします。バイナリはソースと同じバージョンである必要があります。
ターゲット・マシンがWindowsの場合、管理エージェントのデプロイには、WindowsマシンにCYGWINをインストールして構成します。

2. 管理エージェントをターゲット・サーバーにデプロイします。

3. Data Guardのドキュメントに従い、フィジカル・スタンバイを作成します。

4. Data Guard Brokerのドキュメントに従い、Data Guard Brokerを構成します。

5. OMSを停止します。
emctl stop oms -all

6. OMS接続記述子を確認します。
./emctl config oms -list_repos_details

7. dgmgrlを使用してデータベースをスイッチオーバーします。
次のコマンドを使用します。

DGMGRL> switchover to target_db
verify
show configuration
show database target_db
show database source_db

8. OMS管理サーバーを起動します。
emctl start oms -admin_only

9. スタンバイ・データベースを指すように接続記述子を更新します。
eemctl config oms -store_repos_details -repos_conndesc "(DESC= )" -repos_user sysman

[oracle]$ ./emctl config oms -store_repos_details -repos_conndesc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sample2.us.company.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=test_win)))" -repos_user sysman
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.4.0
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.
Enter Repository User's Password :
Successfully updated datasources and stored repository details in Credential Store.

この環境にOracle Management Serviceが複数ある場合は、それらすべてでこのstore_repos_detailsコマンドを実行します。

10. すべてのOracle Management Serviceを停止します。
emctl stop oms -all

11. OMSを開始します。
emctl start oms

12. Oracle Management Serviceとリポジトリを再配置します。
emctl config emrep -conn_desc

[oracle]$ ./emctl config emrep -conn_desc "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sample2.us.company)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=test_win)))"
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.4.0
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.
Please enter repository password:
Enter password :
Login successful
Moved all targets from sample.us.company.com:3872 to sample2.us.company.com:3872
Command completed successfully!
Enter password :
Login successful
Moved all targets from sample.us.company.com:3872 to sample2.us.company.com:3872
Command completed successfully!

13. OMSのバックアップを作成します(管理サーバーが動作しているOMS)。
$ <ORACLE_HOME>/bin/emctl exportconfig oms [-sysman_pwd <sysman password>]

バックアップ・ファイルを保存するディレクトリを指定します。

[-dir <backup dir>]

OMSが仮想のホスト名を使用してインストール(ORACLE_HOSTNAME=<virtual_hostname>を使用)された場合は、次のパラメータを指定します。

[-keep_host]

20.5.3 移行後の検証

次の検証手順を移行後に実行し、移行が完全に成功したかどうかを確認します。

- ソース・データベースとターゲット・データベースをEnterprise Managerで比較してオブジェクトの矛盾を検証します。

- 移行されたデータベースをEnterprise Managerで検証し、データベースが問題なく実行しているかどうかを確認します。

- リポジトリ操作、dbmsジョブ、管理システム・エラーが報告されているかどうかを検証します。

- すべてのEnterprise Manager機能が移行後適切に機能しているかどうかを検証します。

- Enterprise Managerによる検証で、管理サービスとリポジトリ・データベースが適切に再配置されていることを確認します。

21 Cloud Controlの更新

自己更新機能では、新規または更新機能が使用可能になるとすぐにEnterprise Managerコンポーネントが更新されるため、Enterprise Managerの機能を強化できます。更新プラグインはEnterprise Managerストアから使用でき、この外部サイトは、ダウンロード可能な更新についての情報を得るためにEnterprise Manager Cloud Controlによって定期的にチェックされます。

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

- 自己更新の使用方法

- 自己更新の設定

- 更新の適用

- 情報更新へのアクセス

- 管理エージェント・ソフトウェアの取得または更新

21.1 自己更新の使用方法

自己更新機能は、自己更新ホームページからアクセスされます。このホームページは、新規の更新に関する情報の入手に使用される共通ダッシュボードであり、更新の確認、ダウンロードおよび適用を行うための共通ワークフローでもあります。自己更新コンソールを使用すると、オラクル社から入手できる新規の更新について様々なチャネルを監視する必要がなくなります。自己更新コンソールでは、新規の更新がオラクル社から入手可能になると自動的に通知されます。サイトに適用される更新のみ表示されるため、関係のない更新を確認する必要はありません。

21.1.1 更新できる内容

オラクル社が作成する特定の更新は通常、特定のCloud Controlリリースにバンドルされており、これは自己更新によって更新できます。たとえば、オラクル社が作成した管理プラグインやデプロイメント・プロシージャがその例です。一般に、オラクル社提供のエンティティは読取り専用です。ユーザーは、必要に応じてコピーを作成し、コピーをカスタマイズできますが、オラクル社提供の元のエンティティを変更することはできません。

これらのエンティティは、Oracle Technology Network (OTN)やMy Oracle Support (MOS)などのオラクル社のWebサイトでも公開されます。更新可能なエンティティで提供される特定のインポート機能を使用して、エンティティ・アーカイブをダウンロードし、Cloud Control環境にインポートできます。

更新できるエンティティ・タイプ

更新可能なエンティティ・タイプの例として、次のものがあります。

- 管理エージェント

- 管理プラグイン

- 管理コネクタ

- データベース・プロファイルとゴールド・イメージ

- アプリケーション・サーバー・プロファイルとゴールド・イメージ

- プロビジョニング・バンドル

- Enterprise Managerデプロイの前提条件チェック

- コンプライアンス・コンテンツ

- 診断チェック

21.2 自己更新の設定

自己更新機能を使用する前に、次の前提条件を満たしている必要があります。

- My Oracle Support資格証明がSYSMANユーザーを使用して設定されていること。これは、My Oracle Supportサイトからのエンティティのダウンロードに必要です。

- ソフトウェア・ライブラリ(ローカル・ストアとも呼ばれています)が構成されていること。更新は、Cloud Controlにデプロイされる前に、このローカル・ストアにダウンロードされます。

自己更新の設定手順は、次の各項を参照してください。

- Enterprise Manager自己更新モードの設定

- ユーザーへの自己更新権限の割当て

- ソフトウェア・ライブラリの設定

- My Oracle Supportの優先資格証明の設定

- My Oracle Support用のプロキシ詳細の登録

- EM CLIユーティリティの設定(オプション)

21.2.1 Enterprise Manager自己更新モードの設定

Enterprise Managerの自己更新機能を設定または変更するためには、Enterprise Managerスーパー管理者権限を持っている必要があります。

1. スーパー管理者権限のある管理者としてEnterprise Managerにログインします。

2. 「設定」メニューで、「拡張性」、「自己更新」の順に選択します。自己更新コンソールがデフォルト設定で表示されます。

3. 「一般」ステータス領域から、「接続モード」ステータスをクリックして、オフライン・モードまたはオンライン・モードのいずれかを設定します。パッチ適用設定ページに移動したら、オンラインおよびオフライン設定を指定します。

重要:
オンライン・モードで動作しているCloud Controlは、いずれのデータもMOSにアップロードしません。MOSを使用するのは、最新の更新をダウンロードする場合のみです。

4. 必要な接続モードを設定したら、自己更新コンソールに戻ります。
ここから、エンティティ・タイプを選択し、Enterprise Manager Updateストアからの更新をスケジュールすることができます。

21.2.2 ユーザーへの自己更新権限の割当て

Enterprise Manager管理者は、自己更新機能を使用するのに必要な権限を持っている必要があります。Enterprise Managerのスーパー管理者は、次の自己更新ロール/権限をこれらの管理者に割り当てる必要があります。

- 任意のEnterprise Managerの更新を表示–自己更新コンソールを表示し、ダウンロードと適用ジョブのステータスを監視できます。

- 自己更新管理者–ダウンロードと適用ジョブをスケジュールできます。更新の抑止と抑止解除も可能です。この権限には、「任意のEnterprise Managerの更新を表示」権限が暗黙的に含まれます。

- EM_INFRASTRUCTURE_ADMIN–すべての自己更新操作を実行できます。このロールには、「自己更新管理者」権限が暗黙的に含まれます。

デフォルトでは、スーパー管理者にはEM_INFRASTRUCTURE_ADMIN権限が付与されます。

自己更新の権限を通常のEnterprise Manager管理者に割り当てるには:

1. 「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。

2. 管理者を選択し、「編集」をクリックします。

3. ロール・ページから、適切な自己更新ロールを割り当てます。

21.2.3 ソフトウェア・ライブラリの設定

ソフトウェア・ライブラリは、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなどのソフトウェア・エンティティを格納するリポジトリです。これらを格納する以外に、ソフトウェア・エンティティのバージョン、成熟度レベルおよび状態を管理することもできます。更新適用のコンテキストでは、デプロイの前にエンティティがダウンロードされるのはローカル・ストアです。

ソフトウェア・ライブラリが使用環境で設定されていない場合、ソフトウェア・ライブラリを構成する様々な方法での手順については、第8章「ソフトウェア・ライブラリの構成」を参照してください。

21.2.4 My Oracle Support優先資格証明の設定

OMSで使用する必要がある優先資格証明を設定して、My Oracle Support (MOS)に接続するには、次の手順を実行します。

1. 「設定」メニューから「My Oracle Support」を選択し、「資格証明の設定」を選択します。

2. ユーザー名とパスワードを指定します。

3. 「適用」をクリックします。

21.2.5 My Oracle Support用のプロキシ詳細の登録

Cloud Controlでは、OMSホストで設定したインターネット接続を使用してMy Oracle Supportに接続します。ただし、環境でプロキシ・サーバーを設定している場合は、プロキシの詳細を登録する必要があります。My Oracle Supportの「プロキシ設定」ページを使用して、My Oracle Support用のプロキシ詳細を登録できます。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Supportからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを指定するか、My Oracle SupportにアクセスするクライアントからこのURLへのプロキシ・アクセスを付与する必要があることを意味します。

My Oracle Support (MOS)用のプロキシ詳細を登録するには、次の手順を実行します。

1. 「設定」メニューから、「プロキシ設定」を選択してから、「My Oracle Support」を選択します。

2. OMSがプロキシ・サーバーを使用せずにMOSに直接接続する必要がある場合は、次の手順を実行します。

1. 「プロキシなし」を選択します。

2. 「テスト」をクリックして、OMSがMOSに直接接続できるかどうかをテストします。

3. 接続が成功した場合、「適用」をクリックしてプロキシ設定をリポジトリに保存します。

3. OMSがプロキシ・サーバーを使用してMOSに接続する必要がある場合は、次の手順を実行します。

1. 「手動プロキシ構成」を選択します。

2. 「https」にプロキシ・サーバーのホスト名を、「ポート」に適切なポート値を指定します。

3. 指定したプロキシ・サーバーがセキュリティ・レルムまたはログイン資格証明(あるいはその両方)を使用して構成されている場合、「パスワード/拡張設定」を選択してから、「レルム」、「ユーザー名」および「パスワード」に値を指定します。

4. 「テスト」をクリックして、指定したプロキシ・サーバーを使用してOMSがMOSに接続できるかどうかをテストします。

5. 接続が成功した場合、「適用」をクリックしてプロキシ設定をリポジトリに保存します。

注意:

- 設定でプロキシ・サーバーを使用している場合、aru-akam.oracle.com、ccr.oracle.com、login.oracle.com、support.oracle.comおよびupdates.oracle.comに接続できることを確認します。
Microsoftプロキシ・サーバーに基づいたNTLM (NT LAN Manager)はサポートされていません。Microsoftプロキシ・サーバーに基づいたNTLMを使用している場合、前述のサイトにアクセスできるようにするには、プロキシ・サーバーの認証されていないサイト・プロパティに前述のURLを追加します。

- MOSのプロキシ設定ページで指定したMOSプロキシ・サーバーの詳細は、複数のOMS環境内のすべてのOMSに適用されます。

21.2.6 EM CLIユーティリティの設定(オプション)

ソフトウェア更新をオフライン・モードで適用する場合、Enterprise Managerコマンドライン・ユーティリティ、つまりEM CLIを使用して、デプロイ用のエンティティ・アーカイブをEnterprise Managerにインポートする必要があります。

EM CLIは、OMSアウトオブボックスで設定されています。Enterprise Managerが管理する別のマシンでEM CLIを設定する必要がある場合は、Cloud ControlコンソールにEM CLIの設定手順を示すページが表示されます。Cloud Controlコンソールへのアクセスに使用するURLに/console/emcli/downloadを追加して、ページにアクセスします。

https://emcc_host:emcc_port/em

次に例を示します。

https://emcc_host:emcc_port/em/console/emcli/download

21.3 更新の適用

更新の適用プロセスは、基本的に次のようになります。

- オラクル社から入手可能な最新の更新をチェックします。

- ソフトウェア・ライブラリに適用する更新をダウンロードします。

- 更新を適用します。

次の項で、更新の適用方法について説明します。

- オンライン・モードでの更新の適用

- オフライン・モードでの更新の適用

21.3.1 オンライン・モードでの更新の適用

更新を適用するためには、ソフトウェア・ライブラリ(ローカル・ストア)にダウンロードする必要があります。自己更新コンソールから、入手可能な最新の更新を確認できます。

Enterprise Managerで入手可能な更新をダウンロードするには、インターネット経由でEnterprise Managerストアにアクセスできる必要があります。このアクセスが不可能な場合は、オフライン・モードでエンティティをダウンロードできます。詳細は、第21.3.2項「オフライン・モードでの更新の適用」を参照してください。

1. 「設定」メニューで、「拡張性」、「自己更新」の順に選択します。

2. 「更新の確認」をクリックして、Oracleからの新しい更新があるかどうかを確認するジョブを発行します。「OK」をクリックして、確認メッセージを閉じます。

3. ジョブが完了したら、目的のエンティティ・タイプを選択し、「アクション」メニューから「開く」を選択します。エンティティ・タイプのページが表示されます。

4. 使用可能な更新のリストから更新を選択します。

5. 「ダウンロード」をクリックします。「スケジュール・ダウンロード」ダイアログ・ボックスが表示されます。

6. 更新をいつダウンロードするか選択します。複数のダウンロードを同時にスケジュールすることも可能です。
次のオプションが使用可能です。

- 即時

- 後で(指定した時刻)

- ダウンロードが完了したとき通知を送信するかどうか

7. 「選択」をクリックします。ソフトウェア・ライブラリに更新をダウンロードするためのEnterprise Managerジョブが作成されます。
Enterprise Managerでは、Oracle Enterprise Managerストアからのアーカイブのダウンロードが開始します。ダウンロードが完了するまで待ちます。(オフライン・モードの場合、システムは指定された場所からの読取りを開始します。)

ダウンロードが完了すると、確認ページが表示されます。

注意:
ページは自動的にはリフレッシュされません。更新出力ダウンロード・ステータスを表示するには、リフレッシュ・アイコンをクリックします。

8. エンティティが一度ソフトウェア・ライブラリにダウンロードされれば、インストールに適用できるようになります。リストから「ダウンロード」ステータスの更新を選択してから、「適用」をクリックします。
アプリケーション・プロセスはエンティティ・タイプによって次のように異なります。

- コネクタ、診断チェックおよびコンプライアンス・コンテンツの場合、「適用」をクリックすると、Enterprise Managerの更新がインストールされます。これ以外のアクションは必要ありません。

- プラグインの場合、プラグイン・デプロイ・ページにリダイレクトされます。

- プロビジョニング・バンドルの場合、Enterprise Managerコンソールを終了し、端末を介してOpatchおよび他のコマンドを実行し、OMSを再起動する必要があります。

21.3.2 オフライン・モードでの更新の適用

セキュリティの厳しい環境など、状況によっては、Enterprise ManagerとEnterprise Manager Updateストアとの間でインターネット接続を確立できない場合があります。このような状況では、オフライン・モードで自己更新機能を使用できます。

Enterprise Manager Updateストアへの接続で引き続き更新を入手する必要があるため、更新プロセスでは、インターネットにアクセス可能なコンピュータがサイトに存在する必要があります。このコンピュータからは、ファイアウォールを越えたところにあるコンピュータにも更新ファイルを転送できます。

オフライン更新の一般的な手順は、次のとおりです。

1. Cloud Controlがオフライン・モードに設定されていることを確認します。「設定」メニューから、「プロビジョニングとパッチ適用」、「オフライン・パッチ」の順に選択します。

2. 「接続」の設定を「オフライン」に変更します。

3. 自己更新ホームページで、「更新の確認」をクリックします。メッセージが表示され、すべての更新のカタログをダウンロードするためにアクセスされるURLが示されます。

4. インターネット接続できるコンピュータから、メッセージに記載されていたURLを使用してカタログ・ファイルをダウンロードします。

5. ダウンロードしたファイルを、更新のデプロイ先であるOracle Management Serviceホストまたは管理エージェント・ホストにコピーします。

6. emcli import_update_catalogコマンドを実行して、更新するOracle Management Serviceインスタンスまたは管理エージェントに、ファイルをインポートします。

7. 自己更新ホームから更新を確認し、「アクション」メニューの「ダウンロード」をクリックします。URLおよび手順を含むメッセージが表示されます。

8. 更新を適用するには、「アクション」メニューの「適用」をクリックします。

21.4 情報更新へのアクセス

自己更新機能は、新製品のお知らせ、ニュース記事、業界の最新情報、およびOracleコミュニティにとって関心のあるその他の多くの項目などを提供する、ニュース・フィードとしても機能します。これらの情報更新は、非定型ベースで発生し、通常、追加情報およびダウンロード項目を取得できる便利なリンクがあります。

1. 「設定」メニューで、「拡張性」、「自己更新」の順に選択します。

2. 図21-1に示すように、自己更新ページで、右上隅にある「情報更新」リンクをクリックします。リンクには、新規更新の数が含まれています。新規(未読)の更新がある場合のみ、数が表示されます。

図21-1 自己更新ホーム・ページでの「情報更新」リンク

「情報更新」ダイアログが開きます。

3. 表で更新通知を選択し、「詳細」をクリックします。
新製品を説明し、適用可能なリンクがリストされたポップアップが表示されます。

図21-2に、Enterprise Managerにリモートから接続できる新しいiPhoneアプリである、Enterprise Manager Cloud Control Mobileが使用可能になったことをお知らせする情報更新を示します。この場合、お知らせには、そこからアプリをダウンロードできるiTunesへのリンクが含まれることに注意してください。

図21-2 モバイル・アプリの情報更新

4. 「OK」をクリックして、詳細表示を閉じ、お知らせの表に戻ります。
デフォルトでは、表には未読のお知らせのみが表示されます。すべてのお知らせを表示するか、既読のお知らせのみを表示するかを選択できます。選択した項目の、既読と未読の状態を切り替えることもできます。項目を既読としてマークした場合、それはすべてのユーザーに対して行われていることに注意してください。その旨を示す警告が表示されます。

21.5 管理エージェント・ソフトウェアの取得または更新

Enterprise Manager Cloud Controlでサポートされている各種のプラットフォーム(オペレーティング・システム)用の管理エージェント・ソフトウェアは、自己更新コンソールを使用してソフトウェア・ライブラリにダウンロードできます。管理エージェントは、ソフトウェア・ライブラリに保存されると、ホスト・ターゲットの追加ウィザードを使用して、 Cloud Controlが管理するホスト・マシンにインストールできます。

オンラインおよびオフラインの両方のモードで管理エージェント・ソフトウェアを取得する手順は、『Oracle® Enterprise Manager Cloud Control基本インストレーション・ガイド』の管理エージェント・ソフトウェアの前提条件を満たすことに関する説明を参照してください。

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

この章では、Cloud Controlコンソールを使用した新しいソフトウェア・ライブラリの構成方法やソフトウェア・ライブラリのアクセスには様々なユーザーおよび権限が必要になることを説明し、最後にEnterprise Manager Cloud Control環境で既存のソフトウェア・ライブラリを管理する方法について説明します。

注意:
インストーラによって自動的に構成が行われるため、時間と労力を省くことができるように、インストール時に「Oracleソフトウェア・ライブラリの構成」オプションを選択し、ソフトウェア・ライブラリを構成することをお薦めします。詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。
ただし、ソフトウェア・ライブラリをまだ構成していない場合は、この章で説明するとおり、Enterprise Manager Cloud Controlコンソールから構成します。

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

- ソフトウェア・ライブラリの概要

- ユーザー、ロールおよび権限

- ソフトウェア・ライブラリの新機能

- EM CLI動詞またはグラフィカル・モードを使用したソフトウェア・ライブラリ・タスクの実行

- ソフトウェア・ライブラリ記憶域

- ソフトウェア・ライブラリの構成に関する前提条件

- ソフトウェア・ライブラリ記憶域の場所の構成

- 複数OMSシステムでのソフトウェア・ライブラリの構成

- ソフトウェア・ライブラリのキャッシュ・ノード

- ソフトウェア・ライブラリ・ファイルの転送

- ソフトウェア・ライブラリ・エンティティの使用

- ソフトウェア・ライブラリのホームページを使用して実行できるタスク

- ソフトウェア・ライブラリの管理

22.1 ソフトウェア・ライブラリの概要

Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)は、Enterprise Manager Cloud Controlで提供されるコア機能の1つです。これは、技術的には、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなどのソフトウェア・エンティティを格納するリポジトリです。これらを格納する以外に、ソフトウェア・エンティティのバージョン、成熟度レベルおよび状態を管理することもできます。

ソフトウェア・ライブラリのコンソール・ページにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。図22-1に示すように、ソフトウェア・ライブラリのホームページには、Oracle所有のフォルダ(ロック記号が付いている)とユーザー所有のフォルダの2種類があります。

Oracle所有のフォルダとその内容(他のサブフォルダやエンティティ)はデフォルトで製品に付属しており、ソフトウェア・ライブラリを構成すると、ソフトウェア・ライブラリのホームページに表示されます。ユーザー所有のフォルダは、論理的に最上位のフォルダで、ユーザーが作成するエンティティを編成するために作成されます。

図22-1 ソフトウェア・ライブラリ・コンソール

ソフトウェア・ライブラリ・ページを使用すると、Enterprise Managerエンティティの格納が容易になります。次に例を示します。

- プラグイン、コネクタ、DBワークロードなどの自己更新エンティティ。

- ゴールド・イメージ、アプリケーション・アーカイブ、Perl/シェル・スクリプトなどのプロビジョニングおよびパッチ適用のエンティティ。

利点:

- ソフトウェア・ライブラリでは、オンライン・モードおよびオフライン・モードでのパッチ適用およびプロビジョニングがサポートされます。たとえば、データベースのパッチがMy Oracle Supportから直接ダウンロードできない場合、それを別個にダウンロードし、オフライン・デプロイメント用にソフトウェア・ライブラリからステージングできます。

- Enterprise Manager Cloud Control 12c以上では、「参照されるファイルの場所」がサポートされ、組織の既存のインフラストラクチャ(ファイル・サーバー、Webサーバー、ストレージ・システムなど)をソフトウェア・ライブラリで活用できます。

- ソフトウェア・ライブラリにより、実際には組織内のソフトウェア・バイナリまたはディレクティブ・スクリプトを参照するエンティティを論理的なフォルダに編成し、効率的に管理できます。

ソフトウェア・ライブラリ・コンソール・ページで、次のタスクを実行できます。

- ソフトウェア・ライブラリ記憶域を構成します。詳細は、第22.7項「ソフトウェア・ライブラリ記憶域の場所の構成」を参照してください。

- ソフトウェア・ライブラリ・エンティティを作成します。たとえば、汎用コンポーネントやディレクティブの作成などです。

- ソフトウェア・ライブラリ・エンティティを管理します。たとえば、エンティティの表示、編集、削除、検索などです。

22.2 ユーザー、ロールおよび権限

デフォルトでは、ソフトウェア・ライブラリのフォルダとエンティティはすべて製品に付属し、Enterprise Managerのすべてのユーザーが表示できます。権限を細分化することにより、ソフトウェア・ライブラリ内の様々なエンティティに対するアクセスを制御できます。デフォルトでは、管理者にソフトウェア・ライブラリ権限はありません。スーパー管理者が管理者にアクセス権を付与します。

注意:
Windowsホストで、「ソフトウェア・ライブラリ」のエンティティの実行を伴うプロシージャ(ディレクティブ・スクリプトなど)を実行するには、Windowsユーザーに次の権限を付与する必要があります。

- オペレーティング システムの一部として機能

- プロセスのメモリ クォータの増加

- バッチ・ジョブとしてログオンする権限

- プロセス レベル トークンの置き換え

そうではない場合、このプロシージャのディレクティブ手順の実行は失敗することがあります。

ソフトウェア・ライブラリのユーザー・ロールは、大きく次のように分類できます。

- デザイナは、ソフトウェア・ライブラリの設定、エンティティの移行、オペレータへの権限の付与、エンティティの削除などの設計時のタスクを実行する管理者です。彼らは、設計時の作業およびオペレータが実行できる実行時の作業の両方を実行できます。Enterprise Manager Cloud Controlのデザイナには、スーパー管理者のロール、またはソフトウェア・ライブラリのすべてのエンティティを作成およびメンテナンスできるEM_PROVISIONING_DESIGNERロールを付与できます。

- オペレータは、エンティティの削除や成熟度ステータスの変更などの実行時の作業を実行できる管理者です。オペレータには、通常、EM_PROVISIONING_OPERATOR、EM_PATCH_OPERATORなどのロールが付与されます。

Enterprise Managerユーザーがソフトウェア・ライブラリのホームページでエンティティを表示するには、最低限、そのエンティティに対する表示権限が必要です。ユーザーは、少なくともエンティティに対する表示権限がスーパー管理者またはエンティティの所有者から付与されるまで、該当のエンティティを表示することはできません。

注意:
製品に付属し、Oracle所有エンティティとも呼ばれるフォルダとエンティティは、デフォルトでEnterprise Managerのすべてのユーザーがそのすべてを表示できます。

デフォルトでは、管理者にソフトウェア・ライブラリ権限はありません。スーパー管理者が管理者にアクセス権を付与します。表22-1で、ユーザーやロールに付与できるすべてのソフトウェア・ライブラリ権限について説明します。

特定のエンティティに関する権限は、エンティティの所有者またはスーパー管理者によってユーザーとロールに付与できます。詳細は、Oracle Enterprise Managerのソフトウェアとサーバーのプロビジョニングとパッチ適用についての管理者ガイドを参照してください。

表22-1 管理者のソフトウェア・ライブラリ権限

リソース・タイプ

説明

任意のテンプレート・エンティティの表示

テンプレート・エンティティを表示できます。

任意のソフトウェア・ライブラリ・エンティティのエクスポート

ソフトウェア・エンティティをエクスポートできます。

ソフトウェア・ライブラリ・エンティティの編集

任意のソフトウェア・ライブラリ・エンティティを編集する機能

任意のソフトウェア・ライブラリ・エンティティの管理

ソフトウェア・ライブラリ・エンティティを作成、表示、編集、削除できます。

任意のソフトウェア・ライブラリ・エンティティのインポート

ソフトウェア・ライブラリ・エンティティをインポートできます。

任意のソフトウェア・ライブラリ・エンティティの作成

任意のソフトウェア・ライブラリ・エンティティを作成する機能

任意のソフトウェア・ライブラリ・エンティティの表示

任意のソフトウェア・ライブラリ・エンティティを表示する機能

アセンブリ・エンティティの表示

アセンブリ・エンティティを表示できます。

任意のエンティティ権限の付与

ソフトウェア・ライブラリ・エンティティに対する表示、編集、削除権限を付与できます。この権限は、エンティティに対する権限を付与するユーザーがスーパー管理者またはエンティティの所有者以外の場合に必要です。

表22-2で、ソフトウェア・ライブラリのすべてのプライマリ・ユーザーとそのユーザーに関連付けられる権限について説明します。

表22-2 ロールおよび権限

ロール

ソフトウェア・ライブラリ権限

スーパー管理者

すべてのソフトウェア・ライブラリ権限

EM_PROVISIONING_DESIGNER(デザイナ)

任意のソフトウェア・ライブラリ・エンティティの作成

EM_PROVISIONING_OPERATOR(オペレータ)

任意のソフトウェア・ライブラリ・エンティティの表示

EM_PATCH_OPERATOR

任意のソフトウェア・ライブラリ・エンティティの作成

任意のソフトウェア・ライブラリ・エンティティの表示

EM_USER(管理者)

Enterprise Managerへのアクセス

スーパー管理者には、ソフトウェア・ライブラリにあるすべてのエンティティに対する完全な権限があります。スーパー管理者は、別のユーザーやロールに対して1つ以上の権限を付与した後、以前に付与された権限を取り消すことにより、エンティティに対するアクセスを制御できます。

デザイナにはデフォルトで作成権限が付与されるため、エンティティを作成して管理できます。

オペレータにはデフォルトで表示権限が付与されるため、Enterprise Manager Cloud Controlですべてのエンティティを表示できます。

Enterprise Managerユーザーがソフトウェア・ライブラリ・コンソールでエンティティを表示するには、少なくともエンティティに対する表示権限が必要です。スーパー管理者は、表22-1で説明した追加の権限をユーザーやロールに付与できます。ユーザーは、少なくともエンティティに対する表示権限がスーパー管理者から付与されるまで該当のエンティティを表示することはできません。

22.3 ソフトウェア・ライブラリの新機能

Enterprise Manager 12cソフトウェア・ライブラリの拡張については、『Enterprise Manager Cloud Control概要』を参照してください。

22.4 EM CLI動詞またはグラフィカル・モードを使用したソフトウェア・ライブラリ・タスクの実行

Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以上では、コマンドライン・ユーティリティがOracle Enterprise Manager Cloud Controlのソフトウェア・ライブラリ・ユーザー用に導入され、テキスト・ベース・コンソールを使用して、コンソール・ベースのソフトウェア・ライブラリ操作の一部を実行できるようになりました。

次の表で、一部のソフトウェア・ライブラリ・タスクを実行する両方のアプローチについて説明します。

- Enterprise Managerコマンドライン・インタフェース(EM CLI)

- Enterprise Managerグラフィカル・ユーザー・インタフェース(EM GUI)

注意:
表22-3で説明しているEM CLI動詞の構文および使用方法の詳細とワークフローの例は、Oracle Enterprise Manager Lifecycle Management管理者ガイドを参照してください。

表22-3 ソフトウェア・ライブラリEMCLI動詞

説明

アプローチA: EM CLI動詞の使用

アプローチB: Enterprise Manager Cloud Controlコンソールの使用

ソフトウェア・ライブラリ記憶域の場所の追加

add_swlib_storage_location

OMS共有ファイル・システムの場所の構成

OMSエージェント・ファイル・システムの場所の構成

参照されるファイルの場所の構成

ソフトウェア・ライブラリ・エンティティの作成

create_swlib_entity

汎用コンポーネントの作成

ディレクティブの作成

ソフトウェア・ライブラリ・フォルダの作成

create_swlib_folder

エンティティの編成

ソフトウェア・ライブラリ・エンティティのリスト

list_swlib_entities

ソフトウェア・ライブラリ・ホーム・ページへのアクセス

エンティティの検索

ソフトウェア・ライブラリ・エンティティ・タイプのリスト

list_swlib_entity_types

該当なし

ソフトウェア・ライブラリ・エンティティ・サブタイプのリスト

list_swlib_entity_subtypes

該当なし

ソフトウェア・ライブラリ・フォルダのリスト

list_swlib_folders

該当なし

ソフトウェア・ライブラリ・ストレージの場所のリスト

list_swlib_storage_locations

ソフトウェア・ライブラリの管理・ページへのアクセス

ソフトウェア・ライブラリ・エンティティからのファイルの参照

refer_swlib_entity_files

エンティティの作成

エンティティの表示、編集および削除

ソフトウェア・ライブラリ・メタデータの再インポート

reimport_swlib_metadata

Oracle所有エンティティ・ファイルの再インポート

ソフトウェア・ライブラリ記憶域の場所の削除

remove_swlib_storage_location

ソフトウェア・ライブラリ記憶域の場所の削除(および移行)

ソフトウェア・ライブラリ・エンティティの変更

update_swlib_entity

エンティティの表示、編集および削除

ソフトウェア・ライブラリ・エンティティへのファイルのアップロード

upload_swlib_entity_files

エンティティの作成

エンティティの表示、編集および削除

ソフトウェア・ライブラリのOMSエージェント記憶域の場所を変更し、関連付けられたOMSホストおよびこの場所にアクセスするための資格証明を変更します。

switch_swlib_oms_agent_storage

該当なし

ソフトウェア・ライブラリにアップロードされたファイルを確認し、記憶域の場所にないファイルをレポートします。通常、関連付けられた記憶域の場所にファイルが不足していることが原因で、プロビジョニング/パッチ適用/デプロイ・アクティビティが失敗する場合にこの処理が開始されます。

verify_swlib

該当なし

ホスト・ターゲットのファイル・システムの場所に、ソフトウェア・ライブラリで使用可能なエントリ・リビジョンに関連付けられた1つ以上のファイルをステージングします。

stage_swlib_entity_files

エンティティのステージング

EMエージェントによってモニタリングされないホストのローカル・ファイル・システムに、ソフトウェア・ライブラリのエンティティ・リビジョンに関連付けられた1つ以上のファイルをステージングします。

stage_swlib_entity_files_local

エンティティのステージング

ソフトウェア・ライブラリでDirectiveタイプのエンティティを作成します。作成に成功すると、エンティティ・リビジョンがソフトウェア・ライブラリのホームページの指定したフォルダに表示されます。

create_swlib_directive_entity

ディレクティブの作成

ソフトウェア・ライブラリでDirectiveタイプのエンティティを変更します。デフォルトでは、エンティティの新しいリビジョンが作成されます。説明または属性値のみを変更しても新しいリビジョンは作成されず、このような変更はエンティティのすべての既存のリビジョンで表示できます

update_swlib_directive_entity

エンティティの表示、編集および削除

エンティティ・リビジョンのすべての詳細をリストします。

get_swlib_entity_details

エンティティの表示、編集および削除

キャッシュ・ノードにインポートされるソフトウェア・ライブラリ・エンティティのファイルをキャッシュ済ファイルとしてエクスポートします。

export_swlib_cache_files

キャッシュ・ノードのファイルのエクスポートおよびインポート

ソフトウェア・ライブラリのエンティティ・ファイルを圧縮ファイルからキャッシュ・ノードにインポートします。

import_swlib_cache_files

キャッシュ・ノードのファイルのエクスポートおよびインポート

1つまたはすべてのキャッシュ・ノードの再同期化を起動します。

resync_swlib_cache

キャッシュ・ノードの同期

注意:
EM CLI動詞の使用方法の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

22.5 ソフトウェア・ライブラリ記憶域

ソフトウェア・ライブラリ管理コンソールでは、ソフトウェア・ライブラリを構成して管理できます。ソフトウェア・ライブラリの使用を開始するには、OMSが実行されているホストで、少なくとも1つのアップロード・ファイル記憶域の場所(OMS共有ファイル・システムまたはOMSエージェント・ファイル・システム)を追加する必要があります。ソフトウェア・ライブラリ記憶域の場所は、ファイルのリポジトリを表し、これらのファイルは、ソフトウェア・ライブラリにアップロードされるか、ソフトウェア・ライブラリによって参照されます。

注意:
OMS共有記憶域の場所を新しく構成する場合、場所に指定するファイルシステム・パスは共有パスまたはマウント済のパスのいずれかであることを確認します。そうすることで、新しく構成された場所は今後、複数OMS環境からアクセス可能になります。新しい場所が複数OMS環境に追加されると、ファイルシステム・パスはすべてのOMSホストからアクセス可能になります。
ただし、ローカルのファイルシステムにOMS共有記憶域の場所を構成した場合、第22.7項にリストしている手順を実行して、この場所を、共有またはマウント済パスのある別のOMS共有記憶域の場所に移行する必要があります。

管理コンソールにアクセスするには、管理アクセスでEnterprise Manager Cloud Controlにログインして次の手順を実行します。

Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

または

Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。「ソフトウェア・ライブラリ」ホームページで、「アクション」メニューから「管理」を選択します。

「ソフトウェア・ライブラリ管理」ページは、GUIベースの画面で、エンティティに関連付けられたファイルを格納または参照する記憶域の場所を1つ以上作成できます。記憶域の場所にあるエンティティを表示するには、「管理」ページで「表示」をクリックします。OMS、またはOMSと同じホストで実行するエージェント上に記憶域の場所を作成できます。Enterprise Manager 12cの場合、参照されるファイルの場所と呼ばれる新機能が導入され、ソフトウェア・ライブラリ・エンティティは、別のホストに格納されているファイルを参照できます。ただし、これらの場所は、ソフトウェア・ライブラリの読取り専用であり、ファイルのアップロードには使用されません。

ソフトウェア・ライブラリを構成する領域要件は、ソフトウェア・バイナリやその関連スクリプトの格納に必要な領域によって異なります。時間が経過し、作成したエンティティが増えれば、この領域要件が増えることは言うまでもありません。プロビジョニングとパッチに必要な機能またはソフトウェアに応じて、ソフトウェア・ライブラリの記憶域の領域を決定し、構成する必要があります。

注意:
本番環境では、ソフトウェア・ライブラリの記憶域に最低100GBを割り当てることをお薦めします。または、今後、領域不足で実行し始めたら、この記憶域を容易に拡張できるようにしてください。
記憶域の場所の領域が不足し始めたら、構成されている記憶域の場所を非アクティブにし、この場所でこれ以上アップロードが行われないようにすることが重要です。記憶域の場所の削除の詳細は、第22.13項を参照してください。

利用可能な記憶域は次のとおりです。

- アップロード・ファイルの場所

- 参照先ファイルの場所

- キャッシュ・ノード

22.5.1 アップロード・ファイルの場所

アップロード・ファイルの場所は、エンティティの作成または更新の一環としてソフトウェア・ライブラリによってアップロードされたファイルを格納するために構成された場所です。

ソフトウェア・ライブラリを使用可能にするには、少なくとも1つのアップロード・ファイルの場所が構成されている必要があります。初めてアップロード・ファイルの場所を追加するときに、インストール済の各Enterprise ManagerプラグインのOracleホームからソフトウェア・ライブラリ・メタデータをインポートするジョブが発行されます。このジョブが正常に完了するのを待ってから、他のパッチ適用操作やプロビジョニング操作を行います。

注意:
ソフトウェア・ライブラリでアップロード記憶域の場所として構成されたファイル・システムを物理的に削除するには、最初に、既存のコンテンツ(エンティティ)を移行できる別の記憶域の場所を構成する必要があります。この移行の実行に失敗すると、この場所からのファイルに依存するエンティティは使用不可にレンダリングされます。記憶域の場所の削除とコンテンツの移行の詳細は、第22.13.3項を参照してください。

前提条件

アップロード・ファイルの場所を記憶域のオプションとして使用する前に、前提条件として、OMS共有ファイル・システムまたはOMSエージェント・ファイル・システムを使用するための資格証明を設定する必要があります。

- 複数のOMS環境の場合、すべてのOMSホストに優先通常ホスト資格証明を設定する必要があります。
OMSインスタンスが追加された場合、新しいOMSがプロビジョニングされる指定のホストから、構成された場所にアクセスできるようにする必要があります。管理サービス追加機能を使用してプロビジョニングされるOMSの場合、アップロード場所として構成された共有場所を指定のホストにマウントして、手動で検証する必要があります。

- OMSエージェント・ファイル・システムの場所の構成の場合、資格証明(優先または名前付き)を指定する必要があります。

アップロード・ファイルの場所は、次のように2つの記憶域オプションをサポートしています。

OMS共有ファイル・システム(推奨記憶域オプション)

OMS共有ファイル・システムの場所は、すべてのOracle Management Server(OMS)ホスト間で共有(またはマウント)されている必要があります。このオプションはUNIXシステムに最適です。

注意:
オラクル社は、ソフトウェア・ライブラリにアップロードしたファイルの保管に、OMS共有ファイル・システムの使用をお薦めします。しかし、なんらかの制約で共有ファイル・システムを設定できない場合は、OMSエージェント・ファイル・システムを使用できます。詳細は、「OMSエージェント・ファイル・システム」を参照してください

OMS環境が1つの場合、ソフトウェア・ライブラリはOMSが実行されているホスト上にも、共有場所にも構成できます。ただし、今後、1つのOMS設定を複数のOMS設定に拡張する計画がある場合は、ローカル・ファイル・システムのパスはお薦めしません。

注意:
複数OMSシナリオでは、NFS、ACFSまたはDBFSを使用してクラスタ・ファイル・システムを設定する必要があります。Windowsでは、共有についてOCFS2クラスタ・ファイル・システムが推奨されています。

高可用性のために複数の管理サーバーを実装している場合は、ソフトウェア・ライブラリのファイル・システムも高可用にします。アクセシビリティおよび可用性の他にも、ソフトウェア・バイナリの記憶域として十分な領域が使用可能であること(Enterprise Managerの本番デプロイ用に100GB以上)と、作成および格納するエンティティに関連付けられたスクリプトがあることを確認することが重要です。

OMSエージェント・ファイル・システム

OMSエージェント・ファイル・システムの場所は、OMSがデプロイされるホスト・マシンで実行するエージェントにアクセスできる必要があります。OMSエージェント・ファイル・システム記憶域のオプションを使用するには、OMSホストの優先または指定の資格証明があることを確認します。「資格証明の変更」をクリックして、この場所へのアクセスに使用される関連資格証明を変更します。

注意:
なんらかの制約のために格納にOMS共有ファイル・システムを設定できない場合は、OMSエージェント・ファイル・システムを使用できます。

22.5.2 参照先ファイルの場所

参照先ファイルの場所は、ソフトウェアのバイナリやスクリプトを保護するために組織の既存のITインフラストラクチャ(ファイル・サーバー、Webサーバーまたは記憶域システムなど)を活用できる場所です。このような場所を使用すると、エンティティはソフトウェア・ライブラリ記憶域にファイルを明示的にアップロードしなくてもそのファイルを参照できます。

参照先ファイルの場所は、3つの記憶域オプションをサポートしています。

- HTTP: HTTP記憶域の場所は、参照可能なファイルのソースとして機能するベースURLを表します。
たとえば、ベースURL http://my.files.com/scriptsは、http://my.files.com/scripts/perl/installMyDB.plまたはhttp://my.files.com/scripts/linux/stopMyDB.shなどのソース・ファイルのHTTPの場所として構成できます。

- NFS: NFS記憶域の場所は、サーバー上でエクスポートされたファイルシステム・ディレクトリを表します。サーバーはEnterprise Managerホスト・ターゲットである必要はありません。
たとえば、サーバーmy.file.server上でエクスポートされたディレクトリ/exported/scriptsは、ターゲット・ホスト・ファイルシステムでマウントされた後、/exported/scripts/generic/installMyDB.plまたは/exported/scripts/linux/stopMyDB.shなどのソース・ファイルのNFSの場所として構成できます。

- エージェント: エージェント記憶域の場所は、OMSエージェント・ファイル・システムのオプションと似ていますが、Enterprise Managerエージェントによって監視される任意のホストに設定できます。エージェントは、このホスト上にあるファイルを処理するよう構成できます。
たとえば、Enterprise Managerホストmy.em.file.server上にあるディレクトリ/u01/binariesは、/u01/binaries/rpms/myCustomDB.rpmまたは/u01/binaries/templates/myTemplate.tar.gzなどのソース・ファイルのエージェントの場所として構成できます。

これらの場所には、Enterprise Managerエージェントを介してホスト上のベースの場所からファイルにアクセスするために使用される名前付き資格証明を関連付ける必要があります。

注意:
場所のファイルを参照するエンティティを使用するには、その場所に関連付けられた資格証明で表示権限を持っている必要があります。

22.5.3 キャッシュ・ノード

キャッシュ・ノードは、OMSに対するロードを削減することで、遠距離のサーバーやデータ・センターへのファイル転送操作を拡張するEnterprise Managerの機能です。キャッシュ・ノードは、グループと呼ばれる1つの単位として機能する一連の事前設定済ターゲットで実行します。各キャッシュ・ノードは、関連付けられている特定のターゲット・グループが稼働するホスト上の中間記憶域の場所です。キャッシュ・ノードの詳細は、第22.9.1項を参照してください

22.6 ソフトウェア・ライブラリの構成に関する前提条件

様々な種類の記憶域を管理してソフトウェア・ライブラリを構成するには、次の点に留意します。

- プロビジョニングとパッチに必要な機能またはソフトウェアに応じて、ソフトウェア・ライブラリの記憶域の領域を決定し、構成する必要があります。 記憶域は、使用するパターンに基づく変更が必要です。

- 各OMSホストには、場所を構成する前に通常の優先ホスト資格証明を設定する必要があります。OMSエージェント・ファイル・システムの場所の構成の場合、資格証明(優先または名前付き)を指定する必要があります。

- ソフトウェア・ライブラリを構成するユーザーには、すべてのOMS、およびホスト・マシンで実行しているエージェント・ターゲットに対する表示権限が必要です。アクセシビリティの検証に従って、これらの新しく構成した場所を表示および編集できる必要があります。

- OMSエージェント記憶域の場所を追加するには、ターゲットのOMSホストの表示権限を持っていること、およびターゲット・ホストでエージェントが実行中であることを確認します。

22.7 ソフトウェア・ライブラリ記憶域の場所の構成

システム管理者が、記憶域の場所を構成します。記憶域の場所を構成しないと、エンティティ・ファイルのアップロードは開始できません。

注意:
オンプレミスCloudの設定によっては、デプロイメント・プロシージャや地域固有のジョブのために、ソフトウェア・ライブラリのコンポーネントやディレクティブのようなエンティティが、Oracle Public Cloud (OPC)ターゲットを管理するために使用されることがあります。OPCターゲットがプロシージャによって正常に管理されるように、ソフトウェア・ライブラリにアップロードされたファイルがOMS共有ファイル・システム記憶域に格納されるようにライブラリを構成してください。こうしたコンポーネントやディレクティブがOMSエージェント・ファイル・システム記憶域に格納されていると、これらのファイルがOPCターゲットへ転送される際にプロシージャが失敗します。

次のいずれかの場所にソフトウェア・ライブラリを構成できます。

- OMS共有ファイル・システムの場所の構成

- OMSエージェント・ファイル・システムの場所の構成

- 参照されるファイルの場所の構成

注意:
Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以上では、この項で説明しているGUIの使用に加えて、かわりにコマンドライン・インタフェース・ツールを使用してソフトウェア・ライブラリを構成できます。これを行うには、『Oracle Enterprise Manager Lifecycle Management管理者ガイド』を参照してください。

22.7.1 OMS共有ファイル・システムの場所の構成

ソフトウェア・ライブラリ・エンティティ・ファイルのアップロードに使用できるOMS共有ファイルシステム記憶域の場所を構成するには、次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ: 管理」ページで、「OMS共有ファイルシステム」を選択します。

3. 新しいOMS共有ファイルシステムを追加するには、「+」(追加)をクリックします。

4. 「OMS共有ファイルシステムの場所の追加」ダイアログ・ボックスで、アップロード場所を設定する、OMSホスト上の一意の名前、ホスト名および場所を指定します。

資格証明の指定はオプションです。指定した場合、それがファイル転送に使用されます。

構成済の記憶域の場所が、すべてのOMSインスタンスからアクセスできる共有場所であることを確認してください。マルチOMS設定の場合、すべてのOMSに対して通常優先資格証明を設定します。

アップロード場所を初めて構成する場合、メタデータ登録ジョブが発行され、OMSのOracleホームからインストール済のすべてのプラグインのメタデータ情報がすべてインポートされます。

ジョブの進行状況を追跡するには、「詳細な結果の表示」をクリックします。通常、ジョブの名前はSWLIBREGISTERMETADATA_*で始まります。

インポート・ジョブが失敗した場合、Oracle所有ファイルのメタデータの再インポートについては、第22.13項を参照してください。

5. 「OK」をクリックすると、「名前」、「場所」、「ホスト」、「ステータス」、「ホスト資格証明」などの詳細を使用して、記憶域の場所の新しいエントリが表に作成されます。
これ以外に、「関連エンティティ」をクリックして、選択したアップロードの場所にあるエンティティの表示または検索を行うことができます。

22.7.2 OMSエージェント・ファイル・システムの場所の構成

注意:
推奨記憶域オプションであるOMS共有ファイル・システムをなんらかの制約のために設定できない場合のみ、OMSエージェント・ファイル・システムを設定する必要があります。詳細は、22.5.1項を参照してください。

OMSエージェントの場所を構成するには、次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ: 管理」ページで、「OMSエージェント・ファイル・システム」を選択します。

3. 「OMSエージェント・ファイルシステムの場所の追加」ダイアログ・ボックスで「+」(追加)をクリックし、次の詳細を指定します。

1. 「名前」フィールドに、記憶域の一意な名前を入力します。

2. 「ホスト」フィールドで、虫眼鏡アイコンをクリックします。「検索と選択: ホスト」ダイアログ・ボックスで、OMSが実行しているホストを選択して、「選択」をクリックします。
たとえば、xyz.acme.comのようにします

3. 「場所」フィールドで、虫眼鏡アイコンをクリックします。「リモート・ファイル・ブラウザ」ダイアログ・ボックスで、「次のユーザーでログイン」をクリックして、優先、指定、または新規資格証明でホスト・マシンにログインします。

注意:
ユーザーが正常にOMSエージェント・ファイル・システムのアップロード場所にアクセスして利用するために、名前付き資格証明(基本的に、ホスト・マシンに接続するのに使用する資格証明)の所有者は、このOMSエージェント・ファイル・システムの場所にアクセスするすべての管理者(またはユーザー)に、選択した資格証明の表示権限を付与する必要があります。
名前付き資格証明の権限の付与に関する詳細は、Oracle Enterprise Managerライフサイクル管理管理者ガイドを参照してください。

エージェント・ファイル・システムを作成するホストの場所にナビゲートして、「OK」をクリックします。

選択した資格証明が、ホストおよび選択したファイル・システムのパスとともに保存されます。保存した資格証明は、プロビジョニングまたはパッチ適用操作の一環としてファイルをアップロードするときや、アップロードしたファイルをホスト・ターゲットにステージングするときに使用されます。

注意: 資格証明は、SWLIBで始まる生成名の付いた資格証明を所有するシステムにコピーされます。これは、資格証明の編集フローで元の資格証明の名前として表示されます。

4. 「OK」をクリックすると、「名前」、「場所」、「ホスト」、「ステータス」、「ホスト資格証明」などの詳細を使用して、記憶域の場所の新しいエントリが表に作成されます。
これ以外に、「関連エンティティ」をクリックして、選択したアップロードの場所にあるエンティティの表示または検索を行うことができます。

これで、新しく構成されたこれらのOMSエージェントの場所を使用してエンティティ・ファイル格納できるようになります。

22.7.3 参照されるファイルの場所の構成

ソフトウェア・ライブラリ・エンティティからファイルを参照するために使用できる記憶域の場所を構成するには、次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリ: 管理ページで、「参照されるファイルの場所」をクリックします。

3. HTTP URLを介してアクセスできるHTTPの場所を追加するには、「記憶域のタイプ」リストから「HTTP」を選択し、「+」(追加)をクリックします。

「HTTPの場所の追加」ダイアログ・ボックスで、参照する記憶域の一意な名前と、HTTPの場所を入力し、「OK」をクリックします。

「名前」、「場所」、「ステータス」などの詳細を使用して、記憶域の場所の新しいエントリが作成されます。

4. NFSの場所を追加する場合は、「記憶域のタイプ」リストから「NFS」を選択し、「+」(追加)をクリックします。

「NFSの場所の追加」ダイアログ・ボックスで、次の操作を行います。

1. 「名前」フィールドに、記憶域の一意な名前を入力します。

2. 「NFSサーバー」フィールドに、NFSサービスが実行されているホスト先マシンの完全修飾ドメイン名またはIPアドレスを入力します。

3. 「場所」フィールドに、NFSサーバー上の共有場所またはディレクトリ・パスを入力して記憶域の場所を定義し、「OK」をクリックします。

「名前」、「場所」、「ステータス」などの詳細を使用して、記憶域の場所の新しいエントリが作成されます。

注意:
プロシージャの作成中に、NFSファイルの場所を参照するコンポーネント・ステップまたはディレクティブ・ステップがある場合、プロシージャの実行を発行する前に、ターゲット・ホストの特権優先資格証明を設定する必要があります。

5. 読取り専用権限が設定されたエージェントの場所を追加する場合は、「記憶域のタイプ」リストから「エージェント」を選択し、「+」(追加)をクリックします。

エージェントの場所の追加ダイアログ・ボックスで、次の詳細を入力します。

1. 「名前」フィールドに、記憶域の一意な名前を入力します。

2. 「ホスト」フィールドで、拡大鏡アイコンをクリックし、使用可能なリストからターゲットを選択します。
例: xyz.company.com

3. 「場所」フィールドで「次のユーザーでログイン」をクリックし、資格証明を選択して、以前に選択したホストを参照します。
選択した資格証明(優先、名前付き、新規)が、ホスト値および選択したファイルシステムのパスとともに保存されます。保存した資格証明は、プロビジョニングまたはパッチ適用操作の一環としてファイルをホスト・ターゲットにステージングするときに使用されます。

注意: ソフトウェア・ライブラリを構成している管理者は、この場所に対してファイルのアップロードまたはステージングを行うすべてのデザイナに、選択した資格証明に対する表示権限(最低でも)を付与する必要があります。

注意: 新規エンティティを作成すると、新しく構成されたこれらの参照先ファイルの場所が記憶域オプションとして使用可能になります。

22.8 複数OMSシステムでのソフトウェア・ライブラリの構成

共有またはマウント済ファイルシステム・パスを使用するには、各OMS共有記憶域の場所を構成することをお薦めします。これを行うことで、新しく構成された場所は、追加されたどのOMSホストからも、引き続きアクセスできるようになります。ファイルに対するすべてのアップロードおよびステージング・リクエストは、OMSホストを監視する管理エージェントを介して発生します。

注意:
Enterprise Manager 12c以上では、異なる記憶域タイプのアップロードの場所間でファイルを移行するために、EM CLIユーティリティを使用します。OMS共有記憶域の場所からOMSエージェント記憶域の場所にファイルを移行するには、EM CLI動詞remove_swlib_storage_locationを使用します。同じ動詞で、逆の処理もできます。または、Cloud Control UIを使用することもできます。Cloud Controlを使用した記憶域の場所間の移行については、第22.13.3項を参照してください。

しかし、ローカルのファイル・システム・パスを使用するようにOMS共有記憶域の場所を構成した場合、共有またはマウント済パスを使用する別のOMS共有記憶域の場所に移行する必要があります。次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリ管理ページで、名前(例: NewShared)と共有ファイルシステム・パスを指定して、新しいOMS共有記憶域の場所を追加します。

3. 正常に完了すると、移行する場所を選択し(例: OldNonShared)、「移行と削除」をクリックします。

4. ポップアップ・ダイアログ・ボックスで、記憶域プラグイン・タイプとして新しいOMS共有ファイル・システムを選択し、ファイルの移行先として新しいOMS共有記憶域の場所(NewShared)を選択します。

5. 「削除」をクリックしてジョブを発行します。このジョブが成功すると、記憶域の場所のエントリが表から削除されます。

22.9 ソフトウェア・ライブラリのキャッシュ・ノード

Oracle Enterprise Manger Cloud Control 13c R1には、ターゲット・グループへの距離が近い、1つ以上のキャッシュ・ノードを構成するためのサポートが導入されています。構成すると、ソフトウェア・ライブラリ・ファイルの転送ジョブで、エンティティ・ファイルが適切なキャッシュ・ノードから取得され、必要に応じてエンティティ・ファイルがキャッシュされるため、Oracle Management Serviceから距離の離れたターゲットへのファイル転送にかかる時間が短縮されます。

22.9.1 キャッシュ・ノードの構成

キャッシュ・ノードは、OMSに対するロードを削減することで、遠距離のサーバーやデータ・センターへのファイル転送操作を拡張するEnterprise Managerの機能です。キャッシュ・ノードは、グループと呼ばれる1つの単位として機能する一連の事前設定済ターゲットで実行します。各キャッシュ・ノードは、関連付けられている特定のターゲット・グループが稼働するホスト上の中間記憶域の場所です。

通常は、地理的に同じ場所にあるターゲットを含むグループを作成するとメリットがあります。これらのターゲットの近さによって効率的なファイル転送が保証されます。キャッシュ・ノードの使用は、OMSに対する負荷の軽減にも大きなメリットがあります。たとえば、100個のターゲットに同時にパッチ適用を行うと、OMSはファイル転送を100個のターゲットそれぞれと調整する必要があるため、OMSに対して莫大な負荷がかかります。ただし、OMSがファイルをキャッシュ・ノードに1回転送すれば済むようにキャッシュ・ノードを使用することでこれに対処できます。その後、キャッシュ・ノードが、対応するグループ内の個々のターゲットへのファイル転送を処理します。所定のターゲット・グループを複数のキャッシュ・ノードにリンクできることに注意してください。このアプローチを利用すると、負荷がノード間で均等に分散されるようになり、関連するグループの個々のキャッシュ・ノードのパフォーマンスを最大化することができます。

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

- キャッシュ・ノードの追加

- キャッシュ・ノードの編集

- キャッシュ・ノードの削除

- キャッシュ・ノードのアクティブ化または非アクティブ化

- キャッシュ・ノードのクリア

- キャッシュ・ノードの同期

22.9.1.1 キャッシュ・ノードの追加

注意:
資格証明は、SWLIBで始まる生成名の付いた資格証明を所有するシステムにコピーされます。これは、資格証明の編集フローで元の資格証明の名前として表示されます。

キャッシュ・ノードの追加を開始する前に、対応するキャッシュ・ノードに関連付けるターゲット・グループをあらかじめ作成しておく必要があります。グループの作成方法の詳細は、グループ・ページを参照してください。

キャッシュ・ノードを追加するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリ管理ページで「キャッシュ・ノード」を選択します。

3. 「キャッシュ・ノード」タブで「追加」をクリックします。

4. 「キャッシュ・ノードの追加」ダイアログ・ボックスで、次の詳細を入力します。

1. キャッシュ・ノードの表示名を入力します。たとえば、「Austin Nodes」とします。

2. 自分の参考用にキャッシュ・ノードの簡単な説明を追加します。たとえば、「these are the targets on different hosts restricted to Austin, U.S.A.」とします。

3. キャッシュ・ノードとして使用されるホスト・ターゲット・マシンを指定します。たとえば、slc01.example.comです。

4. OMSから転送されるファイルを格納するホスト上の場所を指定します。このディレクトリはサーバーにすでに存在し、空であることが必要です。たとえば、/usr/cachenodesです

5. キャッシュ・ノードに関連付けるグループを検索して選択します。たとえば、「Austin Group」です。

6. デフォルトの割当ては10 GBです。この値を変更して、要件に合せてカスタマイズできます。

5. 「OK」をクリックすると、指定したグループに追加されたターゲットに対応するキャッシュ・ノードが作成されます。
ノードが正常に作成されると、使用可能なディスク領域、ファイル転送履歴およびキャッシュ・ノードの情報のサマリーが表示されます。

キャッシュ・ノードが正常に作成されたら、「表示」をクリックして、グループ内のターゲットに関連付けられたすべてのエンティティを表示できます。また、グループ名をクリックするとグループの詳細も表示できます。

22.9.1.2 キャッシュ・ノードの編集

キャッシュ・ノードを編集するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリ管理ページで「キャッシュ・ノード」を選択します。

3. 「キャッシュ・ノード」タブで、更新するキャッシュ・ノードを選択して「編集」をクリックします。これが特に役立つのは、キャッシュに関連付けられているグループを変更する場合または割当ての詳細を更新する場合です。

4. 「OK」をクリックすると変更が反映されます。

22.9.1.3 キャッシュ・ノードの削除

キャッシュを削除するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリ管理ページで「キャッシュ・ノード」を選択します。

3. 「キャッシュ・ノード」タブで、1つ以上のキャッシュ・ノードを選択して「削除」をクリックします。

22.9.1.4 キャッシュ・ノードのアクティブ化または非アクティブ化

特定のキャッシュ・ノードの機能を一時的に停止する場合は、「非アクティブ化」をクリックします。通常、割当てが一杯になったとき、またはキャッシュ・ノードのメンテナンス・タスクを実行する必要があるときに、このオプションが役立ちます。

キャッシュ・ノードを非アクティブ化するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリ管理ページで「キャッシュ・ノード」を選択します。

3. 「キャッシュ・ノード」タブで、キャッシュ・ノードを選択して「非アクティブ化」をクリックします。

22.9.1.5 キャッシュ・ノードのクリア

割当てを解放するためにキャッシュ・ノードに関連付けられているすべてのファイルを削除する場合は、「クリア」をクリックします。

キャッシュ・ノードをクリアするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリ管理ページで「キャッシュ・ノード」を選択します。

3. 「キャッシュ・ノード」タブで、キャッシュ・ノードを選択して「クリア」をクリックします。

22.9.1.6 キャッシュ・ノードの同期

キャッシュ・ノード間の不一致を特定してクリーンアップするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリ管理ページで「キャッシュ・ノード」を選択します。

3. 「キャッシュ・ノード」タブで、キャッシュ・ノードを選択して「再同期化」をクリックします。

22.9.2 キャッシュ・ノードのファイルのエクスポートおよびインポート

EM CLI動詞は、ソフトウェア・ライブラリ・エンティティのファイルを圧縮ファイルにエクスポートするために使用できます。これらの圧縮ファイルは、キャッシュ・ノード・ホストに転送してキャッシュ・ノードにインポートできます。ソフトウェア・ライブラリ・エンティティがキャッシュ・ノードの提供するグループの1つ以上のターゲットにステージングされる場合、ファイルはOMSのかわりにキャッシュ・ノードから直接提供されます。

22.9.2.1 エクスポート

1行に1つのソフトウェア・ライブラリ・エンティティの内部IDを付けて、ファイルを作成します。エンティティの内部IDは、emcli動詞list_swlib_entitiesで確認できます。次の例では、file /u01/urnfeがこのようなファイルです。このファイルの行で表されたエンティティのファイルは、EMユーザーADMIN1が所有するcreds1という名前の資格証明を使用して、ホストsyq.acme.comの/u01/exportcache/cachefiles.zipとしてエクスポートされます。

emcli export_swlib_cache_files -dest_dir_path=/u01/exportcache -zip_file_name=cachefiles.zip -dest_host_name=syq.acme.com -urn_file_entry_file="/u01/urnfe" -dest_host_tmp_dir=/tmp -credential_name=creds1 -credential_owner=ADMIN1

エクスポートされたcachefiles.zipファイルは、skx.af.acme.comのような、指定した宛先キャッシュ・ノードに取り込むことができます。

22.9.2.2 インポート

次のemcli動詞を使用してzipファイルをキャッシュ・ノードにインポートできます。emcli import_swlib_cache_files -src_dir_path=/u01/cachefiles -zip_file_name=cachefiles.zip -cache_node_name=afcachenode -src_host_tmp_dir=/tmp -src_host_name=skx.af.acme.com

キャッシュ・ノードに関連付けられた資格証明は、インポートの実行に使用されます。

詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』ガイドを参照してください。

22.10 ソフトウェア・ライブラリ・ファイルの転送

異なるプロビジョニング/パッチ適用プロシージャ/ジョブ実行の一部として発行されるソフトウェア・ライブラリ・ファイルの転送ジョブは、「ファイル転送アクティビティ」ページから検索および表示できます。

「ファイル転送アクティビティ」ページ

「ファイル転送アクティビティ」ページでは、ソフトウェア・ライブラリに関連するファイル転送を追跡できます。

このページにアクセスするには、Enterprise Manager Cloud Controlにログインし、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択して「ソフトウェア・ライブラリ」をクリックします。ソフトウェア・ライブラリのホームページで、「アクション」メニューから「ファイル転送アクティビティ」を選択します。

このページの表には、最近実行されたすべてのファイル転送アクティビティが表示されます。「ジョブ名」列にはファイル転送アクティビティが実行されたジョブが表示され、ジョブがデプロイメント・プロシージャ内で実行された場合は「プロシージャ実行名」列にデプロイメント・プロシージャ実行名が表示されます。これらの列の両方を使用して、ファイル転送アクティビティを識別できます。

22.11 ソフトウェア・ライブラリ・エンティティの使用

Cloud Controlでソフトウェア・ライブラリのホームページにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。ソフトウェア・ライブラリは、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなど、通常はエンティティと呼ばれる認証済ソフトウェア・バイナリを格納するリポジトリです。これらのエンティティに対するアクセスや権限は、スーパー管理者またはエンティティの所有者が決定します。

エンティティは、大きく次のように分類できます。

タイプ

説明

Oracle所有エンティティ

このエンティティは、ソフトウェア・ライブラリが構成されていれば、デフォルトでソフトウェア・ライブラリのホームページで使用できます。次の図で、所有者がOracleのすべてのエンティティはOracle所有エンティティであり、Application Server Provisioning、Bare Metal Provisioning、Cloudなど、ロックのアイコン付きで表示されるすべてのフォルダはOracle所有のフォルダです。

カスタム・エンティティ

このエンティティは、ソフトウェア・ライブラリのユーザーによって作成されます。たとえば、次の図にはMy Entitiesというカスタム・フォルダがあり、エンティティの所有者によって作成されたos2およびos1というエンティティがあります。これらのエンティティはユーザー所有のエンティティと呼ばれます。

注意:
すべてのOracle所有フォルダ(およびエンティティ)は、デフォルトでソフトウェア・ライブラリのホームページで使用できます。Oracle所有フォルダは読取り専用のため、これらのフォルダを選択してエンティティは作成できません。エンティティを格納するカスタム・フォルダを作成する必要があります。

パッチ適用、デプロイメント・プロシージャのプロビジョニングなどの多くのライフサイクル管理タスクでは、ソフトウェア・ライブラリで使用可能なエンティティを利用して目的を達成できます。次の図は、デプロイメント・プロシージャのプロビジョニングおよびデプロイメント・プロシージャのパッチ適用で、ソフトウェア・ライブラリで使用可能なエンティティを利用する方法を示したものです。

図22-2 プロビジョニングおよびパッチ適用タスクにおけるソフトウェア・ライブラリのエンティティの使用

22.12 ソフトウェア・ライブラリのホームページを使用して実行できるタスク

ソフトウェア・ライブラリのホームページで、次のタスクを実行できます。

- エンティティの編成

- エンティティの作成

- エンティティのカスタマイズ

- エンティティの管理

- エンティティのステージング

22.12.1 エンティティの編成

ソフトウェア・ライブラリ・エンティティを作成する権限のあるデザイナのみがフォルダを作成できます。

注意:
Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以上では、この項で説明しているGUIの使用に加えて、かわりにコマンドライン・インタフェース・ツールを使用してフォルダを作成できます。これを行うには、『Oracle Enterprise Manager Lifecycle Management管理者ガイド』を参照してください。

カスタム・フォルダを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、「アクション」メニューの「フォルダの作成」をクリックし、カスタム・フォルダを作成します。
カスタム・フォルダには、ユーザー所有のフォルダ、エンティティ、および「類似作成」オプションを使用して作成したカスタマイズ済エンティティを格納できます。

3. 「フォルダの作成」ダイアログ・ボックスで、フォルダの一意な名前を入力します。また、この新しいカスタム・フォルダの上位になる親フォルダを選択し、「保存」をクリックします。
たとえば、Software Libraryをルート・フォルダとしてCloud12gTestというカスタム・フォルダを作成する場合、「親フォルダ」フィールドには/Software Library/Cloud12gTestという名前が移入されます。

注意: フォルダを削除する権限を持つのはフォルダの所有者またはスーパー管理者のみであり、他のユーザーが削除することはできません。

22.12.2 エンティティの作成

ソフトウェア・ライブラリのホームページで、次のエンティティを作成できます。

- 汎用コンポーネントの作成

- ディレクティブの作成

注意:
Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以上では、この項で説明しているGUIの使用に加えて、かわりにコマンドライン・インタフェース・ツールを使用してエンティティを作成できます。これを行うには、『Oracle Enterprise Manager Lifecycle Management管理者ガイド』を参照してください。

22.12.2.1 汎用コンポーネントの作成

ソフトウェア・ライブラリのホームページから汎用コンポーネントを作成する手順:

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、Oracle所有ではないカスタム・フォルダを選択します。
注意: Oracle所有フォルダには汎用コンポーネントを作成できません。カスタム・フォルダの作成については、第22.12.1項を参照してください。

3. 「アクション」メニューから「エンティティの作成」を選択し、「コンポーネント」をクリックします。または、カスタム・フォルダを右クリックして、メニューから「エンティティの作成」を選択して「コンポーネント」をクリックします。

4. 「エンティティの作成: コンポーネント」ダイアログ・ボックスから「汎用コンポーネント」を選択し、「続行」をクリックします。
Enterprise Manager Cloud Controlに、汎用コンポーネントの作成: 説明ページが表示されます。

5. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

「+」(追加)をクリックして、README、付帯状況、ライセンスなど、そのエンティティを適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡する変更履歴など、エンティティに関連する情報を追加します。

6. 構成ページで、新しいプロパティを追加するかコンポーネントの既存のプロパティを更新して、汎用コンポーネントをカスタマイズできます。
注意: コンポーネントのプロパティを再利用するには、「共有タイプ」を選択します。共有タイプはテンプレートとして格納でき、それを使用して別の複雑なトップ・レベルのタイプできます。

新しいプロパティを追加するには、次の操作を行ってから「次へ」をクリックします。

1. 「トップ・レベル・タイプ」または「共有タイプ」を選択し、「追加」をクリックします。

2. プロパティの一意の名前を入力します。選択したプロパティ・タイプに応じて、プロパティの初期値またはデフォルト値を入力します。

3. 制約を追加するには、選択したプロパティ・タイプに「最小」または「最大」値を指定し、「制約の追加」をクリックします。
「構成済の制約」表に、追加したすべての制約がリストされます。プロパティから特定の制約を削除するには、そのプロパティを選択して「削除」をクリックします。

7. ファイルの選択ページで、エンティティに関連付ける1つ以上のファイルを選択できます。次のいずれかのオプションを選択します。

- ファイルのアップロード: 一部のエンティティ・ファイルをローカルのファイル・システムまたはエージェント・マシンから、選択した宛先の場所にアップロードするとき。
宛先の場所を選択するには、「宛先の指定」セクションの「アップロード場所」フィールドで、拡大鏡アイコンをクリックして次のオプションの1つを選択します。

- OMS共有ファイル・システム

- OMSエージェント・ファイル・システム

選択した場所に対応する記憶域のタイプおよび場所のパスが移入されます。

注意:
ファイルをアップロードするには、アップロード先の記憶域の場所のステータスが「アクティブ」であることが必要です。
OMSエージェント・ファイル・システムの場所を選択する場合は、その場所へのアクセスに必要な権限があることを確認してください

「ソースの指定」セクションで、ソースとなるファイルの場所として、ローカルのファイル・システム、または管理エージェントによって監視されているリモートのファイル・システムのいずれかを入力します。ファイル・ソースとして、次のいずれかを選択します。

- ローカル・マシンを選択する場合は、「追加」をクリックすると、「ファイルの追加」ダイアログ・ボックスが表示されます。「参照」をクリックしてソースの場所からエンティティ・ファイルを選択し、一意の名前を付けて「OK」をクリックします。
OMS共有ファイル・システムまたはOMSエージェント・ファイル・システムで構成されている任意の記憶域の場所にファイルをアップロードできます

- エージェント・マシンを選択する場合は、エンティティ・ファイルを選択するホスト・マシンの名前を選択します。「+」(追加)をクリックし、任意の資格証明を使用してホスト・マシンにログインします。別の資格証明タイプおよびその設定の詳細は、『Oracle Enterprise Managerライフサイクル管理者ガイド』を参照してください。
ホスト・マシンにログインしたら、アップロードするファイルが存在する場所を参照します。OMS共有ファイル・システムまたはOMSエージェント・ファイル・システムで構成されている任意の記憶域の場所にファイルをアップロードできます。

- ファイルの参照: 「ファイルの参照」オプションを選択する場合は、実際にはソフトウェア・ライブラリには何もアップロードされないため、入力を必要とするのはソースの場所の詳細のみです。「ソースの指定」セクションで、記憶域のタイプとして「HTTP」、「NFS」または「エージェント」のいずれかを選択して「OK」をクリックします。選択した場所に対応する記憶域のタイプおよび場所のパスが移入されます。
「+」(追加)をクリックし、選択した参照されるファイルの場所に存在するエンティティを参照します。参照先ファイルの追加ダイアログ・ボックスで、「ベースの場所」にファイルの相対パスを入力します。「次の名前でステージング」をクリックし、一意な名前の一時的なステージング場所にファイルを編成します。

それぞれの記憶域オプションの詳細は、第22.7.3項を参照してください。

8. ディレクティブの設定ページで、「ディレクティブの選択」をクリックして1つ以上のディレクティブにコンポーネントを関連付けると、そのディレクティブが実行されます。「次へ」をクリックします。

9. 確認ページで詳細をすべて確認して「終了」をクリックすると、コンポーネントが作成されてソフトウェア・ライブラリにアップロードされます。

22.12.2.2 ディレクティブの作成

ディレクティブは、実行される一連の命令を表す、ソフトウェア・ライブラリのエンティティです。これらは、スクリプトをソフトウェア・コンポーネントおよびイメージに関連付ける際に使用する構成体です。このスクリプトには、特定のコンポーネントまたはイメージの内容を解釈して処理する方法に関する指示が記載されています。

ソフトウェア・ライブラリのホームページからディレクティブを作成する手順:

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、Oracle所有ではないカスタム・フォルダを選択します。
注意: Oracle所有フォルダには汎用コンポーネントを作成できません。カスタム・フォルダの作成については、第22.12.1項を参照してください。

3. 「アクション」メニューから「エンティティの作成」を選択し、「ディレクティブ」をクリックします。エンティティの作成: ディレクティブ・ウィザードが表示されます。

4. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力しているのに競合と表示される場合は、表示権限がないために表示されていないフォルダの中に同じ名前のエンティティが存在する可能性があります。

「+」(追加)をクリックして、README、付帯状況、ライセンスなど、そのエンティティを適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡する変更履歴など、エンティティに関連する情報を追加します。

5. 構成ページで、ディレクティブに渡す必要があるコマンドライン引数を指定します。このコマンドでは、ディレクティブの実行に必要なパラメータを指定します。
コマンドライン引数またはパラメータを追加するには、「追加」をクリックします。

「コマンドライン引数の追加」ダイアログ・ボックスで、次の各フィールドに値を入力します。

- 引数の接頭辞: スイッチまたは定数のコマンドライン引数です。
引数の接頭辞を使用すると、任意のディレクティブでパラメータが実行される順序を手動で指定するという、エラーの起きやすいタスクが不要になります。ディレクティブが複数のパラメータからなる場合は特に便利です。

引数の接頭辞を使用してコマンドライン引数を作成することをお薦めします。

- プロパティ名: プロパティの名前。文字列値である必要があります。

- 引数の接尾辞: コマンドライン・プロパティに続くテキストです。
接尾辞はほとんど使用されませんが、この接尾辞の値に基づいて、どのようにパラメータが実行されるかを決定します。

たとえば、渡すコマンドライン引数が次のような場合、

./test.sh -user={username}

結果

引数の接頭辞: –user

パラメータ名: username

追加したパラメータはすべて、追加順に「コマンドライン」フィールドに表示されます。

パラメータの順序を変更する、または既存のパラメータのプロパティを編集する場合には、「編集」をクリックします。

パラメータを削除する場合には「削除」をクリックします。

「構成プロパティ」セクションで、スクリプトに定義されている「Bash」または「Perl」を選択します。

「権限付きで実行」を選択し、root権限でスクリプトを実行します。

6. ファイルの選択ページで、エンティティに関連付ける1つ以上のファイルを選択できます。次のいずれかのオプションを選択します。

- ファイルのアップロード: 一部のエンティティ・ファイルをローカルのファイル・システムまたはエージェント・マシンから、選択した宛先の場所にアップロードするとき。
宛先の場所を選択するには、「宛先の指定」セクションの「アップロード場所」フィールドで、拡大鏡アイコンをクリックして次のオプションの1つを選択します。

- OMS共有ファイル・システム

- OMSエージェント・ファイル・システム

選択した場所に対応する記憶域のタイプおよび場所のパスが移入されます。

注意:

ファイルをアップロードするには、アップロード先の記憶域の場所のステータスが「アクティブ」であることが必要です。

OMSエージェント・ファイル・システムの場所を選択する場合は、その場所へのアクセスに必要な権限があることを確認してください。

「ソースの指定」セクションで、ソースとなるファイルの場所として、ローカルのファイル・システム、または管理エージェントによって監視されているリモートのファイル・システムのいずれかを入力します。ファイル・ソースとして、次のオプションのいずれかを選択します。

- ローカル・マシンを選択する場合は、「追加」をクリックすると、「ファイルの追加」ダイアログ・ボックスが表示されます。「参照」をクリックしてソースの場所からエンティティ・ファイルを選択し、一意の名前を付けて「OK」をクリックします。
OMS共有ファイル・システムまたはOMSエージェント・ファイル・システムで構成されている任意の記憶域の場所にファイルをアップロードできます

- エージェント・マシンを選択する場合は、エンティティ・ファイルを選択するホスト・マシンの名前を選択します。「+」(追加)をクリックし、任意の資格証明を使用してホスト・マシンにログインします。別の資格証明タイプおよびその設定の詳細は、『Oracle Enterprise Managerライフサイクル管理者ガイド』を参照してください。
ホスト・マシンにログインしたら、アップロードするファイルが存在する場所を参照します。OMS共有ファイル・システムまたはOMSエージェント・ファイル・システムで構成されている任意の記憶域の場所にファイルをアップロードできます。

- ファイルの参照: 「ファイルの参照」オプションを選択する場合は、実際にはソフトウェア・ライブラリには何もアップロードされないため、入力を必要とするのはソースの場所の詳細のみです。「ソースの指定」セクションで、記憶域のタイプとして「HTTP」、「NFS」または「エージェント」のいずれかを選択して「OK」をクリックします。選択した場所に対応する記憶域のタイプおよび場所のパスが移入されます。
「+」(追加)をクリックし、選択した参照されるファイルの場所に存在するエンティティを参照します。参照先ファイルの追加ダイアログ・ボックスで、「ベースの場所」にファイルの相対パスを入力します。「次の名前でステージング」をクリックし、一意な名前の一時的なステージング場所にファイルを編成します。

それぞれの記憶域オプションの詳細は、第22.7.3項を参照してください。

7. 確認ページで詳細をすべて確認して「終了」をクリックすると、コンポーネントが作成されてソフトウェア・ライブラリにアップロードされます。

22.12.3 エンティティのカスタマイズ

Oracle所有のフォルダ内にあるエンティティは編集できません。Oracle所有エンティティを編集する場合は、エンティティのコピーを作成して、それをカスタム・フォルダに格納できます。これで、エンティティに対する完全なアクセス権が付与されるため、使用環境に基づいてエンティティをカスタマイズできるだけでなく、このエンティティに対するアクセス権を他のユーザーに付与することもできます。

Oracle所有のエンティティからカスタム・エンティティを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、エンティティを選択するか、エンティティを検索して選択します。
エンティティの検索の詳細は、第22.12.4.10項を参照してください。

3. 「アクション」メニューから、「類似作成」を選択します。

4. 「類似作成: <エンティティ名>」ダイアログ・ボックスで、親フォルダに対して一意な名前と、エンティティの説明を入力します。
デフォルトでは、ルート・ディレクトリの「Software Library」が「親フォルダ」フィールドで事前選択されています。

親フォルダを変更してエンティティを編成するには、「親フォルダの変更」をクリックし、任意のフォルダを選択します。

5. 「OK」をクリックして変更内容を適用します。
新しいエンティティは、「エンティティ」表で、選択した親フォルダの下位に表示されます。

エンティティの所有者はエンティティに対してすべての権限を持ち、必要に応じてプロパティを更新できます。

エンティティのプロパティを更新するには、第22.12.4.8項を参照してください。

Oracle所有エンティティとユーザー所有エンティティの詳細は、第22.11項を参照してください。

22.12.4 エンティティの管理

ソフトウェア・ライブラリのホームページで、既存のエンティティに対して次のメンテナンス・タスクを実行できます。

- ソフトウェア・ライブラリ・ホーム・ページへのアクセス

- ソフトウェア・ライブラリの管理・ページへのアクセス

- 権限の付与または取消し

- エンティティの移動

- エンティティの成熟度の変更

- エンティティへのノートの追加

- エンティティへの添付ファイルの追加

- エンティティの表示、編集および削除

- エンティティの検索

- エンティティのエクスポート

- エンティティのインポート

注意:
Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以降では、表22-3に示すすべてのタスクを実行するために、GUIを使用することもコマンドライン・インタフェース・ツールを使用することもできます。

22.12.4.1 ソフトウェア・ライブラリ・ホーム・ページへのアクセス

ソフトウェア・ライブラリ・ホーム・ページにアクセスするには、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。

22.12.4.2 ソフトウェア・ライブラリの管理・ページへのアクセス

ソフトウェア・ライブラリの管理・ページにアクセスするには、「設定」メニューから、「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。

22.12.4.3 権限の付与または取消し

Enterprise Managerユーザーがソフトウェア・ライブラリのホームページでエンティティを表示するには、少なくともエンティティに対する表示権限が必要です。所有者およびスーパー管理者は、編集(更新の意味)または管理(または完全)などの追加権限を付与したり、前に付与した権限を後で取り消すことを選択できます。

権限を付与する、または取り消すには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 他のユーザーに対して、自分が所有しているエンティティに対するファイングレイン権限の付与または取消しを行うには、カスタム・エンティティを選択し、「アクション」メニューで「権限の付与/取消し」をクリックします。

3. <エンティティ名>に対する「権限の付与/取消し」ウィンドウで、組織におけるユーザー・ロールや職責に応じて、ソフトウェア・ライブラリ権限の付与または取消しを行うことができます。
権限を付与する場合: 1つ以上の新しい権限を付与するには、「+」(追加)をクリックしてユーザーを検索します。自分が所有しているエンティティに対する次の権限のいずれかを、ユーザーに付与できます。

- ソフトウェア・ライブラリ・エンティティの表示: 通常はオペレータの権限で、ユーザーはソフトウェア・ライブラリのホームページでエンティティの表示のみ可能です。エンティティの編集や管理はできません。Oracle所有のすべてのエンティティは、Enterprise Managerのすべてのユーザーが表示できます。

- ソフトウェア・ライブラリ・エンティティの編集: デザイナの権限です。ユーザーにはエンティティに対する作成、更新、編集の権限が付与されます。

- ソフトウェア・ライブラリ・エンティティの管理: スーパー管理者の権限です。ユーザーにはエンティティに対するすべての権限が付与されます。この権限を使用すると、他のユーザーに対するこのエンティティのアクセス権の付与または取消し、またはエンティティの削除を実行できます。

権限を取り消す場合: 以前に付与した権限を取り消すには、ユーザーを選択して「削除」をクリックします。

4. 「更新」をクリックすると、選択した権限の付与がエンティティに適用されます。

22.12.4.4 エンティティの移動

エンティティのすべてのリビジョンをフォルダ間で移動する手順:

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、エンティティを選択するか、エンティティを検索して選択します。
エンティティの検索の詳細は、第22.12.4.10項を参照してください。

3. 「アクション」メニューで「エンティティの移動」をクリックし、確定します。

4. 「エンティティの移動」ダイアログ・ボックスでエンティティの移動先フォルダを選択し、新しい親フォルダの選択をクリックします。
注意: Oracle所有のフォルダは移動も編集もできないため、移動元と移動先のフォルダがOracle所有ではないことを確認してください。

22.12.4.5 エンティティの成熟度の変更

エンティティをEnterprise Managerホームから作成した場合、エンティティは現在、未テスト状態にあります。エンティティをテストし、テスト結果に基づいて成熟度レベルを変更するのは設計者の職責です。

エンティティのライフサイクルを管理し、エンティティの品質(成熟度レベル)を示すには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、エンティティを選択するか、エンティティを検索して選択します。
エンティティの検索の詳細は、第22.12.4.10項を参照してください。

3. 「アクション」メニューで「成熟度の変更」をクリックし、テスト後のエンティティの成熟度の値を変更します。

たとえば、Oracle Databaseクローン・コンポーネントをテストするには、データベースをプロビジョニングするデプロイメント・プロシージャ・インタビュー・フローでこのコンポーネントを選択します。エンティティをテストした後、設計者は、テスト結果に基づいてエンティティの成熟度をベータまたは本番に変更できます。オペレータがエンティティを使用できるのは、エンティティが本番レベルとしてマークされている場合のみです。

22.12.4.6 エンティティへのノートの追加

既存のエンティティに対する変更または更新に関する情報をログに記録するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、エンティティを選択するか、エンティティを検索して選択します。
エンティティの検索の詳細は、第22.12.4.10項を参照してください。

3. 「アクション」メニューで「ノート」をクリックし、エンティティに関連する重要な情報を追加します。エンティティの編集中にノートを追加することもできます。
最新のノートが表の上位に表示され、古いノートは下に表示されます。

4. 詳細を更新したら、「終了」をクリックして変更を発行し、ソフトウェア・ライブラリのホームページに戻ります。

22.12.4.7 エンティティへの添付ファイルの追加

エンティティが表すソフトウェアに関連する通常のドキュメント(README、インストール、構成)であるファイルを追加またはアップロードするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、エンティティを選択するか、エンティティを検索して選択します。
エンティティの検索の詳細は、第22.12.4.10項を参照してください。

3. 「アクション」メニューで「添付ファイル」をクリックし、エンティティに関連するファイルを追加します。これらのファイルには、エンティティに関する重要な情報が含まれています。エンティティの編集中に添付ファイルを追加することもできます。
たとえば、パッチやコンポーネントにREADMEファイルを添付したり、ディレクティブにテスト・スクリプトを添付したりすることが可能です。ただし、添付ファイルのサイズは1ファイル当たり2 MBまでです。

4. 「終了」をクリックして変更を発行し、ソフトウェア・ライブラリのホームページに戻ります。

22.12.4.8 エンティティの表示、編集および削除

エンティティの詳細を表示、編集、削除するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、エンティティを選択するか、エンティティを検索して選択します。
エンティティの検索の詳細は、第22.12.4.10項を参照してください。

3. 既存のエンティティを管理するには、エンティティを選択し、次のいずれかの機能を実行します。

- 表示: エンティティの詳細を表示するには、表で「表示」アイコンをクリックします。ここからエンティティのプロパティを更新することはできません。

- 編集: 表で「編集」アイコンをクリックするか、エンティティを右クリックしてコンテキスト・メニューから「編集」を選択し、エンティティのプロパティを更新します。
詳細に問題がなければ、「保存とアップロード」をクリックし、ソフトウェア・ライブラリのホームページで使用可能な変更を行います。

- 削除: エンティティをソフトウェア・ライブラリのホームページから削除するには、「削除」アイコンをクリックします。
注意: エンティティを削除すると、エンティティが選択、表示または編集できなくなり、ソフトウェア・ライブラリのホームページに表示されません。しかし、そのエンティティはリポジトリには残っており、関連するファイルがアップロードされていれば、そのファイルもそれぞれのディスク記憶域に残っています。エンティティをリポジトリから完全に削除し、関連するファイルをファイル・システムから削除するには、削除したエンティティを管理ページからパージする必要があります。パージ・ジョブは、削除されたエンティティに関連付けられているファイルを削除するだけでなく、リポジトリ表から削除されたエンティティ自体を削除します。

削除されたエンティティの記憶域の場所からのパージ方法の詳細は、第22.12.4.9項を参照してください。

22.12.4.9 削除されたエンティティのパージ

パージ・ジョブを実行し、削除されたエンティティをすべての構成済のエージェント記憶域の場所からパージできます。次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。

2. ソフトウェア・ライブラリホームページの「アクション」メニューから、「削除済エンティティ」を選択します。ソフトウェア・ライブラリから削除されたエンティティのリストが表示されます。

注意:
ソフトウェア・ライブラリにファイルをアップロードした削除済エンティティに対してのみ、使用領域属性が表示されます。

3. 削除済エンティティ・ページで「パージ」をクリックして、これらのエンティティをOracle Management Repositoryから、および関連付けられたファイルをアップロード記憶域の場所から完全に削除します。

4. 「確認メッセージ」ダイアログ・ボックスが表示されます。「ジョブ詳細」をクリックして、発行されたパージ・ジョブのステータスを表示します。

注意:
SWLIBPURGEという名前の定期的なジョブが毎日実行され、削除済エンティティをソフトウェア・ライブラリからパージします。

22.12.4.10 エンティティの検索

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

- 基本検索および拡張検索の実行

- 検索の保存

- 保存済検索の取得

- 保存済検索の管理

22.12.4.10.1 基本検索および拡張検索の実行

エンティティの基本検索または拡張検索を実行するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. エンティティを検索するには、次のいずれかの操作を行います。

1. 検索: ソフトウェア・ライブラリのホームページで、「名前」、「説明」または「タイプ」別にエンティティを検索できます。検索カテゴリを選択し、目的の値を入力し、矢印アイコンをクリックします。
矢印アイコンをクリックすると、一致した結果の数が結果ページに表示され、上下矢印をクリックして結果行を切り替えることができます。

2. 検索: エンティティの拡張検索を実行するには、「検索」をクリックします。デフォルトの検索オプションでは、「タイプ」、「名前」、「説明」、「改訂」、「成熟度」、「ステータス」および「ファイル名」別に検索して、さらに詳細な検索結果を取得できます。
注意: サブタイプ(コンポーネントなど)が関連付けられているエンティティを選択すると、「サブタイプ」を追加の検索カテゴリとしてページがリフレッシュされます。

「すべて」または「任意」の検索フィールドに適切な値を指定して「検索」をクリックします。

検索パラメータを追加するには、「拡張検索」セクションで「フィールドの追加」メニューをクリックし、任意の検索フィールドを選択します。選択したフィールドが、新しい検索パラメータとして「拡張検索」セクションに表示されます。この新しい検索機能を使用すると、検索を絞り込み、さらに正確な目的の検索結果にドリルダウンすることができます。

簡易検索の表示に戻すには、「検索を閉じる」をクリックします。

22.12.4.10.2 検索の保存

オプションで、コンソールの「拡張検索」画面の検索基準を保存できます。保存済検索を取得し、再度実行できます。また、編集および削除も可能です。

1. エンティティを検索します。

2. 「検索の保存」をクリックします。

3. テキスト・ボックスに検索に必要な名前を入力し、「OK」をクリックします。

22.12.4.10.3 保存済検索の取得

保存済検索を取得するには、次の手順に従います。

1. エンティティを検索します。

2. 「保存済検索」をクリックし、リストから必要な保存済検索を選択します。
また、「お気に入り」メニューから必要な保存済検索を選択することもできます。このためには、「お気に入り」メニューから「保存されたソフトウェア・ライブラリ検索」を選択し、必要な保存済検索を選択します。

22.12.4.10.4 保存済検索の管理

「保存済検索の管理」オプションを使用すると、保存済検索の名前を編集、または保存済検索を削除できます。次の手順を実行します。

- 保存済検索を管理するには、次のいずれかの手順を実行します。

- 「お気に入り」メニューから、「お気に入りの管理」を選択します。

- 「保存済検索」をクリックし、「保存済検索の管理」を選択します。

- 保存済検索の名前を編集するには、必要な保存済検索を選択し、「名前」テキスト・フィールドに新しい名前を入力します。「OK」をクリックして変更内容を保存します。

- 保存済検索を削除するには、該当する保存済検索を選択し、「選択項目の削除」を選択します。「OK」をクリックして変更内容を保存します。

22.12.4.11 エンティティのエクスポート

選択したエンティティをエクスポートするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、「アクション」メニューから「エクスポート」をクリックし、ソフトウェア・ライブラリ内にプロビジョニング・アーカイブ(PAR)ファイルとして存在するエンティティをエクスポートします。
PARファイルは、Enterprise Managerで別のリポジトリを使用してエンティティを再作成するために使用できます。

3. ソフトウェア・ライブラリ・エンティティのエクスポート・ページで、次の操作を実行します。

- 「+」(追加)をクリックし、エンティティを検索および選択します。

- 「ディレクトリの場所」で、生成されるPARファイルを格納するための、OMSからアクセス可能なディレクトリの場所を入力します。

- 「PARファイル」で、エクスポート時に生成された、.par拡張子を持つPARファイルの名前を入力します。

- エクスポートするPARファイルのすべてのシークレット・プロパティ値を暗号化して安全に格納するには、「Oracleウォレット・パスワード」フィールドに値を入力します。
注意: このPARをインポートするときは同じパスワードを指定します。インポート時の詳細は、第22.12.4.12項を参照してください。

- エンティティに関連付けられたファイル、バイナリまたはスクリプトをエクスポートの対象外にするには、「関連付けられたファイルの除外」を選択します。

たとえば、別のテストおよび本番環境があり、テストが済んで認証されたテスト環境内のエンティティのみを本番にインポートするとします。テスト・システムからエクスポートされるエンティティは、プロビジョニング・アーカイブ(PAR)ファイルとして使用可能になります。これで、このPARファイルを(テスト・システムと同じ)本番システムにインポートし、テストしたエンティティを使用できるようになります。

4. 「発行」をクリックし、エクスポート・ジョブを発行します。ジョブが正常に実行された後、ソフトウェア・ライブラリから選択したエンティティがPARファイルとしてエクスポートされます。

注意:
バージョン12cよりも前のバージョンのEnterprise Managerからエクスポートされたプロビジョニング・アーカイブ・ファイルは、Enterprise Manager 12cにはインポートできません。

22.12.4.12 エンティティのインポート

PAR(プロビジョニング・アーカイブ)ファイルをソフトウェア・ライブラリにインポートする、またはOMSにデプロイするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、「アクション」メニューから「インポート」をクリックし、PARファイルをインポートします。

3. ソフトウェア・ライブラリ・エンティティのインポート・ページで、インポートする「PARファイル」を指定します。
PARファイルを正常にインポートするには、「パスワード」フィールドに、エクスポート時にシークレット・プロパティ値を保護するためPARファイルに設定されていたものと同じパスワードを入力します。

たとえば、別のテストおよび本番環境があり、テストが済んで認証されたテスト環境内のエンティティのみを本番にインポートするとします。テスト・システムからエクスポートされるエンティティは、プロビジョニング・アーカイブ(PAR)ファイルとして使用可能になります。これで、このPARファイルを(テスト・システムと同じ)本番システムにインポートし、テストしたエンティティを使用できるようになります。

4. インポートするエンティティのリビジョンがソフトウェア・ライブラリ内にすでに存在する場合は、「新規リビジョンを強制」を選択することにより、インポート時に新規リビジョンで既存のエンティティを上書きできます。
注意: インポートしようとするエンティティのリビジョンがすでにリポジトリに存在する場合に、「新規リビジョンを強制」オプションを選択しないと、インポート・プロセスは失敗します。

5. 「発行」をクリックし、インポート・ジョブを発行します。ジョブが正常に完了すると、ソフトウェア・ライブラリにPARファイルがインポートされます。

注意:
バージョン12cよりも前のバージョンのEnterprise Managerからエクスポートされたプロビジョニング・アーカイブ・ファイルは、Enterprise Manager 12cにはインポートできません。

22.12.5 エンティティのステージング

複数のエンティティに関連付けられたファイルを複数のターゲット・ホストに転送するには、この項で説明している手順を実行します。

前提条件

ファイルをステージングする前に、次の前提条件を満たしていることを確認します。

1. Enterprise Managerによって監視されているホストのみが、エンティティに関連付けられたファイルのステージングのための宛先として指定できます。

2. 各エンティティでは、エンティティに正常にアップロードされたファイル(したがって「準備完了」ステータス)のみが、ステージング用に選択できます。

注意:
エンティティに「準備完了」状態のファイルがあるかどうかを検証するには、次の手順を実行します。

1. エンティティを選択し、「表示」をクリックします。

2. エンティティの表示ページで、「ファイルの選択」タブを選択し、エンティティに関連付けられたファイルを検証します。

3. 1つ以上の「準備完了」ステータスのファイルがない場合、ステージング・プロセスを続行できません。

3. ジョブの表示権限を持つユーザーのみがステージングを実行できます。

4. ユーザーが少なくとも表示権限を持つエンティティのみをステージング対象として選択できます。

5. ターゲット・ホストに与えられた資格証明を使用して、場所に書込みできる必要があります。

6. ステージングされるソース・ファイルがNFS上にある場合、宛先ターゲットを参照するために使用される資格証明には、NFSの場所をマウントできるようにroot権限を持つ必要があります。

ステージング・プロシージャ

Enterprise Manager Cloud Controlにログインして、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「アクション」メニューから、「ステージング・エンティティ」を選択します。

3. 「ステージング・エンティティ」ページから、「エンティティ」セクションを展開します(展開されていない場合)。

4. 「+」(追加)をクリックし、エンティティを検索および選択します。まだ追加されていないエンティティ、および1つ以上のファイルが「準備完了」ステータスになっているエンティティのみを追加できます。

5. デフォルトでは、「準備完了」ステータスのすべてのファイルがステージングに選択されます。選択を変更するには、表内の追加済エンティティの行を展開して、「選択」列を選択/選択解除します。

6. オプションで、「ステージング先のファイルを上書きします」を選択して、同じファイルの既存のバージョンを上書きできます。選択しない場合、このオプションを無視して続行します。

7. 「ステージング先」セクションで、「+」(追加)をクリックしてステージング先の詳細を追加します。

8. 「+」(追加)をクリックして、ステージングのターゲット・ホストを選択します。

9. 選択したホスト・ターゲットに適した「ステージングの場所」をテキスト・ボックスで指定します。

10. ステージングに使用する資格証明を選択します。複数のホスト・ターゲットを選択する場合、各ホストで選択した資格証明を使用して、ステージングの場所を書込み可能にする必要があります。

11. 「OK」をクリックして、ステージング先の表の選択したホストを更新します。

12. 「発行」をクリックします。

13. 発行したジョブのステータスを確認するには、「ジョブ詳細」リンクをクリックして「ファイル転送アクティビティ」ページに移動し、ファイル転送の詳細を表示します。または、「エンタープライズ」メニューから、「ジョブ」を選択し、「アクティビティ」をクリックしてジョブを検索します。

22.13 ソフトウェア・ライブラリの管理

ソフトウェア・ライブラリの状態と適切な機能性を維持するために、ソフトウェア・ライブラリを構成した管理者、またはソフトウェア・ライブラリに対する管理アクセス権を持つデザイナは次のタスクを実行する必要があります。

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

- 定期的なマンテナンス・タスク

- Oracle所有エンティティ・ファイルの再インポート

- ソフトウェア・ライブラリ記憶域の場所の削除(および移行)

- 参照先記憶域の場所の削除

- 記憶域の場所の非アクティブ化およびアクティブ化

- パージ・ジョブのスケジュール

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

22.13.1 定期的なメンテナンス・タスク

管理者は、ソフトウェア・ライブラリの適切な機能性について次のタスクを定期的に実行する必要があります。

- ソフトウェア・ライブラリを定期的にリフレッシュして、使用可能な領域、空き領域、および削除したエンティティが使用していた領域を計算します。これを行うには、管理ページの「アップロード・ファイルの場所」タブで、記憶域の場所を選択します。「アクション」メニューから、「リフレッシュ」を選択します。リフレッシュが成功すると、確認メッセージが表示されます。また、定期的なリフレッシュ・ジョブSWLIBREFRESHLOCSTATSを検索し、要件に合うようにスケジュールおよび他の属性を編集することもできます。デフォルトでは、このジョブは6時間ごとに実行されるようにスケジュールされています。

- 削除されたエンティティをパージし、ディスク領域を節約する。これを行うには、第22.13.6項を参照してください。また、定期的なパージ・ジョブSWLIBPURGEを検索し、要件に合うようにスケジュールおよび属性を編集することもできます。デフォルトでは、このジョブは24時間ごとに実行されるようにスケジュールされています。

- 構成したソフトウェア・ライブラリの場所のアクセシビリティを確認します。これを行うには、管理ページの「アップロード・ファイルの場所」タブで、記憶域の場所を選択します。「アクション」メニューから、「アクセシビリティの確認」を選択します。

22.13.2 Oracle所有エンティティ・ファイルの再インポート

注意:
再インポートするメタデータは、Oracle所有ファイル(デフォルトでEnterprise Manager製品に付属するすべてのエンティティ・ファイル)にのみ適用されます。ユーザー所有エンティティ・ファイルのメタデータは、再インポート機能では回復できません。

Oracle所有エンティティ・ファイルのメタデータの再インポートは、定期的な作業ではありません。再インポートは、次のいずれかの状況でメタデータ・ファイルを回復する場合に役立ちます。

- メタデータがインポートされたファイル・システムの場所を削除する場合。例: /scratch/swlib1/

- 最初のアップロードの場所の作成中に発行されたインポート・ジョブが失敗した場合。

Oracle所有ファイルのメタデータを再インポートするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. 「ソフトウェア・ライブラリ管理」ページの「アップロード・ファイルの場所」タブで、「アクション」メニューから「メタデータの再インポート」オプションを選択して、再インポート・プロセスを再起動するジョブを発行します。

22.13.3 ソフトウェア・ライブラリ記憶域の場所の削除(および移行)

ソフトウェア・ライブラリの記憶域管理者には、記憶域の場所を削除するのに必要な権限があります。記憶域の場所を使用していない場合は、その場で削除できます。ただし、使用中である場合は、内容を別の場所に移行して、これらのファイルを使用するエンティティを引き続き使用できるようにする必要があります。

使用中の記憶域の場所を削除する前に、ファイルを移行する別の場所を選択するよう求められます。別の場所を選択すると、移行ジョブが発行され、この場所が「移行中」としてマークされます。新しい場所にエンティティ・ファイルが正常に移行された後、場所の構成が削除されます。移行中になんらかのエラーが発生した場合、場所は「非アクティブ」としてマークされます。エラーが修正されると、その場所が使用可能になったことを記憶域管理者が確認し、場所が「アクティブ」としてマークされます。

注意:
OMSエージェント・ファイル・システムまたは参照先エージェント・ファイル・システム記憶域から場所を削除するには、削除する場所、およびファイルを移行する別の場所に関する資格証明に対する表示権限が必要です。

構成済の記憶域の場所を構成するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ管理」ページで、記憶域の場所を選択して「移行と削除」をクリックします。

3. 「場所の移行と削除」ダイアログ・ボックスで、「OMS共有ファイル・システム」または「OMSエージェント・ファイル・システム」のいずれかを選択します。使用可能でアクティブな記憶域の場所のリストが表示されるので、1つを選択し、「移行と削除」をクリックします。

注意:
1つ以上のアップロード場所(OMS共有ファイル・システムまたはOMSエージェント・ファイル・システムのいずれか)が存在する必要があります。最後のアクティブなアップロード場所は削除できません。Cloud ControlまたはEMCLIのいずれかを使用して、いずれかのアップロード記憶域タイプ(OMS共有ファイル・システムまたはOMSエージェント・ファイル・システム)のアップロード場所をもう一方のアップロード場所に移行します。たとえば、OMS共有ファイル・システム記憶域の場所をOMSエージェント・ファイル・システム記憶域の場所に移行できます。逆の操作もサポートされます。しかし、このタイプの移行は、記憶域タイプ全体で特にアップロード記憶域タイプに対してサポートされ、参照記憶域タイプには適用されないことに注意してください。
記憶域の場所については、アクティブなアップロード場所(OMS共有ファイル・システムまたはOMSエージェント・ファイル・システム)がない場合、その場所では「移行と削除」ボタンは有効になりません。

ファイルをあるアップロードの場所から別の場所へと移行するには、EM CLI動詞emcli remove_swlib_storage_locationを使用することもできます。このコマンドの詳細は、第22.4項を参照してください。

4. 確認のダイアログ・ボックスで「移行と削除」をクリックしてジョブを発行します。このジョブが成功すると、記憶域エントリが表から削除されます。

注意:
たとえば、/vol/swlib1から/vol/swlib2のように、記憶域の場所を別の場所に移行するとき、ソースの場所(/vol/swlib1)のファイル・システム・コンテンツは移行中は削除されません。しかし、その後、ソースの場所およびファイルはソフトウェア・ライブラリによって二度と参照されません。

22.13.4 参照先記憶域の場所の削除

構成済の参照記憶域の場所(HTTP/NFS/外部エージェントの場所)を削除するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ管理」ページで、記憶域の場所を選択して「移行と削除」をクリックします。

注意:
場所が使用中でない場合、記憶域の場所を選択し、「OK」をクリックしてその場所を削除します。ただし、いくつかのエンティティで記憶域の場所を使用中の場合は、既存の場所を削除する前に、ファイルを別の場所に移行する必要があります。

3. 「場所の移行と削除」ダイアログ・ボックスから、ファイルを別の場所に移行するには、アクティブな記憶域の場所のリストから移行先の場所を選択し、「OK」をクリックします。

注意:
移行可能で同じ記憶域タイプのアクティブな場所がない場合、その場所では「移行と削除」ボタンは無効です。

22.13.5 記憶域の場所の非アクティブ化およびアクティブ化

アップロードまたは参照の記憶域の場所は非アクティブ化できます。非アクティブ化すると、記憶域の場所のステータスは「非アクティブ」になり、アップロード記憶域の場所へのアップロードはできなくなります。非アクティブな記憶域の場所は、使用可能にするためにアクティブにできます。

記憶域の場所を非アクティブにするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ管理」ページで、「アクティブ」な状態の記憶域の場所を選択し、「アクション」メニューから「解除」を選択します。確認のダイアログが表示されます。

3. 確認時、記憶域の場所は非アクティブで、状態は「非アクティブ」に変わります。

記憶域の場所をアクティブにするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ管理」ページで、非アクティブな状態の記憶域の場所を選択し、「アクション」メニューから「アクティブにする」を選択します。確認のダイアログが表示されます。

3. 確認時、記憶域の場所はアクティブで、状態は「アクティブ」に変わります。

22.13.6 パージ・ジョブのスケジュール

Enterprise Manager 12c以上では、パージ・ジョブをスケジュールできます。次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリ管理ページで記憶域の場所を選択し、「アクション」メニューから「パージ」を選択します。次のダイアログ・ボックスが表示され、パージ・ジョブをスケジュールできます。

3. すべての詳細を入力し、「OK」をクリックしてジョブを発行し、ジョブが正常に完了すると、すべての削除済エンティティが記憶域の場所から消去されます。

ただし、次の方法でこの操作を実行することもできます。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ管理」ページで、「アクション」メニューから、「削除済エンティティ」を選択します。タイプ、サブタイプ、所有者およびサイズが記載された削除済エンティティのリストが表示されます。

3. 「パージ」をクリックしてジョブを発行し、ジョブが正常に完了すると、すべての削除済エンティティが記憶域の場所から消去されます。

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

ソフトウェア・ライブラリのバックアップの詳細は、Enterprise Managerのアドバンスト・インストレーションおよび構成ガイドのEnterprise Managerのバックアップおよびリカバリに関する章を参照してください。

23 プラグインの管理

この章では、プラグイン・マネージャの概要と、プラグイン・マネージャを使用してプラグインを表示、デプロイ、管理およびアンデプロイする方法について説明します。

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

- プラグインの概要

- プラグインのデプロイ・ワークフロー

- プラグイン・マネージャの概要

- プラグインについて

- プラグインのダウンロード、デプロイおよびアップグレード

- プラグインのアンデプロイ

- プラグインの高度な操作

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

注意:
13cリリース1以降、一部のプラグインが廃止され、一部が非推奨になっています。廃止されたプラグインはEnterprise Manager (EM) Cloud Controlで完全にはサポートされないのに対し、非推奨のプラグインは将来のリリースからサポートされなくなります。EMを13cリリース1にアップグレードする場合は、廃止されたプラグインをEMからアンデプロイした後でアップグレードに進む必要があります。詳細は、第23.2.5項「廃止および非推奨のプラグイン」を参照してください。

23.1 スタート・ガイド

表23-1は、この章で説明する各項の概要を示しています。

表23-1 スタート・ガイド

ユーザー

推奨される項

初心者

- プラグインの概要

- プラグインのデプロイ・ワークフロー

- プラグイン・マネージャの概要

基本ユーザー

- プラグインのデプロイ・ワークフロー

- 表示のカスタマイズ

- プラグインの可用性の確認

- プラグインに関する情報の表示

中級ユーザー

- 表示のカスタマイズ

- プラグインの可用性の確認

- プラグインに関する情報の表示

- プラグインのダウンロード

- Oracle Management Serviceへのプラグインのデプロイ(OMS再起動時間および停止時間の削減)

- Oracle Management Serviceにデプロイ済のプラグインのアップグレード

- Oracle Management Agentへのプラグインのデプロイ

- Oracle Management Agentにデプロイ済のプラグインのアップグレード

- Oracle Management Serviceからのプラグインのアンデプロイ

- Oracle Management Agentからのプラグインのアンデプロイ

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

上級ユーザー

- Oracle Management Agentへのプラグインの再デプロイ

- 管理エージェントのデプロイまたはアップグレード中にプラグイン・パッチをデプロイ(カスタム・プラグイン更新の作成)

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

23.2 プラグインの概要

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

- Enterprise Managerの拡張性の枠組み

- プラグイン

- デフォルトでデプロイされるプラグイン

- プラグイン・リリース

- プラグインを管理するために必要なロール

23.2.1 Enterprise Managerの拡張性の枠組み

Enterprise Managerは、OracleおよびOracle以外のテクノロジを実行するシステムを含むITインフラストラクチャ全体に対して、集中化された監視機能、管理機能およびライフ・サイクル管理機能を提供するシステム管理ソフトウェアです。

Enterprise Managerは何年にもわたり、サイズと規模を拡大し、強力なIT管理と監視ソリューションを提供してきました。この拡大が、新しい機能、拡張機能およびバグ修正のサポートの管理に変化をもたらしました。

このような開発を考慮して、オラクル社では、製品が動作するフレームワークまたはコア・ベースを、機能を使用してITソリューションを提供するレイヤーから明確に分離するという方法で、Enterprise Managerのアーキテクチャを注意深く再設計しました。このEnterprise Manager 12cと将来のリリースに実装される新しいアーキテクチャにより、新しい機能や拡張機能をサポートするために適宜、自己をシームレスに拡張する機能を含む、より強力なフレームワークが提供されます。

リリース済の製品用の最新の監視機能にアクセスするために、Enterprise Managerの次のリリースを待つ必要はもうありません。Enterprise Manager 12cと将来のリリースのプラガブル・フレームワークでは、新しいバージョンのターゲットが出荷されるとすぐに、ターゲットのサポートを含めることが可能になります。Enterprise ManagerのリリースがOracleにより使用可能になるとすぐに、新しいEnterprise Managerシステムをインストールまたは既存のシステムをアップグレードできます。

新しい設計に基づき、Enterprise Manager 12cと将来のリリースのアーキテクチャは次の論理部分から構成されます。

- EMプラットフォーム: Enterprise Managerのほとんどの監視および管理機能が依存する、密接に統合されたUIとバックエンド・サービスから構成されます。プラットフォーム・サブシステムの例には、Enterprise Managerターゲットおよびメトリック・モデル、ジョブ、イベントおよびプロビジョニング・フレームワークがあります。このプラットフォームには、Oracle Management Agent (管理エージェント)も、データ・ローダー、ジョブ・ディスパッチャ、通知マネージャなどのコア・バックグラウンド・サービスとともに含まれています。プラットフォームはEnterprise Managerのリリースの一部として提供され、Enterprise Managerの新しいアージョンへのアップグレードによってのみアップグレードできます。

- EMプラグイン: 既存のEnterprise Managerプラットフォームにプラグインされて、Enterprise Managerのターゲット管理またはその他の垂直方向の機能を提供できるモジュール。プラグインは特別なソリューションや新しい機能を提供します。たとえば、My Oracle Supportへの接続、ホスト上の特定のターゲットを監視できるEnterprise Managerへの拡張監視および管理機能。プラグインはOMSおよび管理エージェントと連携して動作し、監視サービスを提供するので、OMSおよび管理エージェントにデプロイされます。

プラグインのリリースは、Enterprise Managerのコア・プラットフォームのリリースよりも頻繁に発生します。プラグインを使用すれば、プラットフォームの次回リリースを待たなくても、Oracle製品の最新リリースに対応した新機能および管理サポートがEnterprise Manager 12cと将来のリリースで利用できるようになります。

23.2.2 プラグイン

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

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

23.2.3 デフォルトでデプロイされるプラグイン

Enterprise Manager Cloud Controlのインストールの一部として、基本のプラグインのセットがデフォルトでデプロイされます。その他のプラグインをデプロイして、Enterprise Manager Cloud Controlの基本機能を拡張できます。

デフォルトでデプロイされるプラグイン、または即時利用可能なプラグインは、次のとおりです。

- Oracle Database: oracle.sysman.db

- Oracle Fusion Middleware: oracle.sysman.emas

- Oracle Systems Infrastructure: oracle.sysman.si

- Oracle Exadata: oracle.sysman.xa

- Oracle Cloud Framework: oracle.sysman.cfw

注意:
これらのプラグインの概要については、『Oracle Enterprise Manager基本インストレーション・ガイド』を参照してください。

23.2.4 プラグイン・リリース

プラグインのリリースは、Enterprise Managerのコア・プラットフォームのリリースよりも頻繁に発生します。この新しいプラガブル・フレームワークを使用すれば、プラットフォームの次回リリースを待たなくても、Oracle製品の最新リリースに対応した管理機能がEnterprise Manager Cloud Controlで利用できるようになります。

たとえば、Oracle Databaseの新規バージョンがリリースされた場合は、Oracle Databaseの最新リリースの管理サポートが含まれる最新のOracle Databaseプラグインをダウンロードしてデプロイするのみです。オフライン・モードでプラグインを使用して作業することもできます。

23.2.5 廃止および非推奨のプラグイン

廃止されたプラグインは、Enterprise Manager 13cリリース1と将来のリリースでサポートされないプラグインです。これらのプラグインは、Enterprise Manager 13cリリース1以上にアップグレードする前に、管理エージェントおよびOracle Management Serviceからアンデプロイする必要があります。

非推奨のプラグインは、Enterprise Managerの将来のリリースでサポートされなくなるプラグインです。非推奨のプラグインのデプロイは制限することをお薦めします。

廃止および非推奨のプラグインをEnterprise Managerからアンデプロイするには、まず管理エージェントから(第23.7.2項「Oracle Management Agentからのプラグインのアンデプロイ」を参照)、次にOMSから(第23.7.1項「Oracle Management Serviceからのプラグインのアンデプロイ」を参照)、プラグインをアンデプロイします。

アンデプロイされたプラグインのプラグイン・バイナリを自己更新から削除することをお薦めします。

23.2.6 プラグインを管理するために必要なロール

プラグインをダウンロード、管理、およびデプロイするには、すぐに使用できる次のロールが1つ以上必要です。

- EM_PLUGIN_OMS_ADMIN: 管理サーバー・インスタンスでプラグインのライフサイクルを管理できます。

- EM_PLUGIN_AGENT_ADMIN: 管理エージェントでプラグインのライフサイクルを管理できます。

- EM_PLUGIN_USER: プラグインのライフサイクル・コンソールを表示できます。

23.3 プラグインのデプロイ・ワークフロー

図23-1に、プラグインのデプロイ・ワークフロー、つまりEnterprise Managerインフラストラクチャの通常の設定、プラグインのOMSへのデプロイ、デプロイされたプラグインを使用したターゲットの検出とモニタリングの方法を示します。

図23-1 プラグインのデプロイ・ワークフロー

手順1: 自己更新コンソールの設定

自己更新コンソールは、Enterprise Managerで使用可能な新しい更新を確認、ダウンロード、適用するのに使用される一般的なダッシュボードです。このコンソールを使用すると、オラクル社から入手できる新規の更新について様々なチャネルを監視する必要がなくなります。自己更新により自動的にダウンロードされた更新にはプラグインが含まれています。プラグインの可用性を確認しEnterprise Managerへダウンロードするには、自己更新コンソールを設定する必要があります。『Oracle Enterprise Manager Cloud Control管理者ガイド』の説明に従い、自己更新コンソールを設定します。

手順2: プラグインの可用性の確認

プラグインの可用性の確認は、基本的に、プラグインがMy Oracle SupportでEnterprise Managerでのダウンロードおよびデプロイに使用可能かどうかを検証する動作のことです。これはプラグインのダウンロード前の前提条件です。プラグインの可用性を確認するには、第23.5.2項で説明する手順に従います。

手順3: プラグイン情報の表示

プラグイン情報の表示は、プラグインID、プラグイン・リリース番号、その他の基本情報などの、特定のプラグインに関する基本情報を表示する動作のことです。プラグインの情報を表示して、どのターゲットおよびオペレーティング・システムがプラグインで動作保証されているかを理解する必要があります。特定のプラグインがすでにデプロイされているかどうかを確認することもできます。プラグイン情報を確認するには、第23.5.3項で説明する手順に従います。

手順4: プラグインのダウンロード

プラグインのダウンロードは、プラグインのアーカイブまたはコンポーネントおよびそのメタデータを、特定のターゲットの検出および監視のために適切にデプロイできるように、My Oracle SupportからOracle Software Library (ソフトウェア・ライブラリ)へダウンロードする動作のことです。特定のターゲットがプラグインにより監視されていないことが判明したら、必要なプラグインをダウンロードする必要があります。オンライン・モードおよびオフライン・モードのどちらでもダウンロードできます。プラグインをダウンロードするには、第23.6.1項で説明する手順に従います。

ステップ5: OMSへのプラグインのデプロイ

プラグインのOMSへのデプロイは、プラグインがMy Oracle Supportからダウンロードされた後の、次の自然な行動です。これにより、OMSの機能が、新しいターゲットの管理または新しい垂直機能の追加のいずれかに拡張されます。OMSでのプラグインのインストールおよび構成は、基本的にデプロイメントと呼ばれます。デプロイしたときにOMSの再起動が必要なプラグインもあります。

図23-2に、プラグインのOMSへのデプロイ方法を示します。

図23-2 OMSへのプラグインのデプロイ

プラグイン・アーカイブがソフトウェア・ライブラリからOMSにデプロイされると、OMSはプラグインごとに、OMSプラグイン・コンポーネント、検出プラグイン・コンポーネント、および監視プラグイン・コンポーネントの、異なる3つのコンポーネントを受信します。

検出プラグイン・コンポーネントは、管理対象外ターゲットの検出に役立つコンポーネントです。監視プラグイン・コンポーネントは、検出されたターゲットを監視目的でEnterprise Manager Cloud Controlコンソールに追加するのに役立つコンポーネントです。

プラグインをOMSにデプロイするには、第23.6.2項で説明する手順に従います。

手順6: ターゲットの検出

ターゲットの検出は、使用環境で管理対象外のホストおよびターゲットを識別するプロセスのことです。ターゲットの検出中に、プラグインの検出コンポーネントが管理エージェント・ホームにデプロイされます。これにより、ターゲットを監視せずに、Enterprise Manager Cloud Controlは使用環境内の新しいターゲットのみを識別することができます。

Enterprise Manager Cloud Controlで管理対象外ホストを管理対象ホストに変換後、それらのホスト上のターゲットの自動検出を構成し、それらのホストで実行中の管理対象外ターゲットを識別できるようにする必要があります。

管理対象ホスト上のターゲットの自動検出を構成する手順は、次のURLで、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの検出および監視」を参照してください。

http://docs.oracle.com/cd/E24628_01/doc.121/e24473/discovery.htm#CBAGJFHC

注意:
管理対象ホストでのターゲットの自動検出を構成するときに、検出プラグイン・コンポーネントが管理エージェントにコピーされます。

管理対象ホストでのターゲットの自動検出を構成したら、Enterprise Manager Cloud Controlで昇格および監視できるようにするために、定期的にターゲットをチェックする必要があります。

検出されたターゲットを確認して管理対象ステータスに昇格する手順は、次のURLで、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの検出および監視」を参照してください。

http://docs.oracle.com/cd/E24628_01/doc.121/e24473/discovery.htm#CBAFHEHC

注意:
特定のターゲット・タイプのプラグインは、そのタイプのターゲットを監視する管理エージェントに自動的にデプロイされます。たとえば、データベース・ターゲットを検出する場合、データベース・プラグインの検出プラグイン・コンポーネントは、データベース・ホストにインストールされた管理エージェントに自動でデプロイされます。
ただし、これが行われるのは、最初のデプロイのときのみです。管理エージェント・プラグインに対する以降のすべての更新は、明示的にデプロイする必要があります。たとえば、新しいバージョンのデータベース・プラグインを管理エージェントにデプロイする場合、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』で説明されている手順を使用してデプロイを開始する必要があります。

同じく、管理エージェント(フレームワークまたはプラグイン)にパッチを適用する場合、『Oracle Enterprise Manager Cloud Control管理者ガイド』で説明されている手順を使用して明示的に適用する必要があります。

図23-3に、新しいターゲットの検出時の、検出プラグイン・コンポーネントの管理エージェントへのデプロイ方法を示します。

図23-3 ターゲットの検出

手順7: 監視用ターゲットの追加

ターゲットが検出されると、Enterprise Manager Cloud Controlで監視できるように、インフラストラクチャに追加されます。ターゲットの追加中に、プラグインの監視コンポーネントが管理エージェント・ホームにデプロイされます。

図23-4に、ターゲットの追加時の、監視プラグイン・コンポーネントの管理エージェントへのデプロイ方法を示します。

図23-4 ターゲットの追加

23.4 プラグイン・マネージャの概要

プラグイン・マネージャはEnterprise Manager Cloud Controlの機能で、すべてのプラグインのデプロイ関係のアクティビティを、GUIおよびCLIを介して実行するための、単一ウィンドウ・ソリューションとして機能します。プラグイン・マネージャを使用して、次のことができます。

- ダウンロード可能なプラグイン、ダウンロード済のプラグイン、およびCloud Controlにデプロイ済のプラグインの表示。

- プラグインの名前、提供ベンダー、プラグインIDおよびバージョン、簡単な説明などの、プラグインに関する重要な情報と動作保証の表示。

- OMSへのプラグインのデプロイ。

- 管理エージェントへのプラグインのデプロイおよび再デプロイ。

- カスタム・プラグイン更新の作成。

- プラグインのOMSおよび管理エージェントからのアンデプロイ。

- プラグインのデプロイ操作のステータスの表示。

23.4.1 プラグイン・マネージャのアクセス

プラグイン・マネージャ・コンソールにアクセスするには、「設定」メニューから、「拡張性」を選択し、「プラグイン」を選択します。

図23-5に、プラグイン・マネージャへのナビゲート方法を示します。

図23-5 プラグイン・マネージャへのナビゲート

23.4.2 プラグイン・マネージャを使用した操作の実行

プラグイン・マネージャを使用すると、プラグインのデプロイ、アップグレード、再デプロイおよびアンデプロイが可能です。

図23-6に、プラグイン・マネージャを使用して実行できる操作を示します。

図23-6 プラグイン・マネージャの操作

23.5 プラグインについて

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

- 表示のカスタマイズ

- プラグインの可用性の確認

- プラグインに関する情報の表示

23.5.1 表示のカスタマイズ

この項では、表示をカスタマイズし、表示されるプラグインと列を整理する方法について説明します。

23.5.1.1 表示されるプラグインのカスタマイズ

時間の経過とともに、プラグインをダウンロードしてデプロイするにつれ、リストのプラグインの数が増加します。これらのプラグインをソートして、必要なプラグインのみ(たとえば、使用可能なプラグインのみ、またはデプロイ済のプラグインのみ)を表示できます。

表示をカスタマイズするには、次の手順を実行します。

1. 「表示」メニューから、「プラグイン」を選択します。

2. 「プラグイン」メニューから、次のいずれかのフィルタを選択します。

- すべて: このフィルタを使用すると、使用可能、ダウンロード済およびデプロイ済のプラグインを含むすべてのプラグインを表示できます。

- 使用可能のみ: このフィルタを使用すると、ダウンロードできるプラグインを表示できます。

- ダウンロード済のみ: このフィルタを使用すると、ダウンロードされたプラグインを表示できます。

- デプロイ済のみ: このフィルタを使用すると、デプロイされたプラグインを表示できます。

23.5.1.2 表示される列のカスタマイズ

デフォルトでは、情報の列はほとんど表示されません。オプションで、関心のある他の列を有効にするか、すでに表示されている列を無効にできます。

表示される列をカスタマイズするには、次の手順を実行します。

1. 「表示」メニューから、「列」を選択します。

2. 「列」メニューから、次のいずれかの列フィルタを選択します。

- すべて表示: このフィルタを使用すると、すべての列を表示できます。

- ベンダー: このフィルタを使用すると、ベンダーの情報を表示できます。

- プラグインID: このフィルタを使用すると、プラグインIDを表示できます。

- バージョン: このフィルタには、選択可能な3つのオプションがあります。それらは次のとおりです。

- 最新の使用可能: このフィルタを使用すると、使用できる最新のプラグインを表示できます。

- 最新ダウンロード: このフィルタを使用すると、最近ダウンロードされたプラグインを表示できます。

- 管理サーバー上: このフィルタを使用すると、OMSにデプロイされたプラグインを表示できます。

- 検出プラグインのみの管理エージェント: このフィルタでは、デプロイされた検出プラグインのみを含む管理エージェントが表示されます。

- プラグイン付き管理エージェント: このフィルタでは、デプロイされた任意のプラグインを含む管理エージェントが表示されます。

- 説明: このフィルタでは、プラグインの説明が表示されます。

23.5.2 プラグインの可用性の確認

プラグインの可用性を確認するには、次の手順を実行します。

1. 『Oracle Enterprise Manager Cloud Control管理者ガイド』の説明に従い、自己更新コンソールを設定します。

2. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

3. プラグイン・ページで、表の「最新の使用可能」列で、プラグインが使用可能かどうかを確認します。
使用可能なプラグインのリストをリフレッシュするには、「更新の確認」をクリックします。「更新の確認」をクリックすると、自己更新ページに移動することに注意してください。

23.5.3 プラグインに関する情報の表示

この項では、プラグインに関する詳細と、プラグインに関連する機能について説明します。この項の内容は、次のとおりです。

- プラグイン・リリースとEnterprise Managerプラットフォーム・リリースの違い

- プラグインIDの識別

- デプロイ済プラグインに対して動作保証済のターゲットおよびオペレーティング・システムの表示

- プラグイン依存性の表示

- デプロイ済プラグインの確認

23.5.3.1 プラグイン・リリースとEnterprise Managerプラットフォーム・リリースの違い

プラグインは独立したリリース・サイクルおよびリリース番号を持ち、Enterprise Manager Cloud Control製品のリリースおよびリリース番号と関連がある場合もない場合もあります。

プラグインのリリースは、一般的に、Enterprise Managerのプラットフォームのリリースよりも頻繁に発生します。

図23-7で、プラグイン・リリースの番号付け方法について説明します。

図23-7 プラグイン・リリース番号の書式

図23-8で、Enterprise Managerプラットフォーム・リリースの番号付け方法について説明します。

図23-8 Enterprise Managerコア・プラットフォーム・リリース番号の書式

23.5.3.2 プラグインIDの識別

プラグインのIDを識別するには、次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、表の「プラグインID」列の、目的のプラグインのプラグインIDを書き留めます。
この列が表示されない場合は、「表示」メニューで「列」、「プラグインID」の順に選択します。

図23-9に、Oracle DatabaseプラグインのプラグインIDの識別方法を示します。

図23-9 プラグインIDの識別

23.5.3.3 デプロイ済プラグインに対して動作保証済のターゲットおよびオペレーティング・システムの表示

デプロイ済プラグインに対して動作保証済のターゲットおよびオペレーティング・システムのリストを表示するには、次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、目的のプラグインを選択し、「アクション」メニューから「情報」を選択します。

3. プラグイン情報ページの「一般」タブで、「認証されたターゲット」および「動作保証されているオペレーティング・システム」表の情報を確認します。

23.5.3.4 プラグイン依存性の表示

目的のプラグインの依存性を表示するには、次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、目的のプラグインを選択し、「アクション」メニューから「情報」を選択します。

3. プラグイン情報ページの「依存状態」タブで、表に示されている情報を確認します。

23.5.3.5 デプロイ済プラグインの確認

デプロイ済プラグインを表示および管理するには、「設定」メニューから「拡張性」、「プラグイン」の順に選択します。プラグイン・ページが表示されますが、それは基本的にプラグイン・マネージャ・コンソールです。

目的のプラグインのデプロイ先のOMSインスタンスを識別するには、Enterprise Manager Cloud Controlコンソールを使用して次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、目的のプラグインを選択し、「アクション」メニューから「情報」を選択します。

3. プラグイン情報ページの「管理サーバー」タブで、プラグインのデプロイ先のOracle Management Servicesを確認します。

目的のプラグインのデプロイ先の管理エージェントを識別するには、Enterprise Manager Cloud Controlコンソールを使用して次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、目的のプラグインを選択し、「アクション」メニューから「情報」を選択します。

3. プラグイン情報ページの「管理エージェント」タブで、プラグインのデプロイ先の管理エージェントを確認します。

OMSにデプロイ済のプラグインを識別するには、EM CLIでEMCLIにログインし、次のコマンドを入力します。コマンドによって、OMSにデプロイされたすべてのプラグインのリストが表示されます。

$emcli login

-username=<EM Console Username>

[-password=<EM Console Password>]

[-force]

$emcli list_plugins_on_server

例23-1 OMSにデプロイされたプラグインのサンプル・リスト

example.com:7654_Management_Service

プラグイン名

プラグインID

バージョン(リビジョン)

Oracle Database

oracle.sysman.db

12.1.0.4.0

Oracle Fusion Middleware

oracle.sysman.emas

12.1.0.4.0

Oracle MOS (My Oracle Support)

oracle.sysman.mos

12.1.0.5.0

Oracle Exadata

oracle.sysman.xa

12.1.0.4.0

管理エージェントにデプロイ済のプラグインを識別および表示するには、EM CLIで、次のコマンドを入力します。

$emcli list_plugins_on_agent

[agent_names="agent1,agent2,agent3..."

[-all] [-include_discovery]

例23-2 管理エージェントにデプロイされたプラグインのサンプル・リスト

emcli list_plugins_on_agent -agent_names=agent1.example.com:3872
Lists plug-ins on the agent agent1.example.com

emcli list_plugins_on_agent -agent_names=agent1.example.com:3872,agent2.example.com:3872 -include_discovery
Lists plug-ins on both the agents provided along with their discovery components

emcli list_plugins_on_agent -agent_names='agent*,st*93'
Lists plug-ins on all agents with name matching one of the regular expressions agent* or st*93

emcli list_plugins_on_agent -all
Lists plug-ins on all the management agents.

23.6 プラグインのダウンロード、デプロイおよびアップグレード

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

- プラグインのダウンロード

- Oracle Management Serviceへのプラグインのデプロイ(OMS再起動時間および停止時間の削減)

- Oracle Management Serviceにデプロイ済のプラグインのアップグレード

- Oracle Management Agentへのプラグインのデプロイ

- Oracle Management Agentにデプロイ済のプラグインのアップグレード

23.6.1 プラグインのダウンロード

プラグインをオンライン・モードまたはオフライン・モードでダウンロードできます。オンラインとは、Enterprise Manager Storeへのインターネット接続がある環境のことです。オフラインとは、インターネット接続のない環境のことです。この章の項目は次のとおりです。

- オンライン・モードでのプラグインのダウンロード

- オフライン・モードでのプラグインのダウンロード

- カタログ・アーカイブのインポート

- プラグイン・アーカイブのインポート

23.6.1.1 オンライン・モードでのプラグインのダウンロード

オンライン・モードでプラグインをダウンロードするには、次の手順に従います。

1. 「設定」メニューで、「拡張性」、「自己更新」の順に選択します。

2. 「自己更新」ページの表で「プラグイン」をクリックします。

3. プラグインの更新ページで、ダウンロードできるプラグインを選択し、「ダウンロード」をクリックします。
複数のプラグインの選択はサポートされていません。

4. 「スケジュール・ダウンロード」ダイアログで、ダウンロードをスケジュールする適切なオプションを選択します。即時アクション用にジョブをスケジュールする「即時」も選択できます。ダウンロードが完了したら通知を受けるようにするには、「ダウンロード時1回通知」を選択します。

5. 「選択」をクリックします。
Enterprise Manager Cloud Controlは選択したプラグインをEnterprise Managerストアからソフトウェア・ライブラリへダウンロードするジョブを発行します。

ジョブが正常に発行されたことを確認するダイアログが表示されます。この確認ダイアログで、「ジョブ詳細」をクリックし、ジョブのステータスを追跡できます。

23.6.1.2 オフライン・モードでのプラグインのダウンロード

オフライン・モードでプラグインをダウンロードするには、次の手順に従います。

1. Enterprise Manager Cloud Controlをオフライン・モードに設定します。これを行うには、次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」を選択し、「オフライン・パッチ」を選択します。

2. 「オンライン設定とオフライン設定」タブで、「オフライン」を選択します。

2. 「設定」メニューで、「拡張性」、「自己更新」の順に選択します。

3. 自己更新ページで、「更新の確認」をクリックします。
更新のカタログ・ファイルをダウンロードできるOracleサイトへの次のURLを含んだメッセージが表示されます。

https://updates.oracle.com/Orion/Download/download_patch/p9348486_112000_Generic.zip

4. インターネット接続できるコンピュータから、メッセージに記載されていたURLを使用してカタログ・ファイルをダウンロードします。

5. ダウンロードしたカタログ・ファイルを、プラグインをデプロイする予定のOMSホストまたは管理エージェント・ホストにコピーします。

6. Enterprise Managerにカタログ・ファイルをインポートします。手順については、「カタログ・アーカイブのインポート」を参照してください。

7. 「自己更新」ページの表で「プラグイン」をクリックします。

8. プラグインの更新ページで、ダウンロードできるインポート済更新を選択します。「ダウンロード」をクリックします。
更新をダウンロードできるOracleサイトへのURLを含んだメッセージが表示されます。

9. インターネットに接続されたコンピュータから、前述のURLを使用して更新をダウンロードします。

10. ダウンロードしたファイルを、プラグインをデプロイする予定のOMSホストまたは管理エージェント・ホストにコピーします。

11. Enterprise Managerにダウンロードしたプラグイン・アーカイブをインポートします。手順については、「プラグイン・アーカイブのインポート」を参照してください。

23.6.1.3 カタログ・アーカイブのインポート

カタログ・アーカイブをインポートするには、次の手順に従います。

1. 第23.6.1.2項の説明に従い、カタログ・アーカイブをダウンロードします。

2. 次のemcliコマンドを実行して、ダウンロードしたカタログ・アーカイブをインポートします。

$emcli import_update_catalog

-file="file"

-omslocal

emcli import_update_catalog

-file="file"

-host="hostname"

[-credential_set_name="setname"] | -credential_name="name" -credential_owner="owner"

例23-3 カタログ・アーカイブのインポートのサンプル

$emcli import_update_catalog
-file="/u01/common/p9984818_121000_Generic.zip"
-omslocal
Imports the master catalog file p9984818_121000_Generic.zip. The file must exist on the OMS host. In a multiple OMS setup, the request can be processed by any OMS, so the file should be accessible from the OMS processing the request. This means that the file must be kept on a shared location that is accessible from all the OMS instances.
$emcli import_update_catalog
-file="/u01/common/p9984818_121000_Generic.zip"
-host="host1.example.com"
-credential_set_name="HostCredsNormal"

Imports the master catalog file p9984818_121000_Generic.zip that is present on the host host1.example.com. The host must be a managed host target in Enterprise Manager, and the Management Agent on this host must be up and running. The preferred unprivileged credentials for host host1.example.com are used to retrieve the remote file.

23.6.1.4 プラグイン・アーカイブのインポート

次の場合、プラグイン・アーカイブをOracleソフトウェア・ライブラリにインポートします。

- Oracle以外のプラグイン、つまり、オラクル社以外の会社によって作成されたプラグインをデプロイする場合で、「自己更新」コンソールでダウンロードできない場合。

- 自己更新がオフライン・モードで使用されているときに、エンティティ・アーカイブのその他のタイプをインポートする場合。

プラグイン・アーカイブをインポートするには、次の手順に従います。

1. 前の項の説明に従い、外部アーカイブをダウンロードします。

2. Enterprise Managerコマンドライン(EM CLI)ユーティリティを設定します。これを実行するには、「設定」メニューから、「コマンドライン・インタフェース」をクリックします。Enterprise Managerコマンドライン・インタフェースのダウンロード・ページに説明されている手順に従います。

3. EMCLIのインストール先に応じて、次のいずれかの方法で外部アーカイブをインポートします。

- Enterprise Managerサーバーが、プラグイン・アーカイブ(*.oparファイル)をダウンロードしたシステムにある場合、次のコマンドを実行します。
$emcli import_update

-file=”<path to *.opar file>”

-omslocal

-omslocalフラグは、-fileオプションで指定したプラグイン・アーカイブ・パスがEMサーバーに直接アクセス可能であることを示しています。

- Enterprise Managerサーバーがプラグイン・アーカイブとは別のシステム上にある場合は、次のコマンドを実行します。
$emcli import_update

-file=”<path to *.opar file you created>”

-host="host1.example.com"

-credential_name="host1_creds"

-credential_owner="admin1"

コマンド構文は次のとおりです。

-file: アーカイブを作成したシステム上の*.oparファイルへの絶対パス。

-host: ファイルが使用可能なホスト・ターゲットのターゲット名。

-credential_name: 接続先のリモート・システムにある資格証明の名前。

-credential_owner: 接続先のホスト・システムにある資格証明の所有者。

注意:
前述の手順の代替方法として、次のコマンドを実行することもできます。

$emcli import_update
-file=”<path to *.opar file you created>”
-host="hostname"
-credential_set_name="setname"

-credential_set_name: ホスト・ターゲットに対する管理リポジトリに格納されている優先資格証明のセット名。次のいずれかになります。

- HostCredsNormal: デフォルトの権限のない資格証明セット。

- HostCredsPriv: 権限付きの資格証明セット。

23.6.2 Oracle Management Serviceへのプラグインのデプロイ(OMS再起動時間および停止時間の削減)

複数のプラグインを1つのOMSインスタンスにグラフィカル・インタフェースまたはコマンドライン・インタフェースでデプロイできます。

注意:

- 管理エージェントにデプロイする前に、OMSにプラグインをデプロイする必要があります。

- 複数OMS環境では、プラグイン・マネージャはすべての管理サーバーでのプラグインのデプロイを自動化します。

- プラグインのアップグレードの失敗により、管理リポジトリの一貫性が損われることがあります。オラクル社は、リポジトリ・データベースをアーカイブ・ログ・モードで実行し、バックアップ・ポリシーを整えることをお薦めします。

- デプロイ時間は、管理リポジトリに移入されるデータ量によって、プラグインごとに異なります。第23.6.2.1項に説明されているとおりに、デプロイ・ステータスを監視できるページが表示されます。

- プラグインによってはデプロイメントに、OMSの停止と、その後の再開が必要なものもあります。これは、プラグインのデプロイメント・プロセスの一部として自動的に行われます。

- プラグインのOMSへのデプロイ中に、OMSプラグイン・コンポーネント、検出プラグイン・コンポーネント、および監視プラグイン・コンポーネントがOMSにデプロイされます。

グラフィカル・モードでプラグインをOMSにデプロイするには、次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、デプロイするプラグインを選択します。

注意:
または次の手順に進み、その手順の後でプラグインを選択することができます。

3. 「デプロイ先」メニューから、「管理サーバー」を選択します。

4. 「管理サーバー上のプラグインのデプロイ: プラグイン」ページで、画面下部のプラグイン詳細が正しいことを確認します。また、「追加」をクリックして、プラグインを追加することもできます。

5. 前提条件チェックをスキップするには、「最後に成功した前提条件を使用」チェックボックスを選択します。
このチェック・ボックスは、プラグインが過去24時間以内に前提条件チェックを通っていてデプロイされなかった場合にのみ使用可能です。

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

7. 「管理サーバー上のプラグインのデプロイ: 前提条件チェック」ページで、前提条件チェックが(まだ完了していない場合は)完了するまで待機し、「次」をクリックします。

8. 「管理サーバー上のプラグインのデプロイ: リポジトリ」ページで、管理リポジトリSYSの資格証明を指定します。「名前付き」オプションをクリックし、保存された資格証明を選択するか、または「新規」オプションをクリックして新規に資格証明を入力します。
デプロイが成功すると、新規に指定された資格証明が将来のデプロイのために自動的に保存されます。

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

10. 「管理サーバー上のプラグインのデプロイ: 確認」ページに、プラグインがデプロイされるOMSとOMSのステータス、プラグインが表示されます。すべての詳細が正しいことを検証し、「デプロイ」をクリックします。

サイレント・モードでプラグインをOMSにデプロイするには、次の手順に従います。

1. 次のようにEMCLIにログインします。
$ORACLE_HOME/bin/emcli login -username=sysman

2. emcliクライアントのバージョンが古いためにすべての必要な動詞がない場合は、次のコマンドを実行します。
$ORACLE_HOME/bin/emcli sync

3. プラグインをOMSにデプロイするには、次のコマンドを実行します。
$emcli deploy_plugin_on_server

-plugin="plug-in_id[:version]

[-sys_password=sys_password]

[-prereq_check]"

注意:
プラグインIDの詳細は、第23.5.3.2項を参照してください。

次に例を示します。

$emcli deploy_plugin_on_server -plugin="oracle.sysman.db:12.1.0.2.0;oracle.sysman.emas:12.1.0.2.0"

注意:
プラグインのデプロイの手順は、複数OMS環境でも同じです。Enterprise Managerは単一OMSか複数OMS環境かを自動的に検出し、複数OMS環境の場合は、選択したプラグインをすべてのOMSインスタンスに自動的にデプロイします。
管理サーバーが動作しているプライマリOMSでプラグ・インのデプロイが失敗する場合、まずその問題に対処し、次にそのデプロイメントを再開するか、またはバックアップからシステムをリストアする必要があります。ただし非プライマリOMSでのプラグインのデプロイメントが失敗した場合は、失敗の原因を確認します。修正または回避策がある場合、問題を修正し、同じ手順を再度実行します。システムは、プラグインがデプロイされていないOMSインスタンスを自動的に検出し、そのサーバーにデプロイします。

問題が解決されない場合は、Oracleサポートに連絡してください。

23.6.2.1 Oracle Management Serviceへのプラグインのデプロイメント・ステータスのトラッキング

この項では、停止時間を必要としない、および停止時間を必要とする、プラグインのデプロイを監視する手順について説明します。

停止時間を必要とするプラグインのデプロイおよびアンデプロイ操作のステータスを監視するには、次のコマンドを実行します。

emctl status oms -details

停止時間を必要としないプラグインのデプロイおよびアンデプロイ操作のステータスを監視するには、次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、次のいずれかを実行します。

- 「アクション」メニューから、「デプロイメント・アクティビティ」を選択します。

- プラグインを選択し、このページの下部にある「最近のデプロイメント・アクティビティ」タブをクリックします。または、EMCLIを使用して次のコマンドを実行することもできます。
$emcli get_plugin_deployment_status -plugin_id=<plugin_id>

23.6.3 Oracle Management Serviceにデプロイ済のプラグインのアップグレード

プラグイン・バージョン間のアップグレード、つまり、あるプラグイン・バージョンから別のより高いプラグイン・バージョン、または別のより高いプラグイン・バージョンのリビジョンへのアップグレードが可能です。たとえば、Oracle Databaseプラグイン・バージョン12.1.0.1.0からバージョン12.1.0.2.0へ、またはOracle Databaseプラグイン・バージョン12.1.0.1.0からバージョン12.1.0.2.0 [u120427]へのアップグレードです。

OMSにデプロイされたプラグイン・バージョン間でアップグレードするには、次の手順に従います。

1. 第23.5.2項での説明に従い、Enterprise Managerストアで最新の使用可能なバージョンおよびリビジョンを確認します。

2. 第23.6.1項の説明に従い、ダウンロードします。

3. 第23.6.2項の説明に従い、それらをOMSにデプロイします。

23.6.4 Oracle Management Agentへのプラグインのデプロイ

ホスト・ターゲットの追加ウィザードを使用した管理エージェントのインストール中に、OMSで使用可能なすべてのコア検出プラグインは管理エージェントに自動的にデプロイされます。

検出プラグインの詳細は、第23.5.3項を参照してください。

管理エージェントのインストール後に、追加のプラグインをデプロイする場合は、次の手順に従います。

1. 自己更新コンソールを設定します。

2. プラグインがEnterprise Managerストアで使用可能などうかを確認します。手順については、第23.5.2項を参照してください。

3. 使用可能なプラグインをダウンロードします。手順については、第23.6.1項を参照してください。

4. ダウンロードしたプラグインを管理エージェントにデプロイします。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、デプロイするプラグインを選択します。

3. 「デプロイ先」メニューから、「管理エージェント」を選択します。

4. 管理エージェントへのプラグインのデプロイ・ダイアログ・ボックスに示される手順に従います。

5. 「デプロイ」をクリックします。

プラグインをEM CLIでデプロイするには、次のコマンドを実行します。

$emcli deploy_plugin_on_agent

-agent_names="agent1[;agent2...]"

-plugin="plug-in_id[:version"]

[-discovery_only]

プラグ・インの最新の修正をデプロイするには、追加の引数allow_revision_updateを使用して前述のコマンドを実行します。

23.6.4.1 Oracle Management Agentへのプラグインのデプロイメント・ステータスのトラッキング

管理エージェントへのプラグインのデプロイメント・ステータスをトラッキングするには、第23.6.2.1項を参照してください。

23.6.5 Oracle Management Agentにデプロイ済のプラグインのアップグレード

プラグイン・バージョン間のアップグレード、つまり、あるプラグイン・バージョンから別のより高いプラグイン・バージョン、または別のより高いプラグイン・バージョンのリビジョンへのアップグレードが可能です。たとえば、Oracle Databaseプラグイン・バージョン12.1.0.1.0からバージョン12.1.0.2.0へ、またはOracle Databaseプラグイン・バージョン12.1.0.1.0からバージョン12.1.0.2.0 [u120427]へのアップグレードです。

注意:
使用環境にすでにインストール済の管理エージェントでのみ、プラグイン・バージョンおよびリビジョンをアップグレードします。
新しい管理エージェントでプラグインを明示的にデプロイするか、ターゲットを昇格させると、OMSからプラグインの最新のバージョンおよびリビジョンが自動的に含まれます。

管理エージェントにデプロイされたプラグイン・バージョン間でアップグレードするには、次の手順に従います。

1. 第23.5.2項での説明に従い、Enterprise Managerストアで最新の使用可能なバージョンおよびリビジョンを確認します。

2. 第23.6.1項の説明に従い、ダウンロードします。

3. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

4. プラグイン・ページで、アップグレードするプラグインを選択します。

5. 「デプロイ先」メニューから、「管理エージェント」を選択します。

6. 「管理エージェント上のプラグインをデプロイします」ダイアログで、アップグレード先のプラグインのバージョンまたはリビジョンを選択し、「続行」をクリックします。

7. プラグインをアップグレードする目的の管理エージェントを選択し、「続行」をクリックします。「次へ」をクリックします。さらに、「デプロイ」をクリックします。

8. 「確認」ダイアログで「「閉じる」」をクリックします。

23.7 プラグインのアンデプロイ

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

- Oracle Management Serviceからのプラグインのアンデプロイ

- Oracle Management Agentからのプラグインのアンデプロイ

23.7.1 Oracle Management Serviceからのプラグインのアンデプロイ

プラグインをOMSからアンデプロイするには、次の手順に従います。

1. まず、すべての管理エージェントからすべてのプラグインをアンデプロイします。これを行うには、第23.7.2項に示される手順に従います。

2. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

3. プラグイン・ページで、アンデプロイするプラグインを選択し、「アクション」メニューから「アンデプロイ元」、「管理サーバー」の順に選択します。

4. 「管理サーバーからのプラグインのアンデプロイ」ダイアログで、管理リポジトリSYSパスワードを入力して、「続行」をクリックします。さらに、「アンデプロイ」をクリックします。

5. 「確認」ダイアログで「「閉じる」」をクリックします。
アンデプロイ操作を監視するには、「ステータスの表示」をクリックします。

プラグインをEM CLIでアンデプロイするには、次のコマンドを使用します。

$emcli undeploy_plugin_from_server

-plugin="plug-inId"

[-sys_password="sys_password"]

注意:
メタデータ・プラグインがアンデプロイ/再デプロイされたら、次のコマンドを実行することをお薦めします。コマンドは、各OMS環境インスタンスで実行する必要があります。
$emcli metric_control -command=flush_metadata_cache

Enterprise Managerシステム全体ではなく、OMSからプラグインのみをアンデプロイする場合、Enterprise Manager Cloud Controlコンソール内のプラグイン・ページを使用します。プラグインのみのアンデプロイにrunInstallerは使用しないでください。

23.7.2 Oracle Management Agentからのプラグインのアンデプロイ

プラグインを管理エージェントからアンデプロイするには、次の手順を実行します。

注意:

- 次の手順は、廃止および非推奨のプラグインにも適用可能です。

- プラグインの管理エージェントからのアンデプロイでは、プラグインにより監視されていたすべてのターゲットが削除されます。

- プラグインの管理エージェントからのアンデプロイでは、管理エージェントが再起動します。管理エージェントは停止中はターゲットを監視しません。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. プラグイン・ページで、アンデプロイするプラグインを選択し、「アクション」メニューから「アンデプロイ元」、「管理エージェント」の順に選択します。

3. 「管理エージェントからのプラグインのアンデプロイ」ダイアログで、「追加」をクリックし、プラグインをアンデプロイする管理エージェントを追加します。「続行」をクリックします。「アンデプロイ」をクリックします。

4. 「確認」ダイアログで「「閉じる」」をクリックします。
アンデプロイ操作を監視するには、「ステータスの表示」をクリックします。

注意:
プラグインの管理エージェントからのアンデプロイでは、プラグインにより監視されていたすべてのターゲットが削除されます。
プラグインの管理エージェントからのアンデプロイでは、管理エージェントが再起動します。管理エージェントは停止中はターゲットを監視しません。

プラグインをEM CLIを使用してアンデプロイするには、次のコマンドを使用します。

$emcli undeploy_plugin_from_agent

-plugin="pluginId"

{-agent_names="agent1[;agent2...]" | -all_discovery_only_agents}

検出プラグインのみがデプロイされているすべての管理エージェントから、すべてのバージョンのoracle.sysman.db2プラグインをアンデプロイするには、次のコマンドを使用します。

$emcli undeploy_plugin_from_agent -plugin=oracle.sysman.db2 -all_discovery_only_agents

23.8 プラグインの高度な操作

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

- Oracle Management Agentへのプラグインの再デプロイ

- 管理エージェントのデプロイまたはアップグレード中にプラグイン・パッチをデプロイ(カスタム・プラグイン更新の作成)

23.8.1 Oracle Management Agentへのプラグインの再デプロイ

re-deployオプションを使用すると、Oracle Management Agentにプラグインを再デプロイできます。再デプロイのプラグイン・オプションは、管理エージェントで同じプラグインを再構成し、構成の詳細を変更することはありません。

$emcli redeploy_plugin_on_agent

{-agent_names="agent1[;agent2...]" | -group_name="group1"}

-plugin="plug-in_id:version"

[-redeploy_noprompt]

注意:
このオプションを使用する場合、既存のプラグイン・ホームは上書きされ、適用済のパッチはすべて失われることに注意してください。
再デプロイ・ウィザードに次の警告メッセージが表示されます。

プラグインを再デプロイすると、プラグインの既存のOracleHomeが上書きされ、プラグインOracleHomeに適用済のパッチはすべて失われます。

ただし、-redeploy_nopromtオプションを有効化すると、警告メッセージは表示されません。

続行するには「はい」をクリックします。

プラグインのカスタム・プラグイン更新がない場合は、複数の管理エージェントに再デプロイ・コマンドを使用できません。

注意:
メタデータ・プラグインが再デプロイされた後、次のコマンドを実行することをお薦めします。
$emcli metric_control -command=flush_metadata_cache

コマンドは、すべてのOMSインスタンスで実行する必要があります。

23.8.2 管理エージェントのデプロイまたはアップグレード中にプラグイン・パッチをデプロイ(カスタム・プラグイン更新の作成)

新しいプラグインがリリースされると、自己更新を使用してダウンロードできます。管理エージェント・プラグインに不具合がある場合、オラクル社はO-patch形式のパッチをリリースします。管理エージェントでのターゲットの検出中にプラグインが自動的にデプロイされると、そのプラグインのパッチは各プラグインに手動で適用する必要があります。

カスタム・プラグイン更新は、プラグインのユーザー・コピーおよびそのプラグインに適用されるパッチです。カスタム・プラグイン更新の作成コマンドを使用すると、自己更新で適用されるパッチとともにプラグインのカスタム・コピーを作成できます。一度パッチを適用すると、プラグインのカスタム・プラグイン更新をその管理エージェントで作成できます。カスタム・プラグイン更新は、ベース・プラグイン・バイナリとともに、そのOracleホームで適用されたすべてのパッチを持つそのプラグインのゴールド・イメージになります。

カスタム・プラグイン更新が作成された後は、UIまたはEMCLIを使用する、管理エージェント上のプラグインに対するプラグイン・デプロイメント操作で、オラクル社提供のバージョンのかわりに新しいカスタム・コピーがデプロイされます。このため、エージェントの各プラグイン・ホームでプラグイン・パッチを手動で再適用する必要はありません。このカスタム・プラグイン・イメージは、アップグレード・アクティビティのエージェント・デプロイによっても使用され、これらのエージェントにデプロイされるプラグインはパッチが含まれた状態になります。

カスタム・プラグイン更新の作成には2つの方法があります。次の項で2つの方法について説明します。

- EMCLIを使用したカスタム・プラグイン更新の作成(推奨)

- EDKを使用したカスタム・プラグイン更新の作成

23.8.2.1 EMCLIを使用したカスタム・プラグイン更新の作成

カスタム・プラグイン更新を作成するには、次の手順に従います。

1. 目的のプラグインがすでにデプロイされている稼働中のテスト管理エージェントを選択します。このプラグインに適用するパッチを適用します。

2. 必要なテストを実行します。

3. 次のコマンドを使用して、カスタム・プラグイン更新を作成します。
$emcli create_custom_plugin_update

-agent_name="agent_name"

-plugin_id="plugin_id"

注意:
リポジトリに保存されている、現在のカスタム・プラグイン更新を上書きおよび更新するには、overwriteオプションを使用します。
$emcli create_custom_plugin_update

-agent_name="agent_name"

-plugin_id="plugin_id"

[-overwrite]

このコマンドは、選択したプラグインがデプロイされている既存の管理エージェントから、カスタム・プラグイン更新を作成およびインポートします。カスタム・プラグイン更新は、管理エージェントへの以降のすべてのプラグインのデプロイメントで、Oracle提供のバージョンのかわりに使用されます。

カスタム・プラグイン更新は、プラグイン・タイプに従って作成されます。カスタム・プラグイン更新が作成され、3日後にパッチが適用された場合、そのパッチを含めるためにカスタム・プラグイン更新を再作成する必要があります。

作成済のすべてのカスタム・プラグイン更新のリストを表示するには、次のコマンドを実行します。

$emcli list_custom_plugin_updates

特定のカスタム・プラグイン更新に含まれるパッチのリストを表示するには、次のコマンドを実行します。

$emcli list_patches_in_custom_plugin_update -plugin=<plugin_id>:<version> [-discovery]

プラグイン・マネージャ・コンソールでプラグインを選択すると、カスタム・プラグイン更新が存在する場合は、バージョン識別子の横にアイコンが表示され、その特定のプラグイン・バージョンがその環境でカスタマイズされていることがパッチのリストとともに示されます。「カスタム・プラグイン更新」アイコンを示します。カスタム・プラグイン更新が存在する場合、管理エージェントによってデプロイメントおよびアップグレードに自動的に使用されます。

図23-10 「カスタム・プラグイン更新」アイコン

「カスタム・プラグイン更新」アイコンをクリックすると、カスタム・プラグイン更新の情報を表示するページが表示されます。

23.8.2.2 EDKを使用したカスタム・プラグイン更新の作成

EDKを使用してカスタム・プラグイン更新を作成するには、次の手順に従います。

1. 管理エージェント・ホストで、UIまたはEMCLIを使用してEDKをダウンロードします。
UIを使用してEDKをダウンロードするには、「設定」メニューから「拡張性」、「開発キット」の順に選択します。

EMCLIを使用してEDKをダウンロードするには、次のコマンドを実行します。

$emcli get_ext_dev_kit

2. 次のコマンドを実行します。
$empdk create_custom_plugin_update -out_dir <output dir>

-agent_state_dir <agent_state_dir>

-agent_oracle_home <agent_oracle_home>

-plug_id <plugin_id>

empdkコマンドのヘルプについては、次のコマンドを実行します。

$/empdk -help

プラグイン更新が.zipファイルとしてローカル・ディレクトリに保存されます。.zipファイルをOMSインスタンスにコピーする必要があります。一度.zipファイルを作成すると、OMSホームから次のコマンドを実行してカスタム・プラグイン更新をインポートします。

$emcli import_plugin_update -archive=<archive path>

プラグイン・マネージャ・コンソールでプラグインを選択すると、カスタム・プラグイン更新が存在する場合は、バージョン識別子の横にアイコンが表示され、その特定のプラグイン・バージョンがその環境でカスタマイズされていることがパッチのリストとともに示されます。

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

この項では、プラグイン関係の問題のトラブルシューティングについて説明します。この項の内容は、次のとおりです。

- プラグイン・ホームについて

- OMSプラグインのデプロイメントおよびアップグレードの問題のトラブルシューティング

- OMSプラグインのデプロイメントの問題のトラブルシューティング

- OMSプラグイン・アップグレードのロールバックおよび再開

- 管理エージェント・プラグインのデプロイメント、アップグレードおよびブロックの問題のトラブルシューティング

- 管理エージェント・プラグインのデプロイメントの問題のトラブルシューティング

- 管理エージェント・プラグインのアップグレードの問題のトラブルシューティング

- 管理エージェントのプラグインの不一致の解決

- すべてのプラグインの不一致を解決するプラグインの不一致ジョブの実行

23.9.1 プラグイン・ホームについて

プラグイン・ホームは、基本的に、Oracleホームの下にあるプラグイン専用のディレクトリです。OMSにデプロイされたプラグインのプラグイン・ホームは、管理エージェントにデプロイされたプラグインのプラグイン・ホームとは異なります。プラグイン・ホームはoraInventoryに登録されているため、手動で削除または操作しないでください。

図23-11は、Enterprise Manager Cloud Control 13cリリース1 (OMS用)にデプロイされたプラグインのプラグイン・ホーム・ディレクトリを示します。

図23-11 Enterprise Manager Cloud Control 13cリリース1 (OMS用)のプラグイン・ホーム

図23-12に、13cリリース1の管理エージェントにデプロイされたプラグインのプラグイン・ホーム・ディレクトリを示します。

図23-12 Oracle Management Agent 13cリリース1のプラグイン・ホーム

23.9.2 OMSプラグインのデプロイメントおよびアップグレードの問題のトラブルシューティング

新しいプラグインのデプロイメントが失敗した場合、システムは自動的にリカバリします。自動リカバリが完了すると、すべてのOMSインスタンスが再起動されます。既存のプラグインのアップグレードが失敗した場合、手動のシステム・リカバリが必要です。

この項では、次の項目に関連したトラブルシューティングのヒントを示します。

- OMSプラグインのデプロイメントの問題のトラブルシューティング

- OMSプラグイン・アップグレードのロールバックおよび再開

23.9.2.1 OMSプラグインのデプロイメントの問題のトラブルシューティング

OMSへのプラグインのデプロイメントが失敗した場合、まず、次のコマンドを使用してデプロイメントの詳細を確認します。

- OMSが停止している場合は、次のコマンドを使用します。
$emctl status oms -details

- OMSが実行されている場合は、次のコマンドを使用します。
$emcli get_plugin_deployment_status

注意:
OMSのステータスが表示されたら、出力に表示されるログ・ファイルを確認します。
リカバリが失敗したときのために、リポジトリのバックアップをとることをお薦めします。

次の場所にあるplugincaログ・ファイルを確認します。これらを使用して問題をデバッグし、Oracleサポートへサービス・リクエストを出す場合、これらをサービス・リクエストに必ず追加してください。

$<OMS_HOME>/cfgtoollogs/pluginca/*

注意:
既存の実行中のOMSインスタンスをクローニングして追加のOMSをインストールする場合、ソースOMSにデプロイされたプラグインもクローニングされたOMSに自動的に継承されます。したがって、クローニングされたOMSにプラグインを再デプロイする必要はありません。
複数OMS環境の場合、ログ・ファイルのパスのOMS_HOMEは、エラーが発生したOMSのルート・フォルダを示します。

追加のOMSをインストールする方法の詳細は、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

23.9.2.2 OMSプラグイン・アップグレードのロールバックおよび再開

プラグインのアップグレードが失敗した場合、次のいずれかを実行します。

- 現在の管理リポジトリからリカバリする可能性があるか調べるために、サービス・リクエストを出します。

- 管理リポジトリの最新のバックアップにロールバックします。

- 管理リポジトリのバックアップを取っていない場合、プラグインのアップグレードを失敗させた問題を診断して解決します。
次のコマンドを実行し、プラグインのアップグレードを再開します。

$<OMS_HOME>/bin/emctl resume_plugin_upgrade

このコマンドは最後に失敗したアップグレード・セッションを自動的に検出し再開します。プラグインのアップグレードが成功すると、OMSは自動的に再起動します。同じデプロイメントIDが操作の現在のステータスで更新されます。複数OMS環境の場合、プラグインのアップグレードは、最初のOMSで発生し、次に他のすべての追加OMSインスタンスで発生します。

- フラッシュバックが有効な場合、セクション番号が出力されます。

23.9.3 管理エージェント・プラグインのデプロイメント、アップグレードおよびブロックの問題のトラブルシューティング

この項では、次の項目に関連したトラブルシューティングのヒントを示します。

- 管理エージェント・プラグインのデプロイメントの問題のトラブルシューティング

- 管理エージェント・プラグインのアップグレードの問題のトラブルシューティング

- 管理エージェントのプラグインの不一致の解決

- すべてのプラグインの不一致を解決するプラグインの不一致ジョブの実行

23.9.3.1 管理エージェント・プラグインのデプロイメントの問題のトラブルシューティング

プラグインの管理エージェントへのデプロイが失敗した場合、次の場所にあるログ・ファイルを確認します。

agent_inst/sysman/log/*

agent_inst/sysman/registry.xml

agent_inst/install/logs/*

23.9.3.2 管理エージェント・プラグインのアップグレードの問題のトラブルシューティング

プラグインのアップグレードが失敗した場合、次の場所にあるログ・ファイルを確認します。

- UIを使用してログ・ファイルを確認するには、次の手順に従います。

1. 「設定」メニューから「拡張性」、「プラグイン」の順に選択します。

2. 目的のプラグインを選択し、「最近のデプロイメント・アクティビティ」タブに表示される情報を確認します。

3. 目的の管理エージェントの「アクション」列にあるリンクをクリックします。「デプロイメント・ステップ」タブからジョブ名を選択します。ジョブ名を選択すると、ジョブ詳細ウィザードが開きます。

- 管理エージェントのアップグレードおよびデプロイメントの詳細ログは、次の場所で入手できます。
agent_inst/install/logs/agentplugindeploy_N.log

前述の場所のNは内部IDを表します。その場所で、最新のログ・ファイルを確認します。

- サービス・リクエストに入力すると同時に、次のログ・ファイルをアップロードします。
agent_inst/install/logs/*

agent_inst/sysman/log/*

agent_inst/sysman/registry.xml

23.9.3.3 管理エージェントのプラグインの不一致の解決

管理エージェントとOMSでプラグイン・バージョンの不一致がある状況で、管理エージェントを再起動(バウンス)すると、管理エージェントはブロック状態になります。

管理エージェントがプラグインの不一致により「ブロック」状態にある場合、次の手順に従って、不一致エラーを解決します。

1. 「設定」メニューから、「Cloud Controlの管理」を選択し、「エージェント」をクリックします。

2. 「ステータス」列で、「ブロック」状態の管理エージェントを検索します。

3. 管理エージェント名のリンクをクリックして、エージェント・ホームページを開きます。

4. 「サマリー」ペインで、「ステータス」行を検索し、「ブロック」の横にある「不一致の解消」アイコンをクリックします。

5. 「プラグインの不一致」ページで、エージェントで検出されたすべてのプラグインの不一致を確認し、「不一致の解消」をクリックします。

6. 「確認」ポップアップ・ウィンドウで、「OK」をクリックします。

ステータスとともに確認メッセージが表示されます。

23.9.3.4 すべてのプラグインの不一致を解決するプラグインの不一致ジョブの実行

管理エージェントとOMSでプラグイン・バージョンの不一致がある状況で、管理エージェントを再起動(バウンス)すると、管理エージェントはブロック状態になります。

次の手順に従ってジョブを実行して、管理エージェントのプラグインの不一致を検出し、不一致がある場合はその問題を解決します。

1. 「エンタープライズ」メニューから、「ジョブ」を選択し、「アクティビティ」をクリックします。

2. 「ジョブの作成」をクリックします。

3. 「ジョブ・タイプ」列から「プラグインの不一致チェック」を選択し、「選択」をクリックします。

4. 「名前」フィールドに、ジョブの名前を入力します。

5. 「ターゲット」セクションで、「追加」をクリックします。

6. ジョブを実行する管理エージェントを選択し、「選択」をクリックします。

7. 「パラメータ」タブをクリックします。

8. 不一致の修正ドロップダウン・リストから、「True」を選択します。

注意:
不一致の修正フィールドが「True」に設定されている場合、プラグインの不一致が検出されると選択された管理エージェントがジョブによって停止されます。このオプションを設定する際には注意してください。

9. 「発行」をクリックして、ジョブを実行します。

10. ジョブが完了したら、ジョブ名のリンクをクリックして、「ジョブ」ページを開きます。
出力ログには、ジョブ実行の詳細、およびプラグインの不一致(ある場合)を解決するために実行されたアクションが表示されます。

24 Oracle Management Serviceとリポジトリへのパッチ適用

重要:
この章で説明するパッチ適用の手法は、Enterprise Manager Cloud Controlリリース13.1.0.0以上でのみ使用できます。

OMSPatcherでは、特定の環境に基づいてカスタムのパッチ適用手順を生成して、そのパッチを自動的に適用することによって、パッチ適用プロセスを自動化します。

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

- OMSPatcherの自動化

- 必須OMSPatcherパラメータ

- OMSPatcherの実行の前提条件

- OMSPatcherの使用

24.1 OMSPatcherの自動化

OMSPatcherを使用すると、一般的なOMS構成(コア、プラグイン・ホーム)に最小限の操作で自動的にパッチを適用できます。

OMSPatcherは次のような多くのパッチ適用前チェックを実行します。

- 構成ベースの前提条件チェック

- パッチベースのバイナリ前提条件チェック

OMSPatcherはエンドツーエンドの構成パッチ適用を実行します。構成パッチ適用は、構成に基づいてターゲットにパッチを適用するプロセスです。構成情報をパッチ適用プロセスに組み込むことにより、OMSPatcherは手順のほとんどを自動化し、パッチ適用タスクの単純化を可能にしています。

24.1.1 サポートされるOMS構成およびOMSPatcherパッチ適用機能

- 単一OMS – システムの単一OMSインスタンスから実行されるOMSアプリケーション。OMSPatcherはパッチ適用およびデプロイメント操作を実行します

- 複数OMS – 複数のマシンで実行されるOMSアプリケーション。OMSはOracle WebLogicドメインおよび個別の管理対象サーバーによって接続されます。管理対象サーバーと単一マシンにある個別のOMSビットの間には、1対1のマッピングがあります。OMSPatcherは、UNIXベースのシステム用に、自動生成されたbashスクリプト(OMSインスタンスごとに1つ)を提供します。Windowsベースのシステムの場合は、コンテキスト依存の手順(テキストおよびHTML)のみが提供されます。どちらのシステムの場合でも、管理者はOMSPatcherにより提供される手順に従う必要があります。

- 単一インスタンス・データベースまたはReal Application Cluster - 共有またはReal Application Cluster (RAC)

例: 複数OMSシステム

次の図は複数OMSデプロイメントを示しています。次の用語が使用されています。

- 管理者: パッチをOMSのコアおよびプラグイン・ホームにインストールしている個人。

- ローカルOMS: 管理者がOMSPatcherを実行するOMSインスタンス。

- リモートOMS: 管理者がパッチ適用操作を開始していない、(ローカルOMSと同じOMSドメイン内の)他のマシン上のOMSインスタンス。

図24-1 単純な複数OMSシステム

単一OMSシステム(プライマリ)の場合、OMSPatcherがパッチ適用手順を実行します。複数OMSのUNIXシステムでは、OMSPatcherは実行用のbashスクリプトをOMSインスタンスごとに1つずつ生成します。これらのスクリプトを見つけるには、OMSPatcherにより提供される手順に従います。複数OMSのWindowsシステムの場合、OMSPatcherは、環境に合せてカスタマイズされたパッチ適用手順/コマンドをテキストおよびHTML形式で生成します。管理者はこれらの手順を実行して、様々なOracle Management Serviceにパッチを適用する必要があります。

24.1.2 OUIインベントリ構成

ターゲット(または)インスタンスベースの構成とは別に、OMSPatcherは、コアおよびプラグインOracleホームとしてOracle Universal Installer (OUI)インベントリで確立されたインストールの構成関連を活用します。OUIインベントリからのOMS 13cホームは一般的に次のように編成されています。

<Middleware Home>
|_____<CORE_BITS>
|_____<PLUGINS_DIRECTORY>
|_____oracle.sysman.db.oms.plugin_13.1.0.0.0
|_____oracle.sysman.emas.oms.plugin_13.1.0.0.0
|_____oracle.sysman.mos.oms.plugin_13.1.0.0.0
.
.
.

24.1.3 サポートされるパッチの形式

Enterprise Manager リリース12.1.0.3から、Enterprise Managerのパッチは、パッチ自動化をサポートするためにシステム・パッチ形式に変換されました。

システムパッチとは

システム・パッチには複数のサブパッチが含まれ、それらの場所はパッチの最上位レベル・ディレクトリ内のbundle.xmlというファイルによって決定されます。サブパッチは、OMSのコアおよびプラグイン・ホーム編成に対応するシステムの別のサブシステム用です。

標準的なシステム・パッチの形式は次のように編成されています。

<System patch location - directory>
|_____ Readme.txt (or) Readme.html
bundle.xml
automation
|_____ apply_automation.xml
|_____rollback_automation.xml
Sub-patch1
|_____ etc
|_____config
|_____ inventory.xml
|_____ actions.xml
|_____ artifact_apply.xml
|_____ artifact_rollback.xml
|_____ files/Subpatch1 'payload'
Sub-patch2
|_____ etc
|_____config
|_____ inventory.xml
|_____ actions.xml
|_____ artifact_apply.xml
|_____ artifact_rollback.xml
|_____ files/Subpatch1 'payload'

Enterprise Manager release 12.1.0.2以前では、OMSPatcherはリリース済個別パッチではサポートされていません。これらの古いリリースについては、OPatchを使用してパッチのREADME手順に従う必要があります。

24.1.4 サポートされるパッチ適用手法

OMSPatcherは、自動化のないシステム・パッチについてのみローリング・モードをサポートします(OMSPatcherによるバイナリ専用パッチ適用)。他のすべてのアーティファクト(MRS、SQL)については、OMSPatcherは、完全なシステム停止のパッチ適用操作のみをサポートします。

サポートされるパッチ適用手法の明示的な情報は、パッチのREADMEを参照してください。

24.2 必須OMSPatcherパラメータ

Enterprise Manager OMSのOMSPatcherは、パッチ適用操作の実行時に次の入力パラメータを要求します。これらのパラメータは、Enterprise Managerのインストール時に決定されています。

- Oracle WebLogic管理サーバーのURLとポート番号

- Oracle WebLogic管理サーバーのユーザー名

- Oracle WebLogic管理サーバーのパスワード

OMSPatcherでは各パッチ適用操作に対してこの入力が要求されるため、WebLogic暗号化APIを使用してユーザー名およびパスワードを暗号化し、OMSPatcherのapplyおよびrollback操作の実行時にプロパティ・ファイルを使用してこの情報を渡す機能がOMSPatcherで提供されています。次の項では、プロパティ・ファイルの作成方法を説明します。

24.2.1 プロパティ・ファイルの作成

OMSPatcherを使用して実行される自動パッチ適用機能は、パッチ適用および構成検出操作の入力として、WebLogic管理サーバーのURLおよび資格証明を必要とします。主に、WebLogic管理サーバーはOMSインスタンスがデプロイされる管理対象サーバーを管理するホストです。OMSへのパッチの適用時に要求されるたびに資格証明を設定したくない場合、プロパティ・ファイルを更新できます。OMSPatcherでは、プロパティ・ファイルのオプションを使用して入力を繰返し指定することができます。

注意:
プライマリOMSおよびスタンバイOMSのプロパティ・ファイルは、別のドメインにあるため異なります。

OMSPatcherプロパティ・ファイルを作成するには、次の手順を実行します。

1. WebLogicの暗号化構成およびキー・ファイルを作成するために次のスクリプトを実行します。
UNIXの場合:

$ OMSPatcher/wlskeys/createkeys.sh -oh <full path of platform home> -location <location to put the encrypted files>

Windowsの場合:

$ OMSPatcher\wlskeys\createkeys.cmd -oh <full path of platform home> -location <location to put the encrypted files>

要求されたら、OMSインスタンスがデプロイされる管理対象サーバーを管理するOracle WebLogic管理サーバーの資格証明を入力します。2つのファイルはconfigおよびkeyというファイル名で生成されます。

2. 次のエントリでプロパティ・ファイルを作成します。:

AdminServerURL=t3s://<host address from where admin server is running>:<port of the admin server>
AdminConfigFile=<'config' file location>
AdminKeyFile=<'key' file location>

管理サーバーのホスト・アドレス値およびポート値は、次のemctlコマンドをOracleホームで実行して見つけることができます。

次に、(前述のガイドラインによって構築された)プロパティ・ファイルの表示例を示します。

AdminServerURL=t3s://my_admin_server.oracle.com:7101AdminConfigFile=/scratch/patch/oms_install_dir/middleware/oms/config/configAdminKeyFile=/scratch/patch/oms_install_dir/middleware/oms/config/key

注意:
WebLogic管理サーバーのURL詳細を検索するには、パッチを適用するOMSホーム上で、次のコマンドを実行します。
UNIXの場合:

$ORACLE_HOME/bin/emctl status oms -details

Windowsの場合:

%ORACLE_HOME%\bin\emctl.bat status oms -details

コマンド出力にはWebLogic管理サーバーの詳細が表示されます。これらの出力の詳細でURLを構築する方法の例は次のとおりです。

例:

WLS Domain Information

Domain Name : GCDomain
Admin Server Host : my_wls.oracle.com
Admin Server HTTPS Port: 7103

管理者サーバーのURLを構成するには、次の構文を使用します。

t3s://<admin server host>:<port>

この例では、URLは次のように変換されます。

t3s://my_wls.oracle.com:7103

24.3 OMSPatcherの実行の前提条件

OMSPatcherパッチ適用セッションの実行前に、次の構成およびインベントリベースの前提条件を満たしていることを確認する必要があります。OMS自動化のために守る必要がある構成ベースの条件は、次のとおりです。

- Enterprise Managerソフトウェア・ライブラリを構成する必要があります。

- 管理対象サーバーを通して(現在パッチを適用する)OMSインスタンスを制御するOracle WebLogic管理サーバーが稼働中である必要があります。

- OMS管理リポジトリとリスナーを含むOracle Databaseが稼働していることを確認します。

- 各ホストのOMSプラットフォームに最新バージョンのOPatchがあることを確認します。最新のOPatchのリリース・バージョンは13.6.0.0.0で、My Oracle Supportから使用可能です。
最新のOPatchバージョンがない場合は、次のURLのMy Oracle Supportノート224346.1の手順に従います。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=224346.1

- パッチのREADMEを確認し、パッチおよびパッチ適用手法に基づいて実行する固有の前提条件があるかどうか判断します。

システム前提条件の確認

すべての前提条件の確認で問題がなく、OMSPatcherパッチ適用セッション中にエラーが発生しないことを確認するために、各OMSインスタンス(OMSシステム内)で次のコマンドを実行することをお薦めします。

$<Middleware Home>/OMSPatcher/omspatcher apply <PATCH_LOC> -analyze

システム・パッチの場所から実行する必要があります(apply操作の場合)

注意:
OMSPatcher apply -analyzeを実行すると、OMSシステムを停止する必要がありません。

注意:
選択したパッチ適用手法に指定されているパッチのREADMEおよび手順を確認します。

または

$<Middleware Home>/OMSPatcher/omspatcher rollback -analyze -id <comma (,) separated list of sub-patches to be rolled back for System patch>

注意:
すべてのサブパッチをまとめてロールバックするには、すべて同じシステム・パッチからのサブパッチである必要があります。

例24-1 OMSPatcher rollback -analyzeの出力

-------------------------------

bash-3.2$ OMSPatcher/omspatcher rollback -id 1111137 -analyze
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/mw
Log file location  : /scratch/mw/cfgtoollogs/omspatcher/1111137_Nov_11_2015_22_54_57/rollback2015-11-11_22-54-57PM_1.log

OMSPatcher log file: /scratch/mw/cfgtoollogs/omspatcher/SystemPatch/omspatcher_2015-11-11_22-55-02PM_analyze.log

Please enter OMS weblogic admin server URL(t3s://myserver.myco.com:7101):>
Please enter OMS weblogic admin server username(weblogic):>
Please enter OMS weblogic admin server password:>

Sub-patch(es) " 1111137 " are part of the OMS System patch.
Oracle Home: /scratch/mw, Sub-patch(es): [1111137, 1111126]
Do you want to rollback sub-patch(es) "1111137" only? [y|n]
y
User Responded with: Y

Configuration Validation: Success

Running rollback prerequisite checks for patch(es) "1111137" and Oracle Home "/scratch/mw"...
Sub-patch(es) "1111137" are successfully analyzed for Oracle Home "/scratch/mw"

Complete Summary
================

All log file names referenced below can be accessed from the directory "/scratch/mw/cfgtoollogs/omspatcher/2015-11-11_22-54-57PM_SystemPatch_1111192_1"

Prerequisites analysis summary:
-------------------------------

The following sub-patch(es) are rollbackable:

Featureset   Sub-patches                Log file
----------   -----------                --------
oracle.sysman.top.oms       1111137   1111137_RollbackPrereq2015-11-11_22-55-25PM_2.log

Log file location: /scratch/mw/cfgtoollogs/omspatcher/SystemPatch/omspatcher_2015-11-11_22-55-02PM_analyze.log

OMSPatcher succeeded.
bash-3.2$

注意

注意:
分析が終了すると、OMSPatcherログを参照して、OMSPatcherによって分析以外のモードで実行される手順を確認できます。ログ・ファイルには、詳細手順を含むHTMLおよびテキスト出力ファイルHTMLへの参照が含まれます。

24.4 OMSPatcherの使用方法

OMSPatcherは、パッチを適用しているOMSのプラットフォーム・ホームから実行する必要があります。ORACLE_HOME環境変数は、プラットフォーム・ホームとして設定するか、OMSPatcherの-ohオプションを使用して指定する必要があります。次に例を示します。

<Middleware Home>/OMSPatcher/omspatcher apply <patch>

最低限必要なOMSPatcherのバージョン: 13.6.0.0.0

最新バージョンのOPatchがあることの確認

OMSPatcherは、OPatchユーティリティを使用してパッチを適用します。このため、すべてのOMSインスタンス・プラットフォーム・ホームに最新バージョンのOMSPatcherおよびOPatchがあることを確認する必要があります。システムにあるOPatchのバージョンが不明な場合、次のコマンドを実行してください。

<Middleware Home>/OMSPatcher/omspatcher -version

最新バージョンのOPatchをダウンロードするには、次の場所のMy Oracle Supportノート224346.1の手順に従います。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=224346.1

Quickstartのパッチ適用

OMSPatcherの使用には、一般的に次のフェーズが含まれます。

1.システムがOMSPatcherシステム要件を満たすかどうかの判断

OMSPatcher apply -analyzeの実行

apply -analyzeコマンドは、システム(ビットまたは構成のいずれか)を変更することなく、(可能な場合は)すべての前提条件チェックを実行することにより、OMSPatcherのセッション適用をシミュレートします。このコマンドは、パッチは適用しません。

詳細は、「OMSPatcherの実行の前提条件」を参照してください。

2.現在システムに存在するシステム・パッチの決定

OMSPatcher lspatchesの実行

詳細は、「lspatches」を参照してください。

3.My Oracle Support (MOS)からのパッチの取得

OMSPatcherでは、必要なプラットフォームまたはプラグインのシステム・パッチをMy Oracle Supportから取得して、OMSPatcherを実行する予定のOMSインスタンスにダウンロードすることが要求されます。

詳細は、「My Oracle Support: パッチの検索」を参照してください。

4.パッチの適用

$OMSPatcher apply <patch>の実行

applyコマンドは、指定したシステム・パッチ内のすべてのパッチを、OMSPatcherコマンドが実行されるプラットフォーム・ホームに適用します。

詳細は、「omspatcher applyの実行」を参照してください。

5.システム・パッチの個別のサブパッチのアンインストール

$OMSPatcher rollback -id <list of comma separated sub-patches of System patch>の実行

注意:
システム・パッチのサブパッチの完全なリストは、パッチのREADMEを参照してください。

パッチの適用後にシステムが不安定な場合、パッチそのものに原因がある可能性があります。Oracleサポートに連絡してください。OMSPatcher rollbackコマンドを使用してパッチを削除することをお薦めします。

詳細は、「omspatcher rollbackの実行」を参照してください。

24.4.1 My Oracle Support: パッチの検索

パッチ適用の最初の手順は、My Oracle Support (MOS)から必要なパッチを決定することです。MOSは、パッチ適用についての情報がわかる単一ソースです。次の場所からMOSにアクセスできます。

https://support.oracle.com

ログインすると、ユーザーのOracle環境に必要なパッチの検索および取得を簡単にするインタラクティブなサポート・ツールおよび情報にアクセスできます。次の図はMOSホームページを示しています。

図24-2 My Oracle Supportメイン・ページ

注意:
次の場所に、MOSに関する完全なドキュメントがあります。
http://docs.oracle.com/cd/E25290_01/index.htm

My Oracle Supportには多数の機能が含まれており、これらの機能はアプリケーションの上部に表示されるタブでグループ化されています。最も興味深いのは、次の図に示す「パッチと更新版」タブです。

図24-3 MOSのパッチと更新版

タブをクリックしてパッチと更新版ページにアクセスします。ここから、OMSパッチ領域(コア、プラグイン、または組合せ)に基づいてパッチを検索できます。次の例は、様々なパッチ領域のOMSパッチ検索を示しています。

「検索」タブから「製品またはファミリ(拡張検索)」をクリックします。

図24-4 製品またはファミリで検索

例: プラットフォーム用パッチの検索

Enterprise Manager OMSのコア・パッチを検索するには、次の検索パラメータを入力します。

- 製品: Enterprise Manager Base Platform

- リリース: Cloud Control (OMS) 12.1.0.4.0

- プラットフォーム: Linux x86-64

「検索」をクリックすると、次の結果が表示されます。

図24-5 OMSのコア・パッチ検索結果

パッチ18845437をクリックするとそのパッチ・ページに移動し、ナレッジ記事に関連付けられた、このパッチによって解決されるバグを表示することや、一般的なパッチのREADMEを表示することができます。

図24-6 OMSのコア・パッチ・ページ

「ダウンロード」をクリックし、パッチの.ZIPファイルをローカル・システムに保存します。

図24-7 パッチのダウンロード・ダイアログ

24.4.2 omspatcher applyの実行

パッチをダウンロードしたら、明示的なパッチ詳細およびパッチの適用手順についてパッチのREADMEを確認してください。READMEは次の場所にあります

<System patch location>/README.txt (または) README.html

READMEにあるパッチ適用操作を順に行う際に、(パッチ適用される構成、プライマリかスタンバイかに応じて) OMSPatcher applyを実行すると、プライマリ・サイトの複数OMSまたはスタンバイ・サイトのOMSシステム用のパッチ適用操作に対して、カスタムの環境固有バージョンのREADMEが生成されます。プライマリ・サイトの単一OMSシステムについては、OMSPatcher applyを実行するとパッチ適用およびデプロイメント操作が実行されます。

ローカルOMSインスタンスでは、最上位のシステム・パッチ・ディレクトリから次のコマンドを実行します。

$<Middleware home>/OMSPatcher/omspatcher apply <patch>

注意:
OMSPatcher analyzeとは異なり、OMSPatcher applyはすべてのOMSインスタンス上では実行しないでください。OMSPatcherは、すべてのパッチ適用およびデプロイメント操作を実行するか、システムの完全な構成側面を含む環境固有の手順を生成します。

複数OMSのUNIXシステムでは、OMSPatcherは実行用のbashスクリプトをOMSインスタンスごとに1つずつ生成します。これらのスクリプトを見つけるには、OMSPatcherにより提供される手順に従います。複数OMSのWindowsシステムの場合、OMSPatcherは、環境に合せてカスタマイズされたパッチ適用手順/コマンドをテキストおよびHTML形式で生成します。管理者はこれらの手順を実行して、様々なOMSにパッチを適用する必要があります。

24.4.3 omspatcher rollbackの実行

明示的なパッチ詳細およびパッチのアンインストール手順についてパッチのREADMEを確認してください。READMEは次の場所にあります

<System patch location>/README.txt (または) README.html

READMEにあるパッチのアンインストール操作を順に行う際に、(パッチ適用される構成、プライマリかスタンバイかに応じて) OMSPatcher rollbackを実行すると、プライマリ・サイトの複数OMSまたはスタンバイ・サイトのOMSシステム用のパッチ適用操作に対して、カスタムの環境固有バージョンのREADMEが生成されます。プライマリ・サイトの単一OMSシステムについては、omspatcher rollbackを実行するとアンインストール操作が実行されます。

ローカルOMSインスタンスでは、最上位のシステム・パッチ・ディレクトリから次のコマンドを実行します。

$<Middleware home>/OMSPatcher/omspatcher rollback -id <list of comma separated sub-patches of System patch

注意:

- omspatcher analyzeとは異なり、omspatcher rollbackコマンドはすべてのOMSインスタンス上では実行しないでください。OMSPatcherは、すべてのパッチ適用およびデプロイメント操作を実行するか、システムの完全な構成側面を含む環境固有の手順を生成します。

- システム・パッチ内のサブパッチのリストは、パッチのREADMEから取得できます。
システム・パッチのREADMEにリストされるサブパッチのリストは、実際にインストールされているパッチとは異なる場合があります。システム・パッチのインストール中に、いくつかのサブパッチはスキップされる(インストールされない)ことがあります。

複数OMSのUNIXシステムでは、OMSPatcherは実行用のbashスクリプトをOMSインスタンスごとに1つずつ生成します。これらのスクリプトを見つけるには、omspatcherにより提供される手順に従います。複数OMSのWindowsシステムの場合、OMSPatcherは、環境に合せてカスタマイズされたパッチ適用手順/コマンドをテキストおよびHTML形式で生成します。管理者はこれらの手順を実行して、様々なOMSにパッチを適用する必要があります。

24.4.4 omspatcher lspatchesの実行

パッチが適用またはロールバックされた後、omspatcher lspatchesコマンドを実行して、OMSホームとインストール済パッチの包括的なコンポーネント・タイプ - パッチ・マップを生成できます。

24.4.5 omspatcher versionの実行

システムにある様々なOMSPatcherユーティリティ(Opatch、OPlan、OsysModel)のバージョン番号を特定するには、OMSPatcher versionを実行できます。

24.4.6 スタンバイOMSシステムへのパッチ適用

高可用性用のスタンバイOMSを構成する場合は、『Oracle Enterprise Managerアドバンスト・インストレーションおよび構成ガイド』の「Enterprise Manager障害時リカバリ」の章と、付録の「スタンバイWebLogicドメインを使用するスタンバイOMS」を参照してください。

OMSPatcherコマンド構文

この項では、OMSへのパッチ適用に使用するすべてのOMSPatcherコマンドの包括的なリストおよび説明を提供します。

重要:
OMSPatcherコマンドは、OMSミドルウェア・ホームから実行する必要があります。

OMSPatcherコマンド

OMSPatcherコマンドは、OMSミドルウェア・ホームのOMSPatcherディレクトリから実行されます。ミドルウェア・ホームは$ORACLE_HOMEとして設定する必要があります。次の一般的な例では、OMSPatcherコマンドはミドルウェア・ホームから実行されています。

<Middleware home>/OMSPatcher/omspatcher apply <PATH_TO_PATCH_DIRECTORY>

ここで<PATH_TO_PATCH_DIRECTORY>は、システム・パッチの最上位ディレクトリへのフルパスです。

-helpオプションを指定することにより、任意のコマンド(version以外)のオンライン・ヘルプを表示できます。

OMSPatcherは、6つの主なコマンドで構成されます。

- apply

- rollback

- checkapplicable

- saveConfigurationSnapshot

- lspatches

- version

Apply

システム・パッチをOMSインスタンス・ホームに適用します。パッチの場所を指定する必要があり、または現在のディレクトリがパッチの場所として使用されます。

重要:
OMSPatcherは、プラットフォーム・ホームから実行する必要があります。ORACLE_HOME環境変数は、プラットフォーム・ホームとして設定するか、–ohオプションを使用して指定する必要があります。

システム・パッチの場所からApplyコマンドを直接実行する必要があります。

omspatcher applyを実行すると、次の入力を求めるプロンプトが表示されます。

- プライマリOMS(またはスタンバイOMS)のWebLogic管理サーバーのURL

- ユーザー名およびパスワード

silentオプションとproperty_fileオプションを使用すると、サイレント・モードでの対話がサポートされます。standbyオプションは、スタンバイOMSシステムにパッチ適用する場合に使用する必要があります。OMSPatcherは、コマンドラインからx=yプロパティを渡します。表24-2「applyプロパティ」を参照してください。

構文

<Middleware home>/OMSPatcher/omspatcher apply <System patch location>
[-jre <Path to JRE>] [-nonrolling]
[-invPtrLoc <Path to oraInst.loc>]
[-property_file <Path to property file>]
[-analyze] [-silent] [-oh <Platform home path>]

パラメータ

<システムのパッチの場所>

パッチの場所へのパスです。パッチの場所を指定しない場合は、現在のディレクトリがパッチの場所として使用されます。パッチはシステム・パッチになります。

applyコマンドのオプション

表24-1 apply

オプション

説明

jre

このオプションは、Oracleホームの下のデフォルトの場所のかわりに、特定の場所のJRE (Java)を使用するようにOMSPatcherに指示します。

invPtrLoc

oraInst.locファイルを見つける際に使用します。インストールで-invPtrLocフラグを使用した場合に必要です。oraInst.locファイルのパスにする必要があります。

property_file

OMSPatcherが使用する、ユーザー定義のプロパティ・ファイル。プロパティ・ファイルのパスは絶対パスにする必要があります。

omspatcherのキーは次のとおりです。

AdminConfigFile - OMSインスタンス・ドメインの管理サーバー・ユーザーの暗号化ファイル。

AdminKeyFile - OMSインスタンス・ドメインの管理サーバー・パスワードの暗号化ファイル。

AdminServerURL - OMSインスタンス・ドメインの管理サーバーURL。

(例: t3s://<host address>:<port number>)

キー、値のペアはx=yの形式であり、ここでxはomspatcherが理解するキーで、各ペアはプロパティ・ファイル内で改行で区切られます。このオプションは、通常はサイレント操作に使用されます。

このオプションは、サイレント・モードでomspatcherを起動した場合に有用です。WebLogic管理サーバーのユーザー名およびパスワードの暗号化ファイルを作成するには、次を使用します

$ORACLE_HOME/OMSPatcher/wlskeys/createkeys.sh (Windowsの場合は.cmd)を実行してファイルを取得し、カスタム・ファイルでproperty_fileオプションを指定してこのファイルをロードします。

注意: Windowsの場合、プロパティ・ファイル内のパスで、ディレクトリ、ファイルを\\で区切ります。

analyze

構成変更/バイナリ変更のいずれも使用しないアクションをOMSPatcherから出力します。

このオプションは、構成およびバイナリ前提条件の両方のチェックを含む、前提条件チェックを実行します。適用操作をシミュレートします(パッチの適用はしません)。このオプションを付けたomspatcher applyコマンドは、すべての前提条件がパッチ適用操作について合格することを確認するために、各OMSインスタンスで実行する必要があります。

silent

ユーザーとの対話を出力しません。

oh

このオプションによって渡されたパラメータは、ORACLE_HOME環境変数をオーバーライドします。このパラメータ(このオプションが使用される場合)は、コア・プラットフォーム・ホームである必要があります。

applyコマンドのプロパティ

表24-2 applyプロパティ

オプション

説明

OMSPatcher.OMS_DISABLE_HOST_CHECK=true

WebLogic管理サーバーのホストの検証チェックを無効化するために使用されます。OMS構成が仮想ホストを基にしている場合は、このプロパティをtrueに設定します。

OMSPatcher.OMS_USER=<installed OMS user>

インストールされているOMSの管理者名をOMSPatcherが取得できない場合に使用されます。

このスイッチはMicrosoft Windows環境にのみ適用可能です。

OMSPatcher.OMS_SCRIPTS_DIR=<existing directory>

bashスクリプト(複数のOMS構成用のOMSPatcherによって生成された)がコピーされる、単一の既存ディレクトリを指定するために使用されます。

既存ディレクトリを指定することで、このプロパティで指定されたディレクトリの下に新しく作成されたタイムスタンプの名前のサブディレクトリに、bashスクリプトがコピーされます。これによってOMS管理者は、個々のOMSマシンに手動でスクリプトをコピーするかわりに、事前定義した共有の場所からスクリプトを実行することができます。

このスイッチはUNIXシステム環境にのみ適用可能です。

Rollback

システム・パッチのサブパッチをOMSインスタンス・ホームからロールバックします。管理者がシステム・パッチのサブパッチIDを指定します。OMSPatcher lspatchesコマンドの実行によってサブパッチIDを取得できます。「omspatcher lspatchesの実行」を参照してください。

重要: OMSPatcherは、ミドルウェア・ホームから実行する必要があります。ORACLE_HOME環境変数は、プラットフォーム・ホームとして設定するか、–ohオプションを使用して指定する必要があります。

OMSPatcher rollbackを実行すると、次の入力を求めるプロンプトが表示されます。

- プライマリOMS(またはスタンバイOMS)のWebLogic管理サーバーのURL

- ユーザー名およびパスワード

silentオプションとproperty_fileオプションを使用すると、サイレント・モードでの対話がサポートされます。standbyオプションは、スタンバイOMSシステムにパッチ適用する場合に使用する必要があります。OMSPatcherは、コマンドラインからx=yプロパティを渡します。表24-2「applyプロパティ」を参照してください。

構文

omsatcher rollback -id <sub patches ID of System patch>
[-idFile <file contains list of sub-patch IDs
of System patch> ]
[-invPtrLoc <Path to oraInst.loc>]
[-jre <LOC>]
[-silent]
[-nonrolling]
[-property_file <path to property file>]
[-analyze]

パラメータ

システム・パッチをロールバックするためのサブパッチID。システム・パッチ全体をロールバックする必要がある場合は、システム・パッチ(ロールバックされる)のすべてのサブパッチ用のパッチIDを指定する必要があります。

rollbackオプション

表24-3 rollback

オプション

説明

id

システム・パッチのサブパッチのリスト。サブパッチの完全なリストは、システム・パッチのREADMEを参照してください。

システム・パッチ・バンドルに関連するコア・ホームおよびプラグイン・ホームの両方について、すべてのパッチIDを表示するには、omspatcher lspatchesオプションを使用します。パッチidは1セッションに1バンドルからのみ可能です。リストはカンマで区切られます。

idfile

システム・パッチのサブパッチIDのリストを含むファイルです。

invPtrLoc

invPtrLocオプションは、中央インベントリ・ポインタ・ファイル(oraInst.loc)の検索に使用されます。このオプションへの入力は、oraInst.locファイルへのパスです。

jre

このjreオプションは、Oracleホームの下のデフォルトの場所のかわりに、特定のJRE (Java)の場所を使用するようにOMSPatcherに指示します。

silent

このオプションは、呼出しのサイレント・モードを参照します。

nonrolling

nonrollingオプションは、非ローリング・モードで実行されるパッチ適用セッションを実行するようにOMSPatcherに指示します。パッチ適用セッションを開始するには、次の前提条件を満たす必要があります。

- ローカル・ノード上のスタックは稼働している必要があります

- すべてのリモート・ノードは停止している必要があります。

property_file

omspatcherが使用する、管理者定義のプロパティ・ファイル。プロパティ・ファイルのパスは絶対パスにする必要があります。

omspatcherのキーは次のとおりです。

'AdminConfigFile' - OMSインスタンス・ドメインの管理サーバー管理者の暗号化ファイル。

'AdminKeyFile' - OMSインスタンス・ドメインの管理サーバー・パスワードの暗号化ファイル。

'AdminServerURL' - OMSインスタンス・ドメインの管理サーバーURL。

(例: t3s://<host address>:<port number>)

キー、値のペアはx=yの形式であり、ここでxはomspatcherが理解するキーで、各ペアはプロパティ・ファイル内で改行で区切られます。

WebLogic管理サーバーのユーザー名およびパスワードの暗号化ファイルを作成するには、$ORACLE_HOME/OMSPatcher/wlskeys/createkeys.sh (Windowsの場合は.cmd)を実行してファイルを取得し、カスタム・ファイルでproperty_fileオプションを指定してこのファイルをロードします。

注意: Windowsの場合、プロパティ・ファイル内のパスで、ディレクトリ、ファイルを\\で区切ります。

analyze

このオプションは、構成およびバイナリ前提条件の両方のチェックを含む、前提条件チェックのドライランに利用できます。このオプションを付けたコマンドOMSPatcher rollbackは、すべての前提条件がパッチ適用操作について合格することを確認するために、各OMSインスタンスで実行する必要があります。

rollbackコマンドのプロパティ

表24-4 rollbackプロパティ

オプション

説明

OMSPatcher.OMS_DISABLE_HOST_CHECK=true

WebLogic管理サーバーのホストの検証チェックを無効化するために使用されます。OMS構成が仮想ホストを基にしている場合は、このプロパティをtrueに設定します。

OMSPatcher.OMS_USER=<installed OMS user>

インストールされているOMSの管理者名をOMSPatcherが取得できない場合に使用されます。

このスイッチはMicrosoft Windows環境にのみ適用可能です。

OMSPatcher.OMS_SCRIPTS_DIR=<existing directory>

bashスクリプト(複数のOMS構成用のOMSPatcherによって生成された)がコピーされる、単一の既存ディレクトリを指定するために使用されます。

既存ディレクトリを指定することで、このプロパティで指定されたディレクトリの下に新しく作成されたタイムスタンプの名前のサブディレクトリに、bashスクリプトがコピーされます。これによってOMS管理者は、個々のOMSマシンに手動でスクリプトをコピーするかわりに、事前定義した共有の場所からスクリプトを実行することができます。

このスイッチはUNIXシステム環境にのみ適用可能です。

lspatches

OMSホームに適用されるパッチのリストを表示します。これにより、パッチが適用されているコンポーネント名/バージョン、コンポーネント・タイプ、システム・パッチ、サブパッチおよびパッチの説明が表示されます。OMSPatcherは、システム・パッチの適用にのみ使用されることに注意してください。ただし、OMSには、Enterprise Managerのインストール時にすでに適用されている個別パッチを含めることができます。OMSPatcherでは、パッチがシステム・パッチか個別パッチかに関する情報を提供して、システム・パッチである場合には、システム・パッチに含まれるその他のパッチもすべて表示されます。

構文

OMSPatcher lspatches   [ -invPtrLoc <Path to oraInst.loc> ]
[-jre <LOC> ]
[-oh]

オプション

表24-5 lspatches

オプション

説明

jre

このjreオプションは、Oracleホームの下のデフォルトの場所のかわりに、特定のJRE (Java)の場所を使用するようにOMSPatcherに指示します。

invPtrLoc

invPtrLocオプションは、中央インベントリ・ポインタ・ファイル(oraInst.loc)の検索に使用されます。このオプションへの入力は、oraInst.locファイルへのパスです。

oh

ミドルウェア・ホームの場所。これはORACLE_HOME環境変数をオーバーライドします。

version

versionコマンドは、OPatchユーティリティ、依存OPlanバージョンおよびosysmodelバージョンの現在のバージョン番号を表示します。

重要: OMSPatcherは、ミドルウェア・ホームから実行する必要があります。

構文

<MW_HOME>/OMSPatcher/omspatcher version [-invPtrLoc <Path to oraInst.loc>]
[-jre <LOC>]
[-oh <ORACLE_HOME>]
[-help] [-h]

オプション

次の表では、versionコマンドで使用可能なオプションについて説明します。

表24-6 versionコマンドのオプション

オプション

説明

-invPtrLoc

invPtrLocオプションは、中央インベントリ・ポインタ・ファイル(oraInst.loc)の検索に使用されます。このオプションへの入力は、oraInst.locファイルへのパスです。

-jre

このjreオプションは、Oracleホームの下のデフォルトの場所のかわりに、特定のJRE (Java)の場所を使用するようにOMSPatcherに指示します。

-oh

ohオプションは、処理するOracleホームを指定します。環境変数ORACLE_HOMEよりも優先されます。

checkApplicable

checkApplicableコマンドは、システム・パッチの適用可否および(または)システム・パッチのサブパッチをロールバックできるかどうかを判断するために、OMSプラットフォーム・ホームおよびプラグイン・ホームで前提条件のバイナリ・チェックを実行します。

構文

omspatcher checkApplicable
[-id <singleton or System Patch ID to be rolled back>]
[-invPtrLoc <Path to oraInst.loc>]
[-jre <LOC>]
[-ph <System patch that is to be installed>]
[-silent]

オプション

次の表では、checkApplicableコマンドで使用可能なオプションについて説明します。

表24-7 checkApplicableコマンドのオプション

オプション

説明

id

OMSプラットフォーム・ホームまたはプラグイン・ホームからロールバックされるサブパッチIDを指定するために使用されます。

invPtrLoc

oraInst.locファイルを見つける際に使用します。インストールで-invPtrLocフラグを使用した場合に必要です。oraInst.locファイルのパスにする必要があります。

jre

Oracleホーム下のデフォルトの場所のかわりに、指定した場所のJRE(Java)を使用するようにOPatchに指示します。

ph

パッチの場所のパスを指定するために使用されます。入力はシステム・パッチの場所である必要があります。

silent

ユーザーとの対話を出力しません。

saveConfigurationSnapshot

saveConfigurationSnapshotコマンドは、プライマリOMS (およびOMSリポジトリ)のスナップショット構成を生成し、それをOMSPatcherで読取り可能なXMLファイルに保存します。

ファイルを指定しない場合は、次の場所のデフォルト・ファイル(configData.xml)に保存されます。

ORACLE_HOME/cfgtoollogs/opatch/sysconfig/configData.xml

saveConfigurationSnapshotコマンドを実行すると、次の入力を求めるプロンプトが表示されます。

- プライマリOMSのWebLogic管理サーバーのURL

- ユーザー名とパスワード

silentオプションとproperty_fileオプションによって、サイレント・モード(ユーザーとの対話処理を抑止する)でコマンドを実行することができます。

このコマンドはプライマリOMSシステムに属するOMSインスタンスから実行する必要があります。OMS構成を仮想ホストで実行する場合、コマンドラインからOMSPatcher.OMS_DISABLE_HOST_CHECK=trueオプションを設定する必要があります。

構文

omspatcher saveConfigurationSnapshot
[-configFile <File to save configuration snapshot> ]
[-oh <ORACLE_HOME> ]
[-invPtrLoc <Path to oraInst.loc> ]
[-jre <LOC> ]
[-silent ]
[-property_file <path to file> ]

オプション

次の表では、versionコマンドで使用可能なオプションについて説明します。

表24-8 saveConfigurationSnapshotコマンド・オプション

オプション

説明

configFile

OPatchが指定した製品の構成をXMLファイルに記述できるようにします。XMLファイルはOracle System Model APIでのみ認識可能であり、Enterprise Manager SDKによってアクセス可能です。

oh

作業するOracleホームを指定します。指定したOracleホームが、環境変数ORACLE_HOMEよりも優先されます。

invPtrLoc

oraInst.locファイルを見つける際に使用します。インストールで-invPtrLocフラグを使用した場合に必要です。oraInst.locファイルのパスにする必要があります。

jre

Oracleホーム下のデフォルトの場所のかわりに、指定した場所のJRE (Java)を使用するようにOMSPatcherに指示します。

silent

ユーザーとの対話を出力しません。

property_file

OMSPatcherが使用する、ユーザー定義のプロパティ・ファイル。プロパティ・ファイルへのパスは絶対パスである必要があります。

OMSPatcherのキーは次のとおりです。

- AdminConfigFile - GCドメインの管理サーバー・ユーザーのための暗号化ファイル。

- AdminServerURL' - GCドメインの管理サーバーURL(例: t3s://<host address>:<port number>)

- AdminKeyFile - GCドメインの管理サーバー・パスワードのための暗号化ファイル。

キー、値のペアはx=yの形式であり、ここでxはOMSPatcherが理解するキーで、各ペアはプロパティ・ファイル内で改行で区切られます。

property_fileオプションは、通常、サイレント・モード操作(ユーザーとの対話処理を抑える)でOMSPatcherを実行する場合に使用されます

WebLogic管理サーバーのユーザー名およびパスワードの暗号化ファイルを作成するには、次のスクリプトを実行します。

$MW_HOME/OMSPatcher/wlskeys/createKeys.sh

(Windows用のcreateKeys.cmdは)、property_fileオプションを使用してファイルを取得し、カスタム・ファイルを介してそれらをロードします。

注意: Windowsの場合、プロパティ・ファイル内のパスで、ディレクトリ、ファイルを\\で区切ります。

トラブルシューティング

この章では、パッチ適用操作または分析フェーズ中に発生する可能性がある一般的なOMSPatcherの問題について説明します。

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

- OMSPatcherトラブルシューティング・アーキテクチャ

- OMSPatcherログ管理アーキテクチャ

- Oracleサポートのログ

- OMSPatcher: ケース分析、エラー・コードおよび処置/提案

- OMSPatcher: 外部ユーティリティ・エラー・コード

- OMSPatcher OMS自動化の特別なエラー・ケース

OMSPatcherトラブルシューティング・アーキテクチャ

OMSPatcherは、パッチ適用プロセスを十分に自動化するために、様々なツール/ユーティリティにアクセスし、それらの個別のフェーズで様々なパッチ適用タスクを実行します。OPatchまたはOMSPatcherの外部の主なツール/ユーティリティは次のとおりです。

- emctl stop oms - ライフ・サイクル

- emctl start oms - ライフ・サイクル

- emctl applypatch、emctl rollbackpatch – OMSリポジトリのSYSMANスキーマ内のSQL変更を個別に適用、ロールバックします

- emctl register、emctl deregister – パッチ・メタデータ指示に従い、MRSアーティファクトに対する適切なXMLでメタデータ・サービスを個別に登録、登録解除します

これらのツール/ユーティリティはパッチ適用プロセス中にアクセスされます。これらのユーティリティの呼出し中に失敗が発生する可能性もありますが、これらのコマンドのエラーおよび処置はこのドキュメントで説明していません。Oracleサポートで詳細を調査する必要があります。ただし、OMSPatcherはこれらのコマンド出力からエラーをトラップし、適切なログにプッシュして管理者そして最終的にはサポートに通知します。

外部ツール/ユーティリティに加えて、OMSPatcherでは次の内部ユーティリティを使用してバイナリ・パッチ適用操作を実行します。それらには、OMSPatcherによって生成された個別のログ・ファイルがあります。内部ユーティリティはパッチ・バイナリ前提条件チェックであり、パッチ・バイナリのapply、rollback操作です。

OMSPatcherログ管理アーキテクチャ

この項では、OMSPatcherのパッチ適用操作の一部として発行されたログの情報を参照します。この知識は、管理者が正しい領域から適切なログを取得してトラブルシュートし、さらに分析するためにOracleサポートに通知するのに必要です。次の注釈付きの例は、OMSPatcherの実行時に作成される様々なログ・ファイルを表示するOMSPatcher applyの出力を示しています。

OMSPatcher rollbackのサンプル出力

bash-3.2$ OMSPatcher/omspatcher rollback -id 1111137
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.
OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/mw
Log file location  : /scratch/mw/cfgtoollogs/omspatcher/1111137_Nov_11_2015_23_57_40/rollback2015-11-11_23-57-40PM_1.log

OMSPatcher log file: /scratch/mw/cfgtoollogs/omspatcher/SystemPatch/omspatcher_2015-11-11_23-57-45PM_deploy.log

Please enter OMS weblogic admin server URL(t3s://myserver.myco.com:7101):>
Please enter OMS weblogic admin server username(weblogic):>
Please enter OMS weblogic admin server password:>

Sub-patch(es) " 1111137 " are part of the OMS System patch.
Oracle Home: /scratch/mw, Sub-patch(es): [1111137, 1111126]

Do you want to rollback sub-patch(es) "1111137" only? [y|n]
y
User Responded with: Y

Configuration Validation: Success

Running rollback prerequisite checks for patch(es) "1111137" and Oracle Home "/scratch/mw"...
Sub-patch(es) "1111137" are successfully analyzed for Oracle Home "/scratch/mw"

To continue, OMSPatcher will do the following:
[Patch and deploy artifacts]   : De-register MRS artifact "VCPUUtilization";
Rollback sub-patch(es) [ 1111137 ] from component "oracle.sysman.emas.oms.plugin" and version "13.1.1.0.0"
Do you want to proceed? [y|n]
y
User Responded with: Y
De-registering service "VCPUUtilization" with register file "/scratch/mw/plugins/oracle.sysman.emas.oms.plugin_13.1.1.0.0/metadata/vcpu/vcpu-exalogic-registration.xml" for plugin id as "oracle.sysman.emas"...

Rolling back sub-patch "1111137" from Oracle Home "/scratch/mw"...

Complete Summary
================
All log file names referenced below can be accessed from the directory "/scratch/mw/cfgtoollogs/omspatcher/2015-11-11_23-57-40PM_SystemPatch_1111192_1"

Patching summary:
------------------
Binaries of the following sub-patch(es) have been successfully rolled back:
Featureset   Sub-patches               Log file
----------   -----------               --------
oracle.sysman.emas.oms.plugin_13.1.1.0.0       1111137   1111137_rollback2015-11-11_23-58-45PM_3.log
Undeployment Summary:
-------------------
The following artifact(s) have been successfully rolled back:

Artifacts             Log file
---------            --------
MRS-VCPUUtilization   emctl_deregister_VCPUUtilization_2015-11-11_23-58-26PM.log
Log file location: /scratch/mw/cfgtoollogs/omspatcher/SystemPatch/omspatcher_2015-11-11_23-57-45PM_deploy.log
OMSPatcher succeeded.

統合ディレクトリへのログ出力

前述の例に示すように、統合ログ・ディレクトリへのすべてのログのプッシュに参照があります。トレース例の次の行は、この統合ログ・ディレクトリを示しています。

...

All log file names referenced below can be accessed from the directory "/scratch/mw/cfgtoollogs/omspatcher/2015-11-11_23-57-40PM_SystemPatch_1111192_1""

...

この統合ログ・ディレクトリには、次のファイルが含まれます(ここではrollbackの例を参照しています)。

$ ls -l /scratch/aime/work/midnew270/oms/cfgtoollogs/opatch/2014-05-15_03-24-24AM_SystemPatch_1111118_1
total 64
-rw-rw-rw-  1 kamlku dba 59954 Nov 11 23:59 1111137_rollback2015-11-11_23-58-45PM_3.log
-rw-rw-rw-  1 kamlku dba  2361 Nov 11 23:59 1111137_RollbackPrereq2015-11-11_23-58-19PM_2.log
-rw-rw-rw-  1 kamlku dba   120 Nov 11 23:58 AdminServerStatusPrerequisites_2015-11-11_23-58-19PM.log
-rw-rw-rw-  1 kamlku dba   785 Nov 11 23:58 emctl_deregister_VCPUUtilization_2015-11-11_23-58-26PM.log
-rw-rw-rw-  1 kamlku dba    66 Nov 11 23:58 RepositoryStatusPrerequisites_2015-11-11_23-58-19PM.log
-rw-rw-rw-  1 kamlku dba  5165 Nov 11 23:59 rollback2015-11-11_23-57-40PM_1.log
-rw-rw-rw-  1 kamlku dba  3045 Nov 11 23:59 temp_apply_automation.xml
-rw-rw-rw-  1 kamlku dba  2173 Nov 11 23:59 temp_rollback_automation.xml
$

各呼出しのそれぞれのログ・ファイル、コマンドのすべては、前述で強調表示されているように最後に統合場所にコピーされます。各コマンドの命名規則は自己説明的であり、自動化で実行されている実際の操作を示します。管理者が失敗を参照するために個別のファイルに簡単に接続できるように、omspatcherログ・ファイルは個別のログ・ファイルを参照します。

Oracleサポートのログ

管理者がOracleサポートに連絡する場合、次のリファレンスをサポートに提供する必要があります。

- 管理者インタフェースのトレース。

- 統合ログ・ディレクトリのzip

- OPatchログ・ファイル

- OMSPatcherログ・ファイル

- すべてのOMSインスタンス・ホームでのOMSPatcher lspatchesコマンドの出力。

OMSPatcher: ケース分析、エラー・コードおよび処置/提案

一般的なOMSPatcherエラー・コードは、次の表を参照してください。

表24-9 OMSPatcherエラー・コード

エラー・コード

説明

処置/提案

231

Oracle WebLogic管理サーバーのURLが正しくないか、または資格証明が無効(あるいはその両方)です

インタビュー入力を修正し、OMSPatcherを再実行します。

234

Oracle WebLogic管理サーバーのURLの形式が正しくありません

Oracle WebLogic管理サーバーのURLがすでにデフォルト設定されている(値を指定されている)場合、<enter>と入力します。指定されていない場合、t3s://<WebLogic Administration Server host address>:<WebLogic Administration Server port>.OMSがデプロイされている管理対象サーバーを制御するドメイン、としてOracle WebLogic管理サーバーのURLを構築します。

235

OMSリポジトリに接続できません

SYSMAN管理者に対するOMSリポジトリの接続性を確認し、OMSPatcherを再実行します。

236

OUI中央インベントリの読取り問題

OUIインベントリが他のプロセスによってロックされているか確認します。OUIインベントリが読取り可能であるか確認します。

238

パッチ・バイナリ前提条件チェックの失敗

OMSPatcher、OPatch、パッチ・バイナリ前提条件のログ・ファイルでエラーの詳細を確認します。解決できない場合、Oracleサポートに連絡してください。

240 - 251

バイナリ更新(または)デプロイメントの失敗

- 単一OMSシステムのケースです。OMSPatcherによってパッチ適用手順が決定されましたが、手順の実行に失敗しました。OMSPatcherは、失敗した実行済手順と、パッチ適用操作の完了のために実行する予定の残りの手順を出力します。管理者は、ログを準備してOracleサポートに連絡し、失敗した理由を解決し、失敗した手順および操作を完了するためにOMSPatcherによって参照されている手順(OMSPatcherログ・ファイル内)を手動で実行する必要があります。

- 複数OMS (または)スタンバイOMSのパッチ適用操作の場合、テキスト/html出力を通して実行された個別のコマンドの失敗は、詳細な診断のためにサポートに通知する必要があります。失敗の状態が解決されると、管理者は失敗した手順と、HTML (または)テキスト出力で言及されているパッチ適用操作を完了するための残りの手順を実行する必要があります。

233

ソフトウェア・ライブラリが構成されていません

OMSリポジトリの接続に成功していません。(資格証明入力中の同じものに対する成功後チェック)

Oracle WebLogic管理サーバーに到達できません(資格証明入力中の同じものに対する成功後チェック)

OMSPatcherログ・ファイルで失敗を確認します。

OMSPatcher: 外部ユーティリティ・エラー・コード

次の表に、OMSPatcherがライフ・サイクルおよびデプロイメントに使用する外部ユーティリティの終了コードをリストします。OMSPatcherを介してデプロイメント(または)ライフ・サイクルが失敗した場合、管理者は個別のログ・ファイルでエラー・メッセージ/推奨列に示すエラー・メッセージを検索できます。

表24-10 OMSPatcher外部ユーティリティ・エラー・コード

終了コード

エラー・メッセージ / 推奨

34

コマンドの使用方法を表示します。

35

パスワードを読み取れません。終了しています...

36

リポジトリへの接続を取得できません。終了しています...

37

プラグインはこの管理サーバーにデプロイされていません。プラグインのメタデータを登録するには、まずそのプラグインをデプロイする必要があります。

38

入力ファイルが存在しません

39

この操作はサービスでサポートされていません。

40

メタデータ操作はスキップされます。

41

メタデータの登録中にエラーが発生しました。

42

メタデータの登録解除中にエラーが発生しました。

OMSPatcher OMS自動化の特別なエラー・ケース

この項では、OMSPatcher使用時の特別なケースの問題解決情報を提供します。この情報を使用すると、管理者がこのような問題を容易に処理できるようになり、サポート・チームの介入の必要性も少なくなります。

Windowsがパッチ適用の失敗の原因をOracle WebLogic管理サーバーによるファイルのロックと分析

Windowsオペレーティング・システムでは、Enterprise Manager関連のファイルのいくつか(パッチ適用に使用)が、Oracle WebLogic管理サーバーの実行によってロックされることが通知されています。OMSPatcherでは、構成の検出のためにOracle WebLogic管理サーバーが実行中になることが要求されるため、次の手順を実行して環境およびパッチ適用に関するこの競合が取り除かれることを確認する必要があります。

1. ORACLE_HOMEに移動します。

2. OMSPatcherを非分析モードで実行します。詳細な手順は、パッチのREADMEおよび管理者ガイドを参照してください。
OMSPatcherを非分析モードで実行すると、アクティブなファイルがOracle WebLogic管理サーバーによって再びロックされているかが確認され、次に示すようなプロンプトが表示されます(サイレント・モードの場合は自動的にyesになります)。

Running prerequisite checks to verify if any files or services are locked by admin server process...
Please monitor OPatch log file: c:\MW_130518\oms\cfgtoollogs\opatch\1111112_Jun_
26_2014_08_16_19\ApplyPrereq2014-06-26_08-16-57AM_8.log

The details are:

Following files are active :
c:\MW_130518\oms\sysman\jlib\emCoreConsole.jar

Due to active files to be patched, OMSPatcher will stop all OMS processes so tha
t lock on active files may be released...
Do you want to proceed? [y|n]
y
User Responded with: Y
OMSPatcher has stopped all OMS processes successfully.

OMSプロセスの停止中に失敗があった場合、OMSPatcherはそれに応じてエラーを出力します。詳細は、OMSPatcherログ・ファイルを参照してください。

3. OMSPatcherはスタックを停止してから、パッチ・バイナリの前提条件チェックを続行するか管理者に確認を要求します(サイレント・モードの場合は自動的にyesになります)。

OMSPatcher has stopped all OMS processes successfully. Please make sure the above listed active files are unlocked by all windows processes.
Do you want to proceed? [y|n] y

User Responded with: Y

注意:
管理者は、プロセス・エクスプローラのようなオープン・ソース・ユーティリティを使用し、(2)の出力に示されるファイル文字列を検索して、まだアクティブなファイルがあるかどうかをチェックする必要があります。ある場合は、OPatchが自動化要素の確認、パッチ適用およびデプロイを実行するように、これらのファイルのプロセス・ツリーをkillします。

4. OMSPatcherはスタックの再起動を試行しません。管理者は必要に応じてスタックを再起動する必要があります。
このケースの完全なサンプル・トレースを次に示します。

C:\MW_130518\oms\OPatch_June26>omspatcher apply ..\patches\cmdRcu\1111112
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : c:\MW_130518\oms
Log file location: c:\MW_130518\oms\cfgtoollogs\omspatcher\omspatcher2014-06-26_08-16-19AM_1.log

omspatcher log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112\opatch_oms_2014-06-26_08-16-23AM_deploy.log

Please enter the WebLogic Admin Server URL for primary OMS:> t3s://example.o
racle.com:7101
Please enter the WebLogic Admin Server username for primary OMS:> weblogic
Please enter the WebLogic Admin Server password for primary OMS:>

Configuration Validation: Success

Running prerequisite checks to verify if any files or services are locked by admin server process...
Please monitor OPatch log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112_Jun_26_2014_08_16_19\ApplyPrereq2014-06-26_08-16-57AM_8.log

The details are:

Following files are active:
c:\MW_130518\oms\sysman\jlib\emCoreConsole.jar

Due to active files to be patched, omspatcher will stop all OMS processes so that lock on active files may be released...
Do you want to proceed? [y|n]
y
User Responded with: Y
omspatcher has stopped all OMS processes successfully.

omspatcher has stopped all OMS processes successfully. Please make sure the above listed active files are unlocked by all windows processes.
Do you want to proceed? [y|n]
y
User Responded with: Y

Running apply prerequisite checks for patch(es) "1111112" and Oracle Home "c:\MW
_130518\oms"...
Please monitor omspatcher log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112_Jun_26_2014_09_01_33\ApplyPrereq2014-06-26_09-03-41AM_10.log
Patches "1111112" are successfully analyzed for Oracle Home "c:\MW_130518\oms"

To continue, OMSPatcher will do the following:
[Patch and deploy patch(es) binaries]   : Apply patch(es) [ 1111112 ] to Oracle
Home "c:\MW_130518\oms";
Apply RCU artifact with patch "c:\MW_130518\oms\.omspatcher_storage \1111112_Feb_21_2014_06_30_38\original_patch"

Do you want to proceed? [y|n]
y
User Responded with: Y

Applying patch "1111112" to Oracle Home "c:\MW_130518\oms"...
Please monitor OMSPatcher log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112_Jun_26_2014_09_01_33\apply2014-06-26_09-04-17AM_12.log

Updating repository with RCU reference file "c:\MW_130518\oms\.omspatcher_storage\1111112_Feb_21_2014_06_30_38\original_patch"

Copying all logs to: c:\MW_130518\oms\cfgtoollogs\omspatcher\2014-06-26_09-01-32AM_SystemPatch_1111112_1

Patching summary:
Following patch(es) are successfully applied (Oracle home:patch list):
c:\MW_130518\oms:1111112

Log file location: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112\omspatcher_oms_2013-06-26_09-01-36AM_deploy.log

OMSPatcher succeeded.

UNIXベースのシステムでの複数OMS実行

この項では、複数OMS (UNIXベースのシステム)環境で、OMSPatcherにより生成されたbashスクリプトを実行する際に発生する可能性のある問題について説明します。OMSPatcherにより生成された次の出力例は、様々なスクリプトベースの問題を示します。

例24-2 OMSPatcher出力: 複数OMS (UNIXベース)環境

bash-4.3$ OMSPatcher/omspatcher apply /net/slc09jcy/scratch/patch_2nd_nov/em13_1/bundle_patches/1111191
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/hkumars/oms_install/mw
Log file location  : /scratch/hkumars/oms_install/mw/cfgtoollogs/omspatcher/opatch2015-11-11_23-27-35PM_1.log

OMSPatcher log file: /scratch/hkumars/oms_install/mw/cfgtoollogs/omspatcher/1111191/omspatcher_2015-11-11_23-27-46PM_deploy.log

Please enter OMS weblogic admin server URL(t3s://rwsv1452.myco.com:7101):>
Please enter OMS weblogic admin server username():> weblogic
Please enter OMS weblogic admin server password:>

WARNING: Could not apply the patch "1111155" because the "oracle.samples.xohs.oms.plugin with version 13.1.4.0.0" core component of the OMS or the plug-in for which the patch is intended is either not deployed or deployed with another version in your Enterprise Manager system.

Configuration Validation: Success

WARNING:You have a multi-OMS setup. The patch application is not complete until the following steps are executed successfully.

Please perform the following steps to complete patching operations.
-------------------------------------------------------------------
1. Please copy the script "/scratch/hkumars/oms_install/mw/.omspatcher_storage/oms_session/scripts_2015-11-11_23-28-33/run_script#1_on_host_rwsv1452_us_oracle_com_as_user_hkumars.sh" to "rwsv1452.myco.com" and execute the script on host "rwsv1452.myco.com".
2. Please execute the script "/scratch/hkumars/oms_install/mw/.omspatcher_storage/oms_session/scripts_2015-11-11_23-28-33/run_script#2_on_host_rwsv1451_us_oracle_com_as_user_hkumars.sh" on local host.

Complete Summary
================

All log file names referenced below can be accessed from the directory "/scratch/hkumars/oms_install/mw/cfgtoollogs/omspatcher/2015-11-11_23-27-35PM_SystemPatch_1111191_1"

Patching summary:
-----------------

The following sub-patches are incompatible with components installed in the OMS system:
1111155

--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1)  Could not apply the patch "1111155" because the "oracle.samples.xohs.oms.plugin with version 13.1.4.0.0" core component of the OMS or the plug-in for which the patch is intended is either not deployed or deployed with another version in your Enterprise Manager system.
2) You have a multi-OMS setup. The patch application is not complete until the following steps are executed successfully.

--------------------------------------------------------------------------------
OMSPatcher Session completed with warnings.
Log file location: /scratch/hkumars/oms_install/mw/cfgtoollogs/omspatcher/1111191/omspatcher_2015-11-11_23-27-46PM_deploy.log

OMSPatcher completed with warnings.

複数OMS警告メッセージ:

警告: 複数OMS設定が含まれています。次の手順が正常に実行されるまで、パッチ適用は完了しません

このメッセージは、OMSPatcherにより生成されたbashスクリプトの実行手順を管理者が実行するまで、パッチ適用およびデプロイは完了しないことを意味します。

管理者は、OMSPatcherによって生成されたbashスクリプトをセカンダリOMS上で実行するとき、資格証明を提示する必要があります。

例:

/net/slc00skv/scratch/hkumars/work/omshome1967/.omspatcher_storage/oms_session/scripts_2015-11-19_06-40-51/run_script#1_on_host_slc09pjb_us_oracle_com_as_user_hkumars.sh
Verifying embedded script host-address "slc09pjb.myco.com" against the network interface for a match...
Trying for a match with: fe80:0:0:0:221:f6ff:fe6f:9ac1%2(fe80:0:0:0:221:f6ff:fe6f:9ac1%2)
Trying for a match with: slc09pjb.myco.com(10.248.10.100)
Script-host address matched with host network interface.
Creating session file /scratch/hkumars/work/omshome1967/.omspatcher_storage/oms_session/oms_session_2015-11-18_22-40-19PM...
Copying your script to OMSPatcher defined path /scratch/hkumars/work/omshome1967/.omspatcher_storage/oms_session/scripts_2015-11-19_06-40-51/run_script#1_on_host_slc09pjb_us_oracle_com_as_user_hkumars.sh...
The System Patch directory already exists in the machine (this could mean that System Patch is already downloaded). Do you want to overwrite it (y|n)?
n
User provided n for patch transfer. Ignoring patch transfer...
The Patch backup location /scratch/hkumars/work/omshome1967/.omspatcher_storage/1111126_Sep_7_2015_02_06_54/original_patch does not exists in the machine (this could mean that the patch automation data are not present on this host and which is mandatory to rollback this patch later from this host). You need to provide host credential to copy it.
Executing command: mkdir -p /scratch/hkumars/work/omshome1967/.omspatcher_storage/1111126_Sep_7_2015_02_06_54;scp -r slc00skv.myco.com:/scratch/hkumars/work/omshome1967/.omspatcher_storage/1111126_Sep_7_2015_02_06_54/original_patch /scratch/hkumars/work/omshome1967/.omspatcher_storage/1111126_Sep_7_2015_02_06_54
hkumars@slc00skv.myco.com's password:

この場合、管理者はユーザー資格証明を提示して、パッチのロールバック時に使用されるセカンダリOMS上の自動化データをコピーする必要があります。

bashスクリプト実行のトラブルシューティング

次の項では、複数OMS (UNIXベースのシステム)環境で、OMSPatcherにより生成されたbashスクリプトを実行する際に発生する可能性のある最も一般的な問題について説明します。

Windowsはサポート対象外

Microsoft Windowsでは、bashスクリプトの実行はサポートされていません。このため、この最適化(手順削減)は、Windows OMS PS2環境には適用できません。OMSPatcherを通して出力される、より旧式の状況依存の個々の手順は、Windowsで引き続きサポートされます。

bashスクリプト・プログラムの可用性

スクリプトは、bashが/bin/bashに配置されていることを想定します。これ以外の場所に配置されている場合、スクリプトの先頭行がwhereis bashの出力で更新されていることを確認します。

bashスクリプトでのコマンド間障害

bashスクリプトのコマンド実行の間で障害が発生すると、スクリプトは実行を停止します。OMS管理者は障害を選別し、スクリプトの実行済の部分をコメント・アウトして(行頭に#文字を挿入)、bashスクリプトの実行を再開する必要があります。スクリプト内のプロンプトまたはプロンプト関連のコードをコメント・アウトしないように注意します。

すべてのbashスクリプトの実行を完了させることが必要

すべてのbashスクリプトを実行する必要があります。すべてのスクリプトおよびスクリプト内のすべての手順を、障害が発生した場合でも、省略せずに実行する必要があります。すべてのbashスクリプトのすべての手順が、指定されたとおりに正しく実行された場合のみ、パッチ適用は正常に完了します。

パッチの場所(マウントする場合)

マウントした場所から、パッチを入力できます。bashスクリプトは、ローカルOMS (OMSPatcher Perlスクリプトが起動された場所)から、セキュア・コピー(SCP)を実行しようとします。SCP試行は、マウントした場所から入力が行われる場合に失敗することがあります。bashスクリプトは、SCP障害を無視します。

OMSリポジトリのSYSMANパスワードおよびプロンプト

OMSリポジトリのSYSMANパスワードの入力を求めるbashスクリプトのプロンプトは、コマンドがこの情報を必要とするときのみ表示されます。スクリプトの開始時にSYSMANパスワードの入力が求められることはありません。このため、スクリプトの実行時には全体を通して、特にプロンプトの表示に注意する必要があります。bashスクリプトの実行は、サイレント実行ではありません。

bashスクリプトのプロンプトは、次に示すとおりに表示されます。

OMSリポジトリのSYSMANユーザーの資格証明を入力してください。

パッチ転送/ダウンロード

リモート・ノードが関連するスクリプト用に、スクリプトのオプションを使用してパッチをローカルOMSからリモート・ノードにダウンロードできます。パッチが共有の場所に存在するか、またはスクリプトで指定されている場所にすでにダウンロードされている場合、プロンプトでnを入力して、この転送を無視できます。

OMSPatcherリリース13.6.0.0.0の機能

OMSPatcherリリース13.6.0.0.0では、単一OMS構成と複数のOMS構成の両方に対して障害から再開する機能がサポートされます。

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

- 単一OMS構成での再開機能

- 複数OMS構成での再開機能

単一OMS構成での再開機能

単一OMSシステムでは、OMSPatcherにより、パッチ適用手順のエンドツーエンドの自動化が実行されます。障害が発生した場合、OMSPatcherにより、すべての不完全な(または)失敗した手順のリストを含むbashスクリプトを生成できます。OMS管理者は、OMSPatcherによって作成されたマスター・ログ・ファイルを参照して失敗の根本的な原因を確認し、解決してから、OMSPatcherで指定されたbashスクリプトを実行する必要があります。bashスクリプトは、障害発生時点からの手順を実行します。

例

1. 自動システム・パッチの適用中に、ファイルの権限の問題によってOMSPatcherが失敗します。
例:

OMSPatcher/omspatcher apply /scratch/patch_2nd_nov/em13_1/bundle_patches/1111191
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.
OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/mw
Log file location  : /scratch/mw/cfgtoollogs/omspatcher/opatch2015-12-01_01-06-42AM_1.log
OMSPatcher log file: /scratch/mw/cfgtoollogs/omspatcher/1111191/omspatcher_2015-12-01_01-06-50AM_deploy.log
Please enter OMS weblogic admin server URL(t3s://myserver.myco.com:7101):>
Please enter OMS weblogic admin server username(weblogic):>
Please enter OMS weblogic admin server password:>

WARNING: Could not apply the patch "1111155" because the "oracle.samples.xohs.oms.plugin with version 13.1.4.0.0" core component of the OMS or the plug-in for which the patch is intended is either not deployed or deployed with another version in your Enterprise Manager system.

Configuration Validation: Success
Running apply prerequisite checks for sub-patch(es) "1111126 1111137" and Oracle Home "/scratch/mw"...
Sub-patch(es) "1111126 1111137" are successfully analyzed for Oracle Home "/scratch/mw"
To continue, OMSPatcher will do the following:
[Patch and deploy artifacts]   : Apply sub-patch(es) [ 1111126 ] to component "oracle.sysman.top.oms" and version "13.1.0.0.0";
Apply sub-patch(es) [ 1111137 ] to component "oracle.sysman.emas.oms.plugin" and version "13.1.1.0.0";
Register MRS artifact "eventsaux";
Register MRS artifact "VCPUUtilization"

Do you want to proceed? [y|n]
y
User Responded with: Y
Applying sub-patch "1111126 " to component "oracle.sysman.top.oms" and version "13.1.0.0.0"...
Applying sub-patch "1111137 " to component "oracle.sysman.emas.oms.plugin" and version "13.1.1.0.0"...
OMSPatcher failed to apply following patch(es) "1111137"  to core/plugin Oracle home(s).

Complete Summary
================
All log file names referenced below can be accessed from the directory "/scratch/mw/cfgtoollogs/omspatcher/2015-12-01_01-06-42AM_SystemPatch_1111191_1"
Patching summary:
-----------------
Binaries of the following sub-patch(es) have been applied successfully:
Featureset   Sub-patches                                    Log file
----------   -----------                                    --------
oracle.sysman.top.oms_13.1.0.0.0       1111126   1111126_opatch2015-12-01_01-07-32AM_3.log

Binaries of the following sub-patch(es) failed to get applied:
Featureset   Sub-patches                                  Log file
---------- -----------                                    --------
oracle.sysman.emas.oms.plugin_13.1.1.0.0       1111137   1111137_opatch2015-12-01_01-08-06AM_4.log
The following sub-patches are incompatible with components installed in the OMS system:
1111155
OMSPatcher failed to execute some of the patching steps. Please check the Patching summary,individual logs and
try to resolve the issue. Once the issue is resolved,Please execute below script to complete patching session:
"/scratch/mw/.omspatcher_storage/oms_session/scripts_2015-12-01_01-06-42AM/run_script_singleoms_resume.sh"

------------------------------------------------------------------------------------------------
OMSPatcher wont allow any other patching operations unless the script is executed successfully
------------------------------------------------------------------------------------------------
[ Error during Patch and deploy artifacts Phase]. Detail: OMSPatcher failed to apply some of the patches to the OMS instance home(s).
OMSPatcher failed: OMSPatcher failed to execute some of the OMS operations. Please refer log file(s) for details.
--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1)  Could not apply the patch "1111155" because the "oracle.samples.xohs.oms.plugin with version 13.1.4.0.0" core component of the OMS or the plug-in for which the patch is intended is either not deployed or deployed with another version in your Enterprise Manager system.
--------------------------------------------------------------------------------
Log file location: /scratch/mw/cfgtoollogs/omspatcher/1111191/omspatcher_2015-12-01_01-06-50AM_deploy.log

Recommended actions: Please refer log file(s) for more details on the errors. Please contact Oracle Support.

2. 不完全なパッチ適用セッションが残っている場合、OMS管理者は新しいパッチ適用セッションを開始することができません。OMSPatcherは、失敗に関する詳細な情報によって、エラーとその問題を修正するためにとるべきアクションを明確にします。
例:

OMSPatcher/omspatcher apply /scratch/patch_2nd_nov/em13_1/bundle_patches/1111191
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/mw
Log file location  : /scratch/mw/cfgtoollogs/omspatcher/opatch2015-12-01_01-15-09AM_1.log
OMSPatcher failed:
OMSPatcher finds that previous patching session is not yet completed. Please refer log file
"/scratch/mw/cfgtoollogs/omspatcher/1111191/omspatcher_2015-12-01_01-06-50AM_deploy.log"
for the previous session and execute the script
"/scratch/mw/.omspatcher_storage/oms_session/scripts_2015-12-01_01-06-42AM/run_script_singleoms_resume.sh"
to complete the previous session. OMSPatcher can proceed to execute new operations only if previous session is completed successfully.
Log file location: /scratch/mw/cfgtoollogs/omspatcher/opatch2015-12-01_01-15-09AM_1.log
OMSPatcher failed with error code 73

3. OMS管理者は、単一OMSの再開スクリプトを実行して、失敗したパッチ適用セッションを完了させることができます。
例:

/scratch/mw/.omspatcher_storage/oms_session/scripts_2015-12-01_01-06-42AM/run_script_singleoms_resume.sh
Verifying embedded script host-address "myserver.myco.com" against the network interface for a match...
Trying for a match with: fe80:0:0:0:221:f6ff:feb6:424%2(fe80:0:0:0:221:f6ff:feb6:424%2)
Trying for a match with: myserver.myco.com(10.252.41.52)
Script-host address matched with host network interface.

Please provide credential for OMS repository SYSMAN user:
Command to execute (Step 1): echo /scratch/patch_2nd_nov/em13_1/bundle_patches/1111191/1111137 >> /scratch/mw/.phBaseFile2015-12-01_01-06-42AM.txt
Command to execute (Step 1): /scratch/mw/OPatch/opatch napply -phBaseFile /scratch/mw/.phBaseFile2015-12-01_01-06-42AM.txt -invPtrLoc /scratch/mw/oraInst.loc -oh /scratch/mw -silent
Command to execute (Step 1): rm /scratch/mw/.phBaseFile2015-12-01_01-06-42AM.txt
Command to execute (Step 1): mkdir -p /scratch/mw/.omspatcher_storage/1111137_Aug_31_2015_01_01_58; cp -Rf /scratch/mw/.patch_storage/1111137_Aug_31_2015_01_01_58/original_patch /scratch/mw/.omspatcher_storage/1111137_Aug_31_2015_01_01_58
Oracle Interim Patch Installer version 13.6.0.0.0
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

Oracle Home       : /scratch/mw
Central Inventory : /scratch/oraInventory
from           : /scratch/mw/oraInst.loc
OPatch version    : 13.6.0.0.0
OUI version       : 13.6.0.0.0
Log file location : /scratch/mw/cfgtoollogs/opatch/opatch2015-12-01_01-16-33AM_1.log

OPatch detects the Middleware Home as "/scratch/mw"

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   1111137

Do you want to proceed? [y|n]
y
Y (auto-answered by -silent)
User Responded with: Y
All checks passed.
Backing up files...
Applying interim patch '1111137' to OH '/scratch/mw'

Patching component oracle.sysman.emas.oms.plugin, 13.1.1.0.0...
Patch 1111137 successfully applied.
Log file location: /scratch/mw/cfgtoollogs/opatch/opatch2015-12-01_01-16-33AM_1.log

OPatch succeeded.
Command to execute (Step 2): /scratch/mw/bin/emctl register oms metadata -service eventsaux -file /scratch/mw/sysman/metadata/events/auxiliary/metric_alert_aux.xml -core -sysman_pwd %EM_REPOS_PASSWORD%
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Metadata registration successful
Command to execute (Step 3): /scratch/mw/bin/emctl register oms metadata -service VCPUUtilization -file /scratch/mw/plugins/oracle.sysman.emas.oms.plugin_13.1.1.0.0/metadata/vcpu/vcpu-exalogic-registration.xml -pluginId oracle.sysman.emas -sysman_pwd %EM_REPOS_PASSWORD%
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
Metadata registration successful
Command to execute (Step 4): /scratch/mw/OMSPatcher/omspatcher commit -id 1111126 -oh /scratch/mw -invPtrLoc /scratch/mw/oraInst.loc
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/mw
Log file location  : /scratch/mw/cfgtoollogs/omspatcher/opatch2015-12-01_01-17-14AM_1.log

OMSPatcher will now mark the patch "1111126,1111137" as auto-executed.
Log file location: /scratch/mw/cfgtoollogs/omspatcher/opatch2015-12-01_01-17-14AM_1.log

OMSPatcher succeeded.

複数OMS構成での再開機能

スクリプトの開始時に、OMSPatcherにより、SYSMANパスワードを入力するように求められます。OMSPatcherは、複数OMS構成でのパッチ適用手順を実行することができず、各ホストに固有のすべてのパッチ適用手順を含むbashスクリプトをすべてのノードに対して生成します。スクリプト名には、ホスト名およびユーザー名が含まれます。OMS管理者は、すべてのノードで各ホストに固有のスクリプトを実行し、パッチ適用セッションを完了させることができます。

1. OMSPatcherのapplyは、bashスクリプトを実行することなくパッチ適用手順のみを生成するため、正常に実行されます。
例:

$ OMSPatcher/omspatcher apply /scratch/opatchdev/targetPatchingImplRegistration/1111118
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/aime1/work/midnew9693/oms
Log file location  : /scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/opatch2014-05-05_22-43-08PM_1.log

OMSPatcher log file: /scratch/aime1/work/midnew9693/oms/cfgtoollogs/omspatcher/1111118/opatch_oms_2014-05-05_22-43-14PM_deploy.log

Please enter OMS weblogic admin server URL(t3s://linux01amd.myco.com:7101):>
Please enter OMS weblogic admin server username:> weblogic
Please enter OMS weblogic admin server password:>

Configuration Validation: Success

WARNING: OMSPatcher cannot run patching steps in multi-OMS environment.

Please perform the following steps to complete patching operations.
-------------------------------------------------------------------
1. Please copy the script "/scratch/aime1/work/midnew9693/oms/.omspatcher_storage/oms_session/scripts_2014-05-05_22-43-51/run_script#1_on_host_linux07jdx_us_oracle_com_as_user_aime1.sh" to "linux07jdx.myco.com" and execute the script.
2. Please execute the script "/scratch/aime1/work/midnew9693/oms/.omspatcher_storage/oms_session/scripts_2014-05-05_22-43-51/run_script#2_on_host_linux01amd_us_oracle_com_as_user_aime1.sh" on local host.

--------------------------------------------------------------------------------
The following warnings have occurred during OMSPatcher execution:
1)  OMSPatcher cannot run patching steps in multi-OMS environment.

--------------------------------------------------------------------------------
OMSPatcher Session completed with warnings.
Log file location: /scratch/aime1/work/midnew9693/oms/cfgtoollogs/omspatcher/1111118/opatch_oms_2014-05-05_22-43-14PM_deploy.log

OMSPatcher completed with warnings.

2. ローカル・ホスト(複数OMS構成でのプライマリ・ホスト)に対応するbashスクリプトを実行します。スクリプト実行は、誤ったsysmanパスワードによるデータベース・リポジトリへの接続の問題のために失敗しました。
例:

$ /scratch/aime1/work/midnew9693/oms/.omspatcher _storage/oms_session/scripts_2014-05-05_22-43-51/run_script#2_on_host_linux01amd_us_oracle_com_as_user_aime1.sh
Creating  master log file /scratch/aime1/work/midnew9693/oms/.omspathcer_storage/oms_session/oms_session_log_2014-05-05_22-43-08PM...
Creating  session file /scratch/aime1/work/midnew9693/oms/.omspatcher_storage/oms_session/oms_session_2014-05-05_22-43-08PM...

Please provide credential for OMS repository SYSMAN user:
Command to execute (Step 2): /scratch/aime1/work/midnew9693/oms/OMSPatcher/omspatcher checkApplicable -ph /scratch/opatchdev/targetPatchingImplRegistration/1111118 -oh /scratch/aime1/work/midnew9693/oms -invPtrLoc /scratch/aime1/work/midnew9693/oms/oraInst.loc
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/aime1/work/midnew9693/oms
Log file location  : /scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/opatch2014-05-05_22-45-52PM_1.log

OMSPatcher log file: /scratch/aime1/work/midnew9693/oms/cfgtoollogs/omspatcher/1111118/opatch_oms_2014-05-05_22-45-53PM_analyze.log

Running apply prerequisite checks for sub-patch(es) "1111118" and Oracle Home "/scratch/aime1/work/midnew9693/oms"...
Please monitor OPatch log file: /scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/1111118_May_05_2014_22_45_52/ApplyPrereq2014-05-05_22-45-57PM_2.log
Sub-patch(es) "1111118" are successfully analyzed for Oracle Home "/scratch/aime1/work/midnew9693/oms"

Complete Summary
================

All log file names referenced below can be accessed from the directory "/scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/2014-05-05_22-45-52PM_SystemPatch_1111118_1"

Prerequisites analysis summary:
-------------------------------

The following sub-patch(es) are applicable:

Oracle Home Name   Sub-patches             Log file
----------------   -----------             --------
oms12c1       1111118   1111118_ApplyPrereq2014-05-05_22-45-57PM_2.log

Log file location: /scratch/aime1/work/midnew9693/oms/cfgtoollogs/omspatcher/1111118/opatch_oms_2014-05-05_22-45-53PM_analyze.log

OMSPatcher succeeded.
Command to execute (Step 4): echo /scratch/opatchdev/targetPatchingImplRegistration/1111118/1111118 >> /scratch/aime1/work/midnew9693/oms/.phBaseFile2014-05-05_22-43-08PM.txt
Command to execute (Step 4): /scratch/aime1/work/midnew9693/oms/OPatch/opatch napply -phBaseFile /scratch/aime1/work/midnew9693/oms/.phBaseFile2014-05-05_22-43-08PM.txt -invPtrLoc /scratch/aime1/work/midnew9693/oms/oraInst.loc -oh /scratch/aime1/work/midnew9693/oms -silent
Command to execute (Step 4): rm /scratch/aime1/work/midnew9693/oms/.phBaseFile2014-05-05_22-43-08PM.txt
Oracle Interim Patch Installer version 13.6.0.0.0
Copyright (c) 2014, Oracle Corporation.  All rights reserved.

Oracle Home       : /scratch/aime1/work/midnew9693/oms
Central Inventory : /ade/aime1_opatchauto_fix_lat/oracle/work/DB112/oraInventory
from           : /scratch/aime1/work/midnew9693/oms/oraInst.loc
OPatch version    : 13.6.0.0.0
OUI version       : 13.6.0.0.0
Log file location : /scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/opatch2014-05-05_22-46-00PM_1.log

OPatch detects the Middleware Home as "/scratch/aime1/work/midnew9693"

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   1111118

Do you want to proceed? [y|n]
Y (auto-answered by -silent)
User Responded with: Y
All checks passed.
Backing up files...
Applying interim patch '1111118' to OH '/scratch/aime1/work/midnew9693/oms'

Patching component oracle.sysman.oms.core, 13.1.0.0.0...

Verifying the update...
Patch 1111118 successfully applied.
Log file location: /scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/opatch2014-05-05_22-46-00PM_1.log

OPatch succeeded.
Command to execute (Step 6): /scratch/aime1/work/midnew9693/oms/bin/emctl register oms metadata -service TargetPatchingImplRegistration -debug -file /scratch/aime1/work/midnew9693/oms/sysman/metadata/targetpatchingregister/RegisterAgentTarget.xml -core -sysman_pwd %EM_REPOS_PASSWORD%
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
Starting output for debug mode.
Debug logs will be written to /scratch/aime1/work/insthome9693/em/EMGC_OMS1/sysman/log/emctl.log
EM-04036: Unable to get a connection to the repository!  Exiting...
The command failed with error code 36

Script execution has failed. Please refer to log file: /scratch/aime1/work/midnew9693/oms/.omspatcher_storage/oms_session/oms_session_log_2014-05-05_22-43-08PM for more details

Please fix the failures and re-run the same script to complete the patching session.

3. OMS管理者は、問題を修正(データベース・リポジトリへの接続で、正確なsysmanパスワードを指定)することで、スクリプトを再実行することができます。スクリプトは、失敗時点からの実行を再開し、正常に実行されます。
例:

$ /scratch/aime1/work/midnew9693/oms/.omspatcher _storage/oms_session/scripts_2014-05-05_22-43-51/run_script#2_on_host_linux01amd_us_oracle_com_as_user_aime1.sh

Please provide credential for OMS repository SYSMAN user:
Command to execute (Step 2): /scratch/aime1/work/midnew9693/oms/OMSPatcher/omspatcher checkApplicable -ph /scratch/opatchdev/targetPatchingImplRegistration/1111118 -oh /scratch/aime1/work/midnew9693/oms -invPtrLoc /scratch/aime1/work/midnew9693/oms/oraInst.loc
SKIP command for step 2...
Command to execute (Step 4): echo /scratch/opatchdev/targetPatchingImplRegistration/1111118/1111118 >> /scratch/aime1/work/midnew9693/oms/.phBaseFile2014-05-05_22-43-08PM.txt
Command to execute (Step 4): /scratch/aime1/work/midnew9693/oms/OPatch/opatch napply -phBaseFile /scratch/aime1/work/midnew9693/oms/.phBaseFile2014-05-05_22-43-08PM.txt -invPtrLoc /scratch/aime1/work/midnew9693/oms/oraInst.loc -oh /scratch/aime1/work/midnew9693/oms -silent
Command to execute (Step 4): rm /scratch/aime1/work/midnew9693/oms/.phBaseFile2014-05-05_22-43-08PM.txt
SKIP command for step 4...
Command to execute (Step 6): /scratch/aime1/work/midnew9693/oms/bin/emctl register oms metadata -service TargetPatchingImplRegistration -debug -file /scratch/aime1/work/midnew9693/oms/sysman/metadata/targetpatchingregister/RegisterAgentTarget.xml -core -sysman_pwd %EM_REPOS_PASSWORD%
Oracle Enterprise Manager Cloud Control 12c Release 4
Copyright (c) 1996, 2014 Oracle Corporation.  All rights reserved.
Starting output for debug mode.
Debug logs will be written to /scratch/aime1/work/insthome9693/em/EMGC_OMS1/sysman/log/emctl.log
Metadata registration successful
Command to execute (Step 7): /scratch/aime1/work/midnew9693/oms/OMSPatcher/omspatcher commit -id 1111118 -oh /scratch/aime1/work/midnew9693/oms -invPtrLoc /scratch/aime1/work/midnew9693/oms/oraInst.loc
OMSPatcher Automation Tool
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

OMSPatcher version : 13.6.0.0.0
OUI version        : 13.6.0.0.0
Running from       : /scratch/aime1/work/midnew9693/oms
Log file location  : /scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/opatch2014-05-05_22-49-34PM_1.log

OMSPatcher will now mark the patch "1111118" as auto-executed.
Log file location: /scratch/aime1/work/midnew9693/oms/cfgtoollogs/opatch/opatch2014-05-05_22-49-34PM_1.log

OMSPatcher succeeded.

All operations for this script are appended to log file: /scratch/aime1/work/midnew9693/oms/.omspatcher_storage/oms_session/oms_session_log_2014-05-05_22-43-08PM

25 Oracle Management Agentへのパッチ適用

この章では、Enterprise Manager Cloud Control (Cloud Control)のOracle Management Agent (Management Agent)にパッチを適用する方法について説明します。

この章の項目は次のとおりです。

- 概要

- パッチ計画による管理エージェントへのパッチ自動適用(推奨)

- 手動による管理エージェントへのパッチ適用

25.1 概要

管理エージェントのパッチは、管理エージェント・ターゲットで発生した1つ以上のエラーを修正するためにリリースされます。OMSホストおよびリモート・ホストにデプロイされている管理エージェントにパッチを適用できます。Cloud Controlでは、管理エージェントと管理エージェント・プラグインのそれぞれのコア・コンポーネントに対して、異なる管理エージェント・パッチが存在します。

管理エージェントのパッチは、自動(パッチ計画の使用)または手動により適用できます。オラクル社は、自動によるパッチ適用をお薦めします。自動によるパッチ適用では、パッチを大量にデプロイする場合の時間と労力が節約されるだけでなく、人手による操作が少なくなるため、パッチ適用時に発生するエラーを最小限に抑えることができます。自動適用の詳細は、第25.2項を参照してください。

パッチ計画を使用して管理エージェント・ターゲットにパッチを適用できない場合は、手動で適用できます。ただし、この適用方法は推奨されません。自動適用の詳細は、第25.3項を参照してください。

25.2 パッチ計画による管理エージェントへのパッチ自動適用(推奨)

自動によるパッチ適用は、迅速、容易および信頼性の高いパッチ適用メカニズムを提供し、Cloud Controlでパッチ計画を使用することにより、実行しやすくなります。パッチ計画は、Cloud ControlコンソールまたはEM CLIを使用して作成、アクセスおよびデプロイできます。大規模なデプロイメントでは、EM CLIを使用してパッチ計画を作成、アクセスおよびデプロイできます。この項では、Cloud Controlコンソールを使用して管理エージェント・ターゲットにパッチを適用する方法のみを説明します。EM CLIを使用してターゲットにパッチを適用する方法の詳細は、Oracle Enterprise Manager Lifecycle Management管理者ガイドを参照してください。

自動パッチ適用は、Cloud Controlがオンライン・モードで動作しているときでも、オフライン・モードで動作しているときでも実行できます。Cloud Controlがオンライン・モードで動作している場合、My Oracle Supportに接続して、適用するパッチをダウンロードできます。ただし、Cloud Controlがオフライン・モードで動作している場合、適用するパッチがOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)ですでに使用可能であることを確認します。

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

- 自動による管理エージェントへのパッチ適用のメリット

- 「パッチと更新版」ページの利用

- パッチ推奨の表示

- パッチの検索

- 管理エージェント・パッチの適用

- 適用した管理エージェント・パッチの検証

- 管理エージェント・パッチの適用エラー

25.2.1 自動による管理エージェントへのパッチ適用のメリット

自動により管理エージェント・ターゲットにパッチを適用するメリット(手動により適用する場合と比べて)を次に示します。

- パッチ適用操作がまとめられているため、1つのウィンドウですべての操作が完了し、起動は常にOMSからのみ行われます。

- 自動パッチ適用では、My Oracle Supportに接続して最新のパッチをチェックし、自動的にダウンロードするパッチ適用ジョブを定期的にスケジュールできます。これにより、最新のパッチとパッチ・セットを検索したり、パッチが利用できるようになったときにダウンロードしたりする労力が軽減されます。

- 複数のパッチや同種のターゲットに対する複数のパッチ・セットを1つのパッチ計画に追加できます。たとえば、コア・コンポーネントとプラグイン・コンポーネントの両方の管理エージェント・パッチを、同じパッチ計画に追加して適用できます。

25.2.2 「パッチと更新版」ページの利用

Cloud Controlで「パッチと更新版」ページにアクセスするには、「エンタープライズ」メニューで「プロビジョニングとパッチ適用」を選択して、「パッチと更新版」を選択します。

図25-1に、「パッチと更新版」ページを示します。

図25-1 「パッチと更新版」ページ

25.2.3 パッチ推奨の表示

パッチ推奨は、潜在的なシステム上の問題と、システム・パフォーマンスの向上やシステム停止の回避を支援する推奨に関するプロアクティブな通知です。パッチ推奨は、ターゲットに適用する必要のあるクリティカル・パッチを検索する労力を最小限に抑えます。

「パッチ推奨」セクションは、「パッチと更新版」ページで利用できます。このセクションに表示されるパッチは、セキュリティ・パッチとその他の推奨パッチに分類されます。

パッチ推奨の詳細は、Oracle Enterprise Manager Lifecycle Management管理者ガイドを参照してください。

注意:

- パッチ推奨は、企業にOracle Configuration Managerリリース10.3.2以上がデプロイされている場合のみ利用できます。

- パッチ推奨はカスタム・プラグインに対しては利用できません。Cloud Controlに同梱されているデフォルト・プラグインに対してのみ利用できます。

25.2.4 パッチの検索

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

- My Oracle Supportでのパッチの検索

- ソフトウェア・ライブラリでのパッチの検索

25.2.4.1 My Oracle Supportでのパッチの検索

ブログ、Oracle Technologyフォーラムなどの外部ソースや同僚から、パッチが存在していることをすでに把握している場合は、検索機能を使用してそれらのパッチを検索します。検索機能を使用すると、より柔軟な拡張検索を実行できます。また、頻繁に使用される検索を保存したり、既存の保存済検索に基づいて検索するなどの機能があります。これにより、検索時間を短縮し、効率的に検索を実行できます。

My Oracle Supportでパッチを検索するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 簡易検索を実行するには、「パッチ検索」リージョンで「番号/名前またはバグ番号(簡易)」を選択し、パッチ名、パッチ番号またはバグ番号を指定します。「検索」をクリックします。
拡張検索を実行する場合は、「製品またはファミリ(拡張)」を選択して、製品、リリースおよびパッチ検索のために使用するその他の条件を指定します。

あるいは、「保存」タブを使用して、以前に保存した検索を実行できます。また、「最近」タブを使用して、最近実行した検索を利用できます。

パッチ検索が完了すると、結果が「パッチ検索結果」ページに表示されます。このページでは、パッチを選択してローカル・ホストまたはソフトウェア・ライブラリにダウンロードできます。

25.2.4.2 ソフトウェア・ライブラリでのパッチの検索

デフォルトでは、「パッチと更新版」ページでパッチを検索すると、Cloud Controlはそのホストで使用できるインターネット接続を使用してMy Oracle Supportに接続し、リクエストされたパッチをMy Oracle Supportで検索します。これは、デフォルトでは検索機能がオンライン・モードで実行するように設定されているためです。

しかし、ホストにインターネット接続が設定されていない場合、ソフトウェア・ライブラリで検索を実行できるように、オフライン・モードに切り替える必要があります。

オフライン・モードに切り替えるには、次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」を選択し、「オフライン・パッチ」を選択します。

2. 「接続」については、「オフライン」を選択します。

注意:
オフライン・モードでは、次の操作を実行できません。

- My Oracle Supportからのパッチの検索およびダウンロード

- パッチのマージによるパッチ競合の解決

- 関連アクティビティ・リージョンの表示

- クイックリンクへのアクセス

- アップグレード計画の表示または作成

ソフトウェア・ライブラリでパッチを検索するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 簡易検索を実行するには、「ソフトウェア・ライブラリ・パッチ検索」リージョンで「番号/名前またはバグ番号(簡易)」を選択し、パッチ名、パッチ番号またはバグ番号を指定します。「検索」をクリックします。
拡張検索を実行する場合は、「製品またはファミリ(拡張)」を選択して、製品、リリースおよびパッチ検索のために使用するその他の条件を指定します。

あるいは、「保存」タブを使用して、以前に保存した検索を実行できます。また、「最近」タブを使用して、最近実行した検索を利用できます。

パッチ検索が完了すると、結果が「パッチ検索結果」ページに表示されます。

25.2.5 管理エージェント・パッチの適用

パッチ計画を使用して管理エージェント・パッチを適用するには、次の手順を実行します。

注意:

- パッチ計画を使用すると、管理エージェントと管理エージェント・プラグインのそれぞれのコア・コンポーネントにパッチを適用できます。両方の操作で使用する必要のあるパッチ適用プロセスは同じであり、この項で説明されます。

- 大規模なデプロイメントの場合、EM CLIを使用できます。EM CLIを使用するパッチ適用の詳細は、Oracle Enterprise Manager Lifecycle Managementの管理者ガイドを参照してください。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、パッチと更新の順に選択します。

2. 「パッチと更新版」ページで、適用する必要のある管理エージェント・パッチを「パッチ推奨」セクションまたは「パッチ検索」セクションから選択します。
「パッチ推奨」セクションの詳細は、第25.2.3項を参照してください。パッチを検索する方法の詳細は、第25.2.4項を参照してください。

3. 表示されるコンテキスト・メニューから、次のオプションのいずれかを選択します。

- 新規に追加: 選択したパッチを含む新しいパッチ計画を作成する場合は、このオプションを選択します。
計画名とパッチ適用先のターゲットを指定して、「計画の作成」をクリックします。

パッチと関連付けられたターゲットがパッチ計画に追加されます。

- 既存の計画に追加: 選択したパッチを既存のパッチ計画に追加する場合は、このオプションを選択します。
必要なパッチの追加先となる既存のパッチ計画を選択し、パッチ・ターゲットを指定して、「パッチを計画に追加」をクリックします。

注意:
選択したパッチが、パッチの適用先となるターゲットと同じプラットフォームを対象にすることを確認します。たとえば、Linux x86パッチは、Linux x86ターゲットにのみ適用できます。すべての不一致は、パッチ適用エラーになります。

4. 選択したパッチが同種ターゲットに適用される場合、パッチ計画を表示するためのリンクを含むパッチ計画が正常に作成されます。 このリンクをクリックすると、パッチ計画の詳細が表示されます。
共有エージェントまたはクラスタ管理エージェントを管理エージェント・ターゲットとしてパッチ計画に追加すると、パッチをパッチ計画に追加することに関して問題があることを示す警告メッセージが表示されます。

この問題を解決するには、「すべてを計画に追加」をクリックして、影響を受けるすべてのターゲットをパッチ計画に追加します。

ただし、選択したパッチとターゲットの間でプラットフォームが一致しない場合、次のいずれかのエラーまたは警告が表示されます。

- 選択したターゲットのプラットフォームがnullであるため、nullプラットフォーム・エラーが発生しました。パッチとターゲットのプラットフォームが一致しないため、パッチ計画の検証は失敗しました。これは、ターゲットの停止中に発生することがあります。この場合、エラーが修正されるまでパッチ計画は作成されません。

- プラットフォーム不一致の警告は、パッチとターゲットのプラットフォームが一致しない場合に表示されます。このターゲットは無視されます。パッチ計画は作成されますが、このターゲットは追加されません。他の同種のターゲットは、計画に追加されます。

注意:
次に進む前に警告を修正することをお薦めします。修正しない場合、パッチ計画の検証時にエラーが発生することがあります。ただし、エラーが出ても次に進む場合は、「警告を無視して追加」を選択できます。

5. 「パッチと更新版」ページに移動します。「計画」リージョンで、表示するパッチ計画の名前をクリックします。
計画の作成ウィザードが表示されます。

6. 計画の情報ページで、次のようにします。

1. 「概要」セクションで、パッチ計画名を検証します。必要な場合は、計画名を編集できます。

2. (オプション)パッチ計画に関する簡単な説明を入力します。

3. (オプション)「アクセス許可対象」セクションで、「追加」をクリックして管理者またはロールに現在のパッチ計画へのパッチ計画アクセス権限を付与します。
「管理者に権限を追加」ウィンドウで、管理者またはロール、付与するアクセス権限を選択して、「権限の追加」をクリックします。

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

7. 「パッチ」ページで、パッチ計画に追加されたパッチを確認します。
新しいパッチをパッチ計画に追加するか、またはパッチ計画にすでにあるパッチに別のターゲットを追加するには、「パッチの追加」をクリックします。「検索の編集」ダイアログ・ボックスで、パッチ番号を入力して、「検索」をクリックします。必要なパッチを選択して「この計画に追加」をクリックします。パッチに追加するターゲットを選択して、「この計画に追加」をクリックします。

「次」をクリックします。

8. 「デプロイメント・オプション」ページで、次のようにします。

1. ステージング先セクションで、次のオプションのいずれかを選択します。
はい: パッチをターゲットに適用する前に、ウィザードを使用してソフトウェア・ライブラリからターゲット・ホストにアクセスできる一時的な場所にパッチをステージングする場合。デフォルトでは、パッチはターゲット・ホスト上のデフォルトの場所にステージングされますが、場所を変更する場合は、パッチをステージングできる場所を入力できます。

いいえ: すでにターゲット・ホストにアクセスできる一時的な場所にパッチを手動でステージングしている場合。これは、共有NFSマウントの場所でもかまいません。この場合、適用するパッチをダウンロードし、パッチをステージングする場所(親ディレクトリ)に移動して、パッチのZIPファイルと同じ名前のサブディレクトリを作成します。次に、パッチZipファイルの内容をこのサブディレクトリに抽出します。「ステージングの場所」セクションで、パッチを手動でステージングした親ディレクトリへの絶対パスを入力します。

たとえば、パッチ699099.zipをダウンロードし、ステージング場所となる親ディレクトリが/u01/app/oracle/em/stagepatchの場合は、この親ディレクトリ内に699099という名前のサブディレクトリを作成し、その中にzipファイルのコンテンツを抽出します。ステージング・パスとして/u01/app/oracle/em/stagepatchと入力します。

2. 「資格証明情報」セクションに、パッチを適用するために必要な資格証明を入力します。優先資格証明を使用することも、別の資格証明を使用することもできます。
Enterprise Manager Cloud Control 12c リリース4 (12.1.0.4)では、セキュアな管理エージェント・ターゲットにパッチを適用する際に、通常のOracleホーム資格証明は必要ありません。管理エージェント・ターゲットに適用するパッチが、特定のタスクを実行するためにルート・ユーザー・アクセス権を必要とする場合、管理エージェント・ターゲットに対して特権Oracleホーム資格証明を提供する必要があります。

パッチ適用先の管理エージェント・ターゲットがセキュアでない場合、パッチ適用先のすべての管理エージェントに対して、優先管理エージェント・ホスト資格証明を設定する必要があります。管理エージェント・ターゲットに対して優先ホスト資格証明を設定するには、「設定」メニューから、「セキュリティ」、「優先資格証明」の順に選択します。ターゲット・タイプとして「エージェント」を選択し、「優先資格証明の管理」をクリックします。必要な管理エージェント・ターゲットに対して優先ホスト資格証明を設定します。

優先資格証明を設定する方法の詳細は、Oracle Enterprise Manager Lifecycle Management管理者ガイドを参照してください。

注意:
タイプSSHキー資格証明の名前付き資格証明は、Oracleホーム・ターゲットに対して通常ホスト優先資格証明または特権ホスト優先資格証明として設定できません。

「資格証明の検証」をクリックして、提供された資格証明の正確性を検証します。

3. 「通知」セクションに、パッチ計画がスケジュール済、開始、アクションが必要、一時停止、成功、失敗の場合に、電子メール通知を有効化するかどうかを指定します。
電子メール通知を有効化するには、「パッチ適用プロセス時に通知の電子メールを受信」を選択して、必要なオプションを選択します。送信者または受信者の電子メール・アドレスが設定されていないという内容の警告のメッセージが表示される場合は、警告に記載されているアクションを実行してください。

4. 「ロールバック」セクションで、「計画内のパッチをロールバックします」を選択し、計画にリストされているパッチをデプロイするかわりにロールバックします。

5. パッチ適用操作を開始する前に、「OPatchのアップグレード」セクションで、「OPatchのアップグレード」を選択して、OPatchコンポーネントをアップグレードします。
アップグレード対象のOPatchコンポーネントについては、適用するパッチをステージングするのと同じ場所に、ダウンロードして抽出していることを確認します。

6. 「競合チェック」セクションで、分析ステージでパッチ計画内のパッチの競合を検索する際に、Oracle自動リリース更新(ARU)が使用される、ARU競合チェックを有効化または無効化するかを指定します。また、デプロイ時にパッチ競合が発生した場合に、パッチ適用手順で実行する必要のあるアクションを指定します。
競合発生時にパッチ適用手順で、計画のデプロイを停止する場合は、「競合」で「競合で停止」を、競合しているパッチをロールバックして受信パッチを適用する場合は、強制適用を、競合していないパッチのみを適用して競合しているパッチの適用をスキップする場合は、「競合のスキップ」を選択します。

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

9. 「検証」ページで、「分析」をクリックして、パッチをデプロイする前に検証します。検証ジョブが発行され、パッチが競合していないこと、OPatchが最新バージョンであること、ターゲットとパッチのバージョンとプラットフォームが一致していることなどが確認されます。検証ジョブの進行状況を追跡するには、「詳細な結果の表示」をクリックします。
または、「確認とデプロイ」ページに直接移動して、計画を分析することなく管理エージェント・パッチをデプロイできます。その場合、計画を分析し、分析が成功したら計画をデプロイするデプロイ・ジョブが発行されます。

重要:
分析フェーズで問題が発見されると、計画分割機能が起動されます。この機能は、パッチ計画を、分析が失敗したターゲットを含むパッチ計画と、分析が成功したターゲットを含むパッチ計画の2つのパッチ計画に分割します。分析が成功したターゲットを含むパッチ計画はデプロイ可能ですが、失敗したターゲットを含む計画は再分析して個別にデプロイする必要があります。
図25-5は、計画分割機能を示しています。

検証後、2つのパッチ間に競合がある場合、代替パッチを要求することが推奨されます。この場合は、「代替パッチのリクエスト」をクリックします。競合するパッチに対してマージ・パッチがすでに利用できる場合、競合するパッチをマージ・パッチと直接置き換えることができます。これを行うには、「競合するパッチの置換」をクリックします。

検証フェーズ時に発生する可能性のあるエラーの詳細は、第25.2.7項を参照してください

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

10. 「レビューおよびデプロイ」ページで、パッチ計画に指定した詳細を確認し、「デプロイ」をクリックします。
「デプロイ」をクリックすると、「デプロイの確認」ダイアログ・ボックスが表示され、「デプロイ」操作をスケジュールできます。「デプロイ」を選択します。「デプロイ」操作を即時に開始する場合は、「即時」を選択します。「デプロイ」操作を後で開始するようにスケジュールする場合は、「後で」を選択し、時間を指定します。「発行」をクリックします。

デプロイ操作をスケジューリングすると、「レビューおよびデプロイ」ページの「デプロイ」ボタンの名前が「再スケジュール」に変更されます。「準備」または「デプロイ」操作を再スケジュールする場合は、「再スケジュール」をクリックし、「送信」をクリックします。スケジュールを破棄してパッチ計画を最後の有効な状態に戻す場合は、「スケジュールの停止」をクリックします。「デプロイ」操作のスケジュールは、パッチ計画デプロイメント・オプションまたはパッチ・ターゲットを編集した場合には破棄されることに注意してください。この場合は、パッチ計画を再度検証する必要があります。

「デプロイ」ジョブが発行されます。ジョブの進行状況を追跡するには、「詳細な結果の表示」をクリックします。

25.2.6 適用した管理エージェント・パッチの検証

適用した管理エージェント・パッチを検証するには、次の手順を実行します。

1. Cloud Controlで、「ターゲット」メニューから「すべてのターゲット」を選択します。

2. 「すべてのターゲット」ページの「ターゲット名の検索」フィールドに、パッチを適用した管理エージェント・ターゲットの名前を入力し、検索アイコンをクリックします。必要なターゲットの名前をクリックします。

3. 管理エージェント・ターゲットのホームページの「サマリー」セクションの「構成」サブセクションで、「Oracleホームとパッチの詳細」をクリックして、管理エージェントのOracleホーム・ターゲットに対して実行されたすべてのジョブを表示します。

4. 「パッチ・アドバイザ」セクションで、「パッチ適用」タブを選択して、管理エージェント・ターゲットに対して正常に適用されたすべてのパッチを検証します。

25.2.7 管理エージェント・パッチの適用エラー

管理エージェント・ターゲットにパッチを適用する際に発生する可能性のあるエラーを、次に示します。

- Oracleホーム資格証明が設定されていない

- 管理エージェント・ターゲットが停止している

- パッチの競合が検出された

- ユーザーはスーパー・ユーザーではない

- パッチがステージングされていないか見つからない

25.2.7.1 Oracleホーム資格証明が設定されていない

エラーの説明

このエラーは、(セキュアではない管理エージェントにパッチを適用するための)優先管理エージェント・ホスト資格証明または(ルート・ユーザー・アクセス権を必要とするパッチのための)特権Oracleホーム資格証明が設定されていないときに発生します。

回避策

パッチ適用先の管理エージェント・ターゲットがセキュアでない場合、これらのすべての管理エージェントに対して優先管理エージェント・ホスト資格証明を設定します。管理エージェント・ターゲットに対して優先ホスト資格証明を設定するには、「設定」メニューから、「セキュリティ」、「優先資格証明」の順に選択します。ターゲット・タイプとして「エージェント」を選択し、「優先資格証明の管理」をクリックします。管理エージェント・ターゲットに対して優先ホスト資格証明を設定します。パッチ計画を分析してデプロイします。

(管理エージェント・ターゲットに)適用するパッチが、特定のタスクを実行するためにルート・ユーザー・アクセス権を必要とする場合、管理エージェント・ターゲットに対して特権Oracleホーム資格証明を設定します。パッチ計画を分析してデプロイします。

25.2.7.2 管理エージェント・ターゲットが停止している

エラーの説明

このエラーは、パッチ適用のために追加された管理エージェント・ターゲットが稼働中でない場合に発生します。

図25-2に、このエラーの例を示します。

図25-2 パッチ適用エラー: 管理エージェント・ターゲットが停止している

回避策

管理エージェント・ターゲットを起動し、その後、パッチ計画を分析してデプロイします。

25.2.7.3 パッチの競合が検出された

エラーの説明

このエラーは、追加された2つのパッチ間に競合がある場合に発生します。

図25-3に、このエラーの例を示します。

図25-3 パッチ適用エラー: パッチの競合

回避策

次のいずれかを実行します。

- サポートに連絡してマージされたパッチを取得します。

- パッチの適用を強制するために「拡張OPatchオプション」を選択します。ただし、このオプションを選択してパッチを適用すると、以前のパッチ変更が失われます。

25.2.7.4 ユーザーはスーパー・ユーザーではない

エラーの説明

このエラーは、パッチ計画を実行しているユーザーにルート・アクセス権がない場合に発生します。

図25-4に、このエラーの例を示します。

図25-4 パッチ適用エラー: ユーザーはスーパー・ユーザーではない

回避策

次の手順を実行します。

1. ルート・アクセス権を持つ新しい資格証明を作成します。

2. 権限委任設定がターゲット管理エージェント・ホストで構成されていることを確認します。権限委譲の詳細は、Oracle Enterprise Manager Lifecycle Managementの管理者ガイドを参照してください。

3. パッチ計画を分析してデプロイします。

25.2.7.5 パッチがステージングされていないか見つからない

エラーの説明

このエラーは、ステージング場所にパッチが存在しない場合に発生します。

図25-5に、このエラーの例を示します。この図は、計画分割機能も説明します。

図25-5 パッチ適用エラー: パッチがステージングされていないか見つからない

回避策

パッチがステージング場所で利用できることを確認します。パッチ計画を分析してデプロイします。

25.3 手動による管理エージェントへのパッチ適用

手動によるパッチ適用は、順を追った操作に従って管理エージェントに手動でパッチを適用する必要があるパッチ適用方法です。このパッチ適用方法では、特定の前提条件を満たしていることを確認し、適用性および競合についてパッチを手動で検証して、一度に1つの管理エージェントにのみパッチを適用する必要があります。

注意:
オラクル社では、自動によるパッチ適用方法をお薦めします。自動による方法では、パッチを大量にデプロイする場合の時間と労力が節約されるだけでなく、人手による操作が少なくなるため、パッチ適用時に発生するエラーを最小限に抑えることができます。

管理エージェント・ターゲットに手動でパッチを適用するには、次の手順を実行します。

1. My Oracle Support (https://support.oracle.com)にログインします。

注意:
「パッチの推奨」セクションで、使用環境に対して推奨されるパッチが表示されていることを確認します。

2. My Oracle Supportのホームページで、「パッチと更新版」をクリックします。

3. 「パッチ検索」セクションで必要なパッチの番号を入力して、「検索」をクリックします。

4. パッチを選択し、表示されるコンテキスト・メニューから「ダウンロード」をクリックします。

5. パッチZipファイルを抽出し、Readme.htmlまたはReadme.txtに記載されている手順に従って、パッチをインストールします。

注意:
Cloud Controlでは、管理エージェントと管理エージェント・プラグインのそれぞれのコア・コンポーネントに対して、異なる管理エージェント・パッチが存在します。管理エージェント・コア・コンポーネントまたは管理エージェント・プラグインのパッチを手動で適用する際には、<installation_base_directory>の下の正しいディレクトリの場所に移動していることを確認します。たとえば、エージェント・コア・コンポーネントにパッチを手動で適用する場合には<installation_base_directory>/core/に移動し、管理エージェント・プラグインにパッチを適用する場合には<installation_base_directory>/pluginsに移動する必要があります。管理エージェントのインストールのベース・ディレクトリの構造を、次に示します。

<installation_base_directory>
|_____core
|_____12.1.0.4.0
|_____plugins
|_____plugins.txt
|_____plugins.txt.status
|_____agent_inst
|_____sbin
|_____agentimage.properties

26 Cloud Controlのパーソナライズ

Oracle WebLogic Serverのホームページなどのターゲットのホームページを含めて、特定のCloud Controlページに表示されるページ・レイアウトとデータをパーソナライズできます。変更内容は現在ログインしているユーザーに固有なので、様々なターゲット・タイプを監視するカスタム・コンソールを作成することが可能になります。

現行リリースのパーソナライズ・サポートでは、次のことができます。

- ページのリージョンのレイアウトのカスタマイズ

- ページへのリージョンの追加または削除

- 各リージョンに表示されるデータの指定

- 独自のホームページの設定

Cloud Controlのすべてのページをパーソナライズできるわけではないことに注意してください。ページの編集モードは、変更可能なページまたはページ・リージョンでのみ有効になります。

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

- Cloud Controlページのパーソナライズ

- リージョンのカスタマイズ

- 独自のホームページの設定

- ポップアップ・メッセージのプリファレンスの設定

26.1 Cloud Controlページのパーソナライズ

Cloud Control内のページは列形式でレイアウトされています。各列には1つ以上のリージョンが含まれ、そのそれぞれに、棒グラフ、グラフまたはその他の視覚的コンポーネントで表現されたデータが含まれています。

各列内に表示するリージョンを選択できるだけでなく、ページ内の列のレイアウトを変更でき、それによりページ内のデータの配置および表示方法をパーソナライズできます。

ページをパーソナライズする手順:

1. パーソナライズするページにナビゲートします。

2. 次のいずれかを実行します。

- 「ログアウト」メニュー項目のすぐ左の現在ログインしているユーザーの名前を表示するメニュー項目から、「ページのパーソナライズ」を選択します。図26-1には、ユーザー名SYSMANのメニュー項目が表示されています。

図26-1 「ページのパーソナライズ」メニュー

- または、図26-2に示すように、ページの右側、「リフレッシュされたページ」タイムスタンプのすぐ上に表示されている「ページのパーソナライズ」のアイコンをクリックします。

図26-2 「ページのパーソナライズ」アイコン

このメニュー・アイテムまたはアイコンが有効なのは、現在表示しているページがパーソナライズ可能な場合のみです。

3. ページ編集モードに入ります。レイアウトの変更ボタンをクリックします。列のレイアウト・オプションのグラフィカル・メニューが開きます。

4. 使用する列のレイアウトを選択します。

5. 次に、リージョンを各列に追加します。特定の列の「コンテンツの追加」ボタンをクリックします。データを表示するために使用される使用可能なコンポーネントを含むリソース・カタログが開きます。

6. リージョンを選択し、「追加」をクリックして、リージョンを列に追加します。リージョンを1つずつスタックできることに注意してください。

7. リージョンを列に追加したら、次を実行できます。

- リージョンをカスタマイズします。詳細は、第26.2項「リージョンのカスタマイズ」を参照してください。

- リージョンの右上隅のアクションの表示メニューをクリックして、列内でリージョンを上下に移動します。

- ある列から別の列にリージョンをドラッグします。

8. 「閉じる」をクリックして、変更を保存します。

26.2 リージョンのカスタマイズ

リージョンには、棒グラフ、グラフまたは他の視覚的コンポーネントとして表示されたビジネス・データが含まれています。特定のリージョンに表示するコンポーネントを選択できます。

ページの列内のリージョンをカスタマイズする手順:

1. カスタマイズするリージョンのあるページに移動し、第26.1項「Cloud Controlページのパーソナライズ」の説明に従って、ページ編集モードを有効化します。

2. 図26-3に示すように、リージョン内の「X」アイコンの横にあるラチェット・レンチのアイコンをクリックします。このアイコンが有効なのは、リージョンがカスタマイズ可能な場合のみです。

図26-3 「リージョンのカスタマイズ」アイコン

ほとんどのリソースに対して、データを収集するターゲット・ホストを指定します。

その他の構成可能なパラメータやカスタマイズ・オプションは、リージョンごとに異なります。このアイコンをクリックすると、ターゲット・タイプ、ターゲット名およびメトリック名などのパラメータを指定できるダイアログが開きます。

3. 後で、ページからリージョンを削除したくなった場合には、そのリージョンにある「X」アイコンをクリックします。

4. 「閉じる」をクリックして、変更を保存します。

26.3 独自のホームページの設定

Cloud Controlでは、Cloud Controlにログイン後に最初に表示される、独自のホームページとして機能するページを選択できます。次のいずれかを実行できます。

- 頻繁に表示したり、特定のニーズに適合するようカスタマイズされたターゲットのホームページなど、独自のページを選択します。

- 特定のタイプのCloud Controlユーザー向けに作成された、事前設計済のホームページ・テンプレートから選択します。

独自のホームページの選択

1. ホームページとして設定するページにナビゲートします。

2. 図26-1に示すように、「ログアウト」メニュー項目のすぐ左、現在ログインしているユーザー名が表示されているメニュー項目から、「現在のページをホームとして設定」を選択します。

事前設計済のホームページの選択

1. 図26-1に示すように、「ログアウト」メニュー項目のすぐ左、現在ログインしているユーザー名が表示されているメニュー項目から、「ホームの選択」を選択します。

2. 「プレビュー」ボタンをクリックして、目的のページ・デザイン・テンプレートをプレビューします。

3. 「ホームとして選択」ボタンをクリックして、ホームページにするテンプレートを選択します。ページを選択したら、必要に応じてそれをカスタマイズできます。

独自のホームページの選択解除

独自のホームページは「お気に入り」のページとして保存されています。現在のホームページを選択解除するには、次の手順に従います。

1. 「お気に入り」メニューから、「お気に入りの管理」を選択します。

2. リストからホームページを選択してから、「選択項目の削除」ボタンをクリックします。

3. 終了したら、「OK」をクリックします。

26.4 ポップアップ・メッセージのプリファレンスの設定

ポップアップ・メッセージ・プリファレンス・ページでは、様々なサブコンポーネントからメッセージを選択し、Enterprise Manager Cloud Consoleの任意のページで、ユーザーにリアルタイムで表示できます。

このページで設定を適切に変更することで、ターゲット・ステータスの変更などの通知メッセージおよびスーパー管理者からのコマンドライン・ブロードキャスト・メッセージを表示できます。デフォルトでは、ポップアップ・メッセージは「表示」ステータスに設定されています。

ポップアップ・メッセージで「表示」ステータスを保持する場合には、次のプリファレンスを設定できます。

- ターゲットのステータス変更メッセージを表示します: ターゲット・ステータスが変更されるたびにこのオプションはメッセージを表示します。たとえば、ターゲットが停止または起動すると、ページに通知が表示されます。デフォルトでは、メッセージは15秒間継続します。このオプションの選択を解除すると、メッセージはターゲット・ページに表示されません。

- EMCLIメッセージにより、スーパー管理者が送信したメッセージを表示します: このオプションによって、スーパー管理者が送信したすべてのメッセージを表示できます。デフォルトでは、メッセージはEnterprise Manager Cloud Controlコンソールのすべての画面に表示されます。このオプションの選択を解除すると、メッセージは画面に表示されません。
たとえば、次のコマンドを実行すると、カスタム・メッセージの書かれたポップアップがEnterprise Manager Cloud Controlコンソールのすべての画面に表示されます。

emcli send_popup_message -messageType="INFO" -toOption="ALL" -message="EM will be taken down in an hour for an emergency patch"

メッセージは通常一時的で、特定のページで規定された時間だけ表示されます。ただし、コマンドライン・メッセージの場合、ユーザーが閉じることを選択するまでページにメッセージが表示されるようにできる柔軟性が加えられています。

次のタイプのメッセージがこのページでサポートされています: 確認、情報、警告、エラー、致命的。デフォルトでは、メッセージが表示される時間は「15秒」に設定されています。この値は、必要に応じて変更できます。

27 EMCTLコマンドを使用したEnterprise Managerの管理

Enterprise Manager Control (EMCTL)は、Enterprise Manager Cloud Controlのコア・コンポーネント、特にOracle Management Service (OMS)およびOracle Management Agent (管理エージェント)を管理または制御するためにEMとともにインストールされるコマンドライン・ユーティリティです。ユーティリティは、デフォルトですべてのEnterprise Managerインストールで使用可能です。

この章の項目は次のとおりです。

- EMCTLコマンドの実行

- 単一ホストで複数のEnterprise Managerコンポーネントを起動する際のガイドライン

- Oracle Enterprise Manager 12c Cloud Controlの起動および停止

- Oracle Management Serviceとともに起動されるサービス

- Windows上のOracle Management ServiceとManagement Agentの起動および停止

- EMCTLコマンドを使用したメトリック収集の再評価

- 新規のターゲット・モニタリング資格証明のEnterprise Managerでの指定

- EMCTLコマンド:

- OMSのEMCTLコマンド

- 管理エージェントのEMCTLコマンド

- EMCTLのセキュリティ・コマンド

- EMCTLのHAConfigコマンド

- EMCTLのResyncコマンド

- EMCTLのコネクタ・コマンド

- EMCTLのパッチ・リポジトリ・コマンド

- Windows NTのEMCTLコマンド

- EMCTLのPartoolコマンド

- EMCTLのプラグイン・コマンド

- OPSSポリシー・ストアとの同期のためのEMCTLコマンド

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

- Oracle Management Service起動エラーのトラブルシューティング

- 管理エージェント起動エラーのトラブルシューティング

- emctl.logファイルを使用したトラブルシューティング

27.1 EMCTLコマンドの実行

UNIXシステム上でOracle Management Service (OMS)に対してEMCTLコマンドを実行するには、<OMS_HOME>/binディレクトリに移動し、目的のコマンドを実行します。管理エージェントに対してEMCTLコマンドを実行するには、<AGENT_HOME>/binディレクトリに移動し、目的のコマンドを実行します。

同様に、Windowsシステム上でOMSまたは管理エージェントに対してEMCTLコマンドを実行するには、それぞれ<OMS_HOME>\binディレクトリまたは<AGENT_HOME>\binディレクトリに移動します。

27.2 単一ホストで複数のEnterprise Managerコンポーネントを起動する際のガイドライン

Oracle Enterprise Managerコンポーネントは、各種のOracleソフトウェア製品の管理に使用されます。本番環境では、ソフトウェア・リソースのパフォーマンスおよび可用性を向上させるため、複数のホスト間にデータベースおよびWebLogic Serverインスタンスを分散させる場合がほとんどです。ただし、同一ホスト上に複数のWebLogic Serverまたはデータベースをインストールする必要がある場合は、次のガイドラインを参考にしてください。

Fusion Middleware Control、管理エージェントまたはDatabase Controlを起動すると、Enterprise Managerはホストおよびその管理対象ターゲットに関する重要な監視データの収集を即時に開始します。ホスト上のコンポーネントの起動プロセスを開発する際は、このことを念頭に置いてください。

特に、次のプロセスが起動処理を開始する前に各Enterprise Managerプロセスが確実に起動できるように、起動プロセスの時間をずらすことを考慮してください。時間差をおく起動手順を使用することによって、各コンポーネントのCPU集中型の起動段階でのリソースに対するプロセスの競合が回避されます。ただし、システムの再起動時、EMのデプロイ時に登録された/etc/init.d/gcstartupスクリプトによって、OMSおよび管理エージェントが自動的に時間差をおいて起動されることが保証されます。

27.3 Oracle Enterprise Manager 12c Cloud Controlの起動および停止

次の項では、Oracle Enterprise Manager 12c Cloud Controlコンソールのインストール手順でインストールされるすべてのCloud Controlコンポーネントを停止および起動する方法について説明します。

ここで述べる手順を使用して、システムの再起動後にすべてのフレームワーク・コンポーネントを起動することや、システム・メンテナンスのためにシステムを停止する前にすべてのコンポーネントを停止することができます。

ここでは、次の手順について説明します。

- Cloud Controlとそのすべてのコンポーネントの起動

- Cloud Controlとそのすべてのコンポーネントの停止

27.3.1 Cloud Controlとそのすべてのコンポーネントの起動

次の手順には、Cloud Controlのすべてのコンポーネントの起動に必要なステップがまとめられています。たとえば、ホスト・コンピュータを再起動し、Cloud Controlのすべてのコンポーネントがそのホスト上にインストールされている場合は、この手順を使用します。

ホスト上のすべてのCloud Controlコンポーネントを起動するには、次の手順を実行します。

1. Oracle Management Repositoryがホスト上にある場合は、管理リポジトリをインストールした対象のデータベースのOracleホームにディレクトリを変更し、データベースおよびそのデータベースのNet Listenerを起動します。

1. ORACLE_HOME環境変数を管理リポジトリ・データベースのホーム・ディレクトリに設定します。

2. ORACLE_SID環境変数を管理リポジトリ・データベースのSID(デフォルトはasdb)に設定します。

3. Net Listenerを起動します。

$PROMPT> $ORACLE_HOME/bin/lsnrctl start

4. 管理リポジトリ・データベース・インスタンスを起動します。

ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> startup
SQL> quit

2. Oracle Management Serviceを起動します。

$PROMPT> OMS_HOME/bin/emctl start oms

3. ディレクトリをOracle Management Agentのホーム・ディレクトリに変更し、管理エージェントを起動します。

$PROMPT> AGENT_HOME/bin/emctl start agent

注意:
emctl start agentコマンドは、管理サービスのホーム・ディレクトリではなく、必ずOracle Management Agentのホーム・ディレクトリで実行してください。

27.3.2 Cloud Controlとそのすべてのコンポーネントの停止

次の手順には、Cloud Controlのすべてのコンポーネントの停止に必要なステップがまとめられています。たとえば、ホスト・コンピュータを停止または再起動する対象のホストと同じホストに、Cloud Controlのすべてのコンポーネントをインストールしている場合は、この手順を使用します。

ホスト上のすべてのCloud Controlコンポーネントを停止するには、次の手順を実行します。

1. Oracle Management Serviceを停止します。

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

2. ディレクトリをOracle Management Agentのホーム・ディレクトリに変更し、管理エージェントを停止します。

$PROMPT> AGENT_HOME/bin/emctl stop agent

注意:
emctl stop agentコマンドは、Oracle Management Serviceのホーム・ディレクトリではなく、必ずOracle Management Agentのホーム・ディレクトリで実行してください。

3. Oracle Management Repositoryが同じホストに存在する場合、次の手順に従います。

1. ORACLE_HOME環境変数を管理リポジトリ・データベースのホーム・ディレクトリに設定します。

2. ORACLE_SID環境変数を管理リポジトリ・データベースのSID(デフォルトはasdb)に設定します。

3. データベース・インスタンスを停止します。

$PROMPT> ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
SQL> quit

関連項目:
Oracle Databaseの起動および停止の詳細は、『Oracle Database管理者ガイド』を参照してください。

4. Netリスナーを停止します。

$PROMPT> $ORACLE_HOME/bin/lsnrctl stop

27.4 Oracle Management Serviceとともに起動されるサービス

管理サービスを起動するとき、次のサービスが起動されます。

1. OPMNプロセス。これはApacheプロセスのウォッチドッグです。OPMNプロセスは、Apacheプロセスがクラッシュしたときにそれを起動します。

2. HTTPサーバーを起動するApacheプロセス。

3. ノード・マネージャのJavaプロセス。これは、管理対象サーバーおよび管理サーバー・プロセスのウォッチドッグです。管理対象サーバーおよび管理サーバーのプロセスがクラッシュしたときに、それを再起動します。

4. 管理サーバーのJavaプロセス(OMSの起動コマンドが最初のOMSマシンで実行された場合)。これは、構成済Enterprise Managerドメインの構成データをメンテナンスするWebLogic Serverのインスタンスです。

5. 管理対象サーバーのJavaプロセス。これは、Enterprise Managerのアプリケーションがデプロイされる管理対象WebLogic Serverです。

6. (Windowsのみ)ノード・マネージャ・サービスのプロセス。これは、ノード・マネージャを起動および停止するためのWindowsサービスです(Linuxのノード・マネージャ・プロセスに相当する)。

7. (Windowsのみ)OMSサービスのプロセス。これは、OMSを起動および停止するWindowsサービスです。

8. BI PublisherサーバーのJavaプロセス(システムで構成済の場合)。これは、Oracle BI Publisherアプリケーションがデプロイされる管理対象WebLogic Serverです。

27.5 Windows上のOracle Management ServiceとManagement Agentの起動および停止

WindowsシステムにOracle Management Service (OMS)またはOracle Management Agentをインストールすると、インストール時に新規サービスが「サービス」コントロール パネルに作成されます。

「サービス」コントロール パネルにアクセスする手順は、使用しているMicrosoft Windowsのバージョンによって異なります。たとえばWindows 2000では、「スタート」メニューから、「設定」、「管理ツール」の順に選択して「サービス」コントロール パネルに移動します。

注意:
emctlユーティリティは、OMSまたは管理エージェントをインストールしたOracleホームのbinサブディレクトリで使用可能です。しかし、OMSまたは管理エージェントの起動および停止をWindowsシステム上で行う場合は「サービス」コントロール パネルの使用をお薦めします。

表27-1に、OMSおよび管理エージェントの制御に使用するWindowsサービスを示します。

表27-1 OMSおよび管理エージェントをWindowsにインストールする場合にインストールおよび構成されるサービス

コンポーネント

サービス名の形式

説明

Oracle Management Server

OracleManagementServer_EMGC_OMS1_1

このサービスを使用して、管理サービスJ2EEアプリケーションの一部としてインストールおよび構成されたすべてのコンポーネントを起動および停止します。

Oracle Management Agent

Oracle<agent_home>Agent

次に例を示します。

OracleOraHome1Agent

管理エージェントの起動および停止にはこのサービスを使用します。

27.6 EMCTLコマンドを使用したメトリック収集の再評価

次のコマンドを使用して、メトリック収集の即時再評価を実行します。

emctl control agent runCollection <targetName>:<targetType> <colletionItemName>

<collectionItemName>は、メトリックを収集する収集項目の名前です。

通常、関連メトリックはともに収集されます。ともに収集された一連のメトリックはメトリック収集と呼ばれます。各メトリック収集は独自の名前を持ちます。メトリックを再評価する場合、まずそれが属しているメトリック収集の名前を判別し、次にそのメトリック収集の収集項目を判別する必要があります。

前述のコマンドを実行してメトリックを再評価すると、同じメトリック収集および収集項目に含まれているその他のメトリックもすべて再評価されます。

次の手順を実行して、メトリックに対するメトリック収集名および収集項目名を判別します。

1. $INSTALL_BASE/ngagent/pluginsディレクトリ($INSTALL_BASEはインストールのルート)に移動します。管理エージェントのOracleホームはこのディレクトリにあります。

2. ターゲット・タイプのXMLファイルを探します。たとえば、「使用可能なファイルシステム領域(%)」というホスト・メトリックを対象とする場合は、host.xmlファイルを探します。

3. XMLファイル内で、対象とするメトリックを探します。メトリックとして認識しているものは、実際にはメトリックの表示名です。メトリック名には、次で始まるタグが先頭に含まれます。
<Label NLSID=

たとえば、host.xmlファイルでは、「使用可能なファイルシステム領域(%)」のメトリックには、次のようなエントリが含まれます。

<Label NLSID="host_filesys_pctAvailable">Filesystem Space Available (%) </Label>

4. XMLファイル内でメトリックを検索すると、そのエントリがより大きなエントリの一部であることがわかります。このエントリの先頭は次のとおりです。
<Metric NAME=

Metric NAMEに定義されている値を記録します。これがメトリック収集の名前です。たとえば、「使用可能なファイルシステム領域(%)」メトリックの場合、エントリは次のようになります。

<Metric NAME="Filesystems"

したがって、「使用可能なファイルシステム領域(%)」メトリックの場合、メトリック収集の名前はFilesystemsです。

5. 次に、このメトリック収集の収集項目を判別する必要があります。$INSTALL_BASE/plugins/<plugin idディレクトリに移動します。$INSTALL_BASEは管理エージェントのOracleホームです。

6. このディレクトリでは、ターゲット・タイプの収集ファイルを探します。この例では、これはhost.xmlです。

7. メトリック収集がそれ自体によって収集される場合は、同じ名前の単一の収集項目が収集ファイル内に存在します。メトリック収集にこれが該当するかどうかを判別するには、収集ファイル内で、次で始まるエントリを探します。
<CollectionItem NAME=

CollectionItem NAMEに割り当てられている値は、手順4のMetric NAMEと一致します。

「使用可能なファイルシステム領域(%)」メトリックの場合、収集ファイル内のエントリは次のようになります。

<CollectionItem NAME = "Filesystems"

8. そのようなエントリが見つかった場合、CollectionItem NAMEに割り当てられている値が、emctlコマンドで使用可能な収集項目の名前です。

9. それ以外の場合、メトリック収集は、単一の収集項目の下の他のメトリック収集とともに収集されることを意味します。メトリック収集の収集項目を見つけるには、まず、メトリック収集を探します。次のタグが先頭に含まれます。
<MetricColl NAME=

見つかったら、その上のファイル内で<CollectionItem NAME=を探します。

CollectionItem NAMEと関連する値は、emctlコマンドで使用する収集項目の名前です。

たとえば、「オープン・ポート」というホスト・メトリックを再評価する場合は、前述の手順を使用して次の操作を実行します。

1. $INSTALL_BASE/plugins/<plugin idディレクトリに移動します。$INSTALL_BASEは管理エージェントのOracleホームです。host.xmlファイルを探し、そのファイル内で<Metric NAME="openPorts"を探します。

2. $INSTALL_BASE/ngagent/plugins/default_collectionディレクトリに移動します。host.xmlファイルを探し、そのファイル内で<CollectionItem NAME="openPorts"を探します。
見つからなかった場合は、<MetricColl NAME="openPorts"を探します。

3. そのファイル内で、このエントリより前の部分で<CollectionItem NAME=文字列、および<CollectionItem NAME="oracle_security"を探します。

oracle_securityという収集項目名が、emctlコマンドを使用して「オープン・ポート」メトリックを再評価する際に使用されます。

27.7 新規のターゲット・モニタリング資格証明のEnterprise Managerでの指定

データベース・ターゲットのパフォーマンスを監視するため、Enterprise Managerはデータベースのユーザー名およびパスワードを使用してデータベースに接続されます。このユーザー名とパスワードの組合せが、データベースの監視資格証明と呼ばれます。

注意:
この項の指示はデータベース・ターゲットの監視資格証明に固有のものですが、監視資格証明が必要な他のあらゆるターゲット・タイプに対してこの手順を使用できます。たとえば、この手順を使用してOracle Management Serviceおよび管理リポジトリに対する新規の監視資格証明を指定できます。

Oracle9iデータベース・ターゲットを最初に追加したとき、または管理エージェントのインストール時に追加されたとき、Enterprise Managerでは監視資格証明として、DBSNMPデータベース・ユーザー・アカウントとDBSNMPアカウントのデフォルト・パスワードが使用されます。

Oracle Database 11gをインストールする際、データベースのインストール時にDBSNMP監視パスワードを指定します。

このため、DBSNMPデータベース・ユーザー・アカウントのパスワードが変更されている場合は、データベース・ターゲットのプロパティを変更して、Enterprise Managerが引き続きデータベースに接続して構成およびパフォーマンス・データを収集できるようにする必要があります。

同様に、Cloud Controlに新規のOracle Database 11gターゲットを追加したらすぐに、データベースのインストール時に定義したDBSNMPパスワードを認識するようにターゲットを構成する必要があります。このように構成しない場合、データベースのホームページに監視データが何も表示されず、データベースのステータスにメトリック収集エラーが示される可能性があります。

注意:
Enterprise Managerの監視資格証明は、Oracle Enterprise Manager 12c Cloud Controlコンソールを使用して変更できます。

27.8 OMSのEMCTLコマンド

表27-2に、OMSのEMCTLコマンドを示します。

表27-2 OMSのEMCTLコマンド

EMCTLコマンド

説明

emctl getversion oms

OMSインスタンスのバージョンを表示します。

emctl start oms

OMSアプリケーションおよびJVMDエンジンの実行に必要なFusion Middlewareコンポーネントを起動します。

具体的にいうと、このコマンドは、HTTP Server、ノード・マネージャ、OPMNプロセス、および管理サービスがデプロイされる管理対象サーバーを起動します。さらに、このコマンドを管理サーバーがあるホストで実行した場合、その管理サーバーも起動されます。同様に、Oracle BI Publisherが構成されたホストでこのコマンドを実行すると、Oracle BI Publisherも起動されます。

注意: OMSを起動または停止できるのはOracleソフトウェア所有者のみです。

emctl start oms -admin_only

ドメインの管理サーバーのみ起動します。

emctl start oms -bip_only

BI Publisherサーバーのみ起動します。

emctl stop oms

OMS管理対象サーバー、JVMDエンジンおよびHTTPサーバーを停止しますが、ノード・マネージャと管理サーバーは実行中のままにします。

注意: emctl stop omsコマンドではFusion Middlewareを停止しません。

emctl stop oms -all

管理サーバー、OMS、HTTP Server、ノード・マネージャ、管理サーバー、JVMDエンジンおよびOracle BI Publisher (ホストで構成済の場合)を含むすべてのEnterprise Managerプロセスを停止します。

emctl stop oms -all -force

および

emctl stop oms -force

OMSを停止します。

パラメータ-forceは、emctl stop oms -allおよびemctl stop omsの両方のコマンドで使用できます。-forceオプションは、関連プロセスを強制的に停止します。このパラメータを使用することはお薦めしません。

emctl stop oms -bip_only [-force]

BI Publisherサーバーのみ停止します。

パラメータ-forceは、プロセスを正常にではなく強制的に停止します。このパラメータを使用することはお薦めしません。

emctl status oms

OMS、JVMDエンジンおよびBI Publisherサーバーのステータスをリストします。

emctl status oms -bip_only

BI Publisherサーバーのステータスのみリストします。

emctl status oms -details [-sysman_pwd <pwd>]

次のようなOMSの詳細をリストします。

- OMSのHTTPおよびHTTPSアップロードおよびコンソール・ポートとそれぞれのURL

- インスタンス・ホームの場所

- OMSログ・ディレクトリ

- ソフトウェア・ロード・バランサ構成の詳細

- 管理サーバー・マシンおよびポート

- Oracle BI Publisherの詳細

- JVMDエンジン

-sysman_pwdパラメータは、Enterprise ManagerのSYSMANパスワードを示します。コマンドラインで指定しないと、入力するように求められます。

emctl set property

OMS構成プロパティの値を設定します。

デフォルトでは、コマンドemctl set propertyはすべてのOMSのプロパティ値を設定します。特定のOMSのプロパティ値を設定するには、追加オプションの-oms_nameを、hostname.myco.com:17707_Management_Serviceという形式で指定します。現在のOMSのプロパティ値を設定するには、-oms_name = "local_oms."と指定します。リモートのOMSのプロパティ値を設定するには、-oms_name=<name of remote OMS>と指定します。

注意: Enterprise Manager 12.1.0.2.0以降では、次のようにCloud ControlコンソールでOMSプロパティを表示および編集できます。

1. 「設定」メニューから、「Cloud Controlの管理」、「管理サービス」の順に選択します。

2. 「管理サービス」ページで、「構成プロパティ」をクリックします。

3. 「構成プロパティ」ページで、OMSプロパティを表示および編集できます。
注意: このページに移動するには、「OMS構成プロパティ」リソース権限が必要です。

emctl get property

OMS構成プロパティの値を表示します。

emctl get property -name <property name> [-oms_name <OMS name>] [-sysman_pwd "sysman password"]

指定したプロパティの値を表示します。

-nameはプロパティの名前、-oms_nameはプロパティ値が導出されるOMSの名前を示します。-oms_nameを指定しないと、すべてのOMSのプロパティ値が表示されます。

emctl set property -name <property name> -value <property value> [-oms_name <OMS name>] [-module <emoms|logging>] [-sysman_pwd "sysman password"]

指定したプロパティの値を設定します。

次に各パラメータについて説明します。

- -name: プロパティの名前を指定します。

- -oms_name: プロパティ値を設定する必要のあるOMSを示します。このオプションを指定しないと、プロパティ値はグローバル・レベルまたは現在のOMSで設定されます。

- -module_name: プロパティのモジュールを示します。loggingまたはemomsを指定します。loggingプロパティはLog4jを構成するために使用されますが、emomsプロパティはOMSを構成するために使用されます。

emctl set property -file <absolute path of the file containing properties> [-oms_name <OMS name>] [-module <emoms|logging>] [-sysman_pwd "sysman password"]

指定したファイルのプロパティの値を設定します。

次に各パラメータについて説明します。

- -file_name: プロパティおよび値を含む.propertiesファイルの絶対パスを示します。このファイルには、値の設定が必要なプロパティのみが含まれる必要があります。

- -oms_name: プロパティ値を設定する必要のあるOMSを示します。このオプションを指定しないと、プロパティ値はグローバル・レベルまたは現在のOMSで設定されます。

- -module_name: プロパティのモジュールを示します。loggingまたはemomsを指定します。loggingプロパティはLog4jを構成するために使用されますが、emomsプロパティはOMSを構成するために使用されます。

emctl delete property -name <property name> [-oms_name <OMS name>] [-module <emoms|logging>] [-sysman_pwd "sysman password"]

指定したプロパティの構成済の値を削除し、デフォルト値に設定します。

-nameはプロパティの名前、-oms_nameはプロパティ値が削除されるOMSの名前を示します。-oms_nameを指定しないと、プロパティ値はグローバル・レベルまたは現在のOMSで削除されます。

emctl list properties

すべてのOMSのプロパティを表示します。

-out_fileパラメータを使用して、すべてのOMSのすべてのプロパティのリストを取得します。このコマンドによって、2つのOMS間の構成を簡単に比較できます。

emctl list properties [-oms_name <OMS name>] [-module <emoms|logging>] [-out_file <output file name>] [-sysman_pwd "sysman password"]

ユーザーに表示されるすべてのOMSプロパティの値を表示します。

次に各パラメータについて説明します。

- -oms_name: プロパティ値が表示されるOMSを示します。このオプションを指定しないと、すべてのOMSのプロパティ値が表示されます。

- -module_name: プロパティのモジュールを示します。このオプションは、モジュール固有のプロパティを表示するためのフィルタとして使用できます。loggingプロパティはLog4jを構成するために使用されますが、emomsプロパティはOMSを構成するために使用されます。

- -out_file: 出力ファイルの絶対パスを示します。これは、出力をファイルに保存するためのオプションのパラメータです。

emctl config oms -list_repos_details

OMSリポジトリの詳細を表示します。

emctl config oms -store_repos_details [-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <connect descriptor> ] -repos_user <username> [-repos_pwd <pwd>]

管理リポジトリとして指定したデータベースを使用するようにOMSを構成します。

コマンドに示されているすべての追加パラメータを指定する必要があります。

emctl config oms -change_repos_pwd [-old_pwd <old_pwd>] [-new_pwd <new_pwd>] [-use_sys_pwd [-sys_pwd <sys_pwd>]]

リポジトリ・データベースおよびOMSでrootユーザー(SYSMAN)のパスワードを変更します。

Enterprise Managerのrootユーザー(SYSMAN)のパスワードを変更するには:

1. emctl stop omsコマンドを使用してすべてのOMSを停止します。

2. いずれかのOMSでemctl config oms -change_repos_pwdを実行します。

3. emctl stop oms -allおよびemctl start omsコマンドを使用してすべてのOMSを再起動します。

emctl config oms -change_view_user_pwd [-sysman_pwd <sysman_pwd>] [-user_pwd <user_pwd>] [-auto_generate]

OMSがMGMT_VIEWユーザーのためにレポート生成に使用するパスワードを構成します。

Enterprise ManagerのMGMT_VIEWユーザーのパスワードを変更するには:

1. emctl stop omsコマンドを使用してすべてのOMSを停止します。

2. いずれかのOMSでemctl config oms -change_view_user_pwdを実行します。

3. emctl stop oms -allおよびemctl start omsコマンドを使用してすべてのOMSを再起動します。

emctl secure oms

OMSのSSL構成を設定します。

emctl genreport oms -file_name <file_name> [-dest_dir <dest_dir>]

emcliトレース・パフォーマンス・レポートを生成および保存します。

-file_nameはトレース・データを含む入力ファイルの名前を示し、-dest_dirはパフォーマンス・レポートが保存される出力ディレクトリの名前を示します。

emctl gen_ui_trace_report oms [-start_time <start_time in hh:mm:ss format>] [-duration <duration in hh:mm format>] [-user_name <username>] [-out_file <out_file>] [-sysman_pwd <sysman_pwd>]

ユーザー・インタフェース(UI)・アクセスのパフォーマンス・レポートを生成します。

次に各パラメータについて説明します。

- -user_name: UIアクセスのパフォーマンス・レポートを生成する必要のあるユーザー名を示します。デフォルトは、すべてのユーザーです。

- -start_time: レポート生成の開始時間をhh:mm:ssの形式で示します。

- -duration: レポート生成の期間をhh:mmの形式で示します。デフォルトは01:00です。最大期間は24:00です。

- -out_file: 出力レポート・ファイルの名前を示します。

emctl config oms -set_startup_mode [pbs_only | console_only | normal]

OMSの起動モードを構成します。このコマンドをプライマリOMSで実行することはできません。

次の3つの起動モードがあります。

- pbs_only: 起動モードをpbs_onlyに構成すると、コマンドemctl start omsはPBSアプリケーションのみ起動します。

- console_only: 起動モードをconsole_onlyに構成すると、コマンドemctl start omsはコンソール・アプリケーションのみ起動します。

- normal: 起動モードをnormal,に構成すると、コマンドemctl start omsはPBSとコンソールの両方のアプリケーションを起動します。

emctl config oms -get_startup_mode

現在のOMSのOMS起動モードを表示します。

emctl config oms sso -host ssoHost -port ssoPort -sid ssoSid -pass ssoPassword -das dasURL -u user

認証にOracle SSO (OSSO)を使用するようにEnterprise Manager (EM)を構成します。このコマンドを使用するには、このコマンドの入力として生成済の登録ファイルが必要になるため、EMサイトをOSSOサーバーに登録しておく必要があります。

emctl config oms -update_ds_pwd -ds_name <datasource_name> [-ds_pwd <datasource_pwd>]

指定したデータソースの新しいパスワードを更新します。

コマンドでは、-ds_nameはデータソースの名前を示し、-ds_pwdはデータソースの新しいパスワードを示します。

emctl config oms -store_embipws_creds [-admin_pwd <weblogic_pwd>] [-embipws_user <new_embipws_username>] [-embipws_pwd <new_embipws_pwd>]

インストールしたBI PublisherのWebサーバーにアクセスするためにEnterprise Managerが使用するパスワードとオプションでユーザー名を変更します。

emctl動詞は、バックエンドのユーザーの資格証明は変更しません。対応するアプリケーションまたはコンソールを使用して、このemctl動詞で使用する資格証明と一致するようにバックエンドの資格証明を構成します。

このコマンドは、BI Publisherがインストールされている場合にのみ動作します。このコマンドでは、いずれのOMS (EMGC_OMS####、BIP####)も再起動する必要はありません。

emctl config oms -bip_shared_storage -config_volume <vol1> -cluster_volume <vol2> [-admin_pwd <adminpwd>] [-sysman_pwd <sysmanpwd>]

OMSの追加の準備として、BI Publisherの共有記憶域を設定します(スケールアウトされたBI Publisherも含みます)。OMSを追加すると、高可用性環境で動作するBI Publisherサーバーが自動的に追加されます。したがって、BI Publisherは冗長性とスケーラビリティの両方をサポートすることになります。

このコマンドは、高可用性(HA)環境でBI Publisherを実行するための準備として、共有記憶域の場所を設定または移動する場合に使用します。

パラメータ-config_volumeは、BI Publisherのリポジトリおよび構成ファイルを指定します。このパラメータで指定したボリュームに、既存のボリュームがコピーされます。

パラメータ-cluster_volumeは、BI PublisherのスケジューラがHA環境で動作するために必要なストレージを指定します。

通常、このコマンドは、プライマリOMSおよびプライマリBI Publisherを含むシステムで1回のみ実行されます。

emctl extended oms <verb> [verb_args] [-help]

EMCTL拡張フレームワークに登録された<verb>を実行します。

verb_argsパラメータは、動詞固有の引数を指定します。

-helpパラメータは、動詞固有のヘルプを表示します。拡張された動詞のリストについては、emctl extended omsを実行してください。

emctl register oms metadata -service <Metadata Service Id> (-file <Metadata Instance file> | -file_list <File containing list of files to register>) (-core | -pluginId <Plugin Id>) [-sysman_pwd <sysman password>]

メタデータを登録します。

-file_listパラメータは、ファイル・パスのリスト(1行に1つずつ)を含むファイルへのパスを表示します。これらのファイル・パスは、-coreパラメータを渡すか、-pluginIdパラメータを渡すかによって、OMS OracleホームまたはプラグインOracleホームの相対パスになります。

emctl register oms metadata -service targetType -file <XML filename> [-core | -pluginId <Plugin Id>] [-sysman_pwd "sysman password"]およびemctl register oms metadata -service storeTargetType -file <XML filename> [-core | -pluginId <Plugin Id>] [-sysman_pwd "sysman password"]

これらの2つのコマンドが順番に実行されたときにターゲット・タイプを登録します。

パラメータ-file <XML filename>は、ターゲット・タイプの.xmlファイル名と絶対パスまたは相対パスを指定します。

emctl deregister oms metadata -service <Metadata Service Id> (-file <Metadata Instance file> && (-old_file <File containing previous metadata instances> | -no_old_file <in case there are no previous metadata instances>)) | -file_list <File containing list of ';' separeated new and old files to deregister>) (-core | -pluginId <Plugin Id>) [-sysman_pwd <sysman password>]

メタデータを消去します。

-file_listオプションは、ファイル・パスのリスト(1行に1つずつ)を含むファイルへのパスを表示します。これらのファイル・パスは、-coreパラメータを渡すか、-pluginIdパラメータを渡すかによって、OMS OracleホームまたはプラグインOracleホームの相対パスになります。

27.9 管理エージェントのEMCTLコマンド

表27-3に、管理エージェントのEMCTLコマンドを示します。

表27-3 管理エージェントのEMCTLコマンド

EMCTLコマンド

説明

emctl start agent

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

大規模なメモリー構成を使用するIBM AIX環境で、管理エージェントによって多数のターゲットが監視されている場合、エージェントが起動しないことがあります。この問題を防止するには、管理エージェントを起動する前に、共通の環境ファイルに次のパラメータを追加します。

LDR_CNTRL="MAXDATA=0x80000000"@NOKRTL
AIXTHREAD_SCOPE=S

LDR_CNTRL変数は、データ・セグメントのサイズを設定し、カーネル空間でのランタイム・ライブラリのロードを無効にします。AIXTHREAD_SCOPEパラメータは、AIXスレッドスコープのコンテキストを、デフォルトのP(プロセス全体)からS(システム全体)に変更します。これにより、mutexの競合が少なくなります。

emctl stop agent

管理エージェントを停止します。

emctl status agent

管理エージェントのステータスをリストします。

管理エージェントが実行中の場合、このコマンドで、エージェント・ホーム、プロセスIDおよび最後に成功した管理リポジトリへのアップロードの日時など、管理エージェントに関するステータス情報を表示します。

注意: コマンドの実行前にWindowsシステム上でディレクトリをAGENT_INSTANCE_HOMEディレクトリに変更します。

emctl status agent -secure

管理エージェントの保護ステータスおよび管理エージェントが実行している保護モード・ポートをリストします。また、OMSのセキュリティ・ステータスおよびポートもリストします。

emctl status agent scheduler

実行中、準備完了および計画のすべての収集スレッドをリストします。

emctl status agent jobs

現在管理エージェントで実行しているジョブのステータスをリストします。

emctl status agent target <target name>,<target type>,<metric>

指定されたターゲットの詳細ステータス(ターゲット名、ターゲット・タイプなど)をリストします。emctl status agentコマンドに特定のメトリック名を指定することで、ターゲットの特定のメトリックのステータスも取得できます。

emctl status agent mcache <target name>,<target type>,<metric>

メトリック・キャッシュに値が存在しているメトリックの名前をリストします。

emctl upload

アップロードが保留されている.xmlファイルをアップロード・ディレクトリのOMSにアップロードします。

emctl upload(エージェント)

管理対象ホストから管理サービスに対する現在の管理データの即時アップロードを強制実行するには、このコマンドを使用します。このコマンドは、次に予定されているデータのアップロードまで待てない場合に使用できます。

emctl reload(agent)

このコマンドは、emd.propertiesファイルを手動で変更した後に、変更を適用する場合に使用できます。たとえば、アップロード間隔を変更するには、emd.propertiesを変更した後、emctl reloadを実行できます。

注意: 手順が明確に文書化されている場合またはOracleサポートからユーザーに指示があった場合を除いて、手動によるtargets.xmlファイルの編集はサポートされていません。

emctl reload agent dynamicproperties [<Target_name>:<Target_Type>]...

ターゲットの動的プロパティを再計算し、表示します。

emctl pingOMS [agent]

OMSにpingを送信して、管理エージェントがOMSに接続できるかどうかを確認します。pingOMSが正常であることを確認できるように、管理エージェントはOMSからpingが返されるまで待機します。

emctl config agent getTZ

環境に設定したとおり現在のタイムゾーンを構成します。

emctl config agent getSupportedTZ

環境に設定されている値に基づいてサポートされているタイムゾーンを表示します。

emctl config console <fileloc> [<EM loc>]

ファイル<fileloc>に指定されている構成エントリに基づいてコンソールを構成します。

<EM loc>パラメータはオプションで、別のOracleホームで動作するために使用できます。

emctl config agent listtargets [<EM loc>]

管理エージェントによって監視するすべてのターゲット名およびタイプ(targets.xmlファイルにあります)をリストします。

<EM loc>パラメータはオプションで、別のOracleホームで動作するために使用できます。

emctl control agent runCollection <target_name>:<target_type> <metric_name>

ターゲットの特定のメトリックの収集を手動で実行できます。

たとえば、emctl control agent runCollection myOracleHomeTargetName:oracle_home oracle_home_configです。

emctl control agent runCollection <targetName>:<targetType> <colletionItemName>

メトリック収集の即時再評価を実行します

このコマンドを実行すると、メトリックの再評価された値が管理リポジトリにアップロードされ、メトリックがしきい値を超えた場合にアラートをトリガーします。

メトリックに関連付けられているメトリック名と収集項目名を特定するには、第27.6項を参照してください。

emctl resetTZ agent

管理エージェントのタイムゾーンをリセットします。現在のタイムゾーンを別のタイムゾーンに変更するには、管理エージェントを停止してから、このコマンドを実行します。その後、管理エージェントを起動します。

重要:

管理エージェントのタイムゾーンを変更する前に、管理エージェントで管理されているターゲットで現在実行中または実行予定のブラックアウトがあるかどうかを確認してください。ブラックアウトの確認方法については、第4.2.3項を参照してください。

ブラックアウトが存在する場合は、Cloud Controlコンソールから、その管理エージェントで監視されているすべてのターゲットでスケジュールされているブラックアウトおよび現在実行中のブラックアウトをすべて停止します。その後、管理エージェントのタイムゾーンを変更でき、さらに必要に応じてターゲットに新しいブラックアウトを作成できます。

emctl getversion agent

管理エージェントのバージョンを出力します。

emctl dumpstate agent <component> . . .

管理エージェントのダンプを生成します。このコマンドを使用すると、管理エージェントのメモリー/CPUに関する問題を分析できます。

emctl gensudoprops

管理エージェントのsudoプロパティを生成します。

emctl clearsudoprops

sudoプロパティをクリアします。

emctl clearstate

状態ディレクトリの内容をクリアします。このコマンドを実行すると、$ORACLE_HOME/sysman/emd/stateにあるファイルが削除されます。状態ファイルは、管理エージェントによって対応する.xmlファイルに変換されるのを待機しているファイルです。

emctl getemhome

管理エージェントのホーム・ディレクトリを出力します。

emctl start blackout <Blackoutname> [-nodeLevel] [<Target_name>[:<Target_Type>]].... [-d <Duration>]

ターゲットでブラックアウトを開始します。

パラメータ<Target_name:Target_type>を入力しないと、デフォルトとしてローカル・ノード・ターゲットが取得されます。<Blackoutname>の後に-nodeLevelパラメータを指定すると、ブラックアウトがすべてのターゲットに適用され、その後に続くターゲット・リストは無視されます。<Duration>は[days] hh:mmの形式で指定する必要があります。

emctl stop blackout <Blackoutname>

特定のターゲット上で開始されたブラックアウトを停止します。emctlを使用して停止できるのは、emctlツールによって開始されたブラックアウトのみです。このコマンドでは、コンソールまたはemcliユーティリティを使用して開始されたブラックアウトは停止できません。

emctl status blackout[<Target_name>[:<Target_Type>]]....

ターゲットのブラックアウトのステータスを示します。ステータスには、ブラックアウトのタイプ、ブラックアウトが1回のアクションか、繰返しか、またはスケジュール済のいずれであるかが含まれます。このコマンドは、ブラックアウトが開始または停止されているかどうかも指定します。

emctl secure agent [registration password] -emdWalletSrcUrl <url> -protocol <ssl|tls>

OMSで管理エージェントを保護します。コマンドで登録パスワードを指定しなかった場合は入力が求められるため、このパスワードは必須です。

-emdWalletSrcUrlパラメータは、エージェントを保護する必要があるOMSのURLを示します。

-protocolパラメータは、管理エージェントを保護するために使用するプロトコルを示します。使用できる値は、sslおよびtlsです。

emctl unsecure agent

管理エージェントの保護を解除します。このコマンドは、管理エージェントのポートをHTTPポートに変更します。このコマンドを実行した後、管理エージェントは、OMSのHTTPSアップロード・ポートではなく、HTTPアップロード・ポートに接続することによって、HTTPのOMSにアップロードできるようになります。

emctl verifykey

pingOMSの送信によって、OMSと管理エージェント間の通信を検証します。

emctl deploy agent [-s <install-password>] [-o <omshostname:consoleSrvPort>] [-S] <deploy-dir> <deploy-hostname>:<port> <source-hostname>

管理エージェントのみ作成およびデプロイします。

次に各パラメータについて説明します。

- [-s <password>]: 管理エージェントを保護するためのインストール・パスワードを示します。

- [-S ]: パスワードがSTDINで指定されることを示します。

- [-o <omshostname:consoleSrvPort>]: OMSホスト名およびコンソール・サーブレット・ポートを示します。保護解除されたポートを選択します。

- <deploy-dir>: 共有(状態のみ)のインストール・ポートを作成するためのディレクトリを示します。

- <deploy-hostname:port>: 共有(状態のみ)インストールのホスト名およびポートを示します。未使用のポートを選択します。

- <source-hostname>: ソース・インストールのホスト名を示します。通常、EMがインストールされているマシンです。ホスト名は、targets.xmlファイルで検索されるか、またはこのファイルで引数<deploy-hostname:port>で指定したホスト名と置き換えられます。

- <sid>: リモート・データベースのインスタンスを示します。dbconsoleをデプロイする場合にのみ指定します。

emctl setproperty agent

管理エージェント構成ファイルで指定したプロパティ名および値を構成します。フラグallow_newは、管理エージェント構成ファイルに新しいプロパティが存在しない場合に挿入するオプションのフラグです。

emctl getproperty agent

管理エージェント構成ファイルから、指定したプロパティまたはプロパティのカテゴリを取得します。現在、このコマンドでは名前に空白を使用できません。フラグ-nameは、プロパティ名のリストを空白で区切って表示します。

emctl clear_property agent

管理エージェント構成ファイルで指定したプロパティの値を消去します。

emctl status agent verify

管理エージェントが稼働していることを確認します。

27.10 EMCTLのセキュリティ・コマンド

この項では、EMCTLのセキュリティ・コマンドについて説明します。

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

- EMCTLのセキュリティ・コマンド

- セキュリティ診断コマンド

- EMCTL EMキー・コマンド

- 認証の構成

27.10.1 EMCTLのセキュリティ・コマンド

表27-6に、EMCTLの一般的なセキュリティ・コマンドを示します。

表27-4 EMCTLのセキュリティ・コマンド

EMCTLコマンド

説明

emctl secure console [-sysman_pwd <pwd>] (-wallet <wallet_loc>| -self_signed) [-key_strength <strength>] [-cert_validity <validity>]

OMSのHTTPSコンソール・ポートのSSL構成を設定します。

emctl secure lock [-sysman_pwd <pwd>] [-console] [-upload]

OMSのアップロードおよびコンソールをロックすることで、OMSへのHTTPアクセスを回避します。

-consoleおよび-uploadパラメータはオプションです。

-consoleパラメータはEMコンソールへのHTTPアクセスをロックおよび回避し、HTTPSでのみEMコンソールにアクセスできるようにします。

-uploadパラメータによって、管理エージェントがOMSに接続できるのはHTTPS経由でのみになるため、管理エージェントがHTTP経由でOMSにデータをアップロードできなくなります。

emctl secure unlock [-sysman_pwd <pwd>] [-console] [-upload]

OMSアップロードおよびコンソールのロックが解除されるため、OMSへのHTTPアクセスが可能になります。

-consoleおよび-uploadパラメータはオプションです。

-consoleパラメータは、HTTP経由でもアクセスできるようにコンソールのロックを解除します。

-uploadパラメータは、アップロード・アクティビティのロックを解除するため、管理エージェントはHTTP経由でもOMSにデータをアップロードできるようになります。

emctl secure createca [-sysman_pwd <pwd>] [-root_country <root_country>] [-root_state <root_state>] [-root_org <root_org>] [-root_unit <root_unit>] [-key_strength <strength>] [-cert_validity <validity>]

後でOMSおよび管理エージェントを保護するときに証明書を発行するために使用する新しい認証局(CA)を作成します。

emctl secure setpwd [sysman password] [new registration password]

新しい管理エージェント登録パスワードを追加します。

emctl secure sync

管理リポジトリが起動しているかどうかを確認します。

emctl secure create_admin_creds_wallet [-admin_pwd <pwd>] [-nodemgr_pwd <pwd>]

管理者資格証明ウォレットを再作成します。

emctl secure oms [-sysman_pwd <sysman password>] [-reg_pwd <registration password>] [-host <hostname>] [-ms_hostname <Managed Server hostname>] [slb_port <SLB HTTPS upload port>] [-slb_console_port <SLB HTTPS console port>] [-no_slb] [-secure_port <OHS HTTPS upload Port>] [-upload_http_port <OHS HTTP upload port>] [-reset] [-console] [-force_newca] [-lock_upload] [-lock_console] [-unlock_upload] [-unlock_console] [-wallet <wallet_loc> -trust_certs_loc <certs_loc>] [-key_strength <strength>] [-sign_alg <md5|sha1|sha256|sha384|sha512>] [-cert_validity <validity>] [-protocol <protocol>] [-root_dc <root_dc>] [-root_country <root_country>] [-root_email <root_email>] [-root_state <root_state>] [-root_loc <root_loc>] [-root_org <root_org>] [-root_unit <root_unit>]

emctl secure omsコマンドは、管理リポジトリにルート鍵を生成し、OMSと管理エージェント間のHTTPSチャネルが有効になるようにWebTierを変更し、OMSがEnterprise Managerフレームワーク・セキュリティを使用して管理エージェントからのリクエストを受け入れることができるようにします。

emctl secure wls [-sysman_pwd <sysman password>] (-jks_loc <loc> -jks_pvtkey_alias <alias> | -wallet <loc> | -use_demo_cert)

emctl secure wlsコマンドは、WebLogic Serverを保護します。

前述のコマンドのパラメータについて次に説明します。

- -host: ソフトウェア・ロード・バランサ(SLB)または仮想ホスト名を示します。

- -ms_hostname: OMSが実行しているマシンの実際のホスト名を示します。

- -slb_port: アップロード用にSLBで構成されたHTTPSポートを示します。

- -slb_console_port: コンソール・アクセス用にSLBで構成されたHTTPSポートを示します。

- -no_slb: SLB構成を削除します。

- -secure_port : WebTierでのHTTPSアップロード・ポート変更を指定します。

- -upload_http_port: WebTierでのHTTPアップロード・ポート変更を指定します。

- -reset: 新しいCAを作成します。

- -force_newca: 古いCAで保護された管理エージェントがある場合でも、新しいCAを使用してOMSで強制的に保護します。

- -console: コンソールHTTPSポート用にも証明書を作成します。

- -lock_upload: アップロードをロックします。

- -lock_console: コンソールをロックします。

- -unlock_upload: アップロードのロックを解除します。

- -unlock_console: コンソールのロックを解除します。

- -wallet: 外部ウォレットが配置されるディレクトリを示します。

- -trust_certs_loc: 信頼できるすべての証明書を含むファイルを示します。

- -key_strength: 512|1024|2048

- -sign_alg: 署名アルゴリズムmd5|sha1|sha256|sha384|sha512です。

- -cert_validity: 証明書が有効である必要がある日数を示します。最小値が1で、最大値が3650です。

- -protocol: WebTierで使用されるSSLプロトコルを示します。<protocol>の有効な値は、ApacheのSSLプロトコル・ディレクティブで許容される値です。

- -jks_loc: 管理者および管理対象サーバーのカスタム証明書を含むJKSの場所を示します。

- -jks_pvtkey_alias: JKSの秘密鍵の別名を示します。

- -jks_pwd: JKSのキーストアのパスワードを示します。

- -jks_pvtkey_pwd: JKSの秘密鍵のパスワードを示します。

- -wallet: 管理者および管理対象サーバーのカスタム証明書を含むウォレットの場所を示します。

- -use_demo_cert: 管理者および管理対象サーバーのデモンストレーション証明書を構成します。

27.10.2 セキュリティ診断コマンド

表27-5に、EMCTLのセキュリティ診断コマンドを示します。

表27-5 EMCTLのセキュリティ診断コマンド

EMCTLコマンド

説明

emctl secdiag openurl -url <url> [-trust_store <location of jks or base64 file>] [-ssl_protocol <protocol>] [-cipher <low|medium|high|some_ciphersuite_name>] [-proxy_host <host> -proxy_port <port>] [-proxy_realm <realm>] [-proxy_user <user> -proxy_pwd <pwd>]

指定されたURLへの接続性の問題を診断します。

パラメータについて次に説明します。

- -url: テストするURLを示します。

- -trust_store: トラスト・ストアの場所を示します。jksまたはbase64ファイルです。指定しないと、接続は無条件に信頼されることになります。

- -ssl protocol: 接続を確立するために使用されるプロトコルを示します。

- -cipher: 使用される暗号スイートを示します。low、medium、highまたは暗号スイート名を指定できます。

- -proxy_host: プロキシ・サーバーのホスト名を示します。

- -proxy_port: プロキシ・サーバーのポート番号を示します。

- -proxy_realm: プロキシ・サーバーのレルムを示します。

- -proxy_user: プロキシ・ユーザーのIDを示します。

- -proxy_password: プロキシ・ユーザーのパスワードを示します。

emctl secdiag dumpcertsinrepos -repos_conndesc <connect desriptor> [-repos_pwd <pwd>]

指定されたリポジトリに格納された信頼できる証明書を表示します。

emctl secdiag dumpcertsinfile -file <location of jks/sso/p12/base64 file>

指定されたキーストア、ウォレットまたはbase64ファイルにある信頼できる証明書を表示します。

27.10.3 EMCTL EMキー・コマンド

表27-6に、EMCTL EMキー・コマンドを示します。

表27-6 EMCTL EMキー・コマンド

EMCTLコマンド

説明

emctl status emkey [-sysman_pwd <パスワード>]

emkeyの状態またはステータスを表示します。

emctl config emkey -copy_to_credstore [-sysman_pwd <パスワード>]

emkeyを管理リポジトリから資格証明ストアにコピーします。

emctl config emkey -remove_from_repos [-sysman_pwd <パスワード>]

emkeyを管理リポジトリから削除します。

emctl config emkey -copy_to_file_from_credstore -admin_host <ホスト> -admin_port <ポート> -admin_user <ユーザー名> [-admin_pwd <パスワード>] [-repos_pwd <パスワード>] -emkey_file <emkeyファイル>

emkeyを資格証明ストアから指定されたファイルにコピーします。

emctl config emkey -copy_to_file_from_repos (-repos_host <ホスト> -repos_port <ポート> -repos_sid <SID> | -repos_conndesc <接続記述子>) -repos_user <ユーザー名> [-repos_pwd <パスワード>] [-admin_pwd <パスワード>] -emkey_file <emkeyファイル>

emkeyを管理リポジトリから指定されたファイルにコピーします。

emctl config emkey -copy_to_credstore_from_file -admin_host <ホスト> -admin_port <ポート> -admin_user <ユーザー名> [-admin_pwd <パスワード>] [-repos_pwd <パスワード>] -emkey_file <emkeyファイル>

emkeyを指定されたファイルから資格証明ストアにコピーします。

emctl config emkey -copy_to_repos_from_file (-repos_host <ホスト> -repos_port <ポート> -repos_sid <SID> | -repos_conndesc <接続記述子>) -repos_user <ユーザー名> [-repos_pwd <パスワード>] [-admin_pwd <パスワード>] -emkey_file <emkeyファイル>

emkeyを指定されたファイルから管理リポジトリにコピーします。

27.10.4 認証の構成

この項では、認証を構成するためのEMCTLコマンドについて説明します。

この項で説明するコマンドは次のとおりです。

- OSSO認証の構成

- OAM認証の構成

- LDAP (OIDおよびAD)認証の構成

- リポジトリ認証(デフォルトの認証)の構成

これらのすべてのコマンドのパラメータについて次に説明します。

- -enable_auto_provisioning: EMでの自動プロビジョニングを有効にします(この場合、外部LDAPユーザーをEMで手動でプロビジョニングする必要はありません)。

- -auto_provisioning_minimum_role <min_role>: LDAPでmin_roleが付与されているEMの外部ユーザーのみを自動プロビジョニングします。

- -minimum_privilege <min_priv>: min_privが付与されていないユーザーがEMにアクセスできないようにします。

- -use_ssl: LDAPサーバーに接続するためのSSLを示します。

- -cert_file <cert>: SSLによるLDAPサーバーへの接続時に信頼を確立するためのLDAPサーバー証明書を示します。このオプションは、LDAPサーバーが一般的でない(または信頼できない)認証局によって署名された証明書を持つ場合に指定します。

注意:
このパラメータは、1つの証明書のみ受け入れます。証明連鎖のインポートはサポートされていません。このコマンドを実行する前に、keytoolユーティリティを使用して証明書をインポートします。

- -trust_cacerts: LDAPサーバーへの接続時にLDAPサーバーの証明書への信頼を確立します。通常、このパラメータは、証明書が既知の認証局によって署名されている場合に使用します。

- -keystore_pwd <passwd>: デフォルトのDemoTrust.jksキーストア(デフォルトのパスワードが変更された場合)、または検証の一部としてLDAPサーバーの証明書がインポートされるカスタムkeystoreのパスワードを示します。

- -use_anonymous_bind: LDAPサーバーに接続するために匿名バインドを使用します。

27.10.4.1 OSSO認証の構成

EMCTL OSSO認証コマンドは、Oracle Application Server Single Sign-Onを使用して任意のシングル・サインオン・ユーザーをEnterprise Manager管理者として登録するように、Enterprise Managerを構成します。OSSO認証を構成するためのEMCTLコマンドは次のとおりです。

emctl config auth sso -ossoconf <conf file loc> -dasurl <DAS URL> [-unsecure] [-sysman_pwd <pwd>] [-domain <domain>] -ldap_host <ldap host> -ldap_port <ldap port> -ldap_principal <ldap principal> [-ldap_credential <ldap credential>] -user_base_dn <user base DN> -group_base_dn <group base DN> [-logout_url <sso logout url>] [-enable_auto_provisioning] [-auto_provisioning_minimum_role <min_role>] [-minimum_privilege <min_priv>] [-use_ssl] [-cert_file <cert>] [-trust_cacerts] [-use_anonymous_bind] [-keystore_pwd <passwd>]

たとえば、emctl config auth sso -ossoconf $T_WORK/osso.conf -dasurl "http://xxx.oracle.com:11" -sysman_pwd sysman -ldap_host xxx.oracle.com -ldap_port 111 -ldap_principal cn=orcladmin -ldap_credential ackdele1 -user_base_dn "cn=Users,dc=us,dc=oracle,dc=com" -group_base_dn "cn=Groups,dc=us,dc=oracle,dc=com" -logout_url "http://xxx.oracle.com:11/pls/orasso/orasso.wwsso_app_admin.ls_logout?p_done_url=https//xyy.oracle.com:216/emです。

27.10.4.2 OAM認証の構成

Oracle Access Manager認証は、Oracle Fusion Middlewareのシングル・サインオン・ソリューションです。この認証スキームは、すべてのエンタープライズ・アプリケーションにわたる認証用の中心的ツールとしてOracle Access Managerで標準化されたデータ・センターに使用されます。OAM認証を構成するためのEMCTLコマンドは次のとおりです。

emctl config auth oam [-sysman_pwd <pwd>] -oid_host <host> -oid_port <port> -oid_principal <principal> [-oid_credential <credential>] [-use_anonymous_bind] -user_base_dn <dn> -group_base_dn <dn> -oam_host <host< -oam_port <port> [-logout_url <url>] [-is_oam10g] [-user_dn <dn>] [-group_dn <dn>] [-enable_auto_provisioning] [-auto_provisioning_minimum_role <min_role>] [-minimum_privilege <min_priv>] [-use_ssl] [-cert_file <cert>] [-trust_cacerts] [-keystore_pwd <passwd>]

たとえば、emctl config auth oam -oid_host "xxx.oracle.com" -oid_port "111" -oid_principal "cn=orcladmin" -user_base_dn "cn=users,dc=us,dc=oracle,dc=com" -group_base_dn "cn=groups,dc=us,dc=oracle,dc=com" -oam_host "xxx.oracle.com" -oam_port "555" -oid_credential "eldleco1" -sysman_pwd "sysman" -logout_url http://xxx.oracle.com:23716/oam/server/logout?end_url=https://yyy.oracle.com:5416/em -enable_auto_provisioning -auto_provisioning_minimum_role ”EM_DBA”です。

27.10.4.3 LDAP (OIDおよびAD)認証の構成

OID認証を構成するためのEMCTLコマンドは次のとおりです。ADの場合、次のコマンド構文emctl config auth oidをemctl config auth adと置き換えます。その他のすべてのパラメータは同じままです。

OID認証コマンドは、OIDに対するユーザーの認証を行うために、すべてのアプリケーションのアイデンティティ・ストアとしてOracle Internet Directoryを構成します。

同様に、AD認証コマンドは、ADに対するユーザーの認証を行うために、すべてのアプリケーションのアイデンティティ・ストアとしてMicrosoft Active Directoryを構成します。

emctl config auth oid -ldap_host <ldap host> -ldap_port <ldap port> -ldap_principal <ldap principal> [-ldap_credential <ldap credential>] [-sysman_pwd <pwd>] -user_base_dn <user base DN> -group_base_dn <group base DN> [-user_dn <dn>] [-group_dn <dn>] [-enable_auto_provisioning] [-auto_provisioning_minimum_role <min_role>] [-minimum_privilege <min_priv>] [-use_ssl] [-cert_file <cert>] [-trust_cacerts] [-use_anonymous_bind] [-keystore_pwd <passwd>]

たとえば、emctl config auth oid -ldap_host "xxx.oracle.com" -ldap_port "111" -ldap_principal "cn=orcladmin" -user_base_dn "cn=users,dc=us,dc=oracle,dc=com" -group_base_dn "cn=groups,dc=us,dc=oracle,dc=com" -ldap_credential "elecmee1" -sysman_pwd "sysman" –use_ssl –cert_file ”/scratch/oidcert.txt”です。

27.10.4.4 リポジトリ認証(デフォルトの認証)の構成

リポジトリ認証コマンドは、認証を行うために管理リポジトリに対するユーザー資格証明を検証します。リポジトリ認証を構成するためのEMCTLコマンドは次のとおりです。

emctl config auth repos [-sysman_pwd <pwd>]

27.11 EMCTLのHAConfigコマンド

表27-7に、EMCTLのHA構成コマンドを示します。

表27-7 EMCTLのHA構成コマンド

EMCTLコマンド

説明

emctl exportconfig oms [-sysman_pwd <sysman password>]

指定したディレクトリにOMS構成のスナップショットをエクスポートします。構成の詳細は安全な場所に保存し、構成が変更されるたびに保存することをお薦めします。これらの詳細は、システムのリカバリ時に必要になります。

パラメータについて次に説明します。

- -oms_only: 管理サーバー・ホストでのOMSのみのバックアップを指定します。

- -keep_host: SLBが定義されていない場合に、ホスト名もバックアップに含めることを指定します。このオプションは、このホスト名に応答するマシンでリカバリが実行される場合にのみ使用します。

emctl importconfig oms -file <backup file> [-no_resecure] [-sysman_pwd <sysman password>] [-reg_pwd <registration password>]

指定したバックアップ・ファイルからOMS構成をインポートします。このコマンドは、システムのリカバリ時に使用されます。パラメータについて次に説明します。

- -file <backup file>: インポート元となるバックアップ・ファイルを示します。

- -no_resecure: インポートが完了した後、システムがOMSを再度保護しないことを指定します。デフォルトでは、インポートの完了後、OMSは再度保護されます。

emctl config emrep [-sysman_pwd <sysman password>]

OMSおよびリポジトリ・ターゲットを構成します。このコマンドを使用して、ターゲットの監視エージェントや、このターゲットの監視に使用される接続文字列を変更します。パラメータについて次に説明します。

- -agent <new agent>: emrepターゲットの新しい宛先エージェントを指定します。

- -conn_desc [<jdbc connect descriptor>]: 指定された値で接続記述子を更新します。値を指定しないと、emoms.propertiesに格納された値から指定されます。

- -ignore_timeskew: エージェントでの時間誤差を無視します。

emctl config repos [-sysman_pwd <sysman password>]

リポジトリ・データベース・ターゲットを構成します。このコマンドを使用して、ターゲットの監視エージェントや監視プロパティ(ホスト名、Oracleホームおよびこのターゲットの監視に使用される接続文字列)を変更します。パラメータについて次に説明します。

- -agent <new agent>: リポジトリ・ターゲットの新しい宛先エージェントを指定します。

- -host <new host>]: リポジトリ・ターゲットの新しいホスト名を指定します。

- -oh <new oracle home>: リポジトリ・ターゲットの新しいOracleホームを指定します。

- -conn_desc [<jdbc connect descriptor>]: 指定された値で接続記述子を更新します。値を指定しないと、emoms.propertiesに格納された値から指定されます。

- -ignore_timeskew: エージェントでの時間誤差を無視します。

emctl enroll oms [-as_host <host>] -as_port <port> - as_pws <admin password> -nm_pwd <nodemanager password>

指定された管理サーバー・ホストにOMSを登録します。このコマンドは、複数OMS環境でOMSをリカバリするプロセスで使用します。パラメータについて次に説明します。

- -as_port <port>: 管理サーバーのセキュア・ポートを指定します。

- -as_pwd <admin password>: 管理サーバーのパスワードを指定します。

- -nm_pwd <nodemanager password>: ノード・マネージャのパスワードを指定します。

27.12 EMCTLのResyncコマンド

表27-8に、EMCTLのresyncコマンドを示します。

表27-8 EMCTLのResyncコマンド

EMCTLコマンド

説明

emctl resync repos (-full|-agentlist "agent names") [-name "resync name"] [-sysman_pwd "sysman password"]

リポジトリの再同期化操作を発行します。–fullオプションを指定すると、リポジトリへの最新の状態のアップロードがすべてのエージェントに指示されます。

-agentパラメータは、再同期化を行うエージェントのリストを示します。

注意: このコマンドを使用するには、まずOMSesを終了してからresync reposコマンドを発行します。次にOMSesを起動して、再同期化ジョブを起動します。

emctl abortresync repos (-full|-agentlist "agent names") -name "resync name" [-sysman_pwd "sysman password"]

現在実行されているリポジトリの再同期化操作を中断します。–fullオプションはリポジトリ全体の再同期化を停止し、–agentlistオプションはエージェントのリストの再同期化を停止します。

emctl statusresync repos -name "resync name"

指定したリポジトリの再同期化操作のステータスをリストします。

27.13 EMCTLのコネクタ・コマンド

Enterprise Managerでカスタム・テンプレートを追加および登録するEMCTLコマンドは、次のとおりです。

emctl register_template connector [-t <template.xml>] [-repos_pwd <repos password>] [-cname <connectorName>] [-iname <internalName>] [-tname <templateName>] [-ttype <templateType>] [-d <description>]

パラメータについて次に説明します。

- -t: テンプレートのフルパスを示します。

- -repos_pwd: Enterprise Managerのroot (SYSMAN)のパスワードを示します。

- -cname: コネクタ名を示します。

- -iname: テンプレートの内部名を示します。

- -tname: テンプレートの表示名を示します。

- -ttype: テンプレート・タイプを示します。次のタイプがあります。

- <templateType> 1: 着信変換

- <templateType> 2: 送信変換

- <templateType> 3: XMLベースの送信変換

- -d: 説明を示します。

27.14 EMCTLのパッチ・リポジトリ・コマンド

表27-9に、EMCTLのパッチ・リポジトリ・コマンドを示します。

表27-9 EMCTLのパッチ・リポジトリ・コマンド

EMCTLコマンド

説明

emctl applypatch repos [-patchHome <patch home directory> -pluginHome <plugin home directory>]

パッチに含まれる.sqlファイルをリポジトリにロードします。このコマンドはパッチ・ディレクトリから実行する必要があり、パッチが解凍される場所へのパスを指定する必要があります。

emctl rollbackpatch repos [-patchHome <patch home directory> -pluginHome <plugin home directory>]

リポジトリから指定されたパッチ・ディレクトリの場所に.sqlファイルを再コールします。

27.15 Windows NTのEMCTLコマンド

emctl create serviceコマンドは、WindowsのOMSに対するサービスを作成します。このコマンドを使用して、コールド・フェイルオーバー・クラスタ設定内のフェイルオーバー・ホスト上にあるOMS用のWindowsサービスを管理します。このコマンドは、Windows NTにのみ適用されます。このコマンドの構文は次のとおりです。

emctl create service [-oms_svc_name <oms_service_name> -user <username>] [-passwd <password>]

パラメータについて次に説明します。

- -oms_svc_name <servicename>: 作成されるOMSサービスの名前を示します。名前を指定しないと、システムはEMプロパティ・ファイルのサービス名を使用します。

- -user <username>: サービスを登録するOSユーザー名を示します。ユーザー名を指定しないと、システムによってLocalSystemとして登録されます。

- -passwd <password>: 指定されたOSユーザーのOSパスワード。

emctl delete serviceコマンドは、WindowsのOMSに対するサービスを削除します。このコマンドは、Windows NTにのみ適用されます。コマンド構文は次のとおりで、-oms_svc_name <servicename>は、削除されるOMSサービスの名前を示します。

emctl delete service [-oms_svc_name <oms_service_name>]

27.16 EMCTLのPartoolコマンド

emctl partoolユーティリティは、次のことに役立ちます。

- デプロイメント・プロシージャと、その関連付けられたコンポーネントおよびディレクティブをparファイルとしてエクスポートする

- parファイルをCloud Controlの同一インスタンスまたは別のインスタンスにインポートする

次のようなemctl partoolコマンドもあります。

- emctl partool <deploy|view> -parFile <file> -force(optional)

- emctl partool <deploy|view> -parFile <file> -force(optional) -ssPasswd <password>

- emctl partool <deploy|view> -parDir <dir> -force(optional)

- emctl partool export -guid <procedure guid> -file <file> -displayName <name> -description <desc> -metadataOnly(optional)

- emctl partool check

- emctl partool help

表27-10に、EMCTLのpartoolコマンド・オプションを示します。

表27-10 EMCTLのPartoolコマンド・オプション

EMCTLコマンド・オプション

説明

<deploy|view|export>

parファイルをデプロイ、表示またはエクスポートします。

repPasswd <repPasswd>

リポジトリのパスワードを指定します。

force

swlibエンティティの再作成または再アップロードを強制的に行います。すでに存在する場合は、新しいバージョンが作成されます。

check

ソフトウェア・ライブラリが構成されているかどうかをチェックします。

file <file>

parファイルを示します。

verbose

verboseモードを示します。

help

ヘルプ・メッセージを表示します。

displayName <displayName>

parファイル名を示します。

parDir <dir>

parファイルが配置されるディレクトリを示します。

metadataOnly

メタデータのみをエクスポートするためのフィルタ。

guid <guid>

エクスポートするプロシージャguidを示します。複数のプロシージャをエクスポートするときは、guidsをカンマ(,)で区切って指定します。

parFile <file>

parファイルのパスを示します。

description <description>

parファイルの説明を示します。

ssPasswd <secretStorePassword>

このパラメータはオプションです。このパラメータは、指定されたパスワードでOracleウォレットを作成し、エクスポートされたソフトウェア・ライブラリ・エンティティにシークレット・プロパティの値を格納します。ユーザーは、新しいリポジトリにparファイルをインポートする間、同じパスワードを使用する必要があります。

注意:
emctl partoolコマンドの詳細は、『Oracle Enterprise Managerライフサイクル管理ガイド』のemctl partoolユーティリティの使用に関する説明を参照してください。

27.17 EMCTLのプラグイン・コマンド

EMCTLのプラグイン・コマンドは、失敗した以前のプラグイン・アップグレード・セッションを再開する場合に使用します。スキーマ・マネージャ・セッションで以前に失敗が発生した場合は、失敗したPL/SQLブロックから実行が再開されます。コマンド構文は次のとおりです。

emctl resume_plugin_upgrade

注意:
プラグイン・デプロイメントのステータスを確認するには、コマンドemctl status oms -details [-sysman_pwd <pwd>]を実行します。

27.18 OPSSポリシー・ストアとの同期のためのEMCTLコマンド

EMリポジトリとOPSSポリシー・ストア間のロールおよびユーザーを同期するためのEMCTLコマンドは次のとおりです。

emctl sync_opss_policy_store [-force]

注意:
-forceパラメータを指定すると、EMにないOPSSアプリケーション・ロールおよびロール・メンバーシップは削除されます。

27.19 Oracle Management Service起動エラーのトラブルシューティング

Oracle Management Service (OMS)の起動が失敗したときにチェックすべきログ・ファイルについて以下に述べます。

Oracle Management Serviceの起動失敗

表27-11に示す場所にあるログをチェックします。表内のINSTANCE_HOMEはOMSインスタンスのホームで、nはOMSサーバーのインデックスです。

表27-11 OMSのログ・ファイルの場所

OMSのログ・ファイル

ログ・ファイルの場所

EMCTLのログ・ファイル

$INSTANCE_HOME/sysman/log/emctl.log

管理対象サーバーのログ・ファイル

$INSTANCE_HOME/user_projects/domains/<DOMAIN_NAME>/servers/EMGC_OMS<n>/logs/EMGC_OMS<n>.log

$INSTANCE_HOME/user_projects/domains/<DOMAIN_NAME>/servers/EMGC_OMS<n>/logs/EMGC_OMS<n>.out

OMSのログ・ファイル

$INSTANCE_HOME/sysman/log/emoms_pbs.log

$INSTANCE_HOME/sysman/log/emoms_pbs.trc

$INSTANCE_HOME/sysman/log/emoms.trc

$INSTANCE_HOME/sysman/log/emoms.log

ノード・マネージャのログ・ファイル

$INSTANCE_HOME/NodeManager/emnodemanager/nodemanager.log

WebTierサービスの起動失敗

WebTierの起動に失敗する場合は、<WebTier Instance Home>/diagnosticsフォルダにあるログをチェックします。

27.20 管理エージェント起動エラーのトラブルシューティング

エージェントの起動に失敗する場合は、emctl.logおよびemagent.nohupのログ・ファイルで詳細を確認します。ログ・ファイルは$AGENT_INSTANCE_HOME/sysman/logsディレクトリに保存されます。一般的な問題およびトラブルシューティングのヒントを次に示します。

- 管理エージェントを起動しましたが、準備完了になりません

- エージェントとOMS間のタイムゾーンの不一致による管理エージェント起動の失敗

- ポートの競合によるものと思われる管理エージェントの起動失敗

- 保護または保護解除の失敗による管理エージェントの起動失敗

27.20.1 起動した管理エージェントの準備未完了

管理エージェントは、次のようなプロセスを経て起動されます。

1. 起動中(管理エージェントは、起動のリクエストを受信し、初期化シーケンスを開始しようとしています)

2. 初期化中(管理エージェントは、そのコンポーネントのそれぞれについて初期化を繰り返しています)

3. 準備完了(すべてのコンポーネントの初期化が済み、管理エージェントはリクエストの受付が可能です)

管理エージェントの起動コマンド(emctl start agent)は、デフォルトで120秒でタイムアウトします。タイムアウトの最後に、コール元に制御を戻し、制御を戻す直前の管理エージェントの状態を表示します。管理エージェントの監視するターゲット数によっては、前述の手順2に長い時間がかかり、コマンドの終了時、エージェントの状態は「初期化中」で、「エージェントは実行中だが、準備が完了していない」というメッセージが通知されることがあります。

環境変数「EMAGENT_TIME_FOR_START_STOP」の設定により、タイムアウトを延ばすことができます。この値は、コール元に制御を戻すまでの待機秒数を示します。

27.20.2 エージェントとOMS間のタイムゾーンの不一致による管理エージェント起動の失敗

管理エージェントは、emd.propertiesファイルに設定されているタイムゾーンを使用します。管理エージェントのインストール・プロセスで、エージェントおよびホスト・ターゲットはそのタイムゾーンとともにOMSに登録されます。インストール後のいずれかの時点で管理エージェントのタイムゾーンが変更されている場合、OMSはこの不一致を検出するとすぐに、管理エージェントに対し、停止するようにシグナルを送ります。

管理エージェントのタイムゾーンをリセットするには、次のコマンドを実行します。

emctl resetTZ agent

エージェントのタイム・ゾーンの設定の詳細は表27-3のemctl resetTZ agentコマンドの説明を参照してください。

27.20.3 使用可能ポートの競合による管理エージェントの起動失敗

管理エージェントが起動できず、EMCTLからポートが競合している可能性があると通知される場合は、管理エージェントのポート(emd.properties:EMD_URLに基づくもの)をチェックし、すでにそのポートにバインドされてそのマシンで実行中の別のアプリケーション、たとえば別のエージェントが存在しないかを確認します。

この問題を解決するには、現在、管理エージェント用のポートにバインドされているアプリケーションを停止します。

27.20.4 保護または保護解除の失敗による管理エージェントの起動失敗

OMSに対してエージェントを保護するパスワードが正しくない場合、またはOMSがロックされているか停止している場合、管理エージェントの保護または非保護は失敗します。失敗の理由は、<agent state directory>/sysman/log/secure.logファイルで参照できます。

27.21 emctl.logファイルを使用したトラブルシューティング

emctl.logファイルは、実行したすべてのEMCTLコマンドの結果が取得されるファイルです。管理エージェントでは、このログ・ファイルは管理エージェントの$AGENT_INSTANCE_HOME/sysman/logディレクトリにあり、OMSでは、このログ・ファイルは$OMS_INSTANCE_HOME/em/EMGC_OMS<n>/sysman/log/ディレクトリにあります。ファイルは、EMCTLコマンドを実行するたびに更新されます。なんらかの理由でEMCTLコマンドが失敗した場合は、このログ・ファイルにアクセスして問題を診断してください。

たとえば、管理エージェントのOracleホーム・ディレクトリから次のコマンドを実行して、そのステータスを確認します。

UNIXの場合:

<agent_instance_home>/bin/emctl status agent

Windowsの場合:

<agent_instance_home>\bin\emctl status agent

コマンドを実行した後、ログ・ディレクトリに移動して、emctl.logファイルで次の情報を確認します。

1114306 :: Wed Jun 10 02:29:36 2011::AgentLifeCycle.pm: Processing status agent
1114306 :: Wed Jun 10 02:29:36 2011::AgentStatus.pm:Processing status agent
1114306 :: Wed Jun 10 02:29:37 2011::AgentStatus.pm:emdctl status returned 3

ここで、最初の列1114306は、ステータス確認のために使用されたPIDです。2番目の列には、コマンドを実行した日付と時刻が示されます。3番目の列には、コマンドに対して実行されたPerlスクリプトが示されます。最後の列にはコマンドの結果が示され、コマンドによる進行状況とコマンドによって戻された終了コードが示されます。この例では、終了コードは3です。これは管理エージェントが起動され、実行中であることを表しています。

同様に、OMSの場合、管理サービスのOracleホーム・ディレクトリから次のコマンドを実行して、ステータスを確認できます。

UNIXの場合:

<OMS_HOME>/bin/emctl status oms

Windowsの場合:

<OMS_HOME>\bin\emctl status oms

例27-1 OMSのサンプル・ログの内容

2013-06-23 22:50:25,686 [main] INFO  wls.OMSController main.219 - Executing emctl command : status
2013-06-23 22:50:26,281 [main] INFO  commands.BaseCommand printMessage.404 - statusOMS finished with result: 0
2013-06-23 22:50:35,885 [main] INFO  wls.OMSController main.219 - Executing emctl command : status
2013-06-23 22:50:36,464 [main] INFO  commands.BaseCommand printMessage.404 - statusOMS finished with result: 0

別の例として、管理エージェントのOracleホーム・ディレクトリから次のコマンドを実行して、データをアップロードします。

UNIXの場合:

<Agent_Instance_Home>/bin/emctl upload agent

Windowsの場合:

<Agent_Instance_Home>\bin\emctl upload agent

コマンドを実行した後、ログ・ディレクトリに移動して、emctl.logファイルで次の情報を確認します。

1286220 :: Tue Jun  9 07:13:09 2011::AgentStatus.pm:Processing upload
1286220 :: Tue Jun  9 07:13:10 2011::AgentStatus.pm:emdctl status agent returned 3
1286220 :: Tue Jun  9 07:13:41 2011::AgentStatus.pm: emdctl upload returned with exit code 6

ここで示されるエントリは最初の例と似ていますが、戻された終了コードは6です。つまり、なんらかの理由により、アップロード操作が失敗したことを表しています。

実行したemctlコマンドに応じて、終了コードが戻されます。一般に、終了コード「ゼロ」は成功を示し、ゼロ以外の終了コードは失敗を示します。失敗の原因の詳細は、エラー・メッセージを参照してください。

28 Enterprise Managerのログ・ファイルの検索および構成

Oracle Management Agent(管理エージェント)またはOracle Management Service(OMS)をインストールする場合、Enterprise Managerは特定の情報、警告、エラー情報を一連のログ・ファイルに保存するようにシステムを自動的に構成します。

ログ・ファイルは、Enterprise Managerのインストールで発生する可能性のある問題の解決に役立ちます。また、Enterprise Managerで実行されるアクションや、警告またはエラーが発生したかどうかに関する詳細情報を提供します。

この章では、Enterprise Managerのログ・ファイルの内容を検索および確認するだけでなく、トラブルシューティングに役立つ詳細情報や、ディスク領域を節約するための大まかな情報を提供するログ・ファイルの構成手順についても説明します。

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

- ログ・ファイルの管理

- 保存済検索の管理

- 管理エージェントのログ・ファイルおよびトレース・ファイルの検索

- Oracle Management Serviceのログ・ファイルとトレース・ファイルの検索および構成

- ログ・ファイルのモニタリング

- ログ・アーカイブの場所の構成

28.1 ログ・ファイルの管理

多くのEnterprise Managerコンポーネントでは、エラー、通知、警告およびトレースを記録するメッセージが記載されたログ・ファイルが生成されます。

表28-1に、「ログ・メッセージ」表の列を示します。コンポーネントによっては、メッセージでオプションの列は移入されない場合があります。

表28-1 メッセージの列

列名

説明

時間

メッセージが生成された日付と時刻。ローカル・タイムゾーンが反映されます。

メッセージ・タイプ

メッセージのタイプ。使用可能な値は、Incident Error Warning、NotificationおよびTraceです。さらに、タイプが不明な場合は、値「不明」が使用されることもあります。

メッセージID

コンポーネント内でメッセージを一意に識別するID。コンポーネントを表す接頭辞、ダッシュおよび5桁の数字で構成されます。次に例を示します。

OHS-51009

メッセージ

エラー・メッセージのテキスト

ターゲット(拡張)

拡張ターゲットの名前。

ターゲット

ターゲット名。

ターゲット・タイプ

ターゲット・タイプ

実行コンテキスト

実行コンテキストID(ECID)。生成コンポーネントが関与する特定のリクエストの実行のグローバル一意識別子。ECIDは、別のコンポーネントで発生したエラー・メッセージの関連付けに使用できます。

関係ID。同じリクエストについて、1つのプロセスの1つのスレッドで実行された作業を、同じまたは別のプロセスの別のスレッドで実行された作業と識別します。

コンポーネント

メッセージの生成元のコンポーネント。

モジュール

メッセージの生成元のモジュールの識別子。

インシデントID

このメッセージが対応しているインシデントの識別子。

インスタンス

メッセージを生成したコンポーネントが属するOracleインスタンスの名前。

メッセージ・グループ

このメッセージが属しているグループの名前。

メッセージ・レベル

メッセージ・レベルは、メッセージ・タイプを限定する整数値で示されます。使用可能な値は1(最高重大度)から32(最低重大度)です。

ホストするクライアント

このメッセージが関係するクライアントまたはセキュリティ・グループの識別子。

組織

作成元のコンポーネントの組織ID。このIDは、すべてのOracleコンポーネントでoracleです。

ホスト

メッセージの発生元ホストの名前。

ホストIPアドレス

メッセージを生成したホストのネットワーク・アドレス。

ユーザー

メッセージを生成した実行コンテキストを所有するユーザーの名前。

プロセスID

メッセージを生成したプロセスまたは実行ユニットのID。

スレッドID

メッセージを生成したスレッドのID。

アップストリーム・コンポーネント

クライアント(アップストリーム)側で、アップストリーム元のコンポーネントが処理しているコンポーネント。

ダウンストリーム・コンポーネント

サーバー(ダウンストリーム)側で、ダウンストリーム元のコンポーネントが処理しているコンポーネント。

詳細な位置

メッセージに関連する追加情報にリンクするURL。

追加詳細

イベントの追加情報で、メッセージ・テキストより詳細な情報が含まれます。

アーカイブ

値は「はい」または「いいえ」です。チェックボックスが選択されている場合、メッセージはアーカイブの場所から収集されます。それ以外の場合は、メッセージはライブ・システムから収集されます。

ターゲット・ログ・ファイル

このターゲットのログ・ファイル・ページへのリンク。

ログ・ファイル

このメッセージを含むログ・ファイル。

ログ・ビューアを使用して、次のことを実行できます。

- ログ・ファイルおよびそのメッセージの表示

- ログ・ファイルの検索

- ログ・ファイルのダウンロード

28.1.1 ログ・ファイルおよびそのメッセージの表示

Enterprise Manager Cloud Controlを使用して、ログ・ファイル全体のメッセージを表示できます。

特に、ファームまたはドメインのコンテキスト内で移動する場合、表示および検索できるログは、そのファームまたはドメインに関連付けられたもののみに絞り込まれます。「エンタープライズ」メニューを経由して「ログ」に移動した場合、ログを表示および検索するターゲットを正確に選択できます。ドメインまたはファーム全体にわたる複数のWebLogic Serverターゲットなどを選択することもできます。

たとえば、ログ・ファイルとそのメッセージを表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「監視」、「ログ」の順に選択し、ポップアップ・ターゲット・セレクタからターゲットを選択します。
または

「ログ」メニューが個々のターゲット・ラベルおよび親ターゲット・レベルで使用可能です。たとえば、WebLogic Serverおよび他のJ2EEコンポーネントの場合、ログ・メニューには「ターゲット」メニューから「ログ」を選択してアクセスできます。ドメイン・ターゲットやファーム・ターゲットなどの親ターゲットについても同様です。

2. ファームまたはドメインのコンテキスト内で、「選択したターゲット」を開き、特定のコンポーネントまたはアプリケーションの行で、「ターゲット・ログ・ファイル」アイコンをクリックします。
「エンタープライズ」メニューのコンテキスト内である場合、ターゲットを「ターゲット」表に追加し、「ターゲット・ログ・ファイル」アイコンをクリックします。

「ログ・ファイル」ページが表示されます。このページで、ターゲットに関連するログ・ファイルのリストを表示できます。

3. ファイルを選択して、「ログ・ファイルの表示」をクリックします。
ログ・ファイルの表示ページが表示されます。このページで、メッセージのリストを表示し、このページからログ・ファイルをダウンロードできます。

4. メッセージの詳細を表示するには、メッセージを選択します。
デフォルトでは、メッセージは時間を基準として昇順でソートされます。メッセージは、列名をクリックすることにより、メッセージ・タイプなどの任意の列を基準としてソートできます。メッセージ・タイプは、重要度の高い順にソートされ、インシデント・エラー、エラー、警告、通知、トレースの順に使用されます。

5. 1つのドメインまたは1つのファームのコンテキスト内であり、ログを参照している場合、関連するメッセージは、その1つのドメインまたは1つのファームに制限されます。たとえば、時間またはECID別に関連するメッセージを表示するには、「関連メッセージの表示」をクリックし、「時間ごと」または「ECID(実行コンテキストID)ごと」を選択します。
「関連メッセージ」ページが表示されます。

ログ・メッセージの表示を試行したときに次のエラーが表示されることがあります。

ロギング構成が設定されていないか、ターゲットに無効な値が設定されています()。また、これらのターゲットが稼働しており、EMユーザーに該当するドメインでのCONFIGURE_TARGET権限があることを確認してください。

問題解決のためにどの方法を使用するかを確認するには、次の3つから選択します。

- ドメインの管理サーバーが停止しています。問題を解決するには、管理サーバーを起動してログ・メッセージの表示を再試行します。

- ログ・メッセージの表示を試行した管理対象サーバーが停止しています。問題を解決するには、管理対象サーバーを起動してログ・メッセージの表示を再試行します。

- Enterprise Manager Cloud Control管理者がログ・メッセージへのアクセスを試行しましたが、必要なターゲット権限がありません。ログ・メッセージを表示するには、管理者に、該当するWebLogicドメイン・ターゲットに対する「ターゲットの構成」権限が付与されている必要があります。Oracle Enterprise Managerサイト管理者またはスーパー管理者に、この権限がユーザー自身に付与されているかどうかを問い合せてください。

28.1.1.1 「ログ・メッセージの表示」メニュー項目および機能へのアクセス制限

Oracle Enterprise Manager Cloud Controlで、「ログ・メッセージの表示」メニュー項目、および該当する機能へのアクセス権を持つ管理者を制限できます。ターゲット権限「Fusion Middlewareのログを表示する権限」は管理者および/またはロールに付与できます。このターゲット権限は、すべてのOracle Fusion Applications関連およびOracle Fusion Middleware関連のターゲット・タイプに適用できます。このターゲット権限は、自動的に他のターゲット権限(「Fusion Middlewareのオペレータ」、「オペレータ」および「完全」)の一部として含まれます。したがって、管理者に次のいずれかの権限を付与し、その管理者はOracle Fusion Applications関連およびOracle Fusion Middleware関連のログ・ファイルに対するログ・メッセージを表示できるようになります。

- Fusion Middlewareのログを表示する権限ターゲット権限

- 「Fusion Middlewareのオペレータ」ターゲット権限

- 「オペレータ」ターゲット権限

- 「完全」ターゲット権限

Fusion Middlewareログ表示を可能にするターゲット権限を管理者に付与するには、次の手順に従います。

1. Oracle Enterprise Manager 12c Cloud Controlコンソールにスーパー管理者としてログインします。

2. 「設定」メニューで、「セキュリティ」、「管理者」の順に選択します。

3. 該当する管理者を選択し、「編集」をクリックします。

4. 「次へ」を2回クリックしてウィザードの「ターゲット権限」ページへ移動します。

5. ページをスクロール・ダウンし、ページの「ターゲット権限」セクションで「追加」をクリックします。

6. 「検索と追加: ターゲット」ポップアップ・ダイアログから、管理者がログを表示するためのアクセス権を必要とするターゲットを選択します。「選択」をクリックします。

7. ウィザードの「ターゲット権限」ページの「ターゲット権限」セクションから、「Fusion Middlewareのログを表示する権限」ターゲット権限を付与するターゲットを選択し、「選択したものに付与」を選択します。このターゲットには、デフォルトのターゲット権限として「表示」が自動的に付与されます。

8. 「Fusion Middlewareのログを表示する権限」ターゲット権限を選択し、「続行」をクリックします。「Fusion Middlewareのログを表示する権限」ターゲット権限は、他のターゲット権限の一部としても含まれることに注意してください(「オペレータ」ターゲット権限など)。このため、管理者の責任範囲に応じて、「オペレータ」ターゲット権限を管理者に付与することもできます。

9. ウィザードの「ターゲット権限」ページで、新規の権限の表示に注意してください。「確認」をクリックし、次に「終了」をクリックして操作を終了します。

28.1.1.2 追加のログ・ファイルの登録

WebLogic Serverのカスタム・ログ・ファイルを追加して、これらのログ・ファイルおよびメッセージがEnterprise Managerログ・ビューアに表示されるようにすることが必要になる場合があります。Enterprise Managerでは、ログ・ビューアのユーザー・インタフェースを使用したカスタム・ログ・ファイルの追加はサポートされていませんが、Enterprise Managerの外部で追加する方法があります。

通常は、ODL LogQueryMBeanによって、Weblogic ServerログおよびWeblogic Serverに関連付けられたlogging.xmlファイルに定義されているODLログ・ファイルが自動的に検出されます。ただし、追加のログ・ファイルをODL LogQueryMBeanに登録すると、Enterprise Managerログ・ビューアから表示またはダウンロードできるようになります。

新しいログ・ファイルを登録する場合は、2つの方法があります。

- ファイルのコンテンツの解析に使用できる、関連付けられているLogReaderにログ・ファイルを登録できます。この場合、ファイルのコンテンツは、メインの「ログ・メッセージ」ページから表示および検索できます。

- ログ・ファイルへのパスを登録できます(ただし、ファイルのコンテンツを解析するLogReaderは指定しないでください)。この場合、ファイルのコンテンツは、メインの「ログ・メッセージ」ページから表示および検索できませんが、「ターゲット・ログ・ファイル」ページからファイルのRAWコンテンツを表示したり、そのコンテンツをダウンロードできます。

1つ以上の追加のログ・ファイルを登録するために、次のディレクトリの下にファイルを作成できます。

DOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/diagnostics-registration

ファイルには.xml接尾辞と次のようなコンテンツが必要です。

<?xml version='1.0' encoding='UTF-8'?>
<logs xmlns='http://www.oracle.com/iAS/EMComponent/ojdl'>
<log path="/home/oracle/mylogs/my-odl-diagnostic.log">
<logreader class="oracle.core.ojdl.reader.ODLLogReaderFactory">
</logreader>
</log>
</logs>

この場合、ファイルはODLファイルで、LogReaderに登録されます。ODL LogReader以外に、他の形式の読取りに使用できるいくつかの既存のログ・リーダーがあります。

次に示すように、ログ・リーダーがなくてもログを登録できます。

<?xml version='1.0' encoding='UTF-8'?>
<logs xmlns='http://www.oracle.com/iAS/EMComponent/ojdl'>
<log path="/home/oracle/mylogs/my-other-diagnostic.log"/>
</logs>

ログ・パスで変数またはワイルドカードを使用できます。ワイルドカードは「%*%」で示し、変数は「%NAME%」の形式です。パスで同じ変数を複数回使用する場合は、まったく同じ値にする必要があります。変数を1回のみ使用する場合は、ワイルドカードのように動作します。

この方法で登録されたすべてのログ・ファイルは、Enterprise Managerでサーバー・ターゲットに関連付けられます。

28.1.2 ログ・ファイルの検索

ログ・メッセージ・ページを使用して、診断メッセージを検索できます。デフォルトでは、このページには、最後の10分間に記録された問題のサマリーが表示されます。

検索基準は、適合度の高いメッセージが特定されるように変更できます。検索結果を別のモードで表示すると、大量のデータを簡単にナビゲーションできます。

次の各項では、ログ・ファイルの検索方法を説明します。

- ログ・ファイルの検索: 基本検索

- ログ・ファイルの検索: 拡張検索

28.1.2.1 ログ・ファイルの検索: 基本検索

特定のドメイン、Oracle WebLogic Server、コンポーネントまたはアプリケーションのすべてのエンティティのすべてのメッセージを検索できます。

たとえば、特定のドメインのメッセージを検索する手順は次のとおりです。

1. 「エンタープライズ」メニューから、「監視」、「ログ」の順に選択し、ポップアップ・ターゲット・セレクタからターゲットを選択します。
または

「ターゲット」メニューから、「ミドルウェア」を選択し、ファームをクリックします。「ファーム」メニューから、「ログ」を選択し、「ログ・メッセージの表示」を選択します。

ログ・メッセージ・ページに、「検索」セクションと、最後の1時間のメッセージのサマリーが表示されます。

2. 「検索モード」セクションで、ライブ・ログのみ、アーカイブ・ログのみ、または両方の検索を選択できます。

3. 「日付範囲」セクションでは、次のいずれかを選択できます。

- 最新: このオプションを選択した場合は、3時間などの時間を選択します。デフォルトは10分です。

- 時間間隔: このオプションを選択した場合は、「開始日」のカレンダ・アイコンを選択します。日付および時刻を選択します。次に、「終了日」のカレンダ・アイコンを選択します。日付および時刻を選択します。

4. 「メッセージ・タイプ」セクションで、1つ以上のメッセージ・タイプを選択します。

5. 「メッセージ」テキスト・フィールドにテキストを指定するなど、さらに検索基準を指定できるため、明示的な単語またはパターンで、ログ・ファイルを検索できます。「ログ・ファイルの検索: 拡張検索」に示すとおり、さらに検索基準を指定できます。

6. 「検索」をクリックします。

7. 適合性の高いメッセージを特定しやすくするため、表内の「表示」で次のモードのいずれかを選択します。

- メッセージ - 「次を含む」などの演算子を選択してから、照合する値を入力します。
特定のメッセージの詳細を表示するには、該当するメッセージをクリックします。メッセージの表の下に詳細が表示されます。

関連するメッセージを表示するには、メッセージを選択して「関連メッセージの表示」をクリックし、「時間ごと」または「ECID(実行コンテキストID)ごと」を選択します。

- アプリケーションID - 特定のアプリケーションに関連するメッセージをグループ化します。

- ECIDおよび関係ID - 実行コンテキスト(ECID)および関係ID (RID)別にメッセージをグループ化します。これにより、ログ・ファイルのエントリを使用して1つのアプリケーションまたはアプリケーション・サーバー・コンポーネントのメッセージを関係付けることができます。メッセージ相関情報を使用して関連するメッセージを検索することで、複数のメッセージを調べて、最初の問題が発生したコンポーネントを特定できます。

- ホスト - 特定のホストに関連付けられているメッセージをグループ化します。

- ホストIPアドレス - 特定のホストIPアドレスに関連付けられているメッセージをグループ化します。

- インシデントID

- メッセージ・タイプ - メッセージ・タイプに基づいて、各ターゲットのメッセージをグループ化します。ターゲットごとに、ERROR、INCIDENT ERROR、WARNING、NOTIFICATION、TRACEおよびUNKNOWNなどのメッセージ・タイプ別に使用可能なメッセージの合計数が表示されます。

- メッセージID - メッセージID、メッセージ・タイプ、ターゲット、メッセージ・レベル、コンポーネント、モジュール、組織の組合せに基づいて、メッセージをグループ化します。

- モジュール - メッセージが発生したクラス/モジュールをグループ化します。

- ターゲット

- スレッドID - スレッドID別にメッセージをグループ化します。

- ユーザー - 特定ユーザーのすべてのメッセージをグループ化します。たとえば、ユーザーJonesのすべてのメッセージを、ユーザーSmithのメッセージの前に表示します。

28.1.2.2 ログ・ファイルの検索: 拡張検索

検索基準は、「ログ・メッセージ」ページの次のコントロールを使用して絞り込むことができます。

- メッセージ: 「次を含む」などの演算子を選択し、比較する値を入力できます。

- フィールドの追加: クリックすると、ホストなどの追加の基準を指定して、検索範囲を特定のホストに絞り込むことができます。次に、「追加」をクリックします。
追加したフィールドのそれぞれに、「次を含む」などの演算子を選択し、比較する値を入力します。

- 選択したターゲット: これを開くと、検索に関与するターゲットが表示されます。ターゲットを追加するには、「追加」をクリックして、ダイアログ・ボックスに情報を入力します。ターゲットを削除するには、ターゲットを選択して「削除」をクリックします。

- アーカイブ・ログの検索: このチェック・ボックスからログ・ビューアへのアクセスを可能にします。これらは「アーカイブの場所の構成」ページで構成した、複数のターゲットに対するアーカイブ・ログ・ファイルの場所です。

注意:
「アーカイブ・ログの検索」チェック・ボックスは、スタンドアロンのOracle HTTP Serversには適用されません。

28.1.3 ログ・ファイルのダウンロード

ログ・メッセージをファイルにダウンロードできます。検索で一致したメッセージまたは特定のログ・ファイル内のメッセージをダウンロードできます。

検索で一致したメッセージをファイルにダウンロードするには:

1. 「エンタープライズ」メニューから、「監視、「ログ」の順に選択します。
または

「ターゲット」メニューから、「ミドルウェア」を選択し、ドメインを選択します。「ファーム」メニューから、「ログ」を選択し、「ログ・メッセージの表示」を選択します。

「ログ・メッセージ」ページが表示されます。

2. 「ログ・ファイルの検索: 基本検索」の説明に従って、特定のメッセージ・タイプを検索します。

3. 「メッセージをファイルにエクスポート」をクリックしてファイル・タイプを選択し、次のいずれかを選択します。

- Oracle診断ログ・テキスト(.txt)として

- Oracle診断ログXML (.xml)として

- カンマ区切りリスト(.csv)として

「オープン中」ダイアログ・ボックスが表示されます。

4. 次を使用してオープンまたはディスクに保存を選択します。「OK」をクリックします。

特定のタイプのメッセージ、または特定のメッセージIDのメッセージをファイルにエクスポートする手順は次のとおりです。

1. 「エンタープライズ」メニューから、「監視、「ログ」の順に選択します。
または

「ターゲット」メニューから、「ミドルウェア」を選択し、ドメインを選択します。「ファーム」メニューから、「ログ」を選択し、「ログ・メッセージの表示」を選択します。

「ログ・メッセージ」ページが表示されます。

2. 「ログ・ファイルの検索: 基本検索」の説明に従って、特定のメッセージ・タイプを検索します。

3. 「表示」で「メッセージ・タイプ別グループ」または「メッセージID別グループ」を選択します。

4. メッセージをファイルにダウンロードするには、「メッセージ・タイプ別グループ」を選択した場合、列のいずれか(「エラー」列など)で、メッセージ数をリスト表示するリンクを選択します。「メッセージID別グループ」を選択した場合、「発生」列のリンクのいずれかを選択します。
「メッセージ、タイプ別」ページまたはメッセージID別のメッセージが表示されます。

5. 「メッセージをファイルにエクスポート」の近くにある矢印をクリックし、ファイル・タイプを選択します。
次のいずれかを選択します。

- Oracle診断ログ・テキスト(.txt)として

- Oracle診断ログXML (.xml)として

- カンマ区切りリスト(.csv)として

「オープン中」ダイアログ・ボックスが表示されます。

6. 次を使用してオープンまたはディスクに保存を選択します。「OK」をクリックします。

特定のコンポーネントのログ・ファイルをダウンロードするには:

1. 「エンタープライズ」メニューから、「監視、「ログ」の順に選択します。
または

「ターゲット」メニューから、「ミドルウェア」を選択し、ドメインをクリックします。「ファーム」メニューから、「ログ」を選択し、「ログ・メッセージの表示」を選択します。

「ログ・メッセージ」ページが表示されます。

2. 「選択したターゲット」セクションがデフォルトでは非表示になっているため、これを開きます。「ターゲット・ログ・ファイル」をクリックします。
「ログ・ファイル」ページが表示されます。

場合によっては多くの「ターゲット・ログ・ファイル」アイコンのうちの1つを選択します。表示するターゲット・タイプ・ログ・ファイルに関連付けられるアイコンを選択します。

3. ログ・ファイルを選択して、「ダウンロード」をクリックします。

4. 「オープン中」ダイアログ・ボックスが表示されます。

5. 次を使用してオープンまたはディスクに保存を選択します。「OK」をクリックします。

28.2 保存済検索の管理

次の各項では、保存済検索の作成、取得および管理について説明します。

- 検索の保存

- 保存済検索の取得

- 保存済検索の管理

28.2.1 検索の保存

保存済検索によって、同じ検索を後でもう一度再定義する必要がないため、管理者の時間を節約できます。何度も検索を再定義することとは対照的に、保存済検索にアクセスする以外に少しクリックするだけであるため、保存済検索は、問題を迅速に診断する際に役立ちます。

注意: 保存済検索は管理者ごとに設定されます。そのため、管理者がコンソールからログアウトすると、検索は保存され、管理者が次回ログインする際に使用できます。つまり、ある管理者が定義した保存済検索には、別の管理者はアクセスできません。

「ログ・ファイルの検索」に示すように検索基準を指定したら、ページの右上にある「検索の保存」をクリックして保存します。検索の名前は、検索で使用したフィールドを連結して自動的に作成されます。例: ログ・メッセージ - 保存済検索: "error", 過去1時間, インシデント・エラー,エラー,不明

注意: 「保存済検索の管理」ポップアップを使用して、デフォルトの名前を変更できます。これにより、デフォルトの名前のままにして、後で変更できます。

28.2.2 保存済検索の取得

保存済検索を取得するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「監視」、「ログ」の順に選択し、ポップアップ・ターゲット・セレクタからターゲットを選択します。
または

「ターゲット」メニューから、「ミドルウェア」を選択し、ファームをクリックします。「ファーム」メニューから、「ログ」を選択し、「ログ・メッセージの表示」を選択します。

または

「お気に入り」メニューから、保存済検索にアクセスします。

「ログ・メッセージ」ページが表示されます。

2. 「ログ」ページで、ページの右上にある「保存済検索」をクリックします。

3. 検索を選択します。
検索結果は、「検索」リージョンを移入します。

28.2.3 保存済検索の管理

保存済検索を管理するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「監視」、「ログ」の順に選択し、ポップアップ・ターゲット・セレクタからターゲットを選択します。
または

「ターゲット」メニューから、「ミドルウェア」を選択し、ファームをクリックします。「ファーム」メニューから、「ログ」を選択し、「ログ・メッセージの表示」を選択します。ターゲット・コンテキストのみに関連する保存済検索を管理できます。

または

「お気に入り」メニューから保存済検索にアクセスし、「お気に入りの管理」を選択します。コンテキストに関係なく、作成したすべてのログ保存済の検索を管理できます。すべての保存済検索を参照できます。

「ログ・メッセージ」ページが表示されます。

2. 「ログ」ページで、ページの右上にある「保存済検索」をクリックします。

3. リストで、「保存済検索の管理」をクリックします。
「お気に入りの管理」ポップアップが表示されます。次の操作を実行できます。

- 検索の名前の変更
表から行を選択すると、画面の下部にある「名前」フィールドに、検索の名前が表示されます。検索の名前を編集し、「OK」をクリックすることも、「取消」をクリックすることもできます。

注意: 「OK」をクリックした場合、検索の名前のみが変更され、保存済の検索基準の名前は変更されません。検索基準が変更されると、「検索の保存」ボタンが有効になります。

- 検索基準の編集
保存済検索のリンクをクリックします。保存済検索のコンテキストに、「ログ・ビューア」画面が表示されます。変更を行い、「保存」をクリックします。

- 検索の削除
検索を選択し、「選択項目の削除」をクリックします。

28.3 管理エージェントのログ・ファイルおよびトレース・ファイルの検索

次の項では、Oracle Management Agentのログ・ファイルとトレース・ファイルについて説明します。

- 管理エージェントのログ・ファイルおよびトレース・ファイルについて

- 管理エージェントのログ・ファイルおよびトレース・ファイルの検索

28.3.1 管理エージェントのログ・ファイルおよびトレース・ファイルについて

Oracle Management Agentのログ・ファイルとトレース・ファイルは、サポート担当者が後から問題の解決に使用できる重要な情報を格納します。エージェントのメイン・ログは、$EMSTATE/sysman/logにあります。ログは、デフォルトでは、5MBずつの11のセグメントに分かれています。セグメントは、gcagent.logおよびgcagent.log.#と名前が付けられています(#は1から10までの数値です)。これらの設定は、次の項で説明するように、emd.properties内のプロパティによって制御されます。最後のセグメントは常にgcagent.logで、最も古いセグメントはgcagent.log.Xです(Xは最大の数値です)。

管理エージェントは次のログ・ファイルを使用します。

- Oracle Management Agentメタデータ・ログ・ファイル(gcagent.log)
このログ・ファイルには、追跡、デバッグ、情報、エラー、またはエージェントからの警告メッセージが含まれます。

- Oracle Management Agent fetchletトレース・ファイル(gcagent_sdk.trc)
このログ・ファイルには、fetchletおよびreceiveletについてのロギング情報が含まれます。

- Oracle Management Agentエラー・ログ・ファイル(gcagent_errors.log)
このエラー・ログ・ファイルには、エラーについての情報が含まれます。このファイル内のエラーは、gcagent.log内のエラーの複製です。

- Oracle Management Agentメタデータ・ログ・ファイル(gcagent_mdu.log)
このログは、エージェントに対するメタデータの更新を追跡します。

- Enterprise Manager Controlログ・ファイル(emctl.log)
Enterprise Manager Controlコマンドを実行すると、情報はemctl.logファイルに保存されます。emctl.logファイルの詳細は、「Enterprise Managerコンポーネントの起動および停止」の章を参照してください。

注意:
前述のすべてのエージェント・ログ($EMSTATE/sysman/logにあるもの)は一時的なものです。エージェント・ログは、セグメント化されており、全体サイズに制限があるため、削除や管理の必要はありません。

28.3.1.1 エージェント・ログ・ファイルの構造

ログには、次の形式の個別のログ・メッセージが含まれます。

YYYY-MM-DD HH:MM:SS,### [<tid>:<thread code or code:name>] <level> -<the message>

各項目の意味は次のとおりです。

- YYYY-MM-DD HH:MM:SS,###はタイムスタンプです(24時間形式で、###は小数ミリ秒です)。

- <tid>はスレッドIDです(小数)。

- <thread name or code>は、スレッドの完全名または省略形式の16進数コードです(次の例を参照)。

- <level>はロギング・レベルで、(重要性が大きくなる順に)DEBUG、INFO、WARN、ERROR、FATALのいずれかを指定できます。

- <the message>は、ログされるフリー・テキスト・メッセージです。メッセージには、新しい行および生成された複数の行を含めることができます。

次に例を示します。

2011-06-07 15:00:00,016 [1:3305B9:main] DEBUG - ADR_BASE='/ade/example_user/oracle/example/agentStateDir'
2011-06-07 15:00:01,883 [1:3305B9] INFO - Agent is starting up

28.3.2 管理エージェントのログ・ファイルおよびトレース・ファイルの検索

管理エージェントのログ・ファイルおよびトレース・ファイルは、エージェントのランタイム・ディレクトリに書き込まれます。ランタイム・ディレクトリは、次のコマンドを使用して検索できます。

$ emctl getemhome

ログ・ファイルとトレース・ファイルは<EMHOME>/sysman/logにあります。

28.3.3 Oracle Management Agentのログ・レベルの設定

各ログ・メッセージは、特定のログ・レベルを使用してログに記録されます。ログ・レベルは、DEBUG、INFO、WARN、ERROR、FATALという優先順序で並べられます。ログ設定によって、ログに含められる最小レベルが決定されます。たとえば、ログ・レベルがINFO(デフォルト)に設定されている場合、レベルINFO以上(INFO、WARN、ERRORおよびFATAL)のログ・メッセージのみがログに含められます。

ロギング構成構文はハンドラ(log4j用語でのアペンダ)とロガーの概念を使用します。ハンドラは1つの出力ファイルとそのファイルの管理方法(最大ファイル・サイズ、セグメント数など)を定義します。すべてのハンドラに使用されるデフォルトのログ接頭辞oracle.sysmanがあり、ログ接頭辞は指定しないことに注意してください。ロギング・プロパティはLogger.接頭辞をエージェント(log4j)ロギング構成に対し使用し、ODLLogger.接頭辞をODL(java.util.logger.*に基づく)ロギング構成に使用します。接頭辞の他は、どちらのシステムも同じ構文を共有します。構成の完全な構文(LoggerおよびODLLogger接頭辞を除く)は次のとおりです。

表28-2

プロパティ名

説明

必須

デフォルト値

directory=<directory>

ロギング・システム(log4jまたはODL)のロギング・ディレクトリを定義します。1つのシステムに対するディレクトリの指定は他のシステムに影響を与えません(Logger.ディレクトリの設定は、Logger.構成にのみ影響し、ODLLogger.には影響しません)。

いいえ

$EMSTATE/sysman/log

<handler>.filename=<filename>

ハンドラで使用するファイル名。ファイル名が相対的な場合、ロギング・ディレクトリに対して相対的です(前述のディレクトリ・プロパティを参照)。絶対ファイル名はそのまま使用されます。

はい

<handler>.level=<level>

ハンドラのデフォルトのロギング・レベル。使用されるレベルは次のとおりです。

DEBUG、INFO、WARN、ERROR、FATAL

はい

<handler>.totalSize=<size>

すべてのハンドラのファイル・セグメントの合計サイズ(MB)。

いいえ

無制限

<handler>.segment.count=<count>

ハンドラで使用するセグメント数。

いいえ

1

<handler>.logger=<logger names>

このハンドラで使用される、ロガー名のカンマ区切りのリスト。

いいえ

指定しないと、デフォルトのロガーが使用されます。

level.<logger name>=<level>

ロガーとその子孫すべてに特定のロギング・レベルを設定します。使用されるレベルは次のとおりです。

DEBUG、INFO、WARN、ERROR、FATAL

いいえ

additivity.<logger name>=<trueまたはfalse>

falseに設定すると、特定のロガー名に対して構成されているハンドラのみが使用されます。それ以外の場合、ロガーの親の名前に対して構成されているハンドラも使用されます。

いいえ

true

次に構文の例を示します。

# logging properties
Logger.log.filename=gcagent.log
Logger.log.level=INFO
Logger.log.totalSize=100
Logger.log.segment.count=20

ODLLogger.wsm.level=ERROR
ODLLogger.wsm.totalSize=5
ODLLogger.wsm.segment.count=5
ODLLogger.wsm.filename=gcagent_wsm.log

前述のログ構成は、デフォルトのロギング・レベルがINFOで、合計サイズが100MBのgcagent.logファイルを(デフォルトのロギング・ディレクトリに)作成し、最大20セグメントを使用し、デフォルトのロガー(oracle.sysman)により使用されるように構成されたハンドラ(ログ)を設定します。

28.3.3.1 デフォルトのロギング・レベルの変更

管理エージェントにDEBUGレベルのロギングを有効にするには、ログ・ハンドラのレベルをDEBUG(後述)に設定します。その後でエージェントをリロードします。

Logger.log.level=DEBUG

または、次のようにemctl setproperty agentコマンドを使用します。

$ emctl setproperty agent -name "Logger.log.level" -value DEBUG

または

$ emctl setproperty agent -name "Logger.log.level" -value "DEBUG"

28.3.3.2 gcagent.logの設定

gcagent.logはエージェントのメイン・ログで、エージェントのすべてのコア・コードからのログ・エントリが含まれます。次にgcagent.logの構成を示します。

Logger.log.filename=gcagent.log
Logger.log.level=DEBUG
Logger.log.totalSize=100
Logger.log.segment.count=20

28.3.3.3 gcagent_error.logの設定

gcagent_errors.logは、gcagent.logのサブセットで、ERRORおよびFATALレベルのログ・メッセージが含まれます。gcagent_errors.logのロギング構成はemd.propertiesで指定されます。gcagent_errors.logの設定は次のとおりです。

Logger.err.filename=gcagent_errors.log
Logger.err.level=ERROR
Logger.err.totalSize=100
Logger.err.segment.count=5

28.3.3.4 個々のクラスおよびパッケージのログ・レベルの設定

個々のクラスおよびパッケージのロギング・レベルも設定できます。次に、現在デフォルトで構成されている例を示します。

# Set the class loaders to level INFO
Logger.level.oracle.sysman.gcagent.metadata.impl.ChainedClassLoader=INFO
Logger.level.oracle.sysman.gcagent.metadata.impl.ReverseDelegationClassLoader=INFO
Logger.level.oracle.sysman.gcagent.metadata.impl.PluginLibraryClassLoader=INFO
Logger.level.oracle.sysman.gcagent.metadata.impl.PluginClassLoader=INFO

上の構成では、4つのクラスのデフォルトのロギング・レベルがINFOに変更されました。デフォルトのロギング・レベルがINFOの場合、差異はありませんが、デフォルトのログ・レベルがDEBUGに設定されている場合(コードのデバッグ時)、これら4つのクラスのDEBUGレベルでのロギングが阻止されます(一般に詳細すぎるため)。

逆の場合も同様です。たとえば、次の構成が追加されるとします(デフォルトでは設定されていません)。

Logger.level.oracle.sysman.gcagent.metadata.impl.collection=DEBUG

デフォルトのログ・レベルがINFOであっても、oracle.sysman.gcagent.metadata.impl.collectionパッケージ内のすべてのクラスが、DEBUGレベルでログに記録されます。

28.3.3.5 gcagent_mdu.logの設定

gcagent_mdu.logファイルでは、ターゲット・インスタンス、ターゲット・インスタンス・コレクションまたはブラックアウトを変更するクライアント・コマンドごとに一連のエントリが作成されます。次に、エントリを示します。

2011-08-18 22:56:40,467 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SAVE TARGET(S)
<Target IDENTIFIER="TARGET_GUID=6A3A159D0BB320C50B7926E0671A1A98" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="EM Management Beacon" NAME="EM Management Beacon" TYPE="oracle_beacon"/>
<Target IDENTIFIER="TARGET_GUID=51F9BBC6F5B833058F4278B51E496000" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="mytestBeacon" NAME="mytestBeacon" TYPE="oracle_beacon"><Property VALUE="***" NAME="proxyHost"/><Property VALUE="***" NAME="proxyPort"/><Property VALUE="***" NAME="dontProxyFor"/></Target>
<Target IDENTIFIER="TARGET_GUID=7C4336B536C9F241DBCAC4D1D082AD22" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="CSAcollector" NAME="CSAcollector" TYPE="oracle_csa_collector"><Property VALUE="***" NAME="recvFileDir"/></Target>
<Target IDENTIFIER="TARGET_GUID=207B57A3FE300C86F81FE7D409F5DD1C" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="Oemrep_Database" NAME="Oemrep_Database" TYPE="oracle_database"><Property VALUE="***" NAME="MachineName"/><Property VALUE="***" NAME="Port"/><Property VALUE="***" NAME="SID"/><Property VALUE="***" NAME="OracleHome"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="UserName"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="Role"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="password"/></Target>
<Target IDENTIFIER="TARGET_GUID=0C48C5AE0FAFB42ED91F897FF398FC84" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="Management Services and Repository" NAME="Management Services and Repository" TYPE="oracle_emrep"><Property VALUE="***" NAME="ConnectDescriptor"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="UserName"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="password"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service" ASSOCIATION_NAME="internal_contains"/><CompositeMembership><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target>
<Target IDENTIFIER="TARGET_GUID=DF64B4A7C0F2EEBA7894EA3AD4CAF61E" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="linuxserver07.myco.com:41034_Management_Service" NAME="linuxserver07.myco.com:41034_Management_Service" TYPE="oracle_oms"><Property VALUE="***" NAME="InstanceHome"/><Property VALUE="***" NAME="OracleHome"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_console" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_pbs" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service_PBS" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_console" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" ASSOCIATION_NAME="internal_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_pbs" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service_PBS" ASSOCIATION_NAME="internal_contains"/><CompositeMembership><MemberOf ASSOCIATION="" NAME="Management Services and Repository" TYPE="oracle_emrep"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"/></CompositeMembership></Target>
<Target IDENTIFIER="TARGET_GUID=4D290260F13596502EFD8F3E22752404" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"><Property VALUE="***" NAME="InstanceHome"/><Property VALUE="***" NAME="OracleHome"/><CompositeMembership><MemberOf ASSOCIATION="" NAME="Management Services and Repository" TYPE="oracle_emrep"/><MemberOf ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target>
<Target IDENTIFIER="TARGET_GUID=D0A23AE06A9E678221B075A216364541" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="linuxserver07.myco.com:41034_Management_Service_PBS" NAME="linuxserver07.myco.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"><Property VALUE="***" NAME="InstanceHome"/><Property VALUE="***" NAME="OracleHome"/><CompositeMembership><MemberOf ASSOCIATION="" NAME="Management Services and Repository" TYPE="oracle_emrep"/><MemberOf ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target>
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS

上の例の保存されたターゲットのバッチでは、元のリクエストが22:56:40に着信しており、保存されたターゲットのリストがSAVE TARGET(S)メッセージの後の行に表示されています。このケースでは、8個のターゲットがありました。ターゲットの保存結果は、次の8行に表示されており(同じスレッド)、このケースでは、すべてが22:57:10までに正常に保存されました。

パターンは、保存されたコレクション・アイテム(またはコレクション)およびブラックアウトと同じです。

gcagent_mduログのロギング構成はemd.propertiesで指定されますが、このログは変更できません。たとえば、これらのエントリはINFOレベルでログに記録され、スペースを保存してこれをWARNに変更する場合、これはemd.propertiesファイルのmduログ・エントリを編集することでのみ可能で、このログを有効に無効化できます。

gcagent_mduログの設定は次のとおりです。

Logger.mdu.filename=gcagent_mdu.log
Logger.mdu.level=INFO
Logger.mdu.totalSize=100
Logger.mdu.segment.count=5
Logger.mdu.logger=Mdu

注意:
ファイル名およびロガー設定はサポートから要求された場合にのみ変更します。

28.3.3.6 TRACEレベルの設定

次の_enableTraceプロパティがtrueに設定されている場合、DEBUGメッセージとして示されるTRACEロギング・レベルが有効になります。

Logger._enableTrace=true

トレース・レベルが機能するには、エージェント・ログのデフォルトのログ・レベルをDEBUGに設定する必要があります。

28.4 Oracle Management Serviceのログ・ファイルとトレース・ファイルの検索および構成

次の項では、OMSログ・ファイルの検索方法と構成方法について説明します。

- Oracle Management Serviceのログ・ファイルおよびトレース・ファイルについて

- Oracle Management Serviceのログ・ファイルおよびトレース・ファイルの検索

- Oracle Management Serviceのログ・ファイルおよびトレース・ファイルのサイズと数の制御

- Oracle Management Serviceのトレース・ファイルの内容の制御

- Oracle WebLogic ServerおよびOracle HTTP Serverのログ・ファイルの制御

28.4.1 Oracle Management Serviceのログ・ファイルおよびトレース・ファイルについて

OMSのログ・ファイルとトレース・ファイルには、Oracleサポートが問題の解決に使用できる重要な情報が格納されます。OMSでは次の6種類のログ・ファイルが使用されます。

- Oracle Management Serviceログ・ファイル(emoms.log)
管理サービスは、アクション(起動または停止)の実行時やエラーの生成時に、情報をログ・ファイルに保存します。これは、コンソール・アプリケーションのログ・ファイルです。

- Oracle Management Serviceトレース・ファイル(emoms.trc)
OMSトレース・ファイルは、特定の問題の発生時にOMSがどのアクションを実行していたかに関する詳細情報をサポート担当者に提供できる高度なトラブルシューティングの方法を提供します。これは、コンソール・アプリケーションのトレース・ファイルです。

- Oracle Management Serviceログ・ファイル(emoms_pbs.log)
管理サービスは、バックグラウンド・モジュール(ローダー、ジョブ・システム、イベント・システム、通知システムなど)のために、情報をこのログ・ファイルに保存します。このファイルには、ERRORまたはWARNレベルでロギングされたメッセージが含まれます。

- Oracle Management Serviceトレース・ファイル(emoms_pbs.trc)
このトレース・ファイルは、ローダー、ジョブ・システム、イベント・システム、通知システムなどのバックグラウンド・モジュールでDEBUGまたはINFOレベルのロギングが有効になっている場合に、これらのモジュールに追加のロギングを提供します。このファイルは、特定の問題が発生した際にこれらのモジュールで実行されていたアクションについて、サポート担当者により詳しい情報を提供できます。

- Enterprise Manager Controlログ・ファイル(emctl.log)
Enterprise Manager Controlコマンドを実行すると、情報はemctl.logファイルに保存されます。emctl.logファイルの詳細は、「Enterprise Managerコンポーネントの起動および停止」の章を参照してください。

- Enterprise Managerコントロール・メッセージ・ファイル(emctl.msg)
このファイルは、OMSがクリティカル・エラーのために再起動されるときに、OMSのHealthMonitorスレッドにより作成されます。このファイルはOMSの再起動の問題のトラブルシューティングに使用されます。OMSが再起動した正確な時間や、クラッシュの原因となったモジュールなどの情報を提供します。

28.4.2 Oracle Management Serviceのログ・ファイルおよびトレース・ファイルの検索

OMSインスタンス・ベースのディレクトリはOracle Middlewareホーム(ミドルウェア・ホーム)のgc_instです。このディレクトリにはOMS 12cに関連するすべてのログとトレース・ファイルが格納されます。

これは、必要に応じてインストーラで変更することもできます。

たとえば、ミドルウェア・ホームが/u01/app/Oracle/Middleware/の場合、インスタンス・ベースの場所は/u01/app/Oracle/gc_instです。これは、必要に応じてインストーラで変更することもできます。ただし、これは拡張インストールでは変更できますが、簡易インストールでは変更できません。

28.4.3 Oracle Management Serviceのログ・ファイルおよびトレース・ファイルのサイズと数の制御

OMSのログ・ファイルおよびトレース・ファイルのサイズは、情報がファイルに書き込まれるにつれて大きくなります。ただし、ファイルは最大サイズに達するように設計されています。ファイルが事前定義済の最大サイズに達すると、OMSはログ情報の名前を新しいファイル名に変更し(ロール)、新しいログ・ファイルやトレース・ファイルを開始します。このプロセスにより、ログ・ファイルやトレース・ファイルのサイズが大きくなりすぎることはありません。

そのため、OMSログ・ディレクトリに複数のログ・ファイルとトレース・ファイルがある場合が多くなります。次の例は、/u01/app/Oracle/gc_inst/em/EMGC_OMS1/sysman/log/ディレクトリの1つのアーカイブ・ログ・ファイルと現在のログ・ファイルを示しています。

emoms.log
emoms.log.1

OMSのログ・ファイルおよびトレース・ファイルの最大サイズと、ロールオーバー・ファイルの数を制御するには、次のコマンドを実行して、表28-3の説明に従い詳細を指定します。

emctl set property -name <property> -value <property value> -module logging

前述のコマンドはすべてのOMSに対するプロパティを設定します。これを1つのOMSに設定する場合、次のように追加のオプション-oms_nameを指定します。

emctl set property -name <name> -value  <value> -module logging -oms_name example.myco.com:portnumber_Management_Service

これを現在のOMSに設定するには、プロパティ-oms_name local_omsを使用します。これを別のOMSに設定するには、そのOMSの名前を指定できます。OMS名はexample.myco.com:portnumber_Management_Serviceと同様であることが必要です。

注意:
Oracle Enterprise Manager Cloud Control 12cでは、変更を有効にするためにOMSを再起動する必要はありません。

注意:
Oracle Enterprise Manager Cloud Control 12cでは、デフォルトでemctl set propertyはすべてのOMSに対しロギング・プロパティを設定します。1つのOMSに対するプロパティを設定するには、-oms_nameオプションを使用します。

表28-3 emomslogging.propertiesファイルのOracle Management Serviceのログ・ファイル・プロパティ

プロパティ

目的

例

log4j.appender.emlogAppender.
MaxFileSize

OMSログ・ファイルがこのサイズに達すると、OMSはログ・データを新しいロールオーバー・ファイルにコピーして新しいemoms.logログ・ファイルを作成します。ログのサイズはバイト単位で指定します。このプロパティはemoms_pbs.logにも適用可能です。

log4j.appender.emlogAppender.
MaxFileSize=20000000

log4j.appender.emlogAppender.
MaxBackupIndex

このオプションのプロパティは、OMSがログ・データを削除する前にログ・ファイルをロールオーバーして新しいファイル名に変更する回数を示します。このプロパティはemoms_pbs.logにも適用可能です。

注意: ログ・ファイルにはトレース・ファイルほどのデータは含まれないため、通常、複数のロールオーバー・ファイルを作成する必要はありません。

log4j.appender.emlogAppender.
MaxBackupIndex=1

log4j.appender.emtrcAppender.
MaxFileSize

OMSトレース・ファイルがこのサイズに達すると、OMSはログ・データを新しいロールオーバー・ファイルにコピーして新しいemoms.trcログ・ファイルを作成します。このプロパティはemoms_pbs.trcにも適用可能です。

log4j.appender.emtrcAppender.
MaxFileSize=5000000

log4j.appender.emtrcAppender.
MaxBackupIndex

このプロパティは、OMSがトレース・データを削除する前にトレース・ファイルをロールオーバーして新しいファイル名に変更する回数を示します。このプロパティはemoms_pbs.trcにも適用可能です。

log4j.appender.emtrcAppender.
MaxBackupIndex=10

28.4.4 Oracle Management Serviceのトレース・ファイルの内容の制御

デフォルトでは、OMSはすべてのクリティカル・メッセージと警告メッセージをemoms.trcファイルに保存します。ただし、OMSが生成するログ情報量を調整できます。

OMSで生成されるログ情報量を変更するには、次のコマンドを実行します。

emctl set property -name "log4j.rootCategory" -value "<LEVEL>, emlogAppender, emtrcAppender" -module logging

前述のコマンドは、-oms_name optionが指定されていないかぎり、すべてのOMSのログ・レベルを変更します。

注意:
emoms.trcファイルのルート・ログ・レベルを変更する場合、多くのメッセージがトレース・ファイルに書き込まれるため領域はすぐに一杯になり、システムが停止する可能性があります。次のコマンドを実行して、評価する必要のある特定のモジュールを選択してデバッグを有効にします。

emctl set property -name <logging module> -value DEBUG -module logging

<logging module>は、特定のサブシステムのログ・モジュールを表します。

たとえば、oracle.sysman.emdrep.dbjava.loaderなどになります。

次のコマンドを実行して、特定のモジュールのロギング・レベルを変更できます。

emctl set property -name "<CATEGORY>" -value "<LEVEL>" -module logging

LEVELにはDEBUG、INFO、WARNまたはERRORを指定でき、CATEGORYはレベルを変更するモジュールに固有です。ロギング・モジュールを変更する場合は、Oracleサポートに連絡してください。

注意:
emoms.trc、emoms.log、emoms_pbs.trcおよびemoms_pbs.logファイルの場所は、デフォルトの場所から別の場所に変更できます。しかし、それはお薦めしません。

28.4.5 Oracle WebLogic ServerおよびOracle HTTP Serverのログ・ファイルの制御

Oracle Management Serviceは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。Oracle WebLogic Serverの各種コンポーネントにより、各自のログ・ファイルが生成されます。これらのファイルには、後にサポート担当者が問題の解決に使用できる重要な情報が含まれます。

表28-4は、一部のコンポーネントのログ・ファイルの場所を示しています。

表28-4 コンポーネントのログ・ファイルの場所

コンポーネント

場所

Oracle HTTP Server(OHS)

<EM_INSTANCE_BASE>/<webtier_instance_name>/diagnostics/logs/OHS/<ohs_name>

次に例を示します。

/u01/app/Oracle/gc_inst/WebTierIH1/diagnostics/logs/OHS/ohs1

OPMN

<EM_INSTANCE_BASE>/<webtier_instance_name>/diagnostics/logs/OPMN/<opmn_name>

次に例を示します。

/u01/app/Oracle/gc_inst/WebTierIH1/diagnostics/logs/OPMN/opmn

Oracle WebLogic

WebLogicのログ・データは次の場所にあります。

<EM_INSTANCE_BASE>/user_projects/domains/<domain_name>/servers/<SERVER_NAME>/logs/<SERVER_NAME>.log

このログは、サイズ、時間およびWeblogicコンソールのその他の条件によって制限およびローテーションできます。デフォルト設定は次のとおりです。

- 本番モードでは、デフォルトの5MBでローテーションされます。

- ログ・レベルはWARNINGです。

- ファイル数は10に制限されます。

次に例を示します。

/u01/app/Oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.log

sysoutおよびsyserrに書き込まれるメッセージは、.outファイルで入手できます。サイズまたは時間ではローテーションできません。サーバーの起動時にのみローテーションされます。次の場所にあります。

<EM_INSTANCE_BASE>/user_projects/domains/<domain_name>/servers/<SERVER_NAME>/logs/<SERVER_NAME>.out

次に例を示します。

/u01/app/Oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.out

ノード・マネージャのログは<INST_HOME>/NodeManager/emnodemanagerに、管理サーバーのログは<INST_HOME>/user_projects/domains/GCDomain/servers/EMGC_ADMINSERVER/logsにあります。

Enterprise Manager Cloud Controlでは、デフォルトで、新しいファイルに定期的にロールオーバーするようにOracle HTTP Serverのログを構成するため、各ファイルのサイズが大きくなりすぎることはありません。ディスク領域を確保するために古いロールオーバー・ファイルを定期的に削除することも必要です。UNIXのcronと同様に、オペレーティング・システムのスケジューラを使用してロールオーバー・ファイルを定期的に削除できます。

注意:
メンテナンスおよび手動でのパージを必要とするログ・ファイルは次のとおりです。

- <gc_inst>/user_projects/domains/<domain_name>/servers/EMGC_ADMINSERVER/logs/<domain_name>.log*

- <gc_inst>/WebTierIH1/diagnostics/logs/OHS/ohs1/にあるすべてのファイル。次に例を示します。

em_upload_http_access_log.*
access_log.*
em_upload_https_access_log.*
ohs1-*.log
console~OHS~1.log*
mod_wl_ohs.log*

- 管理サーバーおよびemgc_omsサーバーにある次のファイル。

<gc_inst>\users_projects\domains\<domain_name>\servers\EMGC_ADMINSERVER\logs\*.out*
<gc_inst>\users_projects\domains\<domain_name>\servers\EMGC_OMS?\logs\*.out*

これらのログ・ファイルのサイズおよびローテーションの制御手順については、『Oracle Fusion Middleware管理者ガイド』の「ログ・ファイルと診断データの管理」を参照してください。

Fusion Applications PL/SQLおよびC診断ログ・ファイルを表示するようにEnterprise Managerを構成する方法については、Oracle Fusion Applicationsの管理者ガイドのOracle Fusion Applicationのログ・ファイルと診断テストの管理に関する項を参照してください。

28.5 ログ・ファイルのモニタリング

ログ・ファイル監視を使用すると、WebLogic Serverとアプリケーション・デプロイメントのログ・ファイルを監視して特定のパターンを確認できます。パターンが検出された場合にターゲットのコンテキストでアラート通知を受信するようにCloud Controlを設定できます。これにより、ユーザーが問題を発見する前に、管理者として問題に事前に対処し、学習することができます。

ログ・ファイル監視を設定および使用する方法は、次のトピックを参照してください。

- ログ・ビューアについて

- WebLogic Serverとアプリケーション・デプロイメントのログ・ファイル監視の概要

- ログ・ファイル監視の有効化

- ログ・ファイル監視の構成

- ログ・ファイル監視からのアラートの表示

28.5.1 ログ・ビューアについて

ログ・ビューアによって、管理者は、ディスク上のファイルの存在場所に関係なく、ミドルウェア関連のログ・ファイルを表示、検索およびダウンロードできます。複数のFusion MiddlewareファームおよびWebLogicドメインに及ぶ複数のミドルウェア・コンポーネントのパフォーマンスの問題を、管理者が迅速に診断する際に役立つように、複雑な検索基準を指定し、後で参照するために保存できます。

注意:
Cloud Controlでログ・ビューアの機能をすべて使用する際に、ログ・メッセージを表示するターゲット・ドメインが、カスタム証明書を使用してSSLに対応している場合は、ログ・ビューアの機能が正常に機能しません。ログ・ビューアのほとんどの機能では、OMSにより、そのドメインの管理サーバーにJMX接続が確立されます。OMSにより管理サーバーに直接JMX接続が確立されないログ・ビューアの機能は、アーカイブ・ログ・ファイルに使用される機能のみです。アーカイブ・ログ・ファイルの表示には、エージェントがかわりに使用されます。
この環境でログ・ビューア機能が完全に機能するには、追加の構成変更を適用する必要があります。ログ・メッセージを表示するドメインの管理サーバー・ターゲットからカスタム証明書のrootcaを取得し、OMSのトラスト・ストアにインポートします。

ログ・ビューアにアクセスすると、選択したターゲット・タイプに対して、デフォルトの検索基準が指定されます。管理者は、特定のFusion Middlewareファームの診断の要件に基づいて、検索基準を絞り込むことができます。「フィールドの追加」ボタンを使用して、含める検索基準を絞り込むことができます。

- Fusion Middlewareファームの1つ以上のメンバー・ターゲットの選択

- 日付範囲の指定

- メッセージ・タイプの選択

- 検索するメッセージの指定

- 検索するECIDの指定

- アプリケーション名の指定

- ユーザー名の指定

検索基準を定義したら、管理者は「検索」ボタンをクリックします。

管理者は、必要に応じて検索を変更し、ログ・ビューアで「検索の保存」ボタンをクリックします。

検索を実行したターゲットなど、指定した検索基準は、現在ログインしている管理者の管理リポジトリに保存されます。

「保存済検索」ボタンをクリックして、以前に保存した検索基準を取得および保存することができます。

「保存済検索の管理」をクリックして、以前に保存した検索基準を編集または削除するポップアップを起動できます。

28.5.2 WebLogic Serverとアプリケーション・デプロイメントのログ・ファイル監視の概要

ログ・ファイル監視を使用すると、WebLogic Serverとアプリケーション・デプロイメントのログ・ファイルを監視して特定のパターンを確認できるため、トラブルシューティングの時間を短縮できます。パターンが検出された場合にターゲットのコンテキストでアラート通知を受信するようにCloud Controlを設定できます。

「ログ・ファイル・モニタリング」のメトリック(WebLogic Serverおよびアプリケーション・デプロイメントのターゲット・タイプ用のログ・ファイル・パターン一致行数)を使用すると、1つ以上のログ・ファイルで、1つ以上の検索パターンの出現をモニタリングできます。また、ログ・ファイルで無視されるパターンも指定できます。最後のスキャン後に追加された新しい内容に対しては、デフォルトで60分ごとの定期的なスキャンが実行されます。無視パターンと一致する行が最初に無視され、指定した一致パターンに行が一致すると、パターンごとに1つのレコードがリポジトリにアップロードされます。指定されたパターンに一致する行の数のしきい値を設定できます。所定のファイル内でファイル・ローテーションが行われます。

また、監視テンプレート機能も使用できます。これによって管理者は、1度メトリックをテンプレートで構成すると、そのテンプレートを複数のWebLogic Serverまたはアプリケーション・デプロイメントのターゲットに同時に適用できるため、それぞれのWebLogic Serverログ・ファイルの監視メトリックを個別に構成する必要はありません。

ホスト・ターゲット・タイプを介したログ・ファイル監視を使用している場合、Fusion Middleware関連のターゲット・タイプを介してログ・ファイル監視を構成し、Fusion Middlewareターゲットのコンテキストでアラートが表示されるようにします。

ログ・ファイル監視の前提条件

ログ・ファイル監視には、ローカルの管理エージェント監視ターゲットが必要です。つまり、モニタリング対象のログ・ファイルのホストに管理エージェントがインストールされており、稼働している必要があります。管理エージェントをインストールしたオペレーティング・システム・ユーザーには、モニタリング対象のログ・ファイルが存在するディレクトリへの読取りアクセス権が必要です。ログ・ファイル監視はデフォルトで無効になっています。この機能を使用するには、有効にする必要があります。

28.5.3 ログ・ファイル監視の有効化

ログ・ファイル監視はデフォルトで無効になっています。ログ・ファイル監視を有効化するには、次の手順に従います。

1. ターゲット・メニューから、「監視」を選択します。

2. 「メトリックと収集設定」を選択します。

3. 「メトリックと収集設定」ページの「メトリック」タブで、「表示」ドロップダウン・メニューから「すべてのメトリック」を選択します。

4. 「ログ・ファイル・モニタリング」を検索します。「ログ・ファイル・モニタリング」行で「無効化」リンクをクリックします。

5. 「収集設定の編集: ログ・ファイル・モニタリング」ページで、「収集スケジュール」セクションの「有効化」をクリックします。デフォルトの収集スケジュールは、60分ごとに設定されています。

6. 「続行」をクリックします。
「メトリックと収集設定」ページが表示されます。この時点で、Enterprise Manager Cloud Controlによってログ・ファイル・モニタリングが有効化されますが、変更は管理リポジトリに保存されません。

7. 「メトリックと収集設定」ページで「OK」をクリックします。
Enterprise Manager Cloud Controlによって変更が管理リポジトリに保存されます。

28.5.4 ログ・ファイル監視の構成

ログ・ファイル監視を構成するには、次の手順に従います。

1. ターゲット・メニューから、「監視」を選択します。

2. 「モニタリング」メニューから「メトリックと収集設定」を選択します。

3. 「メトリックと収集設定」ページの「メトリック」タブで、「表示」ドロップダウン・メニューから「すべてのメトリック」を選択します。

4. 「ログ・ファイル・モニタリング」を検索します。

5. 「ログ・ファイル・モニタリング」行の下の「ログ・ファイル・パターン一致行数」行で、右側にある「編集」アイコンをクリックします。

6. 「詳細設定の編集: ログ・ファイル・パターン一致行数」ページの「モニター対象オブジェクト」セクションで、「追加」をクリックして、モニタリング対象のログ・ファイルの設定を指定します。
「モニター対象オブジェクト」セクションの表には、このメトリックに設定されているすべてのログ・ファイル名、一致パターンおよび無視パターンがリストされます。列ごとに異なるしきい値設定を指定できます。「並替え」ボタンでは、最初にスキャンするログ・ファイルを指定します。

検索基準を設定するとき、ワイルドカードと正規表現を組み合せて使用できます。

7. 「ログ・ファイル名」列に、検索するログ・ファイル名パターンを入力します。
ワイルドカードと正規表現を組み合せて使用できます。ただし、「ログ・ファイル名」列でワイルドカードを使用する場合は、ログ・ファイルが存在するログ・ディレクトリの場所のパスではなく、ログ・ファイル名を識別する目的でのみワイルドカードを使用してください。

次に例を示します。

- /u01/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/%.logを指定した場合は、ログ・ディレクトリ内の.log拡張子を持つすべてのファイルが選択されます。

- /u01/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/%diagnostics%を指定した場合は、ログ・ディレクトリ内のファイル名にdiagnosticsを含むすべてのファイルが選択されます。

- /u01/domains/%_DOMAIN%/servers/EMGC_OMS1/logs/%diagnostics%を指定した場合は、無効なパターンとして処理されます。ログ・ディレクトリ・パスの識別にワイルドカードを使用しないでください。

8. 「一致パターン」列に、ログ・ファイル内で考慮する必要がある一致パターンを入力します。ワイルドカードと正規表現を組み合せて使用できます。大文字小文字も無視されます。
次に例を示します。

- 一致パターンをFATALと設定します。このパターンは、fatalを含むすべての行に対して真になります。

- 一致パターンを%fatal%critical%と設定します。このパターンは、fatalとcriticalを含むすべての行に対して真になります。

9. 「無視パターン」列に、ログ・ファイル内で無視する必要がある一致パターンを入力します。デフォルトでは、列に%が表示されます。何も無視しない場合は、デフォルト値を削除する必要があります。ワイルドカードと正規表現を組み合せて使用できます。大文字小文字も無視されます。

- 一致パターンをBEA-0023と設定し、無視パターンをwarningと設定します。このパターンでは、BEA-0023を検索しますが、同じ行にwarningが含まれている場合は無視します。

- 一致パターンをADFC-1023%FAILED%と設定します。このパターンでは、同じ行内でFAILEDが後に続くADFC-1023のみを検索します。

- 一致パターンをBEA-%と設定し、無視パターンをBEA-1005と設定します。このパターンでは、BEA-で始まるすべてのパターンを検索しますが、BEA-1005は無視します。

10. 「警告のしきい値」および「クリティカルのしきい値」列で、パターンが収集スケジュール内で指定した回数ログ・ファイルに出現した場合にアラートがトリガーされるように、しきい値をその回数に設定します。発生回数が詳細設定で指定されている場合は、この係数がアラート発生時に考慮されます。
たとえば、クリティカルしきい値を1に設定(パターンがログ・ファイルに複数回見つかると、クリティカル・アラートになります)し、発生数を2に設定した場合、クリティカル・アラートが発生するのは、連続する2回の収集内でログ・ファイルにパターンが複数回見つかる場合のみです。

「ログ・ファイル・パターン一致行数」メトリックをモニタリング・テンプレートの一部に含める

ログ・ファイル監視が有効化および構成されている場合、「ログ・ファイル・パターン一致行数」メトリックを監視テンプレートの一部に含めることができます。ログ・ファイルの場所は、テンプレートが適用されるターゲット全体で同じである必要があります。監視設定をターゲットごとに個別に設定するのではなく、テンプレートを複数のWebLogic Serverまたはアプリケーション・デプロイメントのターゲットに一度に適用できます。

ログ・ファイル監視メトリックの構成後に、指定したパターンがログ・ファイルに含まれるが、アラートがOMSに生成されない場合は、次を実行してください。

- ログ・ファイル名にPerlパターンが含まれているかどうかを確認します。

- 無視パターンにアスタリスク(*)が含まれているかどうかを確認します。無視パターン・フィールドにアスタリスクを指定すると、一致するパターンが含まれるすべての行も無視されます。

構成の問題

特定のターゲットについてロギング構成が見つからないか、無効であることを示すエラー・メッセージが表示される場合、次のオプションを試行できます。

最初に、アクセスしようとしているWebLogicドメインがOracle JRF (Java必須ファイル)有効でない可能性があります。Oracle JRFはOracle WebLogic Serverインストールに含まれていないコンポーネントで構成されており、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークの共通機能を提供します。ログ・メッセージを表示するには、ターゲットがOracle JRF有効である必要があります。WebLogicドメインがOracle JRF有効であるかどうかなどを確認するには、次の手順を実行します。

1. 「WebLogicドメイン」メニューから「ターゲット設定」サブメニュー、「監視構成」の順に選択します。

2. ドメインの「監視構成」ページで、適切な「JRF適用可能」を検索します。このプロパティの値はtrueまたはfalseのいずれかです。値がfalseの場合、ドメインはOracle JRF有効ではありません。

ドメインの「JRF適用可能」プロパティの値がtrueの場合、そのドメイン内のすべての管理対象サーバーがOracle JRF有効でなくてもかまいません。特定の管理対象サーバーのコンテキストでログ・メッセージにアクセスできない場合、関連する管理対象サーバーの「監視構成」ページに移動します。「監視構成」ページから、「JRF有効」プロパティを検索します。このプロパティの値はtrueまたはfalseのいずれかです。値がfalseの場合、管理対象サーバーはOracle JRF有効ではありません。

2番目に、Enterprise Manager Cloud Control管理者がログ・メッセージへのアクセスを試行していますが、必要なターゲット権限がありません。ログ・メッセージを表示するには、対応するターゲットについて、管理者に「Fusion Middlewareのログを表示する権限」のターゲット権限が付与されている必要があります。Oracle Enterprise Managerのサイト管理者またはスーパー管理者に、ユーザー自身にこの権限が付与されているかどうかを問い合せます。このターゲット権限、および管理者への権限の付与の詳細は、このドキュメントの後半の質問を参照してください。

28.5.5 ログ・ファイル監視からのアラートの表示

「ログ・ファイル・パターン一致行数」メトリックから生成されるアラートは、ターゲットのホームページまたは「アラート履歴」ページに表示されます。

トリガーされたアラートは手動でクリアする必要があります。

28.6 ログ・アーカイブの場所の構成

WebLogicドメインおよびそのドメインのすべてのターゲットのホスト、その資格証明およびアーカイブの場所に関する情報を構成できます。ターゲットとして同時にすべてをまとめて構成するか、ターゲットを個別に構成できます。

すべてのターゲットを同時に構成するには、次の手順を実行します。

1. WebLogicドメインのホームページで、「WebLogicドメイン」メニューから「ログ」を選択し、アーカイブの場所の構成を選択してください。
アーカイブの場所の構成ページが表示されます。

2. 表のWebLogicドメインを選択し、「ホスト資格証明の割当て」をクリックします。
ホスト資格証明の割当てポップアップが表示されます。

3. 必要な情報を指定し、上のホスト資格証明を子のターゲットに適用チェック・ボックスが選択されていることを確認して、「OK」をクリックします。
選択したホスト名がアーカイブの場所の構成ページの「ホスト」列に表示され、子のすべてのターゲットでも列にこのホストが表示されます。

4. 「アーカイブの場所の割当て」をクリックします。
「リモート・ファイル・ブラウザ」ポップアップが表示されます。

5. ディレクトリ名をダブルクリックしてホスト名フィールドに入力し、フィールドに入力するサブディレクトリごとにこのプロセスを繰り返します。作業を終了後、「OK」をクリックします。
選択したディレクトリの場所がアーカイブの場所の構成ページの「アーカイブの場所」列に表示され、子のすべてのターゲットでも列にこの場所が表示されます。

ターゲットを個別に構成するには、前述の手順に従いますが、WebLogicドメインのかわりに特定のターゲットを選択します。

29 サービスの構成および使用

この章では、サービスの概要と、Enterprise Managerを使用してサービスを構成および監視する手順を説明します。この章の内容は、次のとおりです。

- サービスの概要

- サービスの作成

- サービスのモニタリング

- サービスの構成

- トランザクション・レコーダの使用

- サービス・レベル合意の設定および使用

- サービス・ダッシュボードの使用

- テスト・リポジトリの使用

- サービス・レベルの設定

- コマンドライン・インタフェースを使用したサービスの構成

- サービス・テストのトラブルシューティング

29.1 サービスの概要

今日のビジネス・アプリケーションは重要で複雑なので、IT組織が高い基準と可用性でアプリケーションのサービス・レベルを監視して管理することが非常に重要になります。エンタープライズが直面する問題には、サービスの失敗やパフォーマンスの低下があります。これらのサービスは業務上の伝達を行う上で重要な役割を果すため、サービスを監視し、業務に影響を及ぼす前に問題を迅速に解消することはすべてのエンタープライズにとって重要です。

Enterprise Managerには、概要レベルから個々のコンポーネント・レベルまでのサービスを効率的に管理できる包括的な監視ソリューションが用意されています。サービスが停止するか、そのパフォーマンスが低下した場合、Enterprise Managerの診断ツールを使用すると、問題を迅速かつ効率的に解決して、問題の特定および解決に要する管理コストを大幅に削減できます。さらに、カスタマイズされたレポートには、一定期間にわたってアプリケーションの動作を分析できる有益なメカニズムが備えられています。Enterprise Managerは、ITインフラストラクチャ内の個々のコンポーネントのみでなく、これらのコンポーネントによってホストされるアプリケーションも監視します。このため、トップダウン方式を使用して、またはエンドユーザーの観点からビジネス機能をモデル化および監視できます。サービスが適切にモデル化されると、モデル化された機能またはアプリケーションの可用性、パフォーマンスおよび使用状況を正確に測定することができます。

29.1.1 Enterprise Managerのサービスの定義

サービスは、ユーザーの役に立つ機能を提供するエンティティとして定義されます。たとえば、サービスには、CRMアプリケーション、オンライン・バンキングおよび電子メール・サービスなどがあります。比較的簡単な形式のサービスは、DNS、LDAP、POP、FTP、SMTPなどのプロトコルでサポートされるビジネス機能です。

Enterprise Managerを使用して、エンタープライズ内で実行するビジネス機能またはアプリケーションを表す1つ以上のサービスを定義できます。これらのサービスを定義するには、共通のエンド・ユーザー機能をシミュレートする1つ以上のテストを作成します。システム・ターゲットに基づいた、またはシステムとサービス・テストの両方に基づいたサービスを定義することもできます。

サービスを事前に監視するサービス・テストを作成できます。これらのテストを使用して、重要なビジネス機能のパフォーマンスと可用性を測定し、問題があるときには通知を受け取り、一般的な問題を識別し、障害の原因を診断することができます。

要件に応じて様々なタイプのサービス・モデルを定義できます。作成可能なサービス・モデルのタイプを次に示します。

- 汎用サービス: 汎用サービスとは、Enterprise Managerで作成できる単純なサービス・モデルです。重要なビジネス機能を表すサービス・テストを関連付けること、または関連するシステム・ターゲットを関連付けること(あるいはその両方)によって、1つ以上のサービス・モデルを定義できます。

- 集約サービス: 複数のサービスを組み合せて、集約サービスを構成できます。集約サービスにおいて、個別のサービスはサブサービスと呼ばれます。ある集約サービスが、サブサービスとして使用されて、別の集約サービスを作成することもできます。
集約サービスには、メンバー・サービス、システムまたはテストの少なくとも1つが含まれている必要があります。メトリックは、メンバー・サービス、システムまたはテストから昇格できます。

要件に応じて他のサービス・モデルを定義できます。

29.2 サービスの作成

サービスを作成する前に、サービス管理の概念についてよく理解する必要があります。また、次のタスクも実行する必要があります。

- 適切なサービス・テストおよびプロトコルを使用して、管理エージェントがサービスを監視できる必要がある場所を特定します。たとえば、サービスにHTTPベースのサービス・テストまたはIMAPベースのサービス・テストが含まれる場合、ネットワーク・アーキテクチャ内の管理エージェントはそれらのテストを許可します。管理エージェントがネットワーク・セキュリティ(ファイアウォール)およびネットワーク・ルーティングのガイドラインに従って、適切な場所にインストールされていることを確認する必要があります。
ビーコン・ターゲットは、サービス作成前に管理エージェント上ですでに作成されている必要があることに注意してください。

- Enterprise Managerターゲットとしてリストされるように、使用中のサービスのすべてのコンポーネントを検出します。

- サービスのベースとなるシステムを定義します。

次のサービスが作成できます。

- 汎用サービス - テスト・ベース: ATS、CalDAV、DNS、FTPなどのサービス・テストのタイプをベースにしたサービスを作成できます。

- 汎用サービス - システム・ベース: システムまたは1つ以上のシステム・コンポーネントをベースにしたサービスを作成できます。

- 集計サービス: 1つまたは複数のサブサービスからなる集計サービスで、テスト・ベースまたはシステム・ベースの汎用サービスのいずれかになります。

29.2.1 汎用サービス - テスト・ベースの作成

テスト・ベースの汎用サービスを作成するには、次の手順に従います。

1. 「ターゲット」メニューから「サービス」を選択します。「サービス」のメイン・ページが表示されます。

2. 「作成」メニューから、「汎用サービス - テスト・ベース」を選択します。「汎用サービスの作成: 一般」ページが表示されます。

3. サービスの名前を入力し、監視する必要があるサービスのタイムゾーンを選択します。サービスの可用性とSLAの計算は、ここで選択したタイムゾーンに基づきます。「次」をクリックします。

4. 「汎用サービスの作成: サービス・テスト」ページが表示されます。「テスト・タイプ」ドロップダウン・リストから、テストを選択します。

図29-1 「汎用サービスの作成: サービス・テスト」ページ

注意:
「ATSトランザクション」テスト・タイプを選択した場合、「ATS Zipアーカイブ」セクションに、ローカル・マシンまたはテスト・リポジトリからファイルをインポートできます。ただし後者を使用するには、そのテスト・リポジトリにテスト・スクリプトをアップロードしておく必要があります。テスト・リポジトリの使用方法の詳細は、第29.8項を参照してください。

5. 選択したテスト・タイプに応じて、このページのその他のパラメータを入力し、「次」をクリックします。「汎用サービスの作成: ビーコン」ページが表示されます。

6. 「追加」をクリックし、サービスを監視するためのビーコンを1つ以上追加します。主要なユーザー・コミュニティに戦略的に配置されたビーコンを使用して、ビーコンが配置された場所のサービスの可用性を予防的にテストすることをお薦めします。ビーコンが存在しない場合、新規のビーコンを作成する必要があります。詳細は、「ビーコンのデプロイと使用」を参照してください。

注意:

- サービス・テストを監視するには、管理エージェントから単一のビーコンのみを追加する必要があります。同じ管理エージェントから1つのサービス・テストに複数のビーコンを追加することはお薦めしません。
ビーコンは、サービス・テストの監視、主に異なる地理的位置からのサービスまたはビジネス機能のパフォーマンス測定に使用されるターゲットです。このため、同じ管理エージェントから複数のビーコンを追加しても、値が追加されません。

- キー・ビーコンとしてマークされているビーコンを使用して、サービスの可用性が判断されます。サービスは、1つ以上のサービス・テストが少なくとも1つのキー・ビーコンから正常に実行できる場合に、使用できます。

- サービスを作成する前にビーコンを作成することをお薦めします。

7. 「次」をクリックします。「汎用サービスの作成: 確認」ページが表示されます。ここまでに入力した情報を確認し、「終了」をクリックしてサービスを作成します。新しく作成したサービスが、メインの「サービス」ページに表示されます。

29.2.2 汎用サービス - システム・ベースの作成

システム・ベースの汎用サービスを作成するには、次の手順に従います。

1. 「ターゲット」メニューから「サービス」を選択します。「サービス」のメイン・ページが表示されます。

2. 「作成」メニューから、「汎用サービス - システム・ベース」を選択します。「汎用サービスの作成: 一般」ページが表示されます。

3. サービスの名前を入力し、サービスのタイム・ゾーンを選択します。「次」をクリックします。「汎用サービスの作成: システム」ページが表示されます。サービスがベースにするシステムを選択します。システムはサービスをホストするために使用されるインフラストラクチャを指します。システムは、ホスト、データベース、その他のターゲットといったコンポーネントで構成されます。

4. 「次」をクリックします。「汎用サービスの作成: 確認」ページが表示されます。ここまでに入力した情報を確認し、「送信」をクリックしてサービスを作成します。新しく作成したサービスが、メインの「サービス」ページに表示されます。

29.2.3 集約サービスの作成

集約サービスは、1つ以上のサービス(サブ・サービスまたはメンバー・サービス)で構成されます。サブサービスは、Enterprise Manager Cloud Controlで作成されるサービスです。集約サービスの可用性、パフォーマンスおよび使用状況は、サービスを構成する個々のサブ・サービスの可用性、パフォーマンスおよび使用状況に依存します。集約サービスを作成する場合は、少なくともシステムまたは1つ以上のサブ・サービスが関連付けられている必要があります。必要な場合は、サブ・サービスとシステムの両方を含めることができます。

集計サービスを作成するには、次の手順に従います。

1. 「ターゲット」メニューから「サービス」を選択します。「サービス」のメイン・ページが表示されます。

2. 「作成」メニューから「集約サービス」を選択します。「集計サービスの作成: 一般」ページが表示されます。

3. 集計サービスの名前を入力し、監視するサービスのタイムゾーンを選択します。監視されたデータは、選択したタイムゾーンで表示されます。「次」をクリックします。

4. 「集計サービスの作成: サービス」ページが表示されます。「追加」をクリックし、集計サービスに含めるメンバー・サービス(サブ・サービス)を1つまたは複数選択します。1つまたは複数のテスト・ベース、システム・ベースの汎用サービス、集計サービスを追加できます。「次」をクリックします。

5. 「集計サービスの作成: システム」ページが表示されます。サービスがベースにするシステム・ターゲットを選択します。必須ではありませんが、システムとサービスを関連付けることをお薦めします。根本原因分析などの機能は、キー・システム・コンポーネントが正しく定義されていることに依存します。

集約サービスの作成後、構成サブ・サービスの追加または削除、可用性定義の変更、およびパフォーマンスあるいは使用状況メトリックの追加または削除ができます。

警告:

集約サービスからサブサービスを削除すると、集約サービスのパフォーマンス、使用状況およびビジネスの各メトリックがサブサービスのメトリックに基づく場合に影響を受けることがあります。

29.3 サービスのモニタリング

サービスが定義されると、サービスのステータスを監視でき、可用性履歴、パフォーマンス、有効化されたSLA、トポロジなどを表示できます。この項の内容は次のとおりです。

- 汎用サービス/集計サービス・ホームページ

- 「パフォーマンス・インシデント」ページ

- SLAダッシュボード

- テストの要約

- トポロジ

29.3.1 「汎用サービス / 集計サービス」ホームページの表示

サービスのパフォーマンス、可用性、使用量の概要を表示するには、メインのサービスのページで選択されたサービスをクリックします。選択されたサービスのホーム・ページが表示されます。次のリージョンが含まれます。

- 一般: この領域では、現在のサービスのステータスと、過去24時間の可用性(%)を表示できます。また、可用性がサービスのテストか、システムのどちらをベースにしているかを表示することもできます。集計サービスの場合、可用性はサブ・サービスをベースにすることもできます。「可用性履歴」のグラフに、サービスが利用可能だった期間、停止したタイミング、ブラックアウト・ステータスになったタイミングなどが表示されます。

- コンポーネントの可用性: この領域には、サービスのテストまたはサービスがベースにしているシステム・コンポーネントの可用性を表示します。キー・コンポーネントまたはテストのみを表示するには、「キー・テストのみを表示」チェック・ボックスを選択します。

29.3.2 「パフォーマンス/インシデント」ページの表示

このページでは、サービスに対して定義されたパフォーマンスおよび使用状況メトリックのグラフを表示し、ドリルダウンして追加のメトリック詳細を表示できます。

パフォーマンス・メトリックは、各リモート・ビーコンに対してサービス・テストがどの程度適切に実行されているかの判別に役立ちます。一般に、ローカル・ビーコンは、Webアプリケーション・ホストに対してローカルなので、非常に有効で一貫したレスポンス時間を備えています。リモート・ビーコンは、アプリケーションのエンドユーザーの実際のレスポンス時間を反映したデータを提供します。

使用状況メトリックは、サービスに対するユーザーの要求またはワークロードの測定に使用されます。使用状況メトリックは、サービスをホストする基礎となるシステム・コンポーネントの使用状況に基づいて収集されます。特定のコンポーネントの使用状況を監視することも、一連のコンポーネントの平均値、最小値および最大値を統計的に計算することも可能です。

「インシデントと問題」領域では、サービスに関連付けられたインシデントまたは問題を表示できます。

29.3.3 SLAダッシュボードの表示

このページでは、このサービスに対して有効になっているSLAのリストが表示されます。SLAごとに、次の情報を参照できます。

- SLAの現在のステータスとそのSLO、およびの現在SLO期間のサービス・レベル値。

- 「履歴」列には、過去1週間のSLAのステータスを表示します。

- 「違反」列には、そのSLOの実績値、残存値およびSLA違反の許容回数の合計が表示されます。

29.3.4 テストの要約の表示

「テスト・レポート・ダッシュボード」には、特定のサービスで有効なすべてのテストのリストが表示されます。過去24時間のテストの実行履歴とは別に、テスト情報の最も失敗したステップ(ビーコン・レベルとテスト(集計)レベルの両方)も表示されます。

過去24時間のトランザクションに要した合計時間の傾向も表示されます。また、特定のトランザクションの実行のステップ・メトリックの内訳も表示されます。

このページでは、すべてのテストの概要をパフォーマンスおよび問題別に表示し、ビーコンごとの個々の実行にドリルダウンして、実行のトランザクション結果にドリルダウンします。

このページを使用する方法

デフォルトでは、このページアクセスすると、有効なすべてのテストが全体的なレベルで表示されます。最も失敗したステップ情報が表示され、すべての実行ビーコンでテストの最も失敗したステップが表示されます。

ツリー表でテスト・ノードを展開すると、ビーコン・レベルの実行サマリーが表示され、テストの実行履歴(過去24時間)と、最も失敗したステップの情報が表示されます。

ツリー表のテスト・ノードをクリックすすると、トランザクション診断領域がパージの下部に表示されます。親ノード(テスト(全体)ノード)が選択されている場合、下部の診断領域に、実行が成功したすべてのビーコンの集計データが表示されます。

この領域の左側の部分には、トランザクションの合計時間の傾向(過去24時間)が表示され、時間セレクタのスライダが表示されます。このスライダの目的は、トランザクション/トランザクション期間を選択して、ステップ診断領域を表示することで、このリージョンは、下部の領域の右側の部分を占めます。

29.3.5 サービス・トポロジの表示

トポロジ・ビューアには、サービスのコンポーネントがグラフィカルに表示されます。トポロジ・ビューアは、すべての従属コンポーネントとサブ・サービスをアイコンで表示し、それらの相互関係をリンクで示します。システム・コンポーネントの場合、キー・コンポーネントのみが表示されます。

次の内容を実行できます。

- サービスとそのサービスに依存する他のサービス、システム・キー・コンポーネントなどの関係の表示。サービスの可用性を決定するすべての要素がEnterprise Manager Cloud Controlのトポロジ・ビューアに表示されます。

- 「根本原因分析」によって特定されたサービス失敗の原因を表示します。潜在的な根本原因と停止中のターゲットがハイライトされます。コンポーネント間のハイライトされたリンクを選択して、サービス失敗の原因の詳細を表示します。詳細は、「根本原因分析について」を参照してください。SMARTS社のネットワーク・アダプタをインストールし構成している場合、この「トポロジ」ページには、障害のあったサービスのネットワーク・ステータスも表示されます。ネットワーク・マネージャ・アダプタのプラグインの詳細は、「SMARTSネットワーク・アダプタについて」を参照してください。

トポロジ・ビューアの詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

29.3.6 サブ・サービス

集約サービスは、1つ以上のサービス(サブ・サービスまたはメンバー・サービス)で構成されます。サブサービスは、汎用のテストベースまたはシステム・ベースのサービスです。集約サービスの可用性、パフォーマンスおよび使用状況は、サービスを構成する個々のサブ・サービスの可用性、パフォーマンスおよび使用状況に依存します。

このページには、集約サービスの一部であるすべてのサブサービスが表示されます。サブサービスごとに、サービスのステータス、キー・コンポーネント、インシデントなどが表示されます。

29.4 サービスの構成

サービスを作成すると、サービスの可用性定義、システムとサービスの関連付け、パフォーマンスと使用状況のメトリックの定義などが行えます。この項の内容は次のとおりです。

- 可用性定義

- 根本原因分析の構成

- システム・アソシエーション

- サービス・テストとビーコン

- テストの要約

- テストのモニタリング設定

- 使用状況メトリック

- パフォーマンス・メトリック

- サービス・レベル・ルールの編集

29.4.1 可用性定義 (汎用サービスおよび集計サービス)

サービスの可用性は、ユーザーがいつでもサービスを使用できるかどうかを示します。何をもって可用性とするかの基準は、アプリケーションによって異なります。たとえば、カスタマ・リレーションシップ・マネジメント(CRM)・アプリケーションでは、可用性はユーザーがアプリケーションに正常にログオンして売上レポートにアクセスできることを意味します。電子メール・アプリケーションの場合は、ユーザーがアプリケーションにアクセスして電子メールを送受信できることが可用性です。

可用性を定義するサービスをクリックし、「サービス・ホーム」ページにナビゲートします。「汎用サービス」メニューから、「管理」、「可用性」の順に選択します。サービスの可用性は、次のことに基づいて判別できます。

- サービス・テスト: エンド・ユーザーの重要な機能の可用性によってサービスの可用性が決定される場合、このオプションを選択します。このような重要な機能の例として、電子メールへのアクセス、販売レポートの生成、オンライン銀行業務トランザクションの実行などがあります。サービス・テストを定義する場合、ビジネス・プロセスの重要な機能に最も適したプロトコルと、ユーザー・コミュニティの場所に適したビーコンの場所を選択します。
標準プロトコルを使用して1つ以上のサービス・テストを定義し、1つ以上のサービス・テストをキー・テストとして指定できます。キー・テストは、様々なユーザー・コミュニティ内で1つ以上のキー・ビーコンによって実行されます。また、「キー・サービス・テスト」チェック・ボックスを選択し、サービス・テストがキー・テストであると指示することもできます。サービスの可用性計算には、キー・サービス・テストのみが使用されます。次にビーコンを選択し、キー・テストの実行およびサービスの可用性判断に使用できます。定義に応じて、すべてのキー・サービス・テストが成功しているか、または1つ以上のキー・サービス・テストが成功している場合にサービスが利用可能とみなされます。ビーコンの詳細とその作成方法については、「ビーコンのデプロイおよび使用」を参照してください。

どの場合にサービスを利用可能とするべきかを指定できます。

- すべてのキー・サービス・テストが成功(デフォルト)このオプションをお薦めします。

- 1つ以上のキー・サービス・テストが成功

注意:
サービス・テストは、1つ以上のキー・ビーコンによって実行できる場合に使用可能であるとみなされます。キー・ビーコンがない場合、サービス・テストのステータスは不明になります。

- システム: サービスの可用性は、サービスをホストしている基盤のシステムまたは選択したシステム・コンポーネントに基づいている場合もあります。可用性が選択したシステム・コンポーネントに基づく場合、サービスの実行に対して重要なコンポーネントを選択し、サービスの可用性を決定するために使用するキー・コンポーネントとして1つ以上のコンポーネントを指定します。可用性の定義に応じて、1つ以上またはすべてのキー・コンポーネントが起動して実行されているかぎり、サービスは使用可能であると判断されます。
どの場合にサービスを利用可能とするべきかを指定できます。

- すべてのキー・コンポーネントが稼働中(デフォルト)

- 1つ以上のキー・コンポーネントが稼働中

また、1つ以上のコンポーネントを、サービスの可用性計算に使用されるキー・システム・コンポーネントとしてマークすることもできます。キー・システム・コンポーネントは、可能性のあるサービス失敗の根本原因特定で使用されます。詳細は、「根本原因分析の構成」を参照してください。

- サブ・サービス: 集約サービスの場合、可用性は、サブ・サービスの可用性にも基づきます。すべてのサブサービスまたは単一のサブサービスの可用性に基づいて、可用性を判別するかを指定できます。

29.4.2 根本原因分析の構成

根本原因分析(RCA)を使用して、一連のイベントをフィルタ処理し、システム、サービスまたはアプリケーションのより高レベルな問題の原因を特定できます。RCAは、根本原因に見えるが、問題の実際の根本原因の副作用または兆候でしかない明らかなパフォーマンスの問題を排除するために役立ち、問題領域を簡単に識別できます。RCAの結果は、現在停止しているサービスのホームページまたは「トポロジ」ページ上から確認できます。トポロジ・ページでは、サービス、システムおよびコンポーネントの依存関係がグラフィカルに表示されます。トポロジ・ページでは、サービスの失敗の原因であるターゲットが強調表示されます。

RCAを実行する前に、次の内容を選択できます。

- サービス失敗時に自動的に実行されるようにツールを構成します。

- 「分析モード」(デフォルト)を「手動」に変更してRCAを無効化します。

- サービスのコンポーネント・テストおよび個々のテストのしきい値を定義します。

根本原因分析を構成する手順は、次のとおりです。

1. サービスのホームページで、「監視構成」をクリックします。

2. 「監視構成」ページで、「根本原因分析の構成」をクリックします。

3. 現在のモードが「自動」に設定されている場合は、「モードを手動に設定」をクリックしてRCAを無効化します。分析を手動で実行するように選択すると、サービスが停止状態の場合に「分析の実行」を選択して、いつでもサービスのホームページから分析を実行できます。現在のモードが「手動」に設定されている場合、サービスおよびそのコンポーネントの状態が変化した際に「モードを自動に設定」をクリックしてRCAを有効化します。

4. 管理するキー・コンポーネント用の表の「コンポーネント・テスト」列のリンクをクリックします。これにより、コンポーネント・テスト・ページ上で、コンポーネント・テストの追加、削除または編集を行うことで、サービスのキー・コンポーネントを管理できます。サービスが停止したときは、キー・コンポーネントをドリルダウンして、根底にある問題を確認できます。コンポーネント・テストの定義の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

注意:
RCAを無効化し、自動モードに設定を戻した場合、RCAにはこれまでの履歴結果は格納されず、今後、参照用としていずれの履歴も表示されません。

29.4.2.1 根本原因分析の最大限の活用

根本原因分析(RCA)は、サービスに関連する大量のデータをフィルタ処理し、サービスの可用性に影響する最も重要なイベントの発生を識別できることから、大きな価値をもたらします。Enterprise Managerで独自のサービスを構成する場合、RCAを最大活用することを考慮および計画して、サービスを定義することが重要です。

RCAを最大活用する上で最初に考慮が必要な項目は、他のサービスまたはシステム・コンポーネントに対してサービスが持つ一連の依存性です。タスクを達成するためにサービスが使用するすべてのシステム・コンポーネントを必ず識別してください。キー・コンポーネントを省略し、サービスが失敗した場合、RCAでは、そのコンポーネントを可能性のある原因として識別できなくなります。逆に、実際にはサービスが依存していないコンポーネントをサービス定義に含めると、RCAで、そのコンポーネントがサービス失敗の原因として誤って識別される場合があります。

サービス依存性を構築する場合、Enterprise Managerでサポートされている集約サービスの概念を利用することを念頭に置いてください。これにより、それぞれ独自の一連の依存性を持つ、より小さなサブサービスにサービスを分割できます。RCAはサブサービス(依存しているサービス)のステータスのみではなく、サブサービスが依存するシステム・コンポーネントまたはサービスも同様に考慮します。

RCAを最大限活用する上で次に考慮が必要な項目は、コンポーネント・テストの使用です。サービスが依存するシステム・コンポーネントを定義する際、これらのコンポーネントには、コンポーネント自体が失敗しなくても、サービス失敗となる部分が存在する場合があることを考慮します。コンポーネント・テストにより、ターゲット自体のステータスのみでなく、その主要部分のステータスもRCAでテストできます。

RCAシステムでは、キー・コンポーネントで使用可能なメトリックに基づくコンポーネント・テストを作成できます。これには、コンポーネント用に作成したユーザー定義メトリックが含まれるため、サービスが失敗した場合は、そのコンポーネントの各部分をRCAによってきわめて柔軟にテストできます。RCAは2つのモードで実行するように構成できます。サービスの失敗に基づき自動的に実行されるか、手動で実行するように構成することができます。監視対象のサービスの予想されるサービス・レベル合意のパーセントに基づいてモードを決定できます。予想されるサービス・レベル合意のパーセントが高い場合、自動モードを選択し、発生する可能性のあるエラーや失敗の根本原因を、容易に検知できるようにする必要があります。

29.4.3 システム・アソシエーション

システムとは、相互に機能することでアプリケーションをホスティングする、一連のインフラストラクチャ・コンポーネント(ホスト、データベース、アプリケーション・サーバーなど)を指します。たとえば、電子メール・アプリケーションはデータベース、リスナー、アプリケーション・サーバー、およびこれらのコンポーネントが常駐するホストによってホスティングされています。

サービスを定義すると、システム内のコンポーネント間の接続または相互関係を論理的に表すため、コンポーネント間の関連付けを指定できます。たとえば、関連付けを定義し、データベースとリスナー間の関連を示すことができます。これらの関連付けはシステムのトポロジ・ビューアに表示されます。一部のデータ・センターには、1つのアプリケーションまたはサービス専用のシステムがあります。その他のデータ・センターのシステムは複数のサービスをホスティングします。データ・センターのセットアップ方法に基づいて、1つまたは複数のサービスをシステムに関連付けできます。

このページでは、このサービスをホストするために使用するEnterprise Managerシステムを選択できます。次の内容を実行できます。

- システムの追加または選択

- 選択したシステムの変更または削除

システムを選択してから、1つ以上のシステム・コンポーネントをキー・コンポーネントとしてマークします。このキー・コンポーネントは、サービスの実行に不可欠です。このキー・コンポーネントを使用して、サービスの可用性の判断や、サービスの障害の原因の識別を行います。

29.4.4 モニタリング設定

各サービスについて、頻度(アプリケーションに対してサービスがトリガーされる頻度を決定)およびパフォーマンスしきい値を定義できます。サービスがそのパフォーマンスしきい値を超えると、アラートが生成されます。

メトリックおよびしきい値を定義するには、「汎用サービス」メニューから、「管理」、「テストの監視設定」の順に選択します。「メトリックとポリシー設定」ページが表示されます。「監視設定」リンクをクリックします。「監視設定 - しきい値」ページが表示されます。

- 表示方法 - メトリック、ビーコン - この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。サービスに追加される新しいビーコンは、デフォルトのしきい値を使用します。「メトリックの追加」をクリックして、1つ以上のメトリックを追加します。

- 表示方法 - ビーコン、メトリック - この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「表示」モード間の切替えができます。「編集」モードでは、メトリックのパラメータを変更できます。特定のビーコンのメトリックのパラメータを変更することもできます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。
これらの手順とは別に、Webトランザクション用にステップおよびステップ・グループのレベルでもメトリックを定義できます。次のいずれかの表示を選択できます。

- 表示方法: ステップ、メトリック、ビーコン: この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。新しくWebトランザクションに追加されるビーコンには、デフォルトのしきい値が使用されます。「メトリックの追加」をクリックして、1つ以上のメトリックのしきい値を定義します。サービス・テストについて、「データの粒度」プロパティの値が「トランザクション」に設定されている場合にのみインシデントが生成されます。Webトランザクションのプロパティの詳細は、Enterprise Managerのオンライン・ヘルプのサービス・テストの作成または編集、Webトランザクションのヘルプ・ページを参照してください。

- 表示方法: ステップ、ビーコン、メトリック: この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「ビュー」モード間の切替えができます。「編集」モードでは、特定のビーコンのメトリックのパラメータを変更できます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。「データの粒度」プロパティの値が「ステップ」に設定されている場合のみ、インシデントが生成されます。

デフォルトの収集頻度および収集プロパティを定義するには、「監視設定」ページの「収集の設定」タブをクリックします。次の内容を実行できます。

- すべてのビーコンのデフォルトの収集頻度を指定します。特定のビーコンの収集頻度を上書きするには、「ビーコンのオーバーライドの追加」をクリックします。

- 1つ以上のビーコンの収集プロパティおよび対応する値を指定します。

収集間隔およびパフォーマンスしきい値の定義の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

29.4.5 サービス・テストとビーコン

サービス・テストを追加し、これらのサービス・テストを実行する1つ以上のビーコンを指定できます。サービス・テストを追加、または既存のサービス・テストを変更するには、監視構成ページの「サービス・テストとビーコン」リンクをクリックします。「サービス・テストとビーコン」ページが表示されます。ドロップダウン・リストからテスト・タイプを選択し、サービス・テストを作成できます。

29.4.5.1 追加のサービス・テストの定義

プロトコルおよびビーコンの場所に基づき、異なるタイプのサービス・テストを作成できます。「サービス・テストとビーコン」ページで、次のことを実行できます。

- サービスに1つ以上のサービス・テストを追加します。テスト・タイプを選択し、「追加」をクリックします。定義可能なテスト・タイプには、ATS、FTP、Webトランザクション、DNS、SOAPなどがあります。

- サービス・テストを作成した後は、これを有効にする必要があります。サービス・テストが有効でない場合は、いずれのビーコンによっても実行されません。1つ以上のサービス・テストをキー・テストとして定義できます。これらのキー・テストは、サービスの可用性およびパフォーマンスの監視に使用されます。有効なサービス・テストのみ、キー・テストとして指定できます。サービス・テストをキー・テストとして設定するには、ページの下部にある「可用性定義」リンクをクリックします。

- ビーコンを作成、追加または削除します。ビーコンの場所を識別する場合、企業内のネットワーク、またはE-Businessに重要なインターネット上の場所を選択します。通常、これらはエンドユーザーが存在する場所です。たとえば、ビジネスがカナダでホストされ、顧客がアメリカ合衆国にいる場合、アメリカ合衆国のホスト・コンピュータにインストールされたビーコンを使用して、アプリケーションの可用性およびパフォーマンスを測定します。

- サービス・テストの作成後、「サービス・テストの検証」をクリックして、検証します。「ステータス」アイコンは、サービス・テストのステータス(キー・ビーコンが正常に実行できるかどうか)を示します。サービスにキー・ビーコンが定義されていない場合、他のビーコンがサービス・テストを実行していてもステータスは不明になります。「ステータス」をクリックすると、ステータス履歴ページに移動します。

注意:

- SOAP(シンプル・オブジェクト・アクセス・プロトコル)サービス・テストの定義中にアクセスするWSDL URLが企業のイントラネット外にある場合は、$OMS_HOME/sysman/config/emoms.propertiesファイルにプロキシ設定を追加する必要があります。
たとえば、www-myproxy.myco.comをプロキシとして設定するには、次のように値を指定します。

proxyHost=www-myproxy.myco.com

proxyPort=80

dontProxyFor=myco.com,mycorp.com

proxyUser、proxyPwd、proxyRealmおよびproxyPropsEncryptedプロパティが、認証されたプロキシの構成に使用されます。プロキシ設定を変更した後、変更が適用されるようにするには、すべてのOMSを再起動する必要があります。

- Formsトランザクション・テスト・タイプはEnterprise Manager 12cで非推奨になりました。前のリリースで作成されたFormsトランザクションは引き続き使用できますが、新たなFormsトランザクション・テスト・タイプは作成できません。汎用サービス・ターゲットを作成し、OATS EBS/Formsロード・テスト・スクリプトを使用してATSトランザクションを作成する必要があります。この「ATS」テスト・タイプを使用して、Oracle Formsアプリケーションを監視します。

- 「Webトランザクション」テスト・タイプはメンテナンス・モード専用です。Webアプリケーションを監視するには、ATSロード・スクリプトを作成し、ATSトランザクション・テスト・タイプを使用してWebアプリケーションを監視することをお薦めします。詳細は、「OATSロード・スクリプトを使用したATSサービス・テストの作成」を参照してください。

異なるタイプのサービス・テストの作成の詳細は、Enterprise Managerオンライン・ヘルプで説明しています。この章では、例としてATSテスト・タイプの作成について説明しています。

29.4.5.2 ビーコンのデプロイと使用

ビーコンは、管理エージェントがサービスをリモートで監視できるターゲットです。ビーコンは、常に1つ以上のサービスを監視できます。

注意:
ビーコンを作成する前に、Oracle Beacon 12.1.0.2以上のプラグインがデプロイされていることを確認する必要があります。

1つ以上のサービス・テストを実行するビーコンを作成するには、次の手順に従います。

1. 「設定」メニューから、「ターゲットの追加」、「ターゲットの手動追加」の順にクリックします。

2. ターゲットの手動追加ページで、「ターゲット監視プロパティを指定して非ホスト・ターゲットを追加」オプションを選択します。

3. 「ターゲット・タイプ」ドロップダウン・リストから「ビーコン」を選択し、「手動追加」をクリックします。

4. ビーコンの作成ページが表示されます。

図29-2 ビーコンの作成ページ

5. 次の詳細を入力します。

- 名前: 作成するビーコンの名前です。

- エージェント: ビーコンが実行する管理エージェントを選択します。

- プロキシ情報: ビーコンがファイアウォールを介してサービスにアクセス中の場合は、プロキシ・サーバー設定を次のように指定する必要があります。

- プロキシ・ホストおよびポート: ビーコンと通信を行うプロキシ・サーバーのホストの名前。

- プロキシ認証レルム: プロキシ・サーバーで資格証明の検証(Basic認証スキームとDigest認証スキーム)に使用される認証レルム

- プロキシ認証ユーザー名: プロキシ・サーバー認証に使用されるユーザー名(完全修飾名)

- プロキシ認証パスワード: プロキシ・サーバー認証で一緒に使用されるパスワード

- メッセージIDのリクエスト・ヘッダーの有効化: WebトランザクションおよびHTTP Pingサービスのテストの実行時に発行されるHTTPリクエストに追加ヘッダーを含めるには、このチェック・ボックスを選択します。これにより、Real User Experience Insight (RUEI)は、WebトランザクションおよびHTTP Pingのテストを監視できます。

- Webトランザクション: Windowsエージェントの場合、 Webトランザクションの再生を行うブラウザの起動時に使用するアカウント資格証明を指定します。

注意:
「サービス」メニューから「ビーコンの作成」オプションを起動できます。「サービス機能」メニューで、「ビーコン」を選択し、「追加」をクリックして、ビーコンの作成ページを起動します。

6. 「作成」をクリックして、ビーコンを作成し、「ビーコンのホームページ」に戻ります。これでビーコンを使用してサービス・テストを監視できるようになりました。

7. 「汎用サービス」メニューで、「管理」、「サービス・テストとビーコン」の順に選択します。ビーコンのリストと、有効化されたサービス・テストのリストが表示されます。

8. 監視するサービス・テストを選択し、「ビーコン」表から作成したビーコンを選択します。それがキー・ビーコンかどうかが示されます。

9. 「サービス・テストの検証」をクリックして、選択したビーコンごとにサービス・テストを実行します。

29.4.5.3 ビーコンの構成

この項では、その他のビーコン関連の構成タスクについて説明します。

- ビーコンのSSL証明書の構成: HTTPS URLを使用してSecure Sockets Layer(SSL)でURLを監視する際にビーコンを使用する場合、そのURLが存在するWebサイトで使用されている認証局を認識するようにビーコンを構成する必要があります。
ポート・チェッカ・テストでSSLオプションを使用するには、管理エージェントの監視ウォレットに証明書を追加する必要がある場合があります。追加証明書を追加するには、次の手順を実行します。

1. Base64encoded X.509 (.CER)形式の、b64SiteCertificate.txtファイル内の証明書を取得します。(ファイル名は構成により異なる可能性があります)。ファイルの内容の例を次に示します。

------BEGIN CERTIFICATE--------------
MIIDBzCCAnCgAw...
...... base 64 certificate content .....
------END CERTIFICATE-----------------

ファイルは管理エージェントのホーム・ディレクトリに<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txtファイルとして保存されています。

2. b64InternetCertificate.txtファイルが作成されていない場合は、エージェントのコア・ディレクトリとインスタンス・ディレクトリに作成します。

<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txt
<AGENT_BASE>/core/12.1.0.2.0/sysman/config/b64InternetCertificate.txt

3. 両方のb64InternetCertificate.txtファイルの末尾に、Base64encoded X.509証明書を追加します。BEGIN行とEND CERTIFICATE行の両方を含めます。

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

- 専用ビーコンの構成: エージェントのビーコン機能には、内部Java VMを使用する必要があります。Java VMの使用により、エージェントの仮想メモリー・サイズを数100MB増加できます。メモリーの制約のため、専用ホスト上で稼働するエージェント上でのみ、ビーコンを作成することをお薦めします。所定のビーコンで多数のテスト(毎分数百回)を実行する場合は、専用ホスト上へのそのビーコンのエージェントのインストールもお薦めします。専用ハードウェアを最大限に利用するには、エージェントの$ORACLE_HOME/sysman/config/emd.propertiesファイルを次のように編集します。
applicationmetadataquota: 各アプリケーション領域に対するディスクの割当てバイト数

- ThreadPoolModel=LARGEプロパティを設定します。これにより、エージェントで多数のスレッドを同時に実行できるようになります。

- useAllCPUs=TRUEプロパティを設定します。これにより、複数のCPU上でエージェントを同時に実行できるようになります。

- applicationMetadataQuota_BEACONプロパティは、ATSのzipファイルを格納するために使用できる合計サイズを指定します。ATSのzipファイルを使用する場合、またはビーコンに小規模なATSのzipファイルを多数構成する必要がある場合、applicationMetadataQuota_BEACONプロパティには大きな値を指定する必要があります。

- @ このプロパティは、ビーコンが次のものの格納に使用できる合計サイズを指定します。
@ ATS zipファイル。ユーザーが大規模なATS zipファイルを使用する予定の場合や、

@ ビーコンに小規模なATS zipファイルを多数構成する必要がある場合は、このプロパティを

@ 適宜増やす必要があります。

- agentJavaDefinesプロパティに-Xms512m -Xmx1024mを追加します。これにより、Java VMのヒープ・サイズを1024MBに増加できます。

- ビーコンのWebプロキシの構成: ネットワーク構成によっては、Webプロキシが使用されるようにビーコンを構成する必要がある場合があります。ビーコンのWebプロキシを構成するには、「すべてのターゲット」ページでビーコンを検索します。構成するビーコンを選択し、「構成」をクリックします。Webプロキシのプロパティを入力します。たとえば、ビーコンのWebプロキシとしてwww-proxy.example.comを設定するには、次のように値を指定します。

Proxy Host: www-proxy.example.com
Proxy Port: 80
Don't use Proxy for: .example.com,.example1.com

注意:
Siebelサービス・テストとWebトランザクション(ブラウザ)サービス・テストは同一のマシン上では再生できません。

29.4.5.4 OATSロード・スクリプトを使用したATSサービス・テストの作成

Oracle Application Test Suite(OATS)を使用して、Openscriptトランザクション・サービス・テストを定義できます。このテストを使用して、Openscriptロード・テスト・スクリプトを使用したビーコン・アプリケーション・トランザクションの監視を有効にできます。OpenscriptはOATSのコンポーネントで、web/HTTP、Oracle EBS/Forms、Oracle Fusion/ADF、Siebel, Adobe Flexなど、様々なタイプのWebトランザクションを記録および再生するための拡張機能を提供します。

ATSロード・スクリプトを使用して、次のことができます。

- アプリケーションのライフサイクル管理の一部として、本番アプリケーション・トランザクション監視用にATSテスト・スクリプトを再使用します。

- 次のことによりビーコンの機能が拡張されます。

- HTTPやOracle Formsアプリケーションなどのプロトコルやアプリケーション・タイプが1つのフローに混在する、複雑なアプリケーション・フローのサポート。

- Siebelアプリケーション監視に基づくプロトコルのサポート。

- データバンク・サポートの提供。

- Openscriptから拡張されたスクリプトおよびデバッグ機能の組込み。

- Enterprise Managerの更新なしでの最新のスクリプト・モジュールおよび機能の追加。

ATSサービス・テストの作成には、次の内容が含まれます。

- Openscriptをダウンロードするには、http://www.oracle.com/technetwork/oem/app-test/index-084446.htmlにアクセスしてください。

- インストーラを起動して、次の手順に従い、Openscriptをインストールします。

- 次の手順に従い、新しいATSトランザクション・スクリプトを記録します。

- Openscriptを起動し、「ファイル」メニューから「新規」を選択します。

- 作成するスクリプトのタイプを選択し、「次へ」をクリックします。作成できるスクリプト・タイプには、Adobe Flex、Oracle Fusion / ADF、Siebel、Database、Java Code Script、Web/HTTPなどがあります。

- スクリプトが保存される場所を選択し、スクリプト名を入力して、「終了」をクリックします。

- Viewメニューで、「OpenScriptプリファレンス」を選択して記録プリファレンスを設定します。

- レコード・カテゴリ、HTTPプリファレンスの順に選択します。「記録モード」を「Web」から「HTTP」に変更します。これによりスクリプトが正しく再生されます。

- 「スクリプト」メニューから「レコード」を選択します。記録を開始すると、ブラウザが自動的に開きます。

- 記録を開始するWebページをブラウザにロードします。ページ・オブジェクト、アクションおよびナビゲーションを記録するWebサイトにアクセスします。ページのナビゲーションが終了したら、ブラウザを閉じて、「停止」をクリックします。

- 「スクリプト」メニューで「再生」を選択し、スクリプトが適切に記録されたことを確認します。再生ペインに再生されているアプリケーション・フローを監視します。メッセージ・ログ・ペインにエラーや障害が発生していないことを確認します。スクリプトを保存します。

- スクリプトが記録されたら、「ファイル」メニューから「スクリプトのエクスポート」を選択します。

- スクリプトを保存する場所を指定します。スクリプトはレジストリまたはワークスペースに保存できます。

- スクリプトの名前を入力し、「終了」をクリックします。スクリプト・バンドル(.zip)が作成されます。スクリプト・バンドルは自己完結していることを確認してください。「自己完結Zipファイルの作成」を参照してください。

注意:
スクリプト・ファイルが非常に大きい場合、「記録されたデータ」オプションはオフにしてください。

- Enterprise Managerにログインし、スクリプト・バンドルをアップロードして、ATSサービス・テストを作成します。詳細は、「ATSサービス・テストの作成」を参照してください。

OATSの詳細は、Oracle® Functional Testing OpenScriptユーザーズ・ガイドを参照してください。

29.4.5.4.1 自己完結Zipファイルの作成

zipファイルは自己完結で、次の内容を含んでいることを確認する必要があります。

- <txn name>.jwg: 実行エンジンで実行される、コンパイル済の実行可能スクリプトを含むアーカイブ・ファイル。

- script.java: 実際のスクリプトJavaソース・ファイル。

- <script name>-descriptor.xml: ステップ階層を示す。

- script.xml: データバンクの変数を示す。

- modules.properties: エンジンに必要な内部モジュールを示す。

- Assets.xml: データバンク・ファイル、サブ・スクリプト・オブジェクト・ライブラリなどを含む、ルート・スクリプトにより使用される依存するリソースを示す。

- データバンク・ファイル: 様々な変数値の代入時にスクリプトにより使用されるデータバンク・ファイル。

- オブジェクト・ライブラリ: ユーザー定義のオブジェクト識別ルールおよび名前を含むライブラリ。これは機能テスト・スクリプトにのみ適用されます。

- 依存スクリプト: 他のスクリプトをコールできるスクリプト。

29.4.5.4.2 ATSサービス・テストの作成

ATSサービス・テストを作成するには、次の手順に従います。

注意:
コマンドライン・ユーティリティ(EM CLI)から、リポジトリで使用可能なサービス・テストを使用してATS Testインスタンスを作成し、カスタマイズする方法は、『Oracle Enterprise Managerライフサイクル管理ガイド』を参照してください。

1. 「ターゲット」メニューから「サービス」を選択し、「作成」メニューから「汎用サービス - テスト・ベース」を選択します。

2. サービスの名前を入力して、タイム・ゾーンを選択します。

3. 「次」をクリックします。汎用サービスの作成: 可用性ページで、「サービス・テスト」を選択します。

4. 「汎用サービスの作成: サービス・テスト」で、「ATSトランザクション」として「テスト・タイプ」を選択します。

5. サービス・テストの名前、説明、および収集頻度を入力します。

6. 「ATS Zipアーカイブ」リージョンで、ATS Zipアーカイブのインポート元を指定します。インポート元には次を指定できます。

- ローカル・マシンから: 「参照」をクリックし、アップロードするzipファイルをローカル・マシンから選択します。

- テスト・リポジトリから: テスト・リポジトリ内のzipファイルを選択し、「続行」をクリックします。詳細は、「テスト・リポジトリの使用」を参照してください。

「続行」をクリックします。アップロードされたzipファイルに基づいて、「ATS Zipアーカイブ」および「変数」セクションに移入されます。

7. ATSサービス・テスト・ページに戻り、次の内容を指定できます。

- 使用オプション: 必要な使用オプションを選択して、スクリプト変数値を構成できます。トランザクション中に記録された値またはデータバンクのいずれかを使用できます。データバンクは、同じスクリプトの複数の反復に対して様々な入力値を指定するためにATSスクリプトが参照できる外部CSVファイルです。たとえば、ログイン・スクリプトはlogin_credential.csvという名前のデータバンク・ファイルを使用して、反復のたびに異なるログイン資格証明を指定できます。
次のいずれかを選択できます。

- 記録した値の使用: トランザクションの再生時に、ビーコンはスクリプトの記録された値を使用します。

- EMテスト・プロパティの値の使用: データバンク列に値を指定できます。これらの値はスクリプトの再生中にビーコンにより使用されます。各変数に同じ値が使用される場合、これは有用です。変数がテスト・プロパティとして定義されている場合、その値はスクリプト・バンドルまたはデータバンク・ファイルを変更する必要がなく、容易に変更できます。

- すべてのデータバンク・レコードをループ: トランザクションの再生時に、ビーコンはスクリプトの各行を移動します。たとえば、最初の反復はすべてのデータバンクの最初の行を使用します。2番目の反復はデータの2行目を使用します(次も同様)。

- 暗号化パスワード: ATS Openscriptを構成しており、(Openscript表示ファイル、「OpenScriptプリファレンス」、「汎用」、「暗号化」を使用して)スクリプトデータを暗号化する場合は、スクリプトを作成するときにATS Openscriptで指定したものと同じ暗号化パスワードを入力し、ビーコンがスクリプトを適切に再生できるようにする必要があります。

- デフォルト再生オプション: ビーコンでATSスクリプトを再生するための、デフォルトの再生オプション。

- 追加再生オプション: 追加の再生オプションを指定する必要がある場合、ここで指定できます。

29.4.5.4.3 ATSサービス・テストの再生の問題のトラブルシューティング

ビーコンの領域割当てが枯渇すると、ビーコンがATSスクリプトに記録された値を再生できず、次のエラーが表示される場合があります。

ビーコンの同期化はエージェントに必要なファイルを転送しませんでした。エージェントのログを確認してください。ファイル <directory>

この問題に対処するには、emd.propertiesファイルのapplicationMetadataQuotaエージェント・プロパティに高い値を設定する必要があります。デフォルト値は500MBですが、大規模なファイルが複数アップロードされる場合はこの値を増やす必要があります。プロパティの値を変更したら、管理エージェントを再起動する必要があります。

注意:

- ATSファイルは/EMSTATE/sysman/ApplicationState/beaconディレクトリにあります。

- ファイルの命名規則: <Txn guid>_<beacon guid>.zip

- ATS関連のログ(gcagent.log、gcagent_error.log、emagent.nohup)は、EMSTATE/sysman/logフォルダにあります。

29.4.5.4.4 データバンクとパラメータ化の使用方法

記録されたスクリプト入力をパラメータ化し、データ駆動型テスティングを実行できます。パラメータ化できる入力の例には、ユーザー名、ログイン・ページでのパスワード、検索フィールドに入力されたデータ、記録されたナビゲーションまたはユーザー・アクションなどが含まれます。

スクリプト入力のパラメータ化にデータ・ソースとしてデータバンクを使用できます。データバンクは、スクリプト・パラメータに対する入力を指定する、1つ以上の外部カンマ区切り値(CSV)またはテキスト(TXT)ファイルです。複数のデータバンク・ファイルを1つのスクリプトにアタッチすることができ、ユーザーは、スクリプト再生中にOpenScriptでデータを割り当てる方法を指定できます。

external.csvファイルからデータ入力値を選択し、変数値にデータバンクからの値を入力できます。フィールド名は、ファイルの先頭行にカンマ区切り(スペースなし)で指定します。フィールド・データは、2行目以降にカンマ区切り(1行に1レコード、カンマ前後のスペースはなし)で指定します。次に例を示します。

FirstName,LastName,Mail,Phone
John,Smith,JohnS@company.com,x993
Mary,Ellen,MaryE@company.com,x742

データバンク・レコードを使用するには、次の手順に従います。

1. スクリプト・プロジェクトを開くか、作成します。

2. アセット・スクリプト・プロパティのスクリプトで使用するデータバンクを構成します。

3. データバンク・レコードを使用するスクリプト・ノードを選択します。

4. 「スクリプト」メニューを選択した後、「追加」サブメニューから「その他」を選択します。

5. 「一般」ノードを開いて、次のデータバンク・レコードの取得を選択します。「OK」をクリックします。

6. レコードを取得するデータバンク・ファイルを指定するデータバンクの別名avitekを選択します。

7. 「OK」をクリックします。「GetNextDatabankRecord:databank alias」ノードがスクリプトに追加されます。Javaコード・ビューでは、次に示すように、getDatabank("データバンクの別名").getNextDataBankRecord()メソッドがスクリプト・コードに追加されます。
getDatabank("avitek").getNextDatabankRecord();

スクリプトで使用するデータバンクを構成した後、データバンク・ファイルを特定のスクリプト・パラメータにマップできます。データバンク・フィールドをスクリプト・パラメータにマップするには、次の手順に従います。

1. [4] Oracle WebLogic ServerのMedical Record Sample Applicationスクリプト・ツリー・ノードを展開します。

2. usernameInputパラメータを右クリックして、「変数の置換」を選択します。変数の置換ウィンドウが開き、データバンクのフィールド名がリストされます。

3. 「ユーザー名」フィールドを選択し、「終了」をクリックします。パラメータ値は二重中カッコで囲まれたデータバンク変数{{db.avitek.Username,fred#@golf.com}}に変更されます。

4. passwordInputパラメータを右クリックして、「変数の置換」を選択します。変数の置換ウィンドウが開き、データバンクのフィールド名がリストされます。

5. 「パスワード」フィールドを選択し、「終了」をクリックします。パラメータ値は二重中カッコで囲まれたデータバンク変数{{db.avitek.Password,weblogic}}に変更されます。

6. スクリプトを保存します。

データバンクの設定の詳細は、Oracle® Functional Testing OpenScriptユーザーズ・ガイドを参照してください。

ビーコン固有のデータバンク・ファイルの追加

ビーコン固有のデータバンク・ファイルを追加するには、emcliコマンドupload_ats_test_databank_fileを使用します。このコマンドの形式は次のとおりです。

emcli upload_ats_test_databank_file -name=<service_name> -type=<service_type> -testname=<test_name> -testtype=<test_type> -databankAlias=<databank alias> -input_file=databank:<input_file> -beaconName=<beacon_name>

29.4.5.4.5 URLのパラメータ化

スクリプト内のURLに使用する変数を作成できます。スクリプトのベースURLを変更する必要がある場合、URLをパラメータ化すると、新しいURLを使用するようにスクリプトを短時間で再ベースライン化できます。

URLをパラメータ化するには、次の手順に従います。

1. スクリプトを記録したら、「ツール」メニューから「URLのパラメータ化」を選択します。

2. パラメータ化するURLを選択し、そのURLに使用する変数の名前を入力します。「次」をクリックします。

3. 変更するURLのインスタンスを指定するチェック・ボックスを選択するか、または選択を解除します。「終了」をクリックします。

4. Javaコード・ビューで、次に示すように、getVariables().set("variable name", "value",scope);メソッドがinitialize()セクションのスクリプト・コードに追加されます。

getVariables().set("myServerVar", "http://myServer.com",
Variables.Scope.GLOBAL);

5. スクリプトの他のURLをパラメータ化するには、これらの手順を繰り返します。

29.4.5.4.6 成功または失敗の検証

TreeViewおよびCodeViewからテキスト一致を実行できます。たとえば、Googleの検索ウィンドウで文字列「hello」を入力した場合、テキスト一致は次のようになります。

web.document("/web:window[@index='0' or @title='Google']/web:document[@index='0']").assertText("MatchText", "hello", Source.DisplayContent, TextPresence.PassIfPresent, MatchOption.Exact);

Source - enum - (Html,Display Content)

Html - Raw Html including Tags

Display Content - Html without tags

MatchOption - Not Case Sensitive

- Exact - sensitive: ソース文字列の任意の部分に一致。たとえば、入力されたテキストがabcdefの場合、abcと入力すると、文字列は一致します。

- ExactEntireString: 正確なソース文字列と一致。

- RegEx - Not Case Sensitive: ソース文字列およびサブ文字列に一致。たとえば、入力されたテキストがabcdefの場合、a.*dと入力できます。

- RegExEntireString: ソース文字列全体にのみ一致。たとえば、入力されたテキストがabcdefの場合、a.*fと入力できます。

- Wildcard - wildcard pattern: ソース文字列およびサブ文字列に一致。たとえば、入力されたテキストがabcdefghijklmの場合、a?c*fと入力できます。

- WildcardEntireString: ソース文字列全体に一致。たとえば、入力されたテキストがabcdefghijklmの場合、a*mと入力できます。

29.4.5.4.7 ビーコンのオーバーライドの使用

ビーコンのオーバーライド機能を使用して、異なるビーコンで実行しているテスト用に異なる変数値を指定できます。次の手順を実行します。

1. スクリプトをデータバンク化します。

2. EMテスト・プロパティの使用オプションを選択します。

3. 次のように、sensitiveまたはnon-sensitiveの値を指定してビーコンを定義します。

Databank_Alias>."<COLUMN_NAME>"="VALUE",<Databank_Alias>."<COLUMN_NAME>"="VALUE",...

次に例を示します。

FusionCredentials."host"="fs-aufsn4x0cxf",FusionCredentials."hostlogin"="login-aufsn4x0cxf",FusionCredentials."username"="faadmin",FusionCredentials."password"="fusionfa1"

29.4.5.4.8 データバンク・ファイルの更新

ATSテスト・スクリプトを更新するには、次の手順に従います。

1. 「汎用サービス」メニューで、「管理」、「サービス・テストとビーコン」の順に選択します。

2. 「サービス・テスト」表で、「ATSトランザクション」テスト・タイプを選択し、「編集」をクリックします。

3. 「ATS Zipアーカイブ」リージョンで、「ダウンロード」をクリックします。ダウンロードされる場所を選択して「OK」をクリックします。

4. .csvファイルをスプレッドシート・エディタを使用して編集し、変更内容を保存します。

5. Enterprise Managerにログインし、ATSトランザクション・テスト・ページにナビゲートします。

6. 「ATS Zipアーカイブ」リージョンで、「アップロード」をクリックして、更新されたファイルをアップロードします。

29.4.5.4.9 RUEI統合用のSLMヘッダーの使用

ATSサービスのRUEIにより監視される場合、x-oracle-slm-message-idリクエスト・ヘッダーをAdditional Playback Optionsフィールドに指定する必要があります。その書式はname1:value1;name2:value2;name3:value3です。

たとえば、x-oracle-slm-message-id: bcn=<beacon_name>; svc=<service_name>;test=<test_name>;step={{@getTopLevelStepName())}}のようになります。

29.4.6 パフォーマンス・メトリック

パフォーマンス・メトリックは、サービスのパフォーマンスの測定に使用されます。サービス・テストが、このサービスに対して定義されている場合、そのサービス・テストの実行の結果行われるレスポンス時間の測定値が、サービスのパフォーマンス・メトリックの基準として使用されます。もう1つの方法として、基礎となるシステム・コンポーネントからのパフォーマンス・メトリックを使用してサービスのパフォーマンスを判断できます。

パフォーマンス・メトリックは、各リモート・ビーコンに対してサービス・テストがどの程度適切に実行されているかの判別に役立ちます。一般に、ローカル・ビーコンは、Webアプリケーション・ホストに対してローカルなので、非常に有効で一貫したレスポンス時間を備えています。リモート・ビーコンは、アプリケーションのエンドユーザーの実際のレスポンス時間を反映したデータを提供します。

次の内容を実行できます。

- サービス・テスト用のパフォーマンス・メトリックを追加できます。メトリックを選択後、次の内容を選択できます。

- 1つのビーコンからのメトリック値を使用します。サービスのパフォーマンスがある特定の場所のパフォーマンスに基づくようにする場合に、このオプションを選択します。

- 複数のビーコン間のメトリックを集計します。複数の場所のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、次の中から適切な集計関数を選択する必要があります。

表29-1 ビーコン集計関数

関数

説明

Maximum

すべてのビーコン間で集計されたデータからのメトリックの最大値が使用されます。すべてのビーコン間で最もパフォーマンスの低いものを測定するには、この関数を使用します。

Minimum

すべてのビーコン間で集計されたデータからのメトリックの最小値が使用されます。すべてのビーコン間で最もパフォーマンスの高いものを測定するには、この関数を使用します。

Average

メトリックの平均値が使用されます。すべてのビーコン間で平均的なパフォーマンスを測定する場合に、この関数を使用します。

Sum

メトリック値の合計が計算されます。各ビーコン間のすべてのレスポンス時間の合計を計算する場合に、この関数を使用します。

注意:
Webトランザクションを構成する場合、ソース(トランザクション、ステップ・グループまたはステップ)を指定できます。この選択に基づいて、追加するメトリックが、トランザクション、ステップ・グループまたはステップのレベルで適用可能になります。

- サービスをホストする基礎となるシステム・コンポーネントのパフォーマンス・メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。

- 特定のコンポーネントからメトリックを使用します。サービスのパフォーマンスがある特定のシステム・コンポーネントのパフォーマンスに基づくようにする場合に、このオプションを選択します。このオプションを選択すると、「ルール・ベース・ターゲット・リスト」を選択できます。

- 複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、適切な集計関数を選択する必要があります。

表29-2 システム集計関数

関数

説明

Maximum

すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。

Minimum

すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。

Average

すべてのコンポーネント間のメトリックの平均値が使用されます。

Sum

すべてのコンポーネント間のメトリックの値の合計が計算されます。

注意:
システムが削除されると、そのシステムに関連付けられているパフォーマンス・メトリックは収集されません。

- 定義済のパフォーマンス・メトリックを編集します。サービス・テストベースのパフォーマンス・メトリックの場合は、メトリック値の計算に使用されるビーコン関数を変更できます。システムベースのパフォーマンス・メトリックの場合は、ターゲット・タイプ、メトリック、および集計関数を使用するかどうかの設定を変更できます。また、メトリックのクリティカルしきい値および警告しきい値も変更できます。

- 定義済のパフォーマンス・メトリックを削除します。

注意:
集約サービスにパフォーマンス・メトリックを定義すると、次の操作が可能です。

- 単一のサブ・サービスからのパフォーマンス・メトリックを追加します。

- 複数のメトリックの統計による集計を指定します。

メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。

29.4.6.1 ルール・ベース・ターゲット・リスト

ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。

- すべて(すべてのシステム・コンポーネント)

- 次を含む(指定された基準を含む任意のコンポーネント)

- 次で始まる(指定された基準で始まる任意のシステム・コンポーネント)

- 次で終わる(指定された基準で終わる任意のシステム・コンポーネント)

- 次と等しい(指定された基準に一致する任意のシステム・コンポーネント)

29.4.6.2 静的ベースのターゲット・リスト

この場合、選択される依存ターゲットがメトリック評価に参加し、選択されないターゲットは含まれません。

29.4.7 使用状況メトリック

使用状況メトリックは、サービスに対するユーザーの要求の測定に使用されます。使用状況メトリックは、サービスをホストする基礎となるシステム・コンポーネントの使用状況に基づいて収集されます。特定のコンポーネントの使用状況を監視することも、一連のコンポーネントの平均値、最小値および最大値を統計的に計算することも可能です。たとえば、IMAPサーバーに依存する電子メール・サービスを定義する場合、IMAPサーバーの「合計クライアント接続」メトリックを使用して、この電子メール・サービスの使用状況を表すことができます。使用状況メトリックは、システムと関連付けられたサービスに対してのみ定義できます。次の内容を実行できます。

- 使用状況メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。

- 特定のコンポーネントからメトリックを使用します。特定のコンポーネントの使用状況を監視する場合に、このオプションを使用します。

- 複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間の使用状況の統計を計算する場合に、このオプションを使用します。このオプションを選択した場合、適切な集計関数を選択する必要があります。

表29-3 集計関数 - 使用状況メトリック

関数

説明

Maximum

すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。

Minimum

すべてのコンポーネント間のメトリックの最小値が、サービスの使用状況メトリック値として使用されます。

Average

すべてのコンポーネント間のメトリックの平均値が使用されます。

Sum

すべてのコンポーネント間のメトリックの値の合計が計算されます。

- 定義済の使用状況メトリックを編集します。

- 定義済の使用状況メトリックを削除します。

システム・ターゲットからのメトリックのみを使用状況メトリックとして追加できることに注意してください。テストからのメトリックは使用状況を示さないため、使用状況メトリックとして追加できません。

注意:
集約サービスに使用状況メトリックを定義すると、次の操作が可能です。

- 単一のサブ・サービスからの使用状況メトリックを追加します。

- 複数のメトリックの統計による集計を指定します。

使用状況メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。

ルール・ベース・ターゲット・リスト

ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。これにより、評価のパフォーマンス・メトリックを促進できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。

- すべて(すべてのシステム・コンポーネント)

- 次を含む(指定された基準を含む任意のコンポーネント)

- 次で始まる(指定された基準で始まる任意のシステム・コンポーネント)

- 次で終わる(指定された基準で終わる任意のシステム・コンポーネント)

- 次と等しい(指定された基準に一致する任意のシステム・コンポーネント)

29.5 トランザクション・レコーダの使用

一連のユーザー処理およびナビゲーション・パスを自動的に記録する直感的な再生レコーダを使用して、トランザクションを記録できます。トランザクションを相互に再生し、データ・センターの内部または外部のいずれに存在するかを確認し、Webアプリケーションのすべての層におけるレスポンス時間の発生の詳細を理解して素早く診断できます。

トランザクションを記録するには、コンピュータにトランザクション・レコーダをインストールする必要があります。トランザクション・レコーダは、トランザクションの再生およびトレースにも使用されます。トランザクション・レコーダは、これらの処理の初回実行時にEnterprise Manager Grid Controlサーバーからダウンロードされます。トランザクション・レコーダを使用するには、コンピュータにいくつかのMicrosoftライブラリがインストールされている必要があります。インストール中にこれらのライブラリが存在しない場合、Microsoftのサイトから自動的にダウンロードおよびインストールが行われます。これらのファイルをダウンロードするには、ご使用のコンピュータがインターネットにアクセスできることを確認します。インストールの完了後、変更を適用するには、コンピュータを再起動する必要がある場合があります。

29.6 サービス・レベル合意の設定および使用

サービス・レベル合意(SLA)は、指定した期間における予測されるサービス品質に関する、サービス・プロバイダと顧客との間の契約です。SLAは、異なるビジネス・カレンダおよび異なるサービス期間用に、提供するサービス・レベルを定義する、1つまたは複数のサービス・レベル・オブジェクト(SLO)で構成されます。SLAを満たしているかどうかは、基礎となるSLOの評価に基づきます。サービス・レベル・インジケータ(SLI)は、SLOを測定および定量化できます。SLOには、1つ以上のSLIを使用できます。

SLOは提供されるサービス・レベルの目標を定義します。SLOは想定可能な個別のサービス・レベル・インジケータ(SLI)の論理グループです。たとえば、SLOはユーザーがサービスを使用可能な時間の割合や、応答時間またはボリュームを単位としてサービスがどの程度実行されているかなどを定義できます。サービス・レベル・インジケータ(SLI)は、定量化可能なパフォーマンスおよび使用状況メトリックで、サービスの品質を評価するのに使用できます。

SLAを作成するには、次の手順に従います。

1. EM_ADMINISTRATORロールを持つユーザーでEnterprise Managerにログインします。

2. 「ターゲット」メニューから「サービス」を選択します。

3. リストで「汎用サービス」ターゲットをクリックします。「サービス・ホーム」ページが表示されます。

4. 「汎用サービス」メニューで、「サービス・レベル合意」、「構成」の順に選択します。サービス・レベル合意構成ページが表示されます。

5. このページには、選択したサービスに対して定義されたすべてのSLAのリストが表示されます。このリストからSLAを選択し、「サービス・レベル合意の詳細」表に詳細を表示します。SLAを作成することも、既存のSLAのコピーを作成(Create Like)することもできます。

6. 「サービス・レベル合意」リージョンで、「作成」をクリックします。サービス・レベル合意ページが表示されます。

図29-3 サービス・レベル合意の作成: サービス・レベル合意の構成

次の詳細を入力します。

- SLAの名前と説明。

- SLAが作成されている顧客の名前。

- SLAのライフサイクル・ステータス。SLAの作成中は、定義ステージング内に存在します。ライフサイクル・ステータスの詳細は、「SLAのライフサイクル」を参照してください。

- 「SLA期間」を指定します。これは、SLAがコンプライアンスに対して決定および評価される契約上の期間です(四半期、月次、週次SLAなど)。「選択」アイコンをクリックして、「毎月」、「毎週」、または「毎日」を選択します。SLAが評価される頻度と、SLAが評価される元のデータを入力します。SLAが評価されると、SLAの目標はリセットされます。
たとえば、SLAの評価期間を「毎月」に、「頻度」を12に、日付を09/01/12に指定した場合、SLAはその日に評価され、その後、連続して11回(10月、11月、というように)評価されます。

- SLA合意期間を指定します。これは繰り返しSLAが有効な期間の、「開始」および「終了日」です。ここで「終了日」を指定しないと、SLAの有効期限は「無期限」になります。

- SLOはサービスにスケジュールされた計画停止またはブラックアウトのため、評価されないときがあります。「サービス・レベル合意の評価オプション」リージョンで、「サービス・レベル目標値評価にブラックアウト時間(計画ダウンタイム)を含める」チェック・ボックスを選択し、ブラックアウト時間をSLO評価に含めるかどうかを指定します。次のいずれかを選択できます。

- 満たす条件として時間を含める

- 満たさない条件として時間を含める

- SLOの全体の計算で、ブラックアウト時間を除外します。

たとえば、1週間のうちブラックアウトまたは計画停止が1日の場合、週の可用性は(7-1) / (7-1)日で、これは依然として100%の可用性です。

デフォルトでは、「サービス・レベル目標値評価にブラックアウト時間(計画ダウンタイム)を含める」オプションは選択されていません。

7. 「次」をクリックします。サービス・レベル目標値ページで、SLAの一部として、1つ以上のSLOを定義します。SLAの「評価条件」を次のように選択できます。

- すべてのサービス・レベル目標値を満たす必要があります

- 1つ以上のサービス・レベル目標値を満たす必要があります

SLAには1つ以上のSLOが必要です。一度に複数のSLOをアクティブにできます。すべてのSLOを満たす必要がある、または1つ以上のSLOを満たす必要があるかのいずれかを指定できます。

8. 「作成」をクリックして、新しいSLOを定義します。詳細は、「サービス・レベル目標の作成」を参照してください。

9. SLOを追加、または定義済のSLOを編集できます。「次」をクリックします。サービス・レベル合意の有効化ページで、SLAが有効化されるときを指定できます。次のいずれかを選択できます。

- 有効にしない: 有効化されていないSLAは定義状態であり、必要に応じて変更できます。

- すぐに有効化: 有効化されているSLAはアクティブ状態なので変更できません。

- 後で有効化: SLAは指定した日に、後で変更できます。

10. 「次へ」をクリックして、SLAの詳細を確認し、「発行」をクリックします。SLAが指定した日に有効化され、サービス・レベル合意構成ページに戻ります。

29.6.1 SLAのアクション可能なアイテム・ルール

次の表に、SLAでその状態に基づき実行できるアクションのリストを示します。

SLAの状態

類似作成

編集

有効化

無効化

削除

定義

はい

はい

はい

いいえ

はい

スケジュール

はい

はい

いいえ

はい

いいえ

アクティブ

はい

いいえ

いいえ

はい

いいえ

撤収

はい

いいえ

いいえ

いいえ

はい

- 状態が「スケジュール済」または「アクティブ」のSLAは直接削除できません。削除する前にSLAを無効化する必要があります。

- 「スケジュール済」状態のSLAを編集するときは、SLAの状態は「定義」に変わります。

29.6.2 サービス・レベル目標の作成

サービス・レベル目標では、指定した測定ウィンドウに対する1つ以上のインジケータのサービス・レベルを測定します。サービス・レベル目標(SLO)は提供されるサービス・レベルを定義します。SLAが満たしているとみなす条件を指定できます。

- すべてのサービス・レベル目標値を満たしている。

- 1つ以上のサービス・レベル目標値を満たしている。

SLOを作成するには、次の手順に従います。

1. サービス・レベル目標値の構成ページで「作成」をクリックします。サービス・レベル目標値の作成ページが表示されます。

図29-4 サービス・レベル目標値の作成

2. 次の詳細を入力します。

- 定義されるSLOの名前。

- SLOのタイプ: SLOは可用性またはパフォーマンス・メトリックに基づくことができます。

- 予測されるサービス・レベル(%): SLAが満たされていることを保証する、SLO条件が満たす時間の割合。

- 警告アラート・レベル(%): SLO条件が指定したしきい値を満たしていない場合、クリティカル・アラートが生成されます。
たとえば、「予測されるサービス・レベル(%)」が90%で、「実際のサービス・レベル(%)」が90から99%の範囲の場合、警告アラートが生成されます。「実際のサービス・レベル(%)」が90%より下の場合、クリティカル・アラートが生成されます。これはSLAが違反していることを示します。「実際のサービス・レベル(%)」が99%より上の場合、SLA条件は十分満たされていることを示します。

- 測定ウィンドウ: SLOが有効な期間。測定ウィンドウには複数の期間を割り当てることができます。たとえば、測定ウィンドウを、月曜日から金曜日の午前9時から午後6時までを平日のピーク時間として、週末のピーク時間を午前10時から午後2時として構成することができます。
SLOの作成時に、SLO用に複数のビジネス・カレンダを選択できます。たとえば、各SLOを午前8時から午後5時まで昼食時間(正午から午後1時)を除いて評価するとします。2つの測定ウィンドウを作成し、測定対象から昼食時間を除くことができます。

2つの測定ウィンドウをマージする別の例は、カレンダ評価を使用して週次評価を結合する場合です。SLOを毎週月曜日と毎月の15日に評価する場合、2つの監視ウィンドウを作成し、両方のウィンドウにその条件を含めることができます。

デフォルトでは、3つの事前定義済のビジネス・カレンダがあります。さらに、独自のカレンダを作成することもできます。詳細は「カスタムSLAビジネス・カレンダの定義」を参照してください。

3. 「次」をクリックします。サービス・レベル・インジケータの作成ページで、SLOを測定できるようにする、1つ以上のSLIまたは条件を追加できます。

図29-5 サービス・レベル・インジケータの作成

たとえば、パフォーマンスSLIを追加している場合、ページ・リード時間が3秒以下である必要があると指定できます。この条件が満たされないと、SLIは違反しているとみなされます。SLIの評価条件を指定します。

- すべてのサービス・レベル・インジケータを満たす必要があります

- 1つ以上のサービス・レベル・インジケータを満たす必要があります。

4. 「追加」をクリックして、1つ以上のメトリックを追加し、値と評価条件を指定します。「発行」をクリックして、サービス・レベル目標値の構成ページに戻ります。

29.6.3 SLAのライフサイクル

次の図に、SLAのライフサイクルを示します。

図29-6 SLAのライフサイクル

SLAのライフサイクルは、次のフェーズで構成されます。

- 定義: SLAが作成されSLOが定義されるステージです。SLAがアクティブ化されるまでSLA定義を構成または編集できます。

- スケジュール済: このステージはSLAが将来の日付に有効化されるようにスケジュールされる前の期間を表します。

- アクティブ: スケジュール済SLAの開始日に達する、またはSLAが手動で有効化されるステージです。

- 撤収: SLAが有効期限に達する、またはSLAが手動で無効化されるステージです。

- 無効: SLAが有効期限に達する前に、手動で無効化できます。SLAを一度無効化すると、再度有効にすることができなくなります。「類似作成」オプションを使用して類似のSLAを作成し、有効化する必要があります。

- 期限切れ: SLAが有効期限に達した、またはすでにアクティブでないステージです。

- 削除済: 定義または撤収ステージのSLAは削除できます。「アクティブ」または「スケジュール済」ステージのSLAは削除できません。

29.6.4 サービスのSLAのステータスの表示

サービスのすべてのSLAのステータスを表示できます。サービスのSLAの現在のステータスを表示するには、次の手順に従います。

1. 「ターゲット」メニューから「サービス」を選択します。

2. リストで「汎用サービス」ターゲットをクリックします。「サービス・ホーム」ページが表示されます。

3. 「汎用サービス」メニューで、「サービス・レベル合意」、「現在のステータス」の順に選択します。サービス・レベル合意の現在のステータス・ページが表示されます。

4. このページには、このサービスに定義されたすべてのアクティブなSLAのリストが表示されます。SLAごとに、SLAのステータス、SLA評価期間、およびサービス・レベル目標が表示されます。

5. SLA内の詳細な情報を表示するSLAを選択します。次の詳細が表示されます。

- ステータスのトラッキング: これはSLIの瞬時のステータスです。可用性SLOの場合、これはターゲットのステータスです。パフォーマンスSLOの場合、特定の時点のパフォーマンスまたは使用状況メトリックの値です。

- サービス・レベル(%): SLO条件を満たすか、または「ステータスのトラッキング」がtrueの時間(現在の評価期間の最初から現在の日付まで)の割合。「実際のサービス・レベル(%)」が「予測されるサービス・レベル(%)」よりも低い場合、またはSLO条件を満たしている場合、「サービス・レベル%」グラフは緑色です。

- タイプ: SLAに対して定義されたSLOのタイプ。これは可用性またはパフォーマンス・メトリックに基づくことができます。可用性SLOは、レスポンス・メトリック[サービス・ターゲット可用性]に基づきます。可用性の目標を満たす必要のあるときの時間の割合または量の形で指定します。パフォーマンスSLOはサービスがどれくらい効率的に実行されているかを測定します。スループットまたはワークロードといった速さおよびボリューム(応答時間、トランザクション/時など)の測定が含まれます。SLOパフォーマンスは、SLIのセット、SLO条件、および可用性の目標を満たす必要のあるときの時間の割合または量のいずれかの形で指定します。

- SLO違反: 各SLA評価期間の許容違反。

- 合計: 評価期間 * (予測されるサービス・レベル)の期間。

- 実績: 評価期間中にSLOが満たされない時間。

- 残り: SLAの違反なしでSLOを満たすことができない時間。SLOが評価期間中、常に満たされている場合は、使用される許容がなく、「実績」フィールドの値は0になります。

29.6.5 カスタムSLAビジネス・カレンダの定義

ビジネス・カレンダは、サービス・レベル目標値(SLO)を測定する特定の期間を定義する測定ウィンドウです。すぐに使用できる事前定義済のビジネス・カレンダが用意されています。それとは別に、カスタムのビジネス・カレンダを作成できます。カスタムのビジネス・カレンダを作成するには、「ターゲット」メニューから「サービス」を選択します。「サービス機能」メニューから、「ビジネス・カレンダ」を選択します。

定義されたビジネス・カレンダのリストは、ここに表示されます。次の操作を実行できます。

- 作成: 「作成」をクリックして、ビジネス・カレンダを設定します。ビジネス・カレンダの追加/編集ページが表示されます。

- 類似作成: カレンダを選択し、「類似作成」をクリックして、このカレンダのコピーを作成します。

- 編集: カレンダを選択し、「編集」をクリックし、ビジネス・カレンダの追加/編集ページで必要な変更を行います。

- 削除: カレンダを選択し、「削除」をクリックして削除します。1つ以上のSLAに関連するビジネス・カレンダは編集または削除できません。

- 関連するサービス・レベル合意の表示: 1つ以上のSLAは、ビジネス・カレンダを使用できます。ビジネス・カレンダを選択し、「関連するサービス・レベル合意の表示」をクリックして、このカレンダに関連付けられているSLAを表示します。

29.7 サービス・ダッシュボードの使用

サービス・ダッシュボードによって、すべてのサービス関連の情報の簡単なサマリーが、1つの場所に提供されます。可用性、パフォーマンス、サービスに関連するSLA、キー・システム・コンポーネントのステータスなどのサービスの重要な側面を統合して表示します。

29.7.1 すべてのダッシュボード・ページの表示

すべてのダッシュボード・ページを表示するには、次の手順に従います。

1. 「ターゲット」メニューから「サービス」を選択します。

2. 「サービス機能」メニューから、「ダッシュボード」を選択します。

3. すべてのダッシュボード・ページが表示され、作成されたすべてのダッシュボードのリストが表示されます。

4. すべてのダッシュボード・ページで、次の操作を実行できます。

- ダッシュボードの作成: 「ダッシュボード名」フィールドに一意の名前を入力し、「ダッシュボードの作成」をクリックします。新しく追加されたダッシュボードが表に表示されます。ダッシュボードを作成するには、「サービス・ダッシュボードの作成」権限のあるEM_ADMINISTRATORロールが必要です。

- ダッシュボードのカスタマイズ: リストからダッシュボードを選択し、「カスタマイズ」をクリックし、サービス・ダッシュボードの編集ページで変更を行います。ダッシュボードは、作成したユーザーのみがカスタマイズできます。

- 削除: リストからダッシュボードを選択し、「削除」をクリックします。選択したダッシュボードが削除されます。ダッシュボードは、作成したユーザーのみが削除できます。

5. 「ダッシュボード名」リンクをクリックし、ダッシュボードの詳細ページにドリルダウンします。

29.7.2 ダッシュボードの詳細ページの表示

このページには次の詳細が表示されます。

- サービス名: リンクをクリックして、サービスの詳細ページにドリルダウンします。

- インシデント: 発生したインシデント。

- パフォーマンス/使用状況メトリック: サービスで使用可能なパフォーマンスおよび使用状況メトリックの名前、各メトリックの最新値が表示されます。傾向グラフは過去24時間のメトリックの傾向を示します。傾向グラフをクリックして、傾向を詳細に表示します。

- SLA: アクティブ、クリティカルまたは警告状態にある有効化されたSLAの数を示します。

- キー・コンポーネント: このサービスに対して使用可能または稼働中のキー・ターゲットを表示します。

- システム・インシデント: サービスの基礎となるシステムに発生したインシデントが表示されます。

図29-7 サービス・ダッシュボード

ダッシュボードにリストするサービスをフィルタできます。「フィルタ条件」に値を指定して「フィルタ」をクリックします。フィルタはすべてのサービスの各行に適用され、結果リストが表示されます。

1つ以上の電子メール・アドレスにダッシュボードを電子メール送信できます。「電子メール」をクリックして電子メール・アドレスとダッシュボードの件名を入力します。「送信」をクリックします。この機能はhtttpモードでのみ動作します。

29.7.3 ダッシュボードのカスタマイズおよびパーソナライズ

ダッシュボードをカスタマイズし、その変更をすべてのユーザーが使用できるようにできます。ダッシュボードをカスタマイズするには、「すべてのダッシュボード」ページで行を選択し、「カスタマイズ」をクリックします。

注意:
crには、次の権限が必要です。

1つ以上のサービスをダッシュボードに追加するには、レンチ・アイコンをクリックします。コンポーネント・プロパティ: サービス・ダッシュボード・ウィンドウが表示されます。ダッシュボードに追加するサービスのタイプを選択し、「検索」をクリックします。「使用可能なターゲット」表に、サービスのリストが表示されます。追加する1つ以上のサービスを選択し、それらを「選択したターゲット」表に移動して、「適用」をクリックします。各サービスにメトリックを追加するには、「メトリック」タブをクリックし、メトリックを追加する各サービスを選択して、「OK」をクリックします。選択したサービスおよびメトリックが、「サービス・ダッシュボード」表に表示されるようになります。

サービス・ターゲットをダッシュボードから削除するには、行を選択してレンチ・アイコンをクリックします。コンポーネント・プロパティ: サービス・ダッシュボード・ウィンドウが表示されます。ダッシュボードから削除するサービスおよびメトリックの選択を解除し、「適用」をクリックして、「OK」をクリックします。ダッシュボードに行った変更をリセットするには、ページのリセットをクリックします。ダッシュボードに行われた変更は完全に削除されます。「閉じる」をクリックして「編集」モードを終了します。

要件に合うように、ダッシュボードに特定の変更を行うことができます。「パーソナライズ」アイコンをクリックして、ダッシュボードに対する1つ以上のサービスの追加または削除を行います。変更内容を参照できるのは、それを行ったユーザーのみで、他のユーザーは変更内容を参照できません。

29.7.4 ダッシュボード・サービスの詳細ページの表示

このページには、選択したサービスの詳細情報が表示されます。

図29-8 ダッシュボードの詳細ページ

次のタブがあります。

- 概要: このタブは選択したサービスの概要を示します。「サービス」リンクをクリックし、サービス・ホーム・ページにドリルダウンします。次のリージョンがあります。

- 一般: このリージョンには、サービスの名前、ステータス、サービスが使用可能になった日付、可用性割合、サービスのタイプ(テスト・ベースまたはシステム・ベース)、停止時間、およびエラー時間が表示されます。サービス名をクリックし、サービス・ホーム・ページにドリルダウンします。

- コンポーネントの可用性: このリージョンには、サービスでのコンポーネントのステータスが表示されます。コンポーネントのステータス、およびサービスが起動した日付が表示されます。キー・サービス・テストのみを表示するには、「キー・テストのみを表示」チェック・ボックスを選択します。

- SLA: このサービスで有効になっているSLAのリストが表示されます。名前、ステータス、およびSLAが適用可能になった日付が表示されます。過去7日間のSLA履歴も表示されます。

- メトリック: このタブには、このサービスに定義されたパフォーマンスおよびメトリックのチャートが表示されます。サービスと、サービスの基礎となるシステムに発生したインシデントも表示されます。

29.8 テスト・リポジトリの使用

テスト・リポジトリは、すべてのテスト・スクリプトを保持できる一元的な場所です。テスト・リポジトリを使用するには、事前に構成されたOMSソフトウェア・ライブラリの場所を指定する必要があります。詳細は、22.7項を参照してください。

テスト・リポジトリを使用する利点は次のとおりです。

- 以前は、テストはサービスのコンテキストでのみ作成できました。これに対し、現在は、サービスのコンテキスト外で任意の数のテスト・スクリプトを作成し、テスト・リポジトリと呼ばれる一元的な場所に保存するなど、柔軟に対応できるようになりました。テスト・スクリプトのアップロードおよびサービスの作成は、独立したイベントになりました。テスト・スクリプトがリポジトリで使用可能になると、サービスの作成中に使用できます。

- 以前は、テスト・スクリプトの所有者のみがスクリプトのコピーを所有していました。現在は、テスト・リポジトリの導入により、スクリプトが一元的な場所に保持され、すべてのユーザーがスクリプトにアクセスできます。サービスの作成時に、ボタンをクリックするだけで、リポジトリからスクリプトをインポートできるため、ユーザーフレンドリですばやい操作が可能になりました。

注意:
現在、ATSテスト・スクリプトは中央リポジトリに格納できます。

29.8.1 テスト・リポジトリの表示

テスト・リポジトリにアップロードされたテスト・スクリプトを表示するには、次の手順に従います。

1. 「ターゲット」メニューから「サービス」を選択します。

2. 「サービス機能」メニューから、「リポジトリのテスト」を選択します。

3. 「リポジトリのテスト」ページに、作成したすべてのテストの一覧が表示されます。

4. 「リポジトリのテスト」ページから、次の操作を実行できます。

- テストの作成: 次のタイプのテストを作成できます。

- ATSテスト: 「作成」をクリックします。「テスト情報」セクションで、「タイプ」ドロップダウン・リストの「ATSトランザクション」を選択し、一意のテスト名と説明を入力します。ATS情報セクションで、「参照」.をクリックして、ローカル・マシンからテスト・スクリプトをアップロードします。関連するファイルを選択すると、ファイル名がステップおよびモジュールの詳細とともに表示されます。「保存」をクリックして、スクリプトを保存します。

- テストの編集: テストクリックして、「編集」をクリックします。次のタイプのテストを編集できます。

- ATSスクリプトはEnterprise Managerコンソール内では変更できません。ただし、前にアップロードしたスクリプトをダウンロードし、zipファイルをATS OpenScriptにインポートできます。ATSスクリプトのダウンロード方法および編集方法は、第29.8.2項を参照してください。

- テストの削除: テストを選択して、「削除」をクリックすると、テスト・スクリプトが削除されます。

- テストの表示: テスト名をクリックすると、テストの詳細が「テストの詳細」表に表示されます。

29.8.2 ATSスクリプトの編集

スクリプト・バンドルをダウンロードして編集するには、次の手順に従います。

- 「ダウンロード」をクリックして、指示に従ってzipファイルを保存します。

- OpenScriptを起動し、「ファイル」メニューから「スクリプトのインポート」を選択して、zipファイルをATS OpenScriptにインポートします。

- ATS OpenScriptでスクリプトを編集したら、「ファイル」を選択し、「スクリプトのエクスポート」を選択して、新規スクリプトをエクスポートし、zipファイルを保存します。

- Cloud Controlにログインし、ATSサービス・テスト・ページにナビゲートします。「アップロード」をクリックし、更新済のスクリプト・ファイルをEnterprise Managerにアップロードします。

29.9 サービス・レベルの設定

サービス・レベル・ルールは、サービスの品質の判断に使用される評価基準として定義されます。これにより、サービス・レベル合意で定義されているように、営業時間中にサービスが満たす必要がある可用性およびパフォーマンス基準を指定できます。たとえば、電子メール・サービスは、月曜から金曜の午前8時から午後8時までは99.99%使用可能である必要があります。

サービス・レベル・ルールは、サービスがサービス・レベル・ルールで定義されているパフォーマンスおよび可用性基準を満たしている時間の割合を指定します。デフォルトでは、規定された営業時間の85%の期間、指定された基準を満たしていることが期待されます。サービスの期待度に応じて、この割合のレベルを上下できます。サービス・レベル・ルールは次の要素に基づいています。

- 営業時間: サービス・レベルがサービス・レベル合意の指定に基づいて計算される時間範囲です。

- 可用性: サービスがどのような場合に使用可能であるとみなされるかを指定できます。これは、サービス・レベルの計算のみに影響し、コンソールに表示される実際の可用性状態には影響しません。サービスが次の1つ以上の状態である場合に、サービスが使用可能であるとみなされるように選択できます。

- 稼働中: デフォルトでは、サービスは「稼働中」または使用可能であるとみなされます。

- ブラックアウト中: このオプションにより、サービスのブラックアウト時間(サービスが技術的に使用不可であることを示す計画アクティビティ)を使用可能なサービス時間として指定できます。

- 不明: このオプションにより、管理エージェントが使用不可であるためにサービスが監視されない時間を、使用可能なサービス時間として指定できます。

- パフォーマンス基準: オプションで、サービスのパフォーマンスが低下している場合に、サービス・レベル違反に指定できます。たとえば、Webサイトが稼働している場合でも、1ページのロードに10秒かかる場合、サービスは使用不可であるとみなされる可能性があります。

- ビジネス基準: ビジネス基準は、特定のサービスのビジネス・プロセスの状態を判断するのに役立ちます。必要に応じて、サービス・レベルに影響するビジネス・メトリックを定義できます。特定のビジネス・メトリックに対してクリティカル・アラートが生成されると、サービス・レベル違反が発生します。

注意:
「ビジネス基準」列は、1つ以上のキー・ビジネス・インジケータがサービスに関連付けられている場合にのみ表示されます。『Oracle Enterprise Manager統合ガイド』を参照してください。

- 実際のサービス・レベル: 営業時間内で、指定された可用性、パフォーマンスおよびビジネス基準をサービスが満たしている時間の割合が計算されます。

- 予測されるサービス・レベル: 関係する評価期間のうち、提供するサービスが満たす必要のある最低限の許容可能なサービス・レベルを表します。

各サービスには、1つのサービス・レベル・ルールのみを定義できます。サービス・レベル・ルールは、ある期間内に「実際のサービス・レベル」を評価し、それを「予測されるサービス・レベル」と比較するために使用されます。

29.9.1 サービス・レベル・ルールの定義

サービス・レベル・ルールは、サービスの品質の測定に使用される評価基準として定義されます。サービス・レベル・ルールは次の要素に基づいています。

- ルールが適用可能な時間範囲。

- ルールを定義するメトリック。

- メトリック値に対するユーザーの期待値。

予測されるサービス・レベルは、サービスに対して期待する品質で、サービス・レベル・ルールのメトリックと時間範囲に基づいて定義されます。たとえば、予測されるサービス・レベルを、営業時間中にサービスが99%の時間使用可能である、とすることができます。

サービスを作成すると、デフォルトのサービス・ルールがそのサービスに適用されます。ただし、サービスに適切な評価基準を正確に定義するには、各サービスのサービス・レベル・ルールを編集する必要があります。To define a service level rule:

1. 「ターゲット」タブをクリックし、「サービス」サブタブをクリックします。「サービス」のメイン・ページが表示されます。

2. サービス名のリンクをクリックし、サービスのホームページに移動します。

3. 「関連リンク」セクションで、「サービス・レベル・ルールの編集」をクリックします。

4. 「サービス・レベル・ルールの編集」ページで、予測されるサービス・レベルと実際のサービス・レベルを指定し、「OK」をクリックします。予測されるサービス・レベルは、サービス・レベル・ルールで定義されているパフォーマンス、使用状況、可用性およびビジネス基準をサービスが満たしている時間の割合を指定します。実際のサービス・レベルは、サービスの質の定義に使用されるベースライン基準を定義するもので、営業時間、可用性、パフォーマンス基準、使用状況基準およびビジネス基準が含まれます。

注意:
スーパー管理者、サービスの所有者またはOPERATOR_TARGETターゲット権限を持つEnterprise Manager管理者が、サービス・レベル・ルールを定義または更新できます。

29.9.2 サービス・レベルの詳細の表示

次のいずれかから直接にサービス・レベル情報を表示できます。

- Enterprise Manager Cloud Controlコンソール -任意のサービスのホームページで、「実際のサービス・レベル」をクリックして、「サービス・レベルの詳細」ページにドリルダウンできます。このページには、予測されるサービス・レベルと比較して、過去24時間、7日間または31日間において、サービスが実際に達成したサービス・レベルが示されます。さらに、サービス違反および各違反の時間の詳細がグラフィックとテキストの両方で表されます。

- 情報パブリッシャ - 情報パブリッシャは、サービス・ダッシュボードと呼ばれる、あらゆるサービスの包括的なビューを提供する即時利用可能なレポート定義を提供します。「レポート定義」ページで、「サービス監視ダッシュボード」レポート定義をクリックし、既存のサービスの包括的なビューを生成します。デフォルトでは、サービスの可用性、パフォーマンス、ステータス、使用状況、ビジネスおよびサービス・レベルが表示されます。また、情報パブリッシャには、独自のカスタム・レポート定義の作成を可能にするサービス固有のレポート要素も用意されています。次のレポート要素が使用可能です。

- サービス・レベルの詳細: ある期間内で達成された「実際のサービス・レベル」とそれに影響を与えた違反を表示します。

- サービス・レベルのサマリー: 一連のサービスについて、選択した期間内に発生したサービス・レベル違反が表示されます。

- サービス監視ダッシュボード: 一連のサービスに関して、そのステータス、パフォーマンス、使用状況、ビジネス、サービス・レベル情報が表示されます。

- サービス・ステータス・サマリー: 1つ以上のサービスの現在のステータス、パフォーマンス、使用状況、ビジネスおよびコンポーネント・ステータスに関する情報が表示されます。
レポート要素の詳細は、オンライン・ヘルプを参照してください。

29.10 コマンドライン・インタフェースを使用したサービスの構成

コマンドライン・インタフェースを使用して、サービス・ターゲットとテンプレートの定義、およびインシデントの設定を行うことができます。EMCLIは、エンタープライズまたはシステム管理者による、カスタマのビジネス・プロセスにワークフローを提供するスクリプト(シェル、バッチ・ファイル、perl、tcl、phpなど)の作成に使用することを意図しています。また、管理者は、オペレーティング・システム・コンソールから直接または対話的にEMCLIを使用できます。『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

WebトランザクションとATSサービス・テストを作成するEMCLIテンプレートの例を次に示します。

例29-1 Webトランザクション・サービス・テスト・テンプレート

<?xml version = '1.0' encoding = 'UTF-8'?> <transaction-template
template_type="generic_service" xmlns="template">
<variables>
<variable name="HOST1" value="linuxserver26.myco.com"/>
<variable name="PORT1" value="5416"/>
<variable name="PROTOCOL1" value="https"/>
</variables>
<transactions>
<mgmt_bcn_transaction>
<mgmt_bcn_txn_with_props>
<mgmt_bcn_txn description="Test for checking the availability of EM Console/Website" is_representative="true"
name="EM Console Service Test" monitoring="true" txn_type="HTTP"/>
<properties>
<property name="readTimeout" num_value="120000.0" prop_type="2" encrypt="false"/>
<property name="Collection Interval" num_value="5.0" prop_type="2" encrypt="false"/>
<property name="certValidationMode" string_value="1" prop_type="1" encrypt="false"/>
<property name="maxDownloadSize" num_value="1.0E8" prop_type="2" encrypt="false"/>
<property name="sensitiveValuesProtection" string_value="0" prop_type="1" encrypt="false"/>
<property name="failureStringModes" string_value="regularText" prop_type="1" encrypt="false"/>
<property name="UserAgent" string_value="Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.1) OracleEMAgentURLTiming/3.0" prop_type="1" encrypt="false"/>
<property name="successStringModes" string_value="regularText" prop_type="1" encrypt="false"/>
<property name="variablesModes" string_value="urlEncode" prop_type="1" encrypt="false"/>
<property name="content" string_value="0" prop_type="1"encrypt="false"/>
<property name="AcceptLanguage" string_value="en" prop_type="1" encrypt="false"/>
<property name="connectionTimeout" num_value="120000.0" prop_type="2" encrypt="false"/>
<property name="useCache" string_value="yes" prop_type="1"encrypt="false"/>
<property name="stringValidationMode" string_value="1" prop_type="1" encrypt="false"/>
<property name="granularity" string_value="transaction" prop_type="1" encrypt="false"/>
<property name="numThreads" num_value="4.0" prop_type="2" encrypt="false"/>
<property name="retries" num_value="1.0" prop_type="2" encrypt="false"/>
<property name="timeout" num_value="300000.0" prop_type="2" encrypt="false"/>
<property name="retryInterval" num_value="5000.0" prop_type="2" encrypt="false"/>
</properties>
<per_bcn_properties/>
</mgmt_bcn_txn_with_props>
<steps_defn_with_props>
<mgmt_bcn_step_with_props>
<mgmt_bcn_step step_number="1" name="1.Access Logout page" step_type="HTTP"/>
<properties>
<property name="req_mode" num_value="1.0" prop_type="2" encrypt="false"/>
<property name="http_method" string_value="G" prop_type="1" encrypt="false"/>
<property name="url" string_value="{PROTOCOL1}://{HOST1}:{PORT1}/em/console/logon/logoff?event=load" prop_type="1" encrypt="false"/>
</properties>
</mgmt_bcn_step_with_props>
</steps_defn_with_props>
<stepgroups_defn/>
<txn_thresholds>
<mgmt_bcn_threshold warning_threshold="6000.0" warning_operator="0" critical_threshold="12000.0" critical_operator="0" num_occurrences="1">
<mgmt_bcn_threshold_key metric_name="http_response" metric_column="avg_response_time"/>
</mgmt_bcn_threshold>
<mgmt_bcn_threshold warning_threshold="0.0" warning_operator="1" critical_threshold="0.0" critical_operator="1" num_occurrences="1">
<mgmt_bcn_threshold_key metric_name="http_response" metric_column="status"/>
</mgmt_bcn_threshold>
</txn_thresholds>
<step_thresholds/>
<stepgroup_thresholds/>
</mgmt_bcn_transaction>
</transactions>
</transaction-template>

例29-2 ATSサービス・テスト・テンプレート

<?xml version = '1.0' encoding = 'UTF-8'?>
<transaction-template template_type="generic_service" xmlns="template">
<variables/>
<transactions>
<mgmt_bcn_transaction>
<mgmt_bcn_txn_with_props>
<mgmt_bcn_txn is_representative="true" name="ATS Page"           monitoring="true" txn_type="OATS"/>
<properties>
<property name="Collection Interval" num_value="5.0" prop_type="2"  encrypt="false"/>
<property name="scriptDescription" string_value="[1] SignIn&#xA;[2] Welcome&#xA;[3] Single Sign-Off&#xA;[4] Sign In" prop_type="1"encrypt="false"/>
<property name="fileUploadTime" string_value="2012-08-0908:47:22.0" prop_type="1" encrypt="false"/>
<property name="OpenScriptJwgName" string_value="ATKHomepage.zip" prop_type="1" encrypt="false"/>
<property name="usageOptions" string_value="userDefined" prop_type="1" encrypt="false"/>
<property name="fileSize" string_value="41368" prop_type="1" encrypt="false"/>
<property name="beaconDistributionOverride" string_value="AtsCredentials=1" prop_type="1" encrypt="false"/>
<property name="FilePropertyValue" prop_type="7" encrypt="false"/>
<property name="databankFilesJar" prop_type="7" encrypt="false"/>
<property name="databankFiles" string_value="AtsCredentials,AtsCredentials.csv,3;" prop_type="1" encrypt="false"/>
<property name="granularity" string_value="transaction" prop_type="1" encrypt="false"/>
<property name="databankValues" string_value="people.firstname=yang.,people.lastName=wang,middle.middlename_col=x." prop_type="1" encrypt="false"/>
<property name="modules" string_value="oracle.oats.scripting.modules.utilities;version=2.4.0&#xA;oracle.oats.scripting.modules.http;version=2.4.0&#xA;"
prop_type="1" encrypt="false"/>
<property name="databankAliasMapping" string_value="AtsCredentials=AtsCredentials.csv" prop_type="1" encrypt="false"/>
<property name="defaultCLIOptions" string_value="-dboptions*:1:FIRST_RECORD_ONLY -jwg ATKHomepage.jwg -noReport true" prop_type="1"
encrypt="false"/>
</properties>
<per_bcn_properties/>
</mgmt_bcn_txn_with_props>
<steps_defn_with_props>
<mgmt_bcn_step_with_props>
<mgmt_bcn_step step_number="1" name="[1] Sign In" step_type="OATS"/>
<properties>
<property name="url" string_value="http:://www.test.com/test1" prop_type="1" encrypt="false"/>
</properties>
</mgmt_bcn_step_with_props>
<mgmt_bcn_step_with_props>
<mgmt_bcn_step step_number="2" name="[2] Welcome" step_type="OATS"/>
<properties>
<property name="url" string_value="http:://www.test.com/test2" prop_type="1" encrypt="false"/>
</properties>
</mgmt_bcn_step_with_props>
<mgmt_bcn_step_with_props>
<mgmt_bcn_step step_number="3" name="[3] Single Sign-Off" step_type="OATS"/>
<properties>
<property name="url" string_value="http:://www.test.com/test3" prop_type="1" encrypt="false"/>
</properties>
</mgmt_bcn_step_with_props>
<mgmt_bcn_step_with_props>
<mgmt_bcn_step step_number="4" name="[4] Sign In" step_type="OATS"/>
<properties>
<property name="url" string_value="http:://www.test.com/test4" prop_type="1" encrypt="false"/>
</properties>
</mgmt_bcn_step_with_props>
</steps_defn_with_props>
<stepgroups_defn/>
<txn_thresholds>
<mgmt_bcn_threshold warning_threshold="0.0" warning_operator="1" critical_threshold="0.0" critical_operator="1" num_occurrences="1">
<mgmt_bcn_threshold_key metric_name="openscript_response" metric_column="status"/>
</mgmt_bcn_threshold>
</txn_thresholds>
<step_thresholds/>
<stepgroup_thresholds/>
</mgmt_bcn_transaction>
</transactions>
</transaction-template>

29.11 サービス・テストのトラブルシューティング

この項では、FormsおよびWebトランザクションのテスト・タイプの使用時によく検出されるエラーをいくつか示します。この項では、次のトピックについて説明します。

- Formsトランザクションの検証およびトラブルシューティング

- Webトランザクションの検証およびトラブルシューティング

29.11.1 Formsトランザクションの検証およびトラブルシューティング

この項では次の内容について説明します。

- Formsトランザクション再生時のトラブルシューティング

- Formsトランザクション記録時のトラブルシューティング

29.11.1.1 Formsトランザクション再生時のトラブルシューティング

この項では、Formsトランザクションの再生時によく検出されるエラーをいくつか示し、その解決方法を示します。

1. エラー・メッセージ: Formsサーバーへの接続が失われました。agentjarsとformsjarsの間でバージョンが一致しない可能性があります。
可能性のある原因: 新しいバージョンのFormsを使用してトランザクションが記録されました。

解決方法: 「Oracle Formsについて」オンライン・ヘルプでバージョン番号をチェックし、実行中のFormsアプリケーションのバージョンを検証します。このバージョンがサポートされていない場合は、「2.」のエラー・メッセージのステップに従ってください。

2. エラー・メッセージ: バージョン<forms_version>はサポートされていません。
可能性のある原因: ビーコンがインストールされているマシンに、必要なForms jarファイルが含まれていません。

解決方法: このエラーを解決するには、次の手順に従います。

1. Formsサーバーがインストールされているシステムにログインします。frmall.jar (Forms 10.1以上を使用している場合)またはf90all.jar(Forms 9.0.4以上を使用している場合)を$FORMS_HOME/forms/javaディレクトリ下で探します。

2. ビーコンがデプロイされているシステムにログインし、このjarファイルを$ORACLE_HOME/jlib/forms/<version>/ディレクトリにコピーします。ここで指定するバージョンは、エラー・メッセージのバージョン文字列と同じにする必要があります。jarファイルをコピーする前に、このディレクトリが空であることを確認します。

Oracle Applications R12を使用してこのエラーが発生した場合は、次の手順に従ってエラーを解決します。

1. Oracle Application Serverがデプロイされているシステムにログインします。次のファイルを探します。

$JAVA_TOP/oracle/apps/fnd/jar/fndforms.jar
$JAVA_TOP/oracle/apps/fnd/jar/fndewt.jar

2. ビーコンがデプロイされているシステムにログインし、これらのファイルを$ORACLE_HOME/jlib/forms/apps/ディレクトリにコピーします。jarファイルをコピーする前に、このディレクトリが空であることを確認します。

注意:
異なるバージョンのOracle Applicationsを使用した場合は、同じビーコンからの2つのOracle Applicationsのデプロイを監視できません。

3. エラー・メッセージ: Forms URLがFormsサーブレットを指していません。
可能性のある原因: Formsトランザクションが記録されたときに、Formsサーブレットの場所を特定できませんでした。

解決方法: Forms URLパラメータがFormsサーブレットを指していることを確認します。Forms10gの場合はhttp://<hostname>:<port>/forms/frmservlet、Forms 9iの場合はhttp://<hostname>:<port>/forms/f90servletです。このパラメータは、Formsトランザクション・レコーダによって自動的に設定されます。ただし、設定されていない場合は、次の手順に従ってURLを特定できます。

- Formsアプリケーションを起動します。

- ソースHTMLファイルをFormsランチャ・ウィンドウで表示します。

- xsurl変数を探します。URLはこの変数に格納されています。

4. エラー・メッセージ: <マシン名>に接続できませんでした
可能性のある原因: ビーコンがインストールされているマシンが、Formsアプリケーションにアクセスできません。

解決方法: ビーコンがインストールされているマシンがFormsアプリケーションにアクセスでき、ファイアウォールが適切に構成されていることを確認します。プロキシ・サーバーを使用したFormsトランザクションの再生は、このリリースではサポートされていません。

5. エラー・メッセージ: 初期メッセージに無効なモジュール・パスが含まれています。
可能性のある原因: トランザクションが、正しく記録されていないか、破壊されている可能性があります。

解決方法: トランザクションの記録を再度実行してみてください。

6. エラー・メッセージ: ログイン・サーバーに接続できません。
可能性のある原因: このエラーは、次の原因で発生する可能性があります。

- 指定したログインURLが正しくありません。

- ログイン・サーバーに指定したHTTPS証明書が無効です。

解決方法:

- ログインURLが正しいことを確認します。

- HTTPSを使用してログイン・サーバーに接続している場合は、サーバー上の証明書がログイン・サーバーのマシン自体用であることを確認します。SSL証明書がエージェントにインポートされ、証明書のCNがログイン・サーバーのURLのホスト名に一致していることを確認します。

29.11.1.2 Formsトランザクション記録時のトラブルシューティング

この項では、Formsトランザクションが正常に記録されない場合に有効なトラブルシューティング方法をいくつか示します。

1. Internet Explorerのインスタンスがすべて閉じられており、Javaランタイム・プログラムが1つも開かれていないことを確認します。

2. Javaコンソールが開かれた状態で、記録を再度開始します。コンソールに例外やエラー・メッセージが表示される場合もあります。

3. コンソールに、Forms Transaction Recorder Version: <version number>"というテキストが表示される場合もあります。このテキストが表示された場合は、ステップ5に進みます。テキストが表示されない場合は、formsRecorder.jarがFormsのアーカイブ・ディレクトリにコピーされているかをチェックします。次のいずれかの方法で、このチェックを実行できます。

1. Formsアーカイブ・ディレクトリにナビゲートし、ディレクトリにformsRecorder.jarファイルが存在するかをチェックします。

2. 「Formsトランザクション監視の有効化」ページにナビゲートし、該当するFormsサーバー・ターゲットを選択し、「構成」をクリックします。ホスト資格証明を入力し、このFormsサーバー上でFormsトランザクション・レコーダが構成済かを確認します。Formsのアーカイブ・ディレクトリにformsRecorder.jarが存在しない場合は、トランザクション監視を行えるようにFormsサーバーを構成する必要があります。formsRecorder.jarがFormサーバーのアーカイブ・ディレクトリ内に存在していることを確認したら、ステップ1に戻って、再度記録を試行します。

4. Javaの.policyファイルに関する例外がJavaコンソールに表示された場合は、そのファイルをチェックし、そのファイルの内容が十分なものであり、そのファイルの場所が正しいことを確認します。エラーが検出された場合は、エラーを解決し、記録を再度試行する必要があります。

5. それでも記録に失敗する場合、Enterprise Manager証明書がセキュアなサイトにインポートされているかどうかを確認します。証明書がインポートされていない場合は、インポートして、再度記録を試行します。

29.11.2 Webトランザクションの検証およびトラブルシューティング

注意:
Enterprise Manager 13.1では、Webトランザクションの記録および再生(ブラウザ・シミュレーションなど)機能は使用できません。新規トランザクションを記録したり、既存のWebトランザクションを再生することはできません。

この項では、Webトランザクションの記録および再生中に発生する可能性のある一般的なエラーについて説明します。

1. シナリオ: 「サービス・テストの検証」で「接続の確立中にタイムアウトが発生しました -- http://..../」と表示されます。
可能性のある原因: ビーコンはプロキシ・サーバーを介してのみ該当するURLにアクセスできますが、その構成が実行されていません。

解決方法: 「すべてのターゲット」ページで、ビーコンを選択し、「構成」をクリックして、ビーコンのプロキシ設定を実行します。

2. シナリオ: 「サービス・テストの検証」で「認証が必要です -- https://...../」と表示されます。
可能性のある原因: Basic認証情報が自動的に記録されていません。

解決方法: このエラーを解決するには、次の手順に従います。

1. 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。

2. Basic認証情報(ユーザー名、パスワードおよびレルム)をすべて入力します。

注意:
レルムは、通常、ブラウザの認証ダイアログ・ボックスの中の「ユーザー名」ラベルの上に表示されます。

3. シナリオ: 「サービス・テストの検証」で「sun.security.validator.ValidatorException: 信頼できる証明書が見つかりません -- https://....../。」と表示されます。
可能性のある原因: ビーコンがこのSSL証明書を認識していません。

可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。「拡張プロパティ」で、「SSL証明書の認証」を「いいえ」に設定します。

4. シナリオ: 「サービス・テストの検証」で、「https://....../に対しタイムアウト値が300000を超えました。レスポンス時間 = 3000000」と表示されます。
可能性のある原因: テストが複雑すぎるため、割り当てられた時間内に完了していない可能性があります。または、サーバー側に、パフォーマンスの問題が実際に存在する可能性もあります。

可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。サーバーのパフォーマンス上の問題でない場合は、「拡張プロパティ」の下の、タイムアウト値を増やします。

5. シナリオ: 「サービス・テストの検証」オプションによると、サービスは停止中ですが、Webアプリケーションは稼働しており、Webトランザクションを正常に再生できることが報告されます。
可能性のある原因: 該当するWebアプリケーションは、Internet ExplorerまたはMozillaベースのブラウザとのみ互換性があります。

可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックします。「拡張プロパティ」の下で、「User-Agentヘッダー」をMozilla/4.0(compatible; MSIE 6.0; Windows NT 5.1)OracleEMAgentURLTiming/3.0に設定します。

注意:
Enterprise Manager 10.2.0.4以上の場合、この「User-Agentヘッダー」は、Webトランザクションの記録中に自動的に設定されます。

6. シナリオ: 「テスト・パフォーマンス」ページに、ステップ・メトリックが表示されません。
可能性のある原因: デフォルトでは、トランザクション・レベルのメトリックのみが収集されます。

可能性のある解決方法: 「サービス・テストとビーコン」ページで、サービス・テストを選択し、「編集」をクリックして、「データの粒度」を「ステップ」に設定します。

30 Enterprise ManagerのSNMPサポートの概要

この章では、Enterprise ManagerのSNMPサポートの概要を説明します。内容は次のとおりです。

- SNMPサポートの利点

- SNMP管理ステーションについて

- Enterprise ManagerのSNMPのサポート方法

- SNMPトラップ通知の送信

- SNMPを使用した外部デバイスの監視

- 管理情報ベース(MIB)について

- メトリック拡張について

Simple Network Management Protocol (SNMP)はデバイスの管理および監視に使用されるプロトコルで、これらのデバイスの多くはルーター、スイッチなどのネットワーク・タイプのデバイスです。SNMPを使用すると、1つのアプリケーションで情報を取り出した後、基礎となるハードウェアに関わりなく、広範なシステム間に新しい情報をプッシュできます。

主にデータベース、ネットワークおよびシステム管理者向けに設計されたSNMPサポートにより、Enterprise Managerは多数の既存の広く使用されている管理システムに統合されます。また、Enterprise Managerはその監視範囲を、SNMPを使用して監視できるデバイスに拡張できます。

30.1 SNMPサポートの利点

SNMPサポートの主な利点は、次のとおりです。

- 主要なOracle製品の監視機能を、SNMPに基づいた任意の管理フレームワークに迅速に統合します。

- これらのOracle製品を、任意の規模の企業ネットワーク全体でリアルタイムに検索、識別および監視します。

- 管理者は、ネットワーク・マップでOracle製品を表す標準のOracleアイコンを参照できます。このマップは、動的にカスタマイズできます。

- 管理者は、Oracle製品の現在のステータスを、管理情報ベース(MIB)で製品ごとに定義されている数種類のステータス変数で参照したり、それらのステータスごとに表示する要素を選択できます。

- 管理者は、しきい値とアラートを定義することによって、例外的な条件の発生を予測し、特別な状況に発生と同時に対応したり、自動的に対応できます。

- 管理者は、SNMPを通じて取得した履歴データを保存し、分析できます。

- SNMPはオープンな標準であるため、管理アプリケーションのプロバイダは、Oracleユーザー向けにカスタマイズしたソリューションを容易に構築できます。

厳密に言うと、SNMPサポートはOracle製品を管理するというよりも監視するためのものです。SNMPサポートはOracleアプリケーションのネットワーク全体の状況をトラッキングするのに非常に有益です。まず、通常の操作の確認、次に潜在的な問題の検出後すぐの特定と対処です。しかし、問題の調査と解決の目的では、Oracle SQL *Plus Worksheetなどの他のOracleツールの方が適している場合もあります。これは、他のツールがシステム・パラメータを設定または調整するように設計されているのに対し、SNMPサポートはステータスを問い合せるように設計され、システム・パラメータを変更するようには設計されていないためです。

注意:
Oracle SNMPは、HP OpenVMSプラットフォームではサポートされていません。

30.2 SNMP管理ステーションについて

SNMP管理ステーションとは、SNMPプロトコルを使用して管理対象の要素を監視するノードのことです。これは通常、管理対象の要素と同じネットワーク上にあるスタンドアロン・ワークステーションです。このマニュアルでは一貫してSNMP管理ステーションという用語を使用しますが、この他に管理コンソール、管理システムまたは管理ノードという用語も使用されます。

ほとんどのフレームワークでは、通信の基礎としてSNMPが使用されるため、SNMPをサポートするOracle製品は事実上すべての管理フレームワークに統合できます。CA Unicenter、HP OpenView、Tivoli NetView、Aprisma Spectrum、Sun SolsticeおよびCastle Rock SNMPc Network Managerのようなサード・パーティ製品は、SNMP管理ステーション機能を提供します。

30.3 Enterprise ManagerのSNMPのサポート方法

Enterprise Managerは、サード・パーティ管理システムとの統合、SNMPトラップを使用したイベント情報の共有、およびSNMPを使用した新しいデバイスおよびターゲットの監視によるEnterprise Managerの監視範囲の拡張により、SNMPをサポートします。

図30-1に示すように、Enterprise ManagerがSNMPを使用する方法は多数あります。

1. Enterprise ManagerからSNMP管理ステーションへのSNMPトラップ通知の生成による、サード・パーティの管理システムとのイベント情報の共有。たとえば、SNMPを使用して、選択済メトリックがしきい値を超えていることをサード・パーティ・アプリケーションに通知できます。
この方法はSNMPバージョン3 (SNMPv3)をサポートします。

詳細は、第30.4項「SNMPトラップ通知の送信」および第3章「通知の使用」を参照してください。

2. 管理対象エンティティとの間でのSMNPトラップの受信またはSNMPデータのフェッチにより、Enterprise Managerの監視範囲を新しいエンティティに拡張します。SNMPトラップを受信するようにメタデータ・プラグインを開発することで、Enterprise ManagerがSNMPトラップをスローできる製品を監視するようにできます。
この方法は、SNMPバージョン1 (SNMPv1)、SNMPバージョン2 (SNMPv2c)およびSNMPバージョン3 (SNMPv3)をサポートします。

詳細は、第30.5項「SNMPを使用した外部デバイスの監視」および『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

3. SNMPアダプタを使用してSNMPエージェントに問い合せる新しいメトリックを作成することで、Enterprise Manager管理エージェントは、メトリック・データとして使用されるManagement Information Base(MIB)変数情報をホスト・ターゲット上のネイティブSNMPエージェントに問い合せることができます。
この方法は、SNMPバージョン1 (SNMPv1)、SNMPバージョン2 (SNMPv2c)およびSNMPバージョン3 (SNMPv3)をサポートします。

詳細は、第30.6項「メトリック拡張について」および第8章「メトリック拡張の使用」を参照してください。

図30-1 Enterprise ManagerのSNMPのサポート方法

30.4 SNMPトラップ通知の送信

Enterprise Managerの通知システムを使用すると、SNMP対応のサード・パーティのアプリケーションとSNMPトラップを介してEnterprise Managerのイベント情報を共有できます。Enterprise Managerはトラップの送信に対してSNMPv1プロトコルをサポートします。たとえば、次のいずれかのイベントが発生したときに、イベント情報をトラップとしてEnterprise Managerからサード・パーティのアプリケーションに送信するとします。

- 特定のメトリックがしきい値を超えた(メトリック・アラート・イベント)

- ターゲットが停止した(ターゲット可用性イベント)

- ジョブの失敗(ジョブ・ステータス変更イベント)

注意:
Enterprise Managerのイベント・タイプのすべてのリストと説明については、第2.1.1項「イベントの管理」を参照してください。

通知システムでSNMPトラップを使用することは、次の点に関する問題です。

1. SNMPトラップを使用する通知メソッドの定義。詳細は、第3.5項「サード・パーティ・システムへのSNMPトラップの送信」を参照してください。

2. 通知メソッドのルールへの割当て。既存のルールを編集または新規のインシデント・ルールを作成できます。詳細は、第2.2.4項「ルール・セットの設定」を参照してください。

30.4.1 管理情報ベース(MIB)について

SNMPを使用すると、Enterprise Managerではサード・パーティのSNMP対応アプリケーションに情報を送信できますが、SNMP対応アプリケーションでEnterprise Managerから情報を取得する必要がある場合があります。これを実施するには、MIB変数を利用し、SNMPトラップの登録を行います。トラップ・コンテンツの詳細は、MIB変数から取得できます。

MIBの詳細は、第3.6項「管理情報ベース(MIB)」および付録A「Enterprise Manager MIBの変数の解釈」を参照してください。

注意:
Enterprise ManagerのMIB変数を使用するには、有効なDiagnostic Packのライセンスが必要です。

30.5 SNMPを使用した外部デバイスの監視

管理者にとってEnterprise Managerによる管理対象ではないアプリケーションからアラートを受信することが重要な場合が多くあります。これらのアプリケーションの多くはアラート条件が発生したときにSNMPトラップをトリガーするように構成できます。これらのトラップをEnterprise Manager内で受信し、それらのアプリケーションのEnterprise Managerからの監視を開始できます。このようなアプリケーションにより発生したSNMPトラップを受信し分析する機能を持つことにより、Enterprise Managerの監視およびアラート機能をこれらのアプリケーションに拡張し、IT環境における監視の複雑性を低下させることができます。

アプリケーションにより発生したSNMPトラップを受信し(Enterprise Managerにより管理されない)、Enterprise Managerでアラートとしてトラップを表示するするように、Enterprise Managerを構成することができます。

これらのトラップを受信するには、管理対象エンティティを表すメタデータ・プラグインを開発する必要があります。次に、SNMP receiveletまたはSNMP fetchletを使用して、そのエンティティに関する監視データを受信または取得します。

メタデータ・プラグインの開発の詳細は、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

30.5.1 SNMP receiveletについて

管理対象環境でサード・パーティのエンティティを監視している間に、サード・パーティのネットワーク要素のステータスが使用不可になった場合、あるいはそのメトリック重大度条件(メトリックしきい値)に達したか、超過した場合は、サード・パーティのネットワーク要素のSNMPエージェントによって、管理エージェントに通知が送信されます。これらの通知はSNMPトラップ形式で、パフォーマンスのしきい値に達すると、管理エージェントからのリクエストなしに、非同期にトリガーされます。

これらのトラップはSNMPに基づいているため、Oracle Management Agentは、SNMP receiveletを使用して、これらのSNMPトラップを受信し、Oracle Management Serviceと互換性のある形式に変換します。

SNMP receiveletの詳細は、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

30.5.2 SNMP fetchletについて

fetchletはパラメータ化されたデータ・アクセス・メカニズムで、管理対象の要素の関連データをEnterprise Managerのメトリック形式にマップするために利用できます。標準の領域にあるEnterprise Managerは現在、SNMP fetchletを使用して、管理対象の環境内のSNMP対応エンティティから情報をフェッチしています。

SNMP fetchletはSNMPエージェントに、ターゲット・タイプの管理情報ベース(MIB)に定義された、管理対象エンティティに関するデータを問い合せます。MIBの詳細は、第30.4.1項「管理情報ベース(MIB)について」および第3.6項「管理情報ベース(MIB)」を参照してください。

SNMP fetchletの詳細は、『Oracle Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス』を参照してください。

30.6 メトリック拡張について

メトリック拡張を使用すると、Oracleの監視機能を拡張してIT環境に固有の条件を監視できるようになります。たとえば、ホスト・ターゲット・タイプに新しいメトリックを作成できます。SNMPアダプタを使用すると、Enterprise Manager管理エージェントは、メトリック・データとして使用される管理情報ベース(MIB)変数情報をターゲット・ホストのネイティブSNMPエージェントに問い合せることができます。

メトリック拡張とSNMPアダプタの詳細は、第8章「メトリック拡張の使用」を参照してください。

第V部

システム・インフラストラクチャ

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

- システム・インフラストラクチャ・ターゲットの処理

- ネットワークの管理

- 記憶域の管理

- サーバーのモニタリング

- PDUの管理

- ラックの管理

- Oracle SuperClusterの管理

- Oracleのオペレーティング・システムのモニタリング

- Oracle Solarisゾーンのモニタリング

- Oracle VM Server for SPARCのモニタリング

31 システム・インフラストラクチャ・ターゲットの処理

この章では、Oracle Enterprise Managerシステム・インフラストラクチャ・プラグインについて説明します。この章の内容は次のとおりです。

- Enterprise Managerシステム・インフラストラクチャの概要

- システム・インフラストラクチャのユーザー・インタフェースの概要

- システム・インフラストラクチャ管理のロールの作成

- システム・インフラストラクチャ・ターゲットの関連リソース

31.1 Enterprise Managerシステム・インフラストラクチャの概要

ホストとは、管理対象のデータベースやその他のサービスが常駐するコンピュータです。ホストは、Oracle Enterprise Manager Cloud Controlでモニタリングされる数多くのコンポーネントやターゲットの1つです。Oracle Enterprise Manager Cloud Controlは、図31-1に示すアプリケーションからストレージ・ディスクまでのOracle製品スタックにおける、エンタープライズ・レベルのデータ・センター管理ソリューションです。

図31-1 Oracle製品スタック

Enterprise Managerシステム・インフラストラクチャ(EMSI)プラグインは、完全に統合されたソフトウェア・プラグインとしてモニタリング機能を提供し、Oracle SolarisおよびLinuxオペレーティング・システム、仮想化されたオペレーティング・システム(ゾーン)や仮想マシン(論理ドメイン)、サーバー、記憶域アプライアンス、ホストの記憶域、ネットワーク・リソースなどのスタックの下半分について、エンタープライズ全体のビューを提供します。

Oracle Enterprise Manager Cloud Controlコンソールのインタフェースは、管理対象コンポーネントに関する詳細情報を提供し、コンポーネント間の関係を示します。ドリルダウンして、特定のコンポーネントやメトリックに関するより詳細な情報を表示できます。

サーバー・ターゲットについては、電力使用量、ネットワーク情報、サービス・プロセッサ構成、ファンや温度の情報などのサーバーの詳細を表示できます。その他のハードウェア・ターゲットには、シャーシ、ラック、電力配分装置、ネットワーク機器などがあります。ホストまたは記憶域アプライアンスの記憶域リソースとそのコンポーネント(記憶域プール、ストレージ・ハードウェア、ファイルシステム、論理ボリューム、論理ユニット(LUN)など)を表示できます。

Oracle SolarisおよびLinuxオペレーティング・システム・ターゲットについては、リソースとプロセスの情報、上位コンシューマ、パフォーマンスおよびオープン・インシデントの詳細を表示できます。さらに、Oracle Solarisの代替ブート環境やゾーンに関する詳細を表示できます。

Oracle VM Server for SPARCを使用してハードウェアを仮想化したり、Oracle Solarisを使用してオペレーティング・システムを仮想化すると、詳細が仮想化プラットフォーム・ページに表示されます。仮想化プラットフォーム・ページには、全体のゲスト、CPUとメモリー、インシデント、構成情報などの高レベルの詳細が表示されます。個々の仮想サーバーのページにドリルダウンして、選択した論理ドメインまたはゾーンに固有のメトリックを表示できます。

Enterprise Managerシステム・インフラストラクチャは、Oracle SuperClusterエンジニアド・システムのビューも提供します。Oracle SuperClusterは、SPARC計算ノード、Oracle ZFS Storage Appliance、インフィニバンド・スイッチ、PDUおよびExadata Storage Serverをマルチラック・システムに統合します。計算ノード、Exadata Storage Server、インフィニバンド・スイッチ、電力配分装置、ZFS記憶域サーバーなど、Oracle SuperClusterのすべてのコンポーネントを表示できます。「計算ノード」を展開すると、論理ドメインおよびゾーンを表示できます。

31.1.1 システム・インフラストラクチャ・ターゲットのモニタリングについて

一連のモニタリング・ルールおよびパラメータが、管理対象ターゲットをモニタリングします。予期したとおりに実行されていないリソースについては、アラートとインシデントが発行されます。

各ターゲットに対するダッシュボードには、ターゲット・タイプに基づいて詳細が表示されます。すべてのダッシュボードに、警告インシデント、クリティカル・インシデントおよび致命的なオープン・インシデントの数がリンクとともに表示され、リンクを使用して特定のインシデントのインシデント・マネージャにドリルダウンできます。

ホストにデプロイされた管理エージェントによって、ターゲットのアクティビティ、ステータス、パフォーマンスおよび状態についての情報が収集され、追跡されます。次の検出されたターゲット・タイプのメトリックを表示できます。

- サーバー

- 記憶域サーバー

- ネットワーク

- ラックおよび電力配分装置(PDU)

- Oracle SolarisおよびLinuxオペレーティング・システム

- Oracle Solarisゾーン

- Oracle VM Server for SPARCおよび論理ドメイン

- Oracle SuperClusterエンジニアド・システム

31.1.2 システム・インフラストラクチャ・ターゲットの動的ビューについて

ターゲットのタイプに応じて、ターゲット・ホームページにグラフ、チャートおよび表が表示され、より詳細な情報が一目でわかります。より複雑なターゲットのホームページには、動的なフォトリアリスティック・ビューと関係チャートが表示されます。場合によっては、イメージと対話することで、ハードウェアのデプロイ方法およびリソースの利用方法について理解を深めることができます。

次のチャートとビューを使用すると、ターゲットを迅速に評価でき、関係が一目でわかります。

- 関係チャート: ゲストへのリソースの割当て方法が表示されます。たとえば、Oracle VM Server for SPARCの「システム・インフラストラクチャ仮想化プラットフォーム」ページには、vCPUとコアの割当てが表示される「コアの分散」タブがあります。チャートには同心円が表示され、そのセグメントには、どのCPUとコアがどのゲストに割り当てられ、どれが割り当てられていないかが示されます。外側の輪の中のゲストをクリックして、そのゲストのリソース使用に関する詳細な情報を表示できます。

- フォトリアリスティック・ビュー: ハードウェア・ターゲットのコンポーネントとポート、およびオープン・インシデントがあるかどうかが表示されます。たとえば、Oracle SuperClusterエンジニアド・システムのモニタリング・ページには、ラック内でのシステムのレイアウト方法がわかるフォトリアリスティック・ビューがあります。システム内のすべてのアクティブなターゲットがイメージで表示されます。イメージ内のターゲットにマウス・ポインタを重ねると、より詳細な情報を表示できます。エンジニアド・システムのコンポーネントにオープン・インシデントがある場合は、コンポーネントが赤枠のイメージで表示されます。

- 構成図ビュー: エンジニアド・システムのコンポーネントのラベルが表示されたシンボリック・ビューが表示されます。エンジニアド・システム内のサーバー、ZFS Storage Applianceサーバー、InfiniBandスイッチおよびPDUのLEDステータス(稼働中、停止中またはブラックアウト)と温度が一目でわかります。

31.2 システム・インフラストラクチャのユーザー・インタフェースの概要

システム・インフラストラクチャ・プラグインによって収集された情報は、更新されたユーザー・インタフェースに表示されます。各ターゲット・ホームページは、ターゲットのタイプ、およびターゲットでOracle VM Server for SPARCとOracle Solaris Zonesのどちらの仮想化テクノロジが利用されているかによって、若干異なります。

ターゲットのオープン・インシデント、リソース使用率およびメトリックがダッシュボードに表示されるため、ダッシュボードは高可用性と最適化されたパフォーマンスの維持に役立ちます。ユーザー・インタフェースのタブには、より詳細なメトリック情報が含まれています。情報は、ステータスやコンポーネント間の関係をすばやく理解できるように、グラフ、表、チャート、構成図ビューおよびフォトリアリスティック・ビューに表示されます。

31.2.1 ターゲット・ホームページについて

ホームページでは、ステータスをすばやく表示したり、潜在的なリソースの問題を特定したり、特定のターゲットのサービス・リクエストや構成履歴を表示することができます。このページからオープン・インシデントの詳細にドリルダウンして、詳細なメトリックおよびゲストの詳細を表示できます。

ホームページには、「すべてのターゲット」メニューからアクセスできます。各ホームページの上部にダッシュボードがあります。ページの右側にあるタブでより詳細な情報や履歴グラフを使用できます。

ダッシュボードは、重要な情報や厳密にモニタリングする必要がある情報の概要を表示するように設計されています。情報は、ダッシュレットと呼ばれる一連のセクションに表示されます。ダッシュボードには、少なくとも4つのダッシュレットが表示されます。ターゲット・タイプによってダッシュレットの数とコンテンツが決まります。ダッシュレット行の下にある小さなボタンをクリックすると、次の一連のダッシュレットに切り替わります。ナビゲーション・ボタンの下に、ダッシュボードを最小化できる1つのボタンがあります。

図31-2は、Oracle ZFS Storage Serverターゲット・ホームページの最初の3つのダッシュレットの例です。この例は、ターゲット・タイプとページが最後にリフレッシュされた日付を示しています。最初のダッシュレットにはターゲットの詳細が含まれ、2番目のダッシュレットは、オープン・インシデントの数と重大度レベルを示しています。3番目のダッシュレットは、このターゲットで使用されている容量と使用可能な容量を示しています。赤枠で示すように、「オープン・インシデント」ダッシュレットの下に1つ以上のボタンが表示されます。ボタンをクリックすると、次の一連のダッシュレットに移動します。

図31-2 ダッシュボード

コンテンツは異なりますが、各ホームページには、ターゲットのステータス、リソース使用率およびメトリックの統合されたビューが表示されます。ダッシュレットに表示される詳細の一部を次に示します。

- 最初のダッシュレットには、選択したターゲットの名前やステータスなどのターゲットの詳細が表示されます。

- 2番目のダッシュレットにはインシデント情報が表示されます。このダッシュレットには、現在オープンになっているクリティカル、警告および情報インシデントの数が表示されます。それぞれの数字は、より詳細な情報へのリンクになっています。

- ターゲット・タイプに固有のリソース使用率、上位統計情報およびメトリック情報が1つ以上のダッシュレットに表示されます。

- 過去30日間および過去5日間にOracleにファイルされた選択ターゲットのサービス・リクエストの数がダッシュレットに表示されます。

- 最後のダッシュレットには、最後の構成変更および最終報告インシデントの時間が表示されます。

場合によっては、ダッシュレットのコンテンツをクリックしてドリルダウンし、詳細情報を取得できます。たとえば、「オープン・インシデント」ダッシュレットは、より詳細な情報にリンクしています。インシデントのタイプの横にある数字をクリックすると、ダッシュボードが反転し、インシデントの表が表示され、ターゲット名、シノプシスおよびそのタイプに応じた追加情報が示されます。さらにドリルダウンしてインシデント・マネージャに移動し、最高レベルの詳細を表示できます。

これらのターゲット・タイプのホームページの違いは、「仮想化ホームページについて」および「Oracleエンジニアド・システムのホームページについて」を参照してください。

31.2.2 仮想化ホームページについて

Oracle VM Server for SPARC仮想化テクノロジを使用する場合とOracle Solaris Zone仮想化テクノロジを使用する場合とでは、ターゲット・ホームページが異なります。

仮想化のターゲット・ホームページは次のとおりです。

- 「仮想化プラットフォーム」ページ

- 「仮想サーバー」ページ

「仮想化プラットフォーム」ページは、制御ドメインまたはグローバル・ゾーンのホームページです。「仮想化プラットフォーム」ページの左上隅には、関連する各論理ドメインまたはゾーンの「仮想サーバー」ホームページへのリンクを含む、「ターゲット・ナビゲーション」アイコンがあります。

ゾーンおよび論理ドメインについては、「仮想化プラットフォーム」ページに表示されるインシデント数にすべての関連するゾーンとドメインのインシデントが含まれます。たとえば、制御ドメインとすべての関連する論理ドメインが含まれます。

31.2.3 Oracleエンジニアド・システムのホームページについて

Oracle SuperClusterエンジニアド・システムについては、ターゲットのホームページからエンジニアド・システムのコンポーネントをモニタリングできます。モニタリング・ページに、エンジニアド・システムのフォトリアリスティック・ビューと構成図ビューが表示されます。フォトリアリスティック・ビューは、ラック内でのシステムの物理的なレイアウト方法の把握に役立ちます。イメージにマウス・ポインタを重ねると、コンポーネントに関する詳細を表示できます。構成図ビューには、コンポーネント・ラベルとLEDステータスが表示されます。

31.3 システム・インフラストラクチャ管理のロールの作成

システム・インフラストラクチャ・プラグインでは、アクセス制御用のロールを独自に定義していません。プラグインを管理するには、ロールおよび管理者を作成して、管理者にロールを割り当てる必要があります。ユーザーの権限は、ロールによって制限されます。

注意:
セキュリティ上の理由により、SYSMANアカウントは、他のアカウントを作成するためのテンプレートとしてのみ使用し、直接使用しないことをお薦めします。

ユーザーに管理権限を指定するロールを作成するには、次の手順を実行します。

1. スーパー管理者ユーザーとしてEnterprise Manager Cloud Controlコンソールにログインします。

2. 「設定」、「セキュリティ」の順に選択します。

3. 「ロール」を選択します。
「セキュリティ」ページに、事前定義済ロールのリストが表示されます。これらのロールを基礎として、固有のサイト・レベル要件に合せてカスタム・ロールを定義できます。

注意:
表示された事前定義済ロールは、編集も削除もできません。

4. 作成する目的のロールに最も近いロールを選択します。「類似作成」をクリックします。

5. 「プロパティ」ページで、新しいロールの名前を入力します。オプションで説明を追加できます。「次」をクリックします。

6. 「ロール」ページで、「使用可能なロール」のリストからロールを選択します。「移動」をクリックして、ロールを「選択したロール」に追加します。「次へ」をクリックします。

7. 「ターゲット権限」ページで、新しいロールに付与する権限を選択します。「次」をクリックします。

8. 「リソース権限」ページで、明示的に付与する特定の権限を編集できます。「権限付与の管理」の「編集」アイコンをクリックして、変更を行います。「次」をクリックします。

9. 「管理者」ページの「選択可能な管理者」リストから、新しいロールを付与する管理者を選択します。「移動」をクリックして、管理者を「選択した管理者」に追加します。「次へ」をクリックします。

10. 「確認」ページに、作成した新しいロールの完全なサマリーが表示されます。「戻る」をクリックして前の画面に戻り、変更を行います。「終了」をクリックして、ロールの作成を完了します。

新しく作成された管理者でログインすると、SYSMANとは異なり、管理者は設定された権限で制限されます。

31.4 システム・インフラストラクチャ・ターゲットの関連リソース

詳細は、次を参照してください:

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- インシデント管理の使用

32 ネットワークの管理

次の情報が含まれています。

- ネットワーク管理のスタート・ガイド

- ユーザー・インタフェース内でのネットワーク情報の場所

- ネットワーク管理の処理

- トポロジの表示

- ファブリック

- データリンク

- ネットワーク

- ネットワーク管理の関連リソース

32.1 ネットワーク管理のスタート・ガイド

Enterprise Managerは、図32-1に示す開放型システム間相互接続(OSI)モデルの第1、第2および第3層に移入するターゲットを検出および管理します。OSIモデルでは、ある層はそれより上の層をサポートし、それより下の層によりプロビジョニングされます。ある層に障害が発生すると、それより上にある層に影響を及ぼします。

図32-1 OSIモデル

- 第1層: ファブリック・ターゲットはOSIモデルの物理層(ネットワーク・スイッチなど)にあります。

- 第2層: データリンク・ターゲットはこのモデルのリンク層にあります。イーサネット・ファブリックの場合、データリンクはVLAN IDです。インフィニバンド・ファブリックの場合、データリンクはパーティション・キーです。この層には、リンクの組合せが含まれます(リンク・アグリゲーションなど)。

- 第3層: ネットワーク・ターゲットはこのモデルのネットワーク層にあり、IPアドレスおよびIPMPグループとしてプラムされるネットワーク・インタフェースです。

ネットワーク管理には、ターゲットがネットワーク・リソースを利用できるようにするためのあらゆるアクティビティが含まれます。

- ファブリックおよびそのデータリンクと、ネットワークの検出。

- レイヤー関連構成およびパフォーマンスのメトリックを収集します。

- 各レベルでの障害の検出。

- トポロジ(ファブリックおよびネットワーク内の関係のグラフィック表示)の表示。

32.2 ユーザー・インタフェース内でのネットワーク情報の場所

表32-1に、情報が記載されている場所を示します。

表32-1 BUI内でのネットワーク情報の場所

リソース

場所

ファブリックの表示

「すべてのターゲット」を表示し、「システム・インフラストラクチャ・ネットワーク」を選択します。

ネットワークの表示

「すべてのターゲット」を表示し、「システム・インフラストラクチャ・ネットワーク」を選択します。ネットワークを選択します。

データリンクの表示

「すべてのターゲット」を表示し、「システム・インフラストラクチャ・ネットワーク」または「ホスト」を選択します。ネットワークを選択し、「ネットワークの接続性」タブをクリックしてから、「データリンク」オプションをクリックします。

ネットワーク・スイッチの表示

「すべてのターゲット」を表示し、「システム・インフラストラクチャOracle InfiniBandスイッチ」または「システム・インフラストラクチャCISCOスイッチ」を選択します。

ネットワークを使用している仮想化ホストの表示

ネットワークを表示して「接続されたノード」セクションを表示するか、「ネットワーク・メンバー」タブをクリックします。

ネットワークにおけるインシデントの表示

ネットワーク・インシデント・ダッシュレットの表示。

ネットワーク・スイッチのステータスの表示

「すべてのターゲット」を表示し、続いて「システム・インフラストラクチャ・スイッチ」を選択し、「温度」、「ファン」パフォーマンスおよび「スループット」ダッシュレットを表示します。

ネットワーク・スイッチのパフォーマンスの表示

「すべてのターゲット」を表示し、「システム・インフラストラクチャ・スイッチ」、ネットワーク・スイッチの順に選択します。「パフォーマンス」タブをクリックします。いつでも表示をリフレッシュできます。

ネットワーク・スイッチに対してモニタリングされているメトリックの表示

「すべてのターゲット」を表示し、「システム・インフラストラクチャ・スイッチ」を選択します。「システム・インフラストラクチャ・スイッチ」を右クリックして、「モニタリング」、「すべてのメトリック」の順に選択します。

ネットワーク・スイッチのポートの表示

「すべてのターゲット」を表示し、「システム・インフラストラクチャ・スイッチ」を選択します。ネットワーク・スイッチを選択します。グリッドに使用済および使用可能なポートが表示されます。

ファブリックの検出

「ターゲットの追加」手順のいずれかを使用します。

ファブリック、データリンクまたはネットワークの削除

「ターゲットの削除」処理を使用します。

32.3 ネットワーク管理の処理

要件に応じて、次の処理を実行できます。

- スイッチやネットワーク接続ターゲットの検出。ファブリックなどのネットワーク接続ターゲットを検出すると、そのデータリンクとネットワークも検出されたアセットとなります。

- ファブリック、データリンクおよびネットワークの構成の表示。

- インシデントおよびパフォーマンス・メトリックを使用した問題の診断。

- ターゲットのモニター方法とパフォーマンス測定方法の変更。

32.4 トポロジの表示

トポロジは、アセット間の関係を表示します。ネットワーク・トポロジは、ポート、データリンクおよびネットワーク・インタフェースから構成されています。

1. 「ターゲット」、「すべてのターゲット」の順に選択します。

2. ファブリックについては、イーサネット/インフィニバンド・ファブリックを選択します。
ネットワーク・スイッチについては、「システム・インフラストラクチャ・スイッチ」を選択します。

ネットワークについては、「システム・インフラストラクチャ・ネットワーク」を選択します。

3. ターゲットの1つを選択します。

4. ターゲットのランディング・ページで、メニューを表示するターゲットのタイプの横にある下向き矢印をクリックします。

5. ファブリックについては、図32-2に示すように、「ファブリック・トポロジ」を選択します。

図32-2 トポロジのメニュー選択

6. 「トポロジ」ページに、このターゲットの関係が表示されます。トポロジの表示を調整して、ターゲットの詳細を表示できます。図32-3は、「フィルタ」オプションにアセットが含まれているため、選択したファブリックを使用するアセットを示しています。

図32-3 ファブリック・トポロジ

7. トポロジのオブジェクトにカーソルを重ねて、アセットの情報を表示します。図32-4に、ファブリックのスイッチにマウス・ポインタを重ねた結果を示します。

図32-4 ターゲット・トポロジ

8. 別のターゲットを表示するには、再度「すべてのターゲット」をクリックしてから、フィルタを削除するターゲット・タイプの横にある「削除」アイコンをクリックします。

32.5 ファブリック

- ファブリックについて

- ファブリックに関する情報の表示

- ファブリック情報について

- ファブリックのパフォーマンスについて

- アクセス・ポイントの表示

- ファブリックの削除

32.5.1 ファブリックについて

ファブリックは、ターゲット(つまり、ポート)間の接続を含む物理ネットワーク・ターゲットを表します。スイッチの場合、すべてのポートがファブリックをサポートします。サーバーや記憶域アプライアンスなど、ネットワーク対応デバイスの場合には、ファブリックへのその接続が、そのポートとなります。OSIモデルの物理層として、ファブリック内のあらゆる障害が、ファブリックを使用するデータリンクとネットワークに影響を及ぼします。

ファブリックの名前は、ターゲットの名前に基づきます。たとえば、abcp01sw-ib02という名前のインフィニバンド・スイッチを検出する場合、ファブリックの名前は、IBFabric@abcp01sw-ib02.us.example.comになります。スイッチがシステム・コンポーネントの場合、ファブリックはシステムで最初に検出されるターゲットに基づく名前になります。ETHFabric@abcp01cn02.us.example.comという名前のファブリックは、このイーサネット・ファブリックで最初に計算ノードが検出されたことを示しています。

Enterprise Managerは、イーサネット・ファブリックとインフィニバンド・ファブリックを検出および管理できます。ファブリックの検出の詳細は、第16章「システム・インフラストラクチャ・ターゲットの検出、昇格および追加」を参照してください。検出後、これらのファブリックが共通して持つ属性、およびこれらの固有の属性を表示できます。

32.5.2 ファブリックに関する情報の表示

ファブリックに関する情報を表示するには、次の手順を実行します。

1. 「ターゲット」、「すべてのターゲット」の順に選択します。

2. イーサネット/インフィニバンド・ファブリックを選択します。

3. ファブリックの1つを選択します。ファブリックのランディング・ページに、このファブリックのインシデントおよびこのファブリックを使用するノードが表示されます。

図32-5 ファブリックのランディング・ページ

4. 「ファブリック詳細」アイコンまたは「ファブリック・パフォーマンス」アイコンをクリックして、このファブリックに関する詳細を表示します。

図32-6 ファブリック・パフォーマンス・アイコン

32.5.3 ファブリック情報について

ファブリック・ダッシュボードのダッシュレットには次の情報が含まれています。

- このファブリックのVLAN IDまたはパーティション・キー:

- タグ付けされているVLANがあるイーサネット・ファブリックの場合、このセクションに各VLAN IDがリストされます。タグ付けされているVLANがない場合、このセクションにUntaggedが表示されます。

- インフィニバンド・ファブリックの場合、このセクションに各パーティション・キーがリストされます。

- オープン・インシデント

- ポート占有

- 最後の構成時間

「接続されたノード」セクションに、ファブリックのすべてのノード、つまりネットワーク・スイッチがリストされます。図32-7に示すように、ノードにマウス・ポインタを重ねることによって、固有の情報を表示することもできます。

図32-7 ファブリックのノード

32.5.4 ファブリックのパフォーマンスについて

メトリックは可能な場合はリアルタイムに収集および表示されます。ネットワーク・スイッチのILOMサービス・プロセッサの場合、メトリック収集はリアルタイムで行われません。それらの場合、最新収集メトリックが、タイムスタンプとともに表示されます。

ファブリックまたはファブリック内のネットワーク・スイッチのインシデントを表示し、パフォーマンスのレコードを表示できます。パフォーマンスの変更が懸念される場合、改善のための推奨事項を検討します。

「設定」、「モニタリング」、「修正処理」の順に選択します。

パフォーマンスとメトリック収集の両方に影響を与える1つの要因は、ガイド付きプロセスを使用した追加ウィザードを使用してネットワーク・スイッチを検出するときに指定するSNMPのバージョンです。SNMPの3つのバージョンすべてがサポートされますが、最もセキュアで最も効率的なバージョン3をお薦めします。ネットワーク・スイッチへのアクセスを取得するために、資格証明でなく、公開のコミュニティ文字列を使用するバージョン2cがデフォルト・バージョンで、効果的なパフォーマンスを提供します。非推奨のSNMPバージョン1は、セキュアでなく、複数の問合せを使用してメトリックを収集します。バージョン1が必要な場合、SNMPのタイムアウト値を少なくとも180秒に増やす必要があります。表32-2に、SNMP指定のオプションを示します。

表32-2 サポートされているSNMPのバージョン

SNMPのバージョン

セキュリティ・レベル

パフォーマンス・レベル

推奨

バージョン3

高: ユーザー名およびパスワードが必要です

高: メトリックが1つの照会で一括収集されます。

推奨

バージョン2

非セキュア: パブリック・コミュニティ文字列

バージョン2cが使用されている場合は許容され、これにより、メトリックを一括収集できます。他のサブバージョンには、拡張された期限切れ間隔が必要です。

パフォーマンスは許容されますが、セキュリティが十分ではありません。

バージョン1

非セキュア: パブリック・コミュニティ文字列

180秒以上の期限切れ間隔が必要です。

非推奨

32.5.5 アクセス・ポイントの表示

1. 「ターゲット」、「すべてのターゲット」の順に選択します。

2. 「システム・インフラストラクチャ・サーバー」を選択します。

3. サーバーを選択します。

4. 「システム・インフラストラクチャ・サーバー」グループの横にある下向き矢印をクリックして、メニューを表示します。

5. 「モニタリング」、「アクセス・ポイント - 概要」の順に選択します。

図32-8 アクセス・ポイントの概要

6. 詳細は、もう一度メニューを選択し、「モニタリング」、「アクセス・ポイント - 現行の機能マップ」の順に選択します。

図32-9 アクセス・ポイントの機能マップ

32.5.6 ファブリックの削除

接続されているすべてのターゲットが削除されたファブリックは、自動的に削除されます。ファブリックを削除するには、「ターゲットの削除」処理を使用して、各ターゲットを削除します。最後のターゲットが削除されると、ファブリックは削除されます。

32.6 データリンク

- データリンクについて

- データリンクに関する情報の表示

32.6.1 データリンクについて

ネットワーク・スイッチまたはネットワーク対応デバイスを検出すると、次のようなそのデータリンクが検出されます。

- ターゲット・コンポーネント

- LAG構成

- LAGメンバーシップ

- 結合構成

- IPMP構成

- IPMPメンバーシップ

データリンク層は、VLAN (タグ付け済およびタグ付けされていないVLAN ID)、インフィニバンド・パーティション(デフォルトおよび割当て済パーティション・キー)およびファイバ・チャネル・ゾーンによってリソースを共有するネットワークを管理します。また、データリンクは、他のデータリンクを使用してスループットまたは信頼性を向上させることもできます。

32.6.2 データリンクに関する情報の表示

データリンクに関する情報を表示するには、次の手順を実行します。

1. 「ターゲット」、「すべてのターゲット」の順に選択します。

2. 「ホスト」を選択します。

3. ホストを選択します。

4. サマリーで、「ネットワークの接続性」タブをクリックします。

5. データリンク・オプションをクリックします。

図32-10 データリンク

6. 「詳細...」オプションをクリックして、パスおよび転送率を表示します。

32.7 ネットワーク

- ネットワークについて

- ネットワークに関する情報の表示

- ネットワークの削除

32.7.1 ネットワークについて

ネットワーク・スイッチまたはネットワーク対応デバイスを検出すると、そのネットワークが検出されます。選択したネットワークに関する次の情報を表示できます。

- メトリックと収集設定

- メトリック収集エラー

- ステータス履歴

- インシデント・マネージャ

- アラート履歴

- ブラックアウトとブラウンアウト

- ブラックアウトの作成...

- ブラックアウトの終了...

- すべてのメトリック

- ブラウンアウトの作成...

- ブラウンアウトの終了...

- ジョブ・アクティビティ

- 情報パブリッシャ・レポート

- 最新収集

- 比較およびドリフト管理

- 比較...

- 検索...

- 履歴

- 保存...

- 保存済

- トポロジ

- コンプライアンス結果

- 標準アソシエーション

- リアルタイム監視

- モニタリング構成

- 管理者アクセス

- ターゲットの削除...

- グループに追加...

- プロパティ

- ターゲット・サイトマップ

- ターゲット情報

オペレーティング・システムを検出すると、OSターゲットのネットワーク接続性に関する次の情報を表示できます。

- ネットワーク・インタフェース: MACアドレス、IPアドレス、ネットマスクおよびブロードキャスト・アドレス

- IPV4およびIpv6

- ルーティング表

- オープンしているネットワーク・ポート

32.7.2 ネットワークに関する情報の表示

ネットワーク・スイッチに関する情報を表示する手順:

1. 「ターゲット」、「すべてのターゲット」の順に選択します。

2. イーサネット/インフィニバンド・ファブリックを選択します。

3. ファブリックの1つを選択します。

4. ネットワーク・スイッチの1つを選択します。

5. 「パフォーマンス」タブなどのタブを使用して、このターゲットに関する情報を表示します。

このページに移動する別の方法は、「すべてのターゲット」リストから、「システム・インフラストラクチャ・スイッチ」を選択することです。

1. 「ターゲット」、「すべてのターゲット」の順に選択します。

2. 「システム・インフラストラクチャ・ネットワーク」を選択します。

3. サブネットを選択します。

4. 「システム・インフラストラクチャ・ネットワーク」の横にある下向き矢印をクリックしてメニューを表示するか、「ターゲット・サイトマップ」を選択してこのターゲットで使用できる処理のリストを表示します。たとえば、パフォーマンス・メトリックを表示するには、「モニタリング」を選択して、ドロップダウン・メニューから「すべてのメトリック」を選択するか、「ターゲット・サイトマップ」から「すべてのメトリック」を選択します。

32.7.3 ネットワークの削除

ネットワークに接続されているすべてのターゲットが削除されると、ネットワークは自動的に削除されます。ネットワークを削除するには、「ターゲットの削除」処理を使用して、各ターゲットを削除します。最後のターゲットが削除されると、ネットワークは削除されます。

32.7.4 OSアセットのネットワークの詳細の表示

この手順の説明に従い、ホストを選択してそのオペレーティング・システムを選択するか、オペレーティング・システムを選択してリストからサーバーを選択することができます。

1. 「ターゲット」、「すべてのターゲット」の順に選択します。

2. 「オペレーティング・システム」セクションまでスクロールして、オペレーティング・システムのタイプを選択します。すべてのサーバーとそのオペレーティング・システムがリストされます。

3. サーバーを選択します。

4. 「OS」ダッシュボードで「ネットワークの使用方法」グラフまでスクロールして、ネットワーク・アクティビティの概要を表示します。このグラフの値および時間間隔は変更できます。

図32-11 ネットワークの使用状況のグラフ

5. 詳細を表示するには、「ネットワークの接続性」タブをクリックします。その後、「インタフェース」または「データリンク」オプションをクリックできます。

32.8 ネットワーク管理の関連リソース

詳細は、次を参照してください:

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- ファブリックの検出

- インシデント管理の使用

- ターゲットの監視および管理

33 記憶域の管理

この章には次の情報が含まれています。

- 記憶域の管理のスタート・ガイド

- ユーザー・インタフェース内でのストレージ情報の場所

- 記憶域管理の処理

- 記憶域アプライアンス・ダッシュボードについて

- フォトリアリスティック画像について

- サマリーについて

- プロジェクトについて

- チャートについて

- ホストの記憶域情報について

- 記憶域構成トポロジについて

- 記憶域メトリックについて

- 記憶域クラスタ・メンバーシップについて

- 記憶域リソースの削除について

- エンジニアド・システムのOracle ZFS Storage Applianceの使用方法

- ストレージの関連リソース

33.1 記憶域の管理のスタート・ガイド

Oracle Enterprise Managerは記憶域リソースとそのコンポーネント(記憶域プール、記憶域ハードウェア、ファイルシステム、および論理ボリュームなど)を検出、管理します。

記憶域サーバーはそのリソースを、論理ユニット(LUN)または共有として公開します。記憶域クライアントはこれらのLUNおよび共有に対するアクセスがあり、固有のファイルシステムまたはデバイスとして表し、さらにこれらのファイルシステムを固有のクライアント(アプリケーション、データベースまたは仮想マシンなど)に公開します。

システム・インフラストラクチャ・プラグインにより、記憶域アプライアンスおよびホストの記憶域リソースが管理されます。

記憶域管理には、記憶域リソースをオペレーティング・システムと仮想アセットが利用できるようにするためのすべてのアクティビティが含まれます。次にいくつかのアクティビティを示します。

- 記憶域ターゲットの検出とそれらの関係を導出します。

- すべての記憶域ターゲット・コンポーネントの構成およびパフォーマンスのメトリックを収集します。

- インシデントを検出します。

- LUN、ファイルシステム、プロジェクト、プールなどの記憶域ターゲット・コンポーネントをモニターします。

33.2 ユーザー・インタフェース内でのストレージ情報の場所

表33-1に、情報が記載されている場所を示します。

表33-1 ユーザー・インタフェース内での記憶域情報の場所

オブジェクト

場所

Oracle ZFS Storage Applianceターゲットの表示

「すべてのターゲット」セレクタで、「Oracle ZFS Storage Server」を選択します。「Oracle ZFS Storage Server」をクリックし、「サマリー」ページを表示します。

ホストの記憶域情報の表示

「すべてのターゲット」セレクタで、「ホスト」を選択します。特定のホストをクリックし、「サマリー」ページを表示します。右側の「記憶域」アイコンをクリックします。詳細を表示するには、左側にある「ディスク」、「ファイルシステム」、「SAN構成」、「Linux LVMボリューム・グループ」または「ZFS記憶域プール」のアイコンをクリックします。

記憶域トポロジの表示

「すべてのターゲット」セレクタで、記憶域アプライアンスを右クリックします。「構成」を選択し、「トポロジ」をクリックします。

記憶域パフォーマンス・メトリックの表示

「すべてのターゲット」セレクタで、記憶域アプライアンスを右クリックします。「モニタリング」を選択し、「すべてのメトリック」をクリックします。

記憶域構成メトリックの表示

「すべてのターゲット」セレクタで、記憶域アプライアンスを右クリックします。「構成」を選択し、「最新収集」をクリックします。

記憶域クラスタ・メンバーシップの表示

「すべてのターゲット」セレクタで、記憶域アプライアンス・クラスタを選択します。「ターゲット・ナビゲーション」アイコンをクリックします。

33.3 記憶域管理の処理

要件に応じて、次の処理を実行できます。

- 記憶域ターゲットの検出。

- ストレージ・ターゲットの構成の表示。

- インシデントおよびパフォーマンス・メトリックの診断。

- ターゲットのモニター方法とパフォーマンス測定方法の変更。

- 記憶域アプライアンス・ターゲットをブラックアウトし、これによりその関連する自動的に昇格されたターゲット・メンバーすべてに対してブラックアウトを実行します。

33.4 記憶域アプライアンス・ダッシュボードについて

記憶域アプライアンス・ダッシュボードには、インシデント、領域使用量、ディスクI/Oアクティビティのグラフィカル表示、LUNの数、共有の数および最終構成詳細を含む、記憶域アプライアンスのステータスに関する基本情報が8個のダッシュレットの形式で表示されます。選択した記憶域アプライアンスのダッシュボードを表示する手順は、「記憶域アプライアンス・ダッシュボードの表示」を参照してください。

図33-1に示すように、ダッシュレットが表示されます。別のダッシュレットの組合せに切り替えるには、ダッシュボードの下のアイコンをクリックします。

図33-1 ダッシュレット・ビュー

記憶域アプライアンス・ダッシュボードにおいて、次のダッシュレットを表示することができます。

- 基本的なハードウェア情報: アプライアンスまたは記憶域サーバーのモデル名、IPアドレス、CPU、バージョン、ロールおよびロケータの詳細が表示されます。また、アプライアンスの新規バージョンがダウンロードできる場合は情報が表示されます。

- オープン・インシデント: 致命的、重要および警告カテゴリのオープン・インシデントの数が表示されます。このダッシュレットにオープン・インシデントとして表示されている数をクリックすると、そのカテゴリのインシデントに関する詳細情報が表示されます。

- 記憶域の使用状況: アプライアンスまたは記憶域サーバーの、使用済領域および使用可能な領域の割合が表示されます。アプライアンス・レベルでの記憶域の使用状況が表示されます。

- ディスクI/Oのバイト数/秒(過去24時間): 記憶域アプライアンスの、全体的なディスクI/Oアクティビティの1秒当たりのバイト数をグラフィカル表示で示します。

- 論理ユニット使用の分散: 使用されているLUNの合計数がグラフィカル表示の形式で表示されます。また、記憶域使用率に基づいたLUNの分散も表示されます。

- 共有使用の分散: 使用されている共有の合計数がグラフィカル表示の形式で表示されます。また、記憶域使用率に基づいた共有の分散も表示されます。

- ディスクI/Oの操作数/秒(過去24時間): 記憶域アプライアンスの、全体的なディスクI/Oの1秒当たりの操作数をグラフィカル表示で示します。

- 最終構成詳細: 最新の構成変更の日時情報および最終報告インシデントが表示されます。

33.4.1 記憶域アプライアンス・ダッシュボードの表示

記憶域アプライアンス・ダッシュボードを表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックし、記憶域アプライアンスのダッシュボードを表示します。

33.4.2 記憶域アプライアンス・クラスタ・ダッシュボードの表示

記憶域アプライアンス・クラスタのダッシュボードを表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「グループ、システムおよびサービス」ターゲット・タイプを開きます。
「グループ、システムおよびサービス」でクラスタ・ターゲットのリストを表示できます。

3. 「グループ、システムおよびサービス」で特定のクラスタ・ターゲットをクリックします。
選択したクラスタ・ターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインでリストから特定のクラスタ・ターゲット名をクリックして、記憶域アプライアンス・クラスタのダッシュボードを表示します。

33.5 フォトリアリスティック画像について

記憶域アプライアンス・ユーザー・インタフェースのメイン・ウィンドウの「ハードウェア」タブには、図33-2に示すように、選択したアプライアンスのフォトリアリスティック・ビュー(前面、最上部、背面など)が表示されます。選択した記憶域アプライアンスのフォトリアリスティック画像を表示する手順は、「フォトリアリスティック画像の表示」を参照してください。

フォトリアリスティック画像で表示されるいずれかのコンポーネントにカーソルを重ねて、そのコンポーネントに関する追加の情報を表示することができます。

図33-2 「ハードウェア」タブ・ビュー

存在してコンポーネントに関連する場合、アプライアンスの次のハードウェア情報を表示できます。

- コンポーネント名

- モデル名

- アーキテクチャ

- 製造業者

- シリアル番号

- クリティカルなインシデント情報

- 部品番号

- メモリー・コンポーネントのサイズ

- CPUのコア合計

- 使用可能なCPUのコア

33.5.1 フォトリアリスティック画像の表示

アプライアンスの「ハードウェア」タブ詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 記憶域アプライアンスのユーザー・インタフェースの右側に表示される「ハードウェア」タブをクリックして、選択したターゲットのフォトリアリスティック画像を表示します。

33.6 サマリーについて

記憶域アプライアンス・ユーザー・インタフェースのメイン・ウィンドウの「サマリー」タブには、ハードウェア・コンポーネントおよびアクティブな記憶域サービスに関する詳細情報が表示されます。選択した記憶域アプライアンスのサマリーを表示する手順は、「サマリーの表示」を参照してください。

アプライアンスまたは記憶域サーバーを選択して詳細情報を表示すると、図33-3に示すように、「サマリー」タブ・ビュー付きのユーザー・インタフェースが開きます。

図33-3 「サマリー」タブ・ビュー

「サマリー」タブで、次のアプライアンスの記憶域サマリー情報を表示できます。

- IPアドレス付きのアプライアンス名と記憶域リソースのステータスを示すロケータ・ライト。

- 記憶域プール配分に関する情報を表示する円グラフ。円グラフの中心ノードをクリックして、記憶域アプライアンスの詳細サマリーを表示できます。記憶域アプライアンスの次の詳細が表示されます。

- 使用済/合計領域

- 記憶域アプライアンスにアタッチされているディスクの数

- 記憶域アプライアンスのプールの数

- 記憶域アプライアンスのLUNの数

- 記憶域アプライアンスの共有の数

- 記憶域アプライアンスに対してアクティブな記憶域サービス

- 過去5時間、過去24時間および過去7日間の使用状況を示す記憶域使用状況グラフ。

- 過去5時間、過去24時間および過去7日間の1秒当たりのディスクI/O操作のグラフ

- 過去5時間、過去24時間および過去7日間の1秒当たりのディスクI/Oバイトのグラフ

- アプライアンス円グラフのプール・ノードをクリックして、記憶域プールの詳細サマリーを表示できます。記憶域プールの次の詳細が表示されます。

- プールの使用済/合計領域情報

- プール内のプロジェクトの数

- プール内のLUNの数

- プール内の共有の数

- プールのステータス

- 物理および論理グループ記憶域プールのサイズ使用量を示すZFS記憶域プール記憶域使用状況グラフ

- 過去5時間、過去24時間および過去7日間のZFS記憶域プールの使用状況のグラフ

33.6.1 サマリーの表示

アプライアンスまたはクラスタの「サマリー」タブ詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 「サマリー」タブをクリックして、選択したターゲットのサマリー詳細を表示します。

33.7 プロジェクトについて

記憶域アプライアンス・ユーザー・インタフェースのメイン・ウィンドウの「プロジェクト」タブには、図33-4に示すように、ファイルシステムおよびLUNで使用される記憶域領域に関する詳細情報が表示されます。さらに、特定のファイルシステムまたはLUN (NFS、SMB、HTTP、FTP、TFTP、SFTPなど)に対してアクティブである記憶域サービスも示されます。選択した記憶域アプライアンスのプロジェクトを表示する手順は、「プロジェクトの表示」を参照してください。

図33-4 「プロジェクト」タブ・ビュー

アプライアンスの次の記憶域プロジェクト情報を「プロジェクト」タブに表示できます。

- 特定の記憶域アプライアンスおよびそれらが使用する記憶域領域のファイルシステムおよびLUNのリスト。

- 論理割当、物理サイズおよび物理使用状況を示す記憶域領域(GB)グラフ。

- グラフの論理割当てバーは、記憶域に割り当てられたサイズを示します。

- グラフの論理割当てバーの上の物理サイズ・バーは、実際の記憶域サイズを示します。

- 物理使用状況バーは、記憶域によって使用されている領域を示します。

- 記憶域の使用率。

- アクティブで、「緑」で示されている「記憶域サービス」。

33.7.1 プロジェクトの表示

アプライアンスの詳細を「プロジェクト」タブに表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 「プロジェクト」タブをクリックして、選択したターゲットの記憶域詳細を表示します。

33.8 チャートについて

記憶域アプライアンス・ユーザー・インタフェースの「グラフ」タブには、「リソース」、「デバイス」、「SAN使用状況」、「NAS使用状況」および「ZFS記憶域プール」の各タブが表示されます。これらのタブのいずれかを選択して、特定のアプライアンスのそれぞれグラフィカル表示を表示できます。

「グラフ」タブは、記憶域アプライアンス・ユーザー・インタフェースの右側に表示されます。「グラフ」タブをクリックすると、図33-5に示すように、左側に別の記憶域アプライアンスのグラフィカル表示のタブが表示されます。

図33-5 「グラフ」タブ・ビュー

「グラフ」タブでアプライアンスのそれぞれグラフィカル表示を示す次のアイテムを表示できます。

- リソース: 「リソース」タブは、時間に対するCPU使用率(%)およびメモリー使用状況詳細をグラフィカル表示で示します。

- デバイス: 「デバイス」タブは、全ディスクにわたる1秒当たりの合計ディスクI/O操作数および合計ディスクI/Oバイト数を時間に対するグラフィカル表示で示します

- SAN使用状況: 「SAN使用状況」タブは、時間に対する1秒当たりの操作合計および1秒当たりのバイト合計をグラフィカル表示で示します。

- NAS使用状況: 「NAS使用状況」タブは、NAS使用状況およびSMB使用率の時間に対する1秒当たりの操作合計を2つのグラフィカル表示で示します。

- ZFS記憶域プール: 「ZFS記憶域プール」タブは、時間に対する使用領域および割当て領域をグラフィカル表示で示します。

33.8.1 「リソース」グラフの表示

アプライアンスの「リソース」グラフ詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 選択したターゲットのグラフィカル表示を表示するための使用可能な様々なオプションには、「グラフ」タブをクリックします。

6. 「リソース」タブをクリックして、選択したターゲットのそれぞれのグラフィカル表示を表示します。

7. (オプション): グラフを表示する必要のある特定の期間を選択できます。「期間」メニューで選択し、過去1時間、過去24時間および過去5日間のグラフィカル表示を表示できます。デフォルトでは、過去1時間のグラフが表示されます。

8. (オプション): 個々のグラフの右下隅にある「表ビュー」をクリックすると、詳細を表形式で表示できます。

33.8.2 「デバイス」グラフの表示

アプライアンスの「デバイス」グラフ詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 選択したターゲットのグラフィカル表示を表示するための使用可能な様々なオプションには、「グラフ」タブをクリックします。

6. 「デバイス」タブをクリックして、選択したターゲットのそれぞれのグラフィカル表示を表示します。

7. (オプション): グラフを表示する必要のある特定の期間を選択できます。「期間」メニューで選択し、過去1時間、過去24時間および過去5日間のグラフィカル表示を表示できます。デフォルトでは、過去1時間のグラフが表示されます。

8. (オプション): 個々のグラフの右下隅にある「表ビュー」をクリックすると、詳細を表形式で表示できます。

33.8.3 「SAN使用状況」グラフの表示

アプライアンスの「SAN使用状況」グラフ詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 選択したターゲットのグラフィカル表示を表示するための使用可能な様々なオプションには、「グラフ」タブをクリックします。

6. 「SAN使用状況」タブをクリックして、選択したターゲットのそれぞれのグラフィカル表示を表示します。

7. (オプション): グラフを表示する必要のある特定の期間を選択できます。「期間」メニューで選択し、過去1時間、過去24時間および過去5日間のグラフィカル表示を表示できます。デフォルトでは、過去1時間のグラフが表示されます。

8. (オプション): 個々のグラフの右下隅にある「表ビュー」をクリックすると、詳細を表形式で表示できます。

33.8.4 「NAS使用状況」グラフの表示

アプライアンスの「NAS使用状況」グラフ詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 選択したターゲットのグラフィカル表示を表示するための使用可能な様々なオプションには、「グラフ」タブをクリックします。

6. 「NAS使用状況」タブをクリックして、選択したターゲットのNAS使用率およびSMB使用率のグラフィカル表示を表示します。

7. (オプション): グラフを表示する必要のある特定の期間を選択できます。「期間」メニューで選択し、過去1時間、過去24時間および過去5日間のグラフィカル表示を表示できます。デフォルトでは、過去1時間のグラフが表示されます。

8. (オプション): 個々のグラフの右下隅にある「表ビュー」をクリックすると、詳細を表形式で表示できます。

33.8.5 「ZFS記憶域プール」グラフの表示

アプライアンスの「ZFS記憶域プール」グラフ詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のターゲット名をクリックします。

5. 選択したターゲットのグラフィカル表示を表示するための使用可能な様々なオプションには、「グラフ」タブをクリックします。

6. 「ZFS記憶域プール」タブをクリックして、選択したターゲットのそれぞれのグラフィカル表示を表示します。

7. 「ZFS記憶域プール」ドロップダウンで、選択したターゲットのグラフィカル表示を表示する特定の記憶域プールを選択します。

8. (オプション): グラフを表示する必要のある特定の期間を選択できます。「期間」メニューで選択し、過去1時間、過去24時間および過去5日間のグラフィカル表示を表示できます。デフォルトでは、過去1時間のグラフが表示されます。

9. (オプション): 個々のグラフの右下隅にある「表ビュー」をクリックすると、詳細を表形式で表示できます。

33.9 ホストの記憶域情報について

検出されたホスト・ターゲットの記憶域情報を表示できます。ホストのユーザー・インタフェースのメイン・ウィンドウの「記憶域」タブには、「ディスク」、「ファイルシステム」、「Linuxボリューム・グループ」、「ZFS記憶域プール」および「SAN構成」の各タブが表示されます。これらのタブのいずれかを選択すると、詳細情報を表示できます。

「記憶域」タブは、ホストのユーザー・インタフェースの右側に表示されます。「記憶域」タブを選択すると、図33-6に示すように、左側に別のホスト記憶域タブが表示されます。

図33-6 ホスト記憶域タブ・ビュー

「記憶域」タブで、次のホストの記憶域情報を表示できます。

- ディスク: 論理ディスク情報および物理ディスク情報が表示されます。

- ファイルシステム: ファイルシステム名、そのマウント位置、サイズ、インシデントおよび記憶域の使用状況が表示されます。

- Linux LVMボリューム・グループ: 別のボリューム名が表示されます。ボリューム・ボックスのいずれかをクリックして、合計領域(GB)、インシデント数、ボリューム数、記憶域使用率およびボリュームのステータスを表示できます。このタブはLinuxホストの場合にのみ表示されます。

- ZFS記憶域プール: 別の記憶域プールのボリュームを表示します。ボリューム・ボックスのいずれかをクリックして、合計領域(GB)、インシデント数、ボリューム数、記憶域使用率およびボリュームのステータスを表示できます。このタブはOracle Solarisホストにのみ表示されます。

- SAN構成: ネットワーク・ハードウェア名、接続されているターゲット数、接続されているデバイス数、セッション・レスポンス時間、最大接続再試行時間、FCポートID、FCポートの状態などを表示します。

33.9.1 ホストのディスク

ホストのメイン・ウィンドウにある「記憶域」タブでは、「ディスク」タブをリストします。LinuxホストまたはOracle Solarisホストのディスク情報を表示できます。

「ディスク」タブで、次のホストのディスク情報を表示できます。

- ローカル・ディスクやリモート・ディスクなどのディスクのタイプ

- 各ディスクの名前

- 各ディスクのサイズ

- 各ディスクのデバイス・ロケーション

- インシデント数が0より大きい場合、それぞれのディスクのインシデント数

- 過去24時間の1秒当たりの読取り操作

- 1秒当たりの最大読取り操作数

- 過去24時間の1秒当たりの書込み操作

- 1秒当たりの最大書込み操作数

- 記憶域の使用状況

- スナップショット数が0より大きい場合、Oracle SolarisホストのSnapshotCountとSnapshotUtilization

- ベンダー名

33.9.1.1 ホストのディスクの表示

ホストのディスク情報を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
リストされたホスト・ターゲットを表示できます。

3. 「ホスト」をクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のホスト・ターゲットをクリックします。

5. ユーザー・インタフェースの右側に表示される「記憶域」タブをクリックします。

6. ディスク・タブをクリックします。

7. (オプション): すべてのディスク、ローカル・ディスクのみ、リモート・ディスクのみを表示する場合に選択できます。また、「フィルタ基準」フィールドにボリューム名を入力すると、ディスクのリストをフィルタ処理できます。

デフォルトでは、表示されるディスク・ボリューム数は、使用率、およびアラートが含まれるボリュームごとに25に制限されています。このデフォルト値は変更できます。左側のナビゲーション・ペインで「ホスト」を選択後、右側のペインにリストされた特定のホストを右クリックします。「モニタリング」を選択して、「メトリックと収集設定」をクリックします。「メトリックと収集設定」ウィンドウでボリューム統計メトリックを見つけ、「ボリュームの領域使用率(%)」行の「編集」をクリックします。「メトリック収集のプロパティ」にプロパティ名およびプロパティ値が表示されます。NumberOfVolumesプロパティの値は、25として表示されます。このプロパティ値を目的の値に編集できます。

33.9.2 ホストのファイルシステム

ホストのメイン・ウィンドウにある「記憶域」タブでは、「ファイルシステム」タブをリストします。LinuxホストまたはOracle Solarisホストのファイルシステム情報を表示できます。

「ファイルシステム」タブで、次のホストのファイルシステム情報を表示できます。

- ローカル・ファイルシステムやリモート・ファイルシステムなどのファイルシステムのタイプ

- 各ファイルシステムの名前

- 各ファイルシステムのサイズ

- 各ファイルシステムのマウント・ロケーション

- それぞれのファイルシステムのインシデント数

- 過去24時間の1秒当たりの読取り操作

- 1秒当たりの最大読取り操作数

- 過去24時間の1秒当たりの書込み操作

- 1秒当たりの最大書込み操作数

- 記憶域使用率

- Oracle Solarisホストに対して有効になっている場合、圧縮率

33.9.2.1 ホストのファイルシステムの表示

ホストのファイルシステム情報を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
リストされたホスト・ターゲットを表示できます。

3. 「ホスト」をクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のホスト・ターゲットをクリックします。

5. ユーザー・インタフェースの右側に表示される「記憶域」タブをクリックします。

6. 「ファイルシステム」タブをクリックします。

7. (オプション): すべてのファイルシステム、ローカル・ファイルシステムのみ、リモート・ファイルシステムのみを表示する場合に選択できます。また、「フィルタ基準」フィールドにファイルシステム名を入力すると、ディスクのリストをフィルタ処理できます。

デフォルトでは、表示されるファイルシステム数は、使用率ごとに25に制限されています。このデフォルト値は変更できます。左側のナビゲーション・ペインで「ホスト」を選択後、右側のペインにリストされた特定のホストを右クリックします。「モニタリング」を選択して、「メトリックと収集設定」をクリックします。「メトリックと収集設定」ウィンドウでファイルシステム統計メトリックを見つけ、「ファイルシステムの領域使用率(%)」行の「編集」をクリックします。「メトリック収集のプロパティ」にプロパティ名およびプロパティ値が表示されます。NumberOfFilesystemsプロパティの値は、25として表示されます。このプロパティ値を目的の値に編集できます。ファイルシステム・プロパティを設定して、使用率に関係なく、収集する必要があるファイルシステムを指定することもできます。

33.9.3 ホストのSAN構成

ホストのメイン・ウィンドウにある「記憶域」タブでは、「SAN構成」タブをリストします。LinuxホストまたはOracle Solarisホストの「SAN構成」情報を表示できます。

「SAN構成」タブで、次のホストの「SAN構成」情報を表示できます。

- iSCSIまたはFCなどのSANイニシエータ・タイプ

- iSCSI SANイニシエータ・タイプのIQN名

- 接続済ターゲットの合計数

- アタッチ済デバイスの合計数

33.9.3.1 ホストのSAN構成の表示

ホストのSAN構成情報を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
リストされたホスト・ターゲットを表示できます。

3. 「ホスト」をクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のホスト・ターゲットをクリックします。

5. ユーザー・インタフェースの右側に表示される「記憶域」タブをクリックします。

6. 「SAN構成」タブをクリックします。

33.9.4 ホストのLinuxボリューム・グループ

ホストのメイン・ウィンドウにある「記憶域」タブでは、「Linux LVMボリューム・グループ」タブをリストします。LinuxホストのLinuxボリューム・グループ情報を表示できます。

注意:
「Linux LVMボリューム・グループ」タブはLinux環境でのみ使用できます。

「Linux LVMボリューム・グループ」タブでは、選択したボリュームの次の情報を表示できます。

- 合計領域(GB)

- 上か下かを示すLVMのターゲット・ステータス

- インシデント

- ボリューム

- 記憶域使用率

- 「Linux LVMボリューム・グループ使用状況」グラフ

- Linux LVMボリューム・グループ階層

33.9.4.1 ホストのLinuxボリューム・グループの表示

ホストのLinuxボリューム・グループ情報を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
リストされたホスト・ターゲットを表示できます。

3. 「ホスト」をクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のホスト・ターゲットをクリックします。

5. ユーザー・インタフェースの右側に表示される「記憶域」タブをクリックします。

6. 「Linux LVMボリューム・グループ」タブをクリックします。様々なボリュームがブロックの形式で左側にリストされます。

7. 詳細情報を表示するには、特定のボリュームをクリックします。

33.9.5 ホストのZFS記憶域プール

ホストのメイン・ウィンドウにある「記憶域」タブでは、「ZFS記憶域プール」タブをリストします。様々なzpoolの詳細情報を表示できます。

注意:
「ZFS記憶域プール」タブはOracle Solaris環境でのみ使用できます。

「ZFS記憶域プール」タブでは、選択したzpoolの次の情報を表示できます。

- 合計領域(GB)

- 上か下かを示すプールのターゲット・ステータス

- インシデント

- ファイルシステム

- ボリューム

- 重複排除率

- 記憶域使用率

- オンライン、オフラインまたは失敗かを示すZpoolのステータス

- ZFS記憶域プール使用状況グラフ

- ZFS記憶域プール階層

33.9.5.1 ホストのZFS記憶域プールの表示

ホストのZFS記憶域プール情報を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
リストされたホスト・ターゲットを表示できます。

3. 「ホスト」をクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のホスト・ターゲットをクリックします。

5. ユーザー・インタフェースの右側に表示される「記憶域」タブをクリックします。

6. 「ZFS記憶域プール」タブをクリックします。様々な使用済zpoolがブロックの形式で左側にリストされます。

7. 詳細情報を表示するには、特定のzpoolをクリックします。

33.10 記憶域構成トポロジについて

Enterprise Managerでは、記憶域サーバーと記憶域クライアントの関係を表示できます。「トポロジ」オプションは、記憶域サーバーのLUNまたは共有などの各公開要素間の関係および指定したホストにデバイスやファイルシステムとして存在するかどうかを表示します。データベースなどの様々なアプリケーション間の関係またはVMなどの仮想化エンティティも示します。

記憶域アプライアンスまたはホストの記憶域構成トポロジを表示できます。また、特定の記憶域サーバー要素または特定のホスト要素の記憶域構成トポロジを表示できます。それぞれの要素を選択し、トポロジ詳細を表示するために選択します。選択した記憶域アプライアンスまたはホストのトポロジを表示する手順は、「記憶域構成トポロジの表示」を参照してください。

33.10.1 記憶域構成トポロジの表示

選択したターゲットのトポロジ情報を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 次の方法のいずれか1つを実行することで、記憶域構成トポロジ情報を表示できます。

- 右側のペインでターゲット名を右クリックすると、関連するオプションが表示されます。

- 右側のペインで特定のターゲットをクリックし、ユーザー・インタフェースの左上部に表示されるターゲット・ドロップダウン・リストをクリックします。

5. 「構成」を選択し、「トポロジ」をクリックします。

33.11 記憶域メトリックについて

この項では、記憶域構成メトリックおよび記憶域パフォーマンス・メトリックを表示する手順について説明します。また、記憶域パフォーマンス・メトリックを変更する手順についても説明します。この項で説明する項目を次に示します。

- 記憶域パフォーマンス・メトリックの表示

- 記憶域構成メトリックの表示

- メトリック収集の変更

33.11.1 記憶域パフォーマンス・メトリックの表示

記憶域パフォーマンス・メトリックを表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 次の方法の1つを実行することで、選択したターゲットのパフォーマンス・メトリックを表示できます。

- 右側のペインでターゲット名を右クリックすると、関連するオプションが表示されます。

- 右側のペインで特定のターゲットをクリックし、ユーザー・インタフェースの左上部に表示されるターゲット・ドロップダウン・リストをクリックします。

5. 「モニタリング」を選択し、「すべてのメトリック」をクリックします。

メトリック収集概要、様々なメトリック・イベント(オープン・アラートおよび過去7日間の上位5つの変更メトリックなど)およびデプロイ済メトリック拡張情報を表示できます。

33.11.2 記憶域構成メトリックの表示

記憶域構成メトリックを表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。中央のペインで、特定のクラスタ・ターゲットを選択します。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 次の方法のいずれか1つを実行することで、記憶域構成メトリックの表示を続行できます。

- 右側のペインでターゲット名を右クリックすると、関連するオプションが表示されます。

- 右側のペインで特定のターゲット名をクリックし、ユーザー・インタフェースの左上部に表示されるターゲット・ドロップダウン・リストをクリックします。

5. 「構成」を選択し、「最新収集」をクリックします。

6. 左側のナビゲーション・ペインから構成メトリックを選択し、選択したメトリックの構成プロパティを表示します。

33.11.3 メトリック収集の変更

Oracle Enterprise Managerは記憶域リソースをモニターし、パフォーマンスを追跡するために、その情報を収集します。収集するメトリックや、場合によっては、メトリックの収集方法(頻度など)を変更することができます。

選択したターゲットのパフォーマンス・メトリックを変更するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 次の方法のいずれか1つを実行することで、パフォーマンス・メトリックの表示を続行できます。

- 右側のペインでターゲット名のいずれかを右クリックすると、関連するオプションが表示されます。

- 右側のペインで特定のターゲット名をクリックし、ユーザー・インタフェースの左上部に表示されるターゲット・ドロップダウン・リストをクリックします。

5. 「モニタリング」を選択し、「すべてのメトリック」をクリックします。
様々なメトリックの詳細を表示できます。

6. 左側のナビゲーション・ペインで、特定のメトリックを選択します。このメトリックを変更できる場合は、「収集スケジュール」の右側のペインに「変更」ボタンが表示されます。

7. 「変更」をクリックします。

8. 「収集スケジュールの変更」ウィンドウで、値を変更してメトリックの収集を調整します(通常は頻度やメトリックの使用方法)。必要に応じて、収集を変更できるように、この変更の影響を受けるメトリックを書き留めておきます。

9. 変更を保存する場合は、「OK」をクリックします。

33.12 記憶域クラスタ・メンバーシップについて

2つのOracle ZFS Storage Applianceでクラスタ構成設定を持つことができます。そのような構成が使用中の場合、これら2つのアプライアンスのクラスタ・メンバーシップ情報を表示できます。

33.12.1 記憶域クラスタ・メンバーシップの表示

クラスタ構成設定にあるアプライアンスのクラスタ・メンバーシップ情報を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「グループ、システムおよびサービス」ターゲット・タイプを開きます。
「グループ、システムおよびサービス」でクラスタ・ターゲットのリストを表示できます。

3. 「グループ、システムおよびサービス」で特定のクラスタ・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 右側のペインのリストから特定のクラスタ・ターゲット名をクリックします。

5. 図33-7に示すように、クラスタ・ドロップダウン・リストの左側に表示される「ターゲット・ナビゲーション」タブをクリックします。

図33-7 「ターゲット・ナビゲーション」タブ・ビュー

6. 特定のクラスタを選択し、クラスタの記憶域サマリー詳細を表示します。ダッシュボードのクラスタ情報、クラスタ構成設定のある記憶域アプライアンスの画像、様々なネットワークおよびプール情報を表示することができます。

33.13 記憶域リソースの削除について

アプライアンスまたはホストがターゲットとして検出されると、一部のターゲット・メンバーが自動的に昇格されます。自動的に昇格されるターゲット・メンバーのリストを表示するには、「Oracle ZFS Storage Applianceのターゲット・メンバー」を参照してください。ターゲットの削除またはそのメンバーの削除のいずれかを選択できます。アプライアンスやホストなどのターゲットを削除することを選択した場合、関連するサブターゲットもすべて削除されます。記憶域リソースを削除する手順は、「記憶域リソースの削除」を参照してください。

すべてのメンバーを削除するには、削除処理をターゲット・レベルで開始する必要があります。

注意:
ターゲット・メンバーにアプライアンスまたはホストとの適切な関連付けがあれば、そのようなメンバーは正常に削除されます。たとえば、ディスクシェルフのターゲット・メンバーは、ZFS記憶域サーバーに関連付けられています。これらのターゲット・メンバーの関連付けが正しくない場合は、ディスクシェルフのターゲット・メンバーは削除されません。

33.13.1 ストレージ・リソースの削除

記憶域リソースを削除するには、次の手順を実行します。

1. 「ターゲット」メニューから、「すべてのターゲット」をクリックします。

2. 左側のナビゲーション・ペインで、「サーバー、ストレージおよびネットワーク」ターゲット・タイプを開きます。
「サーバー、ストレージおよびネットワーク」の下にアプライアンス・ターゲットのリストを表示できます。

注意:
クラスタ・ターゲットを表示するには、左側のナビゲーション・ペインで「グループ、システムおよびサービス」を開きます。右側のペインで特定のクラスタ・ターゲットをクリックします。

3. 「サーバー、ストレージおよびネットワーク」で特定のアプライアンス・ターゲットをクリックします。
選択したターゲットのターゲット名、ターゲット・タイプおよびターゲット・ステータスが右側のペインに表示されます。

4. 次の方法のいずれか1つを実行することで、記憶域リソースの削除を続行できます。

- 右側のペインで削除するターゲット名を右クリックします。

- 右側のペインで特定のターゲット名をクリックし、ユーザー・インタフェースの左上部に表示されるターゲット・ドロップダウン・リストをクリックします。

5. 「ターゲット設定」を選択し、「ターゲットの削除」をクリックします。

6. 「確認」ダイアログ・ボックスで、「はい」をクリックして特定のターゲットを削除します。

33.13.2 Oracle ZFS Storage Applianceクラスタの削除

クラスタの一部であるOracle ZFS Storage Applianceを削除できます。Oracle ZFS Storage Applianceを削除する手順は、「記憶域リソースの削除」を参照してください。2つのOracle ZFS Storage Serverにクラスタ構成設定がある場合、クラスタ・ターゲットを削除すると、クラスタ内の記憶域サーバーとディスクシェルフなどの関連するターゲット・メンバーのいずれも削除されます。Oracle ZFS Storage Applianceのメンバーには次が含まれます。

- ZFS記憶域サーバー

- ディスクシェルフ

- ZFS Storage Applianceクラスタ

クラスタ構成設定に含まれている記憶域サーバーの1つの削除を起動すると、関連するクラスタ・ターゲットが削除されます。その他の記憶域サーバーは削除されません。2つ目の記憶域サーバーが存在する場合、ディスクシェルフは削除されません。

クラスタ構成設定に含まれていない記憶域サーバーの削除を起動すると、関連するディスクシェルフが削除されます。

33.14 エンジニアド・システムのOracle ZFS Storage Applianceの使用方法

この項では、エンジニアド・システム上のOracle ZFS Storage Applianceの前提条件について説明します。非rootユーザーは、分析データセットを表示するために必要な権限を持っている必要があります。特定の権限が割り当てられていない場合、分析メトリックはエラーを表示します。非rootユーザーがデータセットにアクセスするために、追加権限を追加できます。

アプライアンスのユーザー・インタフェースに権限を追加するには、次の手順を実行します。

1. Oracle ZFS Storage Applianceユーザー・インタフェースにログインします。

2. 「構成」をクリックします。

3. 「ユーザー」をクリックします。

4. 非rootユーザーを選択し、「編集」アイコンをクリックします。

5. 「例外」をクリックします。

6. 「有効範囲」ドロップダウンで、「分析」を選択します。

7. 読取り: このドリルダウンで統計を読むチェック・ボックスを選択します。

8. 「追加」をクリックします。

また、分析データセットの読取り用コマンドライン・インタフェースを使用して、例外を非rootユーザーに追加することもできます。次に例を示します。

zfssa:> configuration users
zfssa:configuration users> select oemuser
zfssa:configuration users oemuser> exceptions
zfssa:configuration users oemuser exceptions> create
zfssa:configuration users oemuser auth (uncommitted)> set scope=stat
scope = stat
zfssa:configuration users oemuser auth (uncommitted)> set allow_read=true
allow_read = true (uncommitted)
zfssa:configuration users oemuser auth (uncommitted)> commit
zfssa:configuration users oemuser exceptions>

33.15 ストレージの関連リソース

処理の実行の説明や、この機能のロールの詳細は、次のリソースの1つに移動してください。

- 『Sun ZFS Storage 7000 System Administration Guide』を表示するには、Unified Storage Systemソフトウェア・インタフェースにログインして、いずれかの画面の右上隅でのヘルプをクリックします。ストレージ・システムのホスト名またはIPアドレスで、このガイドにアクセスすることもできます。

- https://hostname:215/wiki

- https://ipaddress:215/wiki

- 詳細な情報へのリンクは、http://www.oracle.com/us/products/servers-storage/storage/unified-storage/sun-storage-7000-uss-103104.htmlにある、Oracle ZFS Storageアプライアンス・ソフトウェア製品情報ページを参照してください。

- 記憶域検出の詳細は、「Oracle ZFS Storageの検出および昇格」を参照してください。

- システム・インフラストラクチャ・ターゲットの検出および昇格の詳細は、「システム・インフラストラクチャ・ターゲットの検出、昇格および追加」の章を参照してください。

34 サーバーのモニタリング

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

- サーバー管理のスタート・ガイド

- UI中でのサーバー情報の場所

- サーバー管理の処理

- 「ハードウェア」ダッシュボードについて

- 「ハードウェア」ダッシュボードの表示

- ハードウェアのフォトリアリスティック画像について

- ハードウェアのフォトリアリスティック画像の表示

- 論理ビューについて

- 論理ビューの表示

- エネルギ消費について

- エネルギ消費の表示

- ネットワークの接続性

- ネットワーク接続性の表示

- サービス・プロセッサ構成について

- サービス・プロセッサ構成の表示

- サーバー管理の関連リソース

34.1 サーバー管理のスタート・ガイド

既存の検出メソッドを使用してOracle Enterprise Managerでハードウェア・アセットを検出し、システムにEnterprise Managerエージェントをデプロイできます。それらが検出されると、インシデント、電力使用量、ネットワーク情報、サービス・プロセッサ構成、ファンや温度の情報などのハードウェアに関するモニタリング情報を表示できるようになります。また、管理対象ハードウェアとオペレーティング・システム、仮想プラットフォームおよびそのハードウェアにインストールされたその他のソフトウェアとの関係も、ユーザー・インタフェースに表示されます。

34.2 UI中でのサーバー情報の場所

サーバーの子である任意のターゲット(仮想プラットフォーム、ゲストまたはホスト)を選択すると、そのサーバーがターゲット・ナビゲーション・ペインに表示されます。

また、「すべてのターゲット」ページから、「システム・インフラストラクチャ・サーバー」をクリックしてサーバーのリストを表示することもできます。このリストのサーバーをクリックして、サーバーのホームページを開くことができます。

34.3 サーバー管理の処理

実行可能な操作は次のとおりです。

- サーバーの検出

- サーバーのハードウェア・コンポーネントの表示

- サーバー構成の表示

- サーバーのリソース使用率の表示

34.4 「ハードウェア」ダッシュボードについて

ダッシュボードは、主要なウィンドウの最上部近くにあります。インシデント、電力使用状況、温度情報、コア情報および最近のイベントなど、サーバーのステータスについての基本情報が含まれます。

ダッシュボードの情報は、自動的に表示されます。3つのダッシュレットが表示されます。別のダッシュレットの組合せに切り替えるには、ダッシュボードの下のアイコンをクリックします。

次のダッシュレットが表示されます。

- 基本的なハードウェア情報について

- オープン・インシデントについて

- ファンおよび温度情報について

- 電力使用量について

- コア情報について

- 最後の構成変更およびインシデントについて

34.4.1 基本的なハードウェア情報について

最初のダッシュレットには、ハードウェアの基本情報が表示されます。見出しには、完全なハードウェア名と電力ステータスが含まれます。

次のフィールドが表示されます。

- IPアドレス

- モデル

- シリアル番号

- 状態

- CPU

- メモリー

- ファームウェア

- ロケータ

34.4.2 オープン・インシデントについて

2番目のダッシュレットには、ハードウェアのオープン・インシデントに関する情報が表示されます。

次のフィールドが表示されます。

- 致命的

- クリティカル

- 警告

カテゴリをクリックすると、このカテゴリ内のインシデントの詳細ビューが表示され、ここには、ターゲット、サマリー、最終更新日、インシデントが認識されているかどうか、およびステータスが示されます。右上隅のXアイコンをクリックして、この詳細ビューを閉じます。

34.4.3 ファンおよび温度情報について

4番目のダッシュレットには、ファンおよび温度の情報が表示されます。

次のフィールドが表示されます。

- ファン使用状況: 最大値のパーセンテージとしてファンの使用状況が表示されます。

- 温度: ハードウェアの温度が摂氏で表示されます。

34.4.4 電力使用量について

3番目のダッシュレットには、電力使用量の情報が表示されます。グラフには、最大値のパーセンテージとして電力使用量が表示されます。

次のフィールドが表示されます。

- 使用可能な電力

- 最大許容

- 使用電力

- 電力ポリシー (SPARCサーバーのみ)

34.4.5 コア情報について

5番目のダッシュレットには、アクティブおよび非アクティブなコアの数を示す円グラフが表示されます。

34.4.6 最後の構成変更およびインシデントについて

6番目のダッシュレットには、最後の構成変更の日時と、最後にインシデントが報告された日時が表示されます。

34.5 「ハードウェア」ダッシュボードの表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ・サーバー」を選択します。
ターゲット・サーバーのリストが表示されます。

3. ターゲット名をクリックしてサーバーの「サマリー」ページを開きます。ページ上部にダッシュレットが表示され、サマリー情報が提供されます。

34.6 サーバー・メトリックについて

選択したサーバーのメトリックの完全なリストを表示できます。

34.7 サーバー・メトリックの表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ・サーバー」を選択します。
ターゲット・サーバーのリストが表示されます。

3. ターゲット名をクリックしてサーバーの「サマリー」ページを開きます。

4. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「モニタリング」をクリックして、「すべてのメトリック」をクリックします。

5. メトリックをクリックすると、詳細、収集スケジュール、アップロード間隔およびその他の詳細が表示されます。

34.8 ハードウェアのフォトリアリスティック画像について

メイン・ウィンドウの「ハードウェア・ビュー」タブに、互換性のあるハードウェアのフォトリアリスティック・ビュー(前面、最上部、背面など)とハードウェアのコンポーネントの表ビューが表示されます。

「フォトリアリスティック・ビュー」を選択すると、ハードウェアのフォトリアリスティック・ビューが表示されます。インシデントがあるコンポーネントは赤で描かれます。

フォトリアリスティック・ビューに表示されているコンポーネントをクリックすると、そのコンポーネントに関する追加情報を表示できます。存在してコンポーネントに関連する場合、次の情報が表示されます。

- コンポーネント名

- 製造業者

- シリアル番号

- 部品番号

- 合計コア: CPUのコアの数

- 有効コア: CPUの有効コアの数

- サイズ: メモリー・コンポーネントのサイズ(GB)

「表」を選択すると、ハードウェア・コンポーネントの表が表示されます。コンポーネントごとに次の情報が表示されます。

- スロット番号

- コンポーネント名

- コンポーネント・タイプ

34.9 ハードウェアのフォトリアリスティック画像の表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ・サーバー」を選択します。
ターゲット・サーバーのリストが表示されます。

3. ターゲット名をクリックしてサーバーの「サマリー」ページを開きます。

4. 「ハードウェア・ビュー」タブをクリックします。

34.10 論理ビューについて

メイン・ウィンドウの「論理ビュー」タブには、ハードウェア・コンポーネントと機能に関する詳細な情報が表示されます。タブの1つを選択すると、それに関する詳細な情報が表示されます。

34.10.1 CPU情報について

「CPU」タブには、CPUとCPU使用状況の情報が表示されます。

一番上のセクションには、サマリー情報が表示されます。円グラフには、インストールされ、利用できるCPUの数が表示されます。

次のフィールドが表示されます。

- アーキテクチャ

- クロック・スピード

- モデル

- CPU消費電力(W)

- 全体のステータス

一番下のセクションには、使用できるプロセッサの表が表示され、名前、アクティブなコア、シリアル番号、部品番号、合計キャッシュ(KB)、コンポーネントの場所、操作ステータスなどが示されます。

34.10.2 メモリー情報について

「メモリー」タブには、合計メモリーとDIMM固有の情報が表示されます。

一番上のセクションには、サマリー情報が表示されます。円グラフには、インストールされ、利用できるDIMMの数が表示されます。

次のフィールドが表示されます。

- メモリー(GB)

- メモリー消費電力(W)

- 全体のステータス

一番下のセクションには、メモリー・モジュールを示す表が表示されます(メモリー・コンポーネント名、サイズ(GB)、製造業者、部品番号、シリアル番号、場所、操作ステータスなど)。

34.10.3 電力情報について

「電力」タブには、電力と電源の情報が表示されます。

一番上のセクションには、サマリー情報が表示されます。円グラフには、インストールされ、利用できる電源の数が表示されます。電源の全体的なステータスが表示されます。

一番下のセクションには、利用できる電源を示す表が表示されます(名前、製造者、部品番号、シリアル番号、出力(W)、場所および操作ステータスなど)。

34.10.4 ファン情報について

「ファン」タブには、冷却とファンの情報が表示されます。

一番上のセクションには、サマリー情報が表示されます。円グラフには、インストールされ、合計および利用可能な電源ユニット・ファンの数が表示されます。冷却の全体的なステータスが表示されます。

一番下のセクションには、利用できるファンを示す表が表示されます(名前、最大値に対するパーセンテージで示されたRPM、場所および操作ステータスなど)。

34.10.5 記憶域情報について

「記憶域」タブには、使用できる記憶域に関する情報が表示されます。

一番上のセクションには、サマリー情報が表示されます。次のフィールドが表示されます。

- インストール済合計ストレージ(GB)

- インストール済・ディスク

一番下のセクションには、利用できるストレージ・ディスクを示す表が表示されます(名前、サイズ(GB)、製造者、シリアル番号、部品番号および操作ステータスなど)。この情報は、ILOMが検出された場合のみ表示されます。

34.10.6 ディスク・コントローラ情報について

「ディスク・コントローラ」タブには、使用できるディスク・コントローラの表が表示されます(名前、モデル、メーカー、シリアル番号および操作ステータスなど)。

この情報は、ILOMが検出された場合のみ表示されます。

34.10.7 ディスク・エキスパンダ情報について

「ディスク・エキスパンダー」タブには、使用できるディスク・エキスパンダの表が表示されます(名前、メーカー、バージョン、モデル、ファームウェア・バージョンおよびシャシーIDなど)。

この情報は、ILOMが検出された場合のみ表示されます。

34.10.8 ネットワーク・ポート情報について

「ネットワーク・ポート」タブには、ネットワーク・インタフェース・コントローラとネットワーク・アダプタに関する情報が表示されます。

一番上のセクションには、NICとステータスの情報が表示されます。次のフィールドが表示されます。

- インストール済イーサネットNIC

- 全体のステータス

一番下のセクションには、ネットワーク・ポートの表が表示されます(名前、MACアドレス、説明、操作ステータスなど)。

34.10.9 PCIデバイス情報について

「PCIデバイス」タブには、PCIデバイスの表が表示されます(名前、説明、デバイス・クラス、PCIデバイスID、PCIベンダーID、PCIエンド・ポイント、PCIサブ・デバイスIDおよびPCIサブ・デバイス・ベンダーIDなど)。

この情報は、サーバー上のオペレーティング・システムにエージェントがデプロイされている場合のみ表示されます。

34.10.10 PDOM情報について

「PDOM」タブには、Mシリーズ・ハードウェア用の物理ドメインの表が表示されます(名前、構成ステータス、割当済DCUおよび操作ステータスなど)。

34.10.11 DCU情報について

「DCU」タブには、Mシリーズ・ハードウェア用のDCUの表が表示されます(名前、CPUの数、メモリー(GB)、ファンの数、PDOM ID、電力ステータスおよび操作ステータスなど)。

34.11 論理ビューの表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ・サーバー」を選択します。
ターゲット・サーバーのリストが表示されます。

3. ターゲット名をクリックしてサーバーの「サマリー」ページを開きます。

4. 「論理ビュー」タブをクリックします。

34.12 エネルギ消費について

メイン・ウィンドウの「エネルギ」タブには、ハードウェアのエネルギ消費に関する情報が表示されます。

「サマリー」セクションには、温度、ファン速度および電力に関する基本情報を示す3つのグラフが表示されます。「時間範囲」ドロップダウンを使用して、表示する別の時間間隔を選択できます。

最初のグラフには、インレット温度と排気温度が摂氏で表示されます。

2番目のグラフには、最大値のパーセンテージとしてファン速度が表示されます。

3番目のグラフは、電力消費量と電力使用量がワットで表示されます。

「表ビュー」リンクをクリックすると、グラフを作成するために使用したデータ・ポイントの表を表示できます。

34.13 エネルギ消費の表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ・サーバー」を選択します。
ターゲット・サーバーのリストが表示されます。

3. ターゲット名をクリックしてサーバーの「サマリー」ページを開きます。

4. 「エネルギー」タブをクリックします。

34.14 ネットワークの接続性

メイン・ウィンドウの「ネットワークの接続性」タブには、ハードウェアのネットワーク・インタフェース、データリンクおよびポートに関する情報が表示されます。この3つのオプションの1つを選択すると、それに関する詳細な情報が表示されます。

34.14.1 ネットワーク・インタフェースについて

「ネットワーク・インタフェース」ページには、ハードウェアのネットワーク・インタフェースの表が表示され、IPアドレス、ネットマスク、現在の状態を示すアイコンが表示されます。

インタフェース名またはインタフェースの状態でリストをソートできます。

追加情報を参照するには、「詳細」リンクをクリックします。

34.14.2 ネットワーク・データ・リンクについて

「ネットワーク・データリンク」ページには、ハードウェアのデータ・リンクの表が表示され、名前、物理アドレス、メディア、VLAN IDなどが示されます。

データ・リンク名またはデータ・リンクの状態でリストをソートできます。

デバイスやデバイス・パスなどの追加情報を参照するには、「詳細」リンクをクリックします。

34.14.3 ネットワーク・ポートについて

「ネットワーク・ポート」ページには、ハードウェアのポートとタイプの表が表示されます。

状態、コネクタまたは番号と名前でリストをソートできます。

エラーやスループットなどの追加情報を参照するには、「詳細」リンクをクリックします。

34.15 ネットワーク接続性の表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ・サーバー」を選択します。
ターゲット・サーバーのリストが表示されます。

3. ターゲット名をクリックしてサーバーの「サマリー」ページを開きます。

4. 「ネットワークの接続性」タブをクリックします。

34.16 サービス・プロセッサ構成について

メイン・ウィンドウの「サービス・プロセッサ構成」タブには、ファームウェア、ホスト・ポリシー構成、電源投入時セルフ・テスト、SPアラート構成、およびDNSとNTPの設定に関する情報が表示されます。タブの1つを選択すると、それに関する詳細な情報が表示されます。

34.16.1 ファームウェア情報について

「ファームウェア情報」タブには、全インストール済ファームウェアのコンポーネント識別子、タイプ、バージョンおよびリリース日付の表が表示されます。

34.16.2 ホスト・ポリシー構成について

「ホスト・ポリシー構成」タブには、ホスト・ポリシー名とその現在の値のリストの表が表示されます。

34.16.3 電源オン・セルフ・テスト構成について

「電源オン・セルフ・テスト構成」タブには、電源オン・セルフ・テスト設定の名前と現在の値の表が表示されます。

34.16.4 SPアラート構成について

「SPアラート構成」タブには、サービス・プロセッサ・アラート名の表が表示されます。表には、各アラートのアラート・タイプ、アラート・レベル、宛先アドレス、宛先ポート、SNMPバージョンおよびコミュニティが表示されます。

34.16.5 DNSおよびNTP情報について

DNSとNTPタブには、DNSとNTPの設定に関する情報が表示されます。次のフィールドが表示されます。

- 自動DNS/DHCP: DNSまたはDHCPが使用されているかどうかを示します。

- DNSサーバー: 使用中のDNSサーバーをリストします。

- 検索パス: DNSサーバーの検索パスをリストします。

- 時間: ハードウェアの現在時刻とタイム・ゾーンがリストされます。

- NTPサーバーを使用: NTPサーバーが使用されているかどうかを示します。

- NTPサーバー1: 最初のNTPサーバーのIPアドレス。

- NTPサーバー2: 2番目のNTPサーバーのIPアドレス。

34.17 サービス・プロセッサ構成の表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ・サーバー」を選択します。
ターゲット・サーバーのリストが表示されます。

3. ターゲット名をクリックしてサーバーの「サマリー」ページを開きます。

4. 「サービス・プロセッサ構成」タブをクリックします。

34.18 メトリックおよびインシデント通知の管理

次のタスクを実行して、モニタリングおよびインシデント通知を管理できます。

- メトリック収集エラーの表示

- メトリックおよび収集設定の編集

- モニタリング構成の編集

- モニタリングの一時停止の通知

- メンテナンスのためのモニタリングの一時停止

- ブラウンアウトまたはブラックアウトのモニタリングの終了

34.18.1 メトリック収集エラーの表示

メトリック収集エラーの原因は通常、インストールまたは構成の問題です。サーバーのエラーを表示できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「モニタリング」をクリックして、「メトリック収集エラー」をクリックします。

34.18.2 メトリックおよび収集設定の編集

「メトリック」タブには、モニター対象属性がすべて表示されます。デフォルトのビューは、しきい値が設定されるメトリックです。このようなタイプのモニター対象属性の場合、比較演算子、しきい値の制限、修正処理、収集スケジュールを変更できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「モニタリング」をクリックして、「メトリックと収集設定」をクリックします。

4. しきい値の制限または収集スケジュールを変更します。しきい値のフィールドが空の場合、そのメトリックのアラートは無効になります。

5. 詳細設定の「編集」アイコンをクリックします。
「収集されたその他のアイテム」タブをクリックすると、しきい値以外のモニター対象属性が表示されます。このような属性の収集期間を変更したり、モニタリングを無効にできます。

6. 「OK」をクリックして、変更を保存します。

34.18.3 モニタリング構成の編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「ターゲット設定」をクリックします。

4. 「モニタリング構成」をクリックします。

34.18.4 モニタリングの一時停止の通知

ブラウンアウトを使用すると、ターゲットでの通知を一時的に抑止できます。エージェントはブラウンアウトの間ターゲットをモニタリングし続けます。実際のターゲット・ステータスとともにターゲットが現在ブラウンアウト中であること示す内容を表示できます。

サーバーのブラウンアウトを作成できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「制御」をクリックします。

4. 「ブラウンアウトの作成」をクリックします。

5. ブラウンアウト・イベントの名前を入力します。

6. メニューから理由を選択し、必要に応じてコメントを追加します。

7. オプションをクリックして、ジョブの実行方法とメンテナンス・ウィンドウを定義します。

8. 「発行」をクリックします。

34.18.5 メンテナンスのためのモニタリングの一時停止

ブラックアウトを使用すると、メンテナンス操作を実行するために1つ以上のターゲットに対するモニタリングを一時停止できます。ターゲットをブラックアウトにするには、少なくともターゲットに対する「ブラックアウト・ターゲット」権限が必要です。ホストを選択すると、デフォルトでそのホスト上のターゲットはすべてブラックアウトに含まれます。同様に、メンバーを持つターゲットを選択すると、デフォルトでメンバーはすべてブラックアウトに含まれます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「制御」をクリックします。

4. 「ブラックアウトの作成」をクリックします。

5. メニューから理由を選択します。

6. 必要に応じて、コメントを追加します。

7. 「発行」をクリックします。

34.18.6 ブラウンアウトまたはブラックアウトのモニタリングの終了

サーバーのブラックアウトまたはブラウンアウトを終了できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「制御」をクリックします。

4. 「ブラックアウトの終了」または「ブラウンアウトの終了」をクリックします。

34.19 サーバーの管理

次のタスクを実行して、サーバーを管理できます。

- コンプライアンスの表示

- サーバー構成における変更の識別

- サーバー管理者アクセスの編集

- サーバーのグループへの追加

- サーバー・プロパティの編集

34.19.1 コンプライアンスの表示

「コンプライアンス」ページでは、コンプライアンス・フレームワーク、標準およびサーバーのコンプライアンスを表示できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「コンプライアンス」をクリックします。

4. オプションをクリックして、「結果」、「標準アソシエーション」または「リアルタイム監視」を表示します。

34.19.2 サーバー構成における変更の識別

管理者がシステムの構成を変更する場合、いつ、構成が最後に変更されたかを知っておくと便利なことがあります。この情報は、「サマリー」ページの構成ダッシュレットに表示されます。

サーバーのより詳細な情報を表示する手順:

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「構成」をクリックします。

4. オプションをクリックして、「最新収集」、「比較およびドリフト管理」、「比較」、「検索」、「履歴」、「保存」、「保存済」または「トポロジ」を表示します。

34.19.3 サーバー管理者アクセスの編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「ターゲット設定」をクリックします。

4. 「管理者アクセス」をクリックします。

34.19.4 サーバーのグループへの追加

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「ターゲット設定」をクリックします。

4. 「グループに追加」をクリックします。

34.19.5 サーバー・プロパティの編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ・サーバー」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「システム・インフラストラクチャ・サーバー」をクリックします。「ターゲット設定」をクリックします。

4. 「プロパティ」をクリックします。

34.20 サーバー管理の関連リソース

詳細は、次の章を参照してください。

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- インシデント管理の使用

35 PDUの管理

この章には次の情報が含まれています。

- PDU管理のスタート・ガイド

- ユーザー・インタフェース内でのPDU情報の場所

- PDUの処理

- PDUバージョン識別

- PDU情報の表示

- PDUモニタリング資格証明の変更

- PDUテスト接続およびメトリック収集のエラーのトラブルシューティング

- PDUのエラー状態

- PDUのアラートおよび構成

- PDU管理の関連リソース

35.1 PDU管理のスタート・ガイド

Enterprise Manager Cloud Control 13.1では、サーバー、スイッチ、ZFS Storage Appliance、Exadataストレージ・セル、PDU、ラック、エンジニアド・システムなどのOracleハードウェア・ターゲットを管理およびモニタリングできます。PDUターゲットは、ラック内のハードウェアに電力を供給しているPDUに関するモニタリング情報を提供します。ターゲットの検出と管理は、ソフトウェアでのほとんどすべての処理の前提条件となります。プロセス全体の手順を示すガイドされた検出ウィザードを使用すると、迅速かつ簡単に検出できます。検出プロセスは、入力として必須情報のみを必要とし、検出を正常に完了するために考えられる問題を解決するのに役立ちます。

35.2 ユーザー・インタフェース内でのPDU情報の場所

表35-1は、どこに情報があるかを示しています。

表35-1 BUI内でのPDU情報の場所

オブジェクト

場所

電力配分装置

Enterprise Managerのユーザー・インタフェースで、「ターゲット」の下の「すべてのターゲット」をクリックします。「検索の絞込み」セクションで、「ターゲット・タイプ」の下の「サーバー、ストレージおよびネットワーク」をクリックします。「システム・インフラストラクチャPDU」をクリックし、表示されたリストからPDUを選択します。

35.3 PDUの処理

要件に応じて、次の処理を実行できます。

- PDUの検出

- PDUの表示

35.4 PDUバージョン識別

PDUハードウェアには、PDU v1およびPDU v2という2つのバージョンがあります。

PDU管理インタフェースにアクセスすると、PDUバージョンを識別できます。このインタフェースにアクセスするには、Webブラウザを使用してPDUに割り当てたIPアドレスまたはDNS名を指定します。一部のPDUのモニタリングまたは検出の問題を解決するために、PDUバージョンを把握することが必要になります。

注意:
PDUは、Webブラウザではアクセスできない分離した管理ネットワーク上にある場合があります。この場合は、管理ネットワーク内からPDU管理インタフェースにアクセスしてください。

1. Webブラウザを開きます。

2. WebブラウザにPDU管理インタフェースのアドレスを入力します。
たとえば、PDU v1の場合はhttp://<PDUのIPまたはDNS名>、PDU v2の場合はhttps://<PDUのIPまたはDNS名>を入力します。

注意:
PDU v2にhttp://とhttps://のどちらを使用するかは、PDUの構成方法に依存します。不明な場合は、両方を使用してみてください。http://とhttps://のどちらも動作しない場合は、PDUがオフラインになっているか、PDUアドレスが正しくない可能性があります。PDU管理インタフェースがオフになっている場合は、PDU SNMPインタフェースを使用してオンにすることができます。

3. PDU管理インタフェースでは、PDU電力消費量セクションを確認することでPDUバージョンを識別できます。PDUの消費量の詳細は、PDU v2の場合のみ表示されます。図35-1にPDU v1の管理インタフェースの例を、図35-2にPDU v2の管理インタフェースの例を示します。

図35-1 PDU v1の管理インタフェース

図35-2 PDU v2の管理インタフェース

35.5 PDU情報の表示

PDU情報画面は2つの部分に分かれています。一番上の領域は、システムの概要を示すダッシュレットで構成されています。メイン領域には、PDUのより詳細な情報が表示されます。

第1シリーズの最初のダッシュレットには、PDUのサマリーが表示されます。PDUの部品番号、シリアル番号、IPアドレスおよびファームウェア・バージョンが表示されます。

第1シリーズの2番目のダッシュレットには、PDU上で中継されるすべてのオープン・インシデントが表示されます。特定の重大度のインシデントのリストを表示するには、表示された番号のいずれかをクリックします。

第1シリーズの3番目のダッシュレットには、PDUの電力使用量が表示されます。PDUの全モジュールのフェーズごとに、アンペア単位の電力(電流)のサマリーが表示されます。

第2シリーズの最初のダッシュレットには、PDUに対して行われた最後の構成変更が表示されます。最後のインシデントが発生した時刻も表示されます。

35.5.1 PDUの物理ビュー

PDUの物理ビューを表示するには、PDUのランディング・ページのメイン・セクションにある最初のタブをクリックします。PDUの物理ビューには、PDUの前面ビューと側面ビューが表示されます。PDUは1つ以上のモジュールで構成されています。いずれかのモジュールまたはPDU自体をクリックして、より詳細な情報を表示できます。

ビューのフォトリアリスティック表現と表形式の表現を切り替えることができます。

- フォトリアリスティック・ビューにはPDUのリアルな写真が表示され、すべてのコンポーネントの詳細なグラフィックスが提供されます。

- 表ビューは、物理ビューを表で表したもので、表示対象コンポーネントと最も重要な情報のリストが表示されます。

図35-3は、PDUの物理ビューの表示です。

図35-3 PDUの物理ビュー

35.5.2 PDU負荷ビュー

PDU負荷ビューを表示するには、PDUのランディング・ページのメイン・セクションにある2番目のタブをクリックします。PDU負荷ビューには、モジュールごとのフェーズ負荷(アンペア単位の電流)の履歴データが表示されます。

35.6 PDUモニタリング資格証明の変更

HTTPおよびSNMP PDUの資格証明をPDUで変更する場合は、Enterprise ManagerでPDUの管理インタフェースを使用して資格証明を変更できます。

35.6.1 HTTP資格証明の変更

HTTP資格証明を変更するには、次の手順を実行します。

1. 「設定」で、「セキュリティ」をクリックしてから「モニタリング資格証明」をクリックします。

2. 「ターゲット・タイプ」列で「システム・インフラストラクチャPDU」を選択し、「モニタリング資格証明の管理」をクリックします。

図35-4 ターゲット・タイプの選択

3. システム・インフラストラクチャPDUの「モニタリング資格証明」画面で、「HTTPモニタリング資格証明」(「資格証明セット」列)を選択し、「資格証明の設定」をクリックします。

図35-5 HTTP資格証明の設定

4. 「モニタリング資格証明の入力」画面で、PDU HTTPの新しい資格証明を入力し、「テストと保存」をクリックします。

35.6.2 SNMP資格証明の変更

SNMP資格証明を変更するには、次の手順を実行します。

1. 「設定」で、「セキュリティ」をクリックしてから「モニタリング資格証明」をクリックします。

2. 「ターゲット・タイプ」列で「システム・インフラストラクチャPDU」を選択し、「モニタリング資格証明の管理」をクリックします。

図35-6 ターゲット・タイプの選択

3. システム・インフラストラクチャPDUの「モニタリング資格証明」画面で、「SNMPモニタリング資格証明」(「資格証明セット」列)を選択し、「資格証明の設定」をクリックします。

図35-7 SNMP資格証明の設定

4. 「モニタリング資格証明の入力」画面で、PDU SNMPの新しい資格証明を入力し、「保存」をクリックします。

35.7 PDUテスト接続およびメトリック収集のエラーのトラブルシューティング

PDUメトリックの収集またはテスト接続は、失敗する場合があります。PDUテスト接続に失敗すると、エラー・メッセージが表示されます。この項では、そのような状況のトラブルシューティング方法について説明します。

35.7.1 テスト接続エラーの識別

テスト接続が失敗した場合は、問題の説明を含むメッセージが表示されます。考えられるPDUのエラー状態とその解決策はPDUのエラー状態と解決策の表を参照し、表の説明に従って問題の原因を修正してからテスト接続を繰り返してください。

図35-8 テスト接続エラー

35.7.2 メトリック収集エラーの識別

メトリックの収集が失敗した場合、メトリック収集エラー・イベントがPDUに対して発生します。

注意:
デフォルトでは、メトリック収集エラーからはインシデントは生成されません。「設定」→「インシデント」→「インシデント・ルール」でインシデントの生成をオンにすることができます。
ルール「ターゲットのメトリック収集エラー・イベントのグループ化」を検索し、有効にします。

PDUのすべてのメトリック収集エラーを識別および表示するには、次の手順を実行します。

1. PDUランディング・ページの左上隅にあるターゲット・メニューに移動し、「システム・インフラストラクチャPDU」をクリックします。

2. 「モニタリング」をクリックして、「すべてのメトリック」をクリックします。

3. 「概要」セクションで、「メトリック収集エラー」の数をクリックします。

4. より詳細な情報を表示するメトリック収集エラーを選択してクリックします。
詳細なエラーの説明が表示されます。

考えられるPDUのエラー状態とその解決策はPDUのエラー状態と解決策の表を参照し、表35-2「PDUのエラー状態と解決策」の説明に従って問題の原因を修正してください。失敗したすべてのメトリックに対して評価を繰り返します。

35.7.3 メトリックの再収集

失敗したすべてのメトリックを評価した後で、メトリック収集を繰り返します。

1. PDUランディング・ページの左上隅にあるターゲット・メニューに移動し、「構成」をクリックしてから「最新収集」をクリックします。

2. 「最新の構成」画面で、「リフレッシュ」ボタンをクリックします。

図35-9 PDUのターゲット・メニュー

メトリックが再収集され、収集エラーのすべての原因が解決されると、インシデントはインシデント・マネージャ、ダッシュレットおよびフォトリアリスティック・ビューに表示されなくなります。

失敗したメトリックが「ステータス」という語ともに表示された場合、そのメトリックはリフレッシュできないパフォーマンス・メトリックです。次にスケジュールされたメトリック再収集を待機する必要があります。デフォルトの構成では、PDUパフォーマンス・メトリックは、15分ごとに再収集されます。

注意:
メトリック再収集の間隔は、Enterprise Managerのユーザーがターゲット・メニューのサブメニュー「メトリック」の項目「メトリックと収集設定」を使用して変更できます。

35.8 PDUのエラー状態

テスト接続またはメトリック収集の間に発生する可能性があるほとんどのエラー状態は、PDUやネットワークの構成ミスか、PDUの反応がないことが原因となります。これらのエラーは、ユーザーが修正できます。

問題の解決を完了した後、「メトリックの再収集」の説明に従ってメトリック収集を繰り返すか、「PDUの検出および昇格」の説明に従ってテスト接続を繰り返します。

PDUのエラー状態と解決策の表のエラー・リストは、完全なリストではありません。次のリリースで新しいメッセージが追加されたり、変更される可能性があります。

表35-2 PDUのエラー状態と解決策

エラー・メッセージ

解決策

PDUディスパッチURL http://pdu.example.comの形式が間違っているか、空であるか、またはIPアドレスに転送できません。有効なディスパッチURL (PDU WebインタフェースのURLアドレス)を指定してください。: 詳細な説明

PDU検出で有効なPDU DNS名を指定したことを確認します。

有効なDNS名を指定した場合は、モニタリング・エージェントとバックアップ・エージェントのホストでDNSが正しく構成されていることを確認します。

#PDU: 127.0.0.1と通信できません。PDUにアクセスできません。HTTPまたはHTTPSを使用してPDU Webインタフェースにアクセスできません。PDUがオンラインかどうか確認して(Webブラウザでアドレスhttp://127.0.0.1を開き、http://とhttps://の両方を試す)、操作(メトリック収集、接続テスト)をやりなおしてください。: 詳細な説明

「PDUバージョン識別」の説明に従い、PDUが稼働中であることを確認します。

モニタリング・エージェントとバックアップ・エージェント(設定されている場合)からPDUにアクセスできる場合は、ネットワーク構成を確認します。

SNMPを使用して#PDU: pdu.example.comと通信できません。PDU SNMPインタフェースが停止しているか使用不可である、またはSNMPコミュニティ文字列が正しく構成されていません。PDUがオンラインかどうかを確認し(Webブラウザでアドレスhttps://pdu.example.comを開く)、Enterprise ManagerおよびPDUでコミュニティ文字列が正しく設定されているかどうかを確認し(Webブラウザでアドレスhttps://pdu.example.comを開き、「ネット構成」セクションに移動してログインし、NMS IP-コミュニティ・テーブルとTrap Hosts Setup IP-コミュニティ・テーブルを確認)、SNMPが有効であるかどうかを確認して(Webブラウザでアドレスhttps://pdu.example.comを開き、「ネット構成」セクションに移動してログインし、SNMPが有効であるかどうかを確認)、操作(メトリック収集、接続テスト)をやりなおしてください。

「PDUバージョン識別」の説明に従い、PDUが稼働中であることを確認します。

稼働中の場合は、「PDU v1 NMSテーブルおよびTrap Hosts Setupテーブルの確認」および「PDU v2 NMSテーブルおよびTrap Hosts Setupテーブルの確認」の説明に従い、NMSテーブルとTrap Hosts Setupテーブルが正しいかどうか、およびSNMPコミュニティ文字列が変更されていないかどうかを確認し、「メトリック再収集」の説明に従い、SNMP構成メトリックを再収集します。

PDU管理インタフェースでSNMPコミュニティを変更した場合は、Enterprise Managerでも変更します。コミュニティ文字列の変更は、「メトリック収集エラーの識別」で説明されています。

#PDU: pdu.example.comのPDUモデルを識別できません。PDUモデルがサポートされていないか、PDUにアクセスできないためPDUモデルを識別できません。PDUがオンラインかどうか確認して(Webブラウザでアドレスhttps://pdu.example.comを開き、http://とhttps://の両方を試す)、操作(メトリック収集、接続テスト)をやりなおすか別のPDUを試してください。

「PDUバージョン識別」の説明に従い、PDUが稼働中であることを確認します。

PDUにアクセスできる場合は、ネットワーク構成を確認します。

「PDUバージョン識別」の説明に従い、検出中に入力したIPアドレスまたはDNS名がPDU (別のハードウェアではない)およびサポートされているPDUモデルを指していることを確認します。

#PDU: pdu.example.comにログインできません。資格証明が間違っています。Enterprise Managerで正しいPDUユーザー名とパスワードを指定してから、操作(メトリック収集、接続テスト)をやりなおしてください

PDU検出中に正しいHTTP資格証明を指定したことを確認します。

このメッセージを含むインシデントが発生した場合は、PDU管理インタフェースでPDU HTTP資格証明が変更された可能性があります。Enterprise Managerでも変更する必要があります。HTTP資格証明の変更は、「HTTP資格証明の変更」で説明されています。

#PDU: pdu.example.comにログインできません。別のユーザーがすでにログインしています。別のユーザーがログアウトするまで続行できません。別のユーザーにログアウトするよう頼むかユーザーが自動的にログアウトするまで待機してから(約30分)、操作(メトリック収集、接続テスト)をやりなおしてください。

別のユーザーがPDU管理インタフェースにログインしています。

ログインしているユーザーが自分である場合は、PDU管理インタフェースに移動し(「PDUの検出および昇格」を参照)、「ログアウト」ボタンをクリックします。

ログインしているユーザーが他のユーザーである場合は、約30分間、自動ログアウトを待機する必要があります。

#PDU: pdu.example.comのPDU SNMPコミュニティ文字列が見つかりません。Enterprise Managerで正しいコミュニティ文字列を指定して、操作(メトリック収集、接続テスト)をやりなおしてください。

PDU検出で正しいSNMPコミュニティ文字列を指定し、検出をやりなおします。

このメッセージを含むインシデントが発生した場合は、Enterprise ManagerでSNMPモニタリング資格証明を変更する必要があります。SNMP資格証明の変更は、「SNMP資格証明の変更」で説明されています。

#PDU: pdu.example.comではSNMPバージョン3はサポートされていません。Enterprise ManagerでSNMPバージョン1の資格証明を指定して、操作(メトリック収集、接続テスト)をやりなおしてください。

SNMP V3の資格証明はサポートされていないため、SNMP V1の資格証明を指定する必要があります

PDU検出で正しいSNMPコミュニティ文字列を指定し、検出をやりなおします。

このメッセージを含むインシデントが発生した場合は、Enterprise ManagerでSNMPモニタリング資格証明を変更する必要があります。SNMP資格証明の変更は、「SNMP資格証明の変更」で説明されています。

PDU Webインタフェースを使用して、EMエージェント・ホストIPアドレスのモニタリングを#PDU: pdu.example.comのNMS IP-コミュニティ・テーブルに書き込めません。異なるコミュニティ文字列を持つ必要なエージェントIPアドレス192.0.2.100のエントリがすでに存在します。PDU Webインタフェースを使用してテーブルからこのエントリを手動で削除するか、正しいコミュニティ文字列に変更するか(Webブラウザでアドレスhttps://pdu.example.comを開き、「ネット構成」セクションに移動してログインし、NMS IP-コミュニティ・テーブルを参照)、Enterprise Managerで正しいコミュニティ文字列を指定してから、操作(SNMP構成メトリック収集、接続テスト)をやりなおしてください。

PDU検出中に正しいSNMPコミュニティ文字列を入力したことを確認します。

「PDU v1 NMSテーブルおよびTrap Hosts Setupテーブルの確認」および「PDU v2 NMSテーブルおよびTrap Hosts Setupテーブルの確認」の説明に従い、NMSテーブルが正しいかどうか、およびSNMPコミュニティ文字列が変更されていないかどうかを確認します。

このメッセージを含むインシデントが発生した場合は、Enterprise ManagerでSNMPモニタリング資格証明を変更する必要があります。SNMP資格証明の変更は、「SNMP資格証明の変更」で説明されています。

PDU Webインタフェースを使用して、EMエージェント・ホストIPアドレスのモニタリングを#PDU: pdu.example.comのTrap Hosts Setup IP-コミュニティ・テーブルに書き込めません。異なるコミュニティ文字列を持つ必要なエージェントIPアドレス192.0.2.100のエントリがすでに存在します。PDU Webインタフェースを使用してテーブルからこのエントリを手動で削除するか、正しいコミュニティ文字列に変更するか(Webブラウザでアドレスhttps://pdu.example.comを開き、「ネット構成」セクションに移動してログインし、Trap Hosts Setup IP-コミュニティ・テーブルを参照)、Enterprise Managerで正しいコミュニティ文字列を指定してから、操作(SNMP構成メトリック収集、接続テスト)をやりなおしてください。

PDU検出中に正しいSNMPコミュニティ文字列を入力したことを確認します。

「PDU v1 NMSテーブルおよびTrap Hosts Setupテーブルの確認」および「PDU v2 NMSテーブルおよびTrap Hosts Setupテーブルの確認」の説明に従い、Trap Hosts Setupテーブルが正しいかどうか、およびSNMPコミュニティ文字列が変更されていないかどうかを確認します。

このメッセージを含むインシデントが発生した場合は、Enterprise ManagerでSNMPモニタリング資格証明を変更する必要があります。SNMP資格証明の変更は、「SNMP資格証明の変更」で説明されています。

PDU Webインタフェースを使用して、EMエージェント・ホストIPアドレスのモニタリングを#PDU: pdu.example.comのNMS IP-コミュニティ・テーブルに書き込めません。テーブルがいっぱいです。PDU Webインタフェースを使用してテーブルから一部のエントリを手動で削除してから(Webブラウザでアドレスhttps://pdu.example.comを開き、「ネット構成」セクションに移動してログインし、NMS IP-コミュニティ・テーブルを参照)、操作(SNMP構成メトリック収集、接続テスト)をやりなおしてください。

「PDU v1 NMSテーブルおよびTrap Hosts Setupテーブルの確認」および「PDU v2 NMSテーブルおよびTrap Hosts Setupテーブルの確認」の説明に従い、NMSテーブルに空のスロットがないことを確認します。

PDU Webインタフェースを使用して、EMエージェント・ホストIPアドレスのモニタリングを#PDU: pdu.example.comのTrap Hosts Setup IP-コミュニティ・テーブルに書き込めません。テーブルがいっぱいです。PDU Webインタフェースを使用してテーブルから一部のエントリを手動で削除してから(Webブラウザでアドレスhttps://pdu.example.comを開き、「ネット構成」セクションに移動してログインし、Trap Hosts Setup IP-コミュニティ・テーブルを参照)、操作(SNMP構成メトリック収集、接続テスト)をやりなおしてください。

「PDU v1 NMSテーブルおよびTrap Hosts Setupテーブルの確認」および「PDU v2 NMSテーブルおよびTrap Hosts Setupテーブルの確認」の説明に従い、Trap Hosts Setupテーブルに空のスロットがないことを確認します。

アドレス#PDU: pdu.example.comの#PDU: pdu.example.comがアクセス可能なEMエージェント・ホスト上のネットワーク・インタフェースのIPアドレス参照で例外が発生しました。エージェント・ホストからPDUにアクセスできません。

#PDU: pdu.example.comがアクセス可能なEMエージェント・ホスト上のネットワーク・インタフェースのIPアドレス参照で例外が発生しました。

アドレス203.0.113.200の#PDU: pdu.example.comはEMエージェント・ホストのどのネットワーク・インタフェースからもアクセスできません。別のエージェントを選択するか、PDUがアクセスできない問題を解決してください。

「PDUバージョン識別」の説明に従い、PDUが稼働中であることを確認します。

PDUにアクセスできる場合は、ネットワーク構成を確認します。

#PDU: pdu.example.com: 問題の説明。サポート対象のPDUではなく、サポート対象外のPDUハードウェアへのアクセスを試行した可能性があります。

「PDUバージョン識別」の説明に従い、PDUが稼働中であることを確認します。

PDUにアクセスできる場合は、ネットワーク構成を確認します。

「PDUバージョン識別」の説明に従い、検出中に入力したIPアドレスまたはDNS名がPDU (別のハードウェアではない)およびサポートされているPDUモデルを指していることを確認します。

モデル#PDU: pdu.example.comはサポートされていません。最大数が4モジュールのPDUのみサポートされています。検出されたモジュール数: 5

「PDUバージョン識別」の説明に従い、PDUが稼働中であることを確認します。

PDUにアクセスできる場合は、ネットワーク構成を確認します。

「PDUバージョン識別」の説明に従い、検出中に入力したIPアドレスまたはDNS名がPDU (別のハードウェアではない)およびサポートされているPDUモデルを指していることを確認します。

PDUが応答しません。過負荷であるかオフラインになっています。取得または確認できないものがあります。PDUがオンラインかどうか確認してから(Webブラウザでアドレスhttps://pdu.example.comを開く)、操作(メトリック収集、接続テスト)をやりなおしてください。

「PDUバージョン識別」の章の説明に従い、PDUが稼働中であることを確認します。

PDUにアクセスできる場合は、ネットワーク構成を確認します。

「PDUバージョン識別」の説明に従い、検出中に入力したIPアドレスまたはDNS名がPDU (別のハードウェアではない)およびサポートされているPDUモデルを指していることを確認します。

35.9 PDUのアラートおよび構成

PDUおよびEnterprise Managerは、2種類のインシデントをユーザーに報告するように構成できます。

- モジュールのフェーズの電流レベル(アンペア)が設定された警告またはアラームのしきい値を超えた場合。

- PDUモジュールのフェーズ間における電流レベル(アンペア)の差が設定されたしきい値より大きい場合。

警告とアラームのしきい値は、PDUとEnterprise Managerの両方で設定できます。これらの設定は互いに影響しません。インシデントは、PDUとEnterprise Managerで設定された警告とアラームのしきい値とは関係なく生成されます。

35.9.1 レガシーPDUでのアラートの構成

レガシーPDU管理インタフェースでアラームと警告のしきい値を構成するには、次の手順を実行します。

1. WebブラウザでPDU管理インタフェースを開きます(「PDUバージョン識別」を参照)。

2. PDUユーザー・インタフェースで、「パラメータ構成」をクリックします。

3. 自分のユーザー名とパスワードでログインします。

4. 入力0のアラームと警告の電流しきい値(アンペア)を設定し、「送信」をクリックします。

注意:
Enterprise Managerでは、「情報」行はPDUモニタリングに使用されません。

5. すべてのモジュールに対しても前述の手順を繰り返します。

35.9.2 Enterprise Managerでのアラートの構成

Enterprise Managerでアラームと警告のしきい値を構成するには、次の手順を実行します。

1. 「PDUの物理ビュー」の説明に従い、PDUランディング・ページを開きます。

2. ターゲット・メニューの「システム・インフラストラクチャPDU」をクリックします。

3. 「システム・インフラストラクチャPDU」で、「モニタリング」を選択してから「メトリックと収集設定」をクリックします。

図35-10 メトリックと収集設定

4. 表で、「フェーズでの電流の消費アンペア」の「編集」アイコンをクリックし、「警告のしきい値」と「クリティカルのしきい値」の値を編集します。

5. 「PDUモジュールの不安定なアンペア・レベル」の「編集」アイコンをクリックし、「クリティカルのしきい値」の値を編集します。

注意:
「PDUモジュール・フェーズのハードウェアしきい値オーバーラン・レベル」および「PDUモジュールの不安定なしきい値オーバーラン・レベル」の「警告のしきい値」と「クリティカルのしきい値」は変更しないでください。これらの値を変更すると、インシデントがPDUで直接設定されたアラームおよび警告レベルに基づいて生成されなくなるか、正しく生成されなくなります。
値をすでに変更した場合は、「PDUモジュール・フェーズのハードウェアしきい値オーバーラン・レベル」の「警告のしきい値」を1に、「クリティカルのしきい値」を2に設定し、「PDUモジュールの不安定なしきい値オーバーラン・レベル」の「クリティカルのしきい値」を1に設定してください。

6. 「OK」をクリックします。

35.9.3 アラート・インシデントの表示

アラームと警告のしきい値に基づいて生成されたインシデントを表示したり、インシデントを識別するには、「オープン・インシデント」ダッシュレットをクリックして、PDU上のすべてのインシデントのサマリーを表示します。特定のインシデントをクリックすると、インシデントの詳細が表示されます。

- たとえば、PDUで直接設定されたアラームと警告のしきい値に基づいて生成されたインシデントには、次のテキストが含まれます。
PDUモジュール0のフェーズ1が、「パラメータ」ページの「PDU Webインタフェース」で設定されている「モジュール・フェーズ・アンペア・レベル」アラームまたは警告しきい値を超えています。「モジュール・フェーズ・アンペア・レベル」は2.4 Aでした。

- たとえば、Enterprise Managerで設定されたアラームと警告のしきい値に基づいて生成されたインシデントには、次のテキストが含まれます。
PDUモジュール1のフェーズ1が、モニタリング・テンプレートでユーザーが設定した「モジュール・フェーズ・アンペア・レベル」アラーム2 Aまたは警告1 Aしきい値を超えています。「モジュール・フェーズ・アンペア・レベル」は3.2 Aでした。

電流レベルが設定されたアラームの警告のレベルを下回ると、インシデントは自動的にクリアされます。

35.10 PDU管理の関連リソース

詳細は、次を参照してください:

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- インシデント管理の使用

- エンタープライズ・モニタリング

36 ラックの管理

この章には次の情報が含まれています。

- ラック管理のスタート・ガイド

- ユーザー・インタフェース内でのラック情報の場所

- ラックの処理

- ラック管理のターゲット・ナビゲーション

- ラックの作成

- ラック情報の表示

- ラック内のターゲットの配置

- ラック管理の関連リソース

36.1 ラック管理のスタート・ガイド

ターゲット管理とは、Enterprise Managerがサーバー・ハードウェア、シャーシ、ラック、電力配分装置、ネットワーク機器、オペレーティング・システム、仮想ソフトウェアおよびクラスタリング・ソフトウェアなどのターゲットの管理およびモニタリングを開始するプロセスです。ターゲットの検出および管理は、ソフトウェアでのほぼすべての処理の前提条件です。検出機能を使用すると、迅速かつ容易にターゲットを追加できます。ガイド付きプロセスを使用して、電力配分装置およびラックを検出できます。

36.2 ユーザー・インタフェース内でのラック情報の場所

表36-1に、情報が記載されている場所を示します。

表36-1 BUI内でのラック情報の場所

オブジェクト

場所

ラック

Enterprise Managerのユーザー・インタフェースで、「ターゲット」の下の「すべてのターゲット」をクリックします。「検索の絞込み」セクションで、「ターゲット・タイプ」の下の「サーバー、ストレージおよびネットワーク」をクリックします。「システム・インフラストラクチャ・ラック」をクリックして、表示されたリストからラックを選択します。

ラックの物理ビュー

Enterprise Managerのユーザー・インタフェースで、「ターゲット」の下の「すべてのターゲット」をクリックします。「検索の絞込み」セクションで、「ターゲット・タイプ」の下の「サーバー、ストレージおよびネットワーク」をクリックします。「システム・インフラストラクチャ・ラック」をクリックして、表示されたリストからラックを選択します。「ダッシュボード」タブをクリックします。オプションの右側にあるフォトリアリスティック・ビュー・ラジオ・ボタンを選択します。

36.3 ラックの処理

要件に応じて、次の処理を実行できます。

- ラックの作成

- ラックの表示

- ラックへのターゲットの配置

- ラックでのターゲットの編集

- ラックからのターゲットの削除

- ラックの削除

36.4 ラック管理のターゲット・ナビゲーション

ターゲット・ナビゲーション・ツリーには、ラックとラック内のすべてのターゲットがツリー構造で表示されます。いずれかのターゲットをクリックすると、選択したターゲットのランディング・ページに移動します。

注意:
ターゲット・ナビゲーション・ツリーは、ラックにターゲットが移入されている場合にのみアクティブになります。

図36-1 ラック管理のターゲット・ナビゲーション

36.5 ラックの作成

ラック・ターゲットは、Enterprise Controllerによって管理されるその他のハードウェア・ターゲットのコンテナとしての役割を果します。ラックを作成するには、次の手順を実行します。

1. Enterprise Managerにログインします。

2. 「設定」で、「ターゲットの追加」、「ターゲットの手動追加」の順にクリックします。

3. 「概要」セクションで、「ガイド付きプロセスを使用したターゲットの追加」をクリックします。

4. 「ガイド付きプロセスを使用した追加」画面で、「システム・インフラストラクチャ・ラック」にスクロール・ダウンして「追加」をクリックします。

5. システム・インフラストラクチャ・ラック検出画面で、必要な情報を入力します。

1. 「ターゲット名」フィールドに、ラックの名前を入力します。

2. 「タイプ」フィールドで、ラックのタイプと、必要に応じてその他の情報を選択します。

3. (オプション)「グローバル・プロパティ」セクションで、「場所」などのその他の情報も設定できます。

6. 画面の右上隅の「追加」をクリックします。ジョブが正常に実行されると、空のラックが作成されます。これで、ラックのランディング画面に移動して、ラックにハードウェア・ターゲットを追加できます。次の図は、空のラックのイメージです。

図36-2 空のラック

36.5.1 コマンドライン・インタフェースを使用したラックの作成

コマンドライン・インタフェースを使用してラックを作成できます。

CLIを使用してラックを作成するには、次の手順を実行します。

1. OMSが実行されているホストでコマンドライン・インタフェースを開きます。

2. 次のコマンドを使用して、emcliにログインします。
emcli login –username=<your user name>

3. 要求されたら、パスワードを入力します。

4. emcli_syncを実行します。

5. 次のコマンドを使用して、新しいラックを追加します。
emcli add_target \

-name="Name of your Rack" \

-type=oracle_si_rack \

-subseparator=properties='=' \

-separator=properties=';' \

-properties='EngineeredSystemId=SomeID;RackType=SomeType;RackSubtype=SomeSubtype;TotalSlots=42'

6. emcli add_targetコマンドで、次のように設定します。

- Name of your Rackとname of your Rackを置換します

- プロパティの値を設定します

36.5.1.1 ラックのプロパティ

ラックには、EngineeredSystemId、RackType、RackSubtypeおよびTotalSlotsという4つのプロパティがあります。プロパティの説明は、表36-2「プロパティの説明」を参照してください。

表36-2 プロパティの説明

プロパティ

説明

指定できる値

必須

注意

EngineeredSystemId

エンジニアド・システムの一意の識別子

任意の文字列

いいえ

ラックが一部のエンジニアド・システムに属さないスタンドアロンの場合、指定する必要はありません

RackType

ラックタイプ(汎用42UキャビネットまたはOracle Exalogic、SPARC SuperClusterなどのよく知られたタイプ)

- GENERIC: 汎用42Uラック・キャビネット

- EXALOGIC: Exalogic Sun Rack II 42Uラック・キャビネット

- EXADATA: Exadata Sun Rack II 42Uラック・キャビネット

- SUPERCLUSTER: SuperCluster Sun Rack II 42Uラック・キャビネット

- BIGDATA: Oracle Big Data Appliance Sun Rack II 42Uラック・キャビネット

- OPCA: Oracle Private Cloud Appliance Sun Rack II 42Uラック・キャビネット

- ZDLRA: Oracle Zero Data Loss Recovery Appliance Sun Rack II 42Uラック・キャビネット

- EXADATA_STORAGE_EXPANSION: Oracle Exadata Storage Expansion Sun Rack II 42Uラック・キャビネット

はい

ラックが一部のエンジニアド・システムに属さないスタンドアロンの場合は、GENERICを指定します

RackSubtype

ラック・タイプに準拠したRackTypeサイズのオプション仕様。たとえば、Full、Quarterなど。このプロパティはエンジニアド・システム・ラックにのみ適用できます。

- UNDEFINED

- FULL

- HALF

- QUARTER

- EIGHTH

いいえ

なし

TotalSlots

ラック内のスロットの合計数。

42

はい

42スロットのラックのみがサポートされます。

次に、汎用ラックを作成するコマンドの例を示します。

emcli add_target \

-name="Name of your Rack" \

-type=oracle_si_rack \

-subseparator=properties='=' \

-separator=properties=';' \

-properties=RackType=GENERIC;TotalSlots=42'

36.6 ラック情報の表示

ラック情報の画面は、2つの部分に分かれています。一番上の領域は、システムの概要を示すダッシュレットで構成されています。メイン・リージョンには、ラックの詳細情報が表示されます。

ダッシュレットは、3つずつ1つ以上のシリーズにグループ化され、ナビゲーション・スイッチを使用して切り替えることができます。

第1シリーズの最初のダッシュレットには、ラックのシリアル番号、合計数、占有されているスロットの数などのラックの概要が表示されます。情報を入手できる場合はラックの場所も表示されます。

第1シリーズの2番目のダッシュレットには、ラック上で中継されたオープン・インシデントの数と、ラック内のすべてのターゲットが表示されます。表示された数字のいずれかをクリックすると、指定された重要度のインシデントのリストが表示されます。

第1シリーズの3番目のダッシュレットには、ラックのフェーズ当たりの電力使用量(アンペア単位)が表示されます。

第2シリーズの最初のダッシュレットには、オンラインであるターゲットの数、オフラインであるターゲットの数、その他のステータスであるターゲットの集計数が表示されます。

第2シリーズの2番目のダッシュレットには、ラックの占有率が表示されます。ラックのスロット占有状況とPDU占有状況がグラフィック表現で表示されます。

第2シリーズの3番目のダッシュレットには、ラックに対して行われた最後の構成変更が表示されます。

注意:
「第2」ダッシュレット・シリーズ・アイコン(ダッシュレットの下に表示)をクリックすると、その他のダッシュレットが表示されます。「第1」ダッシュレット・シリーズ・アイコンをクリックすると、1組目のダッシュレットが表示されます。

36.6.1 ラックの物理ビュー

ラックの物理ビューを表示するには、ラックのランディング・ページのメイン・セクションにある1つ目のタブをクリックします。ラックのフォトリアリスティック・ビューには、ラックと、ラックにターゲットを配置する方法の概要を示した内容が表示されます。ラック内のいずれかのターゲットをクリックすると、選択したターゲットの詳細情報を表示できます。ラック自体の情報を表示するには、ラックをクリックします。物理ビューの表示は、様々に切り替えることができます。

- フォトリアリスティック・ビューには、システムのリアルな写真と、すべてのコンポーネントの詳細なグラフィックスが表示されます。

- 構成図ビューはデータ指向で、ロケータ・ライト、ステータス、温度、ホスト名などの、最も重要な情報が表示されます。ビューの各コンポーネントは、コンポーネントを簡単に識別できるように、タイプに基づいて色分けされています。右側の温度の表示オプションをクリックすると、その情報を提供しているターゲットの温度が表示されます。ターゲットを空のスロットに配置するには、「温度」トグルの下の「空のスロット」オプションを選択します。選択しない場合、空のスロットはアクティブになりません。

- 表ビューは、物理ビューを表で表したもので、表示対象コンポーネントと最も重要な情報のリストが表示されます。

図36-3 ラックのフォトリアリスティック・ビュー

36.6.2 「ファームウェア」ビュー

ラックのランディング・ページのメイン・セクションにある2つ目のタブをクリックして、「ファームウェア」ビューを表示します。「ファームウェア」ビューには、ラックに配置されたすべてのターゲットのファームウェアが表形式で表示されます。ターゲット名、ターゲット・タイプ、ファームウェア・タイプおよびファームウェア・バージョンが表形式で表示されます。検索オプションは、すべての列の表ヘッダー(たとえば「ターゲット名」、「ターゲット・タイプ」、「ファームウェア・タイプ」、「ファームウェアのバージョン」)上で使用できます。「ターゲット・タイプ」検索フィールドで、ドロップダウン・リストからターゲットのタイプを選択します。ファームウェア検索フィールドにファームウェア・タイプを入力して、選択したファームウェア・タイプのターゲットのみを表示できます。

36.6.3 「負荷」ビュー

「負荷」ビューには、ラック内のPDUの負荷に関する詳細情報が表示されます。モジュール当たりのPDUフェーズ負荷のグラフィカル・ビューに、PDUフェーズ負荷の時間履歴が表示されます。

36.6.4 「温度」ビュー

「温度」ビューには、ラック内のすべてのターゲットの温度が表示されます。過去7日間の平均および最高の温度など、履歴データも表示されます。

36.7 ラック内のターゲットの配置

ラックを作成した後、ラックにハードウェア・ターゲットを配置(追加)できます。空のラックのフォトリアリスティック画像が前面ビューと背面ビューとともに表示されます。ラック内のスロットには、ラック・スロットとPDUスロットの2タイプがあります。ラック・スロットには、スイッチ、サーバー、ZFSアプライアンス、ストレージ・セルおよびラックに配置できるその他のターゲットを配置できます。PDUスロットには、PDUを配置できます。

空または占有されているラックやPDUスロットを右クリックして、アクション・メニューを起動できます。

36.7.1 ラック内のターゲットの配置

ラックにターゲットを配置するには、次の手順を実行します。

1. ラックの空のスロットを右クリックし、「ターゲットの配置」をクリックします。ターゲットをラックに配置ウィザードが開きます。

2. 「選択したターゲット」フィールドで、検索アイコンをクリックして追加するターゲットを検出します。

1. 「ターゲット・タイプ」フィールドで、追加するターゲットのタイプに対応するチェック・ボックスを選択します。検出されたターゲットがリストされます。

2. ターゲットをリストから選択し、「選択」をクリックします。

3. 「位置」フィールドの値は、クリックしたスロット位置から、自動的に記入されます。ターゲットを異なるスロットに配置する場合、ターゲットを配置する空のスロットの位置を入力します。

4. 「高さ」フィールドで、ターゲットの高さを指定します。入力以前に表示される高さは、選択したターゲットのタイプに基づいています。

5. 「向き」フィールドで、ターゲットの方向(「全体」、「前面」または「背面」など)を指定します。(スイッチなど、一部のターゲットは、スロットの半分のみを占有します)。

6. 「水平位置」フィールドで、「全体」、「左」または「右」を指定します。これは、そのターゲットの占有状態に基づきます。一部のターゲットはスロット全体を占有し、一部はスロットの左または右の側を占有します。

7. 「OK」をクリックします。ターゲットは、ラックに配置されます。

36.7.2 ラック内のターゲット配置の編集

ラック内のターゲットの位置を編集したり、必要に応じてターゲットを別のスロットに配置することができます。

ターゲットの位置を編集するには、次の手順を実行します。

1. ターゲットを右クリックして、「ターゲットの編集」を選択します。

2. 該当する値を編集し、「OK」をクリックします。

36.7.3 ラックからのターゲットの削除

ラックに配置されたターゲットを削除できます。

ラックからターゲットを削除するには、次の手順を実行します。

1. ラックの物理ビューに移動します。

2. 削除するターゲットを右クリックして、「ターゲットの削除」をクリックします。

3. 「OK」をクリックして確定します。ターゲットがラックから削除されます。

注意:
ターゲットはラックから削除されますが、Enterprise Managerによって引き続きモニタリングされます。

36.7.4 ラックの削除

Enterprise Managerのターゲットとしてラックを削除できます。ラック・ターゲットを削除するとき、ラックにターゲットが配置されている場合、そのターゲットをEnterprise Managerから削除することはできず、引き続き「すべてのターゲット」ビューでアクセスできます。

ラックを削除するには、次の手順を実行します。

1. ラックのランディング・ページで、「ターゲット」メニュー・ドロップダウン・リストをクリックします。

図36-4 ラックの削除

2. 「ターゲット設定」をクリックしてから、「ターゲットの削除」をクリックします。

3. 「はい」をクリックして確認します。ラックが削除されます。

36.8 ラック管理の関連リソース

詳細は、次を参照してください:

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- インシデント管理の使用

- エンタープライズ・モニタリング

37 Oracle SuperClusterの管理

この章には次の情報が含まれています。

- Oracle SuperClusterのスタート・ガイド

- Oracle SuperClusterの処理

- Oracle SuperClusterのターゲット・ナビゲーション

- Oracle SuperClusterシステムの表示

- Oracle SuperClusterの関連リソース

37.1 Oracle SuperClusterのスタート・ガイド

Oracle SuperClusterは、SPARC計算ノード、Oracle ZFS Storage Appliance、インフィニバンドおよびCiscoスイッチ、PDUおよびExadata Storage Serversをシングルまたはマルチラック・システムに統合したOracle Engineered Systemです。

Oracle SuperClusterは、次の構成でサポートされています。

- SPARC SuperCluster T4-4

- Oracle SuperCluster T5-8

- Oracle SuperCluster M6-32

- Oracle SuperCluster M7-8

ターゲット・モニタリングを開始するには、ターゲットを検出する必要があります。プロセス全体の手順を示すガイドされた検出ウィザードでは、必要な情報のみを要求し、検出を正常に完了するために発生する可能性のある問題の解決を支援するため、検出が迅速化および簡易化されます。

37.2 Oracle SuperClusterの処理

要件に応じて、次の処理を実行できます。

- Oracle SuperClusterの検出

- Oracle SuperClusterシステムの表示

- Oracle SuperClusterシステムのモニタリング

37.3 Oracle SuperClusterのターゲット・ナビゲーション

ターゲット・ナビゲーション・ツリーは、Oracle SuperClusterシステムのターゲット間を移動する助けになります。Oracle SuperClusterの下の最初のレベルは、ラックとMシリーズ・サーバーから構成されています。以降のレベルは、タイプによって論理的にグループ化された、システム内の他のハードウェア・ターゲットから構成されます。図37-1は、Oracle SuperClusterシステムのハードウェア構造を示しています。すべてのターゲットは、ZFSアプライアンスを除き、タイプごとに論理的にグループ化されます。ディスク・シェルフはナビゲーション・ツリーにリストされないため、詳細は「記憶域の管理」を参照してください。

図37-1 Oracle SuperClusterのターゲット・ナビゲーション

Enterprise ManagerエージェントがOracle SuperCluster VM Server for SPARCおよびSolarisゾーンにデプロイされると、図37-2のように各計算ノードの仮想スタックを表示できます。仮想スタックの詳細は、「Oracle Solarisゾーンのモニタリング」および「Oracle VM Server for SPARCのモニタリング」を参照してください。

図37-2 仮想スタックのあるOracle SuperClusterのターゲット・ナビゲーション

37.4 Oracle SuperClusterシステムの表示

Oracle SuperClusterのランディング・ページには、システムに関する情報とそのシステムに含まれるターゲットについて集約された情報が表示されます。このページは2つの部分に分かれています。上のリージョンは、システムの概要を示すダッシュレットで構成されています。

最初のダッシュレットは、「サマリー」ダッシュレットです。システムのサマリー、つまり最も重要なターゲット・タイプ(ラック、スイッチ、サーバー、Exadataセル)の合計数が表示されます。

2番目のダッシュレットには、重大度でグループ化されたオープン・インシデントの数が表示されます。Oracle SuperClusterは、関連付けられているすべてのターゲットからインシデントを収集します。ダッシュレットで数字をクリックすると、インシデントの詳細を取得できます。詳細は、たとえば「ターゲット」、「サマリー」、「最終更新」、「確認済」および「ステータス」などの情報とともに、表に表示されます。ターゲットをクリックして特定のターゲットの詳細情報を表示したり、サマリーをクリックしてインシデントの詳細を表示することができます。

3番目のダッシュレットには、最後の構成変更の時間と、最後にインシデントが報告された時間が表示されます。

メイン・ページは、Oracle SuperClusterの物理ビューを表示する1つのタブで構成されています。いずれかのターゲットをクリックすると、重要情報が表示され、ターゲットのランディング・ページが開きます。別のラックまたはMシリーズ・サーバーに切り替えるには、左のメニューで選択します(システムに複数のラックまたはMシリーズ・サーバーがある場合のみ可能。)

37.4.1 Oracle SuperClusterの物理ビュー

Oracle SuperClusterシステムの物理ビューには、Oracle SuperClusterシステムがラックにどのように物理的に構築されているかの概要が表示されます。システムに複数のラックまたはMシリーズ・サーバーがある場合、左側にあるセレクタからターゲットを選択して、その詳細な物理レイアウトを表示することができます。(ラックまたはサーバーが1つのみ存在する場合、セレクタは非表示です)。いずれかのターゲットまたはコンポーネントをクリックすると、その詳細情報を表示できます。ターゲットになんらかのインシデントが存在する場合は、その特定のターゲットが赤枠で強調され、注意が必要であることを示します。重大度ごとにグループ化されたインシデントを表示するには、ターゲットをクリックします。続けて重大度をクリックすると、インシデントの詳細をさらに取得できるインシデント・マネージャを開くことができます。

物理ビューの表示は、様々に切り替えることができます。

- フォトリアリスティック・ビューにはシステムのリアルな写真が表示され、すべてのコンポーネントの詳細なグラフィックスが提供されます。

- 構成図ビューはデータ指向で、ロケータ光、ステータス、温度、ホスト名などの、最も重要な情報が表示されます。ビューの各コンポーネントは、コンポーネントを簡単に識別できるように、タイプに基づいて色分けされています。

- 表ビューは、物理ビューを表で表したもので、表示対象コンポーネントと最も重要な情報のリストが表示されます。

図37-3は、Oracle SuperClusterシステムの前面ビューと背面ビューを示しています。

図37-3 Oracle SuperClusterラックのビュー

37.4.2 Oracle SuperClusterシステムでの仮想化管理

Oracle Superclusterの仮想化管理では、管理する予定の各仮想プラットフォームにEnterprise Managerエージェントをデプロイする必要があります。

Oracle VM Server for SPARCをモニタリングするには、制御ドメイン・オペレーティング・システムにホスト・ターゲットのEMエージェントをデプロイします。このエージェントは、すべてのOracle VM Server for SPARCリソースと、制御ドメインに構成されたSolarisゾーンをモニタリングします。Enterprise managerエージェントがゲスト・ドメイン・オペレーティング・システムにデプロイされると、ゲスト・ドメインに構成されたSolarisゾーンがモニタリングされます。ホスト・ターゲットの追加ウィザードを使用して、EMエージェントを制御ドメインとOracle Solarisゾーンにインストールできます。

37.5 Oracle SuperClusterの関連リソース

詳細は、次を参照してください:

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- インシデント管理の使用

- エンタープライズ・モニタリング

38 Oracleのオペレーティング・システムのモニタリング

この章では、Oracle SolarisおよびLinuxオペレーティング・システム、またはホストをモニタリングする方法について説明します。

内容は次のとおりです。

- Oracleのオペレーティング・システムのモニタリングのスタート・ガイド

- UI中でのOracleのオペレーティング・システム情報の場所

- オペレーティング・システムの処理

- すべてのホストのダッシュボードについて

- 特定のホストに関する情報の取得方法

- オープン・インシデントについて

- パフォーマンスおよびリソース・メトリックの概要

- ホスト・メモリーについて

- ホスト記憶域の表示

- ネットワーク接続性の表示

- ブート環境について

- 実行中のホスト・プロセスの表示

- 管理対象ホスト・サービスの表示

- ホスト・メトリックの処理

- ホストのメトリックおよびインシデント通知の管理

- ホスト・コンプライアンスについて

- オペレーティング・システムの関連リソース

38.1 Oracleのオペレーティング・システムのモニタリングのスタート・ガイド

オペレーティング・システムはコア・プラットフォームの一部であり、そのメトリックはEnterprise Managerの他のターゲットで利用されます。この章では、Oracle SolarisおよびLinuxのモニタリングについてのみ説明します。

Oracle Enterprise Managerでモニタリングしているすべてのホストを表示するには、Enterprise Manager Cloud Controlの「ターゲット」メニューで「ホスト」を選択します。ユーザー・インタフェースの「ホスト」セクションに、Oracle SolarisおよびLinuxオペレーティング・システム構成、リソースおよびプロセスのメトリックが表示されます。パフォーマンスとリソースのメトリックには、オペレーティング・システムのCPU、メモリーおよびプロセス・リソース使用状況が一元的に表示されるため、リソースを管理および最適化できます。

モニタリングは、オペレーティング・システムを検出して、管理するときにアクティブ化されます。予期しない動作が発生した場合、通知のステータス・レベルが段階的に高くなります。最も低いレベルのインシデント・ステータスは警告、次がクリティカル、最も高いレベルが致命的インシデントです。

パフォーマンスと使用率の最大化に役立つよう、オペレーティング・システムに関する情報が提供されます。「ホスト・サマリー」には、ホストの概要が表示されます。ドリルダウンしてCPUとリソースの使用状況を表示し、さらに深く進んでホスト上で実行されているプロセスを表示したり、ホスト上の現在の上位プロセスをリアルタイムで表示することができます。

オペレーティング・システムについては、次の機能が利用できます。

- OSの詳細: オペレーティング・システムのリソースおよびプロセスの情報、Oracle Solarisゾーンおよびブート環境が表示されます。

- インシデント: 詳細を表示するためのリンクを含むインシデントの通知。一連のモニタリング・ルールおよびパラメータが、管理対象アセットをモニタリングします。予期したとおりに実行されていないリソースについては、イベントとインシデントが生成されます。

- パフォーマンス: 分析: オペレーティング・システムのパフォーマンスとリソース使用状況の詳細が表示されます。

- 構成: オペレーティング・システムの構成の変更が表示されます。

38.2 UI中でのOracleのオペレーティング・システム情報の場所

Oracle SolarisおよびLinuxオペレーティング・システム情報は、ユーザー・インタフェース内の次の場所にあります。

表38-1 UI中でのオペレーティング・システム情報の場所

オブジェクト

場所

すべてのOracle SolarisおよびLinuxオペレーティング・システム

「ターゲット」セレクタで、「ホスト」を選択します。

オペレーティング・システム・パラメータが表にない場合は、「表示」をクリックしてから「列」をクリックし、オペレーティング・システム・パラメータを選択します。バージョンを表示するには、「ターゲット・バージョン」を選択します。

特定のOracle SolarisまたはLinuxオペレーティング・システム

「ターゲット」セレクタで、「ホスト」を選択します。「サマリー」ページを表示するには、ホストをクリックします。

特定のOracle SolarisまたはLinuxオペレーティング・システムのシステム・リソース

「ターゲット」セレクタで、「ホスト」を選択します。「サマリー」ページを表示するには、ホストをクリックします。詳細を表示するには、「ホスト」ページの右側にある次のタブ(「CPU」、「ホスト・メモリー」、「記憶域」、「ネットワークの接続性」、「ホスト・プロセス」または「ホスト・サービス」)のいずれかをクリックします。

モニタリング・メトリックと詳細、プログラム・リソース使用率、メトリックと収集設定、メトリック収集エラー、ステータス履歴、インシデント・マネージャ、アラート履歴およびブラックアウトとブラウンアウト。

「ターゲット」セレクタで、「ホスト」を選択します。「サマリー」ページを表示するには、ホストをクリックします。「ホスト」ドロップダウン・メニューをクリックして、「モニタリング」をクリックします。

38.3 オペレーティング・システムの処理

実行可能な操作は次のとおりです。

- ホストの構成およびステータスの表示

- ホスト詳細の表示

- オペレーティング・システムがデプロイされているプラットフォーム(物理または仮想)の表示

- CPUおよびメモリー・リソース使用率、および上位プロセスの使用状況の表示

- インシデントおよびパフォーマンス・メトリックを使用した問題の診断。

38.4 すべてのホストのダッシュボードについて

「ホスト」ダッシュボードは、インシデント、オペレーティング・システムのタイプ、オペレーティング・システムのバージョン、CPUとメモリーの使用率など、管理対象ホストに関する詳細が表示されるソート可能な表です。40を超えるホスト・パラメータが使用可能です。いくつかのパラメータはデフォルトで選択されていますが、それ以外は非表示です。ダッシュボードに表示されるパラメータと表示順序は変更できます。

38.4.1 すべてのホストのダッシュボードの表示

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、管理対象ホストがすべて、オペレーティング・システムの詳細とともに表示されます。ほとんどの列は昇順または降順でソートできます。

2. 「表示」、「列」の順にクリックして、ダッシュボードに表示するパラメータを表示または編集します。

3. パラメータを追加または削除するには、「表示」メニューでパラメータを選択または選択解除します。たとえば、「インシデント」、「オペレーティング・システム」および「ターゲット・バージョン」を表示するとします。

図38-1 ホスト・ダッシュボード

注意:
Oracle Solarisオペレーティング・システムは、ユーザー・インタフェース内にSunOSとして表示され、11.0.0.0リリースは、ターゲット・バージョン5.11.0.0.0として表示されます。

4. (オプション)ダッシュボードに表示される列を並べ替えることができます。「表示」をクリックして、「列の並替え」をクリックします。列を選択し、矢印ボタンを使用して、選択した項目を異なる位置に移動します。変更を保存するには、「OK」をクリックします。

38.5 特定のホストに関する情報の取得方法

サマリーには、選択したオペレーティング・システムの詳細およびメトリックが表示されます。

- ダッシュレット: ページの上部にある一連のダッシュレットにはサマリー情報が含まれており、タブ内のより詳細な情報に関連付けられていることもあります。

- タブ: 詳細情報へのページ・リンクの右側にある一連のタブ。

- ホスト・メニュー: パフォーマンスおよびリソース・メトリック、メトリック収集設定、ステータス履歴、インシデント、アラート履歴およびブラックアウトとブラウンアウトなど、ホストに関する詳細情報へのリンク。

38.5.1 ホスト・ターゲットのサマリーの表示

管理対象オペレーティング・システム・ターゲットのサマリーを表示できます。サマリーには、オペレーティング・システムがデプロイされているプラットフォーム(物理または仮想サーバー)およびインシデントが含まれます。

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストでホスト名をクリックして、そのホストの「サマリー」ページを表示します。
「サマリー」ページには、ホストに関する有益な情報を提供する一連のダッシュレット、およびホスト詳細および使用状況のサマリーが含まれます。

38.5.2 ホストのダッシュレットについて

ホスト・ページの最上部には、上位統計のクイック・ビューを提供する一連のダッシュレットが表示されます。ダッシュレット行の下にある小さなボタンをクリックすると、次の一連のダッシュレットに切り替わります。

図38-2 ダッシュレット

次のダッシュレットが表示されます。

- ホスト詳細: ホスト名、オペレーティング・システムのタイプ、バージョンとリリース、プライマリIPアドレスおよびオペレーティング・システムの起動までの時間など、短いサマリーが提供されます。

- オープン・インシデント: 致命的、クリティカルおよび警告の各インシデントの数が表示されます。数字の上にマウス・ポインタを重ねると、インシデントの小さいスナップショットが表示されます。インシデントの詳細は、数字またはサマリー・リンクをクリックして、「インシデント・マネージャ」コンソールに移動します。

- CPU使用率およびメモリー使用率: CPUとメモリーの使用率がグラフィックと数値で表示されます。

- OSサービス状態: 円グラフに、実行中、停止中、状態なしおよびその他の状態のサービスの割合が表示されます。

- 構成の変更: 最後の構成変更および最後に報告されたインシデントの日時が表示されます。

38.5.3 ホストのタブについて

アイコンが表示された次のタブが、ページの右側に表示されます。タブをクリックして、詳細を表示します。

- サマリー: Oracle SolarisおよびLinuxオペレーティング・システムのモニタリング情報のホームページ。ホスト詳細、インシデント、CPUおよびメモリー、サービスおよび構成変更を含むダッシュレットが表示されます。

- CPU: パフォーマンスおよびリソース・メトリックが表示されます。パフォーマンスおよびプロセスの使用状況に関する次のグラフを使用できます。CPU使用率、CPUスレッド使用率(Oracle Solarisのプロセッサ・グループのスレッド使用率、およびSPARC上のOracle SolarisのCPU頻度の状態を含む。)

- ホスト・メモリー: オペレーティング・システムのメモリー使用率、IPCSおよびスワップ詳細のビュー。

- 記憶域: ディスク、ファイルシステム、ボリューム・グループおよびSAN構成を含む、詳細な記憶域情報へのリンク。

- ネットワークの接続性: Oracle Solarisオペレーティング・システムのネットワーク・インタフェースおよびサブネットが表示されます。

- ブート環境: Oracle Solarisオペレーティング・システムの使用可能な代替ブート環境およびブート環境のスナップショットが表示されます。

- ホスト・プロセス: オペレーティング・システムの上位CPU、メモリー使用率およびプロセス・リソース使用率のビュー。

- ホスト・サービス: オペレーティング・システムによって管理されているサービスおよびそのサービスの状態が表示されます。

38.6 ホスト・メニューについて

「ホスト」メニューには、モニタリング情報や構成情報など、ホストに関する詳細情報へのリンクが表示されます。

ホスト・モニタリング・メニューでは、次の情報が表示されます。

- CPU詳細

- メモリーの詳細

- ディスクの詳細

- プログラム・リソース使用率

- すべてのメトリック

- メトリックと収集設定

- メトリック収集エラー

- ステータス履歴

- インシデント・マネージャ

- アラート履歴

- ブラックアウトとブラウンアウト

38.6.1 ホスト・モニタリング・メニューの表示

1. 「ターゲット」ページで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックして、「モニタリング」をクリックします。

4. さらに詳細を表示するには、オプションをクリックします。たとえば、収集されたすべてのメトリックを表示するには、「すべてのメトリック」をクリックします。

38.7 オープン・インシデントについて

「ホスト」ダッシュボードでは、すべてのオープン・インシデントを表示することも、ホストの「サマリー」ページにある特定のホストのオープン・インシデントを表示することもできます。

「ホスト」ダッシュボードにはすべての管理対象ホストがリストされ、オープン・インシデントが表示されます。列をソートすることも、列の番号をクリックして詳細が表示される「インシデント・マネージャ」ページに直接進むこともできます。別の方法として、「サマリー」ページでホスト名をクリックすると、ホストとホストのインシデントの詳細が表示されます。「ホスト・サマリー」ページのオープン・インシデントダッシュレットには、致命的、クリティカルおよび警告の各インシデントの数が表示されます。

38.7.1 オープン・インシデントの表示

ホストの「サマリー」ページにオープン・インシデントを表示する手順:

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストでホスト名をクリックして、そのホストの「サマリー」ページを表示します。

3. 番号をクリックすると、オープン・インシデントのサマリーが表示されます。

4. 「インシデント・マネージャ」に進むには、サマリー・テキストをクリックします。

図38-3 ホストのオープン・インシデントのサマリー・ページ

インシデント・マネージャは、インシデントの詳細とインシデントをもたらしたイベントを表示します。ドリルダウンすると、イベントと通知に関する詳細を取得することができます。オンラインの場合、リンクはMy Oracle Supportを参照します。

「インシデント・マネージャ」ページでは、インシデントの認識、コメントの追加またはインシデントの管理ができます。

38.7.2 OS構成の変更の識別

管理者がホスト構成を変更する場合、構成が最後に変更された日時を知っておくと役立つことがあります。この情報は、「サマリー」ページの構成ダッシュレットに表示されます。比較機能など、詳細構成情報を表示できます。

1. 「ターゲット」ページで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「構成」をクリックします。

4. 「最新収集」、「比較およびドリフト管理」、「比較」、「検索」、「履歴」、「保存」、「保存済」または「トポロジ」を表示するには、オプションをクリックします。

38.8 パフォーマンスおよびリソース・メトリックの概要

パフォーマンスおよびリソース・メトリックは、カーネル構成とパフォーマンスに関する詳細を提供するものであり、問題を識別する助けになります。「CPU負荷」チャートと「空きメモリー」チャートを使用すると、簡単にステータスを確認できます。高レベルのCPUおよびメモリー使用量は、「CPU」タブおよび「ホスト・メモリー」タブの詳細を含むダッシュレットに表示されます。

次のメトリックのCPUデータは15分ごとに収集され、「CPU」タブに表示されます。

- CPU使用率について

- CPUスレッド使用率について

- Oracle Solaris 11のプロセッサ・グループ使用率について

カーネル情報を表示するために、次のオプションが用意されています。

- 共有メモリー

- CPU I/Oは、キャッシュの読取り/書込みの詳細を待機してバッファに格納します

- 物理I/Oの読取り/書込み、ディスクおよびディスク・ブロックの読取り/書込み

- 実行キューの長さとページング・アクティビティ

- 調整可能なカーネル・パラメータ

リソース・メトリックは、オペレーティング・システム、利用できるリソースおよびオペレーティング・システムまたはゾーン上の負荷に関する詳細を提供します。

次の詳細が表示されます。

- メモリー(合計および使用可能)

- スワップ(構成済合計および使用可能)

- CPUの詳細(ベンダー名、型番、周波数、リビジョンおよびマスクなど)

- CPU当たりのコアおよびスレッド数

- CPUスレッドごとの使用率を示す棒グラフ

- Oracle Solarisの異なる周波数におけるすべてのCPUで費やされた時間

- 時系列上のCPUおよびメモリー使用状況

38.8.1 CPU使用率について

CPU使用率メトリックは、Oracle SolarisおよびLinuxターゲットについて、一定期間のCPUの使用率を表示します。値が異常に高い場合は、システムの負荷が高いことを示しています。この値が常に高い場合には、システム負荷の軽減を検討してください。

CPUデータは、15分ごとに収集されます。デフォルトの表示は、実行キューの長さのグラフィック表示で、1分平均は赤、5分平均は緑、15分平均は黄色の線で示されます。情報を表形式で表示するには、「表ビュー」をクリックします。

38.8.2 CPUメトリックの表示

オペレーティング・システムのカーネルとパフォーマンスのメトリックを表示する手順:

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストから、ホスト名をクリックします。

3. 「CPU」タブをクリックすると、メトリックとチャートが表示されます。
情報はグラフ形式で表示されます。「表ビュー」をクリックして、形式を変更します。時間枠を調整して、過去2時間、4時間、10時間、1日または1週間の履歴データを表示できます。デフォルトでは、CPUおよびシステム負荷が表示されます。グラフから情報を削除するには、選択を解除します。

38.8.3 CPUスレッド使用率について

CPUスレッド使用率メトリックには、Oracle SolarisおよびLinuxターゲットのCPUスレッド診断がグラフ形式で表示され、マルチスレッドCPUの分析に役立ちます。CPUスレッドごとに、効率およびメトリックを表示できます。

効率を評価するために、次のグラフを使用できます。

- 各周波数におけるCPUスレッドの数を示す棒グラフ

- 異なる周波数において要した時間の割合を示す履歴グラフ

38.8.4 Oracle Solaris 11のプロセッサ・グループ使用率について

CPU使用率に加えて、Oracle Solaris 11オペレーティング・システムの次のプロセッサ・グループ使用率の詳細を表示できます。

- プロセッサ・グループおよびグループごとのスレッド数のリスト

- プロセッサ・グループごとのCPU使用率の棒グラフ

- グループのタイプ(整数パイプラインなど)

38.9 ホスト・メモリーについて

「ホスト・メモリー」ページには、オペレーティング・システムのメモリー使用率が一元的に表示されます。

このページには、次の情報が表示されます。

- メモリー使用率: メモリー全体の使用率が表示されます。デフォルトのビューは、ある期間にわたって使用されたメモリーの割合をグラフで示します。ビューを変更して、ある期間にわたって使用されたメモリーのMBを表示できます。必要に応じて、メモリー全体の使用率をグラフではなく表で表示できます。

- 仮想メモリー: 仮想メモリー全体の使用率が表示されます。デフォルトのビューは、ある期間にわたって使用されたスワップ領域の割合をグラフで示します。ビューを変更して、ある期間にわたって使用されたメモリーのMBを表示できます。必要に応じて、仮想メモリー全体の使用率をグラフではなく表で表示できます。

- ページ・アクティビティ: ページング統計アクティビティが、色分けされたグラフ形式で表示されます。このグラフには、ページ・アクティビティが次のように表示されます。アドレス変換ページ・フォルトは青、ページインされたページは緑、ページアウトしたページはオレンジ、ページ・スティーリング・デーモンによってスキャンされたページ数は赤の線で示されます。すべてのアクティビティは、1日に対する1秒ごとのものになっています。必要に応じて、データをグラフではなく表で表示できます。

- メモリーの詳細: メモリーの詳細は円グラフで表示されます。このグラフには、空きメモリー、使用済メモリーおよびその他共有メモリーがメモリー全体の割合として表示されます。

- スワップ・ファイル: スワップ・ファイルおよび使用済領域量が表示されます。使用済スワップ領域量と空きスワップ領域量の概要がグラフで表示されます。

- ZFS ARCキャッシュ使用率: Oracle Solarisオペレーティング・システムのZFS ARC (Adaptive Replacement Cache)使用率が表示されます。

38.9.1 ホスト・メモリー使用率の表示

ホスト・メモリーのグラフを表示するには、次の手順を実行します。

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストから、ホスト名をクリックします。

3. 「ホスト・メモリー」タブをクリックして、メトリックとグラフを表示します。
場合によっては、グラフの横にある「表ビュー」をクリックして、情報を表形式で表示することができます。

4. メモリー使用率グラフおよび仮想メモリー使用量グラフのy軸を変更して、MBではなく割合として表示するには、「パーセンテージ別」を選択します。「時間範囲」メニューから時間枠を選択して、2時間からデフォルトに変更します。

38.9.2 メモリーおよびスワップ・ファイルの詳細の表示

メモリーおよびスワップ・ファイルの詳細を表示するには、次の手順を実行します。

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストから、ホスト名をクリックします。

3. 「ホスト・メモリー」タブをクリックして、中央のペインの「IPCSおよびスワップ詳細」をクリックします。

38.9.3 ホストのメモリーの詳細の表示

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「モニタリング」をクリックして、「メモリーの詳細」をクリックします。

38.10 ホスト記憶域の表示

ホスト記憶域には、ディスク、ファイルシステム、ボリューム・グループおよびSAN構成を含む、詳細な記憶域情報へのリンクが含まれます。すべての記憶域を表示するか、ボリューム名でフィルタ処理するか、ローカルまたはリモート記憶域のみを表示するように選択できます。

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストから、ホスト名をクリックします。

3. ホスト記憶域タブをクリックします。

4. 「ローカル」または「リモート」を選択して、記憶域のサブセットを表示します。「ボリューム名」フィールドに名前を入力して、結果をフィルタ処理します。

5. 表示する記憶域詳細のアイコンをクリックします。たとえば、Linuxの場合、オプションは、「ディスク」、「ファイルシステム」、「Linux LVMボリューム・グループ」および「SAN構成」です。

38.11 ネットワーク接続性の表示

「ネットワークの接続性」には、ネットワーク・インタフェースおよびホストに関連付けるサブネットが表示されます。

ネットワークの様々な層を表示できます。

- ネットワーク・インタフェース: ネットワークの状態、各ネットワーク・インタフェースのサブネットおよびフラグの詳細が表示されます

- データリンク: 各データリンクのデータリンクの状態、物理アドレスおよびメディアのタイプ(イーサネットなど)が表示されます。

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストから、ホスト名をクリックします。

3. 「ネットワークの接続性」タブをクリックします。

4. 「インタフェース」または「データリンク」層を表示するには、アイコンをクリックします。

38.12 ブート環境について

Oracle Solaris 11のブート環境では、beadmユーティリティおよびZFSファイルシステムを使用して、ブート環境を作成および管理します。Oracle Solaris 11ソフトウェアは、ブート環境を自動的に作成します。

ブート環境は、ブート可能なOracle Solarisイメージのインスタンスに、そのイメージにインストールされているその他のソフトウェア・パッケージ、およびOracle Solaris OSインスタンスの操作に必要となる、すべてのファイルシステムとデバイス(ディスク・スライスおよびマウント・ポイント)のセットを加えたものです。1つのシステムでアクティブにできるブート環境(ブートされた環境)は1つのみです。代替ブート環境は、現在ブートされていない非アクティブな環境です。システムは、複数の非アクティブなブート環境を持つことができます。

多くの場合、デュアル・ブート環境は、パッチ適用に通常は伴うサービス停止時間を大幅に削減できるため、更新の管理に使用されます。また、複数のブート環境を維持することで、パッチが適用される前のバージョンに、必要に応じて迅速かつ容易にロールバックすることもできます。

Oracle Solarisオペレーティング・システム・ページの「ブート環境」タブには、Oracle Solarisブート環境およびファイルシステムの詳細(使用可能なすべてのブート環境、サイズおよび同期日時など)が表示されます。選択したブート環境について、スナップショットの詳細、ファイルシステムの詳細および関連付けられているゾーンのブート環境を表示できます。このタブは、Oracle Solarisオペレーティング・システムでのみ使用できます

Oracle Solarisオペレーティング・システム・ページの「ブート環境」タブには、Oracle Solarisブート環境およびファイルシステムの詳細(使用可能なすべてのブート環境、サイズ、およびその環境が作成または同期された日時など)が表示されます。「ブート環境」タブは、Oracle Solarisオペレーティング・システムでのみ使用できます

38.12.1 Oracle Solarisブート環境の表示

1. 「ターゲット」メニューから「ホスト」を選択します。

2. 管理対象ホストのリストから、Oracle Solarisオペレーティング・システムを選択します。

3. 「ブート環境」タブをクリックして、ブート環境のスナップショットおよびファイルシステムの詳細を表示します。ファイルシステムの詳細は、ブート環境の後のページの下部にあります。

4. オペレーティング・システムを展開すると、ブート環境のスナップショットが表示されます。

38.13 実行中のホスト・プロセスの表示

「ホスト・プロセス」ページには、オペレーティング・システムの上位プロセス(各プロセスのCPUおよびメモリーの使用率を含む)が一元的に表示されます。

1. 「ターゲット」メニューから「ホスト」を選択します。
「ホスト」ページに、すべての管理対象ホストのリストが表示されます。リストはソートできます。

2. 管理対象ホストのリストから、ホスト名をクリックします。

3. 「ホスト・プロセス」タブをクリックすると、プロセスが表示されます。

38.14 管理対象ホスト・サービスの表示

ホスト・サービスを使用すると、オペレーティング・システムで管理されているサービスとそのサービスの状態を表示できます。これは、どのサービスに注意が必要か、また、重要とみなしているサービスがどのような状態かを短時間で識別するのに役立ちます。

ホスト・サービスによって、ホストで実行中のサービスがモニタリングおよび表示されます。サービスの現在の状態を表示できます。ただし、サービスのプロパティを作成、削除または変更することはできません。障害管理リソース識別子(FMRI)は、システム上の各サービスを識別します。

次に、サービスの状態を示します。

- 実行中: サービスが実行されています。

- 停止済。サービスが無効またはオフラインで、サービスは実行されていません。

「ホスト・サービス」ページでは、サービスの状態、生成されたプロセス識別子の数および生成されたプロセス識別子(PID)が表示されます。

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. 管理対象ホストのリストでホスト名をクリックして、そのホストの「サマリー」ページを表示します。

3. ダッシュレットの下にある「2番目のダッシュレット・シリーズ」ボタンをクリックして、サービスの現在のステータスを示すチャートを表示します。

4. ユーザー・インタフェースの右側にある「ホスト・サービス」タブをクリックして、サービスの詳細を表示します。

5. デフォルトのビューでは、停止中のサービスが表示されます。ビューを変更するには、ラジオ・ボタンをクリックします。Oracle Solarisの場合、オプションは、「オフライン」、「オンライン」または「すべて」です。Linuxの場合、オプションは、「停止済」、「実行中」または「すべて」です。

6. 番号をクリックすると、生成されたプロセス識別子(PID)が表示されます。

38.15 ホスト・メトリックの処理

次のような詳細なホスト・メトリックは、「ホスト」メニューから表示できます。

- ホストのCPU、メモリーおよびディスクの詳細の表示

- ホストのプログラム・リソース使用率の表示

38.15.1 ホストのCPU、メモリーおよびディスクの詳細の表示

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「モニタリング」をクリックして、「CPU詳細」、「メモリーの詳細」または「ディスクの詳細」をクリックします。

38.15.2 ホストのプログラム・リソース使用率の表示

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「モニタリング」をクリックして、「プログラム・リソース使用率」をクリックします。

38.15.3 すべてのメトリックの表示

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「モニタリング」をクリックして、「すべてのメトリック」をクリックします。

4. (オプション)メトリックではなくカテゴリ別に表示するには、「表示」をクリックして、「メトリック・カテゴリ別」をクリックします。

5. メトリックをクリックすると、詳細、収集スケジュール、アップロード間隔およびその他の詳細が表示されます。

38.16 ホストのメトリックおよびインシデント通知の管理

次のタスクを実行して、モニタリングおよびインシデント通知を管理できます。

- ホストのメトリック収集エラーの表示

- ホストのメトリックおよび収集設定の編集

38.16.1 ホストのメトリック収集エラーの表示

メトリック収集エラーの原因は通常、インストールまたは構成の問題です。

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「モニタリング」をクリックして、「メトリック収集エラー」をクリックします。

38.16.2 ホストのメトリックおよび収集設定の編集

「メトリック」タブには、モニター対象属性がすべて表示されます。デフォルトのビューは、しきい値が設定されるメトリックです。このようなタイプのモニター対象属性の場合、比較演算子、しきい値の制限、修正処理、収集スケジュールを変更できます。

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「モニタリング」をクリックして、「メトリックと収集設定」をクリックします。

4. しきい値の制限または収集スケジュールを変更します。しきい値のフィールドが空の場合、そのメトリックのアラートは無効になります。

5. 詳細設定の「編集」アイコンをクリックします。
「収集されたその他のアイテム」タブをクリックすると、しきい値以外のモニター対象属性が表示されます。このような属性の収集期間を変更したり、モニタリングを無効にできます。

38.17 ホスト・コンプライアンスについて

ホスト・コンプライアンスには、コンプライアンス・フレームワーク、標準、および「コンプライアンス標準ライブラリ」で選択したコンプライアンス標準に関連付けられているターゲットの詳細が示されます。

Cloud Controlによって、コンプライアンス・フレームワークに対するターゲットのコンプライアンスの評価結果およびレベルが表示されます。コンプライアンス・フレームワークの評価結果には、フレームワークの状態の概要、コンプライアンスのレベル(クリティカル、警告またはコンプライアンス)および違反のクリティカル度(クリティカル、警告またはマイナー警告)が示されます。平均スコア(割合)および作成者を表示できます。

コンプライアンス・フレームワーク・エラーが検出されると、次の情報が表示されます。

- ルート・コンプライアンス標準

- ルート・ライフサイクルの状態

- 親コンプライアンス標準

- ルール

- ルート・ターゲット情報

- ターゲット情報

- エラーの日付

- エラー・メッセージ

38.17.1 コンプライアンス・フレームワークの表示

「コンプライアンス・フレームワーク」タブでは、評価結果およびエラーが表示されます(存在する場合)。

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「コンプライアンス」をクリックして、「結果」をクリックします。

4. 「コンプライアンス・フレームワーク」をクリックして、「評価結果」タブを表示します。

5. コンプライアンス・フレームワーク・エラーがあるかどうかを確認するには、「エラー」タブをクリックします。

38.17.2 コンプライアンス標準の表示

ホストの特定のコンプライアンス標準を検索して、評価結果およびエラーを表示できます。

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「コンプライアンス」をクリックして、「結果」をクリックします。

4. 「コンプライアンス標準」をクリックし、「評価結果」タブを表示します。

5. コンプライアンス・フレームワーク・エラーがあるかどうかを確認するには、「エラー」タブをクリックします。

38.17.3 ターゲット・コンプライアンスの表示

ターゲット・コンプライアンスの表に、「コンプライアンス標準ライブラリ」で選択したコンプライアンス標準に関連付けられているターゲットをリストします。

1. 「ターゲット」メニューで「ホスト」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「ホスト」をクリックします。「コンプライアンス」をクリックして、「結果」をクリックします。

4. 「ターゲット・コンプライアンス」をクリックして、標準に準拠しているターゲットを表示します。

38.18 オペレーティング・システムの関連リソース

詳細は、次を参照してください:

- ターゲットの検出および追加の概念は、「ホスト・ターゲットと非ホスト・ターゲットの検出および追加」。

- オペレーティング・システムおよび他のシステム・インフラストラクチャ・ターゲットの検出方法は、「システム・インフラストラクチャ・ターゲットの検出、昇格および追加」。

- ホストの記憶域ファイルシステムの表示および記憶域情報の表示の詳細は、「記憶域の管理」。

- 参照できる情報のタイプの詳細は、「OSアセットのネットワークの詳細の表示」。

- インシデントの管理の詳細は、「インシデント管理の使用」。

次については、http://docs.oracle.com/en/operating-systems/にアクセスしてください。

- Oracle Solarisドキュメント

- Oracle Linuxドキュメント

39 Oracle Solarisゾーンのモニタリング

この章では、Oracle Solarisゾーンのモニタリングについて説明します。

内容は次のとおりです。

- Oracle Solarisゾーンのモニタリングのスタート・ガイド

- UI中でのOracle Solarisゾーン情報の場所

- ゾーンの処理

- ゾーンのターゲット・ナビゲーション

- ゾーンに関する情報の取得方法

- ゾーン・プラットフォーム・メトリックの処理

- ゾーン固有のメトリックの処理

- ゾーンのインシデントの処理

- ゾーンのメトリックおよびインシデント通知の管理

- ゾーンの管理

- Oracle Solarisゾーンの追加リソース

39.1 Oracle Solarisゾーンのモニタリングのスタート・ガイド

Oracle Solarisゾーン(Oracle Solarisコンテナとも呼ばれます)は、オペレーティング・システムを仮想化するために使用され、ソフトウェア・アプリケーションを実行するための隔離されたセキュアな環境を提供します。ゾーンとは、Oracle Solarisオペレーティング・システムの1つのインスタンス内で作成される、仮想化されたオペレーティング・システム環境です。

ゾーンは、ソフトウェアで定義された壁で作成された柔軟な箱と考えてください。単一または複数のアプリケーションが、システムの他の部分と対話することなく、この箱で実行されます。ゾーンはソフトウェア・アプリケーションまたはサービスを隔離するため、Oracle Solaris OSの同じインスタンスで実行されている複数のアプリケーションは、互いに独立に管理されます。たとえば、同じアプリケーションの異なるバージョンを、別々のゾーンで実行できます。ゾーンは、Oracle Solaris 10以上のオペレーティング・システムを実行しているマシンを必要とします。Solaris 11グローバル・ゾーンとSolaris 10 update 11グローバル・ゾーンはサポートされています。

グローバル・ゾーンはデフォルトのオペレーティング・システムであり、すべてのプロセスを制御し、システム全体の管理を制御します。グローバル・ゾーンは、すべての非グローバル・ゾーンのCPU、メモリーおよびネットワーク・リソース割当てを監督します。他のゾーンが構成されていない場合でも、グローバル・ゾーンは常に存在します。

非グローバル・ゾーンまたは単にゾーンは、グローバル・ゾーンの内部に構成されます。ゾーンは、仮想プラットフォーム層によって物理ハードウェアから隔離されます。ゾーンは、他のゾーンの存在を認識できません。

カーネル・ゾーンとは、グローバル・ゾーンのオペレーティング・システム・カーネル内からの仮想化を実装するゾーンです。各カーネル・ゾーンには、グローバル・ゾーン、独自のファイルシステムおよびユーザー空間からの、別個のカーネルがあります。各ゾーン(グローバル・ゾーンを含む)の構成は、ゾーンで利用できるCPU、メモリーとI/Oリソースに制限を設定します。カーネル・ゾーンは、Solaris 11.2以降でサポートされます。カーネル・ゾーンを使用すると、非グローバル・ゾーンを独自のオペレーティング・システム・カーネル・インスタンスとともにデプロイできます。非グローバル・ゾーンには、グローバル・ゾーンと異なるカーネル・バージョンがあります。カーネル・ゾーンの中に1レベルの非カーネル・ゾーンを作成できます。

Oracle Solarisでは、次のタイプの非グローバル・ゾーンを使用できます。

- ネイティブ・ゾーン: グローバル・ゾーンと同じバージョンのSolarisを持つ別個のSolaris 10またはSolaris 11インスタンス。入れ子にされたゾーンは作成できません。

- Solaris 10ブランド・ゾーン: Solaris 11グローバル・ゾーン内部で実行される、独立したSolaris 10インスタンスで、既存のSolaris 10デプロイメントから移行するための道筋となります。入れ子にされた非グローバル・ゾーンはサポートされません。

- カーネル・ゾーン: 非グローバル・ゾーン内部で、異なるカーネル・バージョンを実行します。カーネル・ゾーンは完全に独立したオペレーティング・システム・インスタンスで、カーネル・ゾーン内では、入れ子にされた(非カーネル)ゾーンを作成できます。カーネル・ゾーンは、Oracle Solaris 11.2リリース以上で使用できます。

ユーザー・インタフェースでは、ゾーンはアイコンによって表されます。グローバル・ゾーン、カーネル・ゾーン、非グローバル・ゾーンなどの異なるタイプのゾーンは、異なるアイコンで示されます。

次のSolaris 10およびSolaris 11のグローバル・ゾーンと非グローバル・ゾーンは、Enterprise Managerユーザー・インタフェースを介してモニターできます。

- ネイティブのSolaris 10非グローバル・ゾーンを実行している、Solaris 10グローバル・ゾーン

- Solaris 10のブランド非グローバル・ゾーンを実行している、Solaris 11グローバル・ゾーン

- ネイティブのSolaris 11非グローバル・ゾーンを実行している、Solaris 11グローバル・ゾーン

- Solaris 11カーネル・ゾーンを実行しているSolaris 11グローバル・ゾーン

Enterprise Managerは、次のタイプの仮想化をサポートしています。

- Oracle Solarisゾーン: オペレーティング・システム仮想化

- Oracle VM Server for SPARC: SPARCプラットフォーム上のハードウェア仮想化

SPARCプラットフォーム上の、任意のタイプの論理ドメイン内にあるゾーンを表示できます。

ハイパーバイザは、1つ以上の非グローバル・ゾーンの管理を担当します。非グローバル・ゾーンは、物理サーバーから利用できるCPU、メモリーおよびI/Oリソースのサブセットを与えられた仮想サーバーや、グローバル・ゾーンの構成済リソースの裏付けのある一部の仮想リソース(仮想ディスクやネットワークなど)にデプロイされたオペレーティング・システム・インスタンスとして表されます。グローバル・ゾーンは常に存在するものであり、非グローバル・ゾーンの制御ゾーンです。

39.2 UI中でのOracle Solarisゾーン情報の場所

ゾーンの子または親である任意のターゲット(仮想プラットフォーム、ホストまたはサーバー)を選択でき、ゾーンはターゲットのナビゲーション・ペインに表示されます。

仮想化プラットフォームは、ゾーンを実行するコンテナです。グローバル・ゾーンおよび関連するすべてのゾーンがゾーン仮想化プラットフォーム・ページに表示されます。グローバル・ゾーンは、仮想サーバーによっても表されます。各非グローバル・ゾーン(仮想サーバー)およびカーネル・ゾーンには、そのゾーン固有の詳細を表示する独自の「仮想サーバー」ページがあります。

「すべてのターゲット」ページでは、次のオプションを使用できます。

- 「仮想化プラットフォーム」をクリックすると、仮想プラットフォームのリストが表示されます。このリストで任意の仮想プラットフォームをクリックして、仮想プラットフォームのホームページを開くことができます。

- 「仮想サーバー」をクリックすると、仮想サーバーのリストが表示されます。このリストで任意の仮想サーバーをクリックして、仮想サーバーのホームページを開くことができます。

表39-1 UI中でのゾーン情報の場所

オブジェクト

場所

仮想化プラットフォーム

仮想プラットフォーム・ターゲットのホームページには、「すべてのターゲット」ページから、またはその親または子ターゲットのいずれかから、ターゲット・ナビゲーション・ペインを使用してアクセスできます。

ページの上部にある「すべてのターゲット」セレクタをクリックします。「検索の絞込み」セクションで、「仮想化プラットフォーム」を選択します。

ターゲットは、この仮想プラットフォーム上で実行中のホスト、サーバーまたはゾーン・ターゲットにすることができます。

ターゲット・ナビゲーション・ペインは、親または子のホームページの左上隅にあります。ターゲット・ナビゲーション・ペインをクリックして展開し、ナビゲーション・ペイン内の仮想プラットフォームを確認します。

ゾーン固有の(仮想サーバー)ページ

ゾーン仮想サーバー・ターゲットのホームページには、Solarisゾーンの「仮想化プラットフォーム」ページまたは、「すべてのターゲット」ページからアクセスできます。

ページの上部にある「すべてのターゲット」セレクタをクリックします。「検索の絞込み」セクションで、「仮想サーバー」を選択します。

Solarisゾーンの「仮想化プラットフォーム」ページを表示している場合は、ゾーンをクリックして、そのゾーンの仮想サーバー・ページに移動します。

39.3 ゾーンの処理

Solaris 11またはSolaris 10 update 11のホスト・オペレーティング・システムを検出すると、仮想化プラットフォームが自動的に昇格されます。

実行可能な操作は次のとおりです。

- ゾーンの構成およびステータスの表示

- CPUとメモリー・リソースの使用率およびCPUとメモリー・コンシューマの配分の表示

- インシデントおよびパフォーマンス・メトリックを使用した問題の診断。

- モニタリング通知とモニタリングの無効化および有効化

39.4 ゾーンのターゲット・ナビゲーション

ターゲット・ナビゲーション・ツリーは、Solarisゾーン仮想プラットフォームにあるターゲット間の移動に役立ちます。グローバル・ゾーンのエージェント・デプロイ全体で、すべてのリソースが検出およびモニタリングされている場合は、サーバーからゾーンまで移動できます。

ターゲット・ナビゲーション・ツリーのトップ・レベル、つまりノードは物理サーバーであり、第2ノードは、グローバル・ゾーンをホストしているOracle Solarisゾーン仮想プラットフォームとなります。グローバル・ゾーンおよびその他すべてのタイプのゾーンは、Oracle Solarisゾーン仮想プラットフォームの下に表示されます。ノードを展開してターゲット階層をドリルダウンするか、または特定のターゲットをクリックして、そのターゲットのランディング・ページを開きます。

図39-1は、グローバル・ゾーンおよび2つのカーネル・ゾーンを示すターゲット・ナビゲーション・ツリーの例です。最初のノードは物理サーバー(smx42-1)です。第2ノードは、グローバル・ゾーンと2つのカーネル・ゾーン(kernelzone1およびkernelzone2)をホストしている、Solarisゾーン仮想プラットフォームです。グローバル・ゾーンはオペレーティング・システムを実行中です(smx42-1-n17ホスト。)エージェントがkernelzone1上にデプロイされた場合、これにより、Solarisゾーン仮想プラットフォーム(smvt-175-10)の検出および昇格がトリガーされます。kernelzone1のSolarisゾーン仮想プラットフォームでは、グローバル・ゾーン、オペレーティング・システム(smvt-175-10 host)および2つのローカル・ゾーン(ゾーン1およびゾーン2)が実行されています。

図39-1 ゾーンのターゲット・ナビゲーション

39.5 ゾーンに関する情報の取得方法

プラットフォームの観点から、または特定のゾーンについて、ゾーンに関する情報を表示できます。ゾーンは、Solarisゾーンの「仮想化プラットフォーム」ページに表示され、各グローバル・ゾーン、カーネル・ゾーンおよび非グローバル・ゾーンには、独自の仮想サーバー・ページがあります。

Solarisゾーンの「仮想化プラットフォーム」ページには、ゾーンについての一般情報(オープン・インシデント、CPU使用状況、メモリー・リソース、実行中および構成済のゾーンの数、グローバル・ゾーンのすべてのゾーンのリストとその状態など)が表示されます。

仮想化プラットフォームは、ゾーンを実行するコンテナです。「仮想化プラットフォーム」ページに移動すると、仮想プラットフォーム上で実行中のゾーン(仮想サーバー)のリストが表示されます。ゾーンをクリックすると、そのゾーンのホームページが表示されます。

「サマリー」には、選択したゾーンの詳細およびメトリックが表示されます。

- ダッシュレット: ページの上部にある一連のダッシュレットにはサマリー情報が含まれており、タブ内のより詳細な情報に関連付けられていることもあります。

- タブ: ページの右側にある一連のタブは、CPUやメモリー・パフォーマンスなど、より詳細な情報にリンクされています。

ページの上部には、上位の統計のクイック・ビューを表示する一連のダッシュレットが含まれています。ダッシュレット行の下にある小さなボタンをクリックすると、次の一連のダッシュレットに切り替わります。ダッシュレットを最小化するには、切替えアイコンの下のアイコンをクリックします。

仮想化プラットフォームのダッシュレットには、次のタイプの情報が表示されます。

- プラットフォーム・ステータス

- ゾーン・プラットフォームが稼働していた時間

- オープン・インシデント

- ゲストの構成

- ゾーン当たりのCPUおよびメモリー・コンシューマの配分

- 最後の構成変更とインシデントの日時

詳細は、「ゾーン・プラットフォーム・メトリックの処理」を参照してください。

仮想サーバーのダッシュレットには、固有のゾーンに関する次のタイプの情報が表示されます。

- ゾーン・ステータス

- CPUとメモリーの使用状況

- ゲストの構成

- 最後の構成変更とインシデントの日時

詳細は、「ゾーン固有のメトリックの処理」を参照してください。

39.6 ゾーン・プラットフォーム・メトリックの処理

仮想化サーバーのプラットフォーム・メトリックを使用して、データ・センター内の仮想サーバーのパフォーマンスおよびリソース使用率をモニタリングできます。この情報を使用して、リソースをバランスさせたり、将来のパフォーマンスを向上させるためにリソースの追加を事前に計画したりすることができます。

CPUおよびメモリー・コンシューマの配分は、潜在的な問題をプロアクティブに識別できるため、最も負荷の高いゾーンの管理に役立ちます。「サマリー」ページにある最新のダッシュレットには、最後の構成変更および最後のインシデントの日付とタイム・スタンプが表示されます。

ページ上部に横並びに表示されるダッシュレットでは、次のゾーン・メトリックを使用できます。

- プラットフォーム・ステータス

- Oracle Solarisバージョン。

- 現在の状態: 現在のヘルス・ステータスおよびゾーンが稼働している時間が表示されます。

- オープン・インシデント: 致命的、クリティカルおよび警告のインシデントの数が表示されます。数字をクリックすると、シノプシスが表示されます。インシデント詳細を表示するには、シノプシスをクリックして、インシデント・マネージャ・コンソールに移動します。

- CPU使用率: プラットフォームによって使用されているCPUの割合が表示されます。

- メモリー使用量。

- ゲスト数。ゲスト数は、ゾーンの合計数を示します。ゾーンがまだ検出および昇格の処理中である場合、ゲスト数は、ゲストの合計数と自動昇格のキューにまだ入っているゲストの数を示します。

- ゲストの構成

- ゾーンの数: 実行中のゾーン数および構成済のゾーン数が表示されます。

- 仮想CPU: 仮想CPUの数が表示されます。円グラフにカーソルを重ねると、専用CPUと共有CPUの数が表示されます。

- ゾーン当たりのCPUおよびメモリー・コンシューマの配分:

- CPU使用量: 合計CPU使用量と、0-20、20-40、40-60、60-80および80-100パーセントの範囲でCPUを消費しているゾーンまたはゲストの数が表示されます。

- メモリー使用量: 合計メモリー使用量と、0-20、20-40、40-60、60-80および80-100パーセントの範囲でメモリーを消費しているゾーンまたはゲストの数が表示されます。

- 最終変更

- 構成の変更: 構成における最終変更の日付およびタイム・スタンプが表示されます。

- インシデント: 最後のインシデントの日付およびタイム・スタンプが表示されます。

ページの本体には、仮想化プラットフォームの詳細が含まれます。「仮想プラットフォームのゲスト」には、ゾーンおよびゾーン詳細(ゾーン名、ゾーンのタイプ、過去5時間にわたるCPU使用率およびインシデント)のリストが含まれます。ページは、リストまたは表として表示できます。デフォルト・ビューはリスト・ビューであり、インシデント数でソートされています。リスト・ビューにはソートとフィルタリングのオプションがあり、これにより、ゾーンのタイプ、ゾーン名または割当て済リソースによってソートできます。または、「仮想プラットフォームのゲスト」ページをソート可能な表として表示することもできます。「名前」、「タイプ」、「可用性」、「ステータス」、「状態」または「メモリー」の各列でソートできます。また、「致命的」、「クリティカル」または「警告」インシデントの各列でソートすることもできます。

39.6.1 ゾーン・プラットフォーム・メトリックの表示

メトリックの一部はダッシュレットに表示されますが、特定のゾーン・メトリックの詳細は、「サマリー」ページを参照してください。

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」から、「仮想化プラットフォーム」を選択します。

3. Solaris仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。

4. ダッシュレットには、メトリック情報が表示されます。「サマリー」ページには、各ゾーンの詳細が表示されます。詳細には、ゾーン名、ゾーンのタイプ(グローバル、非グローバル、カーネル)、ステータス、vCPUの数、メモリーおよびインシデントが含まれます。

5. ページの本体には、仮想化プラットフォームのゲストまたはゾーンの詳細が含まれます。

39.7 ゾーン固有のメトリックの処理

仮想サーバー・メトリックを使用すると、特定のゾーンのパフォーマンスおよびリソース使用率をモニタリングできます。

仮想化プラットフォームには、ゾーン当たりのCPUおよびメモリー・コンシューマの配分が表示されます。仮想サーバーには、単一のゾーン(グローバル、非グローバルまたはカーネル)による負荷が表示されます。仮想サーバーの「サマリー」ページにある最新のダッシュレットには、最後の構成変更および最後のインシデントの日付とタイム・スタンプが表示されます。

ページ上部に横並びに表示されるダッシュレットでは、次のメトリックを使用できます。

- 仮想サーバーのステータス

- 現在の状態: 現在のヘルス・ステータスおよびゾーンのタイプ(グローバル、非グローバルまたはカーネル)が表示されます。

- オープン・インシデント: 致命的、クリティカルおよび警告のインシデントの数が表示されます。数字をクリックすると、シノプシスが表示されます。インシデント詳細を表示するには、シノプシスをクリックして、インシデント・マネージャ・コンソールに移動します。

- CPUとメモリーの使用率

- CPU使用率: 仮想サーバーによって使用されているCPUの割合が表示されます。

- メモリー使用量: 仮想サーバーによって使用されているメモリーの割合が表示されます。

- 仮想サーバーの構成

- ゲストOS情報: ホスト名、IPアドレスおよびゲスト(ゾーン)が稼働している時間が表示されます。ゲストOS情報を受信するには、ゾーンのオペレーティング・システム上にエージェントをデプロイする必要があります。

- ゲスト構成: ゲストUUID、ホストIDおよび自動ブートが有効化されているかどうかが表示されます。

- 最終変更

- 構成の変更: 構成における最終変更の日付およびタイム・スタンプが表示されます。

- インシデント: 最後のインシデントの日付およびタイム・スタンプが表示されます。

ページの本体には、操作ステータス、仮想サーバーのタイプ(グローバル、非グローバルまたはカーネル・ゾーン)、共有や専用CPUの数、すべてのゾーンで共有されている制限されたメモリー量(定義されている場合)や制限されていないメモリー量など、仮想サーバーに関する詳細が含まれます。また、このページには、CPU使用率プロファイルとメモリー使用量プロファイルを示す2つのグラフも含まれます。グラフには、それぞれ過去7日間および24時間の履歴データが含まれます。「仮想サーバーの使用状況」タブには、より詳細なCPUとメモリーのグラフが表示されます。

39.7.1 ゾーン・メトリックのサマリーの表示

ゾーンの仮想プラットフォームの「サマリー」ページには、ゾーン固有のメトリックおよびリソース使用率のグラフが表示されます。

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある、「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。仮想化プラットフォームでは、ドリルダウンしてオープン・インシデントのある仮想サーバーを確認できます。

3. Solaris仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。

39.7.2 ゾーンのCPUおよびメモリーのメトリックの表示

ゾーン固有のCPUおよびメモリーの使用率メトリックとリソース使用率のグラフは、ゾーンの仮想サーバー・ページに表示されます。「すべてのメトリック」ページでは、さらに詳細なメトリックを入手できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」をクリックします。

2. 仮想サーバーの「サマリー」ページを開くには、ターゲット名をクリックします。CPUおよびメモリーのメトリックは、ゾーンのホームページおよびホームページのダッシュボードに表示されます。次の7日間に加えて24時間および過去5時間の使用率プロファイルが表示されます。

3. ページの右側にある「仮想サーバーの使用状況」アイコンをクリックすると、CPUおよびメモリーの「リソース使用状況」グラフが表示されます。グラフ・ページのスライダ・アイコンを動かして、グラフで表示する日数を変更します。最大7日分の表示ができます。

39.8 すべてのメトリックの表示

「すべてのメトリック」ページでは、プラットフォームおよび仮想サーバー・メトリックを使用できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」をクリックします。

2. ターゲット名をクリックして、ターゲットに応じて、Solaris仮想化プラットフォーム・ページまたは「仮想サーバー」ページを開きます。

3. ページの左上隅にあるSolaris仮想化プラットフォームまたは「仮想サーバー」をクリックします。「モニタリング」をクリックして、「すべてのメトリック」をクリックします。メトリックをクリックすると、詳細、収集スケジュール、アップロード間隔およびその他の詳細が表示されます。

注意:
構成メトリック・リストに表示されますが、コンポーネント・フォルト・メトリックは仮想サーバーにサポートされていません。
CoreUsageメトリックは、フル・コアが割り当てられているゲスト・ドメインの場合のみ報告されます。

39.9 ゾーンのインシデントの処理

次の情報は、ゾーンのインシデント情報を処理するときに役立ちます。

- ゾーンのインシデントについて

- ゾーンのオープン・インシデントの表示

39.9.1 ゾーンのインシデントについて

「仮想化プラットフォーム」ページには、その仮想化プラットフォームに関するすべてのオープン・インシデントが表示されるため、プラットフォームに問題があるかどうかをすばやく確認できます。

ゾーンについては、「仮想化プラットフォーム」ページに表示されるインシデントの数に、グローバル・ゾーンおよびグローバル・ゾーンに関連付けられているすべてのゾーンのインシデントが含まれます。「オープン・インシデント」ダッシュレット内の数字をクリックすると、インシデントと、そのインシデントが発生したターゲットのリストが表示されます。

インシデントのリストでは、ターゲット(グローバル・ゾーンまたはゾーン)・リンクをクリックして、対応するターゲットのホームページに移動したり、インシデントをクリックして、対応するターゲットの「インシデント・マネージャ」ページにリダイレクトできます。

注意:
「仮想化プラットフォーム」ページでのオープン・インシデントの数は、そのプラットフォーム(グローバル・ゾーンおよびすべてのゾーン)に対するすべてのオープン・インシデントを示します。デフォルトでは、グローバル・ゾーンの「インシデント・マネージャ」ページには、グローバル・ゾーンのオープン・インシデントが表示され、関連付けられているゾーンについては表示されません。グローバル・ゾーンおよびゾーンに対するインシデントが表示されるように、インシデント・マネージャでの表示を変更できます。インシデント・マネージャで、「検索」を選択して、「メンバーを含む」検索基準に「ターゲットとすべてのメンバー」を選択します。

39.9.2 ゾーンのオープン・インシデントの表示

「仮想化プラットフォーム」および「仮想サーバー」ページには「オープン・インシデント」ダッシュレットがあり、ここに「致命的」、「クリティカル」、「警告」のインシデントの数が表示されます。「仮想化プラットフォーム」ページには、グローバル・ゾーンおよび関連付けられているすべてのゾーン(非グローバルおよびカーネル)のオープン・インシデントが表示されます。「仮想サーバー」ページには、選択したゾーンのインシデントのみが表示されます。

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある、「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。「仮想化プラットフォーム」では、ドリルダウンしてオープン・インシデントのある仮想サーバーを表示する機能を提供します。

3. Solaris仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。

4. 「オープン・インシデント」ダッシュレットには、いくつのオープン・インシデントがグローバル・ゾーンと非グローバル・ゾーンに関連付けられているかを示す数が表示されます。
ゾーンにオープン・インシデントがある場合、数は「サマリー」ペインの「仮想プラットフォームのゲスト」のセクションにあるゾーン名の横に表示されます。

5. 「オープン・インシデント」ダッシュレットのターゲット名をクリックし、ゾーンの「仮想サーバー」ページに進みます。

6. 「インシデント・マネージャ」ページに進むには、サマリー・テキストをクリックします。
インシデント・マネージャは、インシデントの詳細とインシデントをもたらしたイベントを表示します。ドリルダウンしてイベントおよび通知の詳細を取得できます。「インシデント・マネージャ」ページでは、インシデントの認識、コメントの追加またはインシデントの管理ができます。

注意:
「仮想化プラットフォーム」には、グローバル・ゾーンおよびそのゾーンのすべてのインシデントが表示されます。デフォルトでは、「インシデント・マネージャ」ページにはグローバル・ゾーンのインシデントのみが表示されます。ターゲットおよびすべてのメンバーを表示するように、「インシデント・マネージャ」の設定を変更できます。

39.10 ゾーンのメトリックおよびインシデント通知の管理

次のタスクを実行して、モニタリングおよびインシデント通知を管理できます。

- ゾーンのメトリック収集エラーの表示

- ゾーンのモニタリング構成の編集

- ゾーンのモニタリングの一時停止の通知

- メンテナンスのためのゾーン・モニタリングの一時停止

- ゾーンのブラウンアウトまたはブラックアウトのモニタリングの終了

39.10.1 ゾーンのメトリック収集エラーの表示

メトリック収集エラーの原因は通常、インストールまたは構成の問題です。仮想サーバーまたは仮想化プラットフォームのエラーを表示できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「モニタリング」をクリックして、「メトリック収集エラー」をクリックします。

39.10.2 ゾーンのメトリックおよび収集設定の編集

「メトリック」タブには、モニター対象属性がすべて表示されます。デフォルトのビューは、しきい値が設定されるメトリックです。このようなタイプのモニター対象属性の場合、比較演算子、しきい値の制限、修正処理、収集スケジュールを変更できます。

ゾーンのメトリックおよび設定を編集するには、「仮想サーバー」に移動します。仮想化プラットフォームの設定を編集するには、「仮想化プラットフォーム」に移動します。パラメータはそれぞれ異なります。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」をクリックします。「モニタリング」をクリックして、「メトリックと収集設定」をクリックします。

4. しきい値の制限または収集スケジュールを変更します。しきい値のフィールドが空の場合、そのメトリックのアラートは無効になります。

5. 詳細設定の「編集」アイコンをクリックします。
「収集されたその他のアイテム」タブをクリックすると、しきい値以外のモニター対象属性が表示されます。このような属性の収集期間を変更したり、モニタリングを無効にできます。

39.10.3 ゾーンのモニタリング構成の編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「モニタリング構成」をクリックします。

39.10.4 ゾーンのモニタリングの一時停止の通知

ブラウンアウトを使用すると、ターゲットでの通知を一時的に抑止できます。エージェントはブラウンアウトの間ターゲットをモニタリングし続けます。実際のターゲット・ステータスとともにターゲットが現在ブラウンアウト中であること示す内容を表示できます。

仮想サーバーまたは仮想化プラットフォームにブラウンアウトを作成できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「制御」をクリックします。

4. 「ブラウンアウトの作成」をクリックします。

5. ブラウンアウト・イベントの名前を入力します。

6. メニューから理由を選択し、必要に応じてコメントを追加します。

7. オプションをクリックして、ジョブの実行方法とメンテナンス・ウィンドウを定義します。

8. 「発行」をクリックします。

39.10.5 メンテナンスのためのゾーン・モニタリングの一時停止

ブラックアウトを使用すると、メンテナンス操作を実行するために1つ以上のターゲットに対するモニタリングを一時停止できます。ターゲットをブラックアウトにするには、少なくともターゲットに対する「ブラックアウト・ターゲット」権限が必要です。ホストを選択すると、デフォルトでそのホスト上のターゲットはすべてブラックアウトに含まれます。同様に、メンバーを持つターゲットを選択すると、デフォルトでメンバーはすべてブラックアウトに含まれます。

仮想サーバーまたは仮想化プラットフォームにブラックアウトを作成できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「制御」をクリックします。

4. 「ブラックアウトの作成」をクリックします。

5. メニューから理由を選択します。

6. 必要に応じて、コメントを追加します。

7. 「発行」をクリックします。

39.10.6 ゾーンのブラウンアウトまたはブラックアウトのモニタリングの終了

仮想サーバーまたは仮想化プラットフォームのブラックアウトまたはブラウンアウトを終了できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「制御」をクリックします。

4. 「ブラックアウトの終了」または「ブラウンアウトの終了」をクリックします。

39.11 ゾーンの管理

次のタスクを実行して、ゾーンを管理できます。

- ゾーンのコンプライアンスの表示

- ゾーン構成における変更の識別

- ゾーン管理者アクセスの編集

- グループへのゾーンの追加

- ゾーン・プロパティの編集

39.11.1 ゾーンのコンプライアンスの表示

「コンプライアンス」ページでは、コンプライアンス・フレームワーク、標準およびゾーンのコンプライアンスを表示できます。

仮想サーバーまたは仮想化プラットフォームのコンプライアンスを表示できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「コンプライアンス」をクリックします。

4. オプションをクリックして、「結果」、「標準アソシエーション」または「リアルタイム監視」を表示します。

39.11.2 ゾーン構成における変更の識別

管理者がゾーン構成を変更する場合、いつ、構成が最後に変更されたかを知っておくと便利なことがあります。この情報は、「サマリー」ページの構成ダッシュレットに表示されます。ゾーン構成情報では、ゾーンにエージェントがインストールされている必要はありません。

仮想サーバーまたは仮想化プラットフォームの詳細情報を表示するには、次の手順を実行します。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「構成」をクリックします。

4. オプションをクリックして、「最新収集」、「比較およびドリフト管理」、「比較」、「検索」、「履歴」、「保存」、「保存済」または「トポロジ」を表示します。

39.11.3 ゾーン管理者アクセスの編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「管理者アクセス」をクリックします。

39.11.4 グループへのゾーンの追加

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「グループに追加」をクリックします。

39.11.5 ゾーン・プロパティの編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「プロパティ」をクリックします。

39.12 Oracle Solarisゾーンの追加リソース

詳細は、次を参照してください:

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- インシデント管理の使用

- ブラックアウトと通知ブラックアウトの使用方法

Oracle SolarisおよびOracle Solarisゾーンの詳細は、>http://docs.oracle.com/en/operating-systems/を参照してください。

40 Oracle VM Server for SPARCのモニタリング

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

- Oracle VM Server for SPARCの仮想化のスタート・ガイド

- UI中でのOracle VM Server for SPARC情報の場所

- Oracle VM Server for SPARCの処理

- Oracle VM Server for SPARCのターゲット・ナビゲーション

- サポートされているバージョン

- Oracle VM Server for SPARC仮想化プラットフォームすべての表示

- 仮想化プラットフォームの情報について

- 論理ドメイン内のゾーン

- 論理ドメイン情報について

- Oracle VM Server for SPARCの関連リソース

40.1 Oracle VM Server for SPARCの仮想化のスタート・ガイド

Oracle VM Server for SPARCテクノロジは、SPARCプラットフォーム上でのサーバー仮想化を可能にします。単一のSPARCマシンの上で同時に複数の仮想マシン・インスタンスを作成、管理できます。各仮想マシン(ゲスト)は、Oracle Solaris 10またはOracle Solaris 11オペレーティング・システムを個別に実行できます。

Oracle VM Server for SPARCテクノロジは、SPARCサーバーの仮想化です。このテクノロジは、SPARC Chip Multi Threading(CMT)システムにおける統合とリソース管理方法論の一部です。このテクノロジを使用して、論理的なグループにメモリー、CPUスレッド、デバイスなど、システムの様々なリソースを割り当て、複数の離散システムを作成できます。これらの離散システムには、独自のオペレーティング・システム、リソースおよび単一システムの範囲内でのアイデンティティがあります。Oracle VM Server for SPARC環境は、注意深く設計されたアーキテクチャにより、大量のリソース使用、良好なスケーリングおよびセキュリティと隔離の向上を達成する助けになります。

40.1.1 用語

Oracle Enterprise Managerでは、仮想化プラットフォームは、ゲストをホスティングできる仮想化テクノロジです(Oracle VM Server for SPARC制御ドメインなど)。仮想サーバーはゲストです(論理ドメインなど)。

40.1.2 論理ドメイン

Oracle VM Server for SPARCソフトウェアをインストールすると、制御ドメインと呼ばれるドメインが作成されます。この制御ドメインから、それぞれ独立したOSを実行する、論理ドメインと呼ばれる仮想マシンを作成します。論理ドメインは、リソース(CPUスレッド、メモリー、I/Oデバイスおよび独自のオペレーティング・システム)を持つ仮想マシンです。制御ドメインが論理ドメインを管理します。各論理ドメインは、他の論理ドメインから独立に、作成、削除、再構成、およびリブートできます。

40.2 UI中でのOracle VM Server for SPARC情報の場所

論理ドメイン(仮想プラットフォーム、ホストまたはサーバー)の子または親である任意のターゲットを選択すると、ターゲットのナビゲーション・ペインに論理ドメインが表示されます。

仮想化プラットフォームは、論理ドメインの仮想サーバーまたはゾーンが実行されているコンテナです。

「すべてのターゲット」ページでは、次のオプションを使用できます。

- 「システム・インフラストラクチャ仮想化プラットフォーム」をクリックして、仮想プラットフォームのリストを表示します。このリストで任意の仮想プラットフォームをクリックして、仮想プラットフォームのホームページを開くことができます。

- 「システム・インフラストラクチャ仮想サーバー」をクリックして、仮想サーバーのリストを表示します。このリスト内の仮想サーバーをクリックすると、仮想サーバーのホームページを開くことができます。

表40-1 UI中でのOracle VM Server for SPARC情報の場所

オブジェクト

場所

仮想化プラットフォーム

仮想プラットフォーム・ターゲットのホームページには、「すべてのターゲット」ページから、またはその親または子ターゲットのいずれかから、ターゲット・ナビゲーション・ペインを使用してアクセスできます。

ページの上部にある「すべてのターゲット」セレクタをクリックします。「検索の絞込み」セクションで、「システム・インフラストラクチャ仮想化プラットフォーム」を選択します。

または、「すべてのターゲット」セレクタで、仮想プラットフォームの親または子であるターゲットを選択します。ターゲットは、ホスト、サーバー、またはこの仮想プラットフォームで実行する論理ドメイン・ターゲットです。

ターゲット・ナビゲーション・ペインは、親または子のホームページの左上隅にあります。ターゲット・ナビゲーション・ペインをクリックして展開し、ナビゲーション・ペイン内の仮想プラットフォームを確認します。

仮想サーバー

論理ドメインの仮想サーバー・ターゲットのホームページには、ゾーンの「仮想化プラットフォーム」ページまたは「仮想サーバー」ページからアクセスできます。

ページの上部にある「すべてのターゲット」セレクタをクリックします。「検索の絞込み」セクションで、「システム・インフラストラクチャ仮想サーバー」を選択します。

「仮想化プラットフォーム」ページを開いている場合は、ゾーンをクリックして、そのゾーンの仮想サーバー・ページに移動します。

40.3 Oracle VM Server for SPARCの処理

ハードウェアのILOMを検出して、制御ドメイン・オペレーティング・システムにEMエージェントをデプロイすることにより、Oracle VM Server for SPARCを検出および昇格できます。さらにOracle VM Server for SPARCとそのゲストをモニターできます。制御ドメインまたはそのゲストにOracle Solarisゾーンがインストールされている場合は、ターゲット・ナビゲーション・ツリーに表示され、EMエージェントがゲスト・ドメインにインストールされている場合はこれらのゾーンをモニタリングできます。

実行可能な操作は次のとおりです。

- ドメインの構成およびステータスの表示。

- リソース使用率およびリソースの上位コンシューマの表示。

- インシデントおよびパフォーマンス・メトリックを使用した問題の診断。

40.4 Oracle VM Server for SPARCのターゲット・ナビゲーション

ターゲット・ナビゲーション・ツリーは、Oracle VM Server for SPARC仮想プラットフォーム(OVM SPARC仮想プラットフォーム)にあるターゲット間の移動に役立ちます。プライマリ・ドメインのエージェント・デプロイ全体で、すべてのリソースが検出およびモニタリングされている場合は、サーバーから移動できます。

トップ・レベル、つまりノードは物理サーバーであり、第2ノードは、プライマリ・ドメインおよび他のすべての論理ドメインをホストしているOVM SPARC仮想プラットフォームとなります。ノードを展開してターゲット階層をドリルダウンするか、または特定のターゲットをクリックして、そのターゲットのランディング・ページを開きます。

図40-1は、OVM SPARC仮想プラットフォームのターゲット・ナビゲーション・ツリーの例です。第1ノードは物理サーバー(slci04-node4-ilom)で、Oracle VM Server for SPARCハイパーバイザ(slci04dbadm07 (OVM SPARC仮想プラットフォーム))を実行しています。ハイパーバイザは第2ノードにあります。第3ノードには、4つの論理ドメイン・ゲスト(プライマリ、ssccn4-app1、ssccn4-app2およびssccn4-app3)が表示されています。プライマリ・ドメインはSolarisゾーン仮想プラットフォーム(slci04dbadm07 (Solarisゾーン仮想プラットフォーム))でもあり、オペレーティング・システム(slci04dbadm07ホスト)を実行している1つのグローバル・ゾーンがあります。4番目の論理ドメイン(ssccn4-app3)は展開されています。論理ドメインにエージェントがデプロイされていた場合は、グローバル・ゾーンおよびホストslci04dbadm08を実行しているゾーン仮想プラットフォームとしてドメインが昇格されました。

図40-1 Oracle VM Server for SPARCのターゲット・ナビゲーション

40.5 サポートされているバージョン

Oracle VM Server for SPARC制御ドメイン:

- Oracle Solaris 11.1以降

- Oracle VM Server for SPARC 3.1以降

Oracle VM Server for SPARCゲスト・ドメイン・オペレーティング・システム:

- Oracle Solaris 10 1/13

- Oracle Solaris 11.1以降

40.6 Oracle VM Server for SPARC仮想化プラットフォームすべての表示

ターゲット・リストには、Oracle VM Server for SPARC仮想化プラットフォームを含むすべての仮想化プラットフォームが表示されます。

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ仮想化プラットフォーム」を選択します。
ターゲット仮想化プラットフォームのリストが表示されます。

40.7 仮想化プラットフォームの情報について

仮想化プラットフォームを選択して、その仮想化プラットフォームとそのゲストに関する情報を表示できます。

UIの一番上のセクションには、選択した仮想化プラットフォームの基本情報が表示されます。スクロール・アイコンをクリックすると、左右に移動できます。

- プラットフォーム: このセクションには、プラットフォームのタイプ、バージョンおよび稼働時間が表示されます。

- オープン・インシデント: このセクションには、システムにおける、致命的、重要および警告の各インシデントの数が表示されます。カテゴリをクリックすると、そのカテゴリのインシデントの詳細なリストが表示されます。

注意:
「仮想化プラットフォーム」ページのオープン・インシデントの数は、プラットフォーム(制御ドメインおよびすべての論理ドメイン)のすべてのオープン・インシデントを示しています。デフォルトでは、制御ドメインの「インシデント・マネージャ」ページに、関連付けられている論理ドメインではなく、制御ドメインのオープン・インシデントが表示されます。「インシデント・マネージャ」の表示を変更して、制御ドメインおよび論理ドメインのインシデントを表示できます。インシデント・マネージャで、「検索」を選択して、「メンバーを含む」検索基準に「ターゲットとすべてのメンバー」を選択します。

- CPUとメモリー: このセクションには、現在のCPUとメモリーを最大値に対する割合として示す円ゲージが表示されます。この情報は、ハードウェアのILOMが検出された場合のみ表示されます。

- 稼働中および実行中のゲスト: このセクションには、構成済のゲスト数のうち、実行ゲストの数が表示されます。

- 仮想CPU、メモリーおよびコア: このセクションには、割当て済かつ利用可能な仮想CPUの現在の数、割当て済かつ利用可能なメモリーの容量および割当て済かつ利用可能なコアの数を示す円グラフが表示されます。

- ゲスト当たりの合計CPU使用量とその配分: このセクションには、合計CPU使用量と、CPU範囲当たりのゲスト数のグラフが表示されます。

- ゲスト当たりの合計メモリー使用量とその配分: このセクションには、仮想化プラットフォームの合計メモリー使用量と、メモリー範囲当たりのゲスト数のグラフが表示されます。

- ゲスト当たりの合計電力消費量とその配分: このセクションには、合計電力消費量と、電力範囲当たりのゲスト数のグラフが表示されます。

- 最後の構成変更とインシデント: このセクションには、システム上での最後の構成変更の日付と、最後にインシデントが報告された日付が表示されます。

40.7.1 仮想化プラットフォームの基本情報の表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ仮想化プラットフォーム」を選択します。
ターゲット仮想化プラットフォームのリストが表示されます。

3. 仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。ページ上部にダッシュレットが表示され、サマリー情報が提供されます。

40.7.2 仮想化プラットフォームのゲスト・サマリーについて

ゲスト・サマリー・セクションには、仮想化プラットフォームが管理するゲストの詳細が表示されます。「サマリー」タブを選択すると、この情報が表示されます。

最上部のセクションには、各ゲスト用に構成された仮想CPUおよびメモリーを使用可能な総量に対する割当てとして表示する円グラフが表示されます。

一番下のセクションには、ゲストの表またはリストが表示されます。ゲスト表示には、リストまたは表を選択できます。リスト・モードでは、名前、タイプ、インシデント、メモリーまたはvCPUでゲストをソートするために左上部のソート・オプションを使用します。

デフォルトでは、ドメインはインシデント数の降順で表示されます。

各ゲストについて、次の情報が表示されます。

- ターゲット・ステータス・アイコン: このアイコンは、ゲストがモニターされているかどうかを示します。

- タイプ・アイコン: これらのアイコンは、ゲストのタイプを識別します。制御ドメイン、ゲスト・ドメイン、ルート・ドメイン、IOドメインおよびサービス・ドメインが、別々のアイコンによって識別されます。

- 名前: ゲストの名前。

- コア: ゲストに割り当てられたコアの数を表示します。

- メモリー: ゲストが使用できるメモリーを表示します。

- 操作のステータス・アイコン: このアイコンは、ゲストがアンバインドされているか、起動しているか、停止しているかを示します。

- インシデント: ゲストにオープンな致命的、クリティカルおよび警告のインシデントの数を表示します。

- CPU情報: ゲストに割り当てられたCPUコアおよびvCPUの数を表示します。

- CPU使用率グラフ: 現在のCPU使用率と過去5時間のCPU使用率を表示します。この情報は、ゲストが開始済の場合にリスト・モードでのみ表示されます。

ゲスト表の一番上にある検索フィールドを使用して、特定のゲストを検索できます。

40.7.3 仮想化プラットフォームのゲスト・サマリーの表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ仮想化プラットフォーム」を選択します。
ターゲット仮想化プラットフォームのリストが表示されます。

3. 仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。

4. 「サマリー」タブをクリックします。

40.7.4 仮想化プラットフォームのサービスについて

仮想化プラットフォームで使用できるI/Oおよびネットワーク・サービスの詳細と、仮想化プラットフォームのトポロジを表示でき、提供されているサービスや使用されているサービスを示します。「サービス」タブを選択すると、この情報が表示されます。

一番上のセクションに、I/Oおよびネットワーク・サービスの表が表示されます。各リソースについて、次の情報が表示されます。

- 名前

- Type

- 操作ステータス・アイコン

- リソースを使用しているゲストの数

表の一番上にある検索フィールドを使用して、特定のサービスを検索できます。

各リソースで、「詳細」をクリックして追加情報を表示することができます。

一番下のセクションにはトポロジ図が表示されます。そこには、各ゲストと、各ゲストが提供または消費するネットワークのリソースが表示されます。ゲストのみのオプションを選択して、ゲストのみを表示できます。

ゲストおよびサービス表示では、ゲストの上にカーソルを移動してそのゲストが使用しているネットワーク・サービスをハイライト表示したり、ネットワーク・リソースの上にカーソルを移動してそれを使用しているゲストをハイライト表示できます。

ゲストのみ表示では、ゲストの上にカーソルを移動して他のゲストと共有しているネットワーク・リソースを表示できます。

コントロール・パネル・ボタンをクリックして、ズーム・コントロールにアクセスします。これらのコントロールを使用すると、ズーム・イン、ズーム・アウトまたは現在のウィンドウに合せてズームができます。

40.7.5 仮想化プラットフォームのサービスの表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ仮想化プラットフォーム」を選択します。
ターゲット仮想化プラットフォームのリストが表示されます。

3. 仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。

4. 「サービス」タブをクリックします。

40.7.6 仮想化プラットフォームのvCPUおよびコア割当てについて

vCPUおよびコア割当てに関する詳細を表示できます。コア配分タブを選択すると、この情報が表示されます。

このセクションには、どのCPUとコアがどのゲストに割り当てられ、どれが割り当てられていないかを示す円グラフが表示されます。外側の層のゲストをクリックして、そのゲストのリソース使用に関する詳細な情報を表示できます。次のフィールドが表示されます。

- 名前: ゲストの理解しやすい名前。

- タイプ・アイコン: これらのアイコンは、ゲストのタイプを識別します。制御ドメイン、ゲスト・ドメイン、ルート・ドメイン、IOドメインおよびサービス・ドメインが、別々のアイコンによって識別されます。

- 操作ステータス・アイコン

- vCPUの数: ゲストに割り当てられている仮想CPUの数。

- CPU使用状況: 過去7日間のゲストのCPU使用状況が表示されます。

40.7.7 仮想化プラットフォームのvCPUおよびコア割当ての表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ仮想化プラットフォーム」を選択します。
ターゲット仮想化プラットフォームのリストが表示されます。

3. 仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。

4. 「コアの分散」タブをクリックします。

40.7.8 仮想化プラットフォームのメトリックについて

選択した仮想化プラットフォームのメトリックの完全なリストを表示できます。

40.7.9 プラットフォーム・メトリックの表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある「システム・インフラストラクチャ仮想化プラットフォーム」を選択します。
ターゲット仮想化プラットフォームのリストが表示されます。

3. 仮想化プラットフォームの「サマリー」ページを開くには、ターゲット名をクリックします。

4. ページの左上隅にある「仮想化プラットフォーム」をクリックします。「モニタリング」をクリックして、「すべてのメトリック」をクリックします。

5. メトリックをクリックすると、詳細、収集スケジュール、アップロード間隔およびその他の詳細が表示されます。

40.8 論理ドメイン内のゾーン

論理ドメインのオペレーティング・システムにEMエージェントをインストールしている場合は、論理ドメイン(制御ドメインを含む)のオペレーティング・システムにインストールされているゾーンを検出およびモニタリングできます。

40.8.1 論理ドメイン内のゾーンの表示

論理ドメインにインストールされているゾーンのゾーン表示は、ターゲット・ナビゲーション・ペインの論理ドメインの下に表示されます。ゾーン表示を選択することも、個々のゾーンを選択して詳細な情報を表示することもできます。

40.9 論理ドメイン情報について

Oracle Enterprise Managerでは、モニタリング対象の論理ドメインに関する詳細情報(CPUとメモリーの使用率、論理ドメインのステータスおよびインシデントなど)を収集します。論理ドメインを選択することにより、これらのメトリックを表示できます。

UIの一番上のセクションには、選択した論理ドメインの基本情報が表示されます。スクロール・アイコンをクリックすると、左右に移動できます。

次のセクションが表示されます。

- 論理ドメイン: このセクションには、論理ドメイン名、そのタイプおよびその稼働時間が表示されます。

- オープン・インシデント: このセクションには、システムにおける、致命的、重要および警告の各インシデントの数が表示されます。カテゴリをクリックすると、そのカテゴリのインシデントの詳細なリストが表示されます。

- CPUおよび電力: このセクションには、現在のCPUとメモリーの使用状況を最大値のパーセンテージとして、および現在の電力使用量をワットとして示す円ゲージが表示されます。

- ゲストOS情報: このセクションには、ゲストのオペレーティング・システムについての情報(検出された場合)が表示されます。この情報には、ホスト名、IPアドレスおよび稼働時間が含まれます。

- ゲストの構成: このセクションには、ゲストのUUID、ゲストに自動ブートが設定されているかどうかを示すアイコンおよびコンソール・ポートなどのゲスト構成情報が表示されます。

- 最後の構成変更とインシデント: このセクションには、システム上での最後の構成変更の日付と、最後にインシデントが報告された日付が表示されます。

40.9.1 論理ドメインの基本情報の表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある、「システム・インフラストラクチャ仮想サーバー」を選択します。
ターゲット仮想サーバーのリストが表示されます。

3. 仮想サーバーの「サマリー」ページを開くには、ターゲット名をクリックします。

40.9.2 仮想サーバーのサマリー情報について

仮想サーバー・サマリーのタブには、ステータス、仮想CPUおよびメモリー使用状況などの、仮想サーバーに関する基本情報が表示されます。

次のフィールドが表示されます。

- vCPUまたはコアの数

- 電力量

- メモリー量

- 自動ブート構成

- UUID

- 過去7日間、24時間、5時間のCPU使用率履歴のグラフ

- 過去7日間、24時間、5時間の電力使用量(ワット)履歴のグラフ

40.9.3 仮想サーバーのサマリー情報の表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある、「システム・インフラストラクチャ仮想サーバー」を選択します。
ターゲット仮想サーバーのリストが表示されます。

3. 仮想サーバーの「サマリー」ページを開くには、ターゲット名をクリックします。

4. 「サマリー」タブをクリックします。

40.9.4 仮想サーバーの電力およびCPU使用率チャートについて

仮想サーバー使用状況タブには、ゲストのCPUと電力使用状況のチャートが表示されます。次のアイコンの1つを選択すると、関連のチャートが表示されます。

- CPU (%): 仮想サーバーのCPU使用状況のチャートが、全体のパーセンテージとして表示されます。

- 電力(ワット): CPUおよびメモリーによって消費される電力(ワット)のグラフが表示されます。

グラフごとに、右上にあるスライダを使用して表示する日数を選択できます。

40.9.5 仮想サーバーの電力およびCPU使用率チャートの表示

1. 「ターゲット」リストから、「すべてのターゲット」を選択します。

2. 「サーバー、ストレージおよびネットワーク」という見出しの下にある、「システム・インフラストラクチャ仮想サーバー」を選択します。
ターゲット仮想サーバーのリストが表示されます。

3. 仮想サーバーの「サマリー」ページを開くには、ターゲット名をクリックします。

4. 「仮想サーバーの使用状況」タブをクリックします。

40.10 メトリックおよびインシデント通知の管理

次のタスクを実行して、モニタリングおよびインシデント通知を管理できます。

- メトリック収集エラーの表示

- メトリックおよび収集設定の編集

- モニタリング構成の編集

- モニタリングの一時停止の通知

- メンテナンスのためのモニタリングの一時停止

- ブラウンアウトまたはブラックアウトのモニタリングの終了

40.10.1 メトリック収集エラーの表示

メトリック収集エラーの原因は通常、インストールまたは構成の問題です。仮想サーバーまたは仮想化プラットフォームのエラーを表示できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「モニタリング」をクリックして、「メトリック収集エラー」をクリックします。

40.10.2 メトリックおよび収集設定の編集

「メトリック」タブには、モニター対象属性がすべて表示されます。デフォルトのビューは、しきい値が設定されるメトリックです。このようなタイプのモニター対象属性の場合、比較演算子、しきい値の制限、修正処理、収集スケジュールを変更できます。

仮想サーバーのメトリックおよび設定を編集するには、「仮想サーバー」に移動します。仮想化プラットフォームの設定を編集するには、「仮想化プラットフォーム」に移動します。パラメータはそれぞれ異なります。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「モニタリング」をクリックして、「メトリックと収集設定」をクリックします。

4. しきい値の制限または収集スケジュールを変更します。しきい値のフィールドが空の場合、そのメトリックのアラートは無効になります。

5. 詳細設定の「編集」アイコンをクリックします。
「収集されたその他のアイテム」タブをクリックすると、しきい値以外のモニター対象属性が表示されます。このような属性の収集期間を変更したり、モニタリングを無効にできます。

6. 「OK」をクリックして、変更を保存します。

40.10.3 モニタリング構成の編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「モニタリング構成」をクリックします。

40.10.4 モニタリングの一時停止の通知

ブラウンアウトを使用すると、ターゲットでの通知を一時的に抑止できます。エージェントはブラウンアウトの間ターゲットをモニタリングし続けます。実際のターゲット・ステータスとともにターゲットが現在ブラウンアウト中であること示す内容を表示できます。

仮想サーバーまたは仮想化プラットフォームにブラウンアウトを作成できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「制御」をクリックします。

4. 「ブラウンアウトの作成」をクリックします。

5. ブラウンアウト・イベントの名前を入力します。

6. メニューから理由を選択し、必要に応じてコメントを追加します。

7. オプションをクリックして、ジョブの実行方法とメンテナンス・ウィンドウを定義します。

8. 「発行」をクリックします。

40.10.5 メンテナンスのためのモニタリングの一時停止

ブラックアウトを使用すると、メンテナンス操作を実行するために1つ以上のターゲットに対するモニタリングを一時停止できます。ターゲットをブラックアウトにするには、少なくともターゲットに対する「ブラックアウト・ターゲット」権限が必要です。ホストを選択すると、デフォルトでそのホスト上のターゲットはすべてブラックアウトに含まれます。同様に、メンバーを持つターゲットを選択すると、デフォルトでメンバーはすべてブラックアウトに含まれます。

仮想サーバーまたは仮想化プラットフォームにブラックアウトを作成できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「制御」をクリックします。

4. 「ブラックアウトの作成」をクリックします。

5. メニューから理由を選択します。

6. 必要に応じて、コメントを追加します。

7. 「発行」をクリックします。

40.10.6 ブラウンアウトまたはブラックアウトのモニタリングの終了

仮想サーバーまたは仮想化プラットフォームのブラックアウトまたはブラウンアウトを終了できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「制御」をクリックします。

4. 「ブラックアウトの終了」または「ブラウンアウトの終了」をクリックします。

40.11 Oracle VM Server for SPARCの管理

次のタスクを実行して、Oracle VM Server for SPARCを管理できます。

- コンプライアンスの表示

- 仮想サーバー構成における変更の識別

- 仮想サーバー管理者アクセスの編集

- 仮想サーバーのグループへの追加

- 仮想サーバー・プロパティの編集

40.11.1 コンプライアンスの表示

「コンプライアンス」ページでは、コンプライアンス・フレームワーク、標準および仮想サーバーまたは仮想化プラットフォームのコンプライアンスを表示できます。

仮想サーバーまたは仮想化プラットフォームのコンプライアンスを表示できます。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「コンプライアンス」をクリックします。

4. オプションをクリックして、「結果」、「標準アソシエーション」または「リアルタイム監視」を表示します。

40.11.2 仮想サーバー構成における変更の識別

管理者が仮想サーバーまたは仮想化プラットフォームの構成を変更する場合、いつ、構成が最後に変更されたかを知っておくと便利なことがあります。この情報は、「サマリー」ページの構成ダッシュレットに表示されます。

仮想サーバーまたは仮想化プラットフォームの詳細情報を表示するには、次の手順を実行します。

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「構成」をクリックします。

4. オプションをクリックして、「最新収集」、「比較およびドリフト管理」、「比較」、「検索」、「履歴」、「保存」、「保存済」または「トポロジ」を表示します。

40.11.3 仮想サーバー管理者アクセスの編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「管理者アクセス」をクリックします。

40.11.4 仮想サーバーのグループへの追加

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「グループに追加」をクリックします。

40.11.5 仮想サーバー・プロパティの編集

1. 「すべてのターゲット」ページから「システム・インフラストラクチャ仮想サーバー」または「システム・インフラストラクチャ仮想化プラットフォーム」をクリックします。

2. ターゲット名をクリックしてホームページを開きます。

3. ページの左上隅にある「仮想サーバー」または「仮想化プラットフォーム」をクリックします。「ターゲット設定」をクリックします。

4. 「プロパティ」をクリックします。

40.12 Oracle VM Server for SPARCの関連リソース

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

- ホスト・ターゲットと非ホスト・ターゲットの検出および追加

- システム・インフラストラクチャ・ターゲットの検出、昇格および追加

- インシデント管理の使用

第VI部

レポートの生成

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

- 情報パブリッシャの使用

- 使用状況トラッキング・レポートの作成

41 情報パブリッシャの使用

Enterprise Managerのレポート・フレームワークである情報パブリッシャを使用すると、エンタープライズ全体で対象読者が管理対象の環境に関する情報にアクセスできるようになります。戦略的には、レポートは、エンタープライズの監視情報のビューをビジネス・インテリジェンス目的で提示するために使用されますが、管理対象ターゲットのアクティビティ、リソース使用率および構成を示すことで管理目的でも役立ちます。IT管理者は、レポートを使用して、一連の管理対象システムの可用性を示すことができます。エグゼクティブは、一定期間におけるアプリケーション(エンタープライズの電子メールなど)の可用性に関するレポートを表示できます。

注意:
情報パブリッシャ(IP)レポート・フレームワークはEnterprise Manager 13cでサポートされていますが、このフレームワークを使用した新規レポート開発は、Enterprise Manager 13cでは非推奨になりました。

このレポート・フレームワークにより、カスタマイズされたレポートを作成および公開でき、HTMLベースの直感的なレポートをWeb経由で公開、格納、または選択した受信者に電子メールで送信できます。情報パブリッシャには、事前定義済レポートの包括的なライブラリが用意されており、これを使用することで、追加の設定や構成を行うことなく、レポートを即時に生成できます。

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

- 情報パブリッシャについて

- 即時利用可能なレポート定義

- カスタム・レポート

- レポートのスケジュール

- レポートの共有

41.1 情報パブリッシャについて

情報パブリッシャは、強力なレポートおよび公開機能を備えています。情報パブリッシャのレポートには、管理リポジトリに格納されている意思決定用の重要な情報に対する直感的なインタフェースが用意されています。一方で、Enterprise Managerのセキュリティおよびアクセス制御を利用して、この情報のセキュリティが確保されます。

情報パブリッシャの直感的なユーザー・インタフェースを使用すると、わずかな作業でレポートを作成および公開できます。情報パブリッシャを使用する主な利点は次のとおりです。

- 豊富なコンテンツと適切な形式を持つHTMLレポートを管理リポジトリのデータに基づいて作成するフレームワークが用意されています。

- 即時利用可能なレポートを使用して、システムの構成や設定を行わずに、レポートの生成を即座に開始できます。

- レポートの自動生成をスケジュールし、スケジュールしたコピーの格納および対象読者への電子メールでの送信が可能です。

- Enterprise Manager管理者は、レポートをビジネス・コミュニティ全体(エグゼクティブ、顧客および他のEnterprise Manager管理者)と共有できます。

情報パブリッシャには、社内の中央情報ソースとなる、機能豊富なフレームワークが用意されています。

41.2 即時利用可能なレポート定義

情報パブリッシャの中核は、レポート定義です。レポート定義は、レポートの内容、ユーザー・アクセス、レポート生成のスケジュールなどのレポートのプロパティを定義することで、レポート・フレームワークに対して特定のレポートを生成する方法を指示します。

情報パブリッシャには、事前定義済レポート定義の包括的なライブラリが用意されており、追加の構成や設定を行うことなく、重要な業務やビジネス情報を提示する完全な形式のHTMLレポートを生成できます。

このHTMLレポートの生成では、次の3つの簡単な手順が実行されました。

手順1: レポート定義リストで「可用性履歴(グループ)」をクリックします。

手順2: レポートを実行するグループを選択します。

手順3: 「続行」をクリックし、完全な形式のレポートを生成します。

提供されるレポート定義は、機能カテゴリ別に体系化されており、各カテゴリの主な領域をカバーしています。

情報パブリッシャ・ホームページにアクセスするには、「エンタープライズ」メニューから、「レポート」、情報パブリッシャの順に選択します。

41.3 カスタム・レポート

情報パブリッシャに付属する事前定義済のレポート定義は一般的なレポート・ニーズのほとんどに対応していますが、特別なレポートを作成することが必要な場合があります。情報に対する要件を事前定義済レポートがほぼ満たしていても、完全には満たしていない場合は、情報パブリッシャの類似作成機能を使用して、既存のいずれかのレポート定義に基づいて新しいレポート定義を作成できます。

41.3.1 カスタム・レポートの作成

カスタム・レポートを作成するには、次の手順を実行します。

1. 既存のレポート定義を変更するか、最初から作成するかを選択します。既存のレポート定義がニーズをほぼ満たしている場合は、類似作成機能を使用して簡単にカスタマイズできます。

2. 名前、カテゴリおよびサブカテゴリを指定します。Cloud Controlには、即時利用可能なレポートに使用されているデフォルトのカテゴリとサブカテゴリが用意されています。ただし、カスタム・レポートを任意の方法でも分類できます。

3. 期間パラメータやターゲット・パラメータを指定します。レポートの表示中に、これらのパラメータの入力を求められます。

4. レポート要素を追加します。レポート要素とは、事前定義済のコンテンツのビルディング・ブロックであり、これを使用することで、様々な情報をレポートに追加できます。レポート要素の例としては、グラフ、表、イメージなどがあります。

5. レポートのレイアウトをカスタマイズします。レポート要素をアセンブルした後は、レポートのレイアウトをカスタマイズできます。

41.3.2 レポート・パラメータ

レポート・パラメータを宣言することで、レポートにどのデータが表示されるかをユーザーが制御できるようになります。パラメータには、ターゲットと期間の2種類があります。

例: 問題の診断に使用されるレポート(メモリー使用率レポートなど)を定義すると、対象のターゲットの情報の表示が可能になります。

期間パラメータを指定することで、対象の期間の履歴データの分析が可能になります。

履歴データの分析

情報パブリッシャでは、次のように、様々な期間のレポートを表示できます。

- 過去24時間/7日間/31日間

- 直前のX日/週/月/年(カレンダ単位)

- 今週/今月/今年(現時点では今週)

- 任意のカスタム日付範囲。

41.3.3 レポート要素

レポート要素は、レポート定義構築のためのブロックです。一般に、レポート要素は、パラメータを受け取り、表示可能な情報を生成します。たとえば、「SQLからのグラフ」要素は、データを管理リポジトリから抽出するためのSQL問合せと、データを円、棒または線のどの形式のグラフで表示するかを指定するパラメータを受け取ります。レポート要素により、情報パブリッシャのユーザー・インタフェースを使用して、カスタム・レポート定義をアセンブルできます。

情報パブリッシャには、様々なレポート要素が用意されています。汎用レポート要素では、任意の情報をグラフ、表またはイメージの形式で表示できます。たとえば、会社のロゴや、会社のWebサイトへのリンクを表示できます。監視要素では、管理対象ターゲットの可用性やアラートなどの監視情報を表示できます。サービス・レベル・レポート要素では、可用性、パフォーマンス、使用状況および達成されたサービス・レベルが表示され、サービス・レベル合意に準拠しているかの追跡、および達成されたサービス・レベルの顧客およびエグゼクティブとの共有が可能です。

41.4 レポートのスケジュール

Enterprise Managerを使用すると、レポートの対話方式での表示や、柔軟なスケジュールによるレポート生成のスケジュールが可能です。たとえば、環境内のすべてのサーバーに関するインベントリ・スナップショット・レポートを毎日午前0時に生成できます。

41.4.1 柔軟なスケジュール

Cloud Controlには、次のスケジュール・オプションが用意されています。

- 即時、または将来のある時点における1回かぎりのレポート生成

- 定期的なレポート生成

- 頻度: 任意の分数/時間数/日数/週数/月数/年数

- コピーの無期限な生成または将来の特定の日付までの生成が可能です。

41.4.2 レポートのコピーの格納およびパージ

Enterprise Managerを使用して、スケジュールした任意の枚数のコピーを将来の参照用に格納できます。格納した各コピーを手動での削除、または格納したコピー枚数または保存時間に基づいた自動パージの設定が可能です。たとえば、保存時間が90日を過ぎたすべてのレポートをパージするよう設定できます。

41.4.3 レポートの電子メール送信

電子メールで、任意の数の受信者にスケジュールしたレポートを送信できます。電子メールの返信先アドレスと件名を指定できます。

41.5 レポートの共有

情報パブリッシャを使用すると、ユーザー・コミュニティ全体で簡単にレポートを共有できるようになります。Enterprise Manager管理者は、他の管理者やロールとレポートを共有できます。ただし、顧客やエグゼクティブなどのEnterprise Managerの管理者以外のユーザーとのレポート共有が必要になる場合もあります。このようなユーザーとの情報共有を容易にするため、Enterprise Managerは、ユーザーの認証を必要としない独立したレポート用Webサイトを提供します。

注意:
機密情報が損われることがないように、Enterprise Managerのレポート用Webサイトにレポートを公開できるのは、特別なシステム権限を持つEnterprise Manager管理者のみに制限されています。

情報パブリッシャでは、Enterprise Managerのロールと特権に従って、Enterprise Manager管理者のみが参照可能な情報に関するレポートを作成できます。レポートを共有する場合、管理者はユーザーに対し、所有者の権限付きでレポートの表示を許可できます。たとえば、システム管理者は、サーバーを使用してホストのパフォーマンス情報はDBAと共有し、ホスト・ターゲットに対する権限はDBAに付与しないようにできます。この場合、ホストのパフォーマンス・レポートを作成でき、DBAは権限を使用してそれを表示できます。これによって、ホストのホームページへのアクセス権を付与することなく、参照を許可する情報のみを参照できるようになります。

42 使用状況トラッキング・レポートの作成

使用状況トラッキング・レポートは、組織で使用されていると識別されるデータベース機能の概要を提供します。

重要:
使用状況トラッキング・レポートは、情報提供のみを目的としており、ライセンスの付与または要件を表しているものではありません。ライセンス要件については、次のURLで提供されているLicense Management ServicesのWebサイトを参照してください。
http://www.oracle.com/us/corporate/license-management-services/index.html

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

- 使用状況トラッキング・レポート

- データベース使用状況トラッキングのためのデータ収集

- データベース使用状況トラッキング・レポートの生成

- データベース使用状況トラッキング・サマリー・レポート

- Fusion Middleware使用状況トラッキング・サマリー・レポートの生成

42.1 使用状況トラッキング・レポート

使用状況トラッキング・レポートは、Oracle Business Intelligence Publisher (BI Publisher)と組み合せて利用できる、オラクル社が提供するレポートです。BI Publisherは、対話型レポートおよびすべての種類の高度に書式化されたドキュメントを作成、管理および配布するための単一のWebベースのプラットフォームを提供する主要なレポート・システムです。この章で詳細に説明する手順は、BI PublisherがすでにEnterprise Managerに統合されていることを前提としています。BI Publisherを統合する手順の詳細は、『Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』の「BI PublisherとEnterprise Managerとの統合」を参照してください。

使用状況トラッキング・レポートには、次に示す2つの種類があります。

- データベース使用状況トラッキング・サマリー・レポートは、データベースのバージョン、エディション、ライセンス可能なオプションおよびEnterprise Management Packの使用状況に関する高いレベルのサマリーを提供します。
このレポートは、オンラインでの実行および表示が可能です。出力レポートは、PDF、RTFおよびExcelの形式でエクスポートできます。

- データベース使用状況トラッキング・レポートは、エクスポート可能な形式(csv)で前述の使用状況データを提供します。エクスポートしたデータをOracle License Management Servicesに送信して、ライセンス要件を確認するためにさらなる分析を行うことができます。License Management Services (http://www.oracle.com/us/corporate/license-management-services/index.html)にアクセスして、契約を開始してください。
このレポートはスケジュール実行のみが可能で、オンラインでは実行できません。レポートがスケジュール実行されるたびに、各データベース・インスタンスに対して1つのファイルが生成されます。出力ファイルの形式は、カンマ区切り値(CSV)です。

使用状況トラッキング・レポートを作成するには、概して次の手順を実行します。

1. データベース使用状況トラッキング資格証明を設定します。(データベース使用状況トラッキング・サマリー・レポートとデータベース使用状況トラッキング・レポートの両方で必要です。)

2. 監視テンプレートを使用して、メトリック収集を有効化します。(データベース使用状況トラッキング・サマリー・レポートとデータベース使用状況トラッキング・レポートの両方で必要です。)

3. BI Publisherで、レポートが生成されるFTPサーバーを構成します。(データベース使用状況トラッキング・サマリー・レポートでは必要ありません。)

4. 使用状況トラッキング・レポートを生成します。

42.2 データベース使用状況トラッキングのためのデータ収集

データベース使用状況トラッキング・レポートを作成する前に、対応するメトリック収集を構成し、有効化しておく必要があります。この手順は次のとおりです。

1. データベース使用状況トラッキング資格証明の設定

2. メトリック収集の有効化または無効化(収集が完了した場合)。プリファレンスおよび使用可能なライセンスに応じて、次のように実行します。

- Diagnostics Packでライセンスされているデータベース・ターゲットに対して、OEMコンソールから監視テンプレートを使用

- ライセンスに関係なく、EM Command Line Interface (EM CLI)をデータベース・ターゲットに使用

メトリック収集には次の2つのタイプがあります。

- 週次メトリック - 1週間に1回収集されます: lms_wk_ci and lms_wk_ci_cdb

- 毎時メトリック - 毎時間収集されます: lms_hr_ci and lms_hr_ci_cdb
この収集はセッション情報が必要なときにのみ有効化する必要があり、生成できるデータ量のため、慎重に監視する必要があります。

これらの2つのタイプのそれぞれについて、2つの異なるメトリック収集があります。

- 従来の標準データベース・ターゲットの場合: lms_wk_ci and lms_hr_ci

- コンテナ・データベース(CDB)・ターゲットの場合: lms_wk_ci_cdb and lms_hr_ci_cdb。CDB$ROOTコンテナおよびすべてのプラガブル・データベース(PDB)からもデータを収集します。

42.2.1 データベース使用状況トラッキング資格証明の設定

1. Enterprise Managerにログインします。「設定」メニューから、「セキュリティ」、「監視資格証明」の順に選択します。

2. リストから必要なデータベース・ターゲットを選択し、「監視資格証明の管理」をクリックします。ターゲットの「資格証明」ページが表示されます。

3. リストからターゲット名を選択し、「資格証明の設定」をクリックします。「監視資格証明の入力」ダイアログが表示されます。

4. 必要な監視資格証明を入力し、「保存」をクリックします。

42.2.2 監視テンプレートを使用したメトリック収集の有効化/無効化

この方法は監視テンプレート(Diagnostics Packの機能)を使用するため、Diagnostics Packでライセンスされたデータベース・ターゲットでのみ使用できます。

注意:
データベース・ターゲットに対する監視テンプレートの使用は、Oracle Diagnostics Packのライセンスが必要です。また、追加のライセンスを必要としないメトリック収集を有効化/無効化するために、Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用できます。

週次メトリック収集の有効化:

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. ターゲット・タイプとして「データベース・インスタンス」を選択し、「オラクル社認定のテンプレートを表示」を選択して、「実行」をクリックします。

3. 「オラクル社認定 - 週次データベース使用状況トラッキング・メトリックの有効化」を選択し、「適用」をクリックします。

4. 新しいページで、「追加」をクリックします。チェック・ボックスを使用して該当するターゲットを選択し、「選択」をクリックします。

5. 「OK」をクリックして、変更をファイナライズします。

6. 確認メッセージと、更新されていないターゲットの数を示す「保留中の適用操作」列を検証します。保留中の適用操作がないこと(「0」の表示)を確認します。

毎時メトリック収集の有効化:

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. ターゲット・タイプとして「データベース・インスタンス」を選択し、「オラクル社認定のテンプレートを表示」を選択して、「ジャンプ」をクリックします。

3. 「オラクル社認定 - 毎時データベース使用状況トラッキング・メトリックの有効化」を選択し、「適用」をクリックします。

4. 「追加」をクリックして、該当するターゲットを選択します。

5. 「OK」をクリックして、変更をファイナライズします。

6. ページ上部に確認メッセージが表示されます。

使用状況トラッキング・レポートの無効化

1. 前の項の手順1および手順2を実行します。

2. 手順3で、オラクル社認定 - データベース使用状況トラッキング・メトリックの無効化(毎時と週次の両方を無効化)を選択します。

3. 前の項の手順4から手順6を実行します。

42.2.3 コマンドライン・インタフェースを使用したメトリック収集の有効化/無効化

前述の項、「監視テンプレートを使用したメトリック収集の有効化/無効化」では、Diagnostics Packでライセンスされたデータベース・ターゲットに対してEnterprise Manager Cloud Controlコンソールを使用して、これらのアクションを実行しました。ただし、Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用して、オペレーティング・システム・コマンドラインからのメトリック収集を有効化/無効化することができ、その場合は追加のライセンスは必要ありません。

この項では、次の項目について説明します。

- EM CLIログインの設定

- メトリック収集の有効化/無効化

- EM CLIを使用したすべてのデータベース・ターゲットの一覧表示

- SQLを使用した収集ステータスの確認

42.2.3.1 EM CLIログインの設定

EM CLIコマンドを実行してメトリック収集を有効化/無効化する前に、EM CLIログインを構成する必要があります。これは通常、次の例に示すように、URL、ユーザ名、パスワードを指定することで行います。

emcli setup -url="https://jupiter.solarsystem.com:7799/em" -username=sysman -password=manager -trustall

42.2.3.2 メトリック収集の有効化/無効化

メトリック収集はEM CLI modify_collection_schedule動詞を使用して、有効化/無効化されます。この動詞の詳細は、Oracle Enterprise Managerコマンドライン・インタフェース・ガイドに記載されています。

データベース使用状況トラッキングには、次の構文を使用する必用があります。

emcli modify_collection_schedule
-targetType="oracle_database"
-targetNames="tname1;tname2;tname3;..."
-collectionName="lms_wk_ci_cdb|lms_hr_ci_cdb|lms_wk_ci|lms_hr_ci"
-freqType="HOUR|DAY|WEEKLY"
-freqValue="1|7| MON|TUE|WED|THU|FRI|SAT|SUN"
-collectionStatus="ENABLED|DISABLED"
-preview="N"

パラメータ

- targetNames
ターゲット名は、リポジトリに存在する名前と同じにする必要があります。ターゲットは、すべてtargetTypeパラメータで指定したターゲット・タイプと同じである必要があります。セミコロン(;)を使用して各名前を区切ります。収集スケジュールの変更が実行されるのは、ターゲット名とターゲット・タイプの組合せが有効な場合のみです。例:tname1;tname2;tname3

- collectionName
データベース使用状況トラッキングのために事前に定義された4つのメトリック収集の1つの名前。wkは毎週の収集を示し、hrは毎時の収集を示します。_cdb接尾辞は、収集がCDBデータベース・ターゲットにのみ適用されることを示します。

- lms_hr_ci_cdbおよびlms_wk_ci_cdb - すべてのCDBデータベース・ターゲット(PDBを使用)に適用される必要があります。

- lms_hr_ciおよびlms_wk_ci - 残りすべてのデータベース・ターゲットに適用される必要があります。

- freqTypeおよびfreqValue
頻度を示します。これらの2つのパラメータは、collectionStatus="DISABLED"の場合には、必要がないか(指定されても)無視されます。

これらのパラメータは次のいずれかになります。

- freqType=HOUR freqValue=1

- freqType= DAYS freqValue=7

- freqType=WEEKLY freqValue=MON (または他の平日)

- collectionStatus
収集を有効化または無効化します。デフォルトは「有効」です。Disabledの場合、freqTypeおよびfreqValueは無視されます。

使用例

- CDBデータベース・ターゲットで週次メトリックを有効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb3" \
-collectionName="lms_wk_ci_cdb" \
-freqType="DAY" \
-freqValue="7" \
-collectionStatus="ENABLED" \
-preview="N"

注意: Windowsでは、「\」をWindows固有のコマンドライン連結文字「^」に置き換えます。

- 複数の非CDBデータベース・ターゲットで週次メトリックを有効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb1;targetdb2" \
-collectionName="lms_wk_ci" \
-freqType="WEEKLY" \
-freqValue="SUN" \
-collectionStatus="ENABLED" \
-preview="N"

- CDBデータベース・ターゲットで週次メトリックを無効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb3" \
-collectionName="lms_wk_ci_cdb" \
-collectionStatus="DISABLED" \
-preview="N"

- 複数の非CDBデータベース・ターゲットで週次メトリックを無効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb1;targetdb2" \
-collectionName="lms_wk_ci" \
-collectionStatus="DISABLED" \
-preview="N"

- CDBデータベース・ターゲットで毎時メトリックを有効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb3" \
-collectionName="lms_hr_ci_cdb" \
-freqType="DAY" \
-freqValue="7" \
-collectionStatus="ENABLED" \
-preview="N"

- 複数の非CDBデータベース・ターゲットで毎時メトリックを有効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb1;targetdb2" \
-collectionName="lms_hr_ci" \
-freqType="WEEKLY" \
-freqValue="SUN" \
-collectionStatus="ENABLED" \
-preview="N"

- CDBデータベース・ターゲットで毎時メトリックを無効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb3" \
-collectionName="lms_hr_ci_cdb" \
-collectionStatus="DISABLED" \
-preview="N"

- 複数の非CDBデータベース・ターゲットで毎時メトリックを無効化します。

emcli modify_collection_schedule \
-targetType="oracle_database" \
-targetNames="targetdb1;targetdb2" \
-collectionName="lms_hr_ci" \
-collectionStatus="DISABLED" \
-preview="N"

42.2.3.3 EM CLIを使用したすべてのデータベース・ターゲットの一覧表示

構成処理では、抜けのないようにするため、すべてのデータベース・ターゲットを一覧にすることが有用な場合があります。

すべてのデータベース・ターゲットを一覧表示するには、次のEM CLIのコマンドを実行します。

emcli get_targets -targets="oracle_database"

42.2.3.4 SQLを使用した収集ステータスの確認

次のSQL問合せをOEMリポジトリ上で実行すると、データベース・ターゲットに割り当てられた収集ステータスおよびスケジュールを一覧表示することができます。

select
t.TARGET_NAME,
c.COLL_NAME,
c.IS_ENABLED,
c.SCHEDULE_EX
from      SYSMAN.MGMT_TARGETS          t
left join SYSMAN.MGMT_COLLECTIONS c on t.TARGET_GUID = c.OBJECT_GUID and c.COLL_NAME like 'lms_%_ci%'
where t.target_type = 'oracle_database'
order by t.TARGET_NAME, c.COLL_NAME;

42.2.4 データベース使用状況トラッキング・レポートの作成

1. Enterprise Managerにログインします。「設定」メニューから、「セキュリティ」、「監視資格証明」の順に選択します。

2. 「データベース・インスタンス」ターゲット・タイプを選択し、「監視資格証明の管理」をクリックします。

3. 「資格証明セット」で「データベース使用状況トラッキングの資格証明」エントリを選択し、「検索」をクリックします。

該当するターゲットの行をクリックし、次に「資格証明の設定」をクリックします。

重要:
この操作を、すべてのデータベース・インスタンスに対して実行する必要があります。

4. SYSDBA権限を持つデータベース・ユーザーのユーザー名とパスワードを入力します。

5. 代替方法: Enterprise Managerコマンド・ライン・ユーティリティ(EM CLI)を使用し、次の例を参考にして、前述の設定を行います。

例42-1 複数ターゲット

emcli set_monitoring_credential -target_names="testdb1;testdb2" -target_type=oracle_database -set_name=DBCredsLMSMonitoring -cred_type=DBCreds -attributes="DBUserName:<USERNAME>;DBPassword:<PASSWORD>;DBRole:SYSDBA"

例42-2 単一ターゲット

emcli set_monitoring_credential -target_name=Oemrep_Database -target_type=oracle_database -set_name=DBCredsLMSMonitoring-cred_type=DBCreds -attributes="DBUserName:<USERNAME>;DBPassword:<PASSWORD>;DBRole:SYSDBA"

42.3 データベース使用状況トラッキング・レポートの生成

データベース使用状況トラッキング・レポートの生成は、次の2つの手順で実行します。

1. Business Intelligence Publisher (BI Publisher)の構成 - 出力ファイルの宛先(FTPサーバーとフォルダ)の設定

2. 使用状況トラッキング・レポートの実行 - 情報が収集された後にCSVファイルを生成

42.3.1 Business Intelligence Publisher (BI Publisher)の構成

1. 「エンタープライズ」メニューから「レポート」を選択し、次に「BI Publisher Enterpriseレポート」を選択します。

2. 「BI Publisher EnterpriseレポートWebアプリケーション」をクリックして、Oracle BI Publisher URLにナビゲートします。Enterprise Managerにログインしたときに使用したのと同じ資格証明を使用して、BI Publisherにログインします。

重要:
ページの下部に表示される「データベース使用状況トラッキング・レポート」をクリックしないでください。この「使用状況トラッキング・レポート」のオンライン実行は、無効になっています。

3. 配信先を設定します。
ページの右上隅の「管理」タブをクリックします。その後、次に示すとおり、「配信」の下の「FTP」を選択します。

4. FTPサーバーを追加します。
「サーバーの追加」をクリックします。

FTPサーバーの次のフィールドに入力します。

サーバー名: myFTPserverなど任意の名前

ホスト: myhost.company.comなど

ポート: 22など

「セキュアFTPの使用」チェック・ボックスを選択してセキュアFTP (SFTP)を有効にします。

ホストへの接続に必要なユーザー名およびパスワードを入力します。

5. 前述の手順4で構成したFTPサーバーとともにデータ・モデルを構成します。
次の図に示すとおり、「カタログ・フォルダ」または代替方法として「カタログ」メニューをクリックします。

「共有フォルダ」、「Enterprise Manager Cloud Control」および「EM_Datamodels」を順に選択します。

「データベース使用状況トラッキング・レポート」にスクロールし、編集をクリックします。

左側のリストの下部で、「バースティング」および「BurstToFTPserver」を順にクリックします。

「SQL問合せ」領域で、次に示すとおりに問合せを更新します。

- PARAMETER1列の値として「myFTPserver」(手順4で構成した値)。

- PARAMETER4列の値として出力ディレクトリ(ディスクのディレクトリの絶対パス)。

42.3.2 使用状況トラッキング・レポートの実行:

1. 「カタログ」メニューから、「共有フォルダ」、「Enterprise Manager Cloud Control」、「トラッキング・レポート」、「データベース使用状況トラッキング・レポート」および「スケジュール」を順にクリックします。

2. 「スケジュール」タブで、頻度が「1回」に設定されており、「即時実行」が選択されていることを確認します。「発行」をクリックします。

3. ポップアップ・ウィンドウで、ジョブを後で一意に識別できるようなジョブ名を入力します。
発行したジョブのステータスは、次に示すとおり、レポート・ジョブ履歴ページで監視できます。

メトリック収集のエラー(発生した場合)は、インスタンス用に生成された各レポートの下部に表示されます。

スクリーン・ショット(job_running.png)でハイライト表示されている「リフレッシュ」ボタンを使用して、ジョブのステータスをリフレッシュします。

ジョブのステータスが「実行中」から「成功」に変化するまで待機します。

42.4 データベース使用状況トラッキング・サマリー・レポート

「データベース使用状況トラッキング・レポート」の手順1および手順2を実行します(実行していない場合)。

1. データベース使用状況トラッキング資格証明を設定します。

2. メトリック収集を有効にします。

3. Enterprise Managerにログインしたら、「Enterprise」メニューから、「レポート」および「BI Publisherレポート」を順にクリックします。

4. ツリーで「データベース使用状況トラッキング・サマリー・レポート」をクリックします。初めての場合は、BI Publisherへのログインが求められます。

5. レポートは、BI Publisherにログインすることによっても表示できます。

42.5 Fusion Middleware使用状況トラッキング・サマリー・レポートの生成

注意:
Fusion Middleware使用状況トラッキング・サマリー・レポートには、Enterprise Manager Fusion Middlewareプラグインがインストールされているときに収集されたデータが含まれます。Fusion Middlewareメトリック収集を有効にするために必要な手順はありません。

1. Enterprise Managerにログインしたら、「Enterprise」メニューから、「レポート」および「BI Publisherレポート」を順にクリックします。

2. ツリーで「FMW使用状況トラッキング・レポート」をクリックします。初めての場合は、BI Publisherへのログインが求められます。

3. レポートは、BI Publisherにログインすることによっても表示できます。
次の図のとおり、「カタログ・フォルダ」または「カタログ」メニューをクリックします。

42.6 ホスト使用状況トラッキング・レポート

ホストの使用状況トラッキング・レポートには、ホストのプロセッサ情報の概要が表示されます。これは情報のためのみに使用され、ライセンスの権利または要件は示されません。次に示すLicense Management Servicesで

ライセンス要件について確認してください。http://www.oracle.com/us/corporate/license-management-services/index.html

「ホスト使用状況トラッキング・サマリー・レポート」および「ホスト使用状況トラッキング詳細レポート」という2つのレポートが追加されています。

- 「ホスト使用状況トラッキング・サマリー・レポート」は、ホスト・システムのプロセッサ情報の概要です。
このレポートは、オンラインでの実行および表示が可能です。出力レポートは、PDF、RTFおよびExcelの形式でエクスポートできます。

- 「ホスト使用状況トラッキング詳細レポート」は、エクスポート可能な形式で前述の使用状況データを提供します。エクスポートしたデータをOracle License Management Servicesに送信して、ライセンス要件を確認するためにさらなる分析を行うことができます。License Management Services (http://www.oracle.com/us/corporate/license-management-services/index.html)にアクセスして、契約を開始してください。
管理対象の各ホストのプロセッサ情報による単一のファイルが作成されます。出力ファイルの形式は、パイプで区切られたファイルに限定されています。

42.6.1 ホスト使用状況トラッキング・サマリー・レポートの生成

1. Enterprise Managerにログインしたら、「Enterprise」メニューから、「レポート」および「BI Publisherレポート」を順にクリックします。

2. ツリー・リストで、「ホスト使用状況トラッキング・サマリー・レポート」をクリックします。初回ログインの場合は、BI Publisherにログインするようにプロンプトが表示されます。

42.6.2 ホスト使用状況トラッキング詳細レポートの生成

1. Enterprise Managerにログインしたら、「Enterprise」メニューから、「レポート」および「BI Publisherレポート」を順にクリックします。

2. ツリー・リストで「ホスト使用状況トラッキング詳細レポート」をクリックします。初めての場合は、BI Publisherへのログインが求められます。

3. 右上隅の「表示」アイコンをクリックし、「テキスト」をクリックします。

4. 右上隅の「アクション」アイコンをクリックし、「エクスポート」を選択して「テキスト」をクリックします。

5. 「保存」を選択します。

第VII部

モバイル機器からのEnterprise Managerアクセス

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

- Enterprise Managerへのリモート・アクセス

43 Enterprise Managerへのリモート・アクセス

この章では、Cloud Controlでのインシデントおよび問題を管理する目的でEnterprise Managerにリモートで接続する、iDeviceの設定および使用方法について説明します。

この章では、SafariブラウザからEnterprise Managerデスクトップ・バージョンに直接接続する方法についても説明します。

次の各項では、Cloud Control Mobileの設定と使用について説明します。

システム要件の確認
初期設定の実行
初回の接続
ログイン画面の表示
管理設定
インシデント・マネージャでのCloud Control Mobileの使用
Cloud Control Mobileでの操作
ヒントとテクニックの習得
iDeviceを使用してデスクトップ・バージョンに直接接続するには、第43.9項「Enterprise Managerデスクトップ・バージョンへの接続」を参照してください。

43.1 システム要件の確認

Cloud Control Mobileは、次のようなEnterprise Manager Cloud Control 12cの最小構成にデプロイできます。

- Enterprise Manager Cloud Control 12c (12.1.0.1)のパッチ適用済リリース(2012年2月以降にリリースされたもの)の新規インストール

- バンドル・パッチ1(BP1)適用済の既存Enterprise Manager Cloud Control 12c (12.1.0.1)インストール

追加のシステム要件は次のとおりです。

- iOS 4.2.x以上を実行しているiDevice(iPhone、iPod touchまたはiPad)

- Enterprise Managerにアクセス可能なネットワークへのWi-Fiまたは3G接続(Cloud Control MobileはVPN経由の接続をサポートしています。)

- アプリケーションをiTunes App StoreからダウンロードするためのAppleアカウント

43.2 初期設定の実行

初期設定では、次のタスクを実行します。

- Wi-Fiまたは3Gネットワークに接続します。

- VPNをインストールおよび構成します。

- Cloud Control Mobileアプリケーションをダウンロードし、iDeviceと同期します。

- Cloud Controlの接続URLをインストール済のEnterprise Managerに追加します。

43.3 初回の接続

アプリケーションを最初にインストールした際には、デフォルトのEnterprise Manager接続が存在しないため、Cloud Control URLを指定する必要があります。これを行うには、次の2つの方法があります。

- iDevice設定アプリケーションを使用します。

- Cloud Control Mobileアプリケーションを起動します。

どちらの場合も、まずVPNにログインしてから(必要な場合)、次の手順を続行します。VPN接続がない場合、ログイン画面は表示されません。

iDevice設定

デフォルトのCloud Control URLを次のように定義します。

1. 「ホーム」画面で「設定」アイコンをタップします。

2. アプリケーション・リストで「Cloud Control」をタップします。

3. 「Cloud Control」画面で、サイトを識別する名前を入力し、接続するCloud Control URLを入力します。URLは次の形式で入力する必要があります。

https://www.yoursite.com/em

4. 「設定」をタップして情報を格納し、アプリケーションのリストに戻ります。

アプリケーションの初期起動

デフォルトのCloud Control URLを次のように定義します。

1. 「ホーム」画面でCloud Control Mobileアイコンをタップします。

2. 「サイトの追加」画面で、サイトを識別する名前を入力し、接続するCloud Control URLを入力します。URLは次の形式で入力する必要があります。

https://www.yoursite.com/em

まず右側の「X」をタップしてフィールドをクリアしてから、名前フィールドに入力する必要があります。

3. 「完了」をタップして情報を格納します。

4. 「サイト」画面で「完了」をタップします。この画面を終了する前に、別のサイトを追加することもできます。

5. 「サイト」ナビゲーション・バーで「設定」をタップし、「サイト」リスト画面を閉じます。

6. 「設定」ナビゲーション・バーで「保存」をタップし、アクションを終了します。

ログインを続行します。

43.4 ログイン画面の表示

ログイン画面が表示される条件は、次のとおりです。

- 初期起動でデフォルトのCloud Control URLを指定した後

- 以降のアプリケーション起動時いつでも

- デフォルト・サイトの変更時

- ログアウト時

「設定」アイコンをタップして、サイトのリストを表示するか、デフォルトのログイン・サイトを変更します。詳細は、第43.5項「管理設定」を参照してください。

資格証明を指定し、「ログイン」をタップします。インシデント・マネージャが開き、オープンなインシデントおよび問題のビューが表示されます。

Enterprise Managerのインストールで、有効な認証局で署名されたサイト証明書を持たない場合、無効な証明書を表すアラートが、ログイン画面の上に表示されます。ログインを続行するか、接続しようとするURLを変更することもできます。

注意:
インストール済のEnterprise Managerでシングル・サインオンを使用している場合、サイト・ログインのかわりにSSOプロセスが使用されます。シングル・サインオンが完了すると、ワークフローは、オープンなインシデントおよび問題のビューに進みます。

43.5 管理設定

Cloud Control Mobileには、すべてのアプリケーションを管理するのに使用するiDevice設定アプリケーションとは別に、独自の設定インタフェースがあります。

Cloud Control Mobileアプリケーションの管理設定では、次のアクションを実行します。

- サイトの追加

- サイトの編集

- サイトの削除

- デフォルト・サイトの変更

各アクションは、次の基本的な同じステップで開始します。

1. ナビゲーション・バーの右にある「アクション」アイコンをタップします。

2. アクション・シートで「設定」をタップします。

3. 「サイトの編集」テーブル行をタップします。

4. 「編集」をタップします。次のような「サイト」管理画面が表示されます。

次で説明するように、個別のアクションを続けます。

サイトの追加

1. 「サイト」ナビゲーション・バーの左にある+記号をタップします。

2. 追加するサイトの名前およびURLを入力します。

3. 「サイトの追加」ナビゲーション・バーで「完了」をタップし、画面を閉じます。

4. 「サイト」ナビゲーション・バーで「完了」をタップし、編集モードを終了します。

5. 「サイト」ナビゲーション・バーで「設定」をタップし、「サイト」リスト画面を閉じます。

6. 「設定」ナビゲーション・バーで「保存」をタップし、アクションを終了します。

サイトの編集

1. 編集するURLの右にある青い矢印をタップします。

2. 必要に応じて、値を変更します。

3. 「サイトの編集」ナビゲーション・バーで「完了」をタップし、画面を閉じます。

4. 「サイト」ナビゲーション・バーで「完了」をタップし、編集モードを終了します。

5. 「サイト」ナビゲーション・バーで「設定」をタップし、「サイト」リスト画面を閉じます。

6. 「サイト」ナビゲーション・バーで「保存」をタップし、アクションを終了します。

サイトの削除

1. 削除するURLの左にある赤い円をタップします。

2. テーブル行の右に表示される「削除」をタップします。

3. 「サイト」ナビゲーション・バーで「完了」をタップし、画面を閉じます。

4. 「サイト」ナビゲーション・バーで「設定」をタップし、「サイト」リスト画面を閉じます。

5. 「設定」ナビゲーション・バーで「保存」をタップし、アクションを終了します。

デフォルト・サイトの変更

1. 新しくデフォルトにするサイトをタップします。テーブル行の右にあるチェック・マークによって、選択内容を確認できます。

2. 「設定」をタップし、「サイト」リスト画面を閉じます。

3. 「保存」をタップし、アクションを終了します。

4. しばらくすると、「ログイン」画面が表示されます。新しいサイトにログインするための資格証明を指定します。

Cloud ControlのiDevice設定で、デフォルト・サイトを変更することもできます。

43.6 インシデント・マネージャでのCloud Control Mobileの使用

Cloud Controlにリモートで接続すると、インシデント・マネージャで次のことを実行できます。

- オープンなインシデントと問題の表示、およびそれぞれの詳細(関連する更新やイベントなど)へのドリルダウン

- 指定の問題に対するインシデントのリストの参照、および各インシデントとその詳細へのリンクの使用

- インシデントおよび問題の確認

- ステータスの変更、所有者の割当て、エスカレートなどを効率よく追跡するためのインシデントおよび問題ワークフローの管理

- 問題の通知先のユーザー、および管理者によって追加されるコメントの内容の参照

また、次に示すFAQは、モバイル・アプリケーションとそれに相当するデスクトップのものとの違い、微妙な区別およびニュアンスを理解する際に役立ちます。

さらに問題を表示するにはどうしますか。

アプリケーションには一度に5つの行が表示されます。ディスプレイの下部にある「次」コントロールおよび「前」コントロールを使用して、リストをスクロールします。または数値範囲(1 - 5)をタップして、増分のリストから選択します。

問題の詳細を表示するにはどうしますか。

インシデントや問題を識別する行をタップします。「詳細」画面で、更新やイベントにドリルダウンしたり、サマリー説明を展開することができます。

モバイル・アプリでのビューはデスクトップ・バージョンと同じですか。

イベント関連のビュー(標準またはカスタム)がモバイル・アプリケーションで使用できない点を除いては、同じです。デスクトップ・バージョンで作成したカスタム・ビューは、標準のビューのリストを増補します。

ビューをリフレッシュできますか。

はい。ナビゲーション・バーの左にある「リフレッシュ」アイコンをタップします。これを行うと、タイムスタンプはリフレッシュの日時を反映します。

ターゲット詳細を表示できますか。

はい。まずインシデント詳細にドリルダウンしてから、ターゲット詳細に移動するターゲット名をタップします。インシデント詳細に戻るには、「インシデント」をタップします。

検索基準の設定やカスタム・ビューの作成はできますか。

いいえ。モバイル・アプリケーションでは検索基準の設定やカスタム・ビューの作成はできませんが、デスクトップ・バージョンの製品でビューを作成および管理し、それをモバイル・アプリケーションで使用できます。

インシデント・ルール機能を起動できますか。

いいえ。しかし、Enterprise Managerアカウントに適切な通知プリファレンスがある場合、モバイル・デバイス上のインシデント・ルールによって生成された通知を受信できます。

My Oracle Supportに接続できますか。

問題に割当て済のSR番号がある場合、番号をクリックして、My Oracle Support(MOS)モバイル・アプリケーションでSR詳細を表示できます。

ガイドされた解決情報および診断にアクセスできますか。

いいえ。

すべてのiDeviceはモバイル・アプリケーションと同じ方法で動作しますか。

ほとんど同じです。iPadに関して注意する相違点は、Safariや電子メール・メッセージなどの外部ソースで問題やターゲットへのリンクをタップすると、Safariが起動する際には、通常の「Cloud Control」ログイン画面で応答する、デスクトップ・バージョンの製品の関連するページを示します。その他のデバイスでは、外部ソースでリンクをタップすると、モバイル・アプリケーションが起動します。

43.7 Cloud Control Mobileでの操作

この項では、Cloud Control Mobileでの次の操作タスクについて説明しています。

- インシデントおよび問題の表示

- ビューの変更

- アクションの実行

43.7.1 インシデントおよび問題の表示

ナビゲーションは直感的ですが、次の項では、インシデントおよび問題の表示に関して指示します。相互作用は若干異なるため、問題の各タイプについて別の項で説明します。

インシデントの表示

リストでインシデントを表示する際には、次のガイドラインを使用します。

- 右にある矢印は、追加情報があることを示しています。

- インシデント行の任意の場所をタップすると、インシデント詳細にドリルダウンします。

- 上部にはサマリーが表示されます。サマリーは長いことがあるため、サマリーを完全に表示するには、サマリーの開始行をタップする必要がある場合があります。インシデント詳細に戻るには、「インシデント」をタップします。

- インシデント詳細の問題IDは、問題詳細にリンクしています。リンクをたどった場合、開始点、つまり最初にインシデントを開いた元のリスト・ビューに戻るには、「インシデント」をタップします。

- インシデント詳細ビューでは、ターゲット名はターゲット詳細にリンクしています。インシデント詳細に戻るには、「インシデント」をタップします。

- トラッキング情報は、インシデント詳細ビューのターゲット名の下に表示されます。

- インシデント詳細で下にスクロールし、「すべての更新」をタップすると、デスクトップ・バージョンの製品の「更新」タブと同じ内容が表示されます。インシデント詳細に戻るには、「インシデント」をタップします。

- さらにスクロールし、「イベント・リスト」をタップすると、デスクトップ・バージョンの製品の「イベント」タブと同じ内容が表示されます。インシデント詳細に戻るには、「インシデント」をタップします。

問題の表示

リストで問題を表示する際には、次のガイドラインを使用します。

- 右にある矢印は、追加情報があることを示しています。

- 問題行の任意の場所をタップすると、問題詳細にドリルダウンします。

- 上部にはサマリーが表示されます。サマリーは長いことがあるため、サマリーを完全に表示するには、サマリーの開始行をタップする必要がある場合があります。問題詳細に戻るには、「問題」をタップします。

- 問題に割当て済のSR番号がある場合、番号をタップして、MOS資格証明を使用しているMy Oracle Support(MOS)モバイル・アプリケーションにログインします。SR詳細を表示し、適切なアクションを実行できます。問題詳細に戻るには、「ホーム」画面に移動し、Cloud Control Mobileアプリケーション・アイコンをタップします。

- 問題詳細ビューでは、ターゲット名はターゲット詳細にリンクしています。問題詳細に戻るには、「問題」をタップします。

- トラッキング情報は、問題詳細ビューのターゲット名の下に表示されます。

- 問題詳細で下にスクロールし、「すべての更新」をタップすると、デスクトップ・バージョンの製品の「更新」タブと同じ内容が表示されます。問題詳細に戻るには、「問題」をタップします。

- さらにスクロールすると、最初と最後のインシデント、および問題が発生したインシデントの番号など、追加詳細が表示されます。

- さらにスクロールし、「インシデント・リスト」をタップすると、デスクトップ・バージョンの製品の「インシデント」タブと同じ内容が表示されます。問題詳細に戻るには、「問題」をタップします。

- リスト内の各インシデント・サマリーは、インシデントの詳細にリンクしています。リンクをたどった場合、開始点、つまり最初に問題を開いた元のリスト・ビューに戻るには、「インシデント」をタップします。

43.7.2 ビューの変更

最初にログインすると、デフォルトで、オープンなインシデントと問題のビューが表示されます。次のように、ビューを変更できます。

1. 「ビュー」アイコン(現在のビューのタイトルの右にある3本の横線)をタップして、「ビュー」メニューを開きます。

2. 目的のビューをタップします。右にあるチェック・マークによって、選択内容を確認できます。

3. 「インシデント」をタップして、新しいビューを表示します。

43.7.3 アクションの実行

インシデントや問題の詳細の表示中に、次のアクションを実行できます。

- 問題の確認

- 問題のワークフローの管理

インシデントや問題を確認するには、次の手順を実行します。

1. 詳細の表示中に、「アクション」をタップします。

2. アクション・シートで「確認」をタップします。
メッセージで、「詳細」画面の更新を確認します。

たとえば、問題がすでに確認またはクローズされていたり、問題を確認するための正しい権限が付与されていないなど、様々な理由で、「確認」アクションがアクション・シートに表示されない場合があることに注意してください。

効率よく追跡するためにインシデントや問題のワークフローを管理するには、次の手順を実行します。

1. 詳細の表示中に、「アクション」をタップします。

2. アクション・シートで「管理」をタップします。

3. 「管理」ダイアログで、デスクトップ・バージョンと同じように入力します。スタイルと書式設定をコメントに追加する機能のみがありません。

4. 「保存」をタップし、アクションを終了します。

43.8 ヒントとテクニックの習得

アプリケーション内でタッチとホールドのジェスチャを行うといつでも、ログイン中またはログインしようとしている現在のサイトが、画面の下部に表示されます。サイト名が表示できない場合、URLが表示されます。サイトを識別するものが表示された状態で、右にある情報アイコンをタップすると、「設定」画面にアクセスし、そこでサイトの管理やデフォルト・サイトの変更ができます。タッチとホールドのジェスチャを繰り返すと、画面の下部からサイトの表示が削除されます。

アプリケーションからログアウトして、Cloud Control Mobileに戻ろうとするページで動かなくなってしまった場合、この問題を解決するのに次の2つの方法があります。

- 「初回の接続」を開き、Cloud ControlのデフォルトURLを変更します。

- アプリケーションを強制終了し、Cloud Control Mobileを再起動します。たとえば、電源オフ・スライダが表示されるまでデバイスの上部の「On/Off」ボタンを押したままにし、アプリケーションが閉じるまで「ホーム」ボタンを押します。

43.9 Enterprise Managerデスクトップ・バージョンへの接続

Enterprise Manager Cloud Control 12c (12.1.0.2)では、iDeviceがEnterprise Managerと同じネットワークにある場合、iDeviceでSafariを使用してEnterprise Managerのデスクトップ・バージョンにログインすることができます。リモートにいる場合、VPN接続を確立する必要がある場合があります。

1. WiFiまたは3Gネットワークに接続します。

2. 必要ならばVPN接続を確立します。

3. Safariを開き、Enterprise Manager URLを指定します。

4. Cloud Controlにアクセスするためのログイン資格証明を入力します。

Cloud ControlがiDeviceで開いている状態で、完全な機能セットにアクセスできます。インタフェースを移動するときには次の点を考慮します。

- ジェスチャを練習して、画面領域の一部をズームする感覚をつかんでください。

- 選択したメニューをタップするときは急がないでください。瞬時に処理が行われるとはかぎりません。

- 選択した項目をタッチしてホールドすると、コンテキスト・メニュー(右クリック)が開きます。このジェスチャも、正しい感覚をつかむには多少の練習が必要です。

- すべてのページが正確にレンダリングされるわけではありません。

- Flex/Flash効果のあるページはまったくレンダリングされません。

注意:
Safariを介してEnterprise Managerのデスクトップ・バージョンに接続する場合、Safariのオートフィル名および「パスワード」の構成設定は必ず「OFF」にしてください。それ以外の場合は、ログイン資格証明はローカル・ストアに保存できますが、機密データに対するアプリケーションのスキャンを受けやすい場所です。

第VIII部

付録

この部は、次の付録で構成されています。

- 付録A「Enterprise Manager MIBの変数の解釈」

- 付録B「Enterprise Manager MIBの定義」

- 付録C「SNMPトラップのマッピング」

- 付録D「ターゲットの可用性状態の概要」

A Enterprise Manager MIBの変数の解釈

Enterprise Manager Cloud Controlは、サード・パーティのSNMP対応アプリケーションにSNMPトラップを送信できます。トラップ・コンテンツの詳細は、管理情報ベース(MIB)変数から取得できます。この付録では、プライベートOracle Enterprise Manager MIBの変数の解釈に役立つ情報を提供します。

MIB変数の形式詳細は、第3.6.3項「MIB変数の説明の解釈」を参照してください。

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

- oraEMNGEvent

- oraEM4AlertTable

- oraEM4JobAlertTable

注意:
Cloud Control 12c以降で作成されたSNMPトラップ通知メソッドは、oraEMNGEventトラップを送信します。
Enterprise Managerリリース12c以前に作成されたSNMPトラップ通知メソッドは、oraEM4AlertおよびoraEM4JobAlertトラップを送信します。Enterprise Managerリリース12c以降にアップグレードした後は、以前のリリースからの既存のメソッドは、下位互換性のために古いトラップを送信し続けます。

A.1 oraEMNGEvent

次の項では、Cloud Control 12c以降で作成されたSNMPトラップ通知メソッドから送信されたSNMPトラップについて説明します。

表A-1 oraEMNGEvent変数および対応するオブジェクトID

変数名

オブジェクトID

oraEMNGEventIndex

1.3.6.1.4.1.111.15.3.1.1.1.1

oraEMNGEventNotifType

1.3.6.1.4.1.111.15.3.1.1.2.1

oraEMNGEventMessage

1.3.6.1.4.1.111.15.3.1.1.3.1

oraEMNGEventMessageURL

1.3.6.1.4.1.111.15.3.1.1.4.1

oraEMNGEventSeverity

1.3.6.1.4.1.111.15.3.1.1.5.1

oraEMNGEventSeverityCode

1.3.6.1.4.1.111.15.3.1.1.6.1

oraEMNGEventRepeatCount

1.3.6.1.4.1.111.15.3.1.1.7.1

oraEMNGEventActionMsg

1.3.6.1.4.1.111.15.3.1.1.8.1

oraEMNGEventOccurrenceTime

1.3.6.1.4.1.111.15.3.1.1.9.1

oraEMNGEventReportedTime

1.3.6.1.4.1.111.15.3.1.1.10.1

oraEMNGEventCategories

1.3.6.1.4.1.111.15.3.1.1.11.1

oraEMNGEventCategoryCodes

1.3.6.1.4.1.111.15.3.1.1.12.1

oraEMNGEventType

1.3.6.1.4.1.111.15.3.1.1.13.1

oraEMNGEventName

1.3.6.1.4.1.111.15.3.1.1.14.1

oraEMNGAssocIncidentId

1.3.6.1.4.1.111.15.3.1.1.15.1

oraEMNGAssocIncidentOwner

1.3.6.1.4.1.111.15.3.1.1.16.1

oraEMNGAssocIncidentAcked

1.3.6.1.4.1.111.15.3.1.1.17.1

oraEMNGAssocIncidentStatus

1.3.6.1.4.1.111.15.3.1.1.18.1

oraEMNGAssocIncidentPriority

1.3.6.1.4.1.111.15.3.1.1.19.1

oraEMNGAssocIncidentEscLevel

1.3.6.1.4.1.111.15.3.1.1.20.1

oraEMNGEventTargetName

1.3.6.1.4.1.111.15.3.1.1.21.1

oraEMNGEventTargetNameURL

1.3.6.1.4.1.111.15.3.1.1.22.1

oraEMNGEventTargetType

1.3.6.1.4.1.111.15.3.1.1.23.1

oraEMNGEventHostName

1.3.6.1.4.1.111.15.3.1.1.24.1

oraEMNGEventTargetOwner

1.3.6.1.4.1.111.15.3.1.1.25.1

oraEMNGEventTgtLifeCycleStatus

1.3.6.1.4.1.111.15.3.1.1.26.1

oraEMNGEventTargetVersion

1.3.6.1.4.1.111.15.3.1.1.27.1

oraEMNGEventUserDefinedTgtProp

1.3.6.1.4.1.111.15.3.1.1.28.1

oraEMNGEventSourceObjName

1.3.6.1.4.1.111.15.3.1.1.29.1

oraEMNGEventSourceObjNameURL

1.3.6.1.4.1.111.15.3.1.1.30.1

oraEMNGEventSourceObjType

1.3.6.1.4.1.111.15.3.1.1.31.1

oraEMNGEventSourceObjSubType

1.3.6.1.4.1.111.15.3.1.1.32.1

oraEMNGEventSourceObjOwner

1.3.6.1.4.1.111.15.3.1.1.33.1

oraEMNGEventCAJobName

1.3.6.1.4.1.111.15.3.1.1.34.1

oraEMNGEventCAJobStatus

1.3.6.1.4.1.111.15.3.1.1.35.1

oraEMNGEventCAJobOwner

1.3.6.1.4.1.111.15.3.1.1.36.1

oraEMNGEventCAJobStepOutput

1.3.6.1.4.1.111.15.3.1.1.37.1

oraEMNGEventCAJobType

1.3.6.1.4.1.111.15.3.1.1.38.1

oraEMNGEventRuleSetName

1.3.6.1.4.1.111.15.3.1.1.39.1

oraEMNGEventRuleName

1.3.6.1.4.1.111.15.3.1.1.40.1

oraEMNGEventRuleOwner

1.3.6.1.4.1.111.15.3.1.1.41.1

oraEMNGEventSequenceId

1.3.6.1.4.1.111.15.3.1.1.42.1

oraEMNGEventRCADetails

1.3.6.1.4.1.111.15.3.1.1.43.1

oraEMNGEventContextAttrs

1.3.6.1.4.1.111.15.3.1.1.44.1

oraEMNGEventUserComments

1.3.6.1.4.1.111.15.3.1.1.45.1

oraEMNGEventUpdates

1.3.6.1.4.1.111.15.3.1.1.46.1

oraEMNGEventTotalOccurrenceCount

1.3.6.1.4.1.111.15.3.1.1.47.1

oraEMNGEventCurrOccurrenceCount

1.3.6.1.4.1.111.15.3.1.1.48.1

oraEMNGEventCurrFirstOccurDate

1.3.6.1.4.1.111.15.3.1.1.49.1

oraEMNGEventCurrLastOccurDate

1.3.6.1.4.1.111.15.3.1.1.50.1

oraEMNGEventRCAStatus

1.3.6.1.4.1.111.15.3.1.1.51.1

oraEMNGEventReportedState

1.3.6.1.4.1.111.15.3.1.1.52.1

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.3.1.1.65.1

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.3.1.1.66.1

oraEMNGEventTypeAttr7

1.3.6.1.4.1.111.15.3.1.1.67.1

oraEMNGEventTypeAttr8

1.3.6.1.4.1.111.15.3.1.1.68.1

oraEMNGEventTypeAttr9

1.3.6.1.4.1.111.15.3.1.1.69.1

oraEMNGEventTypeAttr10

1.3.6.1.4.1.111.15.3.1.1.70.1

oraEMNGEventTypeAttr11

1.3.6.1.4.1.111.15.3.1.1.71.1

oraEMNGEventTypeAttr12

1.3.6.1.4.1.111.15.3.1.1.72.1

oraEMNGEventTypeAttr13

1.3.6.1.4.1.111.15.3.1.1.73.1

oraEMNGEventTypeAttr14

1.3.6.1.4.1.111.15.3.1.1.74.1

oraEMNGEventTypeAttr15

1.3.6.1.4.1.111.15.3.1.1.75.1

oraEMNGEventTypeAttr16

1.3.6.1.4.1.111.15.3.1.1.76.1

oraEMNGEventTypeAttr17

1.3.6.1.4.1.111.15.3.1.1.77.1

oraEMNGEventTypeAttr18

1.3.6.1.4.1.111.15.3.1.1.78.1

oraEMNGEventTypeAttr19

1.3.6.1.4.1.111.15.3.1.1.79.1

oraEMNGEventTypeAttr20

1.3.6.1.4.1.111.15.3.1.1.80.1

oraEMNGEventTypeAttr21

1.3.6.1.4.1.111.15.3.1.1.81.1

oraEMNGEventTypeAttr22

1.3.6.1.4.1.111.15.3.1.1.82.1

oraEMNGEventTypeAttr23

1.3.6.1.4.1.111.15.3.1.1.83.1

oraEMNGEventTypeAttr24

1.3.6.1.4.1.111.15.3.1.1.84.1

oraEMNGEventTypeAttr25

1.3.6.1.4.1.111.15.3.1.1.85.1

A.1.1 oraEMNGEventIndex

構文

整数

アクセス

読取り専用

ステータス

必須

説明

特定のイベントの索引で、イベントが生成されたときにのみ一意です。

A.1.2 oraEMNGEventNotifType

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

通知タイプ。表示される値:

- NOTIF_NORMAL

- NOTIF_RETRY

- NOTIF_DURATION

- NOTIF_REPEAT

- NOTIF_CA

- NOTIF_RCA

A.1.3 oraEMNGEventMessage

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたメッセージ。

A.1.4 oraEMNGEventMessageURL

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

イベント・メッセージのEnterprise Manager Cloud ControlコンソールURL。INFORMATIONAL以外の重大度のイベントに対して移入されます。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.5 oraEMNGEventSeverity

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

「致命的」、「クリティカル」、「警告」、「アドバイザ」、「情報」、「クリア」などのイベントの重大度。

A.1.6 oraEMNGEventSeverityCode

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

「致命的」、「クリティカル」、「警告」、「アドバイザ」、「情報」、「クリア」などの重大度の内部コード。

A.1.7 oraEMNGEventRepeatCount

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

イベントの繰返し通知カウンタ。

A.1.8 oraEMNGEventActionMsg

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに対するアクション・メッセージ。

A.1.9 oraEMNGEventOccurrenceTime

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが発生した時刻(オプション)。これは発生時刻のあるイベントに対してのみ移入されます。

A.1.10 oraEMNGEventReportedTime

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントがレポートされた時刻です。

A.1.11 oraEMNGEventCategories

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属するカテゴリのリスト。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.12 oraEMNGEventCategoryCodes

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属する内部カテゴリ・コードのリスト。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.13 oraEMNGEventType

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属するイベント・タイプの名前。

使用可能なイベント・タイプ

- metric_alert

- target_availability

- job_status_change

- metric_error

- user_reported

- cs_core

- sla_alert

- mext_update

- selfupdate

- cs_rule_violation

A.1.14 oraEMNGEventName

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントの名前。

A.1.15 oraEMNGAssocIncidentId

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたインシデントのID(オプション)。

A.1.16 oraEMNGAssocIncidentOwner

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたインシデントの所有者(オプション)。

A.1.17 oraEMNGAssocIncidentAcked

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたインシデントの確認済ステータス。1は確認済、0は未確認を示します。

A.1.18 oraEMNGAssocIncidentStatus

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたインシデントのステータス。

A.1.19 oraEMNGAssocIncidentPriority

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたインシデントの優先度。

A.1.20 oraEMNGAssocIncidentEscLevel

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたインシデントのエスカレーション・レベル。

A.1.21 oraEMNGEventTargetName

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが適用されるターゲットの名前。ターゲットに関するイベントに対してのみ移入されます。

A.1.22 oraEMNGEventTargetNameURL

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが適用されるターゲットのEnterprise ManagerコンソールURL。ターゲットに関するイベントに対してのみ移入されます。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.23 oraEMNGEventTargetType

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが適用されるターゲットの種類。ターゲットに関するイベントに対してのみ移入されます。

A.1.24 oraEMNGEventHostName

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが発生したホストの名前。ターゲットに関するイベントに対してのみ移入されます。

A.1.25 oraEMNGEventTargetOwner

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが発生したターゲットの管理責任者。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.26 oraEMNGEventTgtLifeCycleStatus

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが発生したターゲットのライフサイクル・ステータス。

A.1.27 oraEMNGEventTargetVersion

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが発生したターゲットのバージョン。

A.1.28 oraEMNGEventUserDefinedTgtProp

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたターゲットのユーザー定義済のターゲット・プロパティ[名前、値ペアのリスト]。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.29 oraEMNGEventSourceObjName

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属するソース・オブジェクトの名前。ジョブなどのターゲット以外のオブジェクトに関するイベントに対してのみ移入されます。

A.1.30 oraEMNGEventSourceObjNameURL

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属するソース・オブジェクトのEnterprise ManagerコンソールURL。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.31 oraEMNGEventSourceObjType

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属するソース・オブジェクトのタイプ。

A.1.32 oraEMNGEventSourceObjSubType

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属するソース・オブジェクトのサブタイプ。(オプション)トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.33 oraEMNGEventSourceObjOwner

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントが属するソース・オブジェクトの管理責任者。(オプション)トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.34 oraEMNGEventCAJobName

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられた修正処理ジョブの名前。

A.1.35 oraEMNGEventCAJobStatus

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられた修正処理ジョブのステータス。

A.1.36 oraEMNGEventCAJobOwner

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられた修正処理ジョブの所有者。

A.1.37 oraEMNGEventCAJobStepOutput

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられた修正処理ジョブのジョブ・ステップの出力。

A.1.38 oraEMNGEventCAJobType

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられた修正処理ジョブのジョブ・タイプ。

A.1.39 oraEMNGEventRuleSetName

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

この通知を発生したルールセットの名前。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.40 oraEMNGEventRuleName

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

この通知を発生したルールセット内のルールの名前。

A.1.41 oraEMNGEventRuleOwner

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

この通知を発生したルールセットの所有者。

A.1.42 oraEMNGEventSequenceId

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

現在の問題がクリアされるまで一意に識別するためにEnterprise Managerが生成した識別子。

A.1.43 oraEMNGEventRCADetails

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられた根本原因分析情報(存在する場合)。

A.1.44 oraEMNGEventContextAttrs

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたコンテキスト属性。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.45 oraEMNGEventUserComments

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられたユーザー・コメント。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.46 oraEMNGEventUpdates

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

このイベントに関連付けられた更新。トラップ・サイズが構成済のSNMPパケット・サイズを超えていると、この変数は空です。

A.1.47 oraEMNGEventTotalOccurrenceCount

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

すべてのオープンな重複解除済イベントについて、ターゲット上で同じイベントが発生した合計数。この属性は、重複解除済イベントにのみ適用されます。

A.1.48 oraEMNGEventCurrOccurrenceCount

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

この収集期間におけるイベントの合計発生数。この属性は、重複解除済イベントにのみ適用されます。

A.1.49 oraEMNGEventCurrFirstOccurDate

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

この収集期間においてイベントが最初に発生したときのタイムスタンプ。この属性は、重複解除済イベントにのみ適用されます。

A.1.50 oraEMNGEventCurrLastOccurDate

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

この収集期間においてイベントが最後に発生したときのタイムスタンプ。この属性は、重複解除済イベントにのみ適用されます。

A.1.51 oraEMNGRCAStatus

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

根本原因分析のサマリー(存在する場合)。

A.1.52 oraEMNGEventReportedState

構文

DisplayString

アクセス

読取り専用

ステータス

必須

説明

これは、エンティティの最新の状態を報告するオプション値で、指定したエンティティの状態遷移を示すイベントにのみ適用可能です。たとえば、ターゲットの可用性およびジョブの状態変更のイベントの場合、この値はそれぞれターゲットまたはジョブの最新の状態となります。

A.1.53 oraEMNGEventTypeAttr(1-71)

次の表にoraEMNGEventType MIBの変数1から71をリストします。各表は、特定のイベント・タイプによってMIB変数を分類しています。

表A-2 メトリック・アラート・イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

メトリックGUID

メトリックの一意のID。

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

重大度GUID

アラート・レコードの一意のID。

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

サイクルGUID

アラート・サイクルの一意のID。

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

収集名

メトリックを収集するコレクションの名前。

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.3.1.1.65.1

メトリック・グループ

メトリックの名前。

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.3.1.1.66.1

メトリック

メトリック列の名前。

oraEMNGEventTypeAttr7

1.3.6.1.4.1.111.15.3.1.1.67.1

メトリックの説明

メトリックの簡単な説明。

oraEMNGEventTypeAttr8

1.3.6.1.4.1.111.15.3.1.1.68.1

メトリック値

イベントがトリガーされたときのメトリックの値。

oraEMNGEventTypeAttr9

1.3.6.1.4.1.111.15.3.1.1.69.1

キー値

メトリック・アラート・イベントに対応するメトリックの監視対象オブジェクト。

oraEMNGEventTypeAttr10

1.3.6.1.4.1.111.15.3.1.1.70.1

キー列1

キー列1

oraEMNGEventTypeAttr11

1.3.6.1.4.1.111.15.3.1.1.71.1

キー列1の値

キー列1の値。

oraEMNGEventTypeAttr12

1.3.6.1.4.1.111.15.3.1.1.72.1

キー列2

キー列2

oraEMNGEventTypeAttr13

1.3.6.1.4.1.111.15.3.1.1.73.1

キー列2の値

キー列2の値。

oraEMNGEventTypeAttr14

1.3.6.1.4.1.111.15.3.1.1.74.1

キー列3

キー列3

oraEMNGEventTypeAttr15

1.3.6.1.4.1.111.15.3.1.1.75.1

キー列3の値

キー列3の値。

oraEMNGEventTypeAttr16

1.3.6.1.4.1.111.15.3.1.1.76.1

キー列4

キー列4

oraEMNGEventTypeAttr17

1.3.6.1.4.1.111.15.3.1.1.77.1

キー列4の値

キー列4の値。

oraEMNGEventTypeAttr18

1.3.6.1.4.1.111.15.3.1.1.78.1

キー列5

キー列5

oraEMNGEventTypeAttr19

1.3.6.1.4.1.111.15.3.1.1.79.1

キー列5の値

キー列5の値。

oraEMNGEventTypeAttr20

1.3.6.1.4.1.111.15.3.1.1.80.1

キー列6

キー列6

oraEMNGEventTypeAttr21

1.3.6.1.4.1.111.15.3.1.1.81.1

キー列6の値

キー列6の値。

oraEMNGEventTypeAttr22

1.3.6.1.4.1.111.15.3.1.1.82.1

キー列7

キー列7

oraEMNGEventTypeAttr23

1.3.6.1.4.1.111.15.3.1.1.83.1

キー列7の値

キー列7の値。

oraEMNGEventTypeAttr24

1.3.6.1.4.1.111.15.3.1.1.84.1

キー数

メトリック内のキー・メトリック列の数。

表A-3 ターゲット可用性イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

可用性ステータス

ターゲットの現在の可用性のステータス。

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

重大度GUID

この可用性ステータスに関連付けられている重大度レコードのGUID。

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

可用性サブステータス

現在のステータスに対するターゲットのサブステータス。

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

遷移重大度

ターゲットのステータスが現在の可用性ステータスに変更された要因である遷移。

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.3.1.1.65.1

レスポンス・メトリックGUID

レスポンス・メトリックのメトリックGUID。

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.3.1.1.66.1

可用性サイクルの最初の重大度の重大度GUID

この可用性サイクルの最初の重大度レコードのGUID。

表A-4 ジョブ・ステータス変更イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

実行ID

ジョブ実行の一意のID。

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

ジョブ・ステータス

ジョブ実行のステータス。

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

実行ログ

実行された最後のステップのジョブ出力。

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

ジョブ・ステータス・コード

ジョブ実行の実行ステータス・コード。

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.3.1.1.65.1

状態変更ID

最新ステータス変更の一意のID。

表A-5 コンプライアンス標準ルール違反イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

ルート・コンプライアンス標準

ルート・コンプライアンス標準ノードの表示名。

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

ルート・コンプライアンス標準のバージョン

ルート・コンプライアンス標準のバージョン。

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

ルート・コンプライアンス標準の作成者

ルート・コンプライアンス標準の作成者。

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

親コンプライアンス標準

親コンプライアンス標準ノードの表示名。

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.3.1.1.65.1

コンプライアンス標準のバージョン

コンプライアンス標準のバージョン。

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.3.1.1.66.1

親コンプライアンス標準の作成者

親コンプライアンス標準の作成者。

oraEMNGEventTypeAttr7

1.3.6.1.4.1.111.15.3.1.1.67.1

ルート・ターゲット名

ルート・ターゲット名。

oraEMNGEventTypeAttr8

1.3.6.1.4.1.111.15.3.1.1.68.1

ルート・ターゲット・タイプ

ルート・ターゲット・タイプ。

oraEMNGEventTypeAttr9

1.3.6.1.4.1.111.15.3.1.1.69.1

ルール名

ルールの表示名

表A-6 コンプライアンス基準スコア・イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

ルート・コンプライアンス標準

ルート・コンプライアンス標準ノードの表示名。

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

ルート・コンプライアンス標準の作成者

ルート・コンプライアンス標準の作成者。

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

ルート・コンプライアンス標準のバージョン

ルート・コンプライアンス標準のバージョン。

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

コンプライアンス標準

コンプライアンス標準ノードの表示名。

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.3.1.1.65.1

コンプライアンス標準のバージョン

コンプライアンス標準のバージョン。

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.3.1.1.66.1

コンプライアンス標準の作成者

コンプライアンス標準の作成者。

oraEMNGEventTypeAttr7

1.3.6.1.4.1.111.15.3.1.1.67.1

ルート・ターゲット名

ルート・ターゲット名。

oraEMNGEventTypeAttr8

1.3.6.1.4.1.111.15.3.1.1.68.1

ルート・ターゲット・タイプ

ルート・ターゲット・タイプ。

oraEMNGEventTypeAttr10

1.3.6.1.4.1.111.15.3.1.1.70.1

警告のしきい値

コンプライアンス・スコアの警告のしきい値。

oraEMNGEventTypeAttr9

1.3.6.1.4.1.111.15.3.1.1.69.1

コンプライアンス・スコア

コンプライアンス・スコア。

oraEMNGEventTypeAttr11

1.3.6.1.4.1.111.15.3.1.1.71.1

クリティカルのしきい値

コンプライアンス・スコアのクリティカルのしきい値。

表A-7 メトリック・エラー・イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

メトリック・グループ

メトリックの名前。

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

収集名

メトリックを収集するコレクションの名前。

表A-8 メトリック拡張イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

メトリック拡張のバージョン属性

メトリック拡張のバージョン。

表A-9 自己更新イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

Type

Type

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

説明

説明

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

バージョン

バージョン

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

ステータス

ステータス

表A-10 サービス・レベル合意アラート・イベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

サービス・レベル合意名

サービス・レベル合意名

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

サービス・レベル目標値の名前

サービス・レベル目標値の名前

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.3.1.1.63.1

サービス・レベル目標値のタイプ

サービス・レベル目標値のタイプで、「パフォーマンス」または「可用性」のいずれか

oraEMNGEventTypeAttr4

1.3.6.1.4.1.111.15.3.1.1.64.1

起動済イベントの値

起動済イベントの値

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.3.1.1.65.1

お客様の名前

お客様の名前

表A-11 ユーザー報告のイベント・タイプ

変数名

OID番号

イベント・タイプ属性

説明

oraEMNGEventTypeAttr1

1.3.6.1.4.1.111.15.3.1.1.61.1

名前

問題の性質を説明している名前。

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.3.1.1.62.1

キー

このイベントの内容のターゲット内でサブコンポーネントを説明しているオプションのキー。

A.2 oraEM4AlertTable

oraEM4AlertTableは、メトリック重大度の警告とポリシー違反についてOracle Enterprise Managerから送信されるSNMPトラップを示します。

表A-12に、oraEM4AlertTableの各変数および対応するオブジェクトIDを示します。

表A-12 oraEM4AlertTable変数および対応するオブジェクトID

変数名

オブジェクトID

oraEM4AlertTargetName

1.3.6.1.4.1.111.15.1.1.1.2.1

oraEM4AlertTargetType

1.3.6.1.4.1.111.15.1.1.1.3.1

oraEM4AlertHostName

1.3.6.1.4.1.111.15.1.1.1.4.1

oraEM4AlertMetricName

1.3.6.1.4.1.111.15.1.1.1.5.1

oraEM4AlertKeyName

1.3.6.1.4.1.111.15.1.1.1.6.1

oraEM4AlertKeyValue

1.3.6.1.4.1.111.15.1.1.1.7.1

oraEM4AlertTimeStamp

1.3.6.1.4.1.111.15.1.1.1.8.1

oraEM4AlertSeverity

1.3.6.1.4.1.111.15.1.1.1.9.1

oraEM4AlertMessage

1.3.6.1.4.1.111.15.1.1.1.10.1

oraEM4AlertRuleName

1.3.6.1.4.1.111.15.1.1.1.11.1

oraEM4AlertRuleOwner

1.3.6.1.4.1.111.15.1.1.1.12.1

oraEM4AlertMetricValue

1.3.6.1.4.1.111.15.1.1.1.13.1

oraEM4AlertContext

1.3.6.1.4.1.111.15.1.1.1.14.1

oraEM4AlertCycleGuid

1.3.6.1.4.1.111.15.1.1.1.15.1

oraEM4AlertRepeatCount

1.3.6.1.4.1.111.15.1.1.1.16.1

oraEM4AlertUDTargetProperties

1.3.6.1.4.1.111.15.1.1.1.17.1

oraEM4AlertAck

1.3.6.1.4.1.111.15.1.1.1.18.1

oraEM4AlertAckBy

1.3.6.1.4.1.111.15.1.1.1.19.1

oraEM4AlertNotifType

1.3.6.1.4.1.111.15.1.1.1.20.1

oraEM4AlertViolationGuid

1.3.6.1.4.1.111.15.1.1.1.21.1

各変数の説明は次のとおりです。

A.2.1 oraEM4AlertTargetName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が適用されるターゲットの名前。

標準的な範囲

適用なし

重要度

高

A.2.2 oraEM4AlertTargetType

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が適用されるターゲットの種類。

標準的な範囲

適用なし

重要度

高

A.2.3 oraEM4AlertHostName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が発生したホストの名前。

標準的な範囲

適用なし

重要度

高

A.2.4 oraEM4AlertMetricName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告を生成したメトリックまたはポリシーの名前。

標準的な範囲

適用なし

重要度

高

A.2.5 oraEM4AlertKeyName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告を生成したメトリックのキー列(存在する場合)の名前。

標準的な範囲

適用なし

重要度

高

A.2.6 oraEM4AlertKeyValue

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告を生成したメトリックのキー列(存在する場合)の値。

標準的な範囲

適用なし

重要度

高

A.2.7 oraEM4AlertTimeStamp

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が生成された時刻。

標準的な範囲

適用なし

重要度

重要

A.2.8 oraEM4AlertSeverity

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

アラートの重大度(「クリア」、「情報」、「警告」、「クリティカル」、「使用不可の発生」、「ブラックアウト終了」、「ブラックアウト開始」、「メトリックエラーのクリア」、「メトリック・エラーの開始」、「ステータス保留」など)。

標準的な範囲

クリティカル、警告、消去

重要度

高

A.2.9 oraEM4AlertMessage

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

警告に関連したメッセージ。

標準的な範囲

適用なし

重要度

高

A.2.10 oraEM4AlertRuleName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この通知を発生した通知ルールの名前。

標準的な範囲

適用なし

重要度

重要

A.2.11 oraEM4AlertRuleOwner

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この通知を発生した通知ルールの所有者。

標準的な範囲

適用なし

重要度

重要

A.2.12 oraEM4AlertMetricValue

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告を生成したメトリックの値。

標準的な範囲

適用なし

重要度

重要

A.2.13 oraEM4AlertContext

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告を生成したメトリックに関連するメトリック列の名前と値のカンマ区切りリスト。

標準的な範囲

適用なし

重要度

重要

A.2.14 oraEM4AlertCycleGuid

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

アラートのライフサイクルに一意なEnterprise Managerが生成した識別子。

標準的な範囲

適用なし

重要度

重要

A.2.15 oraEM4AlertRepeatCount

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

アラートの繰返し通知カウンタ。

標準的な範囲

適用なし

重要度

重要

A.2.16 oraEM4AlertUDTargetProperties

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

ターゲットに関連付けられたユーザー定義のターゲット・プロパティ。

標準的な範囲

適用なし

重要度

重要

A.2.17 oraEM4AlertAck

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

このアラートに関連付けられた確認済ステータス・フラグ。1は確認済、0は未確認を示します。

標準的な範囲

適用なし

重要度

重要

A.2.18 oraEM4AlertAckBy

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

アラートに関連付けられた承認者の値。

標準的な範囲

適用なし

重要度

重要

A.2.19 oraEM4AlertNotifType

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

通知タイプ。

使用可能な値は次のとおりです。

- 1: 標準

- 4: 繰返し

- 9: 期間

標準的な範囲

適用なし

重要度

重要

A.2.20 oraEM4AlertViolationGuid

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

特定のアラートを識別するためにEnterprise Managerが生成した識別子。

標準的な範囲

適用なし

重要度

重要

A.3 oraEM4JobAlertTable

oraEM4JobAlertTableは、Oracle Enterprise Managerのジョブ・システムの一部として実行されているジョブまたは修正処理のステータスの変更を示します。

表A-13に、oraEM4JobAlertTableの各変数および対応するオブジェクトIDを示します。

表A-13 oraEM4JobAlertTable変数および対応するオブジェクトID

変数名

オブジェクトID

oraEM4JobAlertJobName

1.3.6.1.4.1.111.15.1.2.1.2.1

oraEM4JobAlertJobOwner

1.3.6.1.4.1.111.15.1.2.1.3.1

oraEM4JobAlertJobType

1.3.6.1.4.1.111.15.1.2.1.4.1

oraEM4JobAlertJobStatus

1.3.6.1.4.1.111.15.1.2.1.5.1

oraEM4JobAlertTargets

1.3.6.1.4.1.111.15.1.2.1.6.1

oraEM4JobAlertTimeStamp

1.3.6.1.4.1.111.15.1.2.1.7.1

oraEM4JobAlertRuleName

1.3.6.1.4.1.111.15.1.2.1.8.1

oraEM4JobAlertRuleOwner

1.3.6.1.4.1.111.15.1.2.1.9.1

oraEM4JobAlertMetricName

1.3.6.1.4.1.111.15.1.2.1.10.1

oraEM4JobAlertMetricValue

1.3.6.1.4.1.111.15.1.2.1.11.1

oraEM4JobAlertContext

1.3.6.1.4.1.111.15.1.2.1.12.1

oraEM4JobAlertKeyName

1.3.6.1.4.1.111.15.1.2.1.13.1

oraEM4JobAlertKeyValue

1.3.6.1.4.1.111.15.1.2.1.14.1

oraEM4JobAlertSeverity

1.3.6.1.4.1.111.15.1.2.1.15.1

oraEM4JobAlertJobId

1.3.6.1.4.1.111.15.1.2.1.16.1

oraEM4JobAlertJobExecId

1.3.6.1.4.1.111.15.1.2.1.17.1

各変数の説明は次のとおりです。

A.3.1 oraEM4JobAlertJobName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が適用されるジョブの名前。

標準的な範囲

適用なし

重要度

高

A.3.2 oraEM4JobAlertJobOwner

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が適用されるジョブの所有者。

標準的な範囲

適用なし

重要度

高

A.3.3 oraEM4JobAlertJobType

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が適用されるジョブの種類。

標準的な範囲

適用なし

重要度

重要

A.3.4 oraEM4JobAlertJobStatus

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が適用されるジョブのステータス。

標準的な範囲

適用なし

重要度

高

A.3.5 oraEM4JobAlertTargets

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が適用されるターゲットのカンマ区切りリスト。

標準的な範囲

適用なし

重要度

高

A.3.6 oraEM4JobAlertTimeStamp

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

ジョブ・ステータスが変更されてこの警告が発生した時刻。

標準的な範囲

適用なし

重要度

重要

A.3.7 oraEM4JobAlertRuleName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この通知を発生した通知ルールの名前。

標準的な範囲

適用なし

重要度

重要

A.3.8 oraEM4JobAlertRuleOwner

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この通知を発生した通知ルールの所有者。

標準的な範囲

適用なし

重要度

重要

A.3.9 oraEM4JobAlertMetricName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が生成された修正処理を実行したメトリックまたはポリシーの名前。

標準的な範囲

適用なし

重要度

高

A.3.10 oraEM4JobAlertMetricValue

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が生成された修正処理を実行したメトリックの値。

標準的な範囲

適用なし

重要度

重要

A.3.11 oraEM4JobAlertContext

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が生成された修正処理を実行したメトリックに関連するメトリック列の名前と値のカンマ区切りリスト。

標準的な範囲

適用なし

重要度

重要

A.3.12 oraEM4JobAlertKeyName

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が生成された修正処理を実行したメトリックのキー列(存在する場合)の名前。

標準的な範囲

適用なし

重要度

高

A.3.13 oraEM4JobAlertKeyValue

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が生成された修正処理を実行したメトリックのキー列(存在する場合)の値。

標準的な範囲

適用なし

重要度

高

A.3.14 oraEM4JobAlertSeverity

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この警告が生成された修正処理を実行したメトリックの重要度(「クリティカル」など)。

標準的な範囲

クリティカル、警告、消去

重要度

高

A.3.15 oraEM4JobAlertJobId

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この通知をトリガーしたEnterprise ManagerジョブのジョブID。

標準的な範囲

適用なし

重要度

高

A.3.16 oraEM4JobAlertJobExecId

構文

DisplayString

最大アクセス

読取り専用

ステータス

必須

説明

この通知をトリガーしたEnterprise Managerジョブの実行ID。

標準的な範囲

適用なし

重要度

高

B Enterprise Manager MIBの定義

次のMIB定義は、公開時点での最新バージョンです。Enterprise Manager 13c MIBの定義の最新バージョンについては、次の場所にあるインストールされているMIB定義ファイルを参照してください。

OMS_HOME/network/doc/omstrap.v1

B.1 MIB定義

ORACLE-ENTERPRISE-MANAGER-4-MIB DEFINITIONS ::= BEGIN

IMPORTS
TRAP-TYPE
FROM RFC-1215
DisplayString
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212
enterprises
FROM RFC1155-SMI;

oracle OBJECT IDENTIFIER ::= { enterprises  111 }

oraEM4 OBJECT IDENTIFIER ::= { oracle  15 }

oraEM4Objects OBJECT IDENTIFIER ::= { oraEM4  1 }

oraEM4AlertTable OBJECT-TYPE
SYNTAX  SEQUENCE OF OraEM4AlertEntry
ACCESS  not-accessible
STATUS  mandatory
DESCRIPTION
"Information on alerts generated by Oracle Enterprise Manager. This table is not queryable; it exists only to document the variables included in the oraEM4Alert trap.  Each trap contains a single instance of each variable in the table."
::= { oraEM4Objects  1 }

oraEM4AlertEntry OBJECT-TYPE
SYNTAX  OraEM4AlertEntry
ACCESS  not-accessible
STATUS  mandatory
DESCRIPTION
"Information about a particular Oracle Enterprise Manager alert."
INDEX   { oraEM4AlertIndex }
::= { oraEM4AlertTable  1 }

OraEM4AlertEntry ::=
SEQUENCE {
oraEM4AlertIndex
INTEGER,

oraEM4AlertTargetName
DisplayString,

oraEM4AlertTargetType
DisplayString,

oraEM4AlertHostName
DisplayString,

oraEM4AlertMetricName
DisplayString,

oraEM4AlertKeyName
DisplayString,

oraEM4AlertKeyValue
DisplayString,

oraEM4AlertTimeStamp
DisplayString,

oraEM4AlertSeverity
DisplayString,

oraEM4AlertMessage
DisplayString,

oraEM4AlertRuleName
DisplayString,

oraEM4AlertRuleOwner
DisplayString,

oraEM4AlertMetricValue
DisplayString,

oraEM4AlertContext
DisplayString,

oraEM4AlertCycleGuid
DisplayString,

oraEM4AlertRepeatCount
DisplayString,

oraEM4AlertUDTargetProperties
DisplayString,

oraEM4AlertAck
DisplayString,

oraEM4AlertAckBy
DisplayString,

oraEM4AlertNotifType
DisplayString,

oraEM4AlertViolationGuid
DisplayString
}

oraEM4AlertIndex OBJECT-TYPE
SYNTAX  INTEGER (0..2147483647)
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Index of a particular alert, unique only at the moment an alert is generated."
::= { oraEM4AlertEntry  1 }

oraEM4AlertTargetName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the target to which this alert applies."
::= { oraEM4AlertEntry  2 }

oraEM4AlertTargetType OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The type of the target to which this alert applies."
::= { oraEM4AlertEntry  3 }

oraEM4AlertHostName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the host on which this alert originated."
::= { oraEM4AlertEntry  4 }

oraEM4AlertMetricName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the metric or policy which generated this alert."
::= { oraEM4AlertEntry  5 }

oraEM4AlertKeyName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the key-column, if present, for the metric which generated this alert."
::= { oraEM4AlertEntry  6 }

oraEM4AlertKeyValue OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The value of the key-column, if present, for the metric which generated this alert."
::= { oraEM4AlertEntry  7 }

oraEM4AlertTimeStamp OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The time at which this alert was generated."
::= { oraEM4AlertEntry  8 }

oraEM4AlertSeverity OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The severity of the alert e.g. Clear, Informational, Warning, Critical, Unreachable Clear, Unreachable Start, Blackout End, Blackout Start, Metric Error Clear, Metric Error Start, Status Pending."
::= { oraEM4AlertEntry  9 }

oraEM4AlertMessage OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The message associated with the alert."
::= { oraEM4AlertEntry  10 }

oraEM4AlertRuleName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the notification rule that caused this notification."
::= { oraEM4AlertEntry  11 }

oraEM4AlertRuleOwner OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The owner of the notification rule that caused this notification."
::= { oraEM4AlertEntry  12 }

oraEM4AlertMetricValue OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The value of the metric which caused this alert to be generated."
::= { oraEM4AlertEntry  13 }

oraEM4AlertContext OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"A comma separated list of metric column names and values associated with the metric that caused this alert to be generated."
::= { oraEM4AlertEntry  14 }

oraEM4AlertCycleGuid OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"An EM generated identifier that is unique for the lifecyle of an alert."
::= { oraEM4AlertEntry  15 }

oraEM4AlertRepeatCount OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The repeat notification counter for the alert."
::= { oraEM4AlertEntry  16 }

oraEM4AlertUDTargetProperties OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"User-defined target properties associated with the target."
::= { oraEM4AlertEntry  17 }

oraEM4AlertAck OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Acknowledged status flag associated with the alert. 1 indicates acknowledged, 0 indicates unacknowledged."
::= { oraEM4AlertEntry  18 }

oraEM4AlertAckBy OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Acknowledged By value  associated with the alert."
::= { oraEM4AlertEntry  19 }

oraEM4AlertNotifType OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Notification Type. 1 - Normal, 4 - Repeat, 9 - Duration"
::= { oraEM4AlertEntry  20 }

oraEM4AlertViolationGuid OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"An EM generated identifier that identifies a particular alert."
::= { oraEM4AlertEntry  21 }

oraEM4Traps OBJECT IDENTIFIER ::= { oraEM4  2 }

oraEM4Alert TRAP-TYPE
ENTERPRISE  oraEM4Traps
VARIABLES   { oraEM4AlertTargetName, oraEM4AlertTargetType,
oraEM4AlertHostName, oraEM4AlertMetricName,
oraEM4AlertKeyName, oraEM4AlertKeyValue, oraEM4AlertTimeStamp,
oraEM4AlertSeverity, oraEM4AlertMessage,
oraEM4AlertRuleName, oraEM4AlertRuleOwner,
oraEM4AlertMetricValue, oraEM4AlertContext, oraEM4AlertCycleGuid,
oraEM4AlertRepeatCount,
oraEM4AlertUDTargetProperties, oraEM4AlertAck, oraEM4AlertAckBy,
oraEM4AlertNotifType, oraEM4AlertViolationGuid }
DESCRIPTION
"The variables included in the oraEM4Alert trap."
::= 1

oraEM4JobAlertTable OBJECT-TYPE
SYNTAX  SEQUENCE OF OraEM4JobAlertEntry
ACCESS  not-accessible
STATUS  mandatory
DESCRIPTION
"Information on alerts generated by Oracle Enterprise Manager. This table is not queryable; it exists only to document the variables included in the oraEM4JobAlert trap.  Each trap contains a single instance of each variable in the table."
::= { oraEM4Objects  2 }

oraEM4JobAlertEntry OBJECT-TYPE
SYNTAX  OraEM4JobAlertEntry
ACCESS  not-accessible
STATUS  mandatory
DESCRIPTION
"Information about a particular Oracle Enterprise Manager alert."
INDEX   { oraEM4JobAlertIndex }
::= { oraEM4JobAlertTable  1 }

OraEM4JobAlertEntry ::=
SEQUENCE {
oraEM4JobAlertIndex
INTEGER,

oraEM4JobAlertJobName
DisplayString,

oraEM4JobAlertJobOwner
DisplayString,

oraEM4JobAlertJobType
DisplayString,

oraEM4JobAlertJobStatus
DisplayString,

oraEM4JobAlertTargets
DisplayString,

oraEM4JobAlertTimeStamp
DisplayString,

oraEM4JobAlertRuleName
DisplayString,

oraEM4JobAlertRuleOwner
DisplayString,

oraEM4JobAlertMetricName
DisplayString,

oraEM4JobAlertMetricValue
DisplayString,

oraEM4JobAlertContext
DisplayString,

oraEM4JobAlertKeyName
DisplayString,

oraEM4JobAlertKeyValue
DisplayString,

oraEM4JobAlertSeverity
DisplayString,

oraEM4JobAlertJobId
DisplayString,

oraEM4JobAlertJobExecId
DisplayString
}

oraEM4JobAlertIndex OBJECT-TYPE
SYNTAX  INTEGER (0..2147483647)
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Index of a particular alert, unique only at the moment an alert is generated."
::= { oraEM4JobAlertEntry  1 }

oraEM4JobAlertJobName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the job to which this alert applies."
::= { oraEM4JobAlertEntry  2 }

oraEM4JobAlertJobOwner OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The owner of the job to which this alert applies."
::= { oraEM4JobAlertEntry  3 }

oraEM4JobAlertJobType OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The type of the job to which this alert applies."
::= { oraEM4JobAlertEntry  4 }

oraEM4JobAlertJobStatus OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The status of the job to which this alert applies."
::= { oraEM4JobAlertEntry  5 }

oraEM4JobAlertTargets OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"A comma separated list of target to which this alert applies."
::= { oraEM4JobAlertEntry  6 }

oraEM4JobAlertTimeStamp OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The time at which this job status changed causing this alert."
::= { oraEM4JobAlertEntry  7 }

oraEM4JobAlertRuleName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the notification rule that caused this notification."
::= { oraEM4JobAlertEntry  8 }

oraEM4JobAlertRuleOwner OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The owner of the notification rule that caused this notification."
::= { oraEM4JobAlertEntry  9 }

oraEM4JobAlertMetricName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the metric or policy which caused the Corrective Action to run that caused this alert."
::= { oraEM4JobAlertEntry  10 }

oraEM4JobAlertMetricValue OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The value of the metric which caused the Corrective Action to run that caused this alert."
::= { oraEM4JobAlertEntry  11 }

oraEM4JobAlertContext OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"A comma separated list of metric column names and values associated with the metric which caused the Corrective Action to run that caused this alert."
::= { oraEM4JobAlertEntry  12 }

oraEM4JobAlertKeyName OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the key-column, if present, for the metric which caused the Corrective Action to run that generated this alert."
::= { oraEM4JobAlertEntry  13 }

oraEM4JobAlertKeyValue OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The value of the key-column, if present, for the metric which caused the Corrective Action to run that generated this alert."
::= { oraEM4JobAlertEntry  14 }

oraEM4JobAlertSeverity OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The severity of the metric which caused the Corrective Action to run that generated this alert e.g. Critical."
::= { oraEM4JobAlertEntry  15 }

oraEM4JobAlertJobId OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The Job Id of the EM Job that triggered this notification."
::= { oraEM4JobAlertEntry  16 }

oraEM4JobAlertJobExecId OBJECT-TYPE
SYNTAX  DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The Job Execution Id of the EM Job that triggered this notification."
::= { oraEM4JobAlertEntry  17 }

oraEM4JobAlert TRAP-TYPE
ENTERPRISE  oraEM4Traps
VARIABLES   { oraEM4JobAlertJobName, oraEM4JobAlertJobOwner,
oraEM4JobAlertJobType, oraEM4JobAlertJobStatus,
oraEM4JobAlertTargets, oraEM4JobAlertTimeStamp,
oraEM4JobAlertRuleName, oraEM4JobAlertRuleOwner,
oraEM4JobAlertMetricName, oraEM4JobAlertMetricValue,
oraEM4JobAlertContext, oraEM4JobAlertKeyName,
oraEM4JobAlertKeyValue, oraEM4JobAlertSeverity,
oraEM4JobAlertJobId, oraEM4JobAlertJobExecId }
DESCRIPTION
"The variables included in the oraEM4JobAlert trap."
::= 2

oraEMNGObjects OBJECT IDENTIFIER ::= { oraEM4  3 }

oraEMNGEventTable OBJECT-TYPE
SYNTAX  SEQUENCE OF OraEMNGEventEntry
ACCESS  not-accessible
STATUS  mandatory
DESCRIPTION
"Information on events published to Oracle Enterprise Manager. This table is not queryable; it exists only to document the variables included in the oraEMNGEventTrap trap.  Each trap can contain a single instance of each variable in the table."
::= { oraEMNGObjects  1 }

oraEMNGEventEntry OBJECT-TYPE
SYNTAX  OraEMNGEventEntry
ACCESS  not-accessible
STATUS  mandatory
DESCRIPTION
"Information about a particular Oracle Enterprise Manager event."
INDEX   { oraEMNGEventIndex }
::= { oraEMNGEventTable  1 }

OraEMNGEventEntry ::=
SEQUENCE {
oraEMNGEventIndex
INTEGER,

oraEMNGEventNotifType
DisplayString,

oraEMNGEventMessage
DisplayString,

oraEMNGEventMessageURL
DisplayString,

oraEMNGEventSeverity
DisplayString,

oraEMNGEventSeverityCode
DisplayString,

oraEMNGEventRepeatCount
DisplayString,

oraEMNGEventActionMsg
DisplayString,

oraEMNGEventOccurrenceTime
DisplayString,

oraEMNGEventReportedTime
DisplayString,

oraEMNGEventCategories
DisplayString,

oraEMNGEventCategoryCodes
DisplayString,

oraEMNGEventType
DisplayString,

oraEMNGEventName
DisplayString,

oraEMNGAssocIncidentId
DisplayString,

oraEMNGAssocIncidentOwner
DisplayString,

oraEMNGAssocIncidentAcked
DisplayString,

oraEMNGAssocIncidentStatus
DisplayString,

oraEMNGAssocIncidentPriority
DisplayString,

oraEMNGAssocIncidentEscLevel
DisplayString,

oraEMNGEventTargetName
DisplayString,

oraEMNGEventTargetNameURL
DisplayString,

oraEMNGEventTargetType
DisplayString,

oraEMNGEventHostName
DisplayString,

oraEMNGEventTargetOwner
DisplayString,

oraEMNGEventTgtLifeCycleStatus
DisplayString,

oraEMNGEventTargetVersion
DisplayString,

oraEMNGEventUserDefinedTgtProp
DisplayString,

oraEMNGEventSourceObjName
DisplayString,

oraEMNGEventSourceObjNameURL
DisplayString,

oraEMNGEventSourceObjType
DisplayString,

oraEMNGEventSourceObjSubType
DisplayString,

oraEMNGEventSourceObjOwner
DisplayString,

oraEMNGEventCAJobName
DisplayString,

oraEMNGEventCAJobStatus
DisplayString,

oraEMNGEventCAJobOwner
DisplayString,

oraEMNGEventCAJobStepOutput
DisplayString,

oraEMNGEventCAJobType
DisplayString,

oraEMNGEventRuleSetName
DisplayString,

oraEMNGEventRuleName
DisplayString,

oraEMNGEventRuleOwner
DisplayString,

oraEMNGEventSequenceId
DisplayString,

oraEMNGEventRCADetails
DisplayString,

oraEMNGEventContextAttrs
DisplayString,

oraEMNGEventUserComments
DisplayString,

oraEMNGEventUpdates
DisplayString,

oraEMNGEventTotalOccurrenceCount
DisplayString,

oraEMNGEventCurrOccurrenceCount
DisplayString,

oraEMNGEventCurrFirstOccurDate
DisplayString,

oraEMNGEventCurrLastOccurDate
DisplayString,

oraEMNGEventRCAStatus
DisplayString,

oraEMNGEventReportedState
DisplayString,

oraEMNGEventTypeAttr1
DisplayString,

oraEMNGEventTypeAttr2
DisplayString,

oraEMNGEventTypeAttr3
DisplayString,

oraEMNGEventTypeAttr4
DisplayString,

oraEMNGEventTypeAttr5
DisplayString,

oraEMNGEventTypeAttr6
DisplayString,

oraEMNGEventTypeAttr7
DisplayString,

oraEMNGEventTypeAttr8
DisplayString,

oraEMNGEventTypeAttr9
DisplayString,

oraEMNGEventTypeAttr10
DisplayString,

oraEMNGEventTypeAttr11
DisplayString,

oraEMNGEventTypeAttr12
DisplayString,

oraEMNGEventTypeAttr13
DisplayString,

oraEMNGEventTypeAttr14
DisplayString,

oraEMNGEventTypeAttr15
DisplayString,

oraEMNGEventTypeAttr16
DisplayString,

oraEMNGEventTypeAttr17
DisplayString,

oraEMNGEventTypeAttr18
DisplayString,

oraEMNGEventTypeAttr19
DisplayString,

oraEMNGEventTypeAttr20
DisplayString,

oraEMNGEventTypeAttr21
DisplayString,

oraEMNGEventTypeAttr22
DisplayString,

oraEMNGEventTypeAttr23
DisplayString,

oraEMNGEventTypeAttr24
DisplayString,

oraEMNGEventTypeAttr25
DisplayString
}

oraEMNGEventIndex OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Index of a particular event, unique only at the moment an event is generated."
::= { oraEMNGEventEntry  1 }

oraEMNGEventNotifType  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Notification Type. NOTIF_NORMAL, NOTIF_RETRY, NOTIF_DURATION, NOTIF_REPEAT, NOTIF_CA, NOTIF_RCA"
::= { oraEMNGEventEntry  2 }

oraEMNGEventMessage  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The message associated with this event."
::= { oraEMNGEventEntry  3 }

oraEMNGEventMessageURL  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"EM Console URL for the event message. Populated for events with severity other than INFORMATIONAL. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  4 }

oraEMNGEventSeverity  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The severity of the event e.g. Fatal, Critical, Warning, Advisory, Information, Clear."
::= { oraEMNGEventEntry  5 }

oraEMNGEventSeverityCode  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Internal code of the severity: FATAL, CRITICAL, WARNING, ADVISORY, INFORMATIONAL, CLEAR."
::= { oraEMNGEventEntry  6 }

oraEMNGEventRepeatCount  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The repeat notification counter for the event."
::= { oraEMNGEventEntry  7 }

oraEMNGEventActionMsg  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The action message for this event."
::= { oraEMNGEventEntry  8 }

oraEMNGEventOccurrenceTime  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The time when this event occurred (optional), this is only populated for events that have occurrence time."
::= { oraEMNGEventEntry  9 }

oraEMNGEventReportedTime  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The time when this event was reported."
::= { oraEMNGEventEntry  10 }

oraEMNGEventCategories  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The list of categories to which this event belongs to. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  11 }

oraEMNGEventCategoryCodes  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The list of internal category codes to which this event belongs to. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  12 }

oraEMNGEventType  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the event type to which this event belongs to."
::= { oraEMNGEventEntry  13 }

oraEMNGEventName  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of this event."
::= { oraEMNGEventEntry  14 }

oraEMNGAssocIncidentId  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"ID of the associated incident with the event (optional)."
::= { oraEMNGEventEntry  15 }

oraEMNGAssocIncidentOwner  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Owner of the associated incident with the event (optional)."
::= { oraEMNGEventEntry  16 }

oraEMNGAssocIncidentAcked  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Acknowledged status of the associated incident with the event. 1 indicates acknowledged, 0 indicates unacknowledged."
::= { oraEMNGEventEntry  17 }

oraEMNGAssocIncidentStatus  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The status of the associated incident with the event."
::= { oraEMNGEventEntry  18 }

oraEMNGAssocIncidentPriority  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The proirity of the associated incident with the event."
::= { oraEMNGEventEntry  19 }

oraEMNGAssocIncidentEscLevel  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The Escalation Level of the associated incident with the event."
::= { oraEMNGEventEntry  20 }

oraEMNGEventTargetName  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the target to which this event applies. Populated for events that are about a target only."
::= { oraEMNGEventEntry  21 }

oraEMNGEventTargetNameURL  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"EM Console URL of the target to which this event applies. Populated for events that are about a target only. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  22 }

oraEMNGEventTargetType  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The type of the target to which this event applies. Populated for events that are about a target only."
::= { oraEMNGEventEntry  23 }

oraEMNGEventHostName  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the host on which this event originated. Populated for events that are about a target only."
::= { oraEMNGEventEntry  24 }

oraEMNGEventTargetOwner  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The primary administrator of the target on which this event originated. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  25 }

oraEMNGEventTgtLifeCycleStatus  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The life cycle status of the target on which this event originated."
::= { oraEMNGEventEntry  26 }

oraEMNGEventTargetVersion  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The version of the target on which this event originated."
::= { oraEMNGEventEntry  27 }

oraEMNGEventUserDefinedTgtProp  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The user defined target properties [name,value pair list] of the associated target with this event. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  28 }

oraEMNGEventSourceObjName  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the source object to which this event belongs to. Populated for events that are about a non-target object only, such as Job."
::= { oraEMNGEventEntry  29 }

oraEMNGEventSourceObjNameURL  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"EM Console URL for the source object to which this event belongs to. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  30 }

oraEMNGEventSourceObjType  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The type of the source object to which this event belongs to."
::= { oraEMNGEventEntry  31 }

oraEMNGEventSourceObjSubType  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The sub type of the source object to which this event belongs to (Optional property). Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  32 }

oraEMNGEventSourceObjOwner  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The primary adminstrator of the source object to which this event belongs to. (Optional property). Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  33 }

oraEMNGEventCAJobName  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The Name of the Corrective Action Job associated with this event."
::= { oraEMNGEventEntry  34 }

oraEMNGEventCAJobStatus  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The Status of the Corrective Action Job associated with this event."
::= { oraEMNGEventEntry  35 }

oraEMNGEventCAJobOwner  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The Owner of the Corrective Action Job associated with this event."
::= { oraEMNGEventEntry  36 }

oraEMNGEventCAJobStepOutput  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The job step output from the Corrective Action Job associated with this event."
::= { oraEMNGEventEntry  37 }

oraEMNGEventCAJobType  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The job type from the Corrective Action Job associated with this event."
::= { oraEMNGEventEntry  38 }

oraEMNGEventRuleSetName  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the ruleset that caused this notification. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  39 }

oraEMNGEventRuleName  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The name of the rule within the ruleset that caused this notification."
::= { oraEMNGEventEntry  40 }

oraEMNGEventRuleOwner  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The owner of the ruleset that caused this notification."
::= { oraEMNGEventEntry  41 }

oraEMNGEventSequenceId  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"An EM generated identifier that uniquely identifies current issue until it is cleared."
::= { oraEMNGEventEntry  42 }

oraEMNGEventRCADetails  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Root Cause Analysis details associated with this event if it exists."
::= { oraEMNGEventEntry  43 }

oraEMNGEventContextAttrs  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The context attributes associated with this event. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  44 }

oraEMNGEventUserComments  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The user comments associated with this event. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  45 }

oraEMNGEventUpdates  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"The updates associated with this event. Empty if trap size exceeds configured snmp packet size."
::= { oraEMNGEventEntry  46 }

oraEMNGEventTotalOccurrenceCount  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Total number of occurrences of the same event on a target across all open deduplicated events. This attribute applies only to deduplicated events."
::= { oraEMNGEventEntry  47 }

oraEMNGEventCurrOccurrenceCount  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Total occurrences of the event in this collection period. This attribute applies only to deduplicated events."
::= { oraEMNGEventEntry  48 }

oraEMNGEventCurrFirstOccurDate  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Timestamp when the event first occurred in this collection period. This attribute applies only to deduplicated events."
::= { oraEMNGEventEntry  49 }

oraEMNGEventCurrLastOccurDate  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Timestamp when the event last occurred in this collection period. This attribute applies only to deduplicated events."
::= { oraEMNGEventEntry  50 }

oraEMNGEventRCAStatus  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Summary of Root Cause Analysis, if applicable."
::= { oraEMNGEventEntry  51 }

oraEMNGEventReportedState  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"This is an optional value reporting the latest state of an entity and is only applicable for events that are representing a state transition for a given entity. For example, for Target availability and Job state change events, this value would be the latest state of the target or job, respectively."
::= { oraEMNGEventEntry  52 }

oraEMNGEventTypeAttr1  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#1."
::= { oraEMNGEventEntry  61 }

oraEMNGEventTypeAttr2  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#2."
::= { oraEMNGEventEntry  62 }

oraEMNGEventTypeAttr3  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#3."
::= { oraEMNGEventEntry  63 }

oraEMNGEventTypeAttr4  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#4."
::= { oraEMNGEventEntry  64 }

oraEMNGEventTypeAttr5  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#5."
::= { oraEMNGEventEntry  65 }

oraEMNGEventTypeAttr6  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#6."
::= { oraEMNGEventEntry  66 }

oraEMNGEventTypeAttr7  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#7."
::= { oraEMNGEventEntry  67 }

oraEMNGEventTypeAttr8  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#8."
::= { oraEMNGEventEntry  68 }

oraEMNGEventTypeAttr9  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#9."
::= { oraEMNGEventEntry  69 }

oraEMNGEventTypeAttr10  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#10."
::= { oraEMNGEventEntry  70 }

oraEMNGEventTypeAttr11  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#11."
::= { oraEMNGEventEntry  71 }

oraEMNGEventTypeAttr12  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#12."
::= { oraEMNGEventEntry  72 }

oraEMNGEventTypeAttr13  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#13."
::= { oraEMNGEventEntry  73 }

oraEMNGEventTypeAttr14  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#14."
::= { oraEMNGEventEntry  74 }

oraEMNGEventTypeAttr15  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#15."
::= { oraEMNGEventEntry  75 }

oraEMNGEventTypeAttr16  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#16."
::= { oraEMNGEventEntry  76 }

oraEMNGEventTypeAttr17  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#17."
::= { oraEMNGEventEntry  77 }

oraEMNGEventTypeAttr18  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#18."
::= { oraEMNGEventEntry  78 }

oraEMNGEventTypeAttr19  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#19."
::= { oraEMNGEventEntry  79 }

oraEMNGEventTypeAttr20  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#20."
::= { oraEMNGEventEntry  80 }

oraEMNGEventTypeAttr21  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#21."
::= { oraEMNGEventEntry  81 }

oraEMNGEventTypeAttr22  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#22."
::= { oraEMNGEventEntry  82 }

oraEMNGEventTypeAttr23  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#23."
::= { oraEMNGEventEntry  83 }

oraEMNGEventTypeAttr24  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#24."
::= { oraEMNGEventEntry  84 }

oraEMNGEventTypeAttr25  OBJECT-TYPE
SYNTAX DisplayString
ACCESS  read-only
STATUS  mandatory
DESCRIPTION
"Name and value pair as name=value for event type specific attribute#25."
::= { oraEMNGEventEntry  85 }

oraEMNGEvent TRAP-TYPE
ENTERPRISE  oraEM4Traps
VARIABLES   {
oraEMNGEventNotifType,
oraEMNGEventMessage, oraEMNGEventMessageURL,
oraEMNGEventSeverity, oraEMNGEventSeverityCode,
oraEMNGEventRepeatCount, oraEMNGEventActionMsg,
oraEMNGEventOccurrenceTime, oraEMNGEventReportedTime,
oraEMNGEventCategories, oraEMNGEventCategoryCodes,
oraEMNGEventType, oraEMNGEventName,
oraEMNGAssocIncidentId, oraEMNGAssocIncidentOwner,
oraEMNGAssocIncidentAcked, oraEMNGAssocIncidentStatus,
oraEMNGAssocIncidentPriority, oraEMNGAssocIncidentEscLevel,
oraEMNGEventTargetName, oraEMNGEventTargetNameURL,
oraEMNGEventTargetType, oraEMNGEventHostName,
oraEMNGEventTargetOwner, oraEMNGEventTgtLifeCycleStatus,
oraEMNGEventTargetVersion, oraEMNGEventUserDefinedTgtProp,
oraEMNGEventSourceObjName, oraEMNGEventSourceObjNameURL,
oraEMNGEventSourceObjType, oraEMNGEventSourceObjSubType,
oraEMNGEventSourceObjOwner, oraEMNGEventCAJobName,
oraEMNGEventCAJobStatus, oraEMNGEventCAJobOwner,
oraEMNGEventCAJobStepOutput, oraEMNGEventCAJobType,
oraEMNGEventRuleSetName, oraEMNGEventRuleName,
oraEMNGEventRuleOwner, oraEMNGEventSequenceId,
oraEMNGEventRCADetails, oraEMNGEventContextAttrs,
oraEMNGEventUserComments, oraEMNGEventUpdates,
oraEMNGEventTotalOccurrenceCount, oraEMNGEventCurrOccurrenceCount,
oraEMNGEventCurrFirstOccurDate, oraEMNGEventCurrLastOccurDate,
oraEMNGEventRCAStatus,
oraEMNGEventTypeAttr1, oraEMNGEventTypeAttr2,
oraEMNGEventTypeAttr3, oraEMNGEventTypeAttr4,
oraEMNGEventTypeAttr5, oraEMNGEventTypeAttr6,
oraEMNGEventTypeAttr7, oraEMNGEventTypeAttr8,
oraEMNGEventTypeAttr9, oraEMNGEventTypeAttr10,
oraEMNGEventTypeAttr11, oraEMNGEventTypeAttr12,
oraEMNGEventTypeAttr13, oraEMNGEventTypeAttr14,
oraEMNGEventTypeAttr15, oraEMNGEventTypeAttr16,
oraEMNGEventTypeAttr17, oraEMNGEventTypeAttr18,
oraEMNGEventTypeAttr19, oraEMNGEventTypeAttr20,
oraEMNGEventTypeAttr21, oraEMNGEventTypeAttr22,
oraEMNGEventTypeAttr23, oraEMNGEventTypeAttr24,
oraEMNGEventTypeAttr25,
oraEMNGEventReportedState
}
DESCRIPTION
"The variables included in the oraEMNGAlert trap."
::= 3

END

C SNMPトラップのマッピング

次の表は、Enterprise Manager 12c以降とそれ以前のリリース間のSNMPトラップのマッピングを示しています。

C.1 12c以前のEnterprise Managerメトリック・アラート

Enterprise Manager 12cより前のリリースでは、メトリック・アラートはoraEM4Alertトラップ・タイプを使用して送信されていました。Enterprise Manager 12c以降では、これらのアラートに対応するイベント・タイプはメトリック・アラートです。Enterprise Manager 12cまたは13cのSNMPトラップのoraEMNGEventTypeの値は、「Metric Alert」に設定されます。

表C-1 メトリック・アラートのマッピング

12C以前のOID番号

12C以前のOID名

12C以降のOID番号

12C以降のOID名

1.3.6.1.4.1.111.15.1.1.1.2.1

oraEM4AlertTargetName

1.3.6.1.4.1.111.15.3.1.1.21.1

oraEMNGEventTargetName

1.3.6.1.4.1.111.15.1.1.1.3.1

oraEM4AlertTargetType

1.3.6.1.4.1.111.15.3.1.1.23.1

oraEMNGEventTargetType

1.3.6.1.4.1.111.15.1.1.1.4.1

oraEM4AlertHostName

1.3.6.1.4.1.111.15.3.1.1.24.1

oraEMNGEventHostName

1.3.6.1.4.1.111.15.1.1.1.5.1

oraEM4AlertMetricName

1.3.6.1.4.1.111.15.3.1.1.65.1

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.1.1.1.6.1

oraEM4AlertKeyName

1.3.6.1.4.1.111.15.3.1.1.66.1

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.1.1.1.7.1

oraEM4AlertKeyValue

* 詳細は、後述する注意を参照してください。

* 詳細は、後述する注意を参照してください。

1.3.6.1.4.1.111.15.1.1.1.8.1

oraEM4AlertTimeStamp

1.3.6.1.4.1.111.15.3.1.1.10.1

oraEMNGEventReportedTime

1.3.6.1.4.1.111.15.1.1.1.9.1

oraEM4AlertSeverity

1.3.6.1.4.1.111.15.3.1.1.5.1

oraEMNGEventSeverity

1.3.6.1.4.1.111.15.1.1.1.10.1

oraEM4AlertMessage

1.3.6.1.4.1.111.15.3.1.1.3.1

oraEMNGEventMessage

1.3.6.1.4.1.111.15.1.1.1.11.1

oraEM4AlertRuleName

1.3.6.1.4.1.111.15.3.1.1.39.1

oraEMNGEventRuleSetName

1.3.6.1.4.1.111.15.1.1.1.12.1

oraEM4AlertRuleOwner

1.3.6.1.4.1.111.15.3.1.1.41.1

oraEMNGEventRuleOwner

1.3.6.1.4.1.111.15.1.1.1.13.1

oraEM4AlertMetricValue

1.3.6.1.4.1.111.15.3.1.1.68.1

oraEMNGEventTypeAttr8

1.3.6.1.4.1.111.15.1.1.1.14.1

oraEM4AlertContext

1.3.6.1.4.1.111.15.3.1.1.44.1

oraEMNGEventContextAttrs

1.3.6.1.4.1.111.15.1.1.1.15.1

oraEM4AlertCycleGuid

1.3.6.1.4.1.111.15.3.1.1.70.1

oraEMNGEventTypeAttr3

1.3.6.1.4.1.111.15.1.1.1.16.1

oraEM4AlertRepeatCount

1.3.6.1.4.1.111.15.3.1.1.7.1

oraEMNGEventRepeatCount

1.3.6.1.4.1.111.15.1.1.1.17.1

oraEM4AlertUDTargetProperties

1.3.6.1.4.1.111.15.3.1.1.28.1

oraEMNGEventUserDefinedTgtProp

1.3.6.1.4.1.111.15.1.1.1.18.1

oraEM4AlertAck

1.3.6.1.4.1.111.15.3.1.1.17.1

oraEMNGAssocIncidentAcked

1.3.6.1.4.1.111.15.1.1.1.19.1

oraEM4AlertAckBy

1.3.6.1.4.1.111.15.3.1.1.16.1

oraEMNGAssocIncidentOwner

1.3.6.1.4.1.111.15.1.1.1.20.1

oraEM4AlertNotifType

1.3.6.1.4.1.111.15.3.1.1.2.1

oraEMNGEventNotifType

1.3.6.1.4.1.111.15.1.1.1.21.1

oraEM4AlertViolationGuid

1.3.6.1.4.1.111.15.3.1.1.42.1

oraEMNGEventSequenceId

C.2 12C以前のターゲットの可用性アラート

Enterprise Manager 12cより前のリリースでは、ターゲットの可用性アラートはoraEM4Alert SNMPトラップ・タイプを使用して送信されていました。Enterprise Manager 12c以降では、これらのアラートに対応するイベント・タイプはtarget_availabilityです。Enterprise Manager 12cまたは13cのトラップのoraEMNGEventTypeの値は、「Target Availability」に設定されます。

表C-2 ターゲットの可用性アラートのマッピング

12C以前のOID番号

12C以前のOID名

12C以降のOID番号

12C以降のOID名

1.3.6.1.4.1.111.15.1.1.1.2.1

oraEM4AlertTargetName

1.3.6.1.4.1.111.15.3.1.1.21.1

oraEMNGEventTargetName

1.3.6.1.4.1.111.15.1.1.1.3.1

oraEM4AlertTargetType

1.3.6.1.4.1.111.15.3.1.1.23.1

oraEMNGEventTargetType

1.3.6.1.4.1.111.15.1.1.1.4.1

oraEM4AlertHostName

1.3.6.1.4.1.111.15.3.1.1.24.1

oraEMNGEventHostName

1.3.6.1.4.1.111.15.1.1.1.5.1

oraEM4AlertMetricName

なし

なし

1.3.6.1.4.1.111.15.1.1.1.6.1

oraEM4AlertKeyName

// 12Cでは非推奨、11GCでは常にnull

// 12Cでは非推奨、11GCでは常にnull

1.3.6.1.4.1.111.15.1.1.1.7.1

oraEM4AlertKeyValue

なし

なし

1.3.6.1.4.1.111.15.1.1.1.8.1

oraEM4AlertTimeStamp

1.3.6.1.4.1.111.15.3.1.1.10.1

oraEMNGEventReportedTime

1.3.6.1.4.1.111.15.1.1.1.9.1

oraEM4AlertSeverity

1.3.6.1.4.1.111.15.3.1.1.61.1

oraEMNGEventTypeAttr1 //target_status

1.3.6.1.4.1.111.15.1.1.1.10.1

oraEM4AlertMessage

1.3.6.1.4.1.111.15.3.1.1.3.1

oraEMNGEventMessage

1.3.6.1.4.1.111.15.1.1.1.11.1

oraEM4AlertRuleName

1.3.6.1.4.1.111.15.3.1.1.39.1

oraEMNGEventRuleSetName

1.3.6.1.4.1.111.15.1.1.1.12.1

oraEM4AlertRuleOwner

1.3.6.1.4.1.111.15.3.1.1.41.1

oraEMNGEventRuleOwner

1.3.6.1.4.1.111.15.1.1.1.13.1

oraEM4AlertMetricValue

なし

なし

1.3.6.1.4.1.111.15.1.1.1.14.1

oraEM4AlertContext

1.3.6.1.4.1.111.15.3.1.1.44.1

oraEMNGEventContextAttrs

1.3.6.1.4.1.111.15.1.1.1.15.1

oraEM4AlertCycleGuid

1.3.6.1.4.1.111.15.3.1.1.66.1

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.1.1.1.16.1

oraEM4AlertRepeatCount

1.3.6.1.4.1.111.15.3.1.1.7.1

oraEMNGEventRepeatCount

1.3.6.1.4.1.111.15.1.1.1.17.1

oraEM4AlertUDTargetProperties

1.3.6.1.4.1.111.15.3.1.1.28.1

oraEMNGEventUserDefinedTgtProp

1.3.6.1.4.1.111.15.1.1.1.18.1

oraEM4AlertAck

1.3.6.1.4.1.111.15.3.1.1.17.1

oraEMNGAssocIncidentAcked

1.3.6.1.4.1.111.15.1.1.1.19.1

oraEM4AlertAckBy

1.3.6.1.4.1.111.15.3.1.1.16.1

oraEMNGAssocIncidentOwner

1.3.6.1.4.1.111.15.1.1.1.20.1

oraEM4AlertNotifType

1.3.6.1.4.1.111.15.3.1.1.2.1

oraEMNGEventNotifType

1.3.6.1.4.1.111.15.1.1.1.21.1

oraEM4AlertViolationGuid

1.3.6.1.4.1.111.15.3.1.1.42.1

oraEMNGEventSequenceId

C.3 12c以前のメトリック・アラートの修正処理結果

Enterprise Manager 12cより前のリリースでは、メトリック・アラートの修正処理結果はoraEM4JobAlertトラップ・タイプを使用して送信されていました。Enterprise Manager 12c以降では、これらのアラートに対応するイベント・タイプはメトリック・アラートです。Enterprise Manager 12cまたは13cのトラップのoraEMNGEventTypeの値は、「Metric Alert」に設定されます。

表C-3 メトリック・アラートの修正処理結果のマッピング

12C以前のOID番号

12C以前のOID名

12c以降のOID番号

12c以降のOID名

1.3.6.1.4.1.111.15.1.2.1.2.1

oraEM4JobAlertJobName

1.3.6.1.4.1.111.15.3.1.1.34.1

oraEMNGEventCAJobName

1.3.6.1.4.1.111.15.1.2.1.3.1

oraEM4JobAlertJobOwner

1.3.6.1.4.1.111.15.3.1.1.36.1

oraEMNGEventCAJobOwner

1.3.6.1.4.1.111.15.1.2.1.4.1

oraEM4JobAlertJobType

1.3.6.1.4.1.111.15.3.1.1.38.1

oraEMNGEventCAJobType

1.3.6.1.4.1.111.15.1.2.1.5.1

oraEM4JobAlertJobStatus

1.3.6.1.4.1.111.15.3.1.1.35.1

oraEMNGEventCAJobStatus

1.3.6.1.4.1.111.15.1.2.1.6.1

oraEM4JobAlertTargets

1.3.6.1.4.1.111.15.3.1.1.23.1

oraEMNGEventTargetType

1.3.6.1.4.1.111.15.3.1.1.21.1

oraEMNGEventTargetName

1.3.6.1.4.1.111.15.1.2.1.7.1

oraEM4JobAlertTimeStamp

1.3.6.1.4.1.111.15.3.1.1.10.1

oraEMNGEventReportedTime

1.3.6.1.4.1.111.15.1.2.1.8.1

oraEM4JobAlertRuleName

1.3.6.1.4.1.111.15.3.1.1.39.1

oraEMNGEventRuleSetName

1.3.6.1.4.1.111.15.1.2.1.9.1

oraEM4JobAlertRuleOwner

1.3.6.1.4.1.111.15.3.1.1.41.1

oraEMNGEventRuleOwner

1.3.6.1.4.1.111.15.1.2.1.10.1

oraEM4JobAlertMetricName

1.3.6.1.4.1.111.15.3.1.1.65.1

oraEMNGEventTypeAttr5

1.3.6.1.4.1.111.15.1.2.1.11.1

oraEM4JobAlertMetricValue

1.3.6.1.4.1.111.15.3.1.1.68.1

oraEMNGEventTypeAttr8

1.3.6.1.4.1.111.15.1.2.1.12.1

oraEM4JobAlertContext

1.3.6.1.4.1.111.15.3.1.1.44.1

oraEMNGEventContextAttrs

1.3.6.1.4.1.111.15.1.2.1.13.1

oraEM4JobAlertKeyName

1.3.6.1.4.1.111.15.3.1.1.66.1

oraEMNGEventTypeAttr6

1.3.6.1.4.1.111.15.1.2.1.14.1

oraEM4JobAlertKeyValue

1.3.6.1.4.1.111.15.3.1.1.69.1

oraEMNGEventTypeAttr9

1.3.6.1.4.1.111.15.1.2.1.15.1

oraEM4JobAlertSeverity

1.3.6.1.4.1.111.15.3.1.1.5.1

oraEMNGEventSeverity

1.3.6.1.4.1.111.15.1.2.1.16.1

oraEM4JobAlertJobId

なし

なし

1.3.6.1.4.1.111.15.1.2.1.17.1

oraEM4JobAlertJobExecId

なし

なし

C.4 ターゲットの可用性の修正処理結果

Enterprise Manager 12cより前のリリースでは、ターゲットの可用性アラートの修正処理結果はoraEM4JobAlertトラップ・タイプを使用して送信されていました。Enterprise Manager 12c以降では、これらのアラートに対応するイベント・タイプはtarget_availabilityアラートです。Enterprise Manager 12cまたは13cのトラップのoraEMNGEventTypeの値は、「Metric Alert」に設定されます。

表C-4 ターゲットの可用性のマッピング

12C以前のOID番号

12C以前のOID名

12c以降のOID番号

12c以降のOID名

1.3.6.1.4.1.111.15.1.2.1.2.1

oraEM4JobAlertJobName

1.3.6.1.4.1.111.15.3.1.1.34.1

oraEMNGEventCAJobName

1.3.6.1.4.1.111.15.1.2.1.3.1

oraEM4JobAlertJobOwner

1.3.6.1.4.1.111.15.3.1.1.36.1

oraEMNGEventCAJobOwner

1.3.6.1.4.1.111.15.1.2.1.4.1

oraEM4JobAlertJobType

1.3.6.1.4.1.111.15.3.1.1.38.1

oraEMNGEventCAJobType

1.3.6.1.4.1.111.15.1.2.1.5.1

oraEM4JobAlertJobStatus

1.3.6.1.4.1.111.15.3.1.1.35.1

oraEMNGEventCAJobStatus

1.3.6.1.4.1.111.15.1.2.1.6.1

oraEM4JobAlertTargets

1.3.6.1.4.1.111.15.3.1.1.23.1

oraEMNGEventTargetTypeおよび

1.3.6.1.4.1.111.15.3.1.1.21.1

oraEMNGEventTargetName

1.3.6.1.4.1.111.15.1.2.1.7.1

oraEM4JobAlertTimeStamp

1.3.6.1.4.1.111.15.3.1.1.10.1

oraEMNGEventReportedTime

1.3.6.1.4.1.111.15.1.2.1.8.1

oraEM4JobAlertRuleName

1.3.6.1.4.1.111.15.3.1.1.39.1

oraEMNGEventRuleSetName

1.3.6.1.4.1.111.15.1.2.1.9.1

oraEM4JobAlertRuleOwner

1.3.6.1.4.1.111.15.3.1.1.41.1

oraEMNGEventRuleOwner

1.3.6.1.4.1.111.15.1.2.1.10.1

oraEM4JobAlertMetricName

なし

なし

1.3.6.1.4.1.111.15.1.2.1.11.1

oraEM4JobAlertMetricValue

なし

なし

1.3.6.1.4.1.111.15.1.2.1.12.1

oraEM4JobAlertContext

1.3.6.1.4.1.111.15.3.1.1.44.1

oraEMNGEventContextAttrs

1.3.6.1.4.1.111.15.1.2.1.13.1

oraEM4JobAlertKeyName

なし

なし

1.3.6.1.4.1.111.15.1.2.1.14.1

oraEM4JobAlertKeyValue

なし

なし

1.3.6.1.4.1.111.15.1.2.1.15.1

oraEM4JobAlertSeverity

1.3.6.1.4.1.111.15.3.1.1.61.1

oraEMNGEventTypeAttr5 // target_status

1.3.6.1.4.1.111.15.1.2.1.16.1

oraEM4JobAlertJobId

なし

なし

1.3.6.1.4.1.111.15.1.2.1.17.1

oraEM4JobAlertJobExecId

なし

なし

C.5 ジョブ・ステータスの変更

Enterprise Manager 12cより前のリリースでは、ジョブ・ステータスの変更はoraEM4JobAlertトラップ・タイプを使用して送信されていました。Enterprise Manager 12c以降では、これらのアラートに対応するイベント・タイプはjob_status_changeアラートです。Enterprise Manager 12cまたは13cのトラップのoraEMNGEventTypeの値は、「Job Status Change」に設定されます。

表C-5 ジョブ・ステータス変更のマッピング

12C以前のOID番号

12C以前のOID名

12c以降のOID番号

12c以降のOID名

1.3.6.1.4.1.111.15.1.2.1.2.1

oraEM4JobAlertJobName

1.3.6.1.4.1.111.15.3.1.1.29.1

oraEMNGEventSourceObjName

1.3.6.1.4.1.111.15.1.2.1.3.1

oraEM4JobAlertJobOwner

1.3.6.1.4.1.111.15.3.1.1.33.1

oraEMNGEventSourceObjOwner

1.3.6.1.4.1.111.15.1.2.1.4.1

oraEM4JobAlertJobType

1.3.6.1.4.1.111.15.3.1.1.32.1

oraEMNGEventSourceObjSubType

1.3.6.1.4.1.111.15.1.2.1.5.1

oraEM4JobAlertJobStatus

1.3.6.1.4.1.111.15.3.1.1.62.1

oraEMNGEventTypeAttr2

1.3.6.1.4.1.111.15.1.2.1.6.1

oraEM4JobAlertTargets

1.3.6.1.4.1.111.15.3.1.1.23.1

oraEMNGEventTargetTypeおよび

1.3.6.1.4.1.111.15.3.1.1.21.1

oraEMNGEventTargetName

1.3.6.1.4.1.111.15.1.2.1.7.1

oraEM4JobAlertTimeStamp

1.3.6.1.4.1.111.15.3.1.1.10.1

oraEMNGEventReportedTime

1.3.6.1.4.1.111.15.1.2.1.8.1

oraEM4JobAlertRuleName

1.3.6.1.4.1.111.15.3.1.1.39.1

oraEMNGEventRuleSetName

1.3.6.1.4.1.111.15.1.2.1.9.1

oraEM4JobAlertRuleOwner

1.3.6.1.4.1.111.15.3.1.1.41.1

oraEMNGEventRuleOwner

1.3.6.1.4.1.111.15.1.2.1.10.1

oraEM4JobAlertMetricName

なし

なし

1.3.6.1.4.1.111.15.1.2.1.11.1

oraEM4JobAlertMetricValue

なし

なし

1.3.6.1.4.1.111.15.1.2.1.12.1

oraEM4JobAlertContext

1.3.6.1.4.1.111.15.3.1.1.44.1

oraEMNGEventContextAttrs

1.3.6.1.4.1.111.15.1.2.1.13.1

oraEM4JobAlertKeyName

なし

なし

1.3.6.1.4.1.111.15.1.2.1.14.1

oraEM4JobAlertKeyValue

なし

なし

1.3.6.1.4.1.111.15.1.2.1.15.1

oraEM4JobAlertSeverity

なし

なし

1.3.6.1.4.1.111.15.1.2.1.16.1

oraEM4JobAlertJobId

なし

なし

1.3.6.1.4.1.111.15.1.2.1.17.1

oraEM4JobAlertJobExecId

1.3.6.1.4.1.111.15.3.1.1.61.1

oraEMNGEventTypeAttr1

* 注意: 1.3.6.1.4.1.111.15.1.1.1.7.1 oraEM4AlertKeyValueを1.3.6.1.4.1.111.15.1.1.1.7.1 oraEM4AlertKeyValueへの12cまたは13cのmetric_alertイベントにマッピングする場合、1.3.6.1.4.1.111.15.3.1.1.84.1 oraEMNGEventTypeAttr24を参照する必要があります。

if oraEMNGEventTypeAttr24 is null
then
oraEM4AlertKeyValue is null

if oraEMNGEventTypeAttr24 value =  "Number of keys=1"
oraEM4AlertKeyValue --> oraEMNGEventTypeAttr8

if oraEMNGEventTypeAttr24 value =  "Number of keys=x" where x is greater than 1
=> check the values for the following pairs of attributes.
<oraEMNGEventTypeAttr10, oraEMNGEventTypeAttr11>
<oraEMNGEventTypeAttr12, oraEMNGEventTypeAttr13>
<oraEMNGEventTypeAttr14, oraEMNGEventTypeAttr15>
<oraEMNGEventTypeAttr16, oraEMNGEventTypeAttr17>
<oraEMNGEventTypeAttr18, oraEMNGEventTypeAttr19>
<oraEMNGEventTypeAttr20, oraEMNGEventTypeAttr21>
<oraEMNGEventTypeAttr22, oraEMNGEventTypeAttr23>
...
...

キー内に存在する部分の数と同じ数のペアが移入され、残りはnullに設定されます。

null以外の属性のペアでは、最初の属性にはキーのその部分の名前を指定し、2番目の属性にはキーのその部分の値を指定します。

重要:
OID 1.3.6.1.4.1.111.15.3.1.1.13.1はイベント・タイプを指定します。次に例を示します。
metric_alertイベント・タイプの場合

oraEMNGEventType=Metric Alert

target_availabilityイベント・タイプの場合

oraEMNGEventType=Target Availability

job_status_changeイベント・タイプの場合

oraEMNGEventType=Job Status Change

D ターゲットの可用性状態の概要

次の項では、使用可能な状態とターゲットのステータスのリアルタイム更新の設定方法について説明します。

D.1 ターゲットの可用性状態の変更

Enterprise Managerでは、ターゲットの可用性ステータスの包括的な配列を情報アイコンの形式で表示します。様々なCloud Controlコンソール・ページでこれらのアイコンが表示され、リポジトリでのターゲットの現在の状態が示されます。

次のように、使用可能なターゲットのすべての可用性ステータスとその意味を示します。

アイコン

可用性の状態

説明

なし

なし

ターゲットの可用性の状態は適用されません。

停止中

ターゲットは停止しています。
エージェントが停止しているためにターゲットが使用できない可能性があります。計画メンテナンスの一環としてエージェントが停止された場合は、エージェントにブラックアウトを作成することを検討してください。

稼働中

ターゲットは稼働しています。

可用性評価エラー

ターゲットの可用性ステータスを判別しようとしてエラーが発生しました。ターゲットの可用性評価エラーは、メトリックの収集エラー、エージェント使用不可、またはネットワークの問題によって発生する可能性があります。

エージェント停止

ターゲットを監視しているエージェントが停止しています。
エージェントがエラーで停止した場合は、再起動する必要があります。計画メンテナンスの一環としてエージェントが停止された場合は、エージェントにブラックアウトを作成することを検討してください。

エージェント停止中、ターゲット稼働中

ターゲットを監視しているエージェントは停止していますが、ターゲットは稼働しています(ただし監視されていません)。
トラブルシューティングとして、エージェントのホームページに移動し、「ステータス」フィールドの横にある「兆候分析」ツールを実行します。

エージェント使用不可

エージェントは使用できません。特に、Oracle Management Service (OMS)はエージェントと通信できません。
エージェントが停止している場合、管理エージェントがOMSによってブロックされた場合、または管理エージェント・ホストが停止している場合は、一般的にエージェントは使用できません。ネットワークやその他の特定の問題が原因で、管理エージェントが使用できない可能性もあります。

エージェント使用不可(移行中)

エージェントの移行処理中のため使用できません。

エージェント使用不可(ファイル・システムに書き込めません)

エージェントはファイル・システムに書き込むことができません。
エージェントのファイル・システムの可用性を確認してください。トラブルシューティングとして、Enterprise Managerコンソールからエージェントのホームページに移動し、「兆候分析」ツール(「ステータス」フィールドの横にあります)を実行します。

エージェント使用不可(収集の無効化)

エージェントのメトリック収集が無効になっています。
エージェントがOMSにアップロードできることを確認してください。トラブルシューティングとして、Enterprise Managerコンソールからエージェントのホームページに移動し、「兆候分析」ツール(「ステータス」フィールドの横にあります)を実行します。

エージェント使用不可(ディスク空きなし)

エージェントのファイル・システムが一杯です。
エージェントのファイル・システムの使用可能領域を確認してください。トラブルシューティングとして、Enterprise Managerコンソールからエージェントのホームページに移動し、「兆候分析」ツール(「ステータス」フィールドの横にあります)を実行します。

エージェント使用不可(ブラックアウト後)

ブラックアウト期間が終了したために最初のアラート条件がまだ発生していないことから、エージェントは使用できません。

エージェントがブロックされました(手動でブロック済)

エージェントは手動でブロックされました。
エージェントをブロック解除します。

エージェントがブロックされました(プラグインの不一致)

プラグインの不一致によりエージェントがブロックされました。
エージェントがバックアップからリストアされた場合は、エージェントの再同期化を実行します。

エージェントがブロックされました(バウンス・カウンタの不一致)

バウンス・カウンタの不一致によりエージェントがブロックされました。
エージェントがバックアップからリストアされた場合は、エージェントの再同期化を実行します。

エージェント使用不可(エージェントの構成ミス)

エージェントは、別のOMSとの通信用に構成されています。
エージェント構成を確認して、エージェントが正しいOMSと通信していることを確認します。

エージェント使用不可(通信の中断)

エージェントとOMS間の通信が中断したことにより、エージェントは使用できません。

ブラックアウト

ターゲットは現在ブラックアウトされています。

ステータス保留

ターゲットのステータスが不明です。

ステータス保留(ターゲットの追加が進行中)

ターゲットのステータスが不明です。ターゲットの追加中です。

ステータス保留中(ブラックアウト後)

ターゲットのステータスが不明です。このターゲットでブラックアウトが終了した直後で、「可用性ステータス」が保留中です。

ステータス保留中(メトリック・エラー後)

ターゲットでメトリック・エラーが終了した直後で、「可用性ステータス」が保留中です。トラブルシューティングとして、My Oracle Supportの「Enterprise Manager 12c: How to run the "Targets Status Diagnostics Report" to Troubleshoot Target Status Availability Issues (up, down, metric collection error, pending, unreachable) for all Targets (Doc ID 1546575.1)」という記事を参照してください。

D.2 ターゲット・ステータス変更の更新

Enterprise Managerにより、ブラウザ・ページをリフレッシュしたり収集間隔の遅延が10分の数秒から数分かかる可能性があるレスポンス・メトリックでステータス変更の検出を待機したりせずに、特定のターゲット・コンテキストUIページのターゲット情報を自動的に更新できます。

ターゲット・コンテキスト・ページには、特定のターゲットの情報が表示されます。このページの上部には、ターゲット名、ターゲット・タイプ、ターゲット・ステータス、ターゲット・メニューなどの情報が表示されるコンテキスト・ヘッダーがあります。

次のターゲット・タイプで、ステータス変更の更新が使用可能です。

- エージェント

- ホスト

- データベース・インスタンス(単一インスタンスのデータベースのみ)

- アプリケーション・デプロイメント

- WebLogic Server

前述のとおり、この機能によって、ターゲットのステータスが変更されたとき(「稼働中」から「停止中」など)に、そのターゲット・コンテキスト・ページを自動的に更新できます。デフォルトでは、自動ステータス変更更新はオフです。この機能は、oracle.sysman.core.uifwk.realTimeUIEnabled OMSプロパティを使用してオン/オフを切り替えることができます。

ステータス変更更新を有効にするには、次のemctlコマンドを実行します。

emctl set property -name oracle.sysman.core.uifwk.realTimeUIEnabled -value true

E Enterprise Managerコンポーネントのタイムアウト値

表E-1は、Enterprise Managerコンポーネントのタイムアウト値について説明しています。

表E-1 Enterprise Managerコンポーネントのタイムアウト値

コンポーネント

説明

タイムアウト値(分)

コマンド

Apacheのタイムアウト

Apacheセッションがアクティブな状態の秒数。

Apacheのタイムアウトがオペレーティング・システムのTCPタイムアウト以上に設定されている場合、予測できない結果が生じる場合があります。オペレーティング・システムのタイムアウトは、デフォルトで2時間に設定されています。

5分(デフォルト)

次のコマンドを実行します。

$ omsvfy show tcp
Parameters Incoming                 Value
--------------------
tcp_keepalive_time                        7200
tcp_keepalive_intvl                         75
tcp_fin_timeout                             60
--------------------

OMSタイムアウトまたはログイン・タイムアウト

これは、OMSごとに設定可能なoracle.sysman.eml.maxInactiveTimeパラメータです。Cloud Controlへの不正なアクセスを回避するため、事前定義された一定期間の間にアクティビティが発生しない場合、Enterprise ManagerはCloud Controlから自動的にログアウトします。たとえば、ブラウザを開いたまま席を離れた場合などです。デフォルトでは、不正なユーザーがEnterprise Manager管理者アカウントを使用できないように動作します。

ログインのタイムアウト値を変更する場合は、デフォルトのタイムアウト期間以外にもセッションをオープンにすることのセキュリティ上の問題を十分に考慮してください。

注意: デフォルトのタイムアウト値は、WebサーバーまたはOMSの再起動の際には適用されません。これらのケースの両方で、デフォルトのタイムアウト値に関係なくCloud Controlコンソールへログインすることを求められます。

45分(デフォルト)

次のコマンドを実行します。emctl set property -name oracle.sysman.eml.maxInactiveTime -value time_in_minutes -module emoms

次に、OMSを再起動して値を有効にします。

ADFタイムアウト

この値は、変数oracle.adf.view.rich.poll.timeoutで制御されます。この変数は自動ポーリングが有効なページに適用されます。ADFページは、自動ポーリングが有効になっている可能性があります。oracle.adf.view.rich.poll.timeout変数の有効期間にページ上でキーボード入力またはマウス操作がなかった場合、ポーリングは停止します。この時点から、このページは標準的なサーバー側セッションのタイムアウトを適用します。

10分

なし

索引
A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  V  W  Z

A

プラグイン・マネージャのアクセス, 23.4.1

ソフトウェア・ライブラリの管理ページへのアクセス, 22.5

ソフトウェア・ライブラリのコンソールへのアクセス, 22.1

アダプタ, 8.4

適応メトリックしきい値, テスト, 9.2.4

適応しきい値, 9

適応しきい値メトリック, 登録解除, 9.2.5

適応しきい値メトリック, 登録, 9.2.1

適応しきい値, 精度, 9.2.3

適応しきい値, 概念, 9.2

適応しきい値, 構成, 9.2.2

適応しきい値, モニタリング・テンプレート, 9.2.6

HTTPの場所の追加, 22.7.3

NFSの場所の追加, 22.7.3

OMSエージェント・ファイルシステムの追加, 22.7.2

OMSエージェント・ファイルシステムの場所の追加, 22.7.3

OMS共有ファイルシステムの追加, 22.7.1

ターゲットの追加, 23.3

ADFタイムアウト設定, E

管理グループ

作成, 6.3

定義, 6.1

階層, 6.3.3

管理グループ, 1.4.2 管理者, 30.1 高度なしきい値管理, 9 エージェントのパッチ適用ディレクトリの構造, 25.3 エージェント, 更新, 21.5 集計およびパージのポリシー

「データ保持ポリシー」を参照

アラート・メッセージ, カスタマイズ, 1.4.3 アラート

自動レスポンス, 1.3.5

修正処理, 1.3.5

通知メソッド, 1.5

通知, 1.5

Always-On Monitoring, 12, 12.1

コマンド, 12.5.1

コンフィギュレーション・アシスタント, 12.3.1

停止時連絡先の構成, 12.3.3

Enterprise Managerとの構成, 12.3.5

構成, 12.3

電子メール・サーバーの構成, 12.3.2

制御, 12.3.5

データ・メンテナンス, 12.7

データベース文字セットの定義, 12.2.1.2

データベースのサイズ設定, 12.2.1.1

診断, 12.11

停止時連絡先, 12.3.3

EM CLI, 12.3.3

ジョブ, 12.3.3

通知の有効化/無効化, 12.5 ステータスおよびログの取得, 12.5 HAとDR, 12.12 インストール, 12.2 インストール, 12.2.3 リポジトリのスキーマ, 12.2.1.1 同期化, 12.3.4 更新, 12.6 Always-On Monitoringのプロパティ, 12.10 分析

ジョブ・アクティビティ, 10.4

Apacheのタイムアウト設定, E アーカイブ・ログ

管理リポジトリ・データベース, 20.1

監査

有効化, 20.1

自動適用テンプレート, 7.3 自動

アラートに対するレスポンス, 1.3.5

自動によるパッチ適用

オフライン・モード, 25.2

オンライン・モード, 25.2

自動によるパッチ適用のメリット, 25.2.1 ドメイン・メンバーの自動検出, 15.2 自動ログアウト, E 自動ターゲット検出, 15.1.1

ドメインの変更, 15.2.1

「可用性履歴」レポート, 図, 41.2

B

ベースライン正規化ビュー, 1.3.2

ベースライン期間, 9.2

ベースライン期間, 変動ウィンドウ, 9.2

ビーコン

概要, 1.2

beadm, 38.12 情報パブリッシャの利点, 41.1 ブラックアウト

コマンドライン・インタフェース, 1.3.7

emctlによる制御, 4.3

例, 4.3

機能, 1.3.7

遡及, 1.3.7

ブラックアウト, 4.2 ブラックアウト・ベスト・エフォート, 4.4 ブート環境, 38.12

C

カタログ・アーカイブ, 23.6.1.3

Checkpoint Firewall, Oracleエコシステム, 1.2

Cloud Control

起動, 27.3.1

すべてのコンポーネントの起動, 27.3.1

Cloud Control Mobile, 2.1.5

問題の確認, 43.7.3

ビューの変更, 43.7.2

強制終了, 43.8

iDevice, 43.1

インシデント・マネージャ, 43.6

インシデントと問題, 43.7.1

iTunes App Store, 43.1

ログイン, 43.4

問題のワークフローの管理, 43.7.3

設定の管理, 43.5

My Oracle Support, 43.6

要件, 43.1

設定, 43.2

SR番号, 43.6

タッチアンドホールド, 43.8

コマンドライン・インタフェース(EMCLI)

ブラックアウト, 1.3.7

構成

ブラックアウト, 機能, 1.3.7

監視テンプレート, 1.4.1

サービスの構成

可用性

ビーコン, 29.2.1

キー・ビーコン, 29.2.1

コマンドライン・インタフェース, 29.10 作成, 29.2 メトリック

使用状況, 29.4.7

モニタリング設定, 29.4.4

ビーコンの上書き, 29.4.4

「収集の設定」タブ, 29.4.4

「データの粒度」プロパティ, 29.4.4

頻度, 29.4.4

パフォーマンス・メトリック, 29.4.6

集計関数, 29.4.6

トランザクションの記録, 29.5 根本原因分析, 29.4.1, 29.4.2

「トポロジ」ページ, 29.4.2

サービス・レベル・ルール, 29.9

実際のサービス・レベル, 29.9

可用性, 29.9

営業時間, 29.9

予測されるサービス・レベル, 29.9

情報パブリッシャ, 29.9.2

パフォーマンス基準, 29.9

サービス・ダッシュボード, 29.9.2

サービス・テスト・ベースの可用性

キー・サービス・テスト, 29.4.1

サービス・テストとビーコン

専用ビーコンの構成, 29.4.5.3

Webプロキシの構成, 29.4.5.3

テスト・タイプの選択, 29.4.5.1

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

インストール手順

OMSエージェント記憶域, 22.7.2

OMS共有ファイル・システム, 22.7.1

参照先記憶域の場所, 22.7.3

ソフトウェア・ライブラリの構成, 22, 22

管理者権限, 22.2

インストール手順, 22.7

メンテナンス手順, 22.13

ソフトウェア・ライブラリ記憶域の場所の削除, 22.13.3

定期的なメンテナンス・タスク, 22.13.1

Oracle所有エンティティ・ファイルの再インポート, 22.13.2

概要, 22.1 前提条件, 22.6 ロールとソフトウェア・ライブラリ権限, 22.2 記憶域, 22.5 ユーザー・ロールと権限, 22.2 接続記述子, 20.3.2.1

接続記述子を使用した管理リポジトリ・データベースの特定, 20.3.1, 20.3.2.1

コネクタ, 1.6.3 修正処理

アラート, 1.3.5

必須権限, 1.3.5

CPU

詳細, 38.15.1

スレッド使用率, 38.8.3

使用率とメトリック, 38.8.1

作成

管理グループ, 6.3

カスタム・レポート, 41.3.1

レポート定義, 41.2

クリティカルURL監視, 管理エージェントの代用, 1.2 クロス・プラットフォーム・トランスポータブル・データベース, 20.5.2.1 カスタム・レポート, 41.3 カスタマイズ

通知, 1.5.1

Cloud Controlページのカスタマイズ, 26

D

ダッシュボード

グループ, 5.2.9

データ

集計, 20.2.1

パージ, 20.2.1

データ・パージ・ポリシー, 20.2.1 データ保持ポリシー

アプリケーション・パフォーマンス管理データ, 20.2.1

管理データ, 20.2.2

管理リポジトリ, 20.2

デフォルトの変更, 20.2.3

データベース

メモリー不足, 20.2.5

データベース・スケジューラ

トラブルシューティング, 20.2.5

データベース使用状況トラッキング・レポート, 42.1 データベース使用状況トラッキング・レポート, 作成, 42.2.4 データベース使用状況トラッキング・サマリー・レポート, 42.1 データベース

表領域の移動, 20.5.2.1

データリンク, 32.1, 32.6.1

表示, 32.2, 32.6.2

dbms_scheduler, 20.2.5

許容されたセッション, 20.2.5

無効化, 20.2.5

DBMS_SCHEDULER

トラブルシューティング, 20.2.5

DBSNMPデータベース・ユーザー, 27.7

パスワードの設定, 27.7

デフォルト集計, 20.2.1 デフォルト・テンプレート, 7.3 プラグインのデプロイ, 23.6.2, 23.6.4 デプロイメント, 23.3 プラグインのデプロイ, 23.6.2.1 デプロイメント・ステータス, 23.6.4.1 ターゲットの検出, 23.3 ディスク

詳細, 38.15.1

ディスクのミラーリングとストリッピング

管理リポジトリのガイドライン, 20.1

ディスク領域管理

ログ・ファイルおよびトレース・ファイルのサイズと数の制御, 28.4.3

ログ・ファイルおよびトレース・ファイルのサイズの制御, 28.4.4

ログのダウンロード, 28.1.3 プラグインのダウンロード, 23.6.1, 23.6.1.2 dropコマンド, 20.3, 20.3.1 管理リポジトリの削除, 20.3

E

電子メールのカスタマイズ, 3.1.4.1

電子メール通知, 上限, 3.1.2.1

電子メール, 書式, 1.5.1

EMCLI, 設定, 21.2.6

emctl

ブラックアウトの制御, 4.3

emctlコマンド

管理エージェント, 27.9

OMSのEMCTLコマンド, 27.8 emctl reload, 27.9 emctl start blackout, 4.3, 4.3 emctl status blackout, 4.3 emctl stop blackout, 4.3 emctl upload, 27.9 emctl.log, 28.3.1, 28.4.1 emctl.log file, 27.21 emctl.msg, 28.4.1 emoms_pbs.log, 28.4.1 emoms_pbs.trc, 28.4.1 emoms.log, 28.4.1, 28.4.3 emomslogging.properties

MaxBackupIndex, 28.4.3

MaxFileSize, 28.4.3

emoms.trc, 28.4.1 EMS

制御, 12.5

停止時連絡先, 12.3.3

電子メールの構成, 12.3.2

Enterprise Managerとの初回同期, 12.3.4

EMSCA, 12.3.1 EMSCA, パラメータ, 12.3.1 EMSI

検出, 16.1

Enterprise Manager

ブラックアウト, 機能, 1.3.7

監視テンプレート, 1.4.1

Enterprise Manager, 管理, 19.1 イベント属性, 2.1.1 イベント・コネクタ, 1.6.3 イベント管理, 2.1.1 イベント

履歴データ, 20.2.1

イベント, 1.3.4 拡張ネットワーク, 管理エージェントの代用, 1.2 拡張性の枠組み, 23.2.1

F

ファブリック, 32.1, 32.5.1, 32.5.3

検出, 16.9, 16.9.1, 16.9.2

インシデント, 32.5.4

パフォーマンス・メトリック, 32.5.4

表示, 32.2, 32.5.2

fetchlet, 30.5.2 強制終了

Cloud Control Mobile, 43.8

G

gcagent_errors.log, 28.3.1

gcagent_mdu.log, 28.3.1

gcagent.log, 28.3.1

HTMLレポートの生成, 41.2

Grid Control

停止, 27.3.2

すべてのコンポーネントの停止, 27.3.2

グループ階層, 6.2 グループの「メンバー」ページ, 図, 5.2.7 グループ

監視中枢の場所, 5.2.5

ダッシュボード, 5.2.9

説明および目的, 5.1

管理機能, 5.2

メンバー・ターゲット, 5.2.7

H

状態の概要, 19.2

ヘルプデスク・コネクタ, 1.6.3

ホームページ

設定, 26.3

ホスト

コンプライアンス, 38.17

コンプライアンス・フレームワーク, 38.17.1

コンプライアンス標準, 38.17.2

メモリー, 38.9

メトリック設定, 38.16.2

メトリック, 38.15.3

モニタリング, 38.1

記憶域, 38.10

ターゲット・コンプライアンス, 38.17.3

ホスト・メトリック, 38.15 ホスト・サービス

状態, 38.14

毎時メトリック収集, 有効化, 42.2.2

I

IBM WebSphere

Oracleエコシステム, 1.2

iDevice

Cloud Control Mobileでサポートされる, 43.1

インシデント属性, 2.1.2.1 インシデント作成, 2.1.2.4 インシデント管理, 2.1.2 インシデント・マネージャ, 1.6.1

Cloud Control Mobile, 43.6

インシデント優先度, 2.1.2.1 インシデント

ファブリック, 32.5.4

スイッチ, 32.2

インシデントと問題

Cloud Control Mobile, 43.7.1

インシデント, 処理, 2.3 情報パブリッシャ

類似作成機能, 41.3

HTMLレポートの生成, 41.2

概要, 41

事前定義済レポート, 5.3

レポート

定義, 41.2

要素, 41.3.3

レポート・フレームワーク, 41 レポートの共有, 41.5 レポートの表示, 41.5 情報更新, 21.4 iTunes App Store

Cloud Control Mobile, 43.1

J

ジョブ・アクティビティ・ページ, 10.1

ジョブ・スレーブ・プロセス, 20.2.5

job_queue_processes, 20.2.5

ジョブ

ジョブ・アクティビティの分析, 10.4

定義, 10.1

ジョブ・アクティビティ・ページ, 10.1

ジョブ実行, 10.1.3

ジョブ実行, 10.1.3

保存期間の変更, 20.2.4

マルチタスク, 10.3.4.1

電子メールの通知ルール, 10.3.2

個別ジョブ実行とジョブ実行の操作, 10.1.4

ジョブ職責の共有に必要な権限, 10.2.3

目的, 10.1

L

ロード・バランサ・スイッチ

BIG-IP, Oracleエコシステム, 1.2

ローカル・ストア, 21.2.3 ログ・ファイル

サイズと数の制御, 28.4.3

検索および構成, 28

管理エージェントの検索, 28.3.2

管理サービスの検索, 28.4.2

管理エージェント, 28.3, 28.3

Oracle Management Service, 28.4

検索, 28.1.2

log4j.appender.emlogAppender.MaxBackupIndex, 28.4.3 log4j.appender.emlogAppender.MaxFileSize, 28.4.3 log4j.appender.emtrcAppender.MaxBackupIndex, 28.4.3 log4j.appender.emtrcAppender.MaxFileSize, 28.4.3 Cloud Control Mobileへのログイン, 43.4 論理ドメイン

検出, 16.4, 16.4

ログイン・タイムアウト設定, E LVM (論理ボリューム・マネージャ), 20.1

M

管理エージェント, 28.3.1

代用としてのクリティカルURL監視, 1.2

代用としての拡張ネットワーク, 1.2

用途, 1.1

管理エージェントのログ

ログ・レベルの設定, 28.3.3, 28.3.3.2, 28.3.3.3, 28.3.3.4, 28.3.3.5

トレース・レベルの設定, 28.3.3.6

管理情報ベース(MIB), 3.6

定義, 3.6.1

MIB変数の説明, 3.6.3

管理リポジトリ, 20.2.1

作成, 20.3.1

デプロイメントのガイドライン, 20.1

削除, 20.3.1

概要, 1.2

移行, 20.5

移行の前提条件, 20.5.1

再作成, 20.3.1

削除, 20.3.1

サーバー接続ハング・エラー, 20.4.2

トラブルシューティング, 20.4, 20.4.3

管理サービス

Windowsシステム上の起動および停止, 27.5

管理

グループ, 5.2

Cloud Control Mobileサイトの管理, 43.5 ログの管理, 28.1 ドメイン・メンバーの手動検出, 15.2.2 MAX_UTILIZATION, 20.2.5 MaxBackupIndex

emomslogging.propertiesのプロパティ, 28.4.3

MaxFileSize

emomslogging.propertiesのプロパティ, 28.4.3

メモリー

詳細, 38.15.1

メトリック

しきい値, 1.3.1

メトリック・アラート・メッセージ, カスタマイズ, 1.4.3 メトリック・ベースライン, 1.3.2 メトリック列, デルタ, 8.3.5 メトリック列, 率, 8.3.5 メトリック拡張, 1.3.6 メトリック拡張のライフサイクル, 8.2 メトリック拡張, 作成, 8.3.5 メトリック拡張, 削除, 8.3.11 メトリック拡張, 編集, 8.3.7 メトリック拡張, エクスポート, 8.3.10 メトリック拡張, インポート, 8.3.9 メトリック拡張, 30.6 メトリック拡張, 8 メトリック拡張, 管理者権限, 8.3 メトリック拡張, デプロイ, 8.3.12 メトリック拡張, 古いバージョンの更新, 8.3.14 メトリック

しきい値, 1.3.1

しきい値, 1.3.1

MGMT_METRICS_1DAY表, 20.2.3 MGMT_METRICS_1HOUR表, 20.2.3 MGMT_METRICS_RAW表, 20.2.3 MIB

「管理情報ベース(MIB)」を参照

移行, 22.13.3 移行

移行後の検証, 20.5.3

リポジトリ, 20.5.1

リポジトリ手法, 20.5.2

フィジカル・スタンバイの使用, 20.5.2.2

パッチ適用のモード, 25.2, 25.2 モニタリング

発生時のアラート, 5.2.9

基本, 1.1

テンプレート

機能, 1.4.1

監視資格証明

定義, 27.7

設定, 27.7

監視の概要, 1.1 監視テンプレート, 作成, 7.5 監視テンプレート, 定義, 7.2 監視テンプレート, 編集, 7.6 監視テンプレート, 保持期間, 7.12 監視テンプレート, 7.1 監視テンプレート, ターゲットへの適用, 7.7 監視テンプレート, ターゲットとの比較, 7.8 監視テンプレート, エクスポート/インポート, 7.10 変動ウィンドウ・ベースライン期間, 9.2 マルチタスク・ジョブ, 10.3.4.1 My Oracle Support, OMSパッチ, 24.4.1 My Oracle Support, OPatchauto, 24.4.1

N

NetApp Filer

Oracleエコシステム, 1.2

ネットワーク

接続性, 38.11

ネットワーク, 32.1

インシデント, 32.2

メトリック, 32.2, 32.7.1

オペレーティング・システム, 32.7.1

オペレーティング・システム, 32.7.4

パフォーマンス, 32.2

トポロジ, 32.4

表示, 32.2, 32.7.2

新製品のお知らせ, 21.4 非グローバル・ゾーン, 39.1 通知, 30.4 通知方法

PL/SQLプロシージャに基づく, 3.4

SNMPトラップに基づく, 3.5

オペレーティング・システム・コマンドに基づく, 3.3

定義, 3.2

通知ルール

定義, 3.1.2.3

即時利用可能, 3.1.2.3

即時利用可能な通知ルール, 3.1.2.1

サブスクライブ, 3.1.2.3

通知スケジュール, 3.1.2.1 通知システム

電子メールのエラー, 3.10.4.4

エラー, 3.10.4.2

トレース・メッセージ, 3.10.4.3

通知

アラート, 1.5

カスタマイズ, 1.5.1

複数のメール・サーバーの定義, 3.1.1

ジョブ, 10.3.2

長い書式の電子メール通知, 3.1.2.1

メール・サーバーの設定, 3.1.1

管理情報ベース(MIB), 3.6

メソッド, 1.5

通知メソッド, 1.5

通知スケジュール, 3.1.2.1

オペレーティング・システム・コマンド・スクリプトの例, 3.3.1

設定, 3.1

短い書式の電子メール通知, 3.1.2.1

O

オフライン・モード, 25.2

OMS

emctlコマンド, 27.8

OMS構成, OPatchauto, 24.1.1 OMS構成,OPatchauto, 24.1.1 OMSタイムアウト設定, E オンライン・モード, 25.2 opatchauto apply, 24.4.2, 24.4.2 opatchauto lspatches, 24.4.4, 24.4.6 OPatchautoパラメータ, 24.2 OPatchautoプロパティ・ファイル, 24.2.1 opatchauto rollback, 24.4.3, 24.4.3 opatchauto version, 24.4.5, 24.4.5 OPatchauto, 前提条件, 24.3 オペレーティング・システム

ブート環境, 38.12

構成の変更, 38.7.2

CPUメトリック, 38.8

ダッシュボード, 38.4

詳細およびメトリック, 38.5

ホスト・サービス, 38.14

インシデント, 38.7

メトリック収集エラー, 38.16.1

メトリック, 38.15.3

モニタリング, 38.1

上位プロセス, 38.13

オペレーティング・システム・コマンド

通知メソッドの例, 3.3

サンプル・スクリプト, 3.3.1

オペレーティング・システム・スクリプト, 3.2, 3.2 オペレーティング・システム

検出, 16.2

オペレーティング・システム

ネットワーク, 32.7.1, 32.7.4

Oracle

エコシステム, 1.2

Oracle Data Guard, 20.1 Oracle Enterprise Manager

ログ・ファイル, 28

Oracle Enterprise Manager Cloud Control, 27.3.1 Oracle HTTP Serverのログ, 28.4.5 Oracle Management Agent

ログ・ファイルおよびトレース・ファイルの概要, 28.3.1

ログ・ファイルとトレース・ファイルの場所, 28.3.2

ログ・ファイルとトレース・ファイル, 28.3

Oracle Management Repository

データ保持ポリシー, 20.2

削除, 20.3

接続記述子による特定, 20.3.1, 20.3.2.1

再作成, 20.3, 20.3.2

管理リポジトリ・データベースの起動, 27.3.1

トラブルシューティング, 20.4.3

Oracle Management Service

ログ・ファイルとトレース・ファイルの概要, 28.4.1

タイムアウト設定の構成, E

ログ・ファイルとトレース・ファイルの場所, 28.4.2

ログ・ファイルとトレース・ファイル, 28.4

モニタリング資格証明の変更, 27.7

Oracle Management Serviceのログ, 28.4.1, 28.4.3 Oracle Management Serviceのトレース・ファイル, 28.4.4 Oracle Process Management and Notification(OPMN)

管理サービスの起動および停止における使用, 27.5

Oracle Solaris

ブート環境, 38.12

ゾーン, 39.1

Oracle SuperCluster

検出, 16.6

Oracle VM Server for SPARC

検出, 16.4

Oracle WebLogic Serverのログ, 28.4.5 Oracle ZFS Storage

検出, 16.8

oraEM4JobAlertTable, A.3 oraEMNGEvent, A.1 orAgentTraps, A.2 OSスクリプト

「オペレーティング・システム・スクリプト」を参照

OSIの層, 32.1 OUIインベントリ構成, 24.1.2 即時利用可能な監視, 1.2 即時利用可能なレポート, 41.2

P

パッチの形式, 24.1.3

パッチ管理ソリューション

パッチのロールバック, 25.2.5

パッチと更新版, 25.2.2

エージェントへのパッチ適用

すべてを計画に追加, 25.2.5

計画の作成, 25.2.5

NULLプラットフォーム, 25.2.5

計画の表示, 25.2.5

「パッチ」ページ, 25.2.5 確認とデプロイ・ページ, 25.2.5 Enterprise Managerへのパッチ適用

管理エージェント・パッチの適用エラー, 25.2.7

管理エージェント

「パッチと更新版」の利用, 25.2.2

エージェント・パッチの適用, 25.2.5

自動によるパッチ適用, 25.2

手動によるパッチ適用, 25.3

概要, 25.1

パッチの検索, 25.2.4 適用したエージェント・パッチの検証, 25.2.6 パッチ推奨の表示, 25.2.3 Enterprise Managerコア・コンポーネントのパッチ適用, 25 管理エージェントへのパッチ適用, 25 OMSへのパッチ適用, 25 リポジトリへのパッチ適用, 25 PDU

検出, 16.7

パフォーマンス

ネットワークのメトリック, 32.2

スイッチ, 32.2

パフォーマンス・メトリック

ビーコンの集計関数

最大値, 29.4.6

最小値, 29.4.6

値の合計, 29.4.6

システム集計関数

最大値, 29.4.6

パフォーマンス・メトリック

ファブリック, 32.5.4

SNMP.SNMPTimeout, 32.5.4, 32.5.4

パフォーマンス・メトリック

ビーコンの集計関数

Average, 29.4.6, 29.4.6

Minimum, 29.4.6

Sum, 29.4.6

Cloud Controlページのパーソナライズ, 26 停止期間の計画, ブラックアウト, 1.3.7 PL/SQLプロシージャ, 3.2

通知メソッドの作成時, 3.4

プラグイン・アーカイブ, 23.6.1.4 プラグイン・ホーム, 23.9.1 プラグインID, 23.5.3.2 プラグイン・マネージャ, 23, 23.4, 23.8 プラグイン, 23.2, 23.2.1, 23.2.2, 23.5.2, 23.5.3.3, 23.6.1.1, 23.6.1.2, 23.9.2.1 ポート

スイッチ, 32.2

権限

修正処理, 1.3.5

ジョブ職責の共有, 10.2.3

問題管理, 2.1.3 プロセス・マネージャ

Windowsシステム上で管理サービスの制御に使用するサービス, 27.5

プログラム・リソース使用率, 38.15.2 削除ジョブ

検証, 20.2.4

パージ・ポリシー

デフォルト, 20.2.4

変更, 20.2.4

パージ・ポリシー, 20.2.1, 20.2.1

「データ保持ポリシー」を参照

R

RAID対応ディスク

管理リポジトリのガイドライン, 20.1

receivelet, 30.5.1 メトリック収集の再評価, 27.6 WebLogicドメイン・ターゲットのリフレッシュ, 15.2.2 繰返し通知, 3.1.5 RepManager, 20.4.3 RepManagerスクリプト, 20.3.1 RepManagerスクリプト, 20.3.1 レポート

カスタム・レポートの作成, 41.3.1

カスタム, 41.3

定義, 情報パブリッシャ, 41.2

電子メール送信, 41.4.3

HTMLレポートの生成, 41.2

情報パブリッシャ, 41

即時利用可能, 情報パブリッシャ, 41.2

事前定義済, 5.3

事前定義済レポート定義, 41.2

レポート要素, 41.3.3

スケジュール, 41.4, 41.4

共有, 41.5, 41.5

格納およびパージ, 41.4.2

表示, 41.5

要件

Cloud Control Mobile, 43.1

リソース使用率, 38.15.2 保存期間, 20.2.4 保存時間, 20.2.3

デフォルト, 20.2.3

遡及ブラックアウト, 1.3.7 根本原因分析

モード

自動, 29.4.2

手動, 29.4.2

ルール・アクション, 2.1.4.3.3 ルール基準, 2.1.4.3.2 ルール・セット・タイプ, 2.1.4.2 ルール・セット, 開発, 2.2.1.1 ルール・セット, 2.1.4 ルール・セット, 即時利用可能, 2.1.4.1 ルール・セット, 設定, 2.2.4 ルール, 1.5

S

ブラックアウトを使用したメンテナンスの計画, 1.3.7

スケジュール

レポート, 41.4

レポート, 柔軟性, 41.4.1

ログの検索, 28.1.2 セキュリティ

SNMP, 16.5.2, 16.9.3, 16.9.3, 16.9.3, 32.5.4

自己更新機能

設定, 21

使用, 21

server

検出, 16.5

サーバー接続ハング

リポジトリ作成時のエラー, 20.4.2

サービス・テストとビーコン

テスト

DNS, 29.4.5.1

FTP, 29.4.5.1

SOAP, 29.4.5.1

Webトランザクション, 29.4.5.1

「サービス」コントロール パネル

管理サービスの起動における使用, 27.5

設定

メトリックしきい値, 1.3.1

ホームページの設定, 26.3 レポートの共有, 41.5, 41.5 SNMP, 16.9.3, 16.9.3, 30, 30, 32.5.4, 32.5.4 SNMPトラップ, 30.4 SNMPトラップ, 3.2, 3.5

概要, A

サンプル, 3.5.3

SNMPトラップ, 30.4.1 SNMP.SNMPTimeout, 16.5.2, 16.9.3 ソフトウェア・ライブラリ, 21.2.3

デザイナ, 22.2

オペレータ, 22.2

スーパー管理者, 22.2

ユーザー, 22.2

ソフトウェア・ライブラリ管理, 22.5, 22.5

参照先ファイルの場所, 22.5.2

エージェント記憶域, 22.5.2

http記憶域, 22.5.2

NFS記憶域, 22.5.2

アップロード・ファイルの場所, 22.5.1 ソフトウェア・ライブラリ・コンソール, 22.1 ソフトウェア・ライブラリの参照先の場所, 22.5 ソフトウェア・ライブラリ記憶域, 22 ソフトウェア・ライブラリのアップロード場所, 22.5 スタンバイOMSシステム, パッチ適用, 24.4.6 ステータス・コード, 修正処理, 3.8.1 スイッチ

ポート, 32.2

表示, 32.2

システム・エラー, 通知, 3.10.4.2 システム・パッチ, 24.1.3

T

表

保存期間の変更, 20.2.3

表領域

プラットフォーム間でのトランスポート, 20.5.2.1

ターゲット

定義, 1.1

ターゲットの検出

自動, 15.1.1

EMCLIの使用, 15.1.3

WebLogic 10.x, 15.1.2

WebLogic 9.x, 15.1.2

ターゲット監視資格証明

定義, 27.7

設定, 27.7

ターゲット・プロパティ, 1.4.2 テンプレート・コレクション, 1.4.2, 6.3

管理グループ, 6.3.5

テンプレート・コレクション, 権限, 6.3.4.1 しきい値変更頻度, 適応しきい値, 9.2.1 しきい値

定義, 1.3.1

メトリック, 1.3.1, 1.3.1

時間ベースの静的しきい値, 9.3 時間ベースの静的しきい値, 登録解除, 9.3.2 時間ベースの静的しきい値, 登録, 9.3.1 時間ベースのしきい値, 9 タッチアンドホールド

Cloud Control Mobile, 43.8

トレース・ファイル

管理サービスの内容の制御, 28.4.4

サイズと数の制御, 28.4.3

管理エージェントの検索, 28.3.2

管理サービスの検索, 28.4.2

管理エージェント, 28.3

Oracle Management Service, 28.4

トラブルシューティング

管理リポジトリ作成時の一般的な技術, 20.4.3

管理サービス, 27.19

通知, 3.10.4

管理リポジトリ作成時, 20.4

トラブルシューティング

管理サービスの起動エラー, 27.19

管理エージェントのトラブルシューティング, 27.20 管理エージェント起動エラーのトラブルシューティング, 27.20 サービス・テストのトラブルシューティング, 29.11

Formsトランザクション, 29.11.1

U

プラグインのアンデプロイ, 23.7.1, 23.7.2

Universal Installer, 20.4

更新

オフライン・モードでの適用, 21.3.2

オンライン・モードでの適用, 21.3.1

Cloud Controlの更新, 21 プラグインのアップグレード, 23.6.3, 23.6.5 プラグインのアップグレード, 23.6.3 プラグインのアップグレード, 23.6.3 使用状況メトリック

集計関数

平均値, 29.4.7

最大値, 29.4.7

最小値, 29.4.7

値の合計, 29.4.7

使用状況トラッキング・レポート, 42

V

有効なメトリックしきい値, 確認, 9.4

検証

移行後, 20.5.3

表示

レポート, 41.5

ログの表示, 28.1.1 VPN

Cloud Control Mobileの要件, 43.1

W

Webアプリケーション

ソース

手順, 29.4.6

ステップ・グループ, 29.4.6

トランザクション, 29.4.6

WebLogicドメインのリフレッシュ・ジョブ, 15.2 週次メトリック収集, 有効化, 42.2.2

Z

ゾーン

CPUおよびメモリーのメトリック, 39.7.2

ゾーン

グループへの追加, 39.11.4

管理者アクセス, 39.11.3

すべてのメトリック, 39.8

コンプライアンス, 39.11.1

構成, 39.11.2

検出, 16.3

プロパティの編集, 39.11.5

インシデント, 39.9.1

メトリックと収集設定, 39.10.2

メトリック収集エラー, 39.10.1

メトリック, 39.7

モニタリング, 39.1

モニタリング構成, 39.10.3

プラットフォーム・メトリック, 39.6

プラットフォームのページ, 39.5

モニタリングの一時停止, 39.10.5

モニタリングの一時停止の通知, 39.10.4

ターゲット・ナビゲーション, 39.4

オラクルの法律上の注意点について

コピーライトについて

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

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

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