¡Hola!
En una serie de posts, nos gustaría compartir nuestra experiencia en el desarrollo y operación de sistemas de la familia MS Dynamics AX (antes Axapta).
Sobre nosotros
Somos una cadena minorista relativamente joven de supermercados de comestibles "Da!" En el momento de escribir este artículo, tenemos poco más de 100 tiendas. Los principales procesos de las actividades operativas de la empresa están automatizados en un paquete de sistemas MS Dynamics Axe 2012 + MS Dynamics 365 FO. Los sistemas funcionan 24 horas al día, 7 días a la semana. En promedio, alrededor de un millón de líneas de recepción y alrededor de 70.000 líneas de pedidos de montaje pasan por el sistema por día.
Guías de planes
El ajuste de rendimiento de Axapts se puede realizar de diferentes formas. La forma más eficaz es, por supuesto, optimizar el código fuente de la aplicación. Pero hay situaciones en las que esto es problemático. Luego, puede utilizar la herramienta proporcionada por MS SQL Server DBMS. Se llama - Guía del plan. Apareció en la versión de SQL Server 2005. Pero según nuestros sentimientos en la comunidad de Axapters (especialmente si la empresa no tiene un DBA profesional), no siempre es conocido y utilizado. Aunque, en algunos casos, su uso puede resultar muy eficaz.
¿Para qué?
Estas son las principales razones por las que debería buscar esta herramienta:
1. Datos inconsistentes en los parámetros de consulta. El resultado del muestreo (número de registros) para el mismo criterio de muestreo (conjunto de campos) difiere según los valores de las variables en los criterios de muestreo. O, de una manera más simple, cuando la misma consulta para diferentes parámetros de entrada da como resultado un número radicalmente diferente de registros (a veces uno, a veces diez mil). Esto se debe al llamado "rastreo" de los parámetros de solicitud. Cuando se crea un plan de consulta una vez bajo la máscara de consulta y luego se extrae de la caché. Sin mirar los valores de estos mismos parámetros.
Este suele ser el caso de consultas que involucran tablas InventSum e InventDim. Por ejemplo, cuando en la analítica el Partido para alguna nomenklatura tiene solo un partido, y para otros - varios miles. La primera solicitud a la base de datos puede pasar por un artículo para el que la contabilidad por lotes está deshabilitada. El optimizador creará un plan de consulta para ello. Y ponerlo en el caché. La siguiente solicitud a la base de datos puede pasar por un artículo que tiene habilitada la contabilidad por lotes. Y proporcione varios miles de registros en la selección de InventSum e InventDim. Y para tal muestra, el plan de la caché será subóptimo.
Una forma de resolver este problema es utilizar la sugerencia forceLiterals en el cuerpo de la solicitud. Esto indica al motor SQL que genere un nuevo plan de consulta cada vez. Pero esto le da una carga tangible adicional a la CPU. Y con las mismas solicitudes restantes, el uso de InventDim no es una opción aceptable. Bueno, debes entender que el optimizador de SQL Server no es perfecto y, a veces, incluso con estadísticas completas, genera planes extraños.
Y en este caso, la Guía de planes viene al rescate, con la ayuda de la cual puede elegir un plan de consulta que brinde una velocidad de ejecución aceptable para cualquier parámetro de entrada de consulta. Y adjunte este plan a la máscara de consulta utilizando la Guía del plan.
2. El optimizador elige un índice que da como resultado bloqueos largos. Con la Guía del plan, puede "precisar" el uso de un índice específico, que reducirá la muestra y reducirá el número de bloqueos.
3. La fuente (lugar en el código) de la consulta del problema no se puede identificar rápidamente y el problema de una caída en el rendimiento de la base de datos debe resolverse de inmediato.
4. El código fuente de la aplicación no se puede cambiar por algún motivo (solución de socio, solicitudes del kernel, etc.). Esto es especialmente cierto para D365, que prohíbe la superposición.
¿Cómo?
No describiré en detalle una guía paso a paso para crear una Guía del plan. Hay una buena descripción en el sitio web del proveedor (estamos interesados en el tipo de plan - SQL) Y la red tiene un mar de tutoriales.
Pero es importante saber que existe otra herramienta de SQL Server que le será de gran ayuda si necesita crear una nueva Guía del plan. Se llama Almacén de consultas. Apareció en 2016. Una descripción detallada de la misma aquí .
La idea principal de la herramienta es que, además del plan de consulta actual en la caché, almacena todo el historial de planes que ha formado el optimizador durante un tiempo determinado. Si sabe que la funcionalidad problemática funcionaba "normalmente" antes. No se detuvo. Solo tienes que encontrar el plan que necesitas en el repositorio y hacer una Guía de planes en base a él. Desafortunadamente, debido a las peculiaridades de Axapta, es imposible crear una Guía de planes con un botón de "plan de fuerza". Tendrá que copiar el plan de consulta del repositorio y crear la Guía del plan manualmente. Pero esto aún simplifica enormemente la tarea.
También debe tenerse en cuenta que el uso del Query Store da una pequeña sobrecarga a los recursos computacionales del servidor DBMS utilizado. Pero en nuestra práctica, son insignificantes y esto puede pasarse por alto.
Ejemplos de
Aquí hay un par de ejemplos de guías de planes de nuestra base de batalla real. Tenga en cuenta que estos son solo ejemplos que son relevantes para nuestros procesos comerciales específicos. Es posible que no sean aplicables o incluso perjudiciales para su instalación.
1. InventSum
Esta guía de planes resuelve el problema de los planes subóptimos en el caso de consultas de elementos con una pequeña cantidad de registros en la tabla InventDim. Con esta guía, siempre puede usar el plan que sea óptimo para el muestreo con una gran cantidad de combinaciones de SKU de InventDim. Las consultas de artículos con un número bajo de SKU serán un poco más lentas. Pero este no es un gran precio a pagar por una velocidad estable y predecible para cualquier combinación de parámetros de entrada.
Estas consultas se generan principalmente mediante el método InventSum :: findSum (). Y dependiendo de la agrupación, los patrones de consulta pueden diferir ligeramente. Entonces, en realidad, tenemos una guía de planes más similar adaptada para diferentes grupos.
2. InventSumDelta
Esta guía de planes le permite crear un plan de consulta óptimo para la tabla InventSumDelta, evitando bloqueos innecesarios en esta tabla. La especificidad de esta tabla es tal que los datos no se almacenan en ella. Pero se agregan / eliminan muy intensamente. Es esencialmente una tabla de semáforo. En este sentido, es imposible recopilar estadísticas normales en esta tabla. Por lo tanto, el optimizador a veces generaba planes subóptimos que resultaban en bloqueos.
Un poco fuera de tema: también debe deshabilitar los bloqueos de página en los índices de esta tabla. Dado que la selección de esta tabla siempre se realiza mediante un ID único, escalar los bloqueos al nivel de la página no tiene sentido e incluso es perjudicial aquí.
conclusiones
Pero en el caso general, déjame llamar tu atención una vez más, no debes abusar de esta herramienta. Si el código se escribe de manera óptima, las estadísticas se actualizan regularmente, los índices no están muy fragmentados; en la mayoría de los casos, el optimizador seleccionará el plan correcto. Pero si la guía del plan está configurada, los criterios de entrada de la solicitud pueden fallar de manera que la guía del plan solo perjudique.