[Pl/Sql] DBMS_JOB et procédure

**oursin** · 03/08/2006, 15h26

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**pifor** · 03/08/2006, 15h36

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é.

**Jaouad** · 03/08/2006, 15h44

DBMS_JOB documentation

**oursin** · 03/08/2006, 15h45

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 :

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 ?

**Jaouad** · 03/08/2006, 15h45

Non ca c'est juste les modications du REDO courant

Peux t'on avoir le source

**oursin** · 03/08/2006, 15h47

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

**oursin** · 03/08/2006, 15h50

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
/

**Jaouad** · 03/08/2006, 15h52

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 ...

**oursin** · 03/08/2006, 15h54

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..

**Jaouad** · 03/08/2006, 15h58

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

**oursin** · 03/08/2006, 16h25

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..)

**Jaouad** · 03/08/2006, 16h27

il faut vérifier
et qu'est ce que cela donne si tu lances la procédure à la main , sans DBMS_JOB

**oursin** · 03/08/2006, 16h31

la procédure marche tres bien si je la lance seule avec exec...

**pifor** · 03/08/2006, 16h44

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 ?

**oursin** · 03/08/2006, 16h51

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...

**Jaouad** · 03/08/2006, 16h53

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select * from dba_jobs 
 
select * from dba_objects 
where object_name = 'PROCEDURE'
 
select * from dba_tables

**oursin** · 03/08/2006, 17h04

merci

avec ca je peux confirmer que les tables, procedures et jobs ont bien le meme propriétaire.

**remi4444** · 03/08/2006, 22h31

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...

**oursin** · 04/08/2006, 09h50

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

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 ?

**oursin** · 04/08/2006, 10h40

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"

merci à tout ceux qui m'ont aidé

[Pl/Sql] DBMS_JOB et procédure

Oracle

Discussions similaires

Partager

Partager