Acceso a la base de datos de instrumentación

Question

Jeff mencionó en uno de los podcasts que una de las cosas que siempre hace es poner instrumentación para llamadas a bases de datos, para que pueda saber qué consultas están causando lentitud, etc. Esto es algo que he medido en el pasado usando SQL Profiler, pero estoy interesado en qué estrategias han usado otras personas para incluir esto como parte de la aplicación.

¿Es simplemente una cuestión de incluir un temporizador a través de cada llamada a la base de datos y registrar el resultado, o hay una manera más 'ordenada' de hacerlo? Tal vez haya un marco que ya lo haga por usted o existe una bandera que podría habilitar en, por ejemplo, Linq-to-SQL que proporcionaría una funcionalidad similar.

Utilizo principalmente C# pero también estaría interesado en ver métodos de diferentes idiomas, y estaría más interesado en una forma de 'código' de hacerlo sobre un método de plataforma de db como SQL Profiler.

Answer 1

Si una consulta es más que un simple SELECCIONAR en una sola tabla, siempre la ejecuto EXPLAIN si estoy en MySQL o PostgreSQL. Si está utilizando SQL Server, Management Studio tiene un Plan de ejecución estimado de visualización que es esencialmente el mismo. Es útil ver cómo el motor accederá a cada tabla y qué índices usará. Algunas veces te sorprenderá.

Answer 2

Si está escribiendo consultas en SQL Management Studio puede ingresar: SET STATISTICS TIME ON y el servidor SQl le dirá cuánto tiempo tardaron las partes individuales de una consulta en analizar, compilar y ejecutar. Es posible que pueda registrar esta información manejando el evento InfoMessage de la clase SqlConnection (pero creo que usar el Analizador SQL es mucho más fácil.)

Answer 3

Grabando las llamadas a la base de datos, el tiempo bruto y el número de registros (bytes) devuelto en la aplicación es útil, pero no le dará toda la información que necesita.

Podría mostrarle patrones de uso que no esperaba. Puede mostrar dónde utiliza el acceso "fila por fila" en lugar de las operaciones "establecidas en función".

La mejor herramienta para usar es el Analizador de SQL y analizar el número de "lecturas" frente a la CPU y la duración. Desea evitar consultas altas de CPU, lecturas altas y duraciones largas (¡duh!).

El "grupo leído" es una característica útil para llevar a la cima las consultas más desagradables.

Answer 4

Hubiera pensado que lo importante que hay que preguntar aquí es "¿qué plataforma de base de datos estás usando?"

Por ejemplo, en Sybase, la instalación de MDA tables podría resolver su problema, proporcionan un montón de estadísticas desde el uso de la llamada a procedimiento hasta la E/S lógica promedio, el tiempo de CPU y la cobertura de índice. Puede ser tan inteligente como quieras que sea.

Answer 5

Definitivamente veo el valor de usar SQL Profiler mientras tu aplicación se está ejecutando, y EXPLAIN o SET STATISTICS te dará información sobre consultas individuales, pero ¿alguien pone rutinariamente puntos de medición en su código para recopilar información sobre consultas a la base de datos? en curso: se vería, por ejemplo, una consulta en una tabla que funciona correctamente inicialmente, pero a medida que crece la cantidad de filas, se vuelve cada vez más lenta.

Si está utilizando MySQL o Postgre, hay varias herramientas para ver la actividad de las consultas en tiempo real, pero no he encontrado una herramienta tan buena como el Analizador de SQL para medir el rendimiento de las consultas a lo largo del tiempo.

Me pregunto si hay (o debería ser?) Algo similar a ELMAH en la forma en que se conecta y le da información sin mucho esfuerzo adicional?

Answer 6

Si le gusta Firebird, es posible que desee ver sinatica.com.
Pronto lanzaremos una herramienta de monitoreo en tiempo real para los DBA de Firebird.

</enchufe descarado>

Answer 7

Si utiliza Hibernate (yo uso la versión de Java, me gustaría imaginar NHibernate tiene algo similar), que puede tener Hibernate recopilar estadísticas sobre un montón de cosas diferentes. Véase, por ejemplo:

http://www.javalobby.org/java/forums/t19807.html