DBMS_JOB ou comment schéduler des jobs sous Oracle
Par
Jaouad (jaouad.developpez.com/)
Apprenez à programmer des tâches planifiées sous Oracle 9i. I. Définition II. Paramètres d'initialisation III. Les Procédures de DBMS_JOB III-A. SUBMIT III-B. ISUBMIT III-C. RUN III-D. REMOVE III-E. BROKEN III-F. WHAT III-G. NEXT_DATE III-H. CHANGE III-I. CHECK_PRIVS III-J. INTERVAL III-K. INSTANCE III-L. USER_EXPORT IV. Définition I. Définition
Oracle gère une file d'attente interne pour les jobs. Ainsi vous pouvez soumettre à Oracle des jobs sans passer par ceux du système d'exploitation ( Crontab ou planificateur de Tâches). Les files d'attente sont généralement utilisées pour gérer les fonctions de la base de données interne, telles que l'analyse des objets de la base de données, ou un grand classique : Le lancement de report STATSPACK. Concernant les travaux de maintenance de la production, il est préférable de les soumettre à la file d'attente du système d'exploitation. La situation optimale consistant à avoir un système de gestion de jobs centralisé. Ces jobs alimentent la table SYS.JOB$ qui appartient au Tablespace SYSTEM. Avant de commencer, je rappelle qu'il est indispensable de toujours valider ( commit ) lorsque l'on fait appel aux procédures du package DBMS_JOB (cf. les exemples). II. Paramètres d'initialisation
Avant de pouvoir commencer à soumettre à Oracle vos jobs, il vous faut vous assurer que les paramètres d'initialisation sont corrects. JOB_QUEUE_PROCESSES : ce paramètre va nous donner le nombre de jobs qu'il est possible de programmer. Ce paramètre est visible par les deux commandes suivantes:
Ce paramètre est apparu avec la version 7.3 d'oracle, et jusqu'à la version 8.0.4 il faisait partie des paramètres statiques. A savoir qu'un arrêt /relance de la base était nécessaire pour que le changement soit pris en compte. Version 8i : Il est possible de faire un Alter system pour modifier la valeur de l'instance. Par la suite une modification du Init.ora sera nécessaire.
Version 9i : Avec le SPFILE :
JOB_QUEUE_INTERVAL : Durée minimum exprimée en secondes entre deux jobs. Une modification de ce paramétre se fait forcément via l'init.ora.De plus il disparaît avec la version 9i. JOB_QUEUE_KEEP_CONNECTIONS : Ce paramètre est par défaut positionné à FALSE, s'il est positionné à TRUE, il indique à Oracle de ne pas se déconnecter lorsque le job a été exécuté. Ce paramètre disparaît avec la 8i. Les vues DBA_JOBS, USER_JOBS, DBA_JOBS_RUNNING et USER_JOBS_RUNNING vont nous permettre d'avoir des informations pertinentes. Il existe un script dbmsjob.sql qui est présent dans $ORACLE_HOME/rdbms/admin et qui permet de recréer le package dbms_job, ce package appartient à l'utilisateur SYS et donc il est conseillé de se connecter; en tant que SYS lors du lancement de ce dernier. Pour pouvoir exécuter le package DMS_JOB il faut avoir le privilège requis.
Pour connaître toutes les procédures du package, il suffit de faire un DESC
III. Les Procédures de DBMS_JOBIII-A. SUBMIT
Cette procédure va nous permettre de soumettre un job dans la file d'attente :
Oracle gère le numéro de job par une séquence interne à oracle et qui appartient à SYS: JOBSEQ.
Donc ce qui donne pour soumettre un job qui va s'exécuter tout les jours à 9 heures :
Détails de quelques paramètres : Job : Identifiant unique du job. What : Code PL/SQL à exécuter. Next date : Prochaine exécution. Interval : Intervalle entre deux dates. No_Parse : Le code PL/SQL doit-il être parsé avant exécution. Comment déterminer la prochaine exécution ? Avant tout, il ne faut pas oublier que dans INTERVAL, sysdate +1 représente demain à 00h00 et non pas dans 24 heures. Pour les heures il faut préciser le nombre d'heures sur 24.
Quelques exemples de soumission : Tous les jours de la semaine à 18 heures :
III-B. ISUBMIT
Cette procédure effectue le même travail que SUBMIT, cependant sans pour autant se baser sur la séquence interne Oracle. L'utilisateur donne lui-même le numéro de job.
Nous ne faisons clairement plus appel à la séquence SYS.JOBSEQ mais oracle nous permet ainsi de gérer nous-même les numéros de JOB. Exemple :
Attention à pas donner de numéro de job existant, car il existe un index unique sur la table sys.job$.
III-C. RUN
Cette procédure va nous permettre de lancer "à la main" le job.
En effet, après lui avoir fournit le numéro de job, Oracle va exécuter le job même si l'état de ce dernier est BROKEN. La procédure se compose de deux arguments, le premier où on lui indique le numéro de JOB et le second qui est positionnée à TRUE ou FALSE. Ce paramètre concerne l'exécution en arrière-plan ou pas.
NB : Cette procédure réinitialise l'état du package suite à son exécution.
III-D. REMOVE
Cette procédure va nous servir à supprimer un job.
Comme nous le constatons, cette procédure ne contient qu'un seul argument le numéro de Job. Cet identifiant unique va nous servir à déterminer le job que nous allons enlever de la file d'attente des traitements programmés.
Chaque user doit supprimer ses propres JOBS, même un user avec les privilèges DBA ne peut le faire.
III-E. BROKEN
Cette procédure permet de changer le statut du job et donc de le passer à BROKEN, ainsi il ne sera plus lancé :
Il reçoit au minimum deux argument, le numéro du job et l'état du BROKEN soit TRUE soit FALSE :
III-F. WHAT
Cette procédure sert à changer l'exécutable du Job.
Ainsi tout en gardant le numéro de traitement et la fréquence d'exécution, on va pouvoir remplacer le code qui est exécuté.
Nous avons besoin de renseigner deux paramètres, le numéro de Job et le nouveau traitement.
III-G. NEXT_DATE
Nous allons nous intéresser à la prochaine exécution et la modifier.
Cette procédure a besoin du numéro de job et de la prochaine date d'exécution.
Dans cet exemple nous retardons la prochaine exécution d'une heure.
III-H. CHANGE
Grâce à la procédure CHANGE nous allons pouvoir changer différents attributs du JOB.
III-I. CHECK_PRIVS
Nous allons tester ici les privilèges du user sur les différents objets.
Cette procédure n'existe plus à partir de la 8174 :
III-J. INTERVAL
Changer le nombre d'exécutions du job.
Un exemple :
III-K. INSTANCE
Ici nous sommes dans un environnement multi-instances.
En effet, dans un environnement RAC, nous allons avoir le choix de forcer l'exécution du job sur une instance plutôt qu'une autre. Si le Job doit se déclencher alors dans ce cas là Oracle va prendre une instance disponible au hasard. Mais grâce à la vue v$instance, la possibilité de visualiser et de choisir son instance est possible. Il suffit pour cela de se servir de la procédure instance et de lui assigner le numéro d'instance.
III-L. USER_EXPORT
Permet de reproduire le texte afin de recréer le JOB, pour un éventuel export/import.
IV. Définition
Job : Travail , tâche ...
|
Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2005 Jaouad ZOUAGHI. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.