Dans la plupart des cas, le regroupement de connexion, les problèmes liés à la connexion "fuites." Votre demande n'a probablement pas fermer ses connexions de base de données correctement et de manière cohérente. Lorsque vous quittez les connexions ouvertes, ils restent bloqués jusqu'à ce que l' .NET garbage collector ferme pour vous en les appelant par leurs Finalize() méthode.
Vous voulez vous assurer que vous êtes vraiment à la fermeture de la connexion. Par exemple, le code suivant provoque une fuite dans le joint, si le code entre .Open et Close déclenche une exception:
SqlConnection myConnection = new SqlConnection(ConnectionString);
myConnection.Open();
// some code
myConnection.Close();
La manière correcte est celle-ci:
SqlConnection myConnection = new SqlConnection(ConnectionString);
try
{
conn.Open();
someCall (myConnection);
}
finally
{
myConnection.Close();
}
ou
using (SqlConnection myConnection = new SqlConnection(ConnectionString))
{
myConnection.Open();
someCall(myConnection);
}
Lorsque votre fonction retourne une connexion à partir d'une méthode de classe, assurez-vous de mettre en cache localement et appeler sa Close méthode. Vous aurez fuite d'une connexion à l'aide de ce code par exemple:
myCommand = new OleDbCommand(SomeUpdateQuery, getConnection());
result = myCommand.ExecuteNonQuery();
myConnection().Close();
La connexion de rentrer du premier appel à getConnection() n'est pas fermé. Au lieu de fermer votre connexion, cette ligne crée une nouvelle et essaie de la fermer.
Si vous utilisez SqlDataReader ou un OleDbDataReader, les fermer. Même si la fermeture de la connexion en elle-même semble faire le tour, à mettre dans les efforts supplémentaires pour fermer votre lecteur de données des objets explicitement lorsque vous les utilisez.
Cet article "Pourquoi une Connexion de Piscine à Débordement?" à partir de MSDN/SQL Magazine explique beaucoup de détails, et suggère des stratégies de débogage:
- Exécutez
sp_who ou sp_who2. Ces procédures stockées du système de retour d'informations de l' sysprocesses système de tableau qui indique le statut et les informations sur tous les processus de travail. En règle générale, vous verrez un processus serveur ID (SPID) par connexion. Si vous avez nommé votre connexion en utilisant le Nom de l'Application argument dans la chaîne de connexion, votre travail connexions sera facile à trouver.
- Utilisation de SQL Server Profiler avec le SQLProfiler
TSQL_Replay modèle pour tracer les connexions ouvertes. Si vous êtes familier avec le Profiler, cette méthode est plus facile que l'interrogation par l'utilisation de sp_who.
- Utilisez l'analyseur de Performances pour Surveiller les piscines et les connexions. Je discuter de cette méthode dans un instant.
- Surveiller les compteurs de performance dans le code. Vous pouvez surveiller l'état de santé de votre pool de connexions et le nombre de connexions établies en utilisant des routines pour extraire les compteurs ou par l'aide de la nouvelle .NET PerformanceCounter contrôles.
