una tutorial traza log hacer descargar como sql-server linq profiler

sql-server - tutorial - sql server profiler log



Trucos inteligentes para encontrar consultas LINQ específicas en SQL Profiler (3)

El perfil de consultas LINQ y sus planes de ejecución es especialmente importante debido al loco SQL que a veces se puede crear.

A menudo me parece que necesito hacer un seguimiento de una consulta específica y me cuesta encontrarlo en el analizador de consultas. A menudo hago esto en una base de datos que tiene muchas transacciones en ejecución (a veces servidor de producción), así que simplemente abrir Profiler no es bueno.

También he descubierto que trato de usar DataContext para rastrear inadecuado, ya que no me da SQL. Puedo ejecutarlo.

Mi mejor estrategia hasta ahora es agregar un número "aleatorio" a mi consulta, y filtrarlo en el rastreo.

LINQ:

where o.CompletedOrderID != "59872547981"

Filtro Profiler:

''TextData'' like ''%59872547981''

Esto funciona bien con un par de advertencias:

  • Tengo que tener cuidado de recordar eliminar los criterios, o elegir algo que no afecte demasiado al plan de consulta. Sí, sé que dejarlo es pedir problemas.
  • Sin embargo, por lo que puedo decir, incluso con este enfoque necesito comenzar un nuevo rastreo para cada consulta LINQ que necesito seguir. Si voy a ''Archivo> Propiedades'' para un rastreo existente, no puedo cambiar los criterios de filtro.

No puede superar la ejecución de una consulta en su aplicación y verla aparecer en el Analizador sin ningún esfuerzo adicional. Solo esperaba que alguien hubiera encontrado una forma mejor que esto, o al menos sugiriera un token menos "peligroso" para buscar que una consulta en una columna.


Puede hacer que su contexto de datos cierre la sesión del SQL sin formato, que luego podría buscar en el generador de perfiles para examinar el rendimiento.

using System.Diagnostics.Debugger; yourDataContext.Log = new DebuggerWriter();

Todas sus consultas SQL se mostrarán en la ventana de salida del depurador ahora.



Tartamudear con la cláusula where es quizás no lo mejor, ya que puede afectar los planes de ejecución de sus consultas.

Haga algo funky con la proyección en clases anónimas en su lugar: use un nombre de columna estático único o algo que no afecte el plan de ejecución. (De esta forma, puede dejarlo intacto en el código de producción en caso de que luego necesite hacer un perfil de código de producción ...)

from someobject in dc.SomeTable where someobject.xyz = 123 select new { MyObject = someobject, QueryTraceID1234132412=''boo'' }