¿Cómo puedo resolver un problema de grupo de conexiones entre ASP.NET y SQL Server?

Puede darse el caso de que halles algún fallo con tu código o proyecto, recuerda probar siempre en un entorno de testing antes aplicar el código al proyecto final.

Solución:

En la mayoría de los casos, los problemas de agrupación de conexiones están relacionados con fugas de conexión. Es probable que su aplicación no cierre sus conexiones de base de datos de manera correcta y consistente. Cuando deja abiertas las conexiones, permanecen bloqueadas hasta que el recolector de elementos no utilizados de .NET las cierra llamando a su Finalize() método.

Quiere asegurarse de que está realmente cerrando la conexión. Por ejemplo, el siguiente código provocará una fuga de conexión, si el código entre .Open y Close lanza una excepción:

var connection = new SqlConnection(connectionString);

connection.Open();
// some code
connection.Close();                

La forma correcta sería esta:

var connection = new SqlConnection(ConnectionString);

try

     connection.Open();
     someCall (connection);

finally

     connection.Close();                

o

using (SqlConnection connection = new SqlConnection(connectionString))

     connection.Open();
     someCall(connection);

Cuando su función devuelve una conexión de un método de clase asegúrese de almacenarlo en caché localmente y llame a su Close método. Perderás una conexión usando este código, por ejemplo:

var command = new OleDbCommand(someUpdateQuery, getConnection());

result = command.ExecuteNonQuery();
connection().Close(); 

La conexión volvió de la primera llamada a getConnection() no se está cerrando. En lugar de cerrar su conexión, esta línea crea una nueva e intenta cerrarla.

Si utiliza SqlDataReader o un OleDbDataReader, cerrarlos. Aunque cerrar la conexión en sí parece funcionar, haga un esfuerzo adicional para cerrar los objetos del lector de datos explícitamente cuando los use.

---

Este artículo “¿Por qué se desborda un grupo de conexiones?” de MSDN/SQL Magazine explica muchos detalles y sugiere algunas estrategias de depuración:

• Correr sp_who o sp_who2. Estos procedimientos almacenados del sistema devuelven información del sysprocesses tabla del sistema que muestra el estado y la información sobre todos los procesos de trabajo. Por lo general, verá un ID de proceso de servidor (SPID) por conexión. Si nombró su conexión usando el argumento Nombre de la aplicación en la conexión stringsus conexiones de trabajo serán fáciles de encontrar.
• Usar SQL Server Profiler con SQLProfiler TSQL_Replay plantilla para rastrear conexiones abiertas. Si está familiarizado con Profiler, este método es más fácil que sondear usando sp_who.
• Utilice el Monitor de rendimiento para monitorear los grupos y las conexiones. Hablo de este método en un momento.
• Supervise los contadores de rendimiento en el código. Puede monitorear el estado de su grupo de conexiones y la cantidad de conexiones establecidas mediante el uso de rutinas para extraer los contadores o mediante el uso de los nuevos controles .NET PerformanceCounter.

Al instalar .NET Framework v4.6.1, nuestras conexiones a una base de datos remota comenzaron a agotarse inmediatamente debido a este cambio.

Para arreglar simplemente agregue el parámetro TransparentNetworkIPResolution en la conexión string y configúralo en false:

Server=myServerName;Database=myDataBase;Trusted_Connection=True;TransparentNetworkIPResolution=Falso

A menos que su uso haya aumentado mucho, parece poco probable que solo haya una acumulación de trabajo. En mi opinión, la opción más probable es que algo esté usando conexiones y no las libere rápidamente. Eres tú Por supuesto Tu estas usando using ¿en todos los casos? ¿O (a través de cualquier mecanismo) liberando las conexiones?

Si sostienes algún recelo y disposición de arreglar nuestro enunciado eres capaz de añadir un exégesis y con deseo lo observaremos.

---

---

Utiliza Nuestro Buscador