Reducción de la sobrecarga de un seguimiento SQL con filtros

Question

Tenemos un servidor SQL 2000 que tiene trabajos muy variados que se ejecutan en diferentes momentos del día o incluso diferentes días del mes. Normalmente, solo usamos el generador de perfiles SQL para ejecutar trazas durante períodos de tiempo muy cortos para la resolución de problemas de rendimiento, pero en este caso, eso realmente no me daría una buena idea general de los tipos de consultas que se ejecutan contra la base de datos en el curso de un día o semana o mes.

¿Cómo puedo minimizar la sobrecarga de rendimiento de una traza de SQL de larga ejecución? Ya sé que:

• Ejecute el seguimiento del lado del servidor (sp_ create_trace), en lugar de usar la interfaz de usuario del Analizador de SQL.
• Rastrear en un archivo, y no en una tabla de base de datos (lo que agregaría una sobrecarga adicional al servidor de BD).

Mi pregunta es acerca de los filtros. Si agrego un filtro solo a las consultas de registro que se ejecutan durante más de cierta duración o que se lee, todavía tiene que examinar toda la actividad en el servidor para decidir si necesita iniciar sesión, ¿no? Entonces, incluso con ese filtro, ¿el seguimiento va a crear un nivel inaceptable de sobrecarga para un servidor que ya se encuentra al borde de un rendimiento inaceptable?

Answer 1

me encontré con un artículo que realmente mide el impacto en el rendimiento de una sesión del Analizador de SQL contra una traza de servidor:

http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx

Esto era realmente mi pregunta subyacente, cómo asegurarme de no empantanar mi servidor de producción durante un rastreo. Parece que si lo haces correctamente, hay una sobrecarga mínima.

Answer 2

La adición de filtros minimiza la sobrecarga de la recopilación de eventos y también evita que el servidor registre entradas de transacciones que no necesita.

En cuanto a si la traza creará un nivel inaceptable de sobrecarga, solo tendrá que probarla y detenerla si hay quejas adicionales. Sin embargo, seguir las sugerencias del DB Tuning Advisor con ese archivo de rastreo de producción podría mejorar el rendimiento para todos.

Answer 3

En realidad, no debe hacer que el servidor procese la traza, ya que puede causar problemas: "Cuando el servidor procesa la traza, no se descarta ningún evento, incluso si eso significa sacrificar la ejecución del servidor para capturar todos los eventos. al procesar la traza, omitirá eventos si el servidor está demasiado ocupado ". (. A partir de las mejores prácticas de SQL 70-431 examen de libros)

Answer 4

En realidad es posible recopilar mediciones más detalladas de las que puede recopilar de Profiler, y hacerlo 24x7 en toda una instancia, sin incurrir en gastos generales. Esto evita la necesidad de averiguar con anticipación lo que necesita filtrar ... lo que puede ser complicado.

Divulgación completa: trabajo para uno de los proveedores que proporcionan tales herramientas ... pero ya sea que use la nuestra o la de otra persona ... esto puede ayudarlo a resolver el problema principal aquí.

Más información en nuestra herramienta de aquí http://bit.ly/aZKerz