[DBA] Programmer des jobs

Version imprimable

23/01/2006, 16h21
pzou

[DBA] Programmer des jobs
Bonjour,

J’ai un problème de lancement d'un job sous oracle. J’ai pour l'instant effectué les manipulations suivantes :

Code:

alter system set job_queue_processes = 2;

La vérification dans la table v$parameter montre que c'est ok
Code:

1 2 3 4 5 begin dbms_job.ISUBMIT (1, 'bdpadtprop.MAJ_contrat_rev();', sysdate+1/1440,'sysdate+1'); commit; end;
Le job est bien prit en compte

Code:

select job, what,sysdate,u.LAST_DATE,u.NEXT_DATE,u.INTERVAL from user_jobs u;

Par contre mon problème est que l'heure de prochaine exécution arrive et qu'il ne se passe strictement rien... alors que si je force l'exécution ça fonctionne

begin
dbms_job.run
(1,true);
commit;
end;

Y aurait il un paramètre qu'il faille activer ailleurs.

Merci de votre aide

Remplacement des balises [ b ] ... [ /b ] au profit de [ code ] ... [ /code ] par LeoAnderson.
23/01/2006, 17h48
plabrevo

Code:

alter system set job_queue_processes = 2;

Signifie que 2 jobs seulement peuvent s'executer simultanement sur l'instance. C'est un peu court surtout si la base herberge beaucoup d'outils.

Verifies dans DBA_JOBS le nombre des jobs deja dans la queue, et eventuellement augmente le parametre de facon tres significative, 10, 20 ou 30.
23/01/2006, 19h06
pzou

Merci pour l'info plabrevo.
Malheureusement j'ai déjà fait le test avec 50 et ça ne fonctionne pas non plus.
De plus la table DBA_JOBS ne contient qu'une seule entrée, celle de mon job.
Il faut savoir que sur cette base, il n'y a pas jamais eu de jobs mis en place.

Y aurait'il qq part une table de log indiquant pourquoi l'heure passe et le job ne s'effectue pas ?
23/01/2006, 19h40
plabrevo

Le job ne serait pas en erreur par hasard, bloquant toutes ses re-executions, sauf celles qui sont manuellement forcees? Que donnent les valeurs 'broken' et 'failures' dans la vue USER_JOBS?
23/01/2006, 20h05
pzou

Alors voila, peut être qu'il est en erreur, mais je n'ai pas de certitude. Comme le job se lance avec un run et comme la procédure se lance elle aussi manuellement sans problème, je ne sais pas...
Quant au re-exécutions, même la première fois (premier lancement) ça ne fonctionne pas. Donc a priori pas de de problème d'auto blocage

Le champ broken est à N et failure reste vide, une fois la date de première exécution passée.
Si on force l'exécution failures passe à 0 et broken reste à N
23/01/2006, 20h57
plabrevo

Est-ce que tu as 'committe' ta session apres l'ordre isubmit?

Si non, le job te paraitra etre dans la queue alors qu'il ne l'est pas encore.

Autre piste, l'heure de la base est-elle a jour, expliquant des comportement a priori bizarres?
23/01/2006, 21h05
pzou

Dans la déclaration de la procédure, il y a le commit

Citation:

begin
dbms_job.ISUBMIT
(1, 'bdpadtprop.MAJ_contrat_rev();', sysdate+1/1440,'sysdate+1');
commit;
end;

Mais il faut peut être en faire un autre

Un seul commit suffit. Le mieux pour debugger ca c'est de s'affranchir de la complexite ou des pb lies a la procedure appelee.

Le testcase suivant devrait te donner des idees pour debugger.

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
30
31
32
33
34
35
36
37
38
 
DROP PROCEDURE pl1_proc
/
DROP TABLE pl1_tab
/
CREATE TABLE pl1_tab
(d        DATE)
/
CREATE OR REPLACE PROCEDURE pl1_proc
AS
BEGIN
INSERT INTO pl1_tab VALUES (sysdate);
COMMIT;
END;
/
BEGIN
dbms_job.remove(1);
dbms_job.isubmit(1, 'pl1_proc();', sysdate,'sysdate+1');
commit;
end; 
/
COL what FOR A30
SELECT TO_CHAR(sysdate,'DDMMYYYY HH24:MI:SS') FROM user_jobs
/
SELECT job,what,broken,failures FROM user_jobs
/
execute dbms_lock.sleep(1);
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
/
execute dbms_lock.sleep(1);
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
/
execute dbms_lock.sleep(1);
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
/
execute dbms_lock.sleep(1);
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
/

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
Procedure dropped.
 
 
Table dropped.
 
 
Table created.
 
 
Procedure created.
 
 
PL/SQL procedure successfully completed.
 
 
TO_CHAR(SYSDATE,'
-----------------
23012006 12:32:12
 
 
       JOB WHAT                           B   FAILURES
---------- ------------------------------ - ----------
         1 pl1_proc();                    N
 
 
PL/SQL procedure successfully completed.
 
 
no rows selected
 
 
PL/SQL procedure successfully completed.
 
 
TO_CHAR(D,'DDMMYY
-----------------
23012006 12:32:14
 
 
PL/SQL procedure successfully completed.
 
 
TO_CHAR(D,'DDMMYY
-----------------
23012006 12:32:14
 
 
PL/SQL procedure successfully completed.
 
 
TO_CHAR(D,'DDMMYY
-----------------
23012006 12:32:14

Effectivement, je doit avoir un problème peut être de droit voila le retour du code que tu m'as envoyé --> pas de ligne dans la table

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
DROP PROCEDURE pl1_proc
Procedure dropped
 
DROP TABLE pl1_tab
Table dropped
 
CREATE TABLE pl1_tab
(d        DATE)
Table created
 
CREATE OR REPLACE PROCEDURE pl1_proc
AS
BEGIN
INSERT INTO pl1_tab VALUES (sysdate);
COMMIT;
END;
Procedure created
 
BEGIN
dbms_job.remove(1);
dbms_job.isubmit(1, 'pl1_proc();', sysdate,'sysdate+1');
commit;
end;
PL/SQL procedure successfully completed
 
COL what FOR A30
SELECT TO_CHAR(sysdate,'DDMMYYYY HH24:MI:SS') FROM user_jobs
TO_CHAR(SYSDATE,'DDMMYYYYHH24:
------------------------------
23012006 17:39:44             
1 row selected
 
 
SELECT job,what,broken,failures FROM user_jobs
JOB WHAT                           BROKEN FAILURES
--- ------------------------------ ------ --------
  1 pl1_proc();                    N              
1 row selected
 
 
begin 
 dbms_lock.sleep(1);
end;
PL/SQL procedure successfully completed
 
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
0 rows selected
 
 
begin 
 dbms_lock.sleep(1);
end;
PL/SQL procedure successfully completed
 
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
0 rows selected
 
 
begin 
 dbms_lock.sleep(1);
end;
PL/SQL procedure successfully completed
 
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
0 rows selected
 
 
begin 
 dbms_lock.sleep(1);
end;
PL/SQL procedure successfully completed
 
SELECT TO_CHAR(d,'DDMMYYYY HH24:MI:SS') FROM pl1_tab
0 rows selected

Merci de ton aide en tous cas. Je vais investiguer dans cette direction...

24/01/2006, 09h11
lalystar

Bonjour,

Quel est la valeur du paramètre job_queue_interval ?

Laly.
24/01/2006, 11h31
Jaouad

DBMS_JOB ou comment plannifier des jobs sous Oracle et plus précisément : Paramètres d'initialisation

Bonjour à tous et merci pour les différentes infos.

Alors je suis en version 9i, donc a priori le paramètre JOB_QUEUE_INTERVAL n'existe plus.

Pour ce qui est des autres paramètres d'initialisations :

JOB_QUEUE_KEEP_CONNECTIONS il n'existe plus depuis la 8i

Les privilèges semblent acceptés

Autorisation de privilèges (GRANT) acceptée.

Par contre :

La commande

Code:

alter system set job_queue_processes=5

ce passe bien

Mais

Code:

alter system set job_queue_processes=5 scope =both ;

Me renvoie l'erreur suivante
Code:

1 2 3 4 ORA-32001: write to SPFILE requested but no SPFILE specified at startup Cause: An alter system command or an internal self tuning mechanism requested a write to the SPFILE but no SPFILE was used to startup the instance Action: Create an SPFILE and re-start the instance using the SPFILE.
Le SPFILE est'il obligatoire? Je pensais que non...

25/01/2006, 14h40
aline

Le spfile n'est pas obligatoire, mais il l'est pour changer des paramètres dynamiquement. c'est d'ailleurs son grand interet.
Et quand tu donne la clause scope =both, tu veux changer dynamiquement tes paramètres....
26/01/2006, 16h29
pzou

Merci pour cette dernière info.

Il faut donc que je crée mon SPFILE (ce qui est fait) et que je relance mon instance.
Le problème est que cette base est en production donc il est quasiment impossible de l'arrêter.
Je crois que je vais me tourner vers une crontab unix en attendant qu'il y ait une intervention sur cette base. C'est bien dommage…

Merci, à tous
26/01/2006, 16h43
Jaouad

Bonjour ,

si tu es en production et que cette instance ne peut pas être arrété :

tu fait :

Code:

alter system set job_queue_processes=5

puis tu met :

Citation:

job_queue_processes=5

dans l'init.ora , il sera ainsi repris lors d'une eventuel re démarrage