¿Hay alguna manera de programar consultas SQL cuando se usa Linq en SQL? Realmente me gusta la función de inicio de sesión, pero sería genial si de alguna manera también se pudiera cronometrar esa consulta. ¿Algunas ideas?Una buena manera de programar consultas SQL cuando se usa Linq en SQL
Analizador de SQL para obtener la consulta y la hora, y también la ruta de ejecución en el analizador de consultas para ver dónde están los cuellos de botella.
Utilizamos SQL Profiler para probar nuestras consultas con LLBLGen Pro.
Puede usar un System.Diagnostics.Stopwatch que le permitirá rastrear el tiempo de ejecución de la consulta. Solo recuerde que las consultas Linq-> SQL no se ejecutarán hasta que las enumere. También tenga en cuenta que si está iniciando sesión en Console.Out habrá un golpe de rendimiento significativo.
Lo mejor es registrar las consultas en un archivo y usar el Analizador de SQL para cronometrarlas y ajustar los índices para las consultas.
Como ya han dicho dos personas, SQL Profiler es la herramienta lista para usar para eso. No quiero ser un eco, pero quería elaborar un poco más en detalle: no solo proporciona los tiempos reales de SQL Server (en comparación con el tiempo desde el lado de la aplicación donde la red se conecta, la conexión y la conexión) los tiempos de la piscina se agregan a la torta) pero también le proporciona las estadísticas de E/S [a menudo más importantes], información de bloqueo (según sea necesario), etc.
La razón por la que las estadísticas de E/S son importantes es que es muy costoso la consulta puede ejecutarse rápidamente mientras consume cantidades excesivas de recursos del servidor. Si, por ejemplo, una consulta que se ejecuta a menudo coincide con tablas grandes y no hay índices coincidentes que resulten escaneos de tablas, SQL Server almacenará las tablas afectadas en la memoria (si es posible). Esto a veces puede hacer que la misma consulta se ejecute sorprendentemente rápido, mientras que en realidad está dañando el resto del sistema/app/db al consumir los recursos del servidor.
La información de bloqueo es casi tan importante -> las consultas pequeñas que realizan búsquedas PK para un solo registro pueden tener tiempos incorrectos debido al bloqueo y el bloqueo. Leí en alguna parte que este mismo sitio estaba plagado de puntos muertos en sus 'primeros días beta'. SQL Profiler es tu amigo para identificar y resolver los problemas causados por el bloqueo también.
Para resumirlo; ya sea que use L2S, EF, ADO simple - si quiere asegurarse de que su aplicación "se comporta bien" con la base de datos, siempre tendrá el Analizador de SQL listo durante el desarrollo y las pruebas. ¡Vale la pena!
Editar: Desde que escribí la respuesta anterior he desarrollado una nueva herramienta de perfil de tiempo de ejecución para L2S que reúne lo mejor de ambos mundos; Estadísticas de E/S y tiempos del lado del servidor de SQL Server, plan de ejecución de SQL Server, alertas de "falta de índice" de SQL Server, combinadas con la pila de llamadas administradas para facilitar la búsqueda del código que generó una consulta determinada y algunas opciones de filtro avanzadas para registrar solo consultas que cumplan con ciertos criterios. Además, el componente de registro se puede distribuir con aplicaciones para facilitar el análisis de consultas en tiempo de ejecución en entornos de clientes activos. La herramienta se puede descargar de:
http://www.huagati.com/L2SProfiler/ donde también puede obtener una licencia de prueba gratuita por 45 días.
Una descripción más larga y fondo de introducción a la herramienta también se encuentra aquí:
http://huagati.blogspot.com/2009/06/profiling-linq-to-sql-applications.html
... y una muestra/tutorial de uso de algunas de las opciones de filtro más avanzados está disponible aquí:
http://huagati.blogspot.com/2009/08/walkthrough-of-newest-filters-and.html
Lo que podría hacer es agregar una implementación personalizada de TextWriter al DataContext.Log que escribirá el sql generado en un archivo o memoria. Luego recorra esas consultas, ejecutándolas con código ADO.NET sin formato, rodeándolas con un cronómetro.
He usado una técnica similar anteriormente porque parecía que cada vez que estaba desarrollando algún código nunca había abierto Profiler, y era muy fácil generar esos resultados en una página HTML. Asegúrese de ejecutarlos dos veces por solicitud de sitio web, pero es útil ver los tiempos de ejecución lo antes posible en lugar de esperar hasta que vea algo en Profiler.
Además, si va a la ruta de la Herramienta SQL, recomendaría buscar en Google "consulta más lenta DMV" y obtener un procedimiento almacenado que le puede dar estadísticas sobre las consultas más lentas en su base de datos. No siempre es fácil desplazarse por los resultados del generador de perfiles para encontrar las consultas incorrectas. Además, con las consultas correctas sobre dmv de sql 2005, también puede hacer pedidos, digamos cpu vs. time, etc.
Estoy buscando de la manera más automática posible. Alinear cada consulta con un cronómetro funcionaría, pero es mucho trabajo. –