Discussion :

[venegan]

Je voudrais savoir s il existe une commande pour voir les update en cours et de les killer car j ai lancé une requete (update) qui répond pas..

je suis sous Oracle 8i.

Merci.

[nuke_y]

Si tu as l'OEM (Oracle Entreprise Manager) tu peux voir les sessions en cours, voir le code SQL en cours et killer la session que tu veux.

Sinon en ligne de commande c'est possible aussi mais je n'ai plus la méthode en tête... Je me demande si il ne faut pas aller zieuter dans SQL_TEXT pour y trouver ton code SQL et ensuite killer la session qui y correspond.

[LeoAnderson]

IL faut commencer par identifier la session :

Code :

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

1
2
3
SELECT sid,serial#,osuser,program
  FROM   v$session s
 WHERE Type = 'USER';

ensuite, en ayant le privilège nécessaire :

Code :

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

ALTER SYSTEM KILL SESSION '<sid>,<serial#>';

[nuke_y]

Certes Leo mais la question est comment identifier la session. Imaginons qu'un utilisateur distant envoie 3 requêtes depuis 3 fenêtres SQL*Plus. Comment identifier sans OEM celle qui est en train de faire un UPDATE ?

[Jaouad]

Bonjour ,
Grace à la jointure entre v$session et v$sqlarea on peut identifier la requête :

Code :

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

v$session.sql_address = v$sqlarea.address

[aline]

et la colonne command de v$session nous donne le type de commande.
Pour un update, c'est 6.

[nuke_y]

Donc on aura quelquechose comme ça :

Code :

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

1
2
3
SELECT sid,serial#,osuser,program
  FROM   v$session s
 WHERE Type = 'USER' and command=6;

pour trouver la session qui fait un update ou bien quelquechose comme ça

Code :

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

1
2
3
4
SELECT sid,serial#,osuser,program,command, sql_text
  FROM   v$session, v$sqlarea
 WHERE Type = 'USER'
 AND v$session.sql_address = v$sqlarea.address;

pour trouver celle qu'on veut ?

[Jaouad]

Tout à fait ,
tu pourrais même si tu étais perfectionniste faire un replace ou decode sur le type de commande et le remplacer par quelquechose de plus explicite.
Du style :

Code :

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

1
2
3
4
5
 
SELECT sid,serial#,osuser,program,DECODE(command,'3','Select','6','Update','7','Delete','2','Insert','85','Truncate','0','Pl/Sql',command), sql_text 
  FROM   v$session, v$sqlarea 
 WHERE TYPE = 'USER' 
 AND v$session.sql_address = v$sqlarea.address;

Aprés à toi de chercher les ordres SQL Que je n'ai pas mis ...

[aline]

Tout à fait ,
tu pourrais même si tu étais perfectionniste faire un replace ou decode sur le type de commande et le remplacer par quelquechose de plus explicite.
Du style :

Code :

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

1
2
3
4
5
 
SELECT sid,serial#,osuser,program,DECODE(command,'3','Select','6','Update','7','Delete','2','Insert','85','Truncate','0','Pl/Sql',command), sql_text 
  FROM   v$session, v$sqlarea 
 WHERE TYPE = 'USER' 
 AND v$session.sql_address = v$sqlarea.address;

Aprés à toi de chercher les ordres SQL Que je n'ai pas mis ...

Bonjour Jaouad,
Que veux dire '0','Pl/Sql'' dans ton decode?
le code 0 n'est pas renseigné dans les specs de la vue v$session et je me suis toujours demandé sa signification.

[Jaouad]

c 'est pas reéllement du SQL , mais le 0 à mon sens sont des ordes récursifs ou systéme si tu préfère.
D'ailleurs en régle génèrale c est SYS qui les lance

[venegan]

Merci pour vos réponses, le seul hic c est que il ne connait pas la (les) table(s) v$session. Est ce que je dois etre un user special ?

[Nick_Holmes]

Non, pas besoin d'être un user spécial, mais il faut avoir les droits pour lire ces tables systèmes. De la même façon, il faut avoir le droit d'executer les ordres de type "ALTER SYSTEM". D'un point de vue global sur la base, seul un utilisateur système ou administrateur (donc de haut niveau d'habilitation) peut les donner à un autre utilisateur.

@+,
NicK.

[xavi]

Bonjour à tous,

Suite à des déconvenues récentes, je déconseille de killer une session qui est en train de faire un update car Oracle doit ensuite rollbacker en tâche de fond, ce qui est très très long. Les lignes restent bien sûr lockées pendant toute l'opération.

Si un update malheureux a été lancé (ex update sur une grosse table sans clause where) mieux vaut attendre qu'il se termine et faire un rollback explicite que le killer : c'est pire que pire.