Usando SQL Profiler en una base de datos que está en producción

Como desarrollador, uso SQL Profiler con bastante frecuencia. Es una buena herramienta de depuración, tanto para rastrear lo que está haciendo mi código como para analizar problemas de rendimiento.

Pero siempre lo he usado en mi entorno de desarrollo , y de forma muy controlada.

• Iniciar mi aplicación y ponerla en un estado específico
• Iniciar un seguimiento en el generador de perfiles
• Realizar una secuencia específica de acciones en mi aplicación
• Pare el rastro y examine los resultados.

¿Se puede usar SQL Profiler prácticamente en un entorno en producción?

Mi primera preocupación es que degradaría el rendimiento.

Mi segunda preocupación es que, debido a que está en producción, no estás activando las acciones interesantes en sí. Tendría que dejar el generador de perfiles en funcionamiento durante un período prolongado y luego analizar los resultados. ¿El conjunto de resultados sería demasiado difícil de manejar? (Ocupando demasiado espacio en disco y siendo demasiado difícil de consultar).

¿Alguien usa el SQL Profiler en producción?

Usar Sql Server Profiler (herramienta GUI) para rastrear un servidor de producción no es una buena idea. Pero depende de la carga. Utilice el rastreo sql del lado del servidor (consulte los procedimientos sp_trace_XXX ) en lugar de hacerlo. También he encontrado artículos:

Impacto en el rendimiento: seguimiento del generador de perfiles frente al seguimiento de SQL del lado del servidor ,

Automatizar el seguimiento del lado del servidor en SQL Server

Evite causar problemas con Profiler

tal vez sea de interés y útil.

Libro en línea dice:

• Ejecute Profiler de forma remota en lugar de directamente en el servidor
• Evite incluir eventos que ocurren con frecuencia (por ejemplo, bloqueo: adquirido) a menos que sea absolutamente necesario
• Incluir solo clases de eventos necesarias
• Especificar filtros limitantes para reducir el número de eventos.
• Evite datos redundantes (por ejemplo, SQL: BatchStarting y SQL: BatchCompleted)
• Evite ejecutar trazas grandes con Profiler; considere un rastreo SQL del lado del servidor
• Limite el tamaño del archivo de rastreo del lado del servidor y administre el uso del espacio

Yo uso SQL Profiler contra la producción todo el tiempo. Cuando se hace correctamente (filtrando para recuperar una cantidad muy pequeña de datos) contra un servidor, el riesgo es mínimo. Trazar todo sería inútil.

1. Sí, el acto de monitoreo requerirá algunos recursos. Ejecutarlo en un servidor sobrecargado podría matarlo.

2. Realmente monitoreará la carga de la vida real: sus acciones podrían perderse en el ruido de esta carga.

Lo ejecutamos en producción a veces. Principalmente con un filtro de texto para código específico, o con filtros de CPU / duración para atrapar consultas más largas. Y no intentamos capturar planes de ejecución XML o alguna falta de este tipo

La clave es saber lo que está buscando: no tendemos a dejarlo funcionando y atraparlo todo.

En este caso, si desea ver los resultados de algunas acciones, ¿puede hacerlo fuera de horario?

Profiler siempre presentará un impacto en el rendimiento.

Si está utilizando SQL Server 2008R2 +, puede usar eventos extendidos. Esto proporciona gran parte de la información que ve en el generador de perfiles con una fracción del impacto en el rendimiento.

Introducción de libros en línea http://technet.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

Esta característica recibió una gran actualización en SQL Server 2012 que ahora incluye una GUI en SSMS.