Discussion :

[LandGreen]

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 :

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

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

[LandGreen]

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

[JeanYvette]

Bonjour,

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

Code :

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

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 :

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

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

Puis killez votre session :

Code :

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

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

[Pomalaix]

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.