2017-10-08 84 views
-3

5分ごとに火曜日から日曜日に実行するジョブを定義しました。午前9時から22:00までOracle DBMSジョブが実行されていない

BEGIN 
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'GET_INVOICES_JOB', 
job_type => 'PLSQL_BLOCK', 
job_action => 'BEGIN LOPES.GET_INVOICES; END;', 
repeat_interval =>'FREQ=MINUTELY; INTERVAL=5; BYHOUR=9,22; BYDAY=TUE,WED,THU,FRI,SAT,SUN', 
enabled => TRUE, 
comments => 'GET_INVOICES'); 
END; 
/

しかし仕事は、OKのようです仕事をチェック

SELECT * 
FROM USER_SCHEDULER_JOB_RUN_DETAILS 
ORDER BY LOG_DATE DESC 

をcheking実行されません:

enter image description here

とジョブを手動で実行すると、手順が実行されますが、5分ごとに1回だけ実行されます。

答えて

1

これは最も一般的なスケジューラの質問の1つです。 ここでは、一般的な問題とその解決策のいくつかを挙げます。 JOB_QUEUE_PROCESSESの

1)JOB_QUEUE_PROCESSESが低すぎてもよい(これは最も一般的な問題である) 値は、所与の時間に実行することができるDBMS_SCHEDULER とDBMS_JOBジョブの総数を制限します。 これが正しいかどうかを確認するには、 のjob_queue_processesの現在の値を確認します。 を使用してSQLを選択します。v $ parameter where name = 'job_queue_processes'; 次に、実行中のジョブの数を確認してください。 SQL> select count()from dba_scheduler_running_jobs; SQL> select count()from dba_jobs_running;

これが問題の場合は、 を使用してパラメータを増やすことができます。SQL> alter system set job_queue_processes = 1000;

2)max_job_slave_processesが低すぎる可能性があります このパラメータがNULLでなければ、一度に実行できるdbms_schedulerジョブの数を制限します。これが問題かどうかを確認するには、 の値を で調べてください。SQL> dba_scheduler_global_attributeから値を選択してください。 where attribute_name = 'MAX_JOB_SLAVE_PROCESSES'; 次に、実行中のジョブの数を確認してください。 SQL> dba_scheduler_running_jobsからcount(*)を選択してください。

これはあなたが SQL> execのDBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE(「max_job_slave_processes」、null)を使用してそれを数を増やすか、単にNULLという問題である場合

3)は、セッションはこのパラメータは、制限 低すぎる可能性がいつでもセッションの数。すべてのスケジューラジョブ には2つのセッションが必要です。これが問題かどうかを確認するには、 を使用して現在の valuleを確認します。SQL> v $ parameter where name = 'sessions'; 次に、 を使用して現在のセッション数を確認します。SQL> v $ sessionからcount(*)を選択します。

数値が近すぎる場合は、 を使用して最大値を大きくすることができます。SQL> alter system set job_queue_processes = 200;

4)最近、タイムゾーン更新パッチを適用したか、データベース を新しいタイムゾーン情報のバージョンにアップグレードしましたか?タイムゾーン情報を更新するときにステップをスキップした場合、ジョブは実行されません。これが かどうかを確認するには SQL> select * from sys.scheduler $ _job; および SQL> select * from sys.scheduler $ _window; 、エラーなしで終了してください。

タイムゾーンの警告が表示された場合は、アップグレードまたはすべての手順を実行していることを確認して タイムゾーンパッチを再適用してください。

5)データベースは制限モードで動作していますか? データベースが制限モードで実行されている場合、ジョブは実行されません( 11gを使用し、ALLOW_RUNS_IN_RESTRICTED_MODE属性を使用しない場合)。 この使用をチェックするには SQL> v $ instanceからログインを選択してください。

ログインが制限されている場合は、 を使用して制限モードを無効にすることができます。SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

6)ジョブが停止しているインスタンスで実行する予定ですか?

instance_idがジョブに設定されているかどうかを確認することで確認できます(dba_scheduler_jobsビューを確認してください)。そうであれば、そのインスタンスが稼動しているかどうかを確認する必要があります。

7)ジョブは、どのインスタンスでも開始されていないサービスで実行する予定ですか?

これは、ジョブが指すjob_classを確認し、そのクラスがサービスを指しているかどうかを確認することで確認できます。存在する場合は、少なくとも1つの実行中のインスタンスでサービスが開始されていることを確認してください。 dbms_service.start_serviceを使用して、インスタンス上でサービスを開始できます。

8)リソースマネージャは制限付きリソースプランで有効ですか?

制限付きリソース・プランが有効な場合、スケジューラー・ジョブに十分なリソースが割り当てられていない可能性があります。

SQL> V $ RSRC_PLANの名前を選択してください。

プランが有効でない場合、または有効なプランがINTERNAL_PLANの場合、リソースマネージャは有効ではありません。リソースマネージャが有効になっている場合、これを無効にすることができます。

SQL> alter system set resource_manager_plan = '';

9)スケジューラは無効になっていますか?これはサポートされているアクションではありませんが、とにかく誰かがそれを行った可能性があります。確認するには、これは、このクエリがTRUEを返した場合、あなたは SQL> execがDBMS_SCHEDULERを使用してこの問題を解決することができdba_scheduler_global_attributeどこATTRIBUTE_NAME =「SCHEDULER_DISABLED」

から SQL>選択値を行います。set_scheduler_attribute( 'scheduler_disabled'、 'false');ジョブを実行する理由

理由後半

1)最初に確認することが仕事が SQL>を選択し、所有者、job_nameを、DBA_SCHEDULER_JOBSかられるnext_run_dateで予定されているタイムゾーンです。ジョブが間違ったタイムゾーンにある場合

彼らが期待 時間に実行されないことがあります。 next_run_dateが、指定されたタイムゾーン(US/PACIFICなど)ではなく、絶対タイムゾーンオフセット( +08:00など)を使用している場合、夏時間が有効な場合は 早いか遅い。

2)ジョブの実行がスケジュールされた時点で、上記の制限数1つの のうちの1つが一時的に到達してジョブが遅れることがあります。 上記の制限が十分に高いかどうかを確認し、可能であれば、 の間にジョブが遅れている時間を確認してください。上記の制限のいずれかがヒットしてもよいこと

3)一つの可能​​な理由は、 メンテナンスウィンドウが有効になってきたことです。メンテナンス・ウィンドウは、 という名前のウィンドウ・グループに属するスケジューラ・ウィンドウです。 MAINTENANCE_WINDOW_GROUPです。スケジュールされたメンテナンスウィンドウでは、いくつかの メンテナンスタスクがジョブを使用して実行されます。これにより、上にリストされた制限のうちの1つがヒットし、ユーザージョブが遅れることがあります。このことについての詳細は、管理者ガイド を参照してください(第24章)。

メンテナンス期間のリストを取得するには SQL> select * from dba_scheduler_wingroup_members;窓は SQLの使用を実行したときに表示するには

> DBA_SCHEDULER_WINDOWSから*を選択。あなたが制限を増やすか、より便利な時間に実行するために、メンテナンスに ウィンドウのスケジュールを変更するか、この問題を解決するには

。これのどれもが、ここであなたは何が起こっているか 図を試すために取ることができるいくつかのさらなるステップがあるうまくいかない場合は、他の問題

診断

1)アラートログにエラーがないか確認してください。データベースが でメモリの割り当てに問題がある場合、またはディスク領域がなくなった場合、またはその他の致命的なエラーが発生した場合は、最初に解決する必要があります。 を使用して、警告ログの場所を確認することができます。SQL> v $ parameter where name = 'background_dump_dest'; アラートログは、このディレクトリに「alert」で始まる名前が付けられます。

2)かどうかあればジョブ・コーディネータのトレースファイルをチェックし、それがない場合は、それ にエラーが含まれている場合は、確認してください。これが存在する場合、それはあなたが上記のように見つけることができるとSID-cjq0_nnnn.trcよう になります 「BACKGROUND_DUMP_DEST」ディレクトリに配置されます。ここにエラーがある場合は、 ジョブが実行されていない理由をヒントできます。

3)上記のいずれかがSYSAUX表領域(スケジューラがロギング表を格納する)がいっぱいであることを示している場合は、dbms_scheduler.purge_logプロシージャを使用して古いログ・エントリを消去できます。

4)現在開いているウィンドウがあるかどうかを確認してください。もしあれば、それを閉じてそれが役立つかどうかを調べることができます。

SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where 
attribute_name='CURRENT_OPEN_WINDOW'; 
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW'); 

5)それは、単純な実行一回のジョブが実行されない場合は、スケジューラなどを再起動してみてくださいすることができます)

SQL>begin 
dbms_scheduler.create_job (
job_name => 'test_job', 
job_type => 'plsql_block', 
job_action => 'null;', 
enabled => true); 
end; 
/
SQL> -- wait a while 
SQL> select * from user_scheduler_job_run_details where job_name='TEST_JOB'; 

6を実行する場合、単純な実行一度ジョブを実行しようとすると、参照続く。

SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'TRUE'); 
SQL> alter system set job_queue_processes=0; 
SQL> exec dbms_ijob.set_enabled(FALSE); 
SQL> 
SQL> alter system flush shared_pool; 
SQL> alter system flush shared_pool; 
SQL> 
SQL> exec dbms_ijob.set_enabled(TRUE); 
SQL> alter system set job_queue_processes=99; 
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE'); 
関連する問題