Oracle Database Enterprise Edition - Problèmes et bogues connus liés à l'utilisation du Scheduler
Oracle Database - Enterprise Edition - Version 9.0.1.0 à 11.2.0.3
Cela correspond aux releases 9.0.1 à 11.2.
Les informations de ce document s'appliquent à toutes les plateformes.
OBJECTIF
Ce document vise à vous aider à résoudre les problèmes liés à l'utilisation du système Oracle Scheduler.
Le Scheduler Oracle permet de mettre en place un environnement très souple et propre à chaque application, ce qui rend difficile l'analyse d'un comportement inattendu.
Il est donc important de décomposer le problème selon ses différents aspects pour une analyse détaillée, afin de trouver finalement la cause du comportement inattendu.
Il existe de nombreuses notes sur les problèmes du système Scheduler, mais il n'est pas toujours facile de trouver une solution immédiate. Ce guide rassemble des trucs et astuces, les notes pertinentes ainsi que les bogues et problèmes connus liés à l'utilisation du Scheduler, et propose les premières étapes d'analyse, avec les notes à consulter selon la version de la base de données et le composant du Scheduler concerné.
REMARQUE :
Vos commentaires et suggestions sont les bienvenus. Cette note sera régulièrement revue et mise à jour avec de nouvelles astuces, notes, bogues et informations complémentaires, afin de rester à jour.
ÉTAPES DE DÉPANNAGE
--- Symptômes ---
1. Problèmes généraux de configuration des jobs du Scheduler et de définition des jobs
Selon la complexité du système de planification que vous souhaitez mettre en place, il peut parfois être difficile de configurer le Scheduler comme prévu. Dès qu'un comportement inattendu ou des erreurs apparaissent, il est souvent utile de revenir en arrière, étape par étape, et d'essayer un code de test simplifié.
Suggestions :
Vérifiez les erreurs éventuelles renvoyées lors de l'exécution des procédures du package DBMS_SCHEDULER.
Utilisez un code de test simplifié pour créer un job Scheduler simple et vérifiez si le problème se reproduit.
Vous trouverez de l'aide pour écrire du code d'exemple dans les notes suivantes :
Note 807159.1 - Sample Code and Select Statements to build Simple Testcases for Scheduler / Jobs
Note 727499.1 - Sample how to create a job running chains
Note 1431664.1 - How to build up an event based job - an example
Note 1300444.1 - How to Create a Event Based Chained Job
Note 470764.1 - How to Control Resources used by a Statistics Job using the Resource Manager
Note 1300313.1 - How to use an own Maintenance Window for the Statistics Collection in 11g
Note 1074141.1 - How to install and setup the Scheduler Agent (schagent) so can run Remote External Jobs
2. Le job planifié ne s'exécute pas automatiquement ni avec run_job
Dans certaines circonstances, il peut arriver que certains jobs ne s'exécutent plus à l'heure prévue ;
Les définitions des jobs n'ont pas été modifiées.
Aucun attribut du Scheduler n'a été modifié.
Notes et bogues connus :
Bug 9197805 - Infrequent delay in execution DBMS_SCHEDULER or DBMS_JOB jobs (Doc ID 9197805.8)
==> corrigé dans 12.1.0.1, 11.2.0.2
Suggestions :
Vérifiez la présence du processus CJQ et des éventuels processus esclaves de jobs au niveau du système d'exploitation.
Vérifiez si des correctifs ont été installés récemment sur la base de données.
Oracle version 11.2 :
L'utilisation du paramètre job_queue_processes a changé.
Alors que dans les versions antérieures (<11.2) il n'existait pas de méthode réellement prise en charge pour arrêter le processus cjq et ses esclaves de jobs, il est désormais possible, à partir de la 11.2, d'arrêter ces processus en définissant job_queue_processes = 0.
La valeur actuelle de job_queue_processes peut donc empêcher l'exécution automatique des jobs.
Si un job ne s'exécute pas automatiquement en version 11.2, vérifiez la valeur actuelle de ce paramètre avec :
SQL> show parameter job_queue_processeset assurez-vous que cette valeur est supérieure à zéro.
Oracle version <= 11.2 :
Vérifiez si le processus CJQ a été désactivé d'une manière ou d'une autre avec :
SQL> select * from dba_scheduler_global_attribute;==> vérifiez la valeur des attributs suivants
MAX_JOB_SLAVE_PROCESSES : nul par défaut, mais s'il est défini, vérifiez que sa valeur est suffisante
SCHEDULER_DISABLED : souvent utilisé dans les versions < 11.2 pour arrêter le cjq.
Comme mentionné, dans Oracle version 11.2, c'est le paramètre job_queue_processes qui a été modifié pour permettre cela.
CURRENT_OPEN_WINDOW : vérifiez si une fenêtre est ouverte et qu'il s'agit de la bonne selon l'heure actuelle
Vérifiez les colonnes ADDITIONAL_INFO et ERROR# de la vue DBA_SCHEDULER_JOB_RUN_DETAILS
Il se peut que le job ait démarré puis échoué. Ces colonnes donneront une indication sur la cause de l'échec.
Vérifiez l'alert.log ainsi que les fichiers de trace des esclaves de jobs et du cjq.
Examinez l'alert.log à la recherche de messages et analysez les erreurs éventuelles affichées dans les fichiers de trace.
Vérifiez si une exécution manuelle du job avec dbms_scheduler.run_job se déroule sans problème.
En cas d'échec, vérifiez sur quel type de job (JOB_TYPE) repose le job.
Pour les jobs que vous n'avez pas créés, consultez la vue DBA_SCHEDULER_JOBS et la valeur des colonnes JOB_TYPE et JOB_ACTION, par exemple :
PLSQL_BLOCK :
Exécutez ce bloc avec sqlplus et vérifiez s'il produit une erreur.
STORED_PROCEDURE :
Exécutez la procédure directement dans sqlplus et vérifiez qu'elle s'exécute sans problème.
CHAIN :
Pour les chaînes, il est important de savoir qu'elles sont constituées d'étapes qui exécutent des programmes précis.
Reportez-vous à la section sur les chaînes.
EXTERNAL :
De nombreuses raisons peuvent empêcher l'exécution des jobs externes.
Reportez-vous à la section sur les jobs externes.
Vérifiez si une valeur autre que celle par défaut est utilisée pour l'attribut job_weight du Scheduler :
Sur un système chargé dont le nombre de processus esclaves de jobs est limité, job_weight donne la priorité à l'exécution des jobs de priorité élevée.
Voir Note 1310649.1 - Scheduler Jobs Refuse To Restart At The Scheduled Time
Le problème survient-il après un changement d'heure du système d'exploitation (heure d'hiver <=> heure d'été) ?
Dans ce cas, il peut s'agir d'un problème lié à l'heure d'été (DST). Reportez-vous à la section sur les problèmes de DST.
La base de données a-t-elle été clonée ?
Vérifiez que les services sont valides
Note 1267379.1 - Oracle Scheduler doesn't execute any job in a cloned database
Le job ne s'exécute-t-il plus automatiquement après une mise à niveau de la base de données ?
Dans ce cas, le problème peut venir des fenêtres du Scheduler dans lesquelles les jobs peuvent être planifiés.
Note 731678.1 - Scheduled jobs do not run as expected after 10.2 upgrades
Les statistiques ne sont pas collectées :
Vérifiez que la bonne fenêtre est ouverte :
Note 1320246.1 Why Auto Optimizer Statistics Collection May Appear to be "Stuck"?
3. Le job planifié ne s'exécute pas automatiquement, mais une exécution manuelle réussit
Suggestions :
Base de données en mode restreint : vérifiez si la base de données est en mode restreint. Si c'est le cas, exécutez ALTER SYSTEM DISABLE RESTRICTED SESSION;
Vérifiez ensuite si les jobs sont pris en charge automatiquement.
Vérifiez l'alert.log, les fichiers de trace des esclaves de jobs et le fichier de trace cjq.. à la recherche d'erreurs.
Vérifiez au niveau du système d'exploitation la présence du CJQ et des esclaves de jobs
Consultez les vues de journal du Scheduler (en particulier les colonnes additional_info, next_run_date et last_run_date)
Lorsque next_run_date est dans le passé, essayez :
alter system set events '27402 trace name context forever, level 65535';';
execute DBMS_SCHEDULER.run_job (job_name => 'Test_Manual_Job', use_current_session => FALSE);
exec dbms_lock.sleep(300);
alter system set events '27402 trace name context off';
==> transmettez les fichiers de trace générés au support Oracle
Vérifiez la charge du système. Des ressources sont-elles disponibles pour exécuter les jobs ? Un rapport AWR ou un dump systemstate peut vous aider.
Version 11.2.0.3 :
Vérifiez si l'événement 10195 est défini. S'il a une valeur non nulle, le Bug 13062518 peut être en cause :
Notes et bogues connus :
Note 461304.1 How to activate tracing for the scheduler
Bug 13062518: DBMS_JOB IS NOT PICKED UP AUTOMATICALLY WHEN SUBMIT FROM APPLICATION
==> Bug de base 10103086, corrigé dans 12.1.0.1, 11.2.0.3
Bug 13324090 - CJQ PROCESS CONSUMING HIGH CPU
Suspendu, informations requises non disponibles
Bug 13906790 - SYS$SERVICE_METRICS IS GROWING ON 2NODE RAC
Suspendu, informations requises non disponibles
Bug 14015067: MESSAGES ON SYS$SERVICE_METRICS ARE INCREASING CAUSING DELAY ON DBMS_SCHEDULER
doublon du Bug 13855490 - CJQ CONSUME PGA MEMORY IN RAC 11.2
==> corrigé dans 12.1.0.1, 11.2.0.4, 11.2.0.3.7 PSU
4. Les jobs bloqués ne peuvent être ni arrêtés ni supprimés
La suppression avec l'option force produit une erreur comme :
ORA-27475: "username.jobname" must be a job
ou
ORA-27478: job "username.jobname" is active
Même un redémarrage de la base de données n'empêche parfois pas le job de redémarrer.
DBA_SCHEDULER_RUNNING_JOBS affiche une entrée pour le job.
Causes possibles :
* stop_job ne fonctionne que sur les exécutions de jobs en arrière-plan, et non sur les exécutions au premier plan
lancées avec run_job(use_current_session=>true). L'exécution run_job au premier plan
se poursuit donc sans être affectée par stop_job.
* Le processus esclave de ce job a peut-être été tué, par exemple par un kill brutal au niveau du système d'exploitation.
Le job reste alors à l'état d'exécution, alors qu'aucun processus esclave n'est disponible.
Plusieurs bogues sont répertoriés pour cette situation.
Vérifiez les points suivants :
1. Vérifiez l'attribut restartable du job et définissez-le à no
2. Effectuez les étapes suivantes dans cet ordre :
- Désactivez le job avec force=>true
- Arrêtez le job avec force=>true
- Supprimez le job avec force=>true
3. En dernier recours (cela affectera la base de données et/ou d'autres jobs) :
3a. Redémarrez la base de données si possible ou
3b. Désactivez le processus cjq et ses processus avec :
pour la version 11.2 et suivantes :
- définissez job_queue_processes = 0
- attendez et vérifiez au niveau du système d'exploitation que les processus sont terminés
- désactivez/supprimez le job
pour les versions < 11.2 :
- définissez job_queue_processes = 0
- désactivez le processus cjq avec
exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','true');
- attendez et vérifiez au niveau du système d'exploitation que les processus sont terminés
- désactivez/supprimez le job
- réactivez le cjq avec
exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
et redonnez à job_queue_processes sa valeur d'origine
4. Recueillez les informations suivantes pour le job bloqué à l'état d'exécution et doté d'un SID (connectez-vous au thread/à l'instance concerné) :
select pid from v$process, v$session where addr=paddr and sid=&sid;
oradebug setorapid &pid
oradebug event immediate trace name errorstack level 3;
oradebug event 10046 trace name context forever, level 12;
exec dbms_lock.sleep(300);
oradebug event 10046 trace name context off;
oradebug tracefile_name
==> transmettez ces fichiers de trace au support Oracle
Notes et bogues connus :
Note 1290836.1 - Can't Delete Scheduled Job : ORA-27475 or ORA-27478
Bug 7606518 - ORA-23766 HIT AT STOP_JOB / ORA-27478 HIT AT DROP_JOB
=> Corrigé dans 11.2.0.1
Bug non publié 7258928 - SCHEDULER JOBS THAT ARE HANGING, CANNOT BE STOPPED
=> Corrigé dans 11.2.0.1, 11.1.0.7.2 PSU
Bug non publié 10363801 - JOB RECOVERY AFTER DATABASE BOUNCE FAILS
==> corrigé dans 12.1.0.1 ,11.2.0.3
Bug 11696169- SCHEDULER JOB CANNOT BE STOPPED / DROPPED ON EXADATA MACHINE
==> corrigé dans 12.1.0.1 ,11.2.0.3
5. Problèmes de DST : les jobs planifiés ne s'exécutent plus après un changement d'heure
Dans certains cas, un changement d'heure lié à l'heure d'été (DST) empêche les jobs de s'exécuter automatiquement.
La cause est principalement une mauvaise configuration des fuseaux horaires, qui ne tiennent pas compte de l'heure d'été.
Le SCHEDULER peut utiliser deux fuseaux horaires différents :
a. le fuseau horaire de la SESSION qui crée le JOB PLANIFIÉ
b. le TZ lu par le BINAIRE ORACLE à son DÉMARRAGE (il peut différer pour le client, la base de données, le listener, l'agent EM, etc., car chacun peut avoir ses propres paramètres d'environnement, qui ne correspondent pas forcément aux autres.)
Une première analyse peut être faite ainsi :
Vérifiez la start_date du job qui ne s'exécute pas, son rapport avec l'heure d'été, ainsi que la configuration actuelle des fuseaux horaires
Vérifiez la sortie suivante pour les paramètres de fuseau horaire :
-- start a sqlplus session
connect / as sysdba
spool DSToutput.txt
alter session set NLS_TIMESTAMP_TZ_FORMAT ='DD/MM/YYYY HH24:MI:SS TZR TZD';
select dbms_scheduler.stime from dual;
select sessiontimezone from dual;
select DBMS_SCHEDULER.GET_SYS_TIME_ZONE_NAME from DUAL;
select name, value$ from props$ where name = 'DBTIMEZONE';
select distinct tzname from v$timezone_names;
! echo $TZ -- for unix systems
-- check of runtimes of job:
set pagesize 9999
set markup html on
spool dba_scheduler_job_log.html
select * from dba_scheduler_job_log where log_date > systimestamp -3 and job_name=upper('&name_of_job') order by log_date desc;
spool off
set markup html off
-- ==> upload dba_scheduler_job_log.html
set pagesize 9999
set markup html on
spool dba_scheduler_job_run_details.html
select * from dba_scheduler_job_run_details where log_date > systimestamp -3 and job_name=upper('&name_of_job') order by log_date desc;
spool off
set markup html off
-- ==> upload dba_scheduler_job_run_details.html
set pagesize 9999
set markup html on
spool dba_scheduler_jobs.html
select * from dba_scheduler_jobs where
job_name=upper('&name_of_job') order by start_date desc;
spool off
set markup html off
-- ==> upload dba_scheduler_jobs.html
set pagesize 9999
set markup html on
spool dba_scheduler_running_job.html
select * from DBA_SCHEDULER_RUNNING_JOBS;
select * from dba_scheduler_global_attribute;
spool off
set markup html off
-- ==> upload dba_scheduler_running_job.html
REMARQUE :
Sur les plateformes Windows :
Assurez-vous que le fuseau horaire de l'horloge est correct. Ouvrez le "Control Panel" et choisissez "Date and Time Properties". Cliquez ensuite sur "Time Zone". Si le fuseau horaire indiqué comporte une période d'heure d'été, la case "Automatically adjust clock for daylight savings changes" doit être cochée. Assurez-vous que l'horloge indique l'heure exacte pour le fuseau horaire indiqué.
Quel fuseau horaire a été utilisé lors de la création du job ?
La session qui a CRÉÉ le JOB a-t-elle été modifiée, par exemple pour utiliser le bon fuseau horaire ?
Par exemple :
ALTER SESSION SET TIME_ZONE = 'Europe/London';
Sachez que le fuseau horaire de la session utilisée lors de la création du JOB détermine les règles du JOB. Il peut donc être nécessaire de définir d'abord time_zone à la valeur attendue, puis de recréer l'objet ou le job du Scheduler. Vous pouvez aussi définir explicitement le fuseau horaire avec la procédure set_attribute.
Pour plus d'informations, consultez :
Note 340512.1 - Timestamps & time zones - Frequently Asked Questions
Note 467722.1 - DBMS_SCHEDULER or DBMS_JOB And DST / Timezones Explained
Note 1077446.1 - All Scheduled Jobs Run One Hour Before or Ahead of Their Scheduled Times After Daylight Saving Time
Note 357056.1 - Impact of changes to daylight saving time (DST) rules on the Oracle database
Note 402614.1 - Time Zone Data in the Data Dictionary (SYS) and the Effects of a Time Zone File Update
Bogues connus :
Bug 6336914 - DBMS_SCHEDULER.GET_SYS_TIME_ZONE_NAME returns NULL for GMT time zone
==> Corrigé dans 11.2.0.1, 11.1.0.7, 10.2.0.5
Bug 12325266 - JOBS FAIL WITH ORA-01878 AFTER SWITCH TO DST
doublon du Bug 11900845
BUG:11900845 - AFTER DST CHANGE LOT OF DBMS_JOBS STARTED FAILING WITH ORA-1878
==> corrigé dans 12.1.0.1, 11.2.0.3
6. Problèmes liés aux vues de journal des jobs du Scheduler
Le Scheduler permet de surveiller l'exécution des jobs ou l'ouverture et la fermeture des fenêtres, ainsi que d'autres informations, dans les vues de journal suivantes :
DBA_SCHEDULER_JOB_RUN_DETAILS
DBA_SCHEDULER_JOB_LOG
DBA_SCHEDULER_WINDOW_LOG
Ces vues fournissent des informations importantes sur l'état réel des objets du Scheduler.
Il arrive que les informations de journal aient été effacées. Cela peut se faire manuellement en exécutant dbms_scheduler.purge_log ou en définissant l'attribut LOG_HISTORY, qui déclenche la purge après un certain délai.
Cet attribut peut être défini au niveau global ou pour une classe de jobs.
Notez que chaque job est associé à une classe de jobs. Si aucune n'est indiquée explicitement, le job est placé dans DEFAULT_JOB_CLASS.
La valeur par défaut de LOG_HISTORY est 30 : 30 jours après l'exécution du job, les informations sur cette exécution sont donc effacées.
Dans d'autres cas, les vues de journal des jobs du Scheduler peuvent atteindre un volume anormalement élevé, ce qui peut retarder les jobs.
Les rapports AWR affichent par exemple :
enq: JS - queue lock
enq: JS - q mem clnup lck
parmi les principaux événements.
Cela peut se produire lorsque
- les vues de journal n'ont pas été purgées depuis longtemps (vérifiez log_history, ou si le job de purge a été désactivé)
- un grand nombre de jobs sont créés chaque jour ou chaque heure, ce qui remplit très rapidement les tables de journal
Suggestions :
- Vérifiez la valeur actuelle de 'log_history' en interrogeant les attributs globaux ainsi que la valeur de cet attribut dans une classe de jobs :
connect / as sysdba
select ATTRIBUTE_NAME, VALUE
from DBA_SCHEDULER_GLOBAL_ATTRIBUTE;
select *
from dba_scheduler_job_classes
where job_class_name in (select job_class
from dba_scheduler_jobs
where job_name=upper('&jobname'));
select count(*) from DBA_SCHEDULER_JOB_RUN_DETAILS;
select count(*) from DBA_SCHEDULER_JOB_LOG;
select JOB_NAME, STATE from DBA_SCHEDULER_JOBS where job_name='PURGE_LOG';
Remarque : la valeur de log_history définie pour une classe de jobs a priorité sur celle de l'attribut global.
Par exemple, si log_history vaut 10 pour la classe de jobs 'A' alors que la vue DBA_SCHEDULER_GLOBAL_ATTRIBUTE affiche la valeur par défaut de 30, les informations de journal de tous les jobs de la classe 'A' seront purgées après 10 jours.
Notes et bogues connus :
Jobs not Automatically start, High waits on enq: JS - queue lock (Doc ID 1928894.1)
Note 1270854.1 - PURGE_LOG Job will purge all entries and ignore the setting of LOG_HISTORY
Note 749440.1 - Dbms_scheduler.Purge Not Removing Entries from dba_scheduler_job_run_details
Bug 9930455 - PURGE_LOG JOB WILL PURGE ALL ENTRIES OF SOME JOBS AND DISREGARD THE SETTING OF L
==> corrigé dans 12.1.0.1, 11.2.0.3
Bug 5687223 - DBMS_SCHEDULER.PURGE_LOG() DOES NOT CLEAR THE ENTRIES IN:SCHEDULER$_EVENT_LOG
fermé, non reproductible
7. Problèmes de jobs externes
Les problèmes liés à l'utilisation des jobs externes doivent aussi être analysés au niveau du système d'exploitation. Dans la plupart des cas, si le job externe ne s'exécute pas, c'est en raison de permissions ou de paramètres incorrects sur les fichiers et exécutables du Scheduler.
Suggestions pour les plateformes UNIX :
Vérifiez que les permissions suivantes sont en place :
Version 10.2. :
- rdbms/admin/externaljob.ora : 644 (rw-r--r--) et appartenant à root:oraclegroup
Les jobs sans identifiants (credentials) qui n'appartiennent pas à SYS s'exécutent sous l'utilisateur indiqué dans ce fichier.
(run_user et run_group)
- bin/extjob : 4750 (-rwsr-x---) et appartenant à root:oraclegroup
- bin/extjobo : 755 (rwxr-xr-x) et appartenant à oracle:oraclegroup
En plus, en version 11g (en raison des identifiants) :
- bin/jssu : 4750 (-rwsr-x---) et appartenant à root:oraclegroup
Les jobs externes pour lesquels un identifiant (credential) est défini s'exécutent sous l'utilisateur
indiqué dans cet identifiant.
Vérifiez l'utilisateur oracle dans /etc/group et /etc/passwd
Vérifiez qu'un job de test simple fonctionne. Par exemple :
-- create a shell script /tmp/test.sh on OS with following contents:
#!/usr/bin/ksh
date >> /tmp/tmp.out
-- change permissions and test it on OS level:
$> chmod 777 test.sh
$> ./test.sh
$> cat /tmp/tmp.out
-- create testuser and job in sqlplus:
connect / as sysdba
drop user crc cascade;
grant connect, dba to crc identified by crc;
connect crc/crc
begin
dbms_scheduler.create_job(
job_name => 'MYTEST',
job_type => 'EXECUTABLE',
job_action => '/tmp/test.sh',
auto_drop => FALSE,
enabled => true,
comments => 'Run shell-script');
end;
/
-- Check if the job did run successfully in the scheduler log tables.
Utilisez les outils de trace du système d'exploitation :
Quelques possibilités, selon leur disponibilité sur votre système :
- TRUSS :
Créez un fichier truss qui montrera aussi le processus d'arrière-plan :
(connectez-vous bien en tant que propriétaire du logiciel Oracle)
$> truss -feao /tmp/truss.log sqlplus /nolog connect crc/crc
SQL> exec dbms_scheduler.run_job(job_name=>'MYTEST', use_current_session=>TRUE);
SQL> exit
- Exemple avec STRACE :
Utilisez deux sessions :
session1 :
=======
connectez-vous à Sqlplus
session2 :
=======
connectez-vous en tant que root au niveau du système d'exploitation et recherchez avec grep le pid Sqlplus de la session1 :
Par exemple :
$> ps -ef | grep sqlplus
oracle 8478 8137 0 15:46 pts/9 00:00:00 sqlplus
$> ps -ef | grep 8478
oracle 8478 8137 0 15:46 pts/9 00:00:00 sqlplus
oracle 8479 8478 0 15:46 ? 00:00:00 oracleGSADEVC - (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 8489 7976 0 15:47 pts/7 00:00:00 grep 8478
==> lancez strace sur le pid 8479
$> strace -fo output1 -p8479
retour à la session1 :
=============
SQL> exec dbms_scheduler.run_job('MY_JOB');
SQL> exit
Recherchez les erreurs dans le fichier journal généré
Vérifiez que PAM est correctement installé, en particulier sur les plateformes Solaris et Linux.
Jssu s'authentifie au moyen de PAM, qui doit donc être correctement configuré.
Vérifiez que la commande "su" vers ce nom d'utilisateur fonctionne sans erreur.
Si PAM est configuré pour interdire "su", le client doit configurer PAM pour autoriser explicitement le service jssu. La documentation PAM de la version du système d'exploitation devrait indiquer comment procéder.
Voir aussi :
Note 976049.1 - DBMS_SCHEDULER fails with ORA-27369 and STANDARD_ERROR="Launching external job failed: Invalid username or password"
Lorsque des identifiants (credentials) sont utilisés, lancez jssu manuellement en lui passant un nom d'utilisateur et un mot de passe du système d'exploitation sur STDIN
Par exemple, pour exécuter "/bin/echo hi there" avec jssu sous l'utilisateur ostestusr, dont le mot de passe est ostestpwd, vous pouvez utiliser :
jssu
ostestusr
ostestpwd
1
/bin/echo
2
hi
there
==> La sortie devrait ressembler à " !@#--!@#7#@!--#@! ". Fournissez cette sortie au support Oracle.
Suggestions pour les plateformes Windows :
Le service Windows OracleJobScheduler doit être démarré pour que les jobs externes s'exécutent.
(sauf pour les jobs du schéma SYS et les jobs avec identifiants).
L'utilisateur sous lequel s'exécute le service Windows OracleJobScheduler doit disposer du privilège Windows "Log on as batch job".
Un fichier batch (se terminant par .bat) ne peut pas être appelé directement par le Scheduler. Il faut plutôt utiliser cmd.exe et lui passer le nom du fichier batch en argument.
Par exemple :
begin
dbms_scheduler.create_job('myjob',
job_action=>'C:\WINDOWS\SYSTEM32\CMD.EXE',
number_of_arguments=>3,
job_type=>'executable', enabled=>false);
dbms_scheduler.set_job_argument_value('myjob',1,'/q');
dbms_scheduler.set_job_argument_value('myjob',2,'/c');
dbms_scheduler.set_job_argument_value('myjob',3,'c:\temp\test.bat');
dbms_scheduler.enable('myjob');
end;
/
Pour plus d'informations, consultez :
OTN Forum - Guide to External Jobs on 10g with dbms_scheduler e.g. scripts,batch files
Note 389685.1 - Items to Check when Problems Running Executables through the Scheduler
Note 976049.1 - DBMS_SCHEDULER fails with ORA-27369 and STANDARD_ERROR="Launching external job failed: Invalid username or password"
Note 1300215.1 - ORA-27369: job of type EXECUTABLE failed with exit code: 274667
Note 11814763.8 - Execution of external job via DBMS_SCHEDULER fails with ORA-12012 / ORA-27369
Note 1494843.1 External Job fails with ORA-27369: job of type EXECUTABLE failed with exit code: 255
Note 961019.1 DBMS_SCHEDULER Extjob Fails With "Login Executable Not Setuid-Root"
Note 787802.1 DBMS_SCHEDULER fails with ORA-27476 ORA-27475
Note 277399.1 DBMS_SCHEDULER Fails To Execute Jobs With Program_type EXECUTABLE On HP-UX
Note 1383236.1 DBMS_SCHEDULER fails with ORA-27369: job of type EXECUTABLE failed with exit code: Arg list too long
Bogues connus :
Bug 9689988 - EXTERNAL JOB FAILS WHEN RUN AS SYS USER
Fermé, pas un bogue
Bug 8780871 - EXTERNAL JOB CANNOT BE STOPPED
==>Corrigé dans 12.1.0.1 , 11.2.0.2
Bug non publié 3887932 - SCHEDULER: STOP_JOB WITH FORCE ON EXECUTABLE JOBS FAIL
==>Corrigé dans 10.2.0.1
Bug 7497013 - RELINKING EXTJOB RESETS PERMISSIONS AND OWNERSHIP OF $ORACLE_HOME/BIN/EXTJOB
doublon du Bug 7361549 - CPUJUL2008 WILL CHANGE PERMISSIONS OF ROOT OWNED EXECUTABLES
ne concerne que les anciens correctifs CPU 10202, 10203, 10204 et 11106
Bug 11814763 - Execution of external job via DBMS_SCHEDULER fails with ORA-12012 / ORA-27369
==> corrigé dans 12.1.0.1, 11.2.0.3
8. Version 11G : jobs externes distants et agent du Scheduler
À partir de la version 11g, le Scheduler peut exécuter des jobs externes sur un hôte distant.
L'agent du Scheduler doit au minimum être installé sur l'hôte distant.
Les fichiers journaux à vérifier sont :
- $ORACLE_HOME\scheduler\execution_agent\data\agent.log (fichier journal de l'agent du Scheduler)
- $ORACLE_HOME\scheduler\execution_agent\data\log\ répertoire contenant la sortie standard (stdout) de chaque job
Pour tracer l'agent du Scheduler, définissez LOGGING_LEVEL=ALL dans le fichier schagent.conf.
Pour un exemple, voir
Note 1074141.1 - How to install and setup the Scheduler Agent (schagent) so can run Remote External Jobs
Notes et bogues connus :
Note 1074141.1 - How to install and setup the Scheduler Agent (schagent) so can run Remote External Jobs
Note 789320.1 - ORA-29024: Certificate validation failure
Note 1360434.1 - 11.2 set up schagent -registgerdatabase error: java.net.SocketException
Bug 12413355 - REMOTE EXTJOB IN WINDOWS CORES IN SCHEDULER AGENT JSSU.EXE
doublon du Bug 12886827 - GET/PUT_FILE FAILURES FOR WINDOWS SERVER
==> corrigé dans 12.1.0.1, 11.2.0.4. problème propre à Windows
Bug 14038023 - TT12.1TOOLS: JOB SCHEDULER ERROR ORA-06512: AT "SYS.DBMS_ISCHED", LINE 8423
==> ORA-1422 lorsque plusieurs agents d'exécution distants partagent le même port
Bug non publié 12886827 - GET/PUT_FILE FAILURES FOR WINDOWS SERVER
==> corrigé dans 12.1.0.1, 11.2.0.4. problème propre à Windows
Bug non publié 6435087 - VARIOUS ISSUES WITH SCHEDULER AGENT
==> Corrigé dans 11.2.0.1, 11.1.0.7
9. Problèmes de jobs basés sur des événements
Grâce à cette fonctionnalité, le Scheduler peut envoyer ou recevoir des messages provenant d'un processus ou d'une application pour signaler qu'une action ou un événement a été détecté.
Par exemple, le Scheduler place un message dans une file d'événements par défaut. Les applications s'abonnent à cette file, en retirent les messages d'événement et prennent les mesures appropriées.
À l'inverse, lorsqu'une application place un message dans une file, le Scheduler peut être averti afin de démarrer un job. Le Scheduler peut donc être l'émetteur comme le destinataire.
Ce mécanisme repose sur Oracle Streams Advanced Queuing pour déclencher et/ou consommer des événements ; le processus Qmon y joue un rôle important.
Qmon est chargé de retirer les messages traités (PROCESSED) d'une table de file d'attente et de mettre à jour l'IOT de retrait (dequeue) au besoin. Lorsque vous combinez le Scheduler et Advanced Queuing, il est fortement recommandé de ne pas définir le paramètre AQ_TM_PROCESSES (valeur par défaut = 1) et de laisser le système s'ajuster automatiquement.
Vous trouverez un exemple de configuration d'un job basé sur des événements dans :
Note 1300444.1 - How to create a event based chained job
Note 1431664.1 - How to build up an event based job - an example
Bogues connus :
Bug non publié 9673944 - DBMS_SCHEDULER.RUN_JOB DOES NOT WORK ON EVENT JOBS.
==> corrigé dans 12.1.0.1
Bug non publié 12423122 - ORA-600 [KWQITNMPHE:LTBAGI] WHEN SCHEDULER USES AQ
==> corrigé dans 12.1.0.1, 11.2.0.3
Bug non publié 9865045 - SCHE:HANG WHILE DROPPING EVENT RECEIVE JOBS.
==> corrigé dans 12.1.0.1, 11.2.0.3
Bug 12899768 - PROCESSED MESSAGES REMAIN IN QUEUE CAUSING SPACE ISSUES
==> corrigé dans 12.1.0.1, 11.2.0.4 , 11.2.0.3.8 PSU
Bug 13038485 - JOB_QUEUE_PROCESS NOT SPAWNED BY SCHEDULER AQ PROPAGATION JOB IN 11.2.0.2
Suspendu, informations requises non disponibles
Bug 9946875 - Scheduler event-based job does not fire when there is a subscriber on AQ queue
==> corrigé dans 12.1.0.1, 11.2.0.4
10. Problèmes de jobs chaînés
Une chaîne est un regroupement de programmes liés entre eux pour atteindre un objectif commun.
Les chaînes de jobs servent à mettre en œuvre des flux de travail dans lesquels chaque étape de la chaîne représente une tâche distincte.
Les règles de la chaîne représentent les dépendances entre ces tâches et peuvent prendre la forme condition => action
Exemples :
a) Chaîne séquentielle :
rule1: TRUE => START S1
rule2: S1 completed => START S2
rule3: S2 completed => START S3
rule4: S3 completed => END
b) Chaîne avec embranchements :
rule1: TRUE => START S1
rule2: S1 completed => START S2, S3
rule3: S2 completed AND S3 completed => START S4
rule4: S4 succeeded => START S5
rule5: S4 failed => START S6
rule6: S5 completed OR S6 completed => END
Notes et bogues connus :
Note 727499.1 - Sample how to create a job running chains
Note 1272728.1 - Is It Possible To Assign Chain Parameters To A Scheduler Job?
Note 1300444.1 - How to create a event based chained job
Bug 12986415 - DBMS_SCHEDULER.RUN_CHAIN WITH STEP_STATE_LIST NOT WORKING DUE TO A MISSING JOIN
==> corrigé dans 12.1.0.1, 11.2.0.4
11. Échec des notifications des jobs du Scheduler
Vous pouvez configurer un job pour qu'il envoie des notifications par courriel lorsqu'il change d'état. Les notifications peuvent être envoyées à plusieurs destinataires et déclenchées par n'importe quel événement d'une liste d'événements d'état de job que vous définissez. Vous pouvez aussi indiquer une condition de filtre : seuls les événements d'état de job qui y correspondent génèrent alors des notifications. Vous pouvez inclure des variables comme le propriétaire du job, le nom du job, le type d'événement, le code d'erreur et le message d'erreur, dans l'objet comme dans le corps du message. Le Scheduler renseigne automatiquement ces variables avant d'envoyer la notification par courriel.
Par exemple, vous pouvez configurer un job pour qu'il envoie un courriel au DBA principal et à l'un des DBA seniors chaque fois que le job échoue avec le code d'erreur 600 ou 700. Vous pouvez aussi configurer ce même job pour qu'il n'avertisse que le DBA principal si le job ne démarre pas à l'heure prévue.
Les notifications par courriel des jobs du Scheduler cessent de fonctionner pour tous les jobs et pour tous les utilisateurs, même après un redémarrage de la base de données.
Notes et bogues connus :
Note 16623661.8 - Bug 16623661 - No email notification is sent by scheduler