Discussion :

[dream_rachid]

Vous pouvez essayer la requête ci-dessous, ceci pourrait vous aider à fermer toutes les connexions de couchage qui sont âgés de plus de 60 min.

Toutefois, la suggestion est de fermer les connexions des utilisateurs du côté de l'application elle-même au lieu du côté de SQL Server.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
Code Snippet
DECLARE @v_spid INT
DECLARE Users CURSOR
FAST_FORWARD FOR
SELECT SPID
FROM master.dbo.sysprocesses (NOLOCK)
WHERE spid>50 
AND status='sleeping'
AND DATEDIFF(mi,last_batch,GETDATE())>=60 --Check sleeping connections that exists before 60 min..
AND spid<>@@spid
OPEN Users
FETCH NEXT FROM Users INTO @v_spid
WHILE (@@FETCH_STATUS=0)
BEGIN
PRINT 'KILLing '+CONVERT(VARCHAR,@v_spid)+'...'
EXEC('KILL '+@v_spid)
FETCH NEXT FROM Users INTO @v_spid
END
CLOSE Users
DEALLOCATE Users

[elsuket]

Bonjour,

Je ne prendrai pas cette requête pour plusieurs raisons :

- tuer des connexions est assez dangereux, et si une connexion n'est pas active, il est fort peu probable qu'elle consomme des ressources.
C'est donc bien d'avoir montré qu'il est préférable de fermer les connexions côté application.

- la table système master.dbo.sysprocesses est obsolète.
Il n'est pas encore à dire qu'elle peut retourner des informations incorrectes, mais il est très probable que vous ne puissiez pas l'utiliser sur les prochaines versions de SQL Server.

- la requête utilise un curseur et je n'aime pas les curseurs.
Il ne s'agit pas là d'une lubie, mais en plus d'être moches et consommateurs de ressources, il sont lents parce qu'ils ne sont pas ensemblistes, ce que SQL est.

J'aurais donc écrit la requête comme suit :

Code :

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

1
2
3
4
5
6
DECLARE @sql varchar(max)
SELECT    @sql = CASE WHEN @sql IS NULL THEN '' ELSE @sql + 'KILL ' + CAST(session_id AS varchar(3)) + '; ' END
FROM    sys.dm_exec_sessions
WHERE    last_request_end_time < DATEADD(minute, -60, GETDATE())
 
EXEC (@sql)

Même si je ne m'en servirai jamais

@++

[SQLpro]

Oui, c'est parfaitement idiot de tuer des connexions inactives qui consomment rien et donc de devoir recréer tout l'environnement d'une connexion à chaque fois ce qui pénalisera très fortement les applications. Sans compter qu'en client lourd, le pauvre utilisateur perdra ses modif en cours et attendra éternellement une reconnexion !!!!

Posons une analogie. Imaginons que vous construisez un parking. Il est plein, mais il y a encore de la surface non structurée. Une voiture arrive. Vous vous mettez à lisser le béton, peindre le sol et délimiter la place. La voiture repart, vous prenez votre marteau piqueur afin de détruire votre travail... Au moins avec une telle stratégie, c'est le secteur du bâtiment qui va y gagner !!!

Encore une preuve de la prolétarisation de l'informatique : je poste un code pour épater la galerie sans voir que les conséquence en seront catastrophique....

Commencez donc par apprendre comment fonctionne un SGBDR et ce que sont les pools de connexion par exemple afin d'éviter de polluer Internet avec de telles inepties....

On va encore dire que je tape fort... Mais devant la bêtise de la chose, je reste pantois !

A +

[dream_rachid]

Bonjour

je respectes vos avis , néanmoins, je pense que cette requête pourra être utile dans certain cas et j'ai déjà précisé deux conditions :

- connexion inactive depuis 60 Mn (on pourra étaler cette période suivant le besoin)
- il est préférable qu'on effectue cette opération coté applicatif : comment faire si ce dernier ne le prends pas en charge

SQLPRO : j'étais très motivé de participer dans ce forum en espérant échanger des différents idées mais en lisant vos commentaires ... vraiment ça donne une impression négative sur les modérateurs

je suis très désolé si , en postulant une requête ,j'ai commis une "bêtise"

[elsuket]

comment faire si ce dernier ne le prends pas en charge

Étant extrêmement loin d'être un expert en développement d'applications, je me doute que si vous ouvrez une connexion à une base de données, il doit exister une méthode pour la fermer );

SQLPro tape effectivement fort, mais il ne le fait pas pour vous démotiver de participer. C'est cela aussi, modérer.

[WOLO Laurent]

Bonjour

je respectes vos avis , néanmoins, je pense que cette requête pourra être utile dans certain cas et j'ai déjà précisé deux conditions :

- connexion inactive depuis 60 Mn (on pourra étaler cette période suivant le besoin)
- il est préférable qu'on effectue cette opération coté applicatif : comment faire si ce dernier ne le prends pas en charge

SQLPRO : j'étais très motivé de participer dans ce forum en espérant échanger des différents idées mais en lisant vos commentaires ... vraiment ça donne une impression négative sur les modérateurs

je suis très désolé si , en postulant une requête ,j'ai commis une "bêtise"

Tu ne gagneras rien en tuons les connexions inactives d'ailleurs les connexions doivent être souvent inactives lors que vous avez réussis votre couche d'accèss aux données le cas contraire, il faut revoir votre stratégie car il y'a beaucoups de conséquences à savoir :
1- la montée en charge que vos applications ne vont pas supporter;
2- les lenteurs liées aux connexions ;
3- Les transactions bloquantes ;

Et j'en passe,

Non, oubliez les anciennes façons de penser, et adopter les bests practices.
Espérant vous relire très bientôt.

[SQLpro]

je suis très désolé si , en postulant une requête ,j'ai commis une "bêtise"

Ce n'est pas en postant (et non pas postulant) une requête que vous avez commis une bêtise. C'est le contenu qui est en cause. Ce n'est pas non plus une bêtise à proprement parler, mais plutôt quelque chose de totalement incongru que vous pensez positif par manque de culture sur le sujet !
Si l'on a justement inventé le pooling de connexion c'est pour éviter des pertes de performance importante. Or justement vous présenter ceci comme étant un avancée...
Quels sont les tests que vous avez effectué pour affirmer cela ?

A +