Comenzaré con dos descargos de responsabilidad:

  • Esta entrada se basa en mi propia comprensión de cómo funciona el motor AS, en base a mi propia experiencia y la pregunta ocasional que planteé al equipo de desarrollo. Los detalles pueden no ser completamente precisos, pero espero que los principios generales sean sólidos; los he usado con éxito en varias ocasiones.
  • El 99 % de las veces, el Asistente de diseño de almacenamiento y el Asistente de optimización basada en el uso diseñarán las agregaciones correctas para usted, y no necesitará crear agregaciones manualmente.

Entonces, ¿qué pasa con el 1% de las veces que necesitará estas técnicas? Por lo general, ocurren cuando tiene varias dimensiones que tienen una gran cantidad de miembros en sus niveles inferiores y consultas que obtienen datos de esos niveles. Los cubos con grandes dimensiones padre-hijo y dimensiones que contienen entidades como clientes son las manifestaciones más comunes del mundo real de este escenario. La regla 1/3, que dicta las agregaciones que puede crear el Asistente de diseño de almacenamiento y el Asistente de optimización basada en el uso (consulte Guía de rendimiento de los servicios de análisis para obtener más detalles), puede haber detenido todas las agregaciones que serían útiles para la creación de sus consultas y, como resultado, el rendimiento de las consultas se ve afectado. Ahora bien, la regla de 1/3 existe por una buena razón: evitar la creación de grandes agregaciones que aumenten el tiempo de procesamiento y el tamaño del cubo, pero que no tengan mucho impacto en el rendimiento de las consultas, pero no es infalible; De manera similar, cuando se enfrenta a problemas de rendimiento de consultas, a menudo agradece cualquier mejora en los tiempos de respuesta, ¡sin importar cuán pequeña sea!

El primer paso para diseñar agregaciones manualmente es comprender qué datos solicitan realmente las consultas que desea ejecutar. La mejor manera de hacer esto es tomar una muestra representativa de esas consultas, borrar el registro de consultas, configurarlo para registrar cada consulta y luego ejecutar las consultas de una en una. Notará que una consulta MDX no equivale necesariamente a una consulta de registro. De hecho, una consulta MDX puede generar varias subconsultas, incluso miles, según su complejidad. también notará que lo que se almacena en el registro de solicitudes está algo encriptado. En lugar de explicarlo aquí, le sugiero que lea lo siguiente papel blanco que explica el contenido en detalle. El contenido de la columna DataSet representa la porción del cubo desde la cual cada consulta de registro solicitó datos; los mismos valores se pueden ver en el Monitor de rendimiento utilizando el contador DSN solicitado. El otro valor útil para monitorear es la porción del cubo que el motor AS solicitó datos para responder a cada una de estas consultas y, lamentablemente, esto no está presente en el registro de consultas; solo puede verlo en PerfMon usando el contador DSN usado. .

Este es probablemente un buen lugar para detenerse y dar algunos ejemplos. Imagina que tienes un cubo con 4 dimensiones aparte de las medidas, y estas dimensiones tienen 5, 6, 7 y 8 niveles cada una respectivamente. Si ejecutó una consulta solicitando valores en el nivel superior de cada una de estas dimensiones, DSN solicitado lo mostraría como 1111 (superior, superior, superior, superior); De manera similar, si ejecutó una consulta solicitando datos en los niveles de hoja de cada dimensión, DSN solicitado lo mostraría como 5678 (hoja, hoja, hoja, hoja). Ahora, si no tuviera agregación en su cubo y ejecutara la primera de estas consultas, 1111, para obtener el valor devuelto, AS agregaría los valores de los miembros de hoja de cada dimensión y el DSN utilizado mostraría 5678; el hecho de que toda esta agregación tuviera que ocurrir en tiempo de ejecución significaría que la consulta podría no ejecutarse muy rápidamente. Sin embargo, si tuviera una agregación creada en el tercer nivel de cada dimensión y ejecutara la misma consulta, el DSN utilizado mostraría 3333 en su lugar, y dado que AS solo tuvo que agregar los miembros en el tercer nivel de cada dimensión, la consulta sería corre más rápido. A continuación, imagine que desea ejecutar una consulta tomando valores de los niveles superiores de las dos primeras dimensiones y los niveles de hoja de las dos últimas dimensiones, de modo que el DSN solicitado sea 1178. Dado que es poco probable que se hayan creado agregaciones en inferior a dos dimensiones tan profundas (especialmente si tenían una gran cantidad de miembros, por ejemplo, si una era una dimensión de Cliente), entonces el DSN utilizado debería ser 5678 y AS aún debería agregar lotes de valores en tiempo de ejecución.

Mirando su registro de consultas y PerfMon, el siguiente paso es decidir si necesita crear agregaciones manualmente. Si ha pasado por el Asistente de diseño de almacenamiento y el Asistente de optimización basada en el uso y ha configurado la propiedad de uso agregado en todas sus dimensiones de manera adecuada (nuevamente, consulte la guía de rendimiento de AS para obtener más información sobre esto), y aún ve que sus consultas no están llegando a las agregaciones (por lo que hay grandes discrepancias entre los DSN solicitados y los DSN utilizados), entonces probablemente necesitará. Por otro lado, si ve valores de DSN solicitado y DSN usado que son iguales o casi iguales, es posible que la creación de múltiples agregaciones no sea útil y que deba buscar otras formas de mejorar el rendimiento, como la creación de particiones.

La herramienta que necesitará para crear agregaciones manualmente es «Administrador de particiones», que está disponible en el Kit de recursos de SQL 2K y también en una forma actualizada en BI Accelerator, que se puede descargar gratis desde el sitio web de Microsoft. La interfaz de usuario puede ser un poco engorrosa cuando tiene más de unas pocas dimensiones, pero es mejor que escribir el código en DSO.

El problema final es qué agregaciones debe crear. Volviendo al ejemplo anterior, si vio el patrón 1178 en DSN solicitado, podría crear una agregación que sea exactamente eso, es decir, los niveles superiores de las dos primeras dimensiones y la hoja de niveles de las dos últimas. Eso funcionaría, pero si sus usuarios quisieran profundizar en cualquiera de las dos primeras dimensiones, AS ya no podría usarlo. Por lo tanto, es una idea mucho mejor crear agregaciones en el nivel más bajo al que es probable que accedan sus usuarios, tal vez 3378, y sacrificar un poco de rendimiento en algunas consultas de nivel superior por otras mucho mejores. En general, sin embargo, es solo por prueba y error que descubrirá qué agregaciones necesita.