| Oracle® Fusion Middleware Oracle Enterprise Scheduler管理者ガイド 11g リリース1 (11.1.1.7) B66432-04 |
|
 前 |
 次 |
この付録では、Oracle Enterprise Schedulerの使用中に発生する可能性のある一般的な問題と、その解決方法について説明します。
この付録では次の項について説明します。
表示される可能性のあるエラー・メッセージの詳細は、この章およびOracle Fusion Middlewareエラー・メッセージ・リファレンスを参照してください。
この項では、この章の情報を使用する際のガイドラインとプロセスを示します。次のガイドラインおよびプロセスに従うことで、作業の焦点を問題解決に絞り、問題解決までの時間を短縮できます。
ガイドライン
この章の情報を使用する際は、次のことをお薦めします。
この章の解決策を実行した後すぐに、このトラブルシューティング情報を利用するきっかけとなった失敗したタスクを再試行します。再試行してもタスクが失敗する場合、この章に記載されている他の解決策を実行し、再度失敗したタスクを実行します。このプロセスを問題が解決するまで繰り返します。
実行した解決策、確認された現象およびトラブルシューティング中に収集したデータを記録しておきます。この章の情報を使用しても問題が解決されずサービス・リクエストを記録することになった場合、これらの情報があると迅速な問題解決につながります。
Oracle Enterprise Schedulerジョブの実行中に発生する次のような一般的な問題について、トラブルシューティングを行う場合があります。
非同期ジョブの実行中状態がいつまでも続きます。
非同期ジョブが止まるまたはクラッシュします。
リモートのスケジュール済ジョブの完了時にOracle Enterprise Schedulerがダウンしていた場合、またはネットワーク問題の影響で、Oracle Enterprise Schedulerがリモート・ジョブから完了のステータスを受信できません。
実行準備が整っているスケジュール済ジョブが実行されません。
スケジュール済ジョブがトラブルシューティングを要する手動エラー・リカバリの状態になります。
Oracle Enterprise Schedulerからエラーがスローされます。
スケジュール済ジョブがエラーで終了します。
Oracle Enterprise Schedulerのトラブルシューティングには、標準のOracle WebLogic Serverシステム・ログを使用します。ジョブ・リクエスト・ログの表示の詳細は、第6.7項を参照してください。
この項には次のトピックが含まれます:
非同期ジョブは別のJVMSで実行されるジョブで、非同期Oracle BI Reporting and Publishing、PL/SQLジョブ、および非同期SOAまたはADFビジネス・コンポーネント・サービスを呼び出すJavaジョブが含まれます。非同期スケジュール済ジョブを処理する際、Oracle Enterprise Schedulerは、実行後のジョブの結果を定義する完了ステータスを送信するリモート・ジョブに依存します。しかし、次のような理由から、完了ステータスが生成されなかったり失われたりすることがあります。
スケジュール済ジョブがクラッシュしました。
ジョブが停止状態でスタックしています。
ジョブの完了時にOracle Enterprise Schedulerがダウンしていました。
ネットワークの問題。
いずれかの状況に当てはまる場合、非同期ジョブがいつまでも実行状態のままになります。その結果、ジョブ・セットの後続のステップが実行されなかったり、非互換ジョブが無期限にブロックされることがあります。
Oracle Enterprise Schedulerの情報はFusion Middleware Controlに表示されるため、ここでリモート・システム上のジョブと外部識別子を確認できます。
実行状態でスタックしている非同期ジョブは、次の方法でトラブルシューティングできます。
リモート・システムを使用してジョブのトラブルシューティングを行い、ジョブの実行結果を確定します。詳細は、第B.2.1.1項および第B.2.1.2項を参照してください。
ジョブを取り消します。詳細は、第4.2.4項を参照してください。
非同期ジョブのタイムアウトを構成します。詳細は、第4.2.1項を参照してください。
ジョブのタイムアウトを構成するときには、Fusion Middleware Controlを使用して、タイムアウトしたジョブをすべて表示できます。ただし、タイムアウトしたジョブはまだ実行中の状態です。タイムアウトしたジョブの状態を手動で変更する必要があります。ステータス・コールバックはタイムアウトになったジョブにも有効で、ジョブは完了の状態に遷移します。
タイムアウトしていない非同期ジョブの状態を変更できます。これに該当するのは、タイムアウトを構成していないジョブで完了ステータスが失われ、ジョブが長時間実行されていることに気づいた場合などです。
非同期Javaジョブ(リモートOracle SOA SuiteまたはOracle ADFビジネス・コンポーネント・サービスを呼び出すジョブを含む)の場合、ログ・レコードにECIDのタグが付加されます。ECIDにより、ドメイン全体のログを表示してジョブ実行の問題を解決できます。Oracle ADFビジネス・コンポーネント、SOAコンポジット、Webサービス・スタックおよびアプリケーションはレコードをECIDとともにログ記録します。
非同期SOAジョブの場合は、第B.4.4項の説明のとおり、Fusion Middleware Controlでインスタンスの監査証跡を使用してコンポジット実行の問題を解決できます。
例B-1は、JRF Webサービスがserver-diagnostic.logにスタックした、サンプルのログ・メッセージ・ファイルであり、各ログにインライン注釈が含まれています。このログは次のディレクトリに格納されています。
(UNIX) DOMAIN_HOME/servers/server_name/logs (Windows) DOMAIN_HOME\servers\server_name\logs
例B-1 server-diagnostic.log内の非同期ジョブのロギング・メッセージ
Sending message to JMS queue "oracle.j2ee.ws.server.async.DefaultRequestQueue" for asynchronousprocessing of service b99d80e5-42aa-423a-9e98-f6f88b8b79dfRequest.[2010-08-30T18:28:13.519-07:00] AdminServer NOTIFICATION [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 0000If5kZGS76EWLHyo2yf1CV5eh000000,0:1] [WEBSERVICE\_PORT.name: EmployeeModuleServiceSoapHttpPort] [APP: ADFBCAsync] [J2EE\_MODULE.name: ADFBCAsync\-ejb] [WEBSERVICE.name: EmployeeModuleService] [J2EE\_APP.name: ADFBCAsync] [MessageID: urn:uuid:01994234-4442-4dee-82a6-e1e04407af56]An asynchronous request message is received and successfully recorded for the serviceEmployeeModuleService with the replyTo addresshttp://adc2180314:7001/ADFBCAsyncCallback/EmployeeModuleServiceCallbackResponseImplService.[2010-08-30T18:28:13.724-07:00] AdminServer NOTIFICATION [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 0000If5kZGS76EWLHyo2yf1CV5eh000000,0:1] [WEBSERVICE\_PORT.name: EmployeeModuleServiceSoapHttpPort] [APP: ADFBCAsync] [J2EE\_MODULE.name: ADFBCAsync\-ejb] [WEBSERVICE.name: EmployeeModuleService] [J2EE\_APP.name: ADFBCAsync] [MessageID: urn:uuid:01994234-4442-4dee-82a6-e1e04407af56] Unknown macro: {/service/common/}Started asynchronous request processing for the service EmployeeModuleService with the messageselector "b99d80e5-42aa-423a-9e98-f6f88b8b79dfRequest". Transaction enabled: "true".[2010-08-30T18:28:13.811-07:00] AdminServer NOTIFICATION [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 0000If5kZGS76EWLHyo2yf1CV5eh000000,0] [APP: ADFBCAsync] [MessageID: urn:uuid:01994234-4442-4dee-82a6-e1e04407af56]Completed asynchronous request processing. A response is sent to the client.[2010-08-30T18:28:17.307-07:00] AdminServer NOTIFICATION [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 0000If5kZGS76EWLHyo2yf1CV5eh000000,0] [APP: ADFBCAsync] [MessageID: urn:uuid:01994234-4442-4dee-82a6-e1e04407af56]Started asynchronous response processing for the service EmployeeModuleService with the messageselector "b99d80e5-42aa-423a-9e98-f6f88b8b79dfResponse".[2010-08-30T18:28:17.330-07:00] AdminServer NOTIFICATION [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 0000If5kZGS76EWLHyo2yf1CV5eh000000,0] [APP: ADFBCAsync] [MessageID: urn:uuid:01994234-4442-4dee-82a6-e1e04407af56] Unknown macro: {/service/common/}Completed asynchronous response processing successfully. The client should have received theresponse at this point.[2010-08-30T18:28:17.825-07:00] AdminServer NOTIFICATION [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 0000If5kZGS76EWLHyo2yf1CV5eh000000,0] [APP: ADFBCAsync] [MessageID: urn:uuid:01994234-4442-4dee-82a6-e1e04407af56]Completed asynchronous response processing with exceptions. The client does not receive anyresponse.[2010-08-31T09:55:33.939-07:00] AdminServer ERROR [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 0000If94mKW76EWLHyo2yf1CVJG1000000,0] [APP: j2wpojoasync] [MessageID: urn:uuid:5b9a5134-1416-4bda-95fd-da6e624466d7]The response will not be sent again as the callback service has replied with a SOAP fault. The HTTPresponse code is 500.[2010-08-31T10:17:35.852-07:00] AdminServer ERROR [] oracle.j2ee.ws.common.jaxws.JAXWSMessages [tid: ACTIVE.ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser] [ecid: 0000If99plA76EWLHyo2yf1CVJ^i000000,0] [APP: ADFBCAsyncInvalidCallbackCreds] [MessageID: urn:uuid:7e355428-f68f-4c3f-a368-baf529048323]
ジョブのパラメータ構成の詳細は、第4.2.1項を参照してください。server-diagnostic.logファイルの表示の詳細は、第6.7.6項を参照してください。
Oracle Database内では、PL/SQLジョブをジョブ名で特定できます。リクエストに関連付けられているデータベース・ジョブ名は、Fusion Middleware Controlの「ジョブ詳細」ページで確認できます。ジョブ・リクエスト詳細の表示の詳細は、第4.2.4項を参照してください。
生成されたジョブ・プロセスは、ホスト名、プロセスIDおよびプロセス・グループIDの組合せで特定できます。これは、Fusion Middleware Controlの「ジョブ詳細」ページに追加情報とともに表示されます。ジョブ・リクエスト詳細の表示の詳細は、第4.2.4項を参照してください。
様々な理由から、ジョブ・リクエストのエラーを手動でリカバリする必要がある場合があります。たとえば、非同期ジョブ・リクエストの場合、ジョブ実装がジョブ・リクエストが正常に起動されたかどうかを把握することができず、手動リカバリ例外がスローされることがあります。ジョブ・リクエストが手動エラー・リカバリになった場合は、そのジョブ・リクエストを手動で完了させる必要があります。ジョブ・リクエストが実際に正常に起動され、完了時に完了ステータスを返した場合、このステータスは無視されます。
ジョブ・リクエストが手動エラー・リカバリになる可能性があるのは、次のような場合です。
非同期Javaジョブ・リクエストがExecutionManualRecoveryExceptionをスローし、Oracle Enterprise Schedulerに手動リカバリの必要性があることを通知します。ジョブ・リクエストはERROR_MANUAL_RECOVERY状態になります。原因はCause.PROCESS_MANUAL_RECOVER_ERROR (209)に設定されます。
非同期Javaジョブ・リクエストがランタイム例外またはエラーをスローします。スローされた例外がジョブ実装によって処理されない場合、Oracle Enterprise Schedulerはリモート・ジョブが呼び出されたかどうかを知ることができず、手動リカバリが必要になります。原因はCause.PROCESS_MANUAL_RECOVER_ERROR (209)に設定されます。
非同期ジョブ・リクエストの開始処理を終了する前にOracle Enterprise Schedulerがクラッシュした場合、Oracle Enterprise Schedulerはリモート・ジョブが呼び出されたかどうかを知ることができません。ジョブ・リクエストの状態はERROR_MANUAL_RECOVERYになり、非互換ロックを保持します。原因はCause.PROCESS_RECOVER (210)に設定されます。非同期ジョブの開始処理が終了しジョブが実行中の状態になってからサービスがクラッシュした場合、ジョブは実行中状態を維持し、コールバックの発生時に完了します。
生成されたジョブがクラスタ環境で実行され、ジョブ・リクエストがOracle Enterprise Schedulerの最初のインスタンスで実行され、これが関連付けられているPerlエージェントとともにダウンします。Oracle Enterprise Schedulerの最初のインスタンスがバックアップされておらず、しばらく実行を続けている場合、Oracle Enterprise Schedulerは生成されたプロセスが実際に実行しているかどうかを知ることができません。手動の検出およびリカバリが必要になります。原因はCause.PROCESS_RECOVER(210)に設定されます。
Javaジョブがタイムアウトした場合や実行時間が異常に長い場合、通常どおりジョブが完了するまで実行を続けるか、終了させることができます。
同期Javaジョブをリカバリするには:
ジョブがERROR_MANUAL_RECOVERY状態でない場合は、ジョブを取り消します。第4.2.6項を参照してください。ジョブのCANCELLING状態が異常に長く続く場合は、次の手順に進みます。
次のいずれかのアクションを実行します。
しばらくしてリクエストが終了状態に遷移した場合は、これ以上の作業は不要です。
リクエストの状態がCANCELLING状態から遷移しない場合は、リクエストが実行されているOracle Enterprise Schedulerサーバーを、サーバーとクラスタ名を探して確認します。
Oracle Enterprise Schedulerプロセス・グループからクラスタ名を判断します。プロセス・グループ情報が検索結果に表示されるのは、ジョブ・リクエスト検索のスコープを「ESSリポジトリを共有するすべてのスケジューリング・サービス」に設定している場合のみです。検索の実行の詳細は、第4.2.2項を参照してください。
ジョブの取消しが効果的でない場合は、関連するOracle Enterprise Schedulerサーバーを再起動します。
ナビゲーション・ペインでファームを開いて「WebLogicドメイン」を開きます。
Oracle Enterprise Schedulerクラスタを展開し、Oracle Enterprise Schedulerサーバーを選択します。
WebLogic Serverホームページで、「WebLogic Server」メニューから、「コントロール」→「停止」を選択します。
サービスの停止後、WebLogic Serverホームページで、「WebLogic Server」メニューから、「コントロール」→「起動」を選択します。
「リクエスト詳細」ページの「アクション」メニューから、「スタック・リクエストのリカバリ」を選択します。
非同期ジョブ・リクエストの手動リカバリが必要な場合は、次の基本の手順を実行します。追加の手順はジョブ・タイプによって異なります。
リクエストがスタックしている(手動リカバリとしてマーキングされている、長時間実行している、またはタイムアウトになっている)場合で、そのリクエストが非同期リモート・ジョブであるときは、まずリモート・ジョブがまだ実行中であるかどうかを調べます。
非同期ジョブを処理するには:
リモート・ジョブがまだ実行中であるかどうかを調べます。
「リクエスト詳細」ページにナビゲートし、リモート・ジョブを特定します。「リクエスト詳細」ページの表示方法の詳細は、第4.2.4項を参照してください。
- PL/SQLジョブの場合は、「リクエスト詳細」ページにナビゲートし、「実行タイプ」アイコンをクリックします。スケジュール済ジョブ・リクエストとデータベース・スケジューラ・ジョブの相関関係を示す、データベース・セッション情報が表示されます。これでジョブ・リクエストがまだ実行中であるかどうかを確認できます。
- 生成されたジョブの場合、「リクエスト詳細」ページにナビゲートし、「実行タイプ」アイコンをクリックして生成されたプロセスの情報を表示します。これはスケジュール済ジョブ・リクエストと非Oracle Enterprise Schedulerジョブ(この場合オペレーティング・システム・プロセス)の相関関係を示します。この相関関係でジョブがまだ実行中であるかどうかを確認できます。
リモート・ジョブがもう実行していないことを確認します。
- リモート・ジョブがリモート・システムで正常に作成されていなかった場合は、ジョブ・リクエストのステータスをERRORに設定します。
- リモート・ジョブが作成され実行を終了している場合は、そのステータスを確認し、ジョブ・リクエストのステータスを適宜設定します。
- リモート・ジョブ・インスタンスの実行が終了してない場合、ジョブの完了を待ち、ジョブ・リクエストのステータスを適宜設定します。
リモート・ジョブが実行中の状態でなくなったら、Oracle Enterprise Schedulerでジョブ・リクエストを終了させ、Oracle Enterprise Schedulerがそのジョブを追跡しないようにします。
「スケジューリング・サービス」メニューをクリックし、「ジョブ・リクエストの検索」を選択し、「リクエストの検索」ページにナビゲートします。
「クイック検索」リストで、手動リカバリ(ERROR_MANUAL_RECOVERY)としてマーキングされた非同期ジョブの場合は、「手動リカバリが必要な非同期リクエスト」を選択します。リクエストはRUNNING状態になっています。ERROR_MANUAL_RECOVERY状態でない非同期ジョブの場合は、「手動リカバリが必要な非同期リクエスト」オプションを使用するのではなく、更新が必要な既知のリクエストを検索します。
検索結果で、「リクエスト詳細」ページを表示するリクエストIDをクリックします。
「リクエスト詳細」ページの「アクション」メニューから、「スタック・リクエストのリカバリ」を選択します。
「スタック・リクエストのリカバリ」ダイアログ・ボックスで、ジョブ・リクエストの状態を適宜設定します。オプションで、ジョブ・リクエストのステータスの説明を追加します。
ステータスをERRORに設定した場合、追加した説明が「リクエスト詳細」ページに表示されます。
様々な理由からスケジュール済ジョブが実行されなかったり、実行に失敗したりすることがあります。いずれの場合でも、Fusion Middleware Controlの「ジョブ詳細」ページにある組込み診断を使用できます。エラーで失敗したジョブの場合、「ジョブ詳細」ページに理由が表示され、ジョブ・リクエスト・ログへのアクセス手段が提供されます。
Fusion Middleware Controlでは次のものが提供されます。
ジョブ・リクエスト・ログへのアクセス。
PL/SQLジョブ・リクエストの場合は、データベース・セッション情報。PL/SQLジョブ・リクエストの「ジョブ詳細」ページに表示されます。
プロセス・ジョブ・リクエスト場合は、生成されたプロセスの情報。プロセス・ジョブ・リクエストの「ジョブ詳細」ページに表示されます。
待機、準備完了またはブロックされている状態のジョブ・リクエストの場合は、ジョブ・リクエストがその状態になっている理由を示すメッセージが「ジョブ詳細」ページに表示されます。
「ジョブ詳細」ページにエラーと警告のメッセージが表示されます。スタック・トレースなどの追加情報も表示されます。
再試行されたジョブ・リクエストの場合は、「ジョブ詳細」ページに、実行した再試行回数、次の再試行時間、エラーが続く場合に実行される残りの再試行回数が表示されます。
手動リカバリを要するジョブ・リクエストまたはタイムアウトしたジョブ・リクエストの場合は、「ジョブ詳細」ページに、手動リカバリの必要性を示すメッセージが表示されます。
ジョブ・リクエスト詳細の表示の詳細は、第4.2.4項を参照してください。
表B-1に、各状態に関連付けられている診断コード、説明および追加情報を示します。この表に記載されていない状態のリクエストについては、その診断にリクエストの状態しか含まれません。
表B-1 ジョブ・リクエストの状態と関連付けられている診断コード
| 状態 | 診断コード | 説明 | 関連ドキュメント |
|---|---|---|---|
|
|
|
非互換のジョブ・リクエストによりブロックされました。ブロックしているリクエストのリクエストIDが含まれます。 |
ジョブ・リクエストの取消しの詳細は、第4.2.6項を参照してください。 |
|
|
|
ポストプロセッサが原因で、ジョブ・リクエストが遅れています。遅延の終了時間が含まれます。 |
|
|
|
|
ジョブ・リクエストは1つ以上のサブリクエストの親であり、一時停止されている状態です。非終了状態のサブリクエストがある場合は、そのリクエストIDが含まれます。 |
一時停止されたジョブ・リクエストの再開の詳細は、第4.2.5項を参照してください。 |
|
|
|
プロセス・グループにアクティブなサーバーがありません。プロセスおよび分離グループの名前が含まれます。 |
Oracle Enterprise Schedulerのアクティブ化の詳細は、第3.6項を参照してください。 |
|
|
|
ジョブ・リクエストの |
|
|
|
|
アプリケーションがデプロイされていないか、非アクティブです。アプリケーション、プロセス・グループおよび分離グループの名前が含まれます。 |
|
|
|
|
アプリケーションがデプロイされていてアクティブ・プロセッサのあるサーバーがないため、リクエストを処理できません。 |
リクエスト・プロセッサの起動の詳細は、第3.6.2項を参照してください。 |
|
|
|
アプリケーションがデプロイされているすべてのサーバーにおいてプロセッサでエラーが発生したため、リクエストを処理できません。 |
|
|
|
|
プロセッサ・スレッドが使用可能になるのをジョブ・リクエストが待機しています。ジョブ・リクエストを処理できる作業割当ての名前が含まれます。 |
|
|
|
|
作業割当てがアクティブになるのを待機しています。アクティブである場合にジョブ・リクエストを処理できる現在非アクティブな作業割当ての名前が含まれます。 |
|
|
|
|
リクエストを処理できる作業割当てがバインドされていますが、バインディングがロードされていません。サーバーがダウンしている可能性があります。リクエストを処理できる未ロードの作業割当ての名前が含まれます。 |
Oracle Enterprise Schedulerのアクティブ化の詳細は、第3.6項を参照してください。 |
|
|
|
特殊化された作業割当てをジョブ・リクエストにバインドする必要があります。 |
作業割当てのバインディングの詳細は、第3.4.2項を参照してください。 |
|
|
|
ジョブ・リクエストは非同期リクエストであり、これと同じタイプのアクティブな非同期ジョブの数が制限数と同じです。作業割当て、稼働シフト、非同期ジョブ・タイプおよび非同期制限が含まれます。 |
ジョブに割り当てるスレッド数を変更するか、稼働シフトの非同期ジョブ制限を変更します。稼働シフトの編集の詳細は、第5.3.1.1項を参照してください。 |
|
|
|
リクエストを処理できる作業割当てがバインドされていますが、作業割当てが無効です。無効の作業割当ての名前が含まれます。 |
作業割当てを有効にします。作業割当ての編集の詳細は、第5.3.1.1項を参照してください。 |
|
|
|
プリプロセッサが原因で、リクエストが遅れています。遅延の終了時間が含まれます。 |
|
|
|
|
ジョブ・リクエストがタイムアウトになりました。通常、このコードはタイムアウトになった非同期Javaジョブ・リクエストに対して表示されます。 |
|
|
|
|
プロセス・グループ内にアクティブなサーバーがないため、ジョブ・リクエストの処理を継続できません。プロセスおよび分離グループの名前が含まれます。 |
Oracle Enterprise Schedulerサーバーが実行中であることを確認します(第6.2項を参照してください)。必要であれば、第3.6項の説明のとおり、Oracle Enterprise Schedulerコンポーネントの1つを再起動します。 |
|
|
|
ジョブ・リクエストの |
Oracle Enterprise Schedulerサーバーが実行中であることを確認します(第6.2項を参照してください)。必要であれば、第3.6項の説明のとおり、Oracle Enterprise Schedulerコンポーネントの1つを再起動します。 |
|
|
|
アプリケーションがデプロイされていないか、非アクティブであるため、ジョブ・リクエストの処理を継続できません。アプリケーション、プロセス・グループおよび分離グループの名前が含まれます。 |
|
|
|
|
アプリケーションがデプロイされていてアクティブ・プロセッサのあるサーバーがないため、ジョブ・リクエストの処理を継続できません。 |
Oracle Enterprise Schedulerサーバーが実行中であることを確認します(第6.2項を参照してください)。第3.6.2項の説明のとおり、リクエスト・プロセッサを起動します。 |
|
|
|
アプリケーションがデプロイされているすべてのサーバーにおいてプロセッサでエラーが発生したため、ジョブ・リクエストの処理を継続できません。 |
Oracle Enterprise Schedulerサーバーが実行中であることを確認します(第6.2項を参照してください)。第3.6.2項の説明のとおり、リクエスト・プロセッサを再起動します。 |
|
|
|
使用可能なプロセッサ・スレッドが非同期Javaジョブ・リクエストの更新イベントを処理するのを待っています。リクエストを処理できる作業割当ての名前が含まれます。ジョブ・リクエストが更新イベントを無効にしたかどうかを示します。 |
|
|
|
|
作業割当てがアクティブになり非同期Javaリクエストの更新イベントを処理するのを待っています。アクティブである場合にリクエストを処理できる現在非アクティブな作業割当ての名前が含まれます。ジョブ・リクエストが更新イベントを無効にしたかどうかを示します。 |
ジョブ・リクエストを処理できるようにするため、非アクティブな作業割当てをアクティブ化します。詳細は、第5.3.1.1項を参照してください。 |
|
|
|
非同期Javaジョブ・リクエストの処理が遅れている可能性があります。更新イベントを処理できる作業割当てがバインドされていますが、バインディングがロードされていません。サーバーがダウンしている可能性があります。ジョブ・リクエストを処理できる未ロードの作業割当ての名前が含まれます。ジョブ・リクエストが更新イベントを無効にしたかどうかを示します。 |
Oracle Enterprise Schedulerサーバーが実行中であることを確認します(第6.2項を参照してください)。必要であれば、第3.6項の説明のとおり、Oracle Enterprise Schedulerコンポーネントの1つを再起動します。 |
|
|
|
非同期Javaジョブ・リクエストの処理が遅れている可能性があります。非同期Javaジョブ・リクエストの更新イベントを処理できる作業割当てがバインドされていません。リクエストが更新イベントを無効にしたかどうかを示します。 |
作業割当てをリクエスト・プロセッサにバインドします。詳細は、第3.4.2項を参照してください。 |
|
|
|
非同期Javaジョブ・リクエストの処理が遅れている可能性があります。ジョブ・リクエストの更新イベントを処理できる作業割当てがバインドされていますが、作業割当てが無効です。無効の作業割当ての名前が含まれます。ジョブ・リクエストが更新イベントを無効にしたかどうかを示します。 |
作業割当てを有効にします。作業割当ての編集の詳細は、第5.3.1.1項を参照してください。 |
|
|
|
ジョブ・リクエストに将来のスケジュール時間があります。ジョブ・リクエストのスケジュール時間が含まれます。 |
|
|
|
|
ジョブ・リクエストでエラーが発生し、再試行が実行される前にジョブ・リクエストが遅れています。スケジュールされている再試行時間が含まれます。 |
|
|
|
|
ジョブ・リクエストのスケジュール時間に到達しましたが、アプリケーションが使用不可(デプロイされていない、またはアクティブでない)であるためジョブ・リクエストをディスパッチできません。アプリケーション、プロセス・グループおよび分離グループの名前が含まれます。 |
|
|
|
|
ジョブ・リクエストはサブリクエストであり、その親が一時停止していません。親が一時停止するまで、サブリクエストは |
一時停止されたジョブ・リクエストの一時停止の詳細は、第4.2.5項を参照してください。 |
|
|
|
ジョブ・リクエストは、前の再帰インスタンスがまだ実行中の再帰インスタンスです。Oracle Enterprise Schedulerでは再帰インスタンスを同時実行できず、現在の再帰がアクティブである間、次の再帰は |
|
|
|
|
アプリケーションがデプロイされていてディスパッチャが実行中のサーバーがないため、ジョブ・リクエストをディスパッチできません。 |
リクエスト・ディスパッチャを再起動します。詳細は、第3.6.2項を参照してください。 |
|
|
|
アプリケーションがデプロイされているすべてのサーバーにおいてディスパッチャでエラーが発生したため、ジョブ・リクエストをディスパッチできません。 |
リクエスト・ディスパッチャまたは他のOracle Enterprise Schedulerコンポーネントを再起動します。詳細は、第3.6.2項および第3.6.1項を参照してください。 |
|
終了状態 |
|
ジョブ・リクエストは終了状態( |
|
注意: ジョブの状態の詳細は、Oracle Fusion Middleware Oracle Enterprise Scheduler Java APIリファレンスを参照してください。 |
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メトリックが用意されています。
ジョブ名別の完了済ジョブ・リクエスト統計。完了したリクエストの実行回数、実行時間、成功率および前回実行ジョブ・リクエストについての統計を、ジョブ名別に表示します。
ユーザー別の完了済ジョブ・リクエスト統計。完了したリクエスト数および完了したリクエストの実行時間を、ユーザー別に表示します。
作業割当て別の完了済ジョブ・リクエスト統計。完了したジョブ・リクエストの待機時間、処理時間、完了数および失敗数を、作業割当て別に表示します。
ステータス別の完了済ジョブ・リクエスト数。様々な終了状態で完了したジョブ・リクエストを表示します。
メトリックの詳細は、[TODO: new link. was 9.7]を参照してください。
複数のアプリケーション・ドメインで共通のデータベースを使用できます。この場合、データベースに複数のソースから負荷がかかる可能性があります。このため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ジョブと非同期ジョブのそれぞれに、最大同時実行性の制限を定義します。非同期スロットル制限は、そのジョブが割り当てられる作業割当てで設定します。非同期ジョブ制限の設定の詳細は、第5.3.2.1項を参照してください。
構成したすべてのスレッドが同期ジョブで使用されてしまい、その結果非同期ジョブの開始が妨げられることがあります。このような状況は、非同期ジョブと同期ジョブを1つの作業割当てで組合せないようにすることで回避できます。
ジョブの非互換性を構成して2つの非互換ジョブが実行されるのを回避するだけでなく、高い負荷を与える2つのジョブが同じリソースに大量の負荷を与えないようにすることができます。そのようなジョブが同時に実行されないよう非互換性を定義することで、高いパフォーマンスを維持できます。ジョブの非互換性の定義の詳細は、第5.2.3.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ファイルのパラメータ」の章を参照してください。
この項では、Oracle Enterprise Schedulerの一般的な問題と解決策について説明します。この章の内容は、次のとおりです。
これらの推奨される解決策に加え、第B.3.3項のチューニングのヒントも参考にしてください。
問題
ユーザーがジョブを送信したときに、ジョブが長時間WAIT状態に留まったまま、RUNNING状態に遷移しないことがあります。
解決策
この問題を解決するには、Oracle Enterprise Schedulerの現在のステータスをFusion Middleware Controlから確認します。
リクエスト・プロセッサおよびディスパッチャが実行しているかどうかを確認します。
ナビゲーション・ペインで、ファーム、「スケジューリング・サービス」を展開します。
適切な管理対象サーバーのESSAPPアプリケーションを選択します。
スケジューリング・サービスのホームページの「スケジューラ・コンポーネント」セクションで、リクエスト・プロセッサのステータスが「起動済」になっていることを確認します。
実行中でない場合は、起動してください。第3.6.2項を参照してください。
スケジューリング・サービスのホームページの「スケジューラ・コンポーネント」セクションで、リクエスト・ディスパッチャのステータスが「起動済」になっていることを確認します。
実行中でない場合は、第3.6.2項の説明のとおり起動します。
ESSAPPアプリケーションが実行していることを確認します。
ナビゲーション・ペインで、ファーム、「スケジューリング・サービス」を展開します。
適切な管理対象サーバーのESSAPPアプリケーションを選択します。
スケジューリング・サービスのホームページの「スケジューラ・コンポーネント」セクションで、リクエスト・ディスパッチャのステータスが「起動済」になっていることを確認します。
WebLogic Serverのホームページの「デプロイメント」セクションで、ESSAPPアプリケーションが実行していることを確認します。
実行中でない場合は、起動してください。第3.6.1項を参照してください。
プロセッサと作業割当ての構成を確認し、構成されている同時実行性またはスレッドが少なすぎないかを確認します。
問題
ユーザーがジョブを送信したときに、ジョブのRUNNING状態が長時間続きます。
解決策
Oracle Enterprise Schedulerサーバーがクラッシュし、リカバリが行われていないために、ジョブがRUNNING状態になっている可能性があります。
この問題を解決するには、Oracle Enterprise Schedulerの現在のステータスをFusion Middleware Controlから確認します。
リクエスト・プロセッサが実行していることを確認します。
ナビゲーション・ペインで、ファーム、「スケジューリング・サービス」を展開します。
適切な管理対象サーバーのESSAPPアプリケーションを選択します。
スケジューリング・サービスのホームページの「スケジューラ・コンポーネント」セクションで、「リクエスト・プロセッサ」が有効で起動済であることを確認します。
実行中でない場合は、起動してください。第3.6.2項を参照してください。
Oracle Enterprise Schedulerサーバーが実行中であることを確認し、実行中でない場合は起動します。
ナビゲーション・ペインでファームを開いて「WebLogicドメイン」を開きます。
Oracle Enterprise Schedulerクラスタを選択します。
「WebLogicクラスタ」ページの「サーバー」セクションで、「ステータス」列を確認し、Oracle Enterprise Schedulerサーバーが実行中であることを確認します。
サーバーのステータス表示がダウン(赤の下向き矢印)である場合は、「名前」列でサーバー名をクリックします。
WebLogic Serverホームページで、「WebLogic Server」メニューから、「コントロール」→「起動」を選択します。
ジョブ出力でジョブが進行していることを確認します。第4.2.4項を参照してください。
Oracle Enterprise Schedulerサーバーを再起動したときに、そのサーバーで実行されている同期ジョブの状態はERROR状態に遷移します。
問題
PLSQL、非同期SOAサービスを呼び出すJavaジョブおよび非同期Oracle Application Development Framework (Oracle ADF) Business Componentサービスを呼び出すJavaジョブは、別のJava仮想マシン(JVM)または別のマシンで実行されます。このような場合、Oracle Enterprise Schedulerは、処理後にジョブの結果を定義する完了ステータスを送信するリモート・ジョブに依存します。しかし、このメッセージが生成されなかったり失われると、ジョブがRUNNING状態のままになることがあります。さらに、ジョブ・セットの後続のステップが実行されなかったり、非互換ジョブが無期限にブロックされることがあります。
解決策
この問題を解決するには、第B.2.1項の手順を実行します。
問題
非同期SOAサービスを呼び出すジョブは別のJava仮想マシン(JVM)または別のマシンで実行されます。このような場合、Oracle Enterprise Schedulerは、処理後にジョブの結果を定義する完了ステータスを送信するリモート・ジョブに依存します。しかし、様々な原因でこのメッセージが生成されないことがあります。
解決策
この問題を解決するには、ネイティブ・ジョブの問題を解決する必要があります。
このタイプの非同期SOAジョブ問題を解決するには:
第4.2.2項の説明のとおり、リクエストを検索します。
「リクエスト詳細」ページの「アクション」メニューから、「リクエスト・ログ」を選択してログ・メッセージを表示します。「リクエスト詳細」ページの詳細は、第4.2.4項を参照してください。
「ログ・メッセージ」ページが表示されます。デフォルトで、ユーザーがリクエストのログを表示したときに表示されるメッセージは、Oracle Enterprise Schedulerクラスタのスコープでログ記録されたメッセージのみです。(ESSAPPアプリケーションがクラスタにデプロイされていない場合は、管理対象サーバーのスコープ内でログ記録されたメッセージが表示されます)。しかし、Oracle Enterprise Schedulerは、リクエストに関連付けられたECIDを、Oracle SOA SuiteやOracle ADFなどのサブシステム全体に伝播します。
「ECID」フィールドの値をメモしておきます。
「広範囲のターゲット・スコープ」リストから、/farm_name/domain_name (Oracle WebLogicドメイン)を選択して、ドメイン全体のメッセージを表示します。
Oracle WebLogic Serverドメインの「ログ・メッセージ」ページの「選択したターゲット」セクションで、「リクエスト詳細」ページで取得した値を持つ「ECID」フィールドが検索に含まれていることを確認します。
Oracle SOA SuiteおよびECIDのログ・レコードを検索して表示し、問題をメモします。第6.7.4項。
ECIDを使用してSOAコンポジット・アプリケーション・インスタンスの監査証跡を表示します。
ナビゲーション・ペインで、ファーム、「SOA」、「SOAインフラ」を展開します。
「SOAインフラストラクチャ」ページで、「インスタンス」タブをクリックします。
「検索」セクションで、「ECID」フィールドにECIDを入力します。
「検索」をクリックし、そのECIDのインスタンスを検索します。
「インスタンス」表内の「インスタンスID」フィールド内のIDをクリックして、インスタンスを選択します。
「フローのトレース」ページが表示されます。
インスタンスの監査証跡を確認し、コンポジットが正常に終了したのか、またはエラーで終了したのかを調べます。「フローのトレース」ウィンドウの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のBPELプロセス・サービス・コンポーネントの監査証跡およびプロセス・フローの表示に関する項を参照してください。
SOAコンポジットが完了していてジョブがまだOracle Enterprise Schedulerで実行中である場合は、「リクエスト詳細」ページでジョブを手動で完了させます。詳細は、第B.2.1項を参照してください。
問題
非同期Oracle ADFビジネス・コンポーネント・サービスを呼び出すジョブは別のJVMまたは別のコンピュータで実行されます。このような場合、Oracle Enterprise Schedulerは、処理後にジョブの結果を定義する完了ステータスを送信するリモート・ジョブに依存します。しかし、様々な原因でこのメッセージが生成されないことがあります。
解決策
この問題を解決するには、ネイティブ・ジョブの問題を解決する必要があります。
このタイプの同期Oracle ADFビジネス・コンポーネント・ジョブ問題を解決するには:
第4.2.2項の説明のとおり、リクエストを検索します。
「リクエスト詳細」ページの「アクション」メニューから、「リクエスト・ログ」を選択してログ・メッセージを表示します。「リクエスト詳細」ページの詳細は、第4.2.4項を参照してください。
「ログ・メッセージ」ページが表示されます。デフォルトで、ユーザーがリクエストのログを表示したときに表示されるメッセージは、Oracle Enterprise Schedulerクラスタのスコープでログ記録されたメッセージのみです。(ESSAPPアプリケーションがクラスタにデプロイされていない場合は、管理対象サーバーのスコープ内でログ記録されたメッセージが表示されます)。しかし、Oracle Enterprise Schedulerは、リクエストに関連付けられたECIDを、Oracle SOA SuiteやOracle ADFなどのサブシステム全体に伝播します。
「ECID」フィールドの値をメモしておきます。
「広範囲のターゲット・スコープ」リストから、/farm_name/domain_name (Oracle WebLogicドメイン)を選択して、ドメイン全体のメッセージを表示します。
Oracle WebLogic Serverドメインの「ログ・メッセージ」ページの「選択したターゲット」セクションで、「リクエスト詳細」ページで取得した値を持つ「ECID」フィールドと「コンポーネント名」フィールドが検索に含まれていることを確認します。
Oracle ADFビジネス・コンポーネントのログ・レコードおよびECIDのWebサービス・スタックを検索して表示し、問題をメモします。『Oracle Fusion Middleware管理者ガイド』のログ・ファイルの表示と検索に関する項を参照してください。
Oracle ADFビジネス・コンポーネントが正常に終了したのか、またはエラーで終了したのかを調べます。
サービスが完了していてジョブがまだOracle Enterprise Schedulerで実行中である場合は、「リクエスト詳細」ページでジョブを手動で完了させます。詳細は、第B.2.1項を参照してください。
問題1
PL/SQLジョブは別のマシンで実行されます。このような場合、Oracle Enterprise Schedulerは、処理後にジョブの結果を定義する完了ステータスを送信するリモート・ジョブに依存します。しかし、様々な原因でこのメッセージが生成されないことがあります。
解決方法1
Oracle Enterprise Scheduler内で、PL/SQLジョブはジョブ名で識別できます。ジョブ定義名は、リクエストに関連付けられているFusion Middleware Controlの「リクエスト詳細」ページで確認できます。第4.2.4項を参照してください。
この問題を解決するには、ネイティブ・ジョブの問題を解決します。詳細は、第B.2.1.2項を参照してください。
問題2
Oracle Enterprise Schedulerは内部でデータベース管理システム(DBMS)のスケジューラを使用して、PL/SQLジョブをスケジュールします。場合によっては、Oracle Enterprise SchedulerがジョブをDBMSスケジューラに送信し、状態をRUNNINGに設定したのに、DBMSスケジューラでジョブ・リクエストがスケジュールされないことがあります。
解決方法2
この問題を解決する手順は次のとおりです。
DBMSスケジューラのリソース使用状況を確認します。『Oracle Database管理者ガイド』の「Oracle Schedulerの管理」の章を参照してください。
PL/SQLジョブ制限を構成し、PL/SQLジョブのスロットル制限を変更します。第5.3.2項を参照してください。
問題
ジョブのスケジュール時間に到達しても、ジョブが実行されません。
解決策
この問題を解決するには、Fusion Middleware Controlの「リクエスト詳細」ページを確認します。このページには組込み診断があり、問題の内容が表示されます。エラーになったジョブの場合、「リクエスト詳細」ページにその理由が表示され、「アクション」メニューからジョブ・リクエスト・ログにアクセスできます。第4.2.4項を参照してください。
ジョブ診断の詳細は、第B.2.4項を参照してください。
問題
ジョブがERROR_MANUAL_RECOVERY状態になります。ジョブがエラー手動リカバリの状態になる理由は様々です。たとえば非同期ジョブの場合、エラーの発生により、ジョブが正常に起動されたどうかをジョブ実装が知ることができず、エラー手動リカバリ例外がスローされます。ジョブがエラー手動リカバリになる理由については、第B.2.3項を参照してください。
解決策
この問題を解決するには、ジョブ・ステータスを手動で完了の状態に更新します。第B.2.3.1項および第B.2.3.2項を参照してください。
問題
生成されたプロセス・タイプのジョブがERROR_MANUAL_RECOVERY状態になります。
解決策
この問題を解決するには、次の手順を実行してリクエストを終了状態に移します。
「リクエスト詳細」ページで、生成されたホストおよびプロセスIDを特定します。「リクエスト詳細」ページの詳細は、第4.2.4項を参照してください。
ホストでまだプロセスが実行している場合は、ジョブが完了するまで待つか、終了させます。
プロセスが実行中でない場合は、エラー状態に遷移させるためリクエストをリカバリします。これは、自動再試行(構成されている場合)に依存します。Fusion Middleware Controlで、次の手順を実行します。
ジョブの手動リカバリの詳細は、第B.2.3項を参照してください。
問題
ジョブを取り消したときに、CANCELLING状態が続いたまま、ジョブが取り消されないことがあります。リクエスト取消しの結果がどうなるかは、取消し操作を実行したときのリクエストの処理ステージと、そのステージの結果によって決まります。多くのジョブが非同期ADFサービスの呼出しとして実装されます。アプリケーション・インフラストラクチャでは進行中サービス・リクエストの取消しがサポートされないため、予期したとおりにジョブを取り消すことがきません。また、これ以外の理由でもジョブがCANCELLING状態でスタックすることがあります。
PL/SQLジョブの場合、Oracle Enterprise SchedulerはRDBMSスケジューラ・ジョブの強制終了を試みます。生成されたプロセスの場合、Oracle Enterprise Schedulerは実行中のプロセスの強制終了を試みます。ジョブが正常に強制終了された場合、リクエストはCANCELLED状態に遷移します。強制終了が成功する前にジョブが完了した場合、リクエストがどの状態に遷移するかは、ジョブ実行の結果によって決まります。これらのタイプのジョブでは、この問題は発生しません。
非同期Javaジョブ: リクエストは取り消されますが、リモート・ジョブが終了ステータスをOracle Enterprise Schedulerに通知しません。これは、AsyncCancellableインタフェースが実装されていないか、リモートの取消し操作の失敗が原因で、ジョブがまだ実行を続けている場合に発生します。リモート・システムが応答できない場合にも発生する可能性があります。
同期Javaジョブ: リクエストは取り消されますが、ジョブがまだ実行しています。これは、Cancellable()インタフェースが実装されていないか、ジョブのExecutable.execute()メソッドがCancellable.cancelの呼出し後に返らないことが原因で、発生します。Executableインタフェースの詳細は、Oracle Fusion Middleware Oracle Enterprise Scheduler開発者ガイドのユース・ケースOracle Enterprise Schedulerサンプル・アプリケーションに関する項を参照してください。
ジョブ・セット(親-子リクエスト): ジョブ・セットの場合、取消し操作はすべての資格のある子リクエストに伝播されます。すべての子リクエストが完了するまで、親リクエストはCANCELLING状態に留まります。
SOA Javaジョブ: ジョブがエラーで終了した場合は、コンポジット・インスタンスを探し監査証跡とECIDタグが付いたログを確認して、Fusion Middleware ControlでECIDを探し、何が発生したのかを確認します。ECIDの検索の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のBPELプロセス・サービス・コンポーネントの監査証跡およびプロセス・フローの表示に関する項を参照してください。
Oracle ADFビジネス・コンポーネントJavaジョブ: リクエストがエラーで終了する場合は、次のディレクトリにあるserver-name-diagnostic.logファイルでメッセージIDを探し、何が発生したのかを確認します。
(UNIX) DOMAIN_HOME/servers/server_name/logs (Windows) DOMAIN_HOME\servers\server_name\logs
ログ・ファイルの表示の詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルの表示と検索に関する項を参照してください。
解決策
Fusion Middleware Controlで手動の介入操作を行い、CANCELLING状態でスタックしているジョブを完了させます。
スタックしている非同期リクエストのリカバリを行うには、リモート・ジョブがまだ実行中であるかどうかを確認します。実行中の場合は、Oracle Enterprise Scheduler側で行う操作はありません。リモート・ジョブがもう実行していない場合は、Fusion Middleware Controlで次の手順を実行し、リクエストを完了させます。
第4.2.2項の説明のとおり、リクエストを検索します。
「リクエスト詳細」ページの「アクション」メニューから、「スタック・リクエストのリカバリ」を選択します。「リクエスト詳細」ページの詳細は、第4.2.4項を参照してください。
同期Javaジョブの場合は、ジョブが完了するまで待ちます。ジョブが完全に止まってしまっている状態の場合は、ジョブの実行先のサーバーを再起動する必要があります。
問題
データベース負荷の高い2個のジョブを同時に実行するとパフォーマンスとスケーラビリティが低下します。
ジョブ・パフォーマンスの問題を確認するには:
オペレーティング・システム・レベルのツールまたはデータベース管理システム(DBMS)ツールを使用して、Oracleデータベース全体のパフォーマンス・メトリックを確認し、パフォーマンスのボトルネックをこれらの同時実行される2つのジョブにまで切り分け、チューニングを実施できるようにします。
ジョブの実行時間を確認します。
ナビゲーション・ペインで、ファーム、「スケジューリング・サービス」を展開します。
適切な管理対象サーバーのESSAPPアプリケーションを選択します。
スケジューリング・サービスのホームページで、「長時間実行しているジョブ・リクエストの上位10」タブをクリックしてジョブを表示します。
解決策
この問題を解決するには、次のいずれかの手順を実行します。
問題
新しく追加した管理対象サーバーが予期したとおりにジョブを実行しない、またはまったく利用されていません。
ジョブ履歴を見ると、このサーバーでジョブが実行されている形跡がない、またはこのサーバーで実行すべきではない特定のジョブが実行されていることを確認できます。
ジョブ履歴を表示するには:
ナビゲーション・ペインで、ファーム、「スケジューリング・サービス」を展開します。
適切な管理対象サーバーのESSAPPアプリケーションを選択します。
ジョブ履歴で、このサーバーでジョブが実行されている形跡がないことを確認します。
第4.2.2項の説明のとおりリクエストを検索し、すでに実行されたジョブのリストを表示します。
「リクエスト検索」ページで「リクエストID」列からジョブをクリックし、ジョブの「リクエスト詳細」ページに移動します。
「リクエスト詳細」ページの「実行証跡」セクションで、ジョブが実行された「ディスパッチャ」、「プロセッサ」、「作業割当て」および「稼働シフト」を確認します。
解決策
新しいサーバーを追加すると、Oracle Enterprise Schedulerはデフォルトの作業割当てを使用できるかどうかを、他のプロセッサのバインド状況を基に判断します。デフォルトの作業割当てを使用できない場合、ヘルス・チェック・サービス(内部作業割当てESSInternalWA)のみを実行するように新しいサーバーが構成されます。このデフォルト構成に再びアクセスして、このサーバーへの作業割当てバインディングを任意に構成し、ヘルス・チェックの完了後に内部作業割当てを削除します。詳細は、第3.4.1項を参照してください。
問題
Oracle Enterprise Schedulerランタイム・システムが正常に動作せず、ジョブの処理時にエラーがスローされる、または問題が発生します。
解決策
この問題を特定および解決するには、Oracle Enterprise Schedulerシステム・ログを確認し、問題を解決します。Fusion Middleware Controlで、次を実行します。
第4.2.2項の説明のとおり、リクエストを検索します。
「リクエスト詳細」ページの「アクション」メニューから、「リクエスト・ログ」を選択してログ・メッセージを表示します。「リクエスト詳細」ページの詳細は、第4.2.4項を参照してください。
ログ・レベルを調整するには:
ナビゲーション・ペインで、ファーム、WebLogicドメイン、Oracle Enterprise Schedulerクラスタを展開し、Oracle Enterprise Schedulerサーバー(たとえば、ess_server1)を選択します。
WebLogic Serverのホームページが表示されます。
「WebLogic Server」メニューから、「ログ」→「ログ構成」を選択して「ログ構成」ページを表示します。
Oracle WebLogic Serverのlogging.xmlファイルを変更して、Oracle WebLogic Serverに対するOracle Enterprise Schedulerサーバー・ログ出力を構成できます。デフォルトで、Oracle Enterprise Schedulerの明示的なログ出力エントリはありません。Oracle Enterprise Schedulerは、親のログ出力(通常は"oracle"ログ出力または("")ルート・ログ出力)で構成されたロギング・レベルとログ・ハンドラを継承します。
デフォルトで、Oracle Enterprise Schedulerサーバー・ログ出力のログ・メッセージは、Oracle WebLogic ServerのOracle WebLogic Server診断ログ・ファイルで確認できます。ロギングとログ・レベルの詳細は、第6.7.4項を参照してください。
|
注意: ログ出力には、Oracle WebLogic Serverで実行されているOracle Enterprise Schedulerジョブが書き込んだログしか表示されません。Oracle Enterprise Schedulerが実行中のPL/SQLジョブおよびCジョブのコントロールを、PL/SQLプロセスまたはCプロセスにそれぞれ移すと、PL/SQLおよびCジョブが別のプロセスで実行されるため、PL/SQLおよびCジョブのロギング・データはOracle Enterprise Schedulerログに書き込まれません。 |
問題
Oracle Enterprise Schedulerでデータベース接続が不足する場合、Oracle Enterprise Schedulerに接続リークの問題が発生している可能性があります。
説明
『Oracle Fusion Middleware管理者ガイド』のデータ・ソース接続の不足に関する項を参照してください。
問題
一部のジョブが予期したとおりに動作しないことがあります。一部のジョブがスピンまたは停止していたり、ジョブにメモリー・リークが存在する場合に、ジョブ・キューが長くなることがあります。
解決策
次に、一般的なシナリオを示します。
Javaジョブが無限ループに入り、キュー内にそのジョブの終了を待っているジョブがあります。
この問題を解決するには、Fusion Middleware Controlで次の手順を実行します。
ナビゲーション・ペインで、ファーム、「スケジューリング・サービス」を展開します。
適切な管理対象サーバーのESSAPPアプリケーションを選択します。
「スケジューリング・サービス」メニューから、「リクエスト・プロセッサ」→「構成」を選択し、「リクエスト・プロセッサの構成」ページの「スレッド数」フィールドを確認します。第3.4.2項を参照してください。
「スレッド数」フィールドが25同期Javaジョブに設定されている場合、RUNNING状態になることができるのは25個のJavaジョブであり、その他すべてのJavaジョブは処理されるまでキューで待つことになります。
一部のジョブで過負荷の処理が実行されている場合やジョブの停止が疑われる場合は、専用の作業割当てを定義して、それらのジョブを特定のOracle Enterprise Schedulerサーバーで実行し、他のジョブは残りのサーバーで実行させるようにして、問題のジョブを分離します。第5.3.1.1項を参照してください。
Oracle Enterprise Schedulerサーバーを再起動します。
ナビゲーション・ペインでファームを開いて「WebLogicドメイン」を開きます。
Oracle Enterprise Schedulerクラスタを展開し、Oracle Enterprise Schedulerサーバーを選択します。
WebLogic Serverホームページで、「WebLogic Server」メニューから、「コントロール」→「停止」を選択します。
サービスの停止後、WebLogic Serverホームページで、「WebLogic Server」メニューから、「コントロール」→「起動」を選択します。
サーバーの再起動後、Oracle Enterprise SchedulerはRUNNINGジョブをERROR状態に移し、キュー内の次のジョブ・バッチの処理を開始します。
PL/SQLジョブが無限ループに入り、終了しません。送信済のPL/SQLジョブが他にも多数あります。
PLSQLジョブを取り消し、ジョブをCANCELLED状態に移動します。第4.2.6項を参照してください。
大規模なデータベース挿入および更新により、ジョブが待機状態になります。
たとえば、表に対して100万件の挿入、更新および削除を行うPL/SQLプロシージャがあるとします。DBMSの負荷によっては、そのようなPL/SQLプロシージャが完了するまでに20分から2時間かかることがあります。PLSQL同時実行性制限を25に設定した、wa1という名前の作業割当てが作成されたとします。多数のPL/SQLジョブがあり、各ジョブがこのPL/SQLプロシージャを実行するとします。
この場合、Oracle Enterprise Schedulerサーバーは一度に25個のPL/SQLジョブしか実行しません。各PL/SQLジョブが完了するのに1から2時間かかるため、残りのPL/SQLジョブはWAIT状態になります。RUNNINGジョブの完了後、WAITキューの先頭のジョブが選択され実行がスケジュールされます。
問題の解決にMy Oracle Support (以前のMetaLink)を使用できます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。
ナレッジ・ベース記事
コミュニティ・フォーラムとディスカッション
パッチとアップグレード
動作保証情報
My Oracle Supportにはhttps://support.oracle.comからアクセスできます。
