Contamos con tu ayuda para compartir nuestras reseñas en referencia a las ciencias de la computación.
Solución:
sp_reset_connection es un artefacto del uso de la agrupación de conexiones. Y lo que crees que estás viendo no es lo que realmente está sucediendo.
La agrupación de conexiones es una característica de la biblioteca del cliente más que de SQL Server. El cliente proporciona la mayor parte de la funcionalidad, mientras que el propio SQL Server proporciona principalmente sp_reset_connection. Cuando se usa la agrupación de conexiones, el controlador del cliente no cierra la conexión física a SQL Server cuando el código de la aplicación llama al método “cerrar conexión”. En su lugar, el controlador mantiene abierta la conexión y la vinculará a la siguiente solicitud de “conexión abierta” que utilice exactamente la misma conexión. string (y desde la misma cuenta de Windows, si usa una Conexión de confianza/Seguridad integrada). Ahora, debido a que la conexión nunca se cerró, SQL Server solo sabe que el cliente mantiene abierta la conexión, pero no sabe por qué. Y debido a que la conexión permanece abierta, la sesión aún existe con los recursos y configuraciones que estaban en su lugar desde el último comando/lote ejecutado. Esta es la razón por la que las tablas temporales creadas en el ámbito principal (es decir, no en un procedimiento almacenado) seguirán existiendo (para obtener más información, consulte: Sesiones, Objetos temporales y Afterlife), y la transacción abierta permanecerá abierta.
SQL Server no sabe que se está utilizando la agrupación de conexiones hasta que se envía el siguiente comando/lote, momento en el que se ejecuta sp_reset_connection. Está sp_reset_connection que limpia el estado anterior de la sesión para que sea como una sesión nueva, que es lo que espera el código del cliente (con algunos elementos menores que no se limpian/reinician).
Por supuesto, esa descripción se basa en los controladores más nuevos. Como dice la cita en la pregunta, los conductores mayores enviaron una solicitud por separado para sp_reset_connection. El hecho de que esté viendo sesiones que no tienen una solicitud en ejecución actualmente (es decir, la CPU está NULL) se espera cuando se utiliza la agrupación de conexiones. Lo que no es típico es ver sp_reset_connection a través de DBCC INPUTBUFFER. Esto no es típico ya que los controladores más nuevos solicitan sp_reset_connection al enviar el primer lote/comando al volver a conectar, por lo que nunca vería sp_reset_connection ya que nunca será lo último en ejecutarse (aunque puede verlo usando SQL Server Profiler o Extended Events). Pero, si lo estás viendo usando DBCC INPUTBUFFER (que continuará mostrando el último comando / lote ejecutado, incluso después de que se complete el lote), entonces eso parecería coincidir con el comportamiento de los controladores más antiguos (suponiendo que los discos más antiguos, porque no envían una bandera junto con el siguiente comando / lote, están solicitando sp_reset_connection a las solicitudes de “conexión cercana”).
De todas formas, sp_reset_connection no se está ejecutando actualmente. Y la razón por la que las solicitudes son todas para el master Lo más probable es que DB haga master siendo la base de datos predeterminada para los inicios de sesión que se utilizan.
Si no hay problemas de rendimiento, probablemente pueda ignorar lo que está viendo. Consulte sp_reset_connection: uso de la tarifa (no peleen por las uvas) por Bob Dorr, ingeniero principal de escalamiento de SQL Server, se destaca a continuación:
Bajo las cubiertas, SQL Server usa la lógica sp_reset_connection para ‘restablecer’ el estado de conexión para SQL Server, que es más rápido que establecer una conexión completamente nueva. Los controladores más antiguos envían la llamada al procedimiento como un TDS separado de ida y vuelta al servidor SQL. Los controladores de cliente más nuevos agregan un bit de indicador junto con el siguiente comando, evitando el viaje de ida y vuelta adicional de la red.
Las discusiones rápidamente se convierten en: “¿Cuál es una tasa razonable de sp_reset_connections en mi servidor?” Como de costumbre, la respuesta es siempre depende.
No existe una regla estricta y rápida, pero al usar el monitor de rendimiento puede comparar rápidamente la tasa general de lotes con las tasas de conexión de restablecimiento. Cuando veo que la tasa comienza a subir por encima del 15%, es una buena indicación de que es posible que la aplicación deba revisarse y ajustarse un poco.
Con todo esto dicho, debe tener cuidado de no extender demasiado la relación. Mantener la conexión cuando no se necesita aumentará el número total de conexiones utilizando más sobrecarga del cliente y de SQL Server. Debe encontrar el punto óptimo que optimice los recursos del cliente y de SQL Server y maximice las capacidades de rendimiento de la aplicación.
También puede considerar cambios recientes que reducen la sobrecarga de sp_reset_connection en SQL Server.
https://support.microsoft.com/kb/2926217
Dan Guzmán también comentó:
sp_reset_connectionnormalmente no toma más de un par de milisegundos (generalmente microsegundos). La excepción es cuando se necesita una reversión porque la conexión se devolvió al grupo con una transacción abierta. Sospecho cuando corresDBCC INPUTBUFFERentonces es el último comando que se ejecutó, no el que estaba tardando mucho.
Aquí puedes ver las comentarios y valoraciones de los usuarios
Si sostienes algún impasse y capacidad de desarrollar nuestro reseña puedes añadir una explicación y con deseo lo ojearemos.