Más diversión con Reporting Services. La otra semana estuve trabajando con un cliente que sospechaba que tenía problemas de rendimiento de consultas como resultado del problema descrito aquí:

http://blogs.msdn.com/sqlcat/archive/2007/10/19/ssas-small-big-query-interaction.aspx

De acuerdo, en Profiler pude ver algunas consultas bastante triviales que tardaron mucho más de lo debido, y cuando las ejecuté en un sistema de prueba, se ejecutaron mucho más rápido. Y ciertamente, cuando ejecuté una «consulta grande» y una «consulta pequeña» simultáneamente, vi que la «consulta pequeña» se ejecutaba lentamente, y cuando obtuve la configuración del archivo ini secreto de PSS, mis «consultas pequeñas» funcionaron mucho. más rápido. Pero todavía había algunas dudas en mi mente sobre cuánto estaba sufriendo el cliente por este problema: con solo mirar los rastros de Profiler de los servidores de producción, no podía decir si muchas de las solicitudes pequeñas se superponían con las solicitudes grandes.

Entonces pensé que sería útil poder ver la información de un seguimiento de Profiler de alguna manera. Experimenté un poco con diferentes tipos de gráficos y diferentes herramientas, principalmente Excel 2007, pero finalmente me decidí por Reporting Services 2005 y el control de gráfico Dundas Gantt. No sé si el diagrama de Gantt se ha integrado en el CTP RS2008 actual, pero supongo que será pronto si no; de todos modos, los datos eran de un sistema de 2005, así que eso es lo que usé.

El primer paso fue extraer los datos de Profiler en un formato útil; la forma más fácil resultó ser tener la salida de Profiler directamente a una tabla de SQL Server y para el problema aquí todo lo que necesitaba eran los eventos finales de consulta, y específicamente las duraciones, SPID, TextData, ConnectionID, EndTime, EventClass, EventSubClass y NTCanonicalUserName columnas Ahora podía ejecutar mi seguimiento de Profiler en el sistema de producción y capturar algunos datos. El siguiente problema fue manipular los datos en un formato utilizable. Los diagramas de Gantt necesitan una hora de inicio y una duración para cada evento y el problema con los datos de rastreo es que solo se sabe cuánto tarda algo cuando finaliza, es decir, cuando tiene un evento de «finalización». Al restar EndTime de la duración, se obtiene la hora de inicio derivada del evento, que es una forma de abordar el problema de determinar cuándo comenzaron y finalizaron las solicitudes. Hay eventos de inicio de consulta y finalización de consulta y tal vez otra mejor solución se habría basado en el hecho de que solo puede ejecutar una consulta en una sesión determinada a la vez y coincidir, por lo que debería ser posible asignar cada evento de finalización de consulta a un Evento de inicio de consulta. De hecho, comencé de manera más ambiciosa al incluir otros tipos de eventos, como informes de progreso, pero el problema que encontré aquí fue que las Horas de inicio y las Horas de finalización proporcionadas por Profiler se redondearon al segundo más cercano, lo que significaba que restar la duración de la EndTime no proporcionó tiempos de inicio derivados precisos y encontré que los eventos salieron en lo que claramente era el orden incorrecto cuando intenté ordenarlos por tiempo de inicio derivado (parte del SQL que daré a continuación es más complejo de lo necesario solo para la consulta Evento final porque también fue escrito para esos otros tipos de eventos). Sería bueno visualizar los diversos eventos internos generados cuando ejecuta una consulta individual, como lecturas de partición y caché, pero necesito trabajar un poco más antes de que eso sea posible.

De todos modos, con mis eventos de finalización de consulta, escribí la siguiente consulta SQL para usar en Reporting Services que encuentra la hora de inicio derivada para cada consulta y luego hace que la primera consulta comience en el momento 0 y calcula todas las demás horas de inicio derivadas en relación con esta primera consulta. Como siempre, debo disculparme de antemano por mi SQL:

with RelativeStartTimes(OriginalRowNumber, RelativeStartTime, EventClass, DurationMSecs
TextData, ConnectionID, EventSubClass, NTCanonicalUserName)
me gusta
(
para seleccionar
a.Número de fila,
–Encuentre la hora de inicio relativa de cada evento
–encontrando la diferencia en segundos entre la hora de finalización
–del evento y la hora de finalización más temprana en ms
–luego restando la Duración
(fecha iff(ss,
c.EarliestEnd,
isnull(a.EndTime, a.StartTime)
) * 1000) – isnull(a.Duration, 0) as RelativeStartTime,
a.EventClass,
isnull(a.duración, 0) como DuraciónMSecs,
a.TextData,
a. ID de conexión,
a.Subclase de evento,
a.NTCanonicalUserName
de cuerpo[102QE] una unión cruzada
–Obtener la primera hora de finalización en la traza
(seleccione min(isnull(b.EndTime, b.StartTime)) como Fin más temprano
de cuerpo[102QE] B
donde b.Rownumber>0
)contra
donde a.Rownumber>0
)

para seleccionar
número_fila() sobre(ordenar por (r.RelativeStartTime – x.EarliestRelStartTime) asc) como fila,
r.OriginalRowNumber,
r.RelativeStartTime,
x.EarliestRelStartTime,
r.RelativeStartTime – x.EarliestRelStartTime como BeginTime,
r.RelativeStartTime – x.EarliestRelStartTime + r.DurationMSecs como EndTime,
r.EventClass,
r.DuraciónMSegs,
r.TextData,
r.ID de conexión,
r.EventSubclase,
r.NTCanonicalUserName
de RelativeStartTimes r
unión cruzada
(–Encuentre la hora de inicio relativa más temprana
para seleccionar
min(RelativeStartTimes.RelativeStartTime) como EarliestRelStartTime from
Horas de inicio relativas) x

Luego podría usarlo como base para mi informe de Reporting Services. Como siempre con estas cosas, pasé la mayor parte de mi tiempo trabajando en cómo usar el diagrama de Gantt, pero cuando lo hice, y después de hacer otras cosas increíbles que me permitieron filtrar por número de fila y hora de inicio/finalización, y hacer clic en un elemento del diagrama de Gantt para mostrar el MDX para la consulta representada por una fila en particular, obtuve un informe que se veía así:

Otro tema a mencionar aquí es que, de manera similar a este informe, cuando tiene muchas consultas para ver, el diagrama de Gantt tarda mucho tiempo en procesarse. De todos modos, desde esta vista inicial, puede ver que casi todas las consultas se ejecutaron muy rápidamente, pero pronto hubo una consulta muy larga, representada por la larga línea marrón alrededor del evento 250 que marqué. Filtrar la vista para mostrar esta consulta y las que la rodean con más detalle le da esto:

gantt2

Aunque la gran mayoría de las consultas aquí se ejecutan de inmediato (estas son solo consultas pequeñas que el front-end usa para obtener metadatos, etc. y se representan como blobs individuales), he marcado con un círculo algunas consultas alrededor de la consulta principal que parecen tardar unos segundos. correr. Y, de hecho, ejecutar al menos una de estas consultas en el servidor de prueba ha demostrado que se ejecuta más rápido por sí solo que cuando se ejecuta este seguimiento de Profiler. Lo que probó mi punto.

Divagando de este ejercicio en particular, estoy bastante sorprendido de que ninguno de los principales proveedores de herramientas de SQL Server haya abordado el problema de monitorear el rendimiento y la actividad de Analysis Services. La única herramienta que conozco que hace esto es Companion for Analysis Services:

http://www.sqlminds.com/Products/CompanionforMSAnalysisServer/tabid/119/Default.aspx

Pero, ¿dónde están los demás? Habría pensado que Analysis Services sería el próximo paso obvio para ellos, ya que muchas tiendas relacionales de SQL Server también usan la pila MS BI. Cada vez que hablo con clientes empresariales, siempre me preguntan qué herramientas están disponibles, claro… Supongo que hay tres cosas aquí: en primer lugar, la ignorancia demasiado común de Analysis Services en la comunidad más amplia de SQL Server; en segundo lugar, nadie (ni siquiera los expertos en SSAS) se ha sentado realmente a pensar en lo que debe supervisarse en una implementación de Analysis Services; y tercero, al menos antes de AS2008, los ganchos para obtener datos que pueden usarse para el monitoreo no estaban disponibles o estaban bien escondidos. Esto y mi último artículo sobre la visualización y supresión de consultas en Reporting Services Sin embargo, dio algunas ideas de lo que es posible y, con suerte, en los próximos años, Microsoft y/o proveedores externos nos brindarán las herramientas que necesitamos.