| Oracle® Enterprise Manager Cloud Control管理者ガイド 12c リリース5 (12.1.0.5) B65081-16 |
|
 前 |
 次 |
Enterprise Manager Cloud Controlのジョブ・システムでは、日常的に繰り返し行われる管理タスクを自動化し、環境内のコンポーネントを同期化することで、より効率的に管理できます。
この章では、次の項の手順に従うことでジョブ・システムの使用が容易になります。
Enterprise Managerジョブ・システムは、次の目的に役立ちます。
バックアップ、クローニング、パッチ適用など、多くの管理タスクを自動化します。
ユーザー独自のカスタムOSスクリプトやSQLスクリプトを使用した、固有のジョブを作成できます。
複数のタスクで構成される独自のマルチタスク・ジョブを作成できます。
ジョブのスケジューリングを単一の堅牢なツールに環境を一元化します。
ジョブとは、頻繁に実行するタスクの自動化を定義するための作業の単位です。スケジュールの柔軟性は、ジョブの長所の1つです。ジョブは、すぐに開始したり、後の日時で開始したりするようにスケジュールできます。ジョブは、1回の実行または特定の間隔(月に3回など)での実行も可能です。
「ジョブ・アクティビティ」ページ(図11-1)は、ジョブ・システムの中枢です。このページからは、次の操作が可能です。
既存のジョブ実行と個別ジョブ実行を検索します。「名前」、「所有者」、「ステータス」、「スケジュール開始」、「ジョブ・タイプ」、「ターゲット・タイプ」、「ターゲット名」などで絞り込みます。
ジョブを作成します。
ジョブ定義を表示または編集します。
ジョブの類似作成、ライブラリへのコピー、一時停止、再開、停止、削除を行います。
結果の表示、ジョブ実行または個別ジョブ実行の編集、類似作成、一時停止、再開、再試行、停止および削除を行います。
「エンタープライズ」メニューから「ジョブ・アクティビティ」ページにアクセスする他に、ターゲット・タイプのメニューから「ジョブ・アクティビティ」を選択して、すべてのターゲット・タイプのターゲット固有のメニューからこのページにアクセスすることもできます。このような別の場所からこのページにアクセスする場合、「ジョブ・アクティビティ」ページには、ジョブの一覧ではなく、特定のターゲットに関連するジョブのサブセットが表示されます。
次の各項では、それぞれの特性について説明します。
個別ジョブ実行は通常、特定のデータベースのパッチ・ジョブなど、単一のターゲットに関連付けられます。ただし、個別ジョブ実行は、必ずしもターゲットへ1対1で割り当てられているとはかぎりません。個別ジョブ実行によっては、ホストの比較など、複数のターゲットに対して実行される場合があります。複数のターゲットに対して実行されるジョブでは、すべてのターゲットを1回の実行で実行する場合と、各ターゲットに対して別々に実行する場合があります。
個別ジョブ実行は通常、特定のデータベースのパッチ・ジョブなど、単一のターゲットに関連付けられます。これらは1回の実行が1ターゲットのみであるため、単一ターゲット・ジョブと呼ばれます。ただし、個別ジョブ実行は、必ずしもターゲットへ1対1で割り当てられているとはかぎりません。個別ジョブ実行によっては、ホストの比較など、複数のターゲットに対して実行される場合があります。これらのジョブは、すべてのターゲットに対して1回のみ実行するため、単一実行ジョブと呼ばれます。複数のターゲットに対して実行されるジョブでは、単一実行ジョブか単一ターゲット・ジョブかによって、1回または多数のジョブが実行されます。わずかですが、ターゲットがないジョブもあります。これらのジョブは、ターゲットのないジョブと呼ばれ、1回の実行で実行されます。
複数のターゲットへジョブを発行する場合、ターゲットごとにジョブの個別実行ステータスを確認するのは大変な作業です。たとえば、複数のデータベースにバックアップ・ジョブを実行するとします。すべてのバックアップ・ジョブが成功したか、成功しなかった場合は、どのジョブが失敗したのかを確認する必要があります。このバックアップ・ジョブを毎週実行する場合は、毎週、どのバックアップが成功して、どのバックアップが失敗したかを把握する必要があります。
ジョブ・システムでは、作成、編集、類似作成、削除などの標準的なジョブ操作のサポートに加えて、次の操作を実行できます。
ジョブの一時停止:
個別ジョブ実行またはジョブ全体を一時停止できます。たとえば、必要なリソースを使用できなかった場合や、ジョブを延期する必要がある場合には、ジョブの中断が必要になる場合があります。
ジョブの繰返しがスケジュールされていても、スケジュールされた繰返し時間や1日の上限を過ぎて一時停止する場合、ジョブの実行は「スキップ」とマークされます。ジョブは、スケジュールされた時間に猶予期間を足した時間が過ぎた場合もスキップされます。
ジョブの再開:
ジョブを一時停止すると、スケジュールされた個別ジョブ実行は、ジョブを再開するまで実行されません。
すべての失敗した実行を1回のジョブ実行で再試行:
個々の実行またはジョブ全体を分析するときに、問題の原因を判別した後で、失敗した実行を再試行すると便利です。こうすると、失敗した実行のために新しいジョブを作成する必要性が少なくなります。「ジョブ・システム」で「再試行」操作を使用するとき、失敗した実行と再試行した実行の間のリンクがEnterprise Managerによって生成されます。これは、失敗した実行の原因を後から調べるために役立ちます。「ジョブ実行」ページには最新のエントリのみが表示されます。
ジョブ・システムでは、ジョブ実行に関して次の操作を行うことができます。
古いジョブ実行の削除
ジョブ実行の停止
すべての失敗した実行を1回のジョブ実行で再試行。正常に実行されると再試行されません。
|
関連項目: 個別ジョブ実行とジョブ実行の詳細は、Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。 |
第11.3項「ジョブの作成」に示す手順情報に進む前に、次の項で説明するトピックに目を通すことをお薦めします。
Enterprise Managerでは、次の管理者タイプが用意されています。
管理者 — ほとんどのジョブその他のアクティビティは、この通常のユーザー・タイプで開始されます。
スーパー管理者 — スーパー管理者向けジョブの実行、ブラックアウトの作成、専用ターゲットという限られた使用状況はありますが、通常は使用しません。
リポジトリ所有者(SYSMAN) — 特別なリポジトリ所有者ユーザーであるSYSMANは、前述の2つのタイプに示すタスクを所有したり実行することはほぼありません。このユーザーはサイトの設置などのような最上位のアクション向けに確保されています。
事前定義済のジョブ・タスクに加え、OSスクリプトやSQLスクリプトに含めるコードを記述し、固有のジョブ・タスクを定義できます。これらのスクリプトの使用には、次のメリットがあります。
これらのジョブの定義時に、ターゲット・プロパティを使用できます。
これらのジョブの定義時に、ジョブ・ライブラリを使用できます。これにより、ジョブを共有でき、問題が発生したときに更新できます。ただし、更新を有効にするために、変済のライブラリ・ジョブを再発行する必要があります。
複数のターゲットに対してジョブを発行できます。
1つのグループに対してジョブを発行できます。ジョブは、自動的にグループ・メンバーシップの変更に対応します。
ホスト・コマンドのジョブでは、クラスタに対してジョブを発行できます。
SQLジョブでは、Real Application Clusterに対してジョブを発行できます。
ジョブ職責の共有を許可するために、ジョブ・システムはジョブ権限を提供しています。これらのジョブ権限を使用し、他の管理者とジョブを共有できます。権限を使用し、次の操作を許可できます。
ジョブの結果を確認する必要がある管理者にアクセス権を付与します。
ジョブ定義の編集や、ジョブ実行の制御(一時停止、再開、停止)が必要な管理者に完全なアクセス権を付与します。
これらの権限を必要に応じて付与できます。
ジョブのターゲットとして、多数のターゲットを個々にリストするのではなく、グループを使用できます。ジョブに選択されたターゲット・タイプと一致するグループのすべてのメンバー・ターゲットは、ジョブを実行する際の実際のターゲットとして選択されます。グループのメンバーシップが変わった場合、それによってジョブの実際のターゲット・リストが変更されます。ジョブを繰り返す場合、そのジョブの反復(実行)ごとに、実行時のグループの一致するターゲットで実行されます。
ターゲット・タイプ選択のオーバーライド
グループに対するターゲット・タイプの選択をオーバーライドするには、targetType=<override_target_type>を入力ファイルのcreate_job動詞に設定します。たとえば、OSコマンド・ジョブのデフォルトのターゲット・タイプはホストです。データベースのグループに対してジョブを送信するには、次のように指定します。
target_list=my_db_group:composite targetType=oracle_database
選択されたターゲット・タイプに一致しないグループのターゲットは無視されます。
「ジョブ・アクティビティ」ページでジョブを作成する際には、最初にジョブ・タイプを選択します。これは、次の「ジョブ・タイプの選択」で説明します。最も一般的なジョブ・タイプは、OSコマンド・ジョブ、スクリプト・ジョブおよびマルチタスク・ジョブです。これらについて次の項で順に説明します。
ジョブ・システムを使用する場合、「ジョブ・アクティビティ」ページの「ジョブの作成」ドロップダウンで、ジョブ・タイプの中からいずれかを選択してジョブを作成できます。よく使用されるタイプは次のとおりです。
OSコマンド - オペレーティング・システムのコマンドまたはスクリプトを実行します。
SQLスクリプト - ユーザー定義のSQLまたはPL/SQLスクリプトを実行します。
マルチタスク - マルチタスク・ジョブまたは修正処理の主な特性を指定します。マルチタスク・ジョブでは、各タスクが独立したジョブとして機能するタスクを定義することにより、コンポジット・ジョブを作成できます。タスクは、通常のジョブと似た方法で編集および定義します。
オペレーティング・システムのコマンドまたはスクリプトを実行するには、このタイプのジョブを使用します。次に、OSコマンドを作成する場合のタスクやその従属手順について説明します。
「エンタープライズ」メニューから「ジョブ」、「ジョブ・アクティビティ」の順に選択します。
「ジョブの作成」ドロップダウンで「OSコマンド」を選択して「実行」をクリックします。「OSコマンド・ジョブの作成」ページの「一般」プロパティ・ページが表示されます。
「一般」プロパティ・ページで次の手順を実行します。
ジョブに必要な名前を指定し、ドロップダウンでターゲット・タイプを選択します。
ジョブに特定のタイプのターゲットを選択すると、その同じタイプのターゲットのみをジョブに追加できます。ターゲット・タイプを変更すると、「ターゲット」表に設定したターゲットと、そのジョブのパラメータおよび資格証明が表示されなくなります。
このジョブのターゲットとしてコンポジットを指定すると、ジョブは選択したターゲット・タイプのコンポジット内のターゲットに対してのみ実行されます。たとえば、ホストとグループのターゲット・タイプをターゲットとして指定すると、グループにホスト以外のターゲットがある場合でも、グループ内のホストに対してのみジョブが実行されます。同じターゲット・タイプのものであれば、ターゲット・リストにクラスタを含めることもできます。たとえば、ターゲット・タイプがホストの場合はホスト・クラスタが選択され、ターゲット・タイプがデータベースの場合はRACデータベースが選択されます。
「追加」をクリックして、「検索と選択: ターゲット」ポップアップ・ウィンドウで1つ以上のターゲットを選択します。「ターゲット」表にターゲットが表示されます。
「パラメータ」プロパティ・ページ・リンクをクリックします。
「パラメータ」プロパティ・ページで次の手順を実行します。
「コマンド・タイプ」ドロップダウンで「単一操作」または「スクリプト」のいずれかを選択します。
指定したコマンドやスクリプトは、ジョブのターゲット・リストに指定された各ターゲットに対して実行されます。管理エージェントは、各ターゲットに対してコマンドやスクリプトを実行します。
目的に応じて次のいずれかのオプションを選択できます。
特定のコマンドを実行する単一操作
OSスクリプトを実行し、スクリプトを処理するインタプリタ(たとえば%perlbin%/perlまたは/bin/sh)をオプションで指定するためのスクリプト。
実行するコマンドを指定する場合で、すべてのホストではスクリプトをインストールおよび更新しない場合、単一のコマンドラインでは不十分なことがあります。この場合、「スクリプト」オプションを使用して、ジョブの一部としてスクリプト・テキストを指定することができます。
目的に応じて、第11.3.2.1項「単一操作の指定」または第11.3.2.2項「スクリプトの指定」の手順に従ってください。
「資格証明」プロパティ・ページ・リンクをクリックします。
|
注意: OSコマンドは、指定したコマンド/インタプリタの実行をターゲット・ホストのシェルに依存します。*nixシステムでは/bin/sh -c、Windowsシステムではcmd /cになります。指定したコマンド・ラインは、対応するシェルで解釈されます。 |
システム・デフォルトの優先資格証明を使用する場合、このページに入力する必要はありません。
「資格証明」プロパティ・ページでは、ターゲット・ホストに対してOSコマンド・ジョブを実行する際にOracle Management Serviceが使用する資格証明を指定できます。ジョブでは、選択したターゲットに対してジョブ発行者のホストベースの優先資格証明を使用することも、他の資格証明を指定して優先資格証明をオーバーライドすることも可能です。
優先資格証明がすでに設定されている場合、このページに入力する必要はありません。
|
ヒント: 優先資格証明は、ジョブが複数のターゲットで送信され、各ターゲットの認証に異なる資格証明を使用する必要がある場合に有用です。 |
優先資格証明を使用するには、次の手順を実行します。
「優先資格証明」ラジオ・ボタン(デフォルト)を選択します。
OSコマンド・ジョブのターゲットがホストまたはホスト・グループの場合、優先ホスト資格証明が使用されます。これらは優先資格証明ページのホスト・ターゲットに指定され、データベースが存在するホストに対するホスト資格証明とは異なります。
「ホスト資格証明」ドロップダウンで「通常ホスト資格証明」または「特権ホスト資格証明」のいずれかを選択します。
これらは、「優先資格証明」ページで指定します(このページは、「設定」メニューの「セキュリティ」、「優先資格証明の順に選択してアクセスします)。「優先資格証明」ページが表示されたら、「優先資格証明の管理」ボタンをクリックして資格証明を設定します。
名前付き資格証明を使用するには、次の手順を実行します。
「名前付き資格証明」ラジオ・ボタンを選択して、データベースまたはホスト優先資格証明をオーバーライドします。
ドロップダウン・リストは、名前と値が一緒に保存されている事前に移入された資格証明のセットです。これらはターゲットにリンクしていませんが、タスクに資格証明と認証情報を提供するために使用できます。
他の資格証明を使用するには、次の手順を実行します。
「新規資格証明」ラジオ・ボタンを選択して、定義済の優先資格証明をオーバーライドします。
資格証明の上書きはすべてのターゲットに適用されることに注意してください。これは名前付き資格証明にも該当します。
実行権限として「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 |
ジョブの発行直後にジョブを実行するデフォルト操作に進む場合、このページに入力する必要はありません。
次のスケジュールのタイプを選択します。
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回の下にある猶予期間の説明を参照してください。
「アクセス」プロパティ・ページ・リンクをクリックします。
ジョブを共有しないシステム・デフォルトを使用して進める場合、このページに入力する必要はありません。表には、ジョブに対して管理者とロールが持つアクセス権が表示されます。ジョブの「アクセス」ページで変更を加えることができるのはジョブ所有者(またはスーパー管理者)のみです。
管理者およびロールのアクセス・レベルを変更するか、管理者およびロールを削除します。変更できる内容はユーザーの役割によって異なります。
ジョブ所有者の場合、次の操作を実行できます。
管理者やロールのアクセスを変更するには、表の「アクセス・レベル」列で「完全」または「表示」アクセス権限を選択します。
管理者やロールのジョブに対するすべてのアクセス権を削除するには、管理者またはロールの「削除」列のアイコンをクリックします。スーパー管理者権限を持つすべての管理者には、ジョブに対する表示アクセス権限があります。ロールにアクセス権限を提供する場合、ロールには完全なアクセス権限ではなく、表示アクセス権限のみを提供できます。プライベート・ロールの場合、完全なアクセス権限を付与することができます。
スーパー管理者の場合、次の操作を実行できます。
Enterprise Managerの他の管理者またはロールに表示アクセス権限を付与します。
すべての管理者のアクセス権限を無効にします。
|
注意: 所有者もスーパー・ユーザーも、スーパー・ユーザーの表示アクセス権限を取り消すことはできません。すべてのスーパー・ユーザーには表示アクセス権限があります。 |
アクセス・レベルの詳細は、第11.3.2.3項「アクセス・レベルのルール」を参照してください。
「追加」をクリックして管理者とロールを追加します。「ジョブの作成」→「管理者およびロールの追加」ページが表示されます。
「検索」セクションで「名前」と「タイプ」を指定し、「実行」をクリックします。名前やタイプを指定せずに「実行」をクリックすると、管理リポジトリのすべての管理者とロールが表に表示されます。
「名前」フィールドに指定した値では大文字/小文字は区別されません。文字列のどの場所にも*または%をワイルドカード文字として指定できます(ワイルドカード文字は文字列の最後に暗黙的に追加されます)。たとえば、「名前」フィールドに%naを指定した場合、ANA、ANA2、CHRISTINAなどの名前を検索結果として「結果」セクションに返すことができます。
「結果」セクションで管理者またはロールを1つ以上選択して「選択」をクリックし、ジョブへのアクセス権を付与します。ジョブの作成: アクセス・ページまたはジョブの編集: アクセス・ページに戻ります。このページでは、管理者およびロールのアクセスを変更できます。
通知ルールを定義します。
通知システム(ルール作成)を使用して、特定のジョブと通知ルールを簡単に関連付けることができます。Cloud Control通知システムでは、ジョブが次のいずれかの選択状態になるとジョブ所有者に電子メールを送信する通知ルールを定義できます。
スケジュール
実行中
一時停止
成功
問題
アクション必須
この時点で、ジョブを発行して実行するか、ジョブをジョブ・ライブラリに保存できます。
ジョブの送信:
「発行」をクリックして、アクティブなジョブを実行するためにジョブ・システムに送信します。その後、「ジョブ・アクティビティ」メイン・ページでジョブの実行ステータスを表示します。ライブラリ・ジョブを作成している場合、「発行」ボタンによりジョブがライブラリに保存され、メインの「ジョブ・ライブラリ」ページに戻ります。このページで、その他のライブラリ・ジョブの編集または作成が可能です。
問題(パラメータや資格証明が見つからないなど)があるジョブを発行すると、エラーが表示され、アクティブなジョブを発行する前に問題を修正する必要があります。ライブラリ・ジョブの場合、不完全な仕様が許可されるため、エラーは発生しません。
|
注意: アクセス権を変更せずに「発行」をクリックする場合、スーパー管理者のみがジョブを表示できます。 |
ライブラリへのジョブの保存:
「ライブラリに保存」をクリックして、頻繁に使用されるジョブのリポジトリとしてのジョブ・ライブラリにジョブを保存します。他の管理者は、アクセス権限が提供される場合、ライブラリ・ジョブの共有や再利用が可能です。アクティブ・ジョブと同様に、特定の管理者に表示権限または完全なアクセス権限を付与できます。さらに、ジョブ・ライブラリを使用して次の内容を保存できます。
ジョブの基本定義、さらにターゲットおよびその他のカスタム設定(ジョブ発行前に追加可能)。
自身で再利用、または他のユーザーと共有するためのジョブ。ジョブへの表示アクセス、または完全なアクセス権限を付与し、ジョブを共有できます。
後から再発行するクリティカル・ジョブ。または、問題が発生した場合に修正されたジョブ。
「コマンド」フィールドに完全なコマンドを入力します。次に例を示します。
/bin/df -k /private
単一操作の指定については次の点に注意してください。
コマンドの一部として、シェル・コマンドを使用できます。プラットフォームのデフォルトのシェル(Linuxでは/bin/sh、Windowsではcmd/c)が使用されます。
ls -la /tmp > /tmp/foobar.out
2つの連続したシェル・コマンドを実行する必要がある場合、「コマンド」フィールドでシェルを起動し、「OSスクリプト」フィールドでコマンド自体を起動する必要があります。「コマンド」フィールドでは次のように指定します。
sleep 3; ls
ジョブ・ステータスは、コマンドによって返された終了コードに依存します。コマンドの実行が0を返す場合、ジョブは「成功」のステータスを返します。その他の値を返す場合は、「失敗」のジョブ・ステータスを返します。
「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
スーパー管理者には、常にジョブに対する表示アクセス権限があります。
ジョブを所有するEnterprise Manager管理者は、ジョブに対するアクセス権限を変更できます(スーパー管理者からの表示権限の取消しを除く)。
ジョブに対して表示または完全アクセス・レベルを持つスーパー管理者は、新しいユーザーに表示(完全ではない)権限を付与できます。スーパー管理者は、通常のユーザーの完全権限および表示権限を取り消し、スーパー管理者の完全権限を取り消すこともできます。
完全アクセス・レベルを持つ通常のEnterprise Manager管理者は、ジョブに対するアクセス権限は変更できません。
ジョブ所有者がジョブに対して類似作成操作を実行する場合、新しいジョブのすべてのアクセス権限は元のジョブと同じになります。ジョブ所有者が他の管理者の表示または完全ジョブ・アクセス権限を他の管理者に付与する場合、これらの管理者はそのジョブに対して類似作成操作を実行し、すべての管理者には新しく作成されたジョブに対する表示アクセス権限がデフォルトで保持されます。
SQLスクリプト・ジョブを作成する基本プロセスは、第11.3.2項「OSコマンド・ジョブの作成」で説明するプロセスと同じです。次の項では、スクリプト・ジョブに固有の補足情報について説明します。
SQLスクリプト・ジョブはデータベースとクラスタ・データベースのターゲット・タイプに対して実行できます。ジョブを実行するターゲットを選択するには、次の手順を実行します。
「ターゲット」セクションで「追加」をクリックします。
ポップアップでデータベース・ターゲットを選択します。
選択内容が「ターゲット」表に表示されます。
|
注意: クラスタ・ホストまたはRACデータベースの場合、データベース・インスタンスの数にかかわらず、ジョブがターゲットに対して実行されるのは一回のみです。そのため、RACクラスタのすべてのノードでジョブを実行することはできません。 |
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のオプション・パラメータを 「パラメータ」 フィールドに入力できます。
「資格証明」プロパティ・ページで、ホスト資格証明とデータベース資格証明を指定します。管理エージェントは、ホスト資格証明を使用してSQL*Plus実行可能ファイルを起動し、データベース資格証明でターゲット・データベースに接続してSQLスクリプトを実行します。ジョブは、ホストとデータベースに対して優先資格証明を使用するか、優先資格証明よりも優先される他の資格証明を指定できます。
優先資格証明の使用:
SQLスクリプト・ジョブのターゲットに対して優先資格証明を使用する場合はこのオプションを選択します。ホストとデータベースの両方に使用される資格証明は、ドロップダウンで指定した資格証明になります。「通常データベース資格証明」を選択する場合、通常のデータベース優先資格証明が使用されます。「SYSDBAのデータベース資格証明」を選択する場合、SYSDBA優先資格証明が使用されます。どちらの場合も、データベース・ターゲットに関連付けられたホスト資格証明が使用されます。ジョブを実行するたびに、優先資格証明の現在の値が取得されます。
名前付き資格証明:
すべてのターゲットに対して優先資格証明を上書きする場合はこのオプションを選択し、すべてのターゲットでジョブが使用する名前付き資格証明を入力します。
多くのIT組織ではパスワードを定期的に変更することが求められます。このオプションを使用して、すべての優先資格証明のパスワードを変更できます。Enterprise Managerは実行時に資格証明の現在の値(ユーザー名およびパスワード)を使用するため、優先資格証明を使用するジョブおよび修正処理は新しく変更された値を自動的に取得します。また、名前付き資格証明は集中管理されます。名前付き資格証明の変更は、その資格証明を使用するすべてのジョブまたは修正処理に伝播されます。
修正処理の場合、優先資格証明を指定すると、Enterprise Managerは修正処理を編集した最後のEnterprise Managerユーザーの優先資格証明を使用します。このため、1番目のユーザーが最初に指定した修正処理を編集しようとする場合、Enterprise Managerでは、その修正処理に使用される資格証明を別のユーザーが指定する必要があります。
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;
マルチタスク・ジョブを作成する基本プロセスは、第11.3.2項「OSコマンド・ジョブの作成」で説明するプロセスと同じです。次の項では、マルチタスク・ジョブに固有の補足情報について説明します。
マルチタスクのジョブを使用し、1つ以上の別個のタスクから構成される複雑なジョブを作成できます。マルチタスクのジョブは同じタイプまたは異なるタイプのターゲットに対して実行できるため、同じタイプまたは異なるタイプの1つ以上のターゲットに対して非定型操作を実行できます。
ジョブ・システムのマルチタスク機能により、非常に複雑な操作を簡単に作成できます。すべてのタスクが単一のターゲットで実行されるマルチタスクのジョブを作成できます。各ジョブのジョブ・タイプが異なり、各タスクが別のターゲット・タイプで動作する複数のタスクで構成されるマルチタスクのジョブも作成できます。次に例を示します。
タスク1(ジョブ・タイプはOSコマンド)はホスト1に対して動作します。
タスク1が成功すると、タスク2(ジョブ・タイプはSQLスクリプト)をデータベース1およびデータベース2に対して実行します。
マルチタスクのジョブは、タスクとして使用可能なジョブが定義されるターゲットに対して実行できます。すべてのジョブ・タイプをタスクとして使用できるわけではありません。
「一般」ページの「ターゲット」ドロップダウンでは、すべてのタスクに対する同じターゲット、または異なるタスクに対する別のターゲットに対してジョブを実行できます。マルチタスクのジョブの各タスクは完全なジョブとみなされるため、「すべてのタスクに対して同じターゲット」オプションを選択すると、ジョブが「一般」ページから実行されるすべてのターゲットを追加します。「異なるタスクに対して別のターゲット」オプションを選択した場合、各タスクの定義どおりにタスクが実行されるターゲット(および必要な資格証明)を指定します。
「ターゲット」ドロップダウンで選択した後、「ターゲット」セクションの「追加」をクリックしてジョブを実行するターゲットを選択します。
「タスク」ページを使用して次の操作を実行できます。
各種ジョブ・タイプのタスクの追加、削除、編集
タスク条件および依存ロジックの設定
タスクのエラー処理の追加
「条件」オプションと「依存先」オプションを設定するには、少なくとも2つのタスクを定義する必要があります。タスク条件は、タスクが実行される状態を定義します。条件オプションは次のとおりです。
常時 - ジョブの実行のたびにタスクが実行されます。
成功時 - タスク実行は、別のタスクの実行が成功するかどうかに依存します。
失敗時 - タスク実行は、別のタスクの実行が失敗するかどうかに依存します。
エラー処理タスクは、多くの場合、ジョブの一部の状態を取り消すことができる「クリーンアップ」手順になります。マルチタスク・ジョブのタスクにエラーが発生した場合、エラー・ハンドラ・タスクが実行されます。エラーは深刻な失敗であり、通常はジョブ・システムがタスクを実行できません。通常、失敗は、タスクが実行したが正常に終了しなかったことを示します。エラー処理タスクによって、ジョブの実行ステータスが影響を受けることはありません。エラー処理に使用されるタスクのジョブ・タイプを指定するには、「タスク・タイプの選択」ページを使用します。
すべてのジョブの集計ステータスの表示
ジョブの発行後、すべてのターゲットに対するすべての個別ジョブ実行は自動的にロールアップされ、「エンタープライズ・サマリー」ページで参照できるようになります。図11-2に、「エンタープライズ・サマリー」ページの下部にある「ジョブ」セクションを示します。
この情報は、何百、何千というシステムに対しジョブを実行する場合には特に重要となります。失敗した個別ジョブ実行を特定することもできます。特定の個別実行に関連付けられた数字をクリックすると、ドリルダウンして失敗したジョブの詳細を参照できます。
特定のジョブの一般ステータスの表示
特定のジョブまたは送信済ジョブの一般ステータス情報を表示するには、図11-1に示す「ジョブ・アクティビティ」ページでジョブを検索します。
ジョブ実行のステータスの表示
単一実行または複数実行についての詳細情報を表示できます。単一実行には単一の手順と複数の手順があります。
実行のステータスを表示するには次の手順を実行します。
「ジョブ・アクティビティ」ページで、対象のジョブの「名前」リンクまたは「ステータス」リンクをクリックします。
図11-3に示すとおり、「ジョブ実行」ページが表示されます。
詳細は、特定の実行または手順の「ステータス」リンクをクリックします。
拡張ビューへの切替え
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の再起動を必要としません。 |
単一実行によるジョブ実行の拡張ステータスの表示
単一実行には単一の手順と複数の手順があります。単一実行のステータスを表示するには次の手順を実行します。
「ジョブ・アクティビティ」ページで、単一実行を含むジョブの「名前」リンクまたは「ステータス」リンクをクリックします。
タスク・リスト表のタスクまたは手順をクリックします。
図11-4に示すとおり、特定の実行についての詳細がページの右側に表示されます。
複数実行によるジョブ実行の拡張ステータスの表示
複数実行のステータスを表示するには次の手順を実行します。
「ジョブ・アクティビティ」ページで、複数実行を含むジョブの「名前」リンクまたは「ステータス」リンクをクリックします。
ジョブ実行ページが表示されます。
左側の表で、対象の実行をクリックします。
図11-5に示すとおり、特定の実行についての詳細がページの右側に表示されます。
ジョブ・システムは、ジョブがその実行ステータスを変更したときにステータス変更イベントを発行し、これらのイベントは実行ステータスに基づいて異なる重大度を持ちます。
「ジョブ・イベント生成基準」ページ(図11-6)を使用して、ジョブ・イベント通知のターゲットを設定します。このページでは、イベントまたは通知を発生させる対象のジョブ、ターゲットまたはステータスを決定できます。これにより、ユーザーは有効なイベントのみを発生できます。このページで行う設定によって、ジョブの動作が変更されることはありません。インシデント・ルール・セットを使用してジョブ・イベントに関する通知を設定できます。
このページにアクセスするには、「設定」メニューから「インシデント」、「ジョブ・イベント」の順に選択します。
ジョブ・ステータスとターゲットのないジョブのイベントを有効化するには、次の手順を実行します。
イベントを生成するジョブ・ステータスを選択するために、スーパー管理者権限があることを確認します。
ターゲットを追加するためのターゲット表示権限を持つ管理者であることを確認します(スーパー管理者によって設定されたジョブ・ステータスに関して、このターゲットに対してイベントを生成します)。
スーパー管理者としてCloud Controlにログインします。
「設定」メニューで「インシデント」、「ジョブ・イベント」の順に選択します。ジョブ・イベント生成基準ページが表示されます。
「ジョブ・イベント生成基準」ページで次の手順を実行します。
「ジョブ・ステータスのイベントを有効化します」リージョンで、イベントを発行するステータスを選択します。
「ステータス重大度のイベントの有効化」リージョンで、クリティカル・ステータス、情報ステータス、またはその両方についてのイベントを有効にするかどうかを選択します。
ターゲットと関連付られていないジョブのイベントを作成する場合は、「ターゲットのないジョブのイベントを有効化します」セクションで「はい」を選択します。
「ターゲットのイベント」セクションで「追加」をクリックし、ジョブ・イベントを有効にするターゲットを追加します。
「適用」をクリックします。
ジョブ・ステータスを発行するイベントをスーパー管理者が選択したら、管理者はイベントを生成するためのターゲットを追加できます。ターゲットを追加して、ジョブ・ステータスのイベントを生成するには、次の手順を実行します。
スーパー管理者によって設定されたジョブ・ステータスに対して、イベントを生成するターゲットを追加するためのターゲット表示権限を持つ管理者であることを確認します。
管理者としてCloud Controlにログインします。
「設定」メニューで「インシデント」、「ジョブ・イベント」の順に選択します。ジョブ・イベント生成基準ページが表示されます。
「ジョブ・イベント生成基準」ページで次の手順を実行します。
「ジョブ・ステータスとターゲットのないジョブのイベント」セクションで、イベントを発行可能なステータスを確認できます。また、ターゲットのないジョブのフィルタに対してイベントが有効になっているかどうかも確認できます。
「ターゲットのイベント」セクションで「追加」をクリックして、ジョブ・イベントを有効にするターゲットを追加します。「削除」をクリックすることで、ジョブ・イベントを有効にしないターゲットを削除することもできます。
|
注意: 「ターゲットのイベント」セクションで選択した設定はグローバルに適用されます。イベントのターゲットを追加または削除すると、他のEnterprise Managerユーザーにも影響します。 |
「適用」をクリックします。
Enterprise Managerでは、ルールを作成して、イベント、インシデントおよび問題に適用することができます。ルールが適用されるのは、新規作成または更新されたイベント、インシデントまたは問題が、ルールに定義された条件と一致するときです。ジョブ・ステータス変更イベントのイベント・ルールを作成する方法を次に説明します。
ジョブのジョブ・ステータス変更イベント・ルールを作成するには、次の手順を実行します。
関連するジョブ・ステータスが有効になっていることと、必要なターゲットがジョブ・イベント生成基準に追加されていることを確認します。
ジョブ・ステータス変更イベントのイベント・ルールを作成するための管理者権限があることを確認します。
管理者としてCloud Controlにログインします。
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール・ページが表示されます。
インシデント・ルール・ページで、「ルール・セットの作成」をクリックしてインシデントのルールを作成します。
「名前」と「説明」を指定し、「有効」を選択してルール・セットを有効にします。すべてのEnterprise Managerにルールを設定する場合は、タイプとして「エンタープライズ」を選択します。特定のユーザーのみに対してルールを設定する場合は「プライベート」を選択します。「適用先」で「ジョブ」を選択します。
「ジョブ」タブで「追加」をクリックし、イベント・ルールを作成するジョブを追加します。
「ジョブの追加」ダイアログ・ボックスで、「パターン別」でジョブを選択する場合は、「類似ジョブ名」を指定して「ジョブ・タイプ」を選択します。「類似ジョブ所有者」を指定します。「特定のジョブ」の選択では、ジョブを選択します。「OK」をクリックします。
「ルール」タブで「作成」をクリックします。
表示される「作成するルールのタイプを選択」ダイアログ・ボックスで、作成するルール・セットに応じて次の項目から選択できます。
「受信イベントおよびイベントの更新」。通知を受信するか、ジョブ・ルールのインシデントを作成します。イベントに対して処理する場合(たとえば、ジョブ失敗などの受信イベントに対して、インシデントの作成やユーザーへの通知を行う場合)は、このオプションを選択します。
「新たに作成されたインシデントおよびインシデントの更新」。インシデントの生成対象のイベントに関連付けられたルールがなくても、通知を受信するか、インシデントのルールを作成します。作成済のインシデントまたは新規作成されるインシデントに対して処理する場合(たとえば、特定のグループfooに関連するすべてのインシデントを特定のユーザーに送るか、オープンしている期間が3日を超えたすべてのインシデントを昇格する場合)は、このオプションを選択します。
「新たに作成された問題および問題の更新」。問題が生成された対象のインシデントに関連するルールがなくても、通知を受信するか、問題のルールを作成します。このオプションはジョブには適用されません。
「受信イベントおよびイベントの更新」を選択し、「新規ルールの作成: イベントの選択」ページで、次の手順を実行します。
「選択基準」の「タイプ」を「ジョブ・ステータスの変更」にします。選択したジョブのすべてのジョブ・ステータス変更イベントに対して、アクションを実行する場合は、「タイプジョブ・ステータスの変更のすべてのイベント」を選択します。特定のジョブ・ステータスに対してのみアクションを実行する場合は、「タイプジョブ・ステータスの変更の特定のイベント」を選択します。「タイプジョブ・ステータスの変更の特定のイベント」を選択した場合は、ルールを作成するイベントのジョブ・ステータスを選択します。
次の図に示されているように、ルールを設定するための他の基準を設定します。
インシデントに関連付けられたイベントに通知ルールがなくても、インシデントのためのルールを作成する場合は、「新たに作成されたインシデントおよびインシデントの更新」を選択します。「新規ルールの作成: インシデントの選択」ページで、次のいずれかを選択します。
「すべての新しいインシデントおよび更新されたインシデント」(新しいインシデントと更新されたインシデントすべてにルールを適用する場合)
「すべての新しいインシデント」(すべての新しいインシデントにルールを適用する場合)
「特定のインシデント」(インシデントの基準も選択)
「新規ルールの作成: アクションの追加」ページで、「追加」をクリックしてアクションをルールに追加します。
「条件付きアクションの追加」ページで、イベントがルールを満たしたときに実行するアクションを指定します。
「アクションの条件」セクションで次のいずれかを選択します。
「常にアクションを実行」(イベントに関係なくアクションを実行する場合)
「指定された条件に一致する場合のみアクションを実行」(特定の基準と一致するときにアクションを実行する場合)
イベントにアクションを追加するときは、次の項目を指定します。
イベントのインシデントを作成して解決方法を管理および追跡するには、「インシデントの作成」を選択します。
「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。
イベントを生成した問題が解決された後でイベントをクリアする場合は、「イベントのクリア」セクションで「完全にクリア」を選択します。
イベント接続を構成している場合は、「イベント・コネクタに転送」セクションでイベントをサードパーティのイベント管理システムに送信できます。
インシデントにアクションを追加するときは、次の項目を指定します。
「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。
「インシデントの更新」セクションで、インシデントの発生時に優先順位を決定するための詳細を指定します。「割当て先」、「優先度の変更」、「ステータスの設定」および「エスカレート先」の詳細を指定します。
チケット・デバイスを構成している場合は、「チケットの作成」セクションで、チケットを作成するための詳細を指定します。
「続行」をクリックします。
名前と説明の指定ページで、イベント・ルールの「名前」と「説明」を指定します。「次」をクリックします。
「確認」ページでイベント・ルールに選択した詳細を確認し、「続行」をクリックすると、このルールがルール・セットに追加されます。
「ルール・セットの作成」ページで「保存」をクリックして、ルール・セットを保存します。
ターゲットのジョブ・ステータス変更イベント・ルールを作成するには、次の手順を実行します。
関連するジョブ・ステータスが有効になっていることと、必要なターゲットがジョブ・イベント生成基準に追加されていることを確認します。
ジョブ・ステータス変更イベントのイベント・ルールを作成するための管理者権限があることを確認します。
管理者としてCloud Controlにログインします。
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。インシデント・ルール・ページが表示されます。
インシデント・ルール・ページで、「ルール・セットの作成」をクリックしてインシデントのルールを作成します。
「名前」と「説明」を指定し、「有効」を選択してルール・セットを有効にします。すべてのEnterprise Managerにルールを設定する場合は、タイプとして「エンタープライズ」を選択します。特定のユーザーのみに対してルールを設定する場合は「プライベート」を選択します。「適用先」で「ターゲット」を選択します。
「ターゲット」タブで次のいずれか1つを選択します。
すべてのターゲットに適用する場合は、「すべてのターゲット」を選択します。「除外されたターゲット」セクションで「追加」をクリックし、ルール・セットから除外するターゲットを検索して選択します。「選択」をクリックします。
ルール・セットを適用するターゲットのタイプを選択する場合は、「タイプのすべてのターゲット」を選択します。
ターゲットを個々に指定する場合は、「特定のターゲット」を選択します。「グループ」または「ターゲット」のどちらを追加するかを選択して、グループまたはターゲットを追加し、「追加」をクリックして、ルール・セットを適用するターゲットを検索および選択します。「選択」をクリックします。「除外されたターゲット」セクションで「追加」をクリックし、ルール・セットから除外するターゲットを検索して選択します。「選択」をクリックします。
「ルール」タブで「作成」をクリックします。
「作成するルールのタイプを選択」ダイアログ・ボックスで、作成するルール・セットに応じて次の項目から選択します。
「受信イベントおよびイベントの更新」。通知を受信するか、ジョブ・ルールのインシデントを作成します。イベントに対して処理する場合(たとえば、ジョブ失敗などの受信イベントに対して、インシデントの作成やユーザーへの通知を行う場合)は、このオプションを選択します。
「新たに作成されたインシデントおよびインシデントの更新」。インシデントの生成対象のイベントに関連付けられたルールがなくても、通知を受信するか、インシデントのルールを作成します。作成済のインシデントまたは新規作成されるインシデントに対して処理する場合(たとえば、特定のグループfooに関連するすべてのインシデントを特定のユーザーに送るか、オープンしている期間が3日を超えたすべてのインシデントを昇格する場合)は、このオプションを選択します。
「新たに作成された問題および問題の更新」。問題が生成された対象のインシデントに関連するルールがなくても、通知を受信するか、問題のルールを作成します。このオプションはジョブには適用されません。
「受信イベントおよびイベントの更新」を選択し、「新規ルールの作成: イベントの選択」ページで、次の手順を実行します。
「選択基準」の「タイプ」を「ジョブ・ステータスの変更」にします。選択したジョブのすべてのジョブ・ステータス変更イベントに対して、アクションを実行する場合は、「タイプジョブ・ステータスの変更のすべてのイベント」を選択します。特定のジョブ・ステータスに対してのみアクションを実行する場合は、「タイプジョブ・ステータスの変更の特定のイベント」を選択します。「タイプジョブ・ステータスの変更の特定のイベント」を選択した場合は、ルールを作成するイベントのジョブ・ステータスを選択します。
この図のように、ルールを設定するための他の基準を設定します。
インシデントに関連付けられたイベントに通知ルールがなくても、インシデントのためのルールを作成する場合は、「新たに作成されたインシデントおよびインシデントの更新」を選択します。「新規ルールの作成: インシデントの選択」ページで、次のいずれかを選択します。
「すべての新しいインシデントおよび更新されたインシデント」(新しいインシデントと更新されたインシデントすべてにルールを適用する場合)。
「すべての新しいインシデント」(すべての新しいインシデントにルールを適用する場合)。
「特定のインシデント」(インシデントの基準も選択)。
「新規ルールの作成: アクションの追加」ページで、「追加」をクリックしてアクションをルールに追加します。
「条件付きアクションの追加」ページで、イベントがルールを満たしたときに実行するアクションを指定します。
「アクションの条件」セクションで次のいずれかを選択します。
「常にアクションを実行」(イベントに関係なくアクションを実行する場合)
「指定された条件に一致する場合のみアクションを実行」(特定の基準と一致するときにアクションを実行する場合)
イベントにアクションを追加するときは、次の項目を指定します。
イベントのインシデントを作成して解決方法を管理および追跡するには、「インシデントの作成」を選択します。
「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。
イベントを生成した問題が解決された後でイベントをクリアする場合は、「イベントのクリア」セクションで「完全にクリア」を選択します。
イベント接続を構成している場合は、「イベント・コネクタに転送」セクションでイベントをサードパーティのイベント管理システムに送信できます。
インシデントにアクションを追加するときは、次の項目を指定します。
「通知」セクションの「電子メール宛先」、「電子メールCc」および「ページ」フィールドで、通知の受信者を指定します。この受信者は、条件が設定されたイベントが発生したときに電子メールを受け取ります。「詳細」オプションや「繰返し通知」オプションを設定した場合は、それらを指定します。
「インシデントの更新」セクションで、インシデントの発生時に優先順位を決定するための詳細を指定します。「割当て先」、「優先度の変更」、「ステータスの設定」および「エスカレート先」の詳細を指定します。
チケット・デバイスを構成している場合は、「チケットの作成」セクションで、チケットを作成するための詳細を指定します。
「続行」をクリックします。
名前と説明の指定ページで、イベント・ルールの「名前」と「説明」を指定します。「次」をクリックします。
「確認」ページでイベント・ルールに選択した詳細を確認し、「続行」をクリックすると、このルールがルール・セットに追加されます。
「ルール・セットの作成」ページで「保存」をクリックして、ルール・セットを保存します。
次の各項では、ここに示す診断トピックのための手順について説明します。
目的のために、オブジェクト・ロギングを有効化または無効化できます。
スケジュールされたジョブに関するジョブ・ロギングを有効化する手順は次のとおりです。
Cloud Controlコンソールの「エンタープライズ」メニューから「ジョブ」、「アクティビティ」の順に選択します。
「上位アクティビティ」表で、記録するジョブのリンクをクリックします。
「ジョブ実行」表で、ジョブの「スケジュール」リンクをクリックします。
表示された「実行」ページで、「デバッグ」をクリックします。
「DEBUGレベルで正常にロギングが有効化されました」という確認メッセージが表示されます。
特定のジョブについてユーザーに表示可能なロギングがある場合は、次の手順を実行することでジョブ実行ログを表示できます。
「上位アクティビティ」ページで、ログを表示するジョブのリンクをクリックします。
「ジョブ実行」表で、ジョブの「ログ・レポート」をクリックします。
「ジョブ実行」ページの「ステータス」列に表示されるリンクをクリックし、「実行」ページの「ログ・レポート」をクリックすることで、次に示すとおり、「実行」ページからもジョブ・ロギングにアクセスできます。
ジョブ・ステップのログを表示するには、次の手順を実行します。
「上位アクティビティ」ページで、ログを表示するジョブのリンクをクリックします。
「ジョブ実行」表で、調べたいステップの「ステータス」列に表示されるリンクをクリックします。
ステップの「出力ログ」が表示されます。
実行に失敗し、事前にロギング・レベルとしてデバッグを設定していなかった場合、実行の再試行時にデバッグ・レベルの設定を選択できます。新規のジョブを実行する場合、「デバッグ」ボタンをクリックすることで、前もってデバッグ・レベルでのロギングを設定できます。オブジェクト・ロギング・フィールドには、ロギングがデバッグ・レベルで有効化されているかどうかが示されます。
失敗したジョブを検出した場合、次の手順を実行します。
失敗したジョブ・ステップを表示します。
失敗したステップの出力を確認します。すべてのステップのみでなく、特定のステップについても集計されたジョブ出力が表示されます。
出力に失敗の理由が含まれない場合、ロギング出力を表示します。また、ジョブの実行時に発生したインシデントを確認することもできます。
失敗の原因を確認し、問題を修正します。
デバッグ・モードを有効にしてから、ジョブを再発行します。
デバッグ・モードのチェック・ボックスが確認ページに表示されるのは、前回の実行がデバッグ・モードではなかった場合のみです。前回の実行がすでにデバッグ・モードであった場合、再試行の実行は自動的にデバッグ・モードになります。
内部コード・エラー、深刻なスケーリングの問題、または他のEnterprise Managerの問題のために、ジョブが失敗する可能性があります。これらに関してインシデントまたはイベント証跡を調べることができます。たとえば、すべてのジョブ・ワーカーがスタックしたためにOMSがバウンスすると、多くのジョブが失敗します。ローダーで障害が発生した場合にも、一部のジョブが失敗します。
ジョブの時間枠内のインシデントまたはアラートを確認します。
インシデントを確認するため、Cloud Controlコンソールの「エンタープライズ」メニューから「サマリー」を選択し、「エンタープライズ・サマリー」ページの「インシデント」セクションを表示します。
詳細は、「エンタープライズ」メニューから「監視」、「サポート・ワークベンチ」の順に選択します。
アラートを確認するには
関連するインシデントまたはイベント・データとともにサービス・リクエストを送信します。
特定のジョブに関するすべてのステップ出力、エラー出力、ロギング、リモート・ログ・ファイルおよびインシデント・ダンプ・ファイルが1つのインシデントについて取得されます。
サービス・リクエストを送信するには、コンソールの「エンタープライズ」メニューから「My Oracle Support」を選択し、「サービス・リクエスト」を選択します。
技術的SRを作成するには、「サービス・リクエスト」ホームページの「SRの作成」をクリックします。問合せSRを作成するには、「問合せサービス・リクエスト」リージョンの一番上にある「「問合せ」SRの作成」をクリックするか、My Oracle Supportページの上部にある「問合せ」をクリックします。技術的サービス・リクエストを作成する場合、プロファイルに登録されているサポートIDに応じて、ハードウェアSRまたはソフトウェアSR (あるいはその両方)を作成できます。
サービス・リクエストの作成ウィザードでは、製品情報の指定プロセスを段階的に実行し、SRがOracleサポートにファイルされる際に、構成情報をSRに添付します。Oracleサポートに最新の正しいターゲット情報があるようにするには、「ステップ1: 問題」の「問題は何ですか。」セクションで、「構成」タブを選択してからターゲットを選択してください。
サポートから提供されるパッチを適用します。
「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。
ログイン資格証明を指定し、「実行」をクリックします。
このページの詳細は、オンライン・ヘルプを確認してください。
パッチが適用されたら、再度ジョブを送信してみます。
インシデントをパッケージングするか、インシデントを手動でトリガーするには、次の手順に従います。
サポート・ワークベンチにアクセスします。
ジョブ関連のすべてのダンプおよびログ・ファイルとともに同時期の他のデータを収集し、サポートに送るためにパッケージングします。
関連するエラーを検索しながらサポート・ワークベンチでインシデント関連のデータを確認します。
サポートの介入なしで根本原因を特定できたら、ジョブを修正して再発行します。
インシデント(およびそこに含まれる問題)は、デフォルトではパッケージ化されていません。重要で関連性のある問題をサポート・ワークベンチでパッケージ化する必要があります。すべての問題をパッケージ化するか、または一部のみをパッケージ化するかを選択できます。
|
注意: リモート・ログ・ファイルを使用するジョブがインシデントに含まれる場合、そのリモート・ログファイルは、パッケージ化の過程で自動的にインシデントに含められます。リモート・ログ・ファイルの詳細は、第11.7.6項「リモート・ログ・ファイルの表示」を参照してください。 |
ジョブ・ステップで生成されるインシデントをパッケージ化するには、次の手順に従います。
「ログ・レポート」ページで、次に示す「インシデントID」リンクをクリックします。
次に示す、サポート・ワークベンチの「インシデントの詳細」ページで「問題キー」リンクをクリックします。
サポート・ワークベンチの「問題の詳細」ページで、「問題のパッケージ化」リンクまたは次に示す「クイック・パッケージ」ボタンのいずれかをクリックし、「クイック・パッケージ」ウィザードとオンライン・ヘルプの手順に従います。
一部のジョブまたはProvisioning Adviser Framework (PAF)のプロシージャによって、DBCAやインストーラのような外部コマンドが実行されます。このようなコマンドによって、専用のログ・ファイルがシステムのローカルとこれらを実行したOracleホームに生成されます。
リモート・ログファイルを表示するには、次の手順に従います。
「上位アクティビティ」ページで、ログを表示するジョブのリンクをクリックします。
「ジョブ実行」表で、ジョブの「ログ・レポート」をクリックします。
「ログ・レポート」ページで、次に示す「リモート・ログ・ファイル」リンクをクリックします。
ホスト資格証明を指定し、「OK」をクリックします。
リモート・ファイル・ビューアにファイルの内容が表示されます。
コンソールのCloud Control管理部分は、ジョブ・システムの現在の状態を評価し、最適なパフォーマンスのための適切なアクションを判断できるように支援するいくつかのツールを提供します。これらのツールはすべてCloud Controlコンソールの「設定」メニューからアクセス可能です。
次の各項では、使用可能な各ツールについて説明します。
Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。
「状態の概要」サブメニューを選択します。
「状態の概要」ページの「ジョブ・システム・ステータス」リージョンに、次の情報が表示されます。
ステップ・スケジューラ・ステータス
ジョブ・ステップ・スケジューラは、実行準備ができているジョブ・ステップを処理します。ジョブ・ステップ・スケジューラが警告モードまたはエラー・モードで実行中であることがステータスに示される場合、ジョブ・システムは正常に機能していません。この場合、ジョブ・システムをフェイルオーバー・モードで実行することができ、ジョブ・ステップ・スケジューラによって定期的に実行されるタスクをジョブ・ディスパッチャ・プロセスが実行することもできます。ただしジョブ・システムは、本来の能力よりも低い状態で実行されている場合があるため、この状況の解決は有益です。
次のようなメッセージが表示される場合があります。
ステップスケジューラのための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を増やします。
遅延の理由が不明です
これは通常、前述の基準のいずれも満たさなかったために表示される、最も一般的な警告です。利用可能なワーカーよりも作業が多いために、ディスパッチャが過負荷であるだけの場合があります。この場合はバックログを確認します。この状況は自動的に解消されるはずですが、引続き残る場合は、ジョブ・システムに利用可能なワーカーの数がサイトで処理されたことのある負荷に対して不十分であることが考えられます。
ジョブ・バックログ
ジョブ・バックログは、その予定時刻を過ぎてもまだ実行されていないジョブ・ステップの数を示します。この数が大きく、かつ長期間減少しない場合、ジョブ・システムは正常に機能していません。この状況は通常、ジョブ・エンジンのリソースが、システムまたはユーザー・アクティビティによるジョブの処理量を満たすことができない場合に発生します。
それらが長期間スタックされることによる特定ジョブの異常な処理のために、バックログが高くなる場合があります。スタック・ジョブのワーカー・スレッドに関する詳細は、次の手順を実行してください。
「状態の概要」ページの「OMSとリポジトリ」メニューから「監視」、「診断メトリック」の順に選択します。
ジョブ・システムに長期間バックログがある場合、またはバックログを速く処理する場合、次のパラメータにemctl set propertyコマンドを設定できます。これらの設定は、より多くの負荷をサポートできる十分なデータベース・リソースがあることを前提としています。これらのパラメータは2 OMSノードのある大規模な構成で必要となる場合があります。
表11-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のデータベースに設定するプロセスの増加が必要な場合があります。 |
|
Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。
「リポジトリ」サブメニューを選択します。
「管理サービスとリポジトリ」ページの「リポジトリ・スケジューラ・ジョブ・ステータス」表に、ジョブ・システムのパージ・ステータスと次の実行スケジュールが表示されます。
「すべてのメトリック」ページへのアクセスには、2つのナビゲーション方法があります。
「設定」メニューから
「ターゲット」メニューから
「設定」メニューのナビゲーション
Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。
「状態の概要」サブメニューを選択します。
表示される「管理サービスとリポジトリ」ページで、「OMSとリポジトリ」メニューから「監視」を選択し、「すべてのメトリック」を選択します。
左側ペインのDBMSジョブ・ステータスまでスクロールし、次に示されるメトリックを選択します。
さらに下へスクロールし、次に示すとおり「リポジトリ・ジョブ・スケジューラのパフォーマンス」を展開します。
利用可能なメトリックの定義は、次のとおりです。
スケジューラが準備完了としてマークしたステップの平均数 — ジョブ・ステップ・スケジューラによって、実行の準備ができているとマークするように処理されたステップの平均数。通常、この数は、ある期間のジョブ・システムの負荷に依存します。
現在のジョブ・ステップ・バックログのクリアの推定時間 — 現在ジョブ・システムに流入する割合を想定してバックログをクリアするための推定時間。
ジョブ・ステップ・バックログ — 予定時刻を過ぎてもまだ実行されていないジョブ・ステップの数。この数が大きく、かつ長期間減少しない場合、ジョブ・システムは正常に機能していません。この状況は通常、ジョブ・エンジンのリソースが、システムまたはユーザー・アクティビティによるジョブの処理量を満たすことができない場合に発生します。
スケジューラがステップを準備完了としてマークする際の待機時間 — ジョブ・ステップ・スケジューラは、スケジュールされたステップを準備キューに移動します。このメトリックは、ステップを準備キューにマーキングする平均待機時間を示します。遅延が大きいということは、ジョブ・ステップ・スケジューラ・プロセスの機能が異常であることを示します。
ジョブ・ステップ全体/秒 — ジョブ・システムが毎秒実行する平均ステップ数。
スケジューラ・サイクル — dbmsスケジューラ・プロセスの頻度。1分間につき最低5サイクルを実行し、ジョブ・システムの負荷に応じて増やすことができます。数が少ない場合、通常はジョブ・ステップ・スケジューラ・プロセスでの問題を示します。
さらに下へスクロールし、次に示すとおり「使用状況サマリー: ジョブ」のエントリを展開して、必要なメトリックを選択します。
「ターゲット」メニューのナビゲーション
Cloud Controlコンソールの「ターゲット」メニューから「すべてのターゲット」を選択します。
「すべてのターゲット」ページの左側ペインで、下にスクロールして「内部」を展開し、「OMSとリポジトリ」を選択します。
次のページの「OMSとリポジトリ」表のエントリをクリックします。
表示される「状態の概要」ページの「OMSとリポジトリ」メニューから「監視」、「すべてのメトリック」の順に選択します。
Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。
「状態の概要」サブメニューを選択します。
表示される「管理サービスとリポジトリ」ページで、「OMSとリポジトリ」メニューから「監視」を選択し、「診断メトリック」を選択します。
pbs_* メトリックは、ジョブ・システムでの問題の診断に適しています。スタック・ジョブ・システムのスレッドで詳細を調べる場合、またはジョブ・スレッドの使用状況の統計を詳細に調べて他のジョブの実行を妨げているアウトライアを判断する場合、この情報は有用です。
Cloud Controlコンソールの「設定」メニューから「Cloud Controlの管理」を選択します。
「状態の概要」サブメニューを選択します。
表示される「管理サービスとリポジトリ」ページで、「OMSとリポジトリ」メニューから「監視」を選択し、「チャート」を選択します。
ジョブがステップを実行した場合、このページには、1秒当たりのアップロード・バックログ全体、ジョブ・ステップ・バックログ、ジョブ・ステップ全体についての履歴チャートが表示されます。
Cloud Controlコンソールの「ターゲット」メニューから「すべてのターゲット」を選択します。
グループ、システム、サービスの下の左側のペインで、「管理サーバー」をクリックします。
「ターゲット名」表の「管理サーバー」をクリックします。
「ジョブ・システム」リージョンに、ジョブ・システムのスナップショットと処理された実行の詳細が表示されます。「最新のジョブ実行サマリー」表に、指定した期間内に実行される予定のユーザーの合計ジョブ実行、完了した件数、実行中の件数、完了も実行もされなかった実行の件数が表示されます。これは、様々なユーザー・ジョブがシステムで想定したとおりに実行されているかどうかの判断に役立ちます。
サマリー表の下の「詳細」リンクをクリックします。
実行を開始したいタイミングについて、ドロップダウンで希望の時間枠を選択します。
ジョブとステータスが(ある場合は)表に表示されます。
「ジョブ・ディスパッチャ」タブを選択します。
複数の管理サーバーが構成されている場合、ページに各管理サーバーのジョブ・ディスパッチャとスレッド・プールの使用率が表示されます。
ディスパッチャ使用率(%) — ジョブ・ディスパッチャがジョブ・ステップを取得する頻度を測定します。利用率が高いということは、ジョブ・システムの負荷が高いことを示しています。
スループット(ディスパッチされたステップ/分) — ディスパッチャによって1分当たりに処理される内部ステップ以外の平均ステップ数を示します。
スレッド・プール使用率 — 各プールに構成された合計スレッド数、スレッド・プールで選択される1分当たりの平均ステップ、利用可能な平均スレッド数を示します。
ジョブ・システムでは、診断レポートと使用状況レポートの両方を提供します。
診断レポート
Cloud Controlコンソールの「エンタープライズの設定」から「レポート」を選択します。
「情報パブリッシャ・レポート」サブメニューを選択します。
「タイトル」フィールドで「ジョブ」を検索し、「実行」をクリックします。
表で「ジョブ・システム診断レポート」リンクをクリックします。
このレポートは、ジョブ・システムの状態の概要と、実行中ジョブまたはスケジュールされた時刻を過ぎていると考えられるジョブに関する診断情報を表示します。この情報は、通常、ジョブ・システムの問題を診断するOracleサポート・エンジニアにとって有用です。
使用状況レポート
このレポートを表示するには、手順4の「ジョブ使用状況レポート」リンクをクリックすることを除き、前述の手順に従います。
このレポートは、過去7日間のジョブ・システム使用状況の情報に関する概要を表示します。
修正処理を使用すると、メトリック・アラートに対する自動的なレスポンスを指定できます。修正処理により、メトリック・アラートに対して決められたレスポンスを自動的に実行できるため、時間を節約でき、エンド・ユーザーに対して顕著な影響が出る前に問題を処理できます。
修正処理にはジョブ・システムと共通する多くの機能があります。デフォルトでは、修正処理はメトリック・アラートがトリガーされたターゲット上で実行されます。この他の方法として修正処理を、各タスクが別のターゲットで実行されるような複数のタスクを含むように指定できます。修正処理の成功または失敗に対する通知を受け取ることもできます。
修正処理は、監視対象のターゲットに対する個々のメトリックについて定義します。次の各項では、修正処理の設定方法と、修正処理の実行の詳細を表示する手順について説明します。
修正処理はターゲットのメトリックしきい値に関連付けられているため、修正処理を定義できるのは、そのターゲットに対してOPERATOR以上の権限を付与されている場合です。警告およびクリティカルのしきい値双方について、別々の修正処理を定義できます。修正処理は、特定のユーザーの資格証明を使用して実行する必要があります。そのため、修正処理を作成または変更する場合は、変更した処理を実行するための資格証明を常に指定する必要があります。
修正処理が管理グループに自動的に適用される監視テンプレート/テンプレート・コレクションの一部である場合、テンプレートを管理グループに関連付けているユーザーの優先資格証明が修正処理で使用されます。
どのターゲットに関しても、「メトリックと収集設定」ページに、様々なメトリックの修正処理が設定されているかどうかが表示されます。メトリックごとに、「修正処理」列に、クリティカルまたは警告(あるいは両方)の重大度に対応する修正処理が設定されているかどうかが示されます。
任意のターゲットのホームページ・メニューで、「監視」、「メトリックと収集設定」の順に選択します。「メトリックと収集設定」ページが表示されます。
|
ヒント: たとえば、dadvmn0630.myco.comという名前のホストのホームページでは、「ホスト」メニュー→「監視」→「メトリックと収集設定」を選択します。 |
特定のメトリックの鉛筆アイコンをクリックし、そのメトリックの「詳細設定の編集」ページにアクセスします。
「修正処理」セクションで、修正処理を関連付ける対象のメトリック重大度(警告またはクリティカル)について「追加」をクリックします。
「修正処理の追加」ページでタスク・タイプを選択し、「続行」をクリックします。
ライブラリにある修正処理を使用する場合は、タスク・タイプとして「ライブラリから」を選択します。ライブラリ修正処理を使用すると、説明、パラメータおよび資格証明はライブラリ修正処理からコピーされます。新規の修正処理の名前は定義する必要があります。必要に応じて修正処理のパラメータを指定できます。
ライブラリに格納する修正処理を作成する場合は、第11.8.3項「ライブラリの修正処理の作成」を参照してください。
エージェント側のレスポンス処理を指定する場合は、「エージェント・レスポンス処理」をタスク・タイプとして選択します。詳細は、第11.8.6項「エージェント側のレスポンス処理の用意」を参照してください。
「修正処理」ページで、ジョブを作成するときのように、「一般」、「パラメータ」および「資格証明」に入力します。
「続行」をクリックして修正処理を保存して、「詳細設定の編集」ページに戻ると、修正処理が表示されます。
オプション: 修正処理の複数のインスタンスが同時に動作することがないように、「このメトリックに対する修正処理を1回のみ任意の時刻に実行することを許可」を有効にします。
このオプションでは、クリティカルまたは警告のいずれかの修正処理が実行中のときに、ある重大度がOracle Management Serviceにレポートされた場合、クリティカルと警告の両方の修正処理を実行しないことを指定します。このようなケースが発生するのは次の場合です。修正処理の実行が、修正対象のメトリックの収集間隔より長時間かかった場合、メトリック値はあるしきい値において前後(結果として、同一の修正処理が複数回実行される)するか、両方のしきい値を急速に上下(結果として、警告の修正処理がクリティカルの修正処理と重複する)します。
このオプションを選択しないと、前述した状況下で修正処理が複数回実行されます。管理者は、同時に実行される修正処理が競合しないようにする必要があります。
修正処理の追加が終了したら、「続行」をクリックして「メトリックと収集設定」ページに戻ります。
このページの「修正処理」列に、メトリックに対して指定した修正処理が表示されます。表示される値:
なし - このメトリックには修正処理が設定されていません。
警告 - このメトリックでは、警告アラートには修正処理が設定されていますが、クリティカル・アラートには設定されていません。
クリティカル - このメトリックでは、クリティカル・アラートには修正処理が設定されていますが、警告アラートには設定されていません。
警告およびクリティカル - このメトリックでは、警告およびクリティカルの両方のアラートに修正処理が設定されています。メトリックにエージェント側のレスポンス処理が関連付けられている場合も、値は「警告およびクリティカル」になります。これは、クリティカルまたは警告のアラート重大度のいずれにも、必ずエージェント側のレスポンス処理がトリガーされるためです。
ステップ2以降のプロセスを続けてから、「メトリックと収集設定」ページで「OK」をクリックして修正アクションを保存し、ステップ1を開始したターゲット・ページに戻ります。
繰り返し使用する修正処理については、ライブラリの修正処理を定義できます。ライブラリに修正処理を保存すると、ターゲット・メトリックまたはポリシー・ルールの修正処理を定義する際に、保存した修正処理の定義を再利用できます。
「エンタープライズ」メニューで「監視」、「修正処理」の順に選択します。「修正処理ライブラリ」ページが表示されます。
「ライブラリ修正処理の作成」ドロップダウンでジョブ・タイプを選択し、「実行」をクリックします。
第11.3項「ジョブの作成」でジョブを作成するときのように、「一般」、「パラメータ」および「資格証明」で修正処理を定義します。「アクセス」については、次のオプションの手順に進みます。
オプション: 「アクセス」を選択して、この修正処理に対する他のユーザーのアクセスを定義または変更します。
詳細は、第11.8.4項「修正処理のアクセスの指定」を参照してください。
終了したら「ライブラリに保存」をクリックします。「修正処理ライブラリ」ページが再び表示されると、リストに修正処理が表示されます。
これで、この修正処理に基づいて別の修正処理を作成したり(「類似作成」ボタン)、この修正処理の編集または削除を行ったりすることができます。
このライブラリ・エントリを使用できるのは、メトリックの重大度について修正処理を定義するときです。「修正処理の追加」ページでタスク・タイプとして「ライブラリから」を選択してください。詳細は、第11.8.2項「メトリックに対する修正処理の作成」の手順4を参照してください。
前の手順で説明したように、他のユーザーによる修正処理へのアクセスを決めることができます。修正処理を共有する予定がない場合、このページに入力する必要はありません。
「アクセス」ページの表に、修正処理に対して管理者とロールが保持するアクセスが表示されます。修正処理の所有者(またはスーパー管理者)のみがこのページを変更できます。
修正処理の所有者は次の操作を実行できます。
「追加」をクリックし、次に表示されるページで適切なタイプを選択し、他の管理者およびロールを表に追加します。
管理者やロールのアクセスを変更するには、表の「アクセス・レベル」列で「完全」または「表示」アクセス権を選択します。
管理者またはロールについて「削除」列のアイコンをクリックし、管理者またはロールの修正処理に対するすべてのアクセスを削除します。スーパー管理者権限を持つすべての管理者には、修正処理に対する「表示」アクセス権があります。
ロールにアクセス権を提供する場合、ロールには完全なアクセス権ではなく、表示アクセス権のみを提供できます。
スーパー管理者の場合、次の操作を実行できます。
Enterprise Managerの他の管理者またはロールに表示アクセス権限を付与します。
すべての管理者のアクセス権限を無効にします。
|
注意: 新規ユーザーを作成している場合、そのユーザーが修正処理を作成するためにはCREATE_JOB権限を持つ必要があります。 |
アクセス・レベル・ルールを次に示します。
スーパー管理者には、常にすべての修正処理に対する表示アクセス権限があります。
修正処理を所有するEnterprise Manager管理者は、修正処理に対するアクセス権限を変更できます(スーパー管理者からの表示権限の取消しを除く)。
修正処理に対して表示または完全アクセス・レベルを持つスーパー管理者は、新しいユーザーに表示(完全ではない)アクセス権限を付与できます。スーパー管理者は、通常のユーザーの完全アクセス権限および表示アクセス権限を取り消し、スーパー管理者の完全アクセス権限を取り消すこともできます。
完全アクセス・レベルを持つ通常のEnterprise Manager管理者は、修正処理に対するアクセス権限は変更できません。
修正処理の所有者が、ある修正処理について「類似作成」操作を実行する場合、新しい修正処理のすべてのアクセス権限は元の修正処理と同じになります。修正処理の所有者が、修正処理の表示または完全アクセス権限を他の管理者に付与し、それらの管理者のいずれかがその修正処理に対して類似作成操作を実行した場合、すべての管理者は新しく作成された修正処理に対する表示アクセス権限をデフォルトで保持します。
修正処理はメトリックに関連付けられており、そのメトリックのアラートで起動します。ターゲットに対して表示以上の権限を持つEnterprise Manager管理者は、修正処理の成功または失敗の後で通知を受け取ることができます。
1つのインシデント・ルールには、アラートと修正処理の状態の任意の組合せが含まれます。インシデント・ルールによって選択されたメトリックおよびターゲットはすべて、同じアラートと修正処理の状態について通知されます。したがって、あるメトリックについては修正処理の成功または失敗に関する通知を希望し、別のメトリックについては失敗のみの通知を希望する場合、2つのインシデント・ルールを使用する必要があります。1つのインシデント・ルールに、修正処理が関連付けられていないメトリックの修正処理状態が含まれる場合があります。この場合、通知は送信されません。
|
注意: ターゲットに対して適用されるインシデント・ルールの状態にかかわらず、エージェント側のレスポンス処理については通知を送信できません。 |
通知のインシデント・ルールを作成するには、次の手順を実行します。
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。
「ルール・セットの作成」をクリックします。ルール・セットの作成ウィザードが表示されます。
「ルール・セットの作成」ページの一番上で必要な情報を指定してから、「ターゲット」サブタブでターゲットの1つを選択し、「すべてのターゲットのタイプ」と「特定のターゲット」の選択に応じて必要な情報を指定します。
「ルール」サブタブを選択し、「作成」をクリックします。
表示されるポップアップで、デフォルトの「受信イベントおよびイベントの更新」を選択し、「続行」をクリックします。
「イベントの選択」ページで、「タイプ」チェック。ボックスを選択し、「メトリック・アラート」を選択します。
「タイプ・メトリック・アラートの特定のイベント」ラジオ・ボタンをクリックし、表示される表で「追加」をクリックします。
表示されるポップアップで、「ターゲット・タイプ」を選択し、メトリックをフィルタ処理して選択し、重大度を選択します。次に、必要な修正処理ステータスを有効にします。「OK」をクリックします。
「アクションの追加」ページで、「追加」をクリックします。
「条件付きアクションの追加」ページの「基本通知」セクションで受信者を指定します。
ウィザードの最後の2ページの指示に従い、「続行」をクリックします。新しいルールが「ルール・セットの作成」ページに表示されます。
「保存」をクリックしてこのルールを保存します。
1つまたは複数のルール・セットを作成したら、次のように通知メソッドを設定する必要があります。
「設定」メニューで「通知」、「通知メソッド」の順に選択します。
「通知メソッド」ページでは、「ヘルプ」、「Enterprise Managerヘルプ」の順に選択して、入力方法を確認してください。
エージェント側のレスポンス処理では、アラートに応答する単純なコマンドが実行されます。メトリックで警告またはクリティカルのアラートが発せられると、管理エージェントで自動的に指定されたコマンドまたはスクリプトが実行されます(Oracle Management Service (OMS)との連携は必要ありません)。エージェントは、エージェント実行可能ファイルを所有するOSユーザーとしてこのコマンドまたはスクリプトを実行します。特定のターゲット・プロパティがエージェントのレスポンス処理スクリプトで使用される場合があります。
|
注意: 「エージェント側のレスポンス処理」ページを使用して、メトリックの警告またはクリティカルの重大度に達したときに実行される、単一コマンドライン処理を指定します。アラート・コンテキストが必要なタスクの場合は、より複雑なロジックを含めるか、成功または失敗時に通知を送信するように要求すると、エージェント側のレスポンス処理のかわりに修正処理が使用されます。 |
このページにアクセスするには、第11.8.2項「メトリックに対する修正処理の作成」の手順1から4に従います。
1つのコマンドの指定やスクリプトの実行も可能です。シェル・コマンド文字(>や<など)をレスポンス処理コマンドの一部として指定することはできません。これらの特別な文字タイプをレスポンス処理コマンドで指定する必要がある場合は、スクリプト内でその文字を使用してから、そのスクリプトをレスポンス処理コマンドで指定します。
スクリプトを使用する場合、必ず、エージェントが存在するホスト・マシン上にスクリプトをインストールするようにしてください。シェル・スクリプトを使用する場合、必ず、シェルを次のレスポンス処理コマンドラインで指定してください。
スクリプト/コマンド: /bin/csh myScript
もしくは、次のようなスクリプトの本体で指定してください。
スクリプト/コマンド: myScript
ここで、myScriptの内容は次のようになります。
!#/bin/csh<
<rest of script>
コマンドでターゲット・プロパティを使用できます。「使用可能なターゲットのプロパティを表示」をクリックして、「スクリプト/コマンド」フィールドで使用できるターゲット・プロパティを表示します。使用可能なターゲット・プロパティのリストは、レスポンス処理を実行する対象のターゲットのタイプに応じて変わります。
ターゲット・プロパティをスクリプトまたはコマンドに対するコマンドライン引数として使用してから、これらのコマンドライン引数をスクリプトが参照するようにします。たとえば、%OracleHome%および%SID%のターゲット・プロパティを使用する場合、コマンドは次のようになります。
/bin/csh MyScript %OracleHome% %SID%
次に、ユーザーのスクリプトであるMyScriptがこれらのプロパティをコマンドライン引数として参照できます。次に例を示します。
IF $1 = 'u1/bin/OracleHome' THEN...
ターゲット・プロパティの大文字と小文字は区別されます。たとえば、管理エージェントのPerlインタプリタにアクセスする場合は、「スクリプト/コマンド」フィールドに%perlBin%/perl <my_perl_script>と指定できます。
他のターゲット・プロパティは、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>
修正処理の実行結果を表示するには、2つの方法があります。
インシデント・マネージャの方法
Enterprise Manager Cloud Controlコンソールの「Enterprise」メニューから、監視」、「インシデント・マネージャ」の順に選択します。
「検索」アイコンをクリックし、タイプ・ドロップダウンから「イベント」を選択して「結果取得」をクリックします。
検索結果の表で、関連するメッセージをダブルクリックします。
次に示すとおり、「修正処理履歴」表がページの下部に表示されます。
履歴表で必要なメッセージを選択し、次に示す眼鏡アイコンをクリックします。
「修正処理の実行」ページに、修正処理、ステータス、開始時刻、終了時刻などの出力が表示されます。
すべてのメトリックの方法
ターゲットのホームページで、「監視」、「すべてのメトリック」の順に選択します。
左側のツリー・パネルから、必要なメトリックの名前をクリックします。
メトリック・アラートの行が、「メトリック・アラート履歴」表に表示されます。
次に示す「詳細」列の眼鏡アイコンをクリックします。
「インシデント・マネージャイベントの詳細」ページが表示されます。
ページ下部の「修正処理履歴」表で、履歴表のメッセージを選択して眼鏡アイコンをクリックします。
「修正処理の実行」ページに、修正処理、ステータス、開始時刻、終了時刻などの出力が表示されます。
