| Oracle® Fusion Middleware Oracle Enterprise Schedulerの管理 12c (12.1.3) E59386-02 |
|
 前 |
 次 |
Oracle Enterprise Schedulerクラスタ環境のトラブルシューティングには、次が含まれます。
Fusion Middleware Controlでパフォーマンス・メトリックを確認することで、パフォーマンスとスケーラビリティに関する問題を検出できます。メトリックには、Oracle WebLogic Server、JVMレベルのメトリックと図表およびOracle Enterprise Schedulerレベルのメトリックが含まれます。
サーバーを実行しているオペレーティング・システム専用のシステムレベルのツールを、追加の診断ツールとして使用できます。システムレベルのツールでは、ネットワーク、メモリー、CPU、I/Oなどのマシン・リソースの利用状況を様々な時間帯ごとに確認できます。このようなシステム・ツールはジョブ実装の調整を行うときに特に便利です。データベースの問題の特定にはデータベース・ツールを使用します。リモート・システムで実行するADFビジネス・コンポーネント・ジョブやSOA Javaジョブなどのリモート・ジョブについては、対応するFusion Middleware Controlとそれらのサーバーのシステムレベルのツールを使用します。
Fusion Middleware Controlには、問題の特定に役立つ次のタイプのOracle Enterprise Schedulerメトリックが用意されています。
ジョブ名別の完了済ジョブ・リクエスト統計。完了したリクエストの実行回数、実行時間、成功率および前回実行ジョブ・リクエストについての統計を、ジョブ名別に表示します。
ユーザー別の完了済ジョブ・リクエスト統計。完了したリクエスト数および完了したリクエストの実行時間を、ユーザー別に表示します。
作業割当て別の完了済ジョブ・リクエスト統計。完了したジョブ・リクエストの待機時間、処理時間、完了数および失敗数を、作業割当て別に表示します。
ステータス別の完了済ジョブ・リクエスト数。様々な終了状態で完了したジョブ・リクエストを表示します。
メトリックの詳細は、「Oracle Enterprise Schedulerのキー・パフォーマンス・メトリックの監視」を参照してください。
複数のアプリケーション・ドメインで共通のデータベースを使用できます。この場合、データベースに複数のソースから負荷がかかる可能性があります。このためOracle Enterprise Managerでは、実行中と待機中のジョブを表示できるほか、複数のOracle Enterprise Schedulerシステムからのデータベース全体にわたるメトリックを表示できます。
ジョブ・リクエストまたはOracle Enterprise Schedulerランタイムのコンテキストで、次のようなパフォーマンスおよびスケーラビリティの問題が発生することがあります。
Oracle Enterprise SchedulerサーバーのCPUがジョブで飽和状態になります。
非同期ジョブが実行されているリモート・システムがジョブによって過負荷状態に陥ります。
CPUの余力があるのにキューが準備完了ジョブで一杯になり、ジョブ出力が遅れます。
複数のドメインで1つのデータベースを共有しています。ドメイン全体でデータベース負荷の高いジョブを多数同時実行すると、データベースの動作が遅くなります。
四半期末や月末に大規模なジョブを実行すると、パフォーマンスとスケーラビリティに影響があります。
データベースに非常に高い負荷を与えるジョブを2つ以上同時実行すると、パフォーマンスとスケーラビリティに影響があります。
チューニングには、ジョブ実装、スケジュール、Oracle Enterprise Schedulerクラスタのサイズ、プロセッサと作業割当てのバインディング、スロットルおよびスレッド制限を変更する作業も含まれます。
クラスタは、スケーラビリティと高可用性を実現するための基本的なメカニズムです。ジョブを実行する際、ジョブを実行するプロセッサは、その時点でジョブを実行する資格のあるプロセッサの中から平等に選択されます。Oracle Enterprise Schedulerクラスタのサイズを慎重に調整することで、ジョブ実行をクラスタ内で効率的に分配し、サーバーの過負荷を防ぐことができます。リモート・ジョブの場合、ジョブは実際にはリモート・システムで実行されるため、クラスタ内のリソースはほとんど消費されません(同期ジョブのためブロックされるスレッドを除く)。ローカルで実行するジョブによりシステムが過負荷になっている場合は、最初にクラスタ・サイズ構成を再確認します。
ジョブの中には物理的に指定のサーバーでのみ実行されるものがあり、これらのジョブはそのサーバーでのみ実行されるようバインドされています。特定のプロセッサに多数のジョブがバインドされていると、事実上クラスタ環境を使用する意味がなくなってしまいます。高可用性を達成するため、ジョブを1つのサーバーに結び付けることは避け、ジョブを少なくとも2つのサーバーで実行できるようにしておきます。バインド先のプロセッサがダウンした場合は、ジョブを実行できません。
クラスタで作業をランダムに配分するのではなく、時間を要しリソースを大量に消費するジョブのセットを特定のスケジュール枠内でローカルで実行する方法もあります。この場合は、これらのジョブを特定のプロセッサにバインドして、ジョブの分配を明示的に制御します。
プロセッサはOracle Enterprise Schedulerインスタンスです。1つのOracle Enterprise Schedulerインスタンスは1つのクラスタ・ノードで実行されます。一般に1つのクラスタ・ノードは1つのコンピュータで実行されるため、通常、プロセッサとコンピュータは同等となります。
リソースを大量消費するジョブが多数スケジュールされている期間に入った途端、クラスタ環境のパフォーマンスが落ちることがあります。パフォーマンスを維持するには、予備のアイドル・ノードをクラスタに構成しておき、負荷の高い時間帯のみアクティブ化させて、通常時を上回るジョブの負荷に対応できるようにします。このようなクラスタを構成するには、標準のOracle WebLogic Serverクラスタ手法を使用します。Oracle WebLogic Serverのクラスタ化の詳細は、『Oracle Fusion Middleware高可用性ガイド』の「WebLogic Serverの高可用性」の章を参照してください。
ジョブのパフォーマンスは、実行しているジョブが同期ジョブか非同期ジョブかで差が出ることがあります。同期ジョブは最後まで1つのスレッドを使用し、通常、存続時間は短いです。(データベースに負荷を与えるプロセッサ・ジョブまたは生成されたジョブの場合は、そうとはかぎりません。)非同期ジョブは開始時と終了時に1つのスレッドを非常に短い時間消費しますが、それ以外は独立して実行されます。非同期ジョブは通常実行時間が長く、サーバーの再起動があっても実行し続けます。非同期ジョブの主な例には、PL/SQLジョブ、リモート非同期ADFビジネス・コンポーネント・サービスを呼び出すJavaジョブ、リモート非同期SOAサービスを呼び出すJavaジョブがあります。
スロットルは、同時実行できるジョブの最大数を制限します。大量のジョブが同時実行されシステムが過負荷に陥いるのを防ぐには、これが重要になります。同期ジョブの場合、この制限を課すには、実行時に使用を許可するスレッドの数を制限します。PL/SQLジョブおよびその他の非同期ジョブの場合、この制限を課すには、PL/SQLジョブと非同期ジョブのそれぞれに、最大同時実行性の制限を定義します。非同期スロットル制限は、そのジョブが割り当てられる作業割当てで設定します。非同期ジョブの制限を設定する方法の詳細は、「稼働シフトの作成または編集」を参照してください
構成したすべてのスレッドが同期ジョブで使用されてしまい、その結果非同期ジョブの開始が妨げられることがあります。このような状況は、非同期ジョブと同期ジョブを1つの作業割当てで組合せないようにすることで回避できます。
ジョブの非互換性を構成して2つの非互換ジョブが実行されるのを回避するだけでなく、高い負荷を与える2つのジョブが同じリソースに大量の負荷を与えないようにすることができます。そのようなジョブが同時に実行されないよう非互換性を定義することで、高いパフォーマンスを維持できます。ジョブの非互換性の定義の詳細は、「非互換性の作成または編集」を参照してください。
次に、チューニングが可能なOracle Enterprise Schedulerコンポーネントを示します。
リクエスト・ディスパッチャ
リクエスト・プロセッサ
接続プール・サイズ
RDBMSスケジューラ
ディスパッチャのチューニング
ディスパッチャ・チューニング・パラメータはOracle Enterprise Schedulerのリクエスト・ディスパッチャに適用されます。リクエスト・ディスパッチャは、スケジュールされている実行を待機しているリクエストを管理します。リクエスト・プロセッサは、実行後のジョブ・リクエストを処理します。
パラメータは次のとおりです。
ディスパッチャ有効: Oracle Enterprise Schedulerサーバーでリクエスト・ディスパッチャが有効であるかどうかを示します。無効にした場合、Oracle Enterprise Schedulerサーバーは、実行スケジュール時間が来てもジョブ・リクエストをディスパッチしません。デフォルトで、このパラメータは有効です。
最大ポーリング間隔: ディスパッチ準備の整ったジョブ・リクエストをリクエスト・ディスパッチャがチェックする頻度の最大間隔を、秒数で指定します。デフォルト値は15秒です。
プロセッサのチューニング
プロセッサ・チューニング・パラメータはOracle Enterprise Schedulerのリクエスト・プロセッサに適用されます。リクエスト・プロセッサは、実行スケジュール時間に到達していて、実行準備が整っているジョブ・リクエストを管理します。
パラメータは次のとおりです。
プロセッサ有効: Oracle Enterprise Schedulerサーバーでリクエスト・プロセッサが有効であるかどうかを示します。無効にした場合、Oracle Enterprise Schedulerサーバーは、実行準備の整ったリクエストを処理しません。デフォルトで、このパラメータは有効です。
最大プロセッサ・スレッド: ジョブ・リクエストの処理に使用する最大スレッド数を指定します。これは、Oracle Enterprise Schedulerサーバーのすべてのアクティブな作業割当てで同時実行できる、ワーカー・スレッドの総数を表します。デフォルトで、このパラメータは25に設定されます。
スターベイションしきい値: 実行準備の整ったジョブ・リクエストが、飢餓状態にあり、スタベーション・ワーカー・スレッドによって処理される資格があるものと見なされるまでの時間を、分単位で示します。スタベーション・ワーカーは、準備完了状態になってからスタベーション時間を経過したジョブ・リクエストのみを処理します。しきい値がゼロの場合、スタベーション・ワーカーは作成されません。
有効にした場合(ゼロより大きいパラメータ値を指定した場合)、Oracle Enterprise Schedulerサーバーの各アクティブ作業割当てに対して、スタベーション・ワーカー・スレッドが作成されます。最大プロセッサ・スレッド・パラメータはスタベーション・ワーカーに適用されません。デフォルトで、このパラメータの値はゼロで、スタベーション・ワーカーは作成されません。
Oracle Enterprise Scheduler内部データ・ソースのための接続プール・サイズのチューニング
Oracle Enterprise Scheduler内部JDBCデータ・ソースの接続プール・サイズは、最大プロセッサ・スレッドと「スタベーションしきい値」パラメータで構成したリクエスト・プロセッサのチューニング値を基に決める必要があります。
「スタベーションしきい値」パラメータを無効(値が0)にした場合、最大プロセッサ・スレッド数に20を加えた数をプール・サイズに指定することをお薦めします。
「スタベーションしきい値」パラメータを有効(値が0より大きい)にした場合、最大プロセッサ・スレッド数とバインドされる作業割当ての数に20を加えた数をプール・サイズに指定することをお薦めします。
RDBMSスケジューラのチューニング
RDBMSスケジューラには自動チューニング機能があります。自動チューニングを有効にするには、job_queue_processesを0に設定します。JOB_QUEUE_PROCESSESはデフォルト値1000のままにします。JOB_QUEUE_PROCESSESパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
Oracle Enterprise Schedulerの生成されたジョブはSQL*Netを使用してデータベースに接続します。生成されたジョブが取り消された場合、Oracle Enterprise Schedulerはこれらのプロセスをオペレーティング・システム・レベルで強制終了します。しかし、これらのプロセスが使用していたデータベース接続がデータベース内に残留することがあります。
データベース内の無効の接続を少なくするには、SQLNET.EXPIRE_TIME構成オプションの値を適切な値に設定します。SQLNET.EXPIRE_TIMEパラメータの詳細は、『Oracle Database Net Servicesリファレンス』の「sqlnet.oraファイルのパラメータ」の章を参照してください。
