Le nombre maximal de connexions entre les versions et éditions de SQL Server est de 32 767.
Vous pouvez déterminer le nombre de connexions que SQL Server possède actuellement en consultant:
SELECT ConnectionStatus = CASE WHEN dec.most_recent_sql_handle = 0x0
THEN 'Unused'
ELSE 'Used'
END
, CASE WHEN des.status = 'Sleeping'
THEN 'sleeping'
ELSE 'Not Sleeping'
END
, ConnectionCount = COUNT(1)
FROM sys.dm_exec_connections dec
INNER JOIN sys.dm_exec_sessions des ON dec.session_id = des.session_id
GROUP BY CASE WHEN des.status = 'Sleeping'
THEN 'sleeping'
ELSE 'Not Sleeping'
END
, CASE WHEN dec.most_recent_sql_handle = 0x0
THEN 'Unused'
ELSE 'Used'
END;
Si le rapport entre les connexions utilisées et inutilisées de la requête ci-dessus est préoccupant, il est probable que le regroupement de connexions est activé par les applications clientes connectées au serveur, et ces connexions ne sont pas utilisées efficacement. Vous souhaiterez peut-être que les développeurs modifient la chaîne de connexion de ces applications pour limiter la taille du pool de connexions et s’assurer qu’ils éliminent correctement les connexions. Si les connexions ne sont pas supprimées correctement, elles resteront ouvertes tant que l'application cliente s'exécutera.
Si vous vous sentez particulièrement enragé et que vous devez vous débarrasser de toutes les connexions qui n'ont rien effectué récemment (indépendamment du fait qu'elles effectuent actuellement un travail), vous pouvez exécuter le code suivant, qui générera une liste de sessions qui peut être tué. Vous devez copier-coller les commandes générées dans une nouvelle fenêtre SSMS pour exécuter réellement les commandes. Je recommanderais également d'avoir votre curriculum vitae à jour au cas où .
DECLARE @cmd NVARCHAR(MAX);
SET @cmd = '';
SELECT @cmd = @cmd +
CASE WHEN @cmd = '' THEN '' ELSE CHAR(13) + CHAR(10) END
+ 'KILL ' + CONVERT(VARCHAR(MAX), dec.session_id) + ';'
FROM sys.dm_exec_connections dec
WHERE dec.most_recent_sql_handle = 0x0;
PRINT @cmd;
Il est possible de mettre à l'échelle le nombre de connexions de manière linéaire au-delà de 32 767 en partageant les données sur plusieurs nœuds SQL Server. Cependant, à mon avis, l'utilisation du sharding comme moyen de contourner la limite du nombre de connexions est similaire à l'utilisation d'une bombe atomique pour tuer une araignée. Il va tuer l'araignée, mais vous ne peut avoir de plus gros problèmes à la fin de la journée. Sans oublier qu'il est assez difficile de construire une bombe atomique, sans parler de mettre en œuvre le sharding correctement.
