supprimer un job [Résolu]

[magboom]

Bonjour ,
SGBD ORACLE 9.2
OS Win 2003 Server,

j'ai creé un job pour executer l'outil stat pack tt les jour à une heure fixe. Pour arreter son execution j'ai utilisé la fonction DBMS_JOB.BROKEN(N° job,TRUE) et ça a marché , le chamaps broken est passé à "Y",
mon probleme c'est que quand je veux le réactiver avec la mem commande DBMS_JOB.BROKEN(N° job,FALSE) ou de forcer son execution avec la fonction DBMS_JOB.RUN(N° job), ou mem de le supprimer avec la commande DBMS_JOB.remove(N° job) il me retourne l'erreur suivante :

SQL> execute dbms_job.remove(21);
BEGIN dbms_job.remove(21); END;

*
ERREUR Ó la ligne 1 :
ORA-23421: le job numÚro 21 n'est pas un job de la file d'attente
ORA-06512: Ó "SYS.DBMS_SYS_ERROR", ligne 86
ORA-06512: Ó "SYS.DBMS_IJOB", ligne 529
ORA-06512: Ó "SYS.DBMS_JOB", ligne 171
ORA-06512: Ó ligne 1

la meme erreur est retourné avec l'utilisateur sys et perfstat,
merci

[Pomalaix]

Bonjour

DBMS_JOB a la particularité que seul le créateur d'une tâche planifiée peut l'exécuter ou la modifier. Se connecter comme DBA ou SYSDBA n'y change rien.

Dans DBA_JOBS, quelle est la valeur de LOG_USER pour la tâche 21 ?
C'est sous ce compte qu'il faut se connecter pour pouvoir manipuler la tâche en question, et éventuellement la supprimer.
Ca c'est la méthode officielle.

Pour l'administrateur qui doit gérer des tâches planifiées appartenant à différents utilisateurs, la restriction sur le propriétaire décrite ci-dessus est franchement pénalisante.
On peut cependant s'en sortir à l'aide du paquetage DBMS_IJOB (noter le I dans le nom qui fait toute la différence), qui lui n'est pas soumis à cettre restriction et permet à quiconque se connecte en SYSDBA d'administrer toutes les tâches planifiées, qu'elles lui appartiennent ou non.

En complément sur DBMS_JOB et les problèmes de propriétaire, il est bon d'être informé que lors d'un import, les tâches planifiées deviennent la propriété du compte Oracle sous lequel on effectue l'import, indépendamment de leur propriétaire dans la base d'origine.
En clair, si SCOTT avait une tâche planifiée N°21, qu'on exporte la base et qu'on l'importe ailleurs en se connectant comme SYSTEM, c'est SYSTEM qui devient propriétaire de la tâche 21 (LOG_USER dans DBA_JOBS).
En revanche, le schéma d'exécution (colonne SCHEMA_USER) n'est pas altéré par l'import, c'est à dire que la procédure exécutée par cette tâche recherchera toujours ses objets dans le schéma SCOTT.

[magboom]

bonjour,
effectivement c'etait un problème de propietaire du job, j'ai consulté le champs Log_user et j'ai fait la manip sous ce compte et ça a marché !
merci de ton aide et pour toute les info précieuse que tu m'a donné !
A+