sql >> データベース >  >> RDS >> Oracle

OracleDBMSジョブが実行されていません

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

    1）job_queue_processesが低すぎる可能性があります（これが最も一般的な問題です）job_queue_processesの値は、特定の時間に実行できるdbms_schedulerand dbms_jobジョブの総数を制限します。これが当てはまるかどうかを確認するには、SQLでjob_queue_processesの現在の値を確認してください> v $parameterから値を選択します。ここでname='job_queue_processes';次に、実行中のジョブの数を確認しますSQL> dba_scheduler_running_jobsからcount（）を選択します; SQL> count（を選択します ）dba_jobs_runningから;

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

    2）max_job_slave_processesが低すぎる可能性がありますこのパラメーターがNULLでない場合、一度に実行できるdbms_schedulerジョブの数が制限されます。これが問題であるかどうかを確認するには、SQLを使用して現在の値を確認します> dba_scheduler_global_attributewhere 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つのセッションが必要です。これが問題であるかどうかを確認するには、SQLを使用してcurrentvaluleを確認します> v $parameterから値を選択します。ここでname='sessions';次に、SQLを使用して現在のセッション数を確認します> v $ sessionからcount（*）を選択します;

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

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

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

    5）データベースは制限付きモードで実行されていますか？データベースが制限付きモードで実行されている場合、ジョブは実行されません（11gを使用してALLOW_RUNS_IN_RESTRICTED_MODE属性を使用している場合を除く）。このuseSQLを確認するには、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）スケジューラは無効になっていますか？これはサポートされているアクションではありませんが、とにかく誰かがそれを行った可能性があります。このdoSQLを確認するには>dba_scheduler_global_attributeから値を選択します。ここでattribute_name='SCHEDULER_DISABLED'

    このクエリがTRUEを返す場合は、SQL> exec dbms_scheduler.set_scheduler_attribute（'scheduler_disabled'、'false'）;

    を使用してこれを修正できます。

    ジョブが遅れる理由

    1）最初に確認するのは、ジョブがSQLでスケジュールされているタイムゾーンです> select owner、job_name、next_run_date from dba_scheduler_jobs;

    ジョブが間違ったタイムゾーンにある場合、期待された時間に実行されない可能性があります。 next_run_dateが名前付きタイムゾーン（US / PACIFICなど）の代わりに絶対タイムゾーンオフセット（+08：00など）を使用している場合、夏時間が有効になっていると、ジョブが期待どおりに実行されない可能性があります。 / P>

    2）ジョブの実行がスケジュールされたときに、上記のいくつかの制限のいずれかに一時的に達してジョブが遅延した可能性があります。上記の制限が十分に高いかどうかを確認し、可能であれば、仕事が遅れています。

    3）上記の制限のいずれかに該当する可能性がある理由の1つは、メンテナンスウィンドウが有効になっている可能性があることです。メンテナンスウィンドウは、MAINTENANCE_WINDOW_GROUPという名前のウィンドウグループに属するOracleSchedulerウィンドウです。スケジュールされたメンテナンスウィンドウ中に、ジョブを使用していくつかのメンテナンスタスクが実行されます。これにより、上記の制限の1つに達し、ユーザージョブが遅延する可能性があります。詳細については、管理ガイドを参照してください（第24章）。

    メンテナンスウィンドウのリストを取得するには、SQLを使用します> select * from dba_scheduler_wingroup_members;

    ウィンドウがいつ実行されるかを確認するには、useSQL> select * from dba_scheduler_windows;

    これを修正するには、制限を増やすか、メンテナンスウィンドウを再スケジュールして、より都合の良い時間に実行することができます。

    他の問題の診断

    これがうまくいかない場合は、何が起こっているのかを理解するために実行できるいくつかの追加の手順があります。

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

    2）ジョブコーディネーターのトレースファイルがあるかどうかを確認し、ある場合はエラーが含まれていないかどうかを確認します。これが存在する場合は、上記のように見つけることができる「background_dump_dest」ディレクトリに配置され、SID-cjq0_nnnn.trcのようになります。ここにエラーがある場合は、ジョブが実行されていない理由を示唆している可能性があります。

    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）単純な1回限りのジョブを実行して、実行されるかどうかを確認します

    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）単純な1回限りのジョブが実行されない場合は、次のようにスケジューラを再起動してみてください。

    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');


    1. AWSRDSのMysqldump

    2. このmysql結合クエリを取得して目的の結果を生成できません

    3. MySQL UDF sys_exec（）が機能しない

    4. 注意：phpでの配列から文字列への変換