C'est l'une des questions les plus fréquemment posées par le planificateur. Nous énumérons ici certains des problèmes courants et leurs solutions.
1) job_queue_processes peut être trop faible (c'est le problème le plus courant) La valeur de job_queue_processes limite le nombre total de travaux dbms_scheduler et dbms_job pouvant être exécutés à un moment donné. Pour vérifier si c'est le cas, vérifiez la valeur actuelle de job_queue_processes avec SQL> select value from v$parameter where name='job_queue_processes';Puis vérifier le nombre de jobs en cours d'exécutionSQL> select count() from dba_scheduler_running_jobs;SQL> select count( ) de dba_jobs_running ;
Si tel est le problème, vous pouvez augmenter le paramètre en utilisant SQL> alter system set job_queue_processes=1000 ;
2) max_job_slave_processes peut être trop faible Si ce paramètre n'est pas NULL, il limite le nombre de tâches dbms_scheduler pouvant être exécutées à la fois. Pour vérifier s'il s'agit du problème, vérifiez la valeur actuelle à l'aide de SQL> sélectionnez la valeur de dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES' ; Vérifiez ensuite le nombre de tâches en cours d'exécution SQL> sélectionnez count(*) de dba_scheduler_running_jobs ;
Si tel est le problème, vous pouvez augmenter le nombre ou simplement le désactiver en utilisant SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) les sessions peuvent être trop faiblesCe paramètre limite le nombre de sessions à tout moment. Chaque tâche du planificateur nécessite 2 sessions. Pour vérifier s'il s'agit du problème, vérifiez la valeur actuelle à l'aide de SQL> sélectionnez la valeur de v$paramètre où nom='sessions' ; Vérifiez ensuite le nombre actuel de sessions à l'aide de SQL> sélectionnez le nombre (*) de v$session ;
Si les nombres sont trop proches, vous pouvez augmenter le maximum en utilisantSQL> alter system set job_queue_processes=200;
4) Avez-vous récemment appliqué un correctif de mise à jour de fuseau horaire ou mis à niveau la base de données vers une version avec des informations de fuseau horaire plus récentes ? Si vous avez sauté des étapes lors de la mise à jour des informations de fuseau horaire, les tâches risquent de ne pas s'exécuter. Pour vérifier si c'est le cas, essayez de faireSQL> sélectionnez * à partir de sys.scheduler$_job;etSQL> sélectionnez * à partir de sys.scheduler$_window;et assurez-vous qu'ils se terminent sans erreur.
S'il émet un avertissement de fuseau horaire, réappliquez la mise à niveau ou le correctif de fuseau horaire en vous assurant de suivre toutes les étapes.
5) La base de données fonctionne-t-elle en mode restreint ? Si la base de données fonctionne en mode restreint, aucune tâche ne sera exécutée (sauf si vous utilisez 11g et utilisez l'attribut ALLOW_RUNS_IN_RESTRICTED_MODE). Pour vérifier cela, utilisez SQL> sélectionnez les connexions à partir de v$instance ;
Si les connexions sont restreintes, vous pouvez désactiver le mode restreint en utilisantSQL> ALTER SYSTEM DISABLE RESTRICTED SESSION ;
6) La tâche est-elle planifiée pour s'exécuter sur une instance en panne ?
Vous pouvez vérifier cela en vérifiant si instance_id est défini pour le travail (vérifiez la vue dba_scheduler_jobs), et si c'est le cas, vous devriez vérifier si cette instance est active.
7) La tâche est-elle planifiée pour s'exécuter sur un service qui n'a été démarré sur aucune instance ?
Vous pouvez vérifier cela en vérifiant vers quelle classe de travail pointe une tâche, puis en vérifiant si cette classe pointe vers un service. Si c'est le cas, assurez-vous que le service a été démarré sur au moins une instance en cours d'exécution. Vous pouvez démarrer un service sur une instance à l'aide de dbms_service.start_service.
8) Le Resource Manager est-il en vigueur avec un plan de ressources restrictif ?
Si un plan de ressources restrictif est en vigueur, les tâches du planificateur peuvent ne pas disposer de suffisamment de ressources allouées pour ne pas s'exécuter. Vous pouvez vérifier quel plan de ressources est en vigueur en faisant
SQL> sélectionnez le nom de V$RSRC_PLAN;
Si aucun plan n'est en vigueur ou si le plan en vigueur est INTERNAL_PLAN, le gestionnaire de ressources n'est pas en vigueur. Si le gestionnaire de ressources est en vigueur, vous pouvez le désactiver en faisant
SQL>Alter system set resource_manager_plan ='';
9) Le planificateur a-t-il été désactivé ? Ce n'est pas une action prise en charge, mais il est possible que quelqu'un l'ait fait quand même. Pour vérifier ce doSQL> sélectionnez la valeur de dba_scheduler_global_attribute où attribute_name='SCHEDULER_DISABLED'
Si cette requête renvoie TRUE, vous pouvez résoudre ce problème en utilisant SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Raisons pour lesquelles les tâches peuvent être exécutées en retard
1) La première chose à vérifier est le fuseau horaire avec lequel le travail est planifié avec SQL> sélectionnez propriétaire, nom_travail, date_suivante depuis dba_scheduler_jobs ;
Si les travaux sont dans le mauvais fuseau horaire, ils peuvent ne pas s'exécuter à l'heure prévue. Si la next_run_date utilise un décalage de fuseau horaire absolu (comme +08:00) au lieu d'un fuseau horaire nommé (comme US/PACIFIC), les travaux peuvent ne pas s'exécuter comme prévu si l'heure d'été est en vigueur - ils peuvent s'exécuter une heure plus tôt ou plus tard.
2) Il se peut qu'au moment où l'exécution du travail a été planifiée, l'une des plusieurs limites ci-dessus ait été temporairement atteinte, ce qui a retardé le travail. Vérifiez si les limites ci-dessus sont suffisamment élevées et, si possible, vérifiez-les pendant le temps que le travail le travail est retardé.
3) Une des raisons possibles pour lesquelles l'une des limites ci-dessus peut être atteinte est qu'une fenêtre de maintenance est peut-être entrée en vigueur. Les fenêtres de maintenance sont des fenêtres OracleScheduler qui appartiennent au groupe de fenêtres nommé MAINTENANCE_WINDOW_GROUP. Au cours d'une fenêtre de maintenance planifiée, plusieurs tâches de maintenance sont exécutées à l'aide de travaux. Cela peut entraîner l'atteinte de l'une des limites répertoriées ci-dessus et retarder les travaux de l'utilisateur. Consultez le guide de l'administrateur pour plus d'informations à ce sujet (chapitre 24).
Pour obtenir une liste des fenêtres de maintenance, utilisez SQL> sélectionnez * à partir de dba_scheduler_wingroup_members ;
Pour voir quand les fenêtres s'exécutent, useSQL> sélectionnez * dans dba_scheduler_windows ;
Pour résoudre ce problème, vous pouvez soit augmenter les limites, soit reprogrammer les fenêtres de maintenance pour qu'elles s'exécutent à des moments plus pratiques.
Diagnostiquer d'autres problèmes
Si rien de tout cela ne fonctionne, voici quelques étapes supplémentaires que vous pouvez suivre pour essayer de comprendre ce qui se passe.
1) Vérifiez s'il y a des erreurs dans le journal des alertes. Si la base de données rencontre des difficultés pour allouer de la mémoire ou manque d'espace disque ou si d'autres erreurs catastrophiques se sont produites, vous devez d'abord les résoudre. Vous pouvez trouver l'emplacement du journal des alertes en utilisant SQL> sélectionnez la valeur de v$parameter où name ='background_dump_dest' ; Le journal des alertes sera dans ce répertoire avec un nom commençant par "alert".
2) Vérifiez s'il existe un fichier de trace du coordinateur de travaux et, si c'est le cas, vérifiez s'il contient des erreurs. Si cela existe, il sera situé dans le répertoire 'background_dump_dest' que vous pouvez trouver comme ci-dessus et ressemblera à SID-cjq0_nnnn.trc . S'il y a des erreurs ici, elles peuvent indiquer pourquoi les tâches ne sont pas en cours d'exécution.
3) Si l'un des éléments ci-dessus indique que l'espace de table SYSAUX (où le planificateur stocke ses tables de journalisation) est plein, vous pouvez utiliser la procédure dbms_scheduler.purge_log pour effacer les anciennes entrées de journal.
4) Voir s'il y a une fenêtre actuellement ouverte. Si c'est le cas, vous pouvez essayer de le fermer pour voir si cela vous aide .
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5) essayez d'exécuter une simple tâche à exécuter une seule fois et voyez si elle s'exécute
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) Si une simple tâche à exécution unique ne s'exécute pas, vous pouvez essayer de redémarrer le planificateur comme suit.
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');
