Procédure en cours d'éxécution depuis plus de 4 jours

Bonjour à tous,

j'ai un job qui est en train de s’exécuter depuis 4 jours,

sachant que ce denier contient une procédure qui fait appelle à d'autres procédures et fonctions
j'ai ce code dans toutes les procédures et fonctions

Code:

---

1 2 3 4 5

EXCEPTION WHEN OTHERS THEN code_erreur := SQLCODE; msg_erreur := substr(SQLERRM(SQLCODE),1,100); INSERT INTO ERROSQL(nomtable,codeerreur,erreur,date_erreur) VALUES ($$PLSQL_UNIT,code_erreur,msg_erreur,sysdate); COMMIT;

---

mais il y a aucune erreur a signaler jusqu'à présent

aussi j'ai vérifier les locked object il n y a rien aussi !!

je vous prie de m'orienter quand à la détection de cette anomalie

merci à vous

comment on peut arrêter une procédure en cours d’exécution ?

Bonjour,

Je vous invite tout d'abord à identifier le SID de la session faisant tourner votre procédure stockée :

Code:

---

1 2 3 4 5 6 7 8

select S.USERNAME, s.sid, s.osuser, t.sql_id, sql_text from v$sqltext_with_newlines t,V$SESSION s where t.address =s.sql_address and t.hash_value = s.sql_hash_value and s.status = 'ACTIVE' and s.username <> 'SYSTEM' order by s.sid,t.piece ;

---

Ensuite retrouver le SERIAL# liè à votre SID :

Code:

---

1 2 3 4

select * from v$session where sid = {Votre SID de session longue};

---

Puis killez votre session :

Code:

---

ALTER SYSTEM KILL SESSION 'SID,#SERIAL';

---

Si vous êtes dans l'urgence, y a pas 30 000 solutions malheureusement

Pour le problème d'origine, voir pourquoi cela met autant de temps, il nous faudrait peut-être le code de votre SP (pensez à anonymiser si besoin)

Bisous bisous

En passant, il faut se méfier du critère V$SESSION.STATUS='ACTIVE'

ACTIVE signifie que la session est actuellement en train de consommer du CPU sur le serveur Oracle.
Or une session "en train de travailler" au sens fonctionnel de la chose n'est pas forcément, à cet instant précis, en train de consommer du CPU.
Le statut d'une session peut passer de ACTIVE à INACTIVE d'une milliseconde à l'autre durant l'exécution d'une instruction, et il faut donc tomber au bon moment.
Donc soit il faut éviter ce critère, soit répéter plusieurs fois la requête dans V$SESSION pour plus de certitude.

(J'en ai peut-être déjà parlé ici : si on fait par exemple un simple SELECT * sur une grosse table, qui dure plusieurs secondes, on va constater que le statut de la session est INACTIVE 95% du temps, car elle passe son temps essentiellement en échanges sur le réseau, ce qui n'est pas considéré comme ACTIVE).

En revanche, si V$SESSION.SQL_ADDRESS est non nul, cela indique plus fiablement que la session est en train de faire quelque chose, même hors CPU.