Discussion :

[davy.g]

Bonjour,

J'ai des sessions inactives depuis 3, 4 jours et j'aimerais les killer !
Seulement, je n'ai accès qu'à SQL*Plus ou Toad ...
Est-ce que je peux le faire via ces outils ?

Merci.

[guigui_cwoco]

Oui
Via SQL Plus:

Tu récupère le SID et le SERIAL# de la session a tuer
(a partir de la vue v$session)

ensuite :

Code :

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

1
2
 
alter system kill session 'SID', 'SERIAL#';

[LeoAnderson]

Seulement, je n'ai accès qu'à SQL*Plus ou Toad ...
Est-ce que je peux le faire via ces outils ?

On peut déjà quasiment TOUT faire sous SQL*Plus, alor si en plus, vous avez une interface graphique type Toad...

Le problème après est plus une question de syntaxe et privilèges qu'autre chose !

[LeoAnderson]

Attention cependant : une session inactive n'est pas gênante en soi, il n'y a aucune raison pour vouloir les killer !

[orafrance]

sauf si elle tient un lock parce qu'elle même est lockée

[LeoAnderson]

ou sauf si elle empêche l'ouverture d'autre session (restriction du profil), ou sauf si....

mais en général, pas besoin de les killer !

mon but est juste d'éviter qu'un lecteur peu avertit déduise à tort qu'une session inactive doit être killée !

[orafrance]

surtout si c'est une background

[davy.g]

Le problème, c'est que la semaine dernière il y avait environ 50 sessions inactives sur la base.
Toute nouvelle connexion était impossible, car un paramètre du fichier d'init bloquait la connexion ( nombre maxi de connexion atteint )...

[orafrance]

faudrait peut-être se demander pourquoi ces sessions ne sont pas déconnectées avec de monter une usine à gaz non ?

[remi4444]

Je partage tout à fait cette mise en garde, dans une base correctetement optimisée, une session doit passer 99% de son temps inactive, ce n'est donc pas une critère d'anomalie. Dans Toad on peu voir facilement la machine connectée, le user de cette machine et meme le programme. Il est donc assez facile de remonter la piste... la meilleure façons de killer une session est quand meme de déconnecter proprement le client

[pifor]

faudrait peut-être se demander pourquoi ces sessions ne sont pas déconnectées avec de monter une usine à gaz non ?

Sans doute parce tout le monde préfère garder une connexion ouverte dans l'application qui elle-même garde une connexion à la base tant que l'utilisateur ne se déconnecte pas.

Je partage tout à fait cette mise en garde, dans une base correctetement optimisée, une session doit passer 99% de son temps inactive, ce n'est donc pas une critère d'anomalie.

Je ne suis pas sûr que c'est vraiment un critère d'optimisation: il peut parfaitement y avoir des sessions beaucoup plus actives du type message applicatif en continu (interfaces) et sur les applications décisionnelles, on peut facilement avoir des sessions beaucoup plus actives car les requêtes peuvent être beaucoup plus longues sans qu'il y ait vraiment de problème d'optimisation.

[remi4444]

Je suis d'accord, mon propos était un résumé brutal. Je voulais juste rectifier un éventuel mal-entendu qui ferait interpréter des sessions inactives comme un signe de mauvais fonctionnement. Au contraire, et de manière générale, il faut s'inquiéter quand beaucoup de sessions restent actives plutot que l'inverse...

[remi4444]

sauf si elle tient un lock parce qu'elle même est lockée

Elle serait notée comme ACTIVE dans se cas non ?