[Pl/Sql] DBMS_JOB et procédure

Version imprimable

03/08/2006, 15h26
oursin

[Pl/Sql] DBMS_JOB et procédure
Bonjour a tous,

je rencontre un probleme avec DBMS_JOB d'oracle.

J'ai créé des procédures stockées pl/sql. Lorsque je les lance directement, elles fonctionnent sans probleme.

J'ai ensuite créé des "jobs" pour chacune d'entre elles genre :
Code:

1 2 3 4 5 6 7 8 DECLARE jobno number; begin dbms_job.submit(jobno,'proc_client_maj;',trunc(sysdate)+1+5/24,'trunc(sysdate)+1+5/24'); commit; end; /
Lorsque je regarde ma liste de jobs, il semble qu'ils aient été correctement lancés, à la date prévue, puisque le next_date passe à la date suivante. De plus, le champs failures reste à 0.

Pourtant, le résultat de la procédure n'apparait pas dans la base.
Le problème est identique si j'essaye de lancer le job manuellement avec dbms_job.run().

Autrement dit, la procédure marche, sauf si elle est lancée par un "job"... et j'avoue ne pas comprendre comment c'est possible.

Je précise également que mes autres jobs marchent, le probleme n'intervient que sur 3 procédures particulieres, qui calculent des stats. Ces procédures sont particulierement longues à s'exécuter (5 à 10 min). Pourtant je n'ai pas trouvé d'information concernant une éventuelle limite genre "timeout" pour les jobs...

Avez-vous une idée de la source éventuelle d'un problème de ce genre ??

Merci
03/08/2006, 15h36
pifor

Vérifiez qu'il y a bien un COMMIT dans la procédure lancée et vérifiez aussi que dans l'alert.log ne contient aucune erreur pour le job lancé.
03/08/2006, 15h44
Jaouad

DBMS_JOB documentation
03/08/2006, 15h45
oursin

Il y a bien un COMMIT dans chaque procédure lancée par un job.

Dans le fichier alert, il y a quelques lignes qui coincident avec l'heure planifiée :

Citation:

Thu Aug 03 05:20:30 2006
Thread 1 advanced to log sequence 12393
Current log# 3 seq# 12393 mem# 0: D:\ORADATA\GTI\REDO03.LOG
Thread 1 advanced to log sequence 12394
Current log# 1 seq# 12394 mem# 0: D:\ORADATA\GTI\REDO01.LOG
Thread 1 advanced to log sequence 12395
Current log# 4 seq# 12395 mem# 0: D:\ORADATA\GTI\LOG5ORCL.ORA

Est-ce que ca peut permettre de mieux comprendre le probleme ?
03/08/2006, 15h45
Jaouad

Non ca c'est juste les modications du REDO courant

Peux t'on avoir le source
03/08/2006, 15h47
oursin

Jaouad, je me suis beaucoup servi de ce tuto qui est tres clair et qui m'a bien rendu service, d'ailleurs la plupart des jobs que j'ai créé marchent, mais j'ai un probleme particulier et je n'ai pas trouvé la réponse pour l'instant dans ce tutoriel ;)

Voila la source d'une des procédures qui posent probleme :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
create or replace procedure proc_pays_maj AS
  datemois CHAR(6);
  code Article.ARKTCODART%TYPE;
  codecomp Article.ARKTCOMART%TYPE;
  pays Client.CLCTCPAYS%TYPE;
  somme Integer;
 
  CURSOR C1 IS select TO_CHAR(TO_DATE(ECCJCRE,'yyyymmdd'),'mmyyyy'), 
  LCCTCODART, LCCTCOMART, ECCTCPAYS, SUM(LCCNQTEEXP)  
  from EEXPCLI,LEXPCLI
  where EEXPCLI.ECKTSOC=LEXPCLI.LCKTSOC 
  and EEXPCLI.ECKTNUMERO=LEXPCLI.LCKTNUMERO 
  and EEXPCLI.ECKTINDICE=LEXPCLI.LCKTPSF 
  and ECKTSOC='110' 
  and ECCJCRE>=to_char(sysdate,'yyyymm')-1 || '01'
  and ECCJCRE<=to_char(sysdate,'yyyymm')-1 || '31' 
  group by TO_CHAR(TO_DATE(ECCJCRE,'yyyymmdd'),'mmyyyy'),LCCTCODART, LCCTCOMART,ECCTCPAYS;
 
  BEGIN
    OPEN C1;
    LOOP
      FETCH C1 INTO datemois,code,codecomp,pays,somme;
        EXIT WHEN C1%NOTFOUND;
        INSERT INTO STATPAYS Values(datemois,code,codecomp,pays,somme);
    END LOOP;
  CLOSE C1;
  commit;
  end;
/

03/08/2006, 15h52
Jaouad

tu es sous quelle version ??
lorsque tu lance la procédure à la main je suppose que cela fonctionne correctement ??

Tu as bien fait attention à tout ce qui était privilége ...
03/08/2006, 15h54
oursin

heu version 8i. ca ne fonctionne pas non plus avec dbms_job.run()... enfin, ca marche dans le sens ou ca me dit que tout s'est bien passé, mais ca ne modifie pas les stats etc..
03/08/2006, 15h58
Jaouad

Bon c'est mort pour DBMS_SCHEDULER , sinon si tu as pu la lancer avec DBMS_JOB, il se peut que le probléme vient de la procédure en elle même et non pas du DBMS_JOB.

Est ce que le user propriétaire de la procédure, des objets et du jobs sont les mêmes
03/08/2006, 16h25
oursin

hé bien j'ai créé moi-même la procédure et le job, sous la même instance, donc je pense que oui.. (mais je suis pas tout a fait sur de verifier les bonnes valeurs pour comparer..)
03/08/2006, 16h27
Jaouad

il faut vérifier
et qu'est ce que cela donne si tu lances la procédure à la main , sans DBMS_JOB
03/08/2006, 16h31
oursin

la procédure marche tres bien si je la lance seule avec exec... :oops:
03/08/2006, 16h44
pifor

S'il y a une erreur à l'exécution (droit d'accès ou autre) elle doit être dans l'alert.log sauf s'il y du code qui récupère toutes les exceptions.

Quand on a un problème de ce type, il peut arriver que le code qui s'exécute n'est pas le bon: il y a peut-être plusieurs schémas avec les objets qui ont le même nom ?
03/08/2006, 16h51
oursin

a priori non, puisque j'ai créé cette procédure moi-même et qu'elle n'existe pas ailleurs, de même pour le job.

néanmoins, comme je le disais plus haut, je me perd un peu avec ce qui concerne le dictionnaire, les méta-données etc.. du coup je sais pas vraiment où chercher les infos pour voir quels sont les proprietaires par exemple... mais j'ai du mal a comprendre comment il pourrait y avoir un proprietaire différent puisque je me connecte toujours de la même façon...
03/08/2006, 16h53
Jaouad
Citation:

Envoyé par oursin

du coup je sais pas vraiment où chercher les infos pour voir quels sont les proprietaires par exemple... m

Si tu as les droits DBA sinon remplacer DBA par ALL
Code:

1 2 3 4 5 6 select * from dba_jobs select * from dba_objects where object_name = 'PROCEDURE' select * from dba_tables
03/08/2006, 17h04
oursin

merci ;)

avec ca je peux confirmer que les tables, procedures et jobs ont bien le meme propriétaire.
03/08/2006, 22h31
remi4444

Tu devrais ajouter une action dont tu est sur en début de proc (du style une insertion en dur dans une table de test) comme ça tu en auras le coeur net.

Piste:
de quel type est ton champ "ECCJCRE" car s'il est du type DATE ou nombre, il y aura des conversions implicites qui dépendront du paramètres NLS_PARAMETER qui peut etre différent d'une session à l'autre ce qui expliquerait les différence de comportement...
04/08/2006, 09h50
oursin
après un redémarrage d'Oracle hier soir, j'arrive ce matin à les lancer avec avec run(), et ca fonctionne. par contre, les jobs qui étaient programmés dans la nuit ont bien été lancés mais une nouvelle fois sans écrire quoi que ce soit dans la base..

pour remi : ECCJCRE est une chaine de caractere. par contre ta remarque me fait penser à une question : dans le tuto de Jaouad, il est indiqué qu'il faut changer le format de date :
Code:

1 2 alter session set NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS' ;
apres ça, la date ET l'heure apparaissent dans le champ next_date :

Citation:

SQL> select job , what, next_date from user_jobs ;
JOB WHAT NEXT_DATE
---------- -------------------- -------------------
1245 statspack.snap; 03/09/2005 09:00:00

or, en ce qui me concerne, l'heure apparait dans NEXT_SEC.

est-ce que ca peut fonctionner tout de même comme ça ou faut il changer forcément le format ?
04/08/2006, 10h40
oursin

bon, vu que le redémarrage d'Oracle semblait avoir réglé une partie du probleme, j'ai supprimé et recréé à l'identique les 3 procédures et jobs correspondant qui posaient probleme. J'ai fait un essai et il semble que ca fonctionne correctement desormais. Mystere...
Je les ai reprogrammé pour ce week-end, j'aurai une bonne ou mauvaise surprise lundi matin...

en attendant, probleme "résolu" :D

merci à tout ceux qui m'ont aidé