Mejores practicas para usar SQL Profiler

  • Article

Dentro de SQL Server, la herramienta SQL Profiler es una gran aliada para poder capturar, entre otras cosas, que consultas son las mas costosas. Pero esta herramienta tiene un coste en recursos alto.

Quiero compartir con vosotros ciertas practicas con las que podremos minimizar esta carga:

    - Si podemos, utilizaremos Extended Events (a partir de SQL Server 2008) en vez de utilizar SQL Trace o SQL Profiler en entornos productivos. La utilización de recursos por parte de SQL Trace, o SQL Profiler se incrementa al aumentar el numero de Cores de la maquina.
   
    - Si necesitamos capturar una traza en un entorno productivo, debemos limitar el numero de eventos a un mínimo. Elige y comprueba cuidadosamente los eventos capturados bajo carga, e intenta evitar combinaciones que aumenten significativamente la carga
   
    - Si tenemos habilitado Hyper-Threading, tenemos que tener cuidado con el siguiente contador: Context Switches/sec
        Este contador nos podrá indicar como de saturados están los cores de cada procesador. Un valor alto (>5000 context swithces por segundo) muestra que estamos saturando la CPU
       
    - La captura de SQL Profiler incrementa la carga del sistema entre un 15 y un 25%, generalmente. Si utilizamos los stored procedures (SQL Trace), el impacto es menor.
        Estos porcentajes dependerán de que estemos capturando, la carga de la instancia, el sistema, y como está siendo usada la instancia.
       
    - Evita capturar eventos que ocurren frecuentemente. Si es posible, ajusta la captura con eventos específicos y filtros. Si se capturan menos eventos, se necesitan menos recursos
   
    - Enfoca la traza para capturar solo eventos que recojan información relevante para nuestro problema. Por ejemplo, si deseas capturar deadlocks, podemos incluir el evento Lock:Deadlock, evitando el evento Lock:Acquired. Si incluimos ambos eventos, la traza tiene que responder a todos los bloqueos que son adquiridos, y el coste de ejecución puede doblarse.
   
    - Evita recolectar datos duplicados. Por ejemplo, podemos evitar recoger SQL:BatchStarted y SQL:BatchCompleted, recogiendo solo SQL:BatchCompleted, que nos mostrara toda la informacion que tiene SQL:BatchStarted
   
    - Utiliza filtros en la definición de traza. Por ejemplo, si sabes que el problema lo está teniendo un usuario especifico, crea un filtro por el nombre de usuario.

Links interesantes:

Optimizing SQL Trace
https://msdn.microsoft.com/en-us/library/ms187023(v=sql.105).aspx

Best practices for running SQL Server on computers that have more than 64 CPUs
https://msdn.microsoft.com/en-us/library/ee210547(v=sql.105).aspx

Optimizing SQL Server CPU Performance
https://technet.microsoft.com/en-us/magazine/2007.10.sqlcpu.aspx

Introducing Extended events
https://msdn.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

Moisés Romero Senosiain – Microsoft Customer Support Services