Discussion :

[maikeul]

Bonjour,

Nous avons un job qui, pour résumer, kill les sessions de la veille.
le pb est que j'ai 3 sessions qui restent à l'état KILLED dans V$SESSION.

Comment se fait-il que ces sessions soient toujours visibles ?
Y a-t-il un moyen de les "purger" ?

Merci d'avance.

[SQLpro]

Un KILL sur une session impose un ROLLBACK de la transaction. Cela signifie que tout le travail entamé doit être défait. Oracle va donc jouer le journal "à l'envers" (undo) pour replacer les "images avant" des données en mémoire.
Ceci peut donc prendre du temps, d'autant plus de temps que vous avez beaucoup de données...

Ceci dit, avoir un job qui "KILL" automatiquement des sessions, révèle généralement un grand désordre dans la conception de votre bases de données et de son implémentation... C'est généralement le signe d'une incompréhension du fonctionnement d'un SGBDR, voire d'une incompétence !

la question est donc, comment et pourquoi en êtes vous arrivée là ?

A +

[Waldar]

Sur des bases OLAP c'est assez courant de tuer toutes les sessions utilisateurs en début de soirée pour que les traitements de la nuit ne soient pas impactés par une requête consommatrice (si ce n'est foireuse) qui aurait pu être oubliée par quelqu'un.

Ça garantit que la disponibilité des ressources.

[maikeul]

Un KILL sur une session impose un ROLLBACK de la transaction. Cela signifie que tout le travail entamé doit être défait. Oracle va donc jouer le journal "à l'envers" (undo) pour replacer les "images avant" des données en mémoire.
Ceci peut donc prendre du temps, d'autant plus de temps que vous avez beaucoup de données...

Ceci dit, avoir un job qui "KILL" automatiquement des sessions, révèle généralement un grand désordre dans la conception de votre bases de données et de son implémentation... C'est généralement le signe d'une incompréhension du fonctionnement d'un SGBDR, voire d'une incompétence !

la question est donc, comment et pourquoi en êtes vous arrivée là ?

A +

Salut,

je voulais juste savoir s'il était possible de forcer le kill.

... grand désordre dans la conception ... incompréhension du fonctionnement d'un SGBDR ... incompétence ... c'est dur !!!

pour en revenir aux sessions à killer, nous avons donc un serveur applicatif qui se connecte à notre BDD.
Le fait est qu'il nous arrive de devoir killer des sessions (par exemple utilisateur qui ne quitte pas proprement l'appli ...)


Nous sommes une équipe de 5 personnes, et on prend tout en charge (maintenance, projets, installation serveur, haute dispo, etc...).
on fait donc en fonction de nos connaissances et/ou compétences, car on en a quand même

[Pomalaix]

Pour essayer d'éviter les cas où une session d'un utilisateur qui ne s'est pas déconnecté proprement persiste en base, vous pouvez ajouter dans le sqlnet.ora du serveur le paramètre : SQLNET.EXPIRE_TIME=10, plus un petit redémarrage du listener.
Ceci est censé tuer les sessions orphelines qui ne répondent plus depuis 10 minutes (mais ne résoudra probablement pas le cas des anciennes sessions déjà dans cet état).

Il peut par ailleurs y avoir des circonstances particulières dans lesquelles effectivement des sessions en statut KILLED persistent anormalement pendant des heures, voire des jours.
On doit alors les tuer explicitement au niveau de l'OS pour réussir à libérer les ressources.

Sous Linux par exemple, il faut récupérer le SPID dans V$PROCESS et faire un kill -9 de ce processus.

Code :

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

1
2
3
4
SELECT    p.program, p.spid, s.saddr, s.sid, s.serial#, s.username,    s.osuser, s.machine, s.program, s.logon_time, s.status 
FROM v$session s, v$process p
WHERE s.paddr = p.addr
AND s.sid =&SID;

[Ikebukuro]

... grand désordre dans la conception ... incompréhension du fonctionnement d'un SGBDR ... incompétence ... c'est dur !!!

Laisse, il est toujours comme ça, certaines personnes ont un mauvais relationnel.
En revanche ce que dit Pomalaix est plus intéressant :-)

[a.presles]

pour la defense le mikeul. Je pense aussi qu'il y a bien plus de gain a faire des application bien conçu qu'a tenter de recoller les morceaux a posteriori. Mais souvent dans notre métier nous subissons de mauvais choix en bout de chaine. Arrêter les applications avant de tenter de killer les sessions est un début. Mais il faudrait étudier chaque requete qui doit être killée car il faudrait les éviter en amon. Elle ont probablement consomées beaucoup de ressource tout au long de la journée.