Ir al contenido principal

Hacer trazas en SQL Server Express

Si necesitas diagnosticar problemas de rendimiento, encontrar consultas conflictivas o simplemente quieras trazar las consultas que hace una aplicación contra la base de datos, seguramente estés acostumbrado a usar el SQL Server Profiler, la herramienta que principalmente hemos utilizado para realizar este tipo de diagnósticos sobre nuestras bases de datos y servidores. También es posible que te hayas decidido a dar el paso a Extended Events, pero esa es otra cuestión.

Si el Profiler es tu herramienta, muy seguramente la eches de menos en el caso de que el diagnóstico tengas que hacerlo sobre un SQL Server Express. La edición gratuita del motor de bases de datos relacionales de Microsoft no incluye esta aplicación. Es un contratiempo, pero hay alternativas. A continuación, os las presentamos:

ExpressProfiler


ExpressProfiler es un ejecutable, gratuito, de código abierto, anteriormente conocido como SqlExpress Profiler. Presenta una interfaz muy sencilla en un ejecutable que solamente tendremos que descargar y ejecutar, sin instalaciones. Simplemente tendremos que darle al botón de play y monitorizar la traza para ver qué consultas se están ejecutando.

El ExpressProfiler v2.0, en acción
El ExpressProfiler v2.0, en acción

Trace Flags o Marcas de Seguimiento


Existen en SQL Server una serie de características que pueden ser configuradas de manera temporal y dinámica, activando y desactivando lo que se conoce como trace flags o marcas de seguimiento, en castellano. Tal y como explica la MSDN, las marcas de seguimiento se suelen utilizar para diagnosticar problemas de rendimiento o para depurar procedimientos almacenados o sistemas complejos.

Pues bien, dos de ellas nos sirven para nuestro propósito, tal y como se explica en este artículo de CodeProject, escrito por BillyBoatGruff en febrero de 2012.

Activando la marca 4032, todas las consultas ejecutadas sobre SQL Server se trazan. El mecanismo habitual para activar una traza es mediante la instrucción DBCC TRACEON:

Sin embargo, si intentamos activar esta traza, obtendremos el siguiente mensaje:
"Se omitirá la marca de seguimiento 4032. Se trata de una marca de seguimiento no válida o que solo se puede especificar durante el inicio del servidor."
Tal y como explica el mensaje, esta traza ha de especificarse durante el inicio del servidor. Para ello ejecutaremos la siguiente instrucción desde una línea de comandos que hayamos ejecutado como administrador:

Para poder ejecutar la instrucción, el servidor deberá estar detenido. Si no lo está, podemos pararlo desde la misma línea de comandos con la instrucción:


Una vez hecho esto, volcaremos las consultas al log de errores de SQL Server para que podamos consultarla, activando la traza 3605:

Con estas dos trazas activas, podremos revisar en el log de nuestro SQL Server todas las consultas realizadas sobre el servidor. El log permite realizar filtrados y exportar su listado a un fichero de texto, desde donde podremos copiar las consultas.

Hay que tener en cuenta que para poder utilizar este mecanismo, es necesario ser administrador tanto del servidor de bases de datos como del equipo en el que esté instalado.

Para deshabilitar las trazas, una vez hayamos acabado con las tareas de diagnóstico, ejecuta:

Comentarios

  1. ¡Gracias por esta información!
    Personalmente, uso dbForge Event Profiler para SQL Server - https://www.devart.com/dbforge/sql/event-profiler/ para rastrear declaraciones, esta herramienta es completamente gratuita y está muy bien.

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Aprendiendo a usar LEFT OUTER JOIN

En esta entrada pretendemos explicar los diferentes resultados obtenidos por distintas construcciones de consultas que, aparentemente, deberían producir el mismo conjunto de resultados. Así, veremos las diferencias entre filtrar los resultados de una query en la unión (Join) mediante condiciones ON y mediante cláusulas WHERE.

Variantes del SELECT COUNT con DISTINCT

Seguramente, muchos de vosotros habréis usado en innumerables ocasiones la función de T-SQL COUNT , que no hace sino devolver un número de registros: de una tabla, de un conjunto de resultados, etc... En una de sus aplicaciones, combinado con el DISTINCT -uno de los dos argumentos que admite- COUNT nos devuelve el número de valores únicos no nulos de la tabla o conjunto de resultados que estemos consultando. Pero ¡ojo! Cuidado con la sintaxis , o podemos obtener el valor equivocado sin darnos cuenta. No es lo mismo: SELECT COUNT (DISTINCT NombreCampo) FROM NombreTabla que: SELECT COUNT(*), DISTINCT NombreCampo FROM NombreTabla

Script para obtener el tamaño de todas las tablas de la base de datos

En algunas ocasiones podemos vernos con la necesidad de conocer qué tablas de nuestra base de datos están ocupando más espacio en disco. Por ejemplo, si disponemos de SQL Server Express , cuyas bases de datos están limitadas a 4GB o 10GB, según la versión que estemos usando -4, hasta 2005; 10, a partir de 2008-, aparte de usar las opciones de comprimir la base de datos, poner el log en el modo simple de recuperación o ajustar las políticas de crecimiento automático de nuestros ficheros, podemos necesitar averiguar qué tablas crecen más para tomar las decisiones oportunas.