SQL Server 2014 et Sharepoint 2013

Bonjour,

J'ai un serveur sur lequel des bases sharepoint sont installées.
Il se trouve que j'ai plus de "800 connected users". quand j'analyse avec la requête suivante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SELECT db_name(dbid) as DBName, status,hostname, spid, COUNT(dbid) as NumberOfConnections, loginame FROM sys.sysprocesses WHERE dbid > 0 GROUP BY dbid, loginame,status,hostname, spid ;

---

Je vois que ce qui fait augmenter le nombre de user c'est les sessions en "sleeping" d'un user.
Comment faire pour faire du nettoyage afin que ces sessions ne trainent pas ?

Je vous remercie de votre aide.

Cordialement,
jeune DBA

À moins que vous ne soyez sous SQL Server 2000 ou version antérieure cette requête est fausse !!!!

En effet la table sys.sysprocesses est (je cite Microsoft) :
"
This SQL Server 2000 system table is included as a view for backward compatibility. We recommend that you use the current SQL Server system views instead. To find the equivalent system view or views, see Mapping System Tables to System Views (Transact-SQL). This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
"

Apprenez à travailler avec SQL Server et vous servir des vues systèmes et DMV adéquates comme :
sys.dm_exec_sessions, sys.dm_exec_connections, sys.dm_exec_requests
Notre livre peut vous y aider :
Pièce jointe 222149

A +

Bonjour,

Merci pour ce rappel.
J'ai utilisé la commande approprié cette fois-ci:

Code:

---

1 2 3

select host_name,program_name,login_name,status from sys.dm_exec_sessions where is_user_process=1;

---

j'obtiens le même login avec un status "sleeping" pour le même program_name ".Net SqlClient Data Provider".

Peut-on killer ces sessions inactives et de quelle maniere.
Sinon quelle solution vous me conseillez pour reduire ce nombre important de session en sleeping.

Merci de votre aide.

Citation:

---

Envoyé par jouwa

Bonjour,

Merci pour ce rappel.
J'ai utilisé la commande approprié cette fois-ci:

select host_name,program_name,login_name,status
from sys.dm_exec_sessions
where is_user_process=1;

j'obtiens le même login avec un status "sleeping" pour le même program_name ".Net SqlClient Data Provider".

Peut-on killer ces sessions inactives et de quelle maniere.
Sinon quelle solution vous me conseillez pour reduire ce nombre important de session en sleeping.

Merci de votre aide.

---

La question n'est pas de savoir s'il faut les tuer... La question est de savoir si cela vous gêne... Si oui, alors il va falloir traiter le mal par la racine. Si non, laissez tomber !

A +

A mon sens, il est genant puisque cela devient compliquer de definir une valeur seuil d'alerte.
D'autres bases qui ne sont pas lié a sharepoint n'ont pas ce comportement.

Merci.

Citation:

---

Envoyé par jouwa

A mon sens, il est genant....

---

Quelle métrique avez vous utilisé pour affirmer cela ?

A +

Nous limitons le paramètre "nbre max de connexions simultanés" à 500 , mais actuellement nous le mettons en illimité à cause de cela.

A+

Citation:

---

Envoyé par jouwa

Nous limitons le paramètre "nbre max de connexions simultanés" à 500 , mais actuellement nous le mettons en illimité à cause de cela.

A+

---

Pourquoi limiter le nombre de connexions max à 500 ? Quelle justification pour cela?

SQLPro a raison, il faut savoir quel programme, module etc ... génère autant de connexions et savoir si comportement normal. Tuer une session sans vraiment savoir ce que cela implique reste dangereux.
Pour ma part, je n'ai jamais vu un tel comportement même avec les bases de données SharePoint. Il va donc falloir investiguer.

++

Citation:

---

Envoyé par jouwa

Nous limitons le paramètre "nbre max de connexions simultanés" à 500 , mais actuellement nous le mettons en illimité à cause de cela.

A+

---

Autrement dit, et à titre de comparaison, vous devez satisfaire 800 clients qui veulent acheter vos produits dans votre boutique et vous décidez autoritairement de vous limiter à n'en servir que 500...
Seriez vous dans une entreprise communiste ??? ;-)

SQL Server est capable de servir 32000 clients en parallèle, à condition que le hardware suive. Je n'ai jamais vu au cours de mes nombreux audits l'intérêt de limiter le nombre de connexion, et en pratique, cela n'a pas de sens...

Essayez de voir à l'aide des DMV sys.dm_exec_session, sys.dm_exec_connections et éventuellement sys.dm_exec_requeqts quelles machines, quelles applications se connectent.

A +