Craig Porteous
C:\Dropbox\Blog Articles\Tabular_02.PNG

Cómo automatizar el procesamiento de modelo tabular SSAS en SQL Server 2016

May 24, 2018 by

Hay muchas maneras de procesar su Modelo Tabular SSAS. Esto puede ser logrado en SSIS usando la tarea DDL Ejecutar Servicios de Análisis (Analysis Services Execute) o manualmente, a través de la interfaz gráfica de Management Studio, pero para tener un poco de diversión y hacer la tarea más flexible, voy a codificar esto con ASSL/TMSL y construir una notificación relacionada. Podemos entonces programar esto como un paso en un trabajo de SQL Server Agent y llamarlo desde SSIS o PowerShell.

La manera más fácil de iniciar para mí fue elegir la opción Process Database en SSMS y, una vez que las opciones estaban configuradas, elegir codificar a una nueva Ventana de Consultas. Esto nos da un script rápido para trabajar sin los problemas de escribirlo por mí mismo. Puedo luego ajustarlo o añadirlo como sea necesario.

La Importancia del nivel de Compatibilidad

Este era el XMLA generado para procesar el modelo tabular llamado Customer Accounts , el cual está en una instalación de SQL Server 2016 SSAS con la que he estado jugando. Una cosa a notar aquí es que el nivel de Compatibilidad para esta Base de Datos está establecida a SQL Server 2012 SP1 o posterior (1103).

De acuerdo a Microsoft, el lenguaje que esto está usando es Analysis Services Scripting Language (ASSL para XMLA). La importancia del nivel de compatibilidad de su base de datos y mantenerlo consistente es que este script no funcionará si usted lo ejecuta contra un modelo tabular con un Nivel de Compatibilidadde 1200. XMLA ya no es usado para modelos tabulares, ya que Microsoft cambió el lenguaje de codificado. SQL Server 2016 ahora usa TMSL para codificar bases de datos de Modelo Tabular. Aquí están fragmentos desde la página MSDN que clarifican el cambio:

Tabular Model Scripting Language (TMSL) se muestra la sintaxis de definición de modelo de comandos y objetos de bases de datos de modelo tabular de Analysis Services en el nivel de compatibilidad 1200 o superior. TMSL se comunica con Analysis Services a través del protocolo XMLA, donde el XMLA.Ejecutarmétodo acepta tanto basada en JSON instrucción scripts en TMSL, así como los scripts tradicionales basado en XML en Analysis Services Scripting Language (ASSL para XMLA).”

Versión y tipo de modelo Multidimensional Tabular 110x Tabular 1200
SQL Server 2012 ASSL ASSL1 No Aplica
SQL Server 2014 ASSL ASSL1 No Aplica
SQL Server 2016 ASSL ASSL1 TMSL

ASSL no es ideal para modelos tabulares, pero diseñar e implementar un lenguaje de scripting más semánticamente correcto requeriría cambios profundos a través del espectro de la arquitectura de los componentes de Servicios de Análisis. Cambios de esta magnitud pueden sólo ser hechos en lanzamientos mayores de versión, y sólo cuando todos los componentes son impactados por este cambio pueden ser actualizados uno después del otro.

El punto principal con este cambio es que no vimos una versión de transición (con soporte para ASSL y TMSL). Es un corte limpio. Las bases de datos “1103” no podrán usar TMSL y las “1200” no podrán usar XMLA. ¡No entre en pánico! Hay una solución alternativa que le ayudará a mover un script entre niveles de compatibilidad (volveré a eso después). El dolor de cabeza es que, si usted tiene cualquier modelo tabular que está pensando en mover al Nivel de Compatibilidad 1200, ¡revise los scripts que corre contra ellos, ya que TODOS necesitan ser recreados usando TMSL!

Puede que también haya notado que incluso cuando estamos usando una base de datos “1200” y hemos generado un script TMSL, SSAS aún está usando una ventana XMLA en Management Studio. Esto es porque SSAS aún usa el protocolo XMLA, el cual aceptará JSON y ASSL. El protocolo XMLA acepta ambos, pero SSAS no, lo cual hace a la transición al nivel más alto de nivel de compatibilidad 1200, lejos de ser simple.

¡Larga vida a TMSL!

Usar los mismos ajustes en el asistente Process Database contra una “Base de datos Tabular 1200”, genera el siguiente script:

Así que, usando esto como nuestro punto de inicio, podemos hacer crecer el script un poco.

  • Podemos añadir más metadatos al script usando la definición description (descripción).
  • Si deseaba sólo procesar una tabla que puede ser definida usando el parámetros table (tabla).
  • Todas las opciones están definidas en la página de referencia de Microsoft para el comando Refresh:

Ejecutando TMSL con SQL Agent

Ahora que tenemos un script con el cual trabajar, creemos un trabajo relacionado.

  1. Cree un Trabajo de SQL Agent en el motor de la Base de datos y nombre al trabajo apropiadamente.

  2. Cree un nuevo paso con los siguientes ajustes:

    1. Type: SQL Server Analysis Services Command
    2. Run As: SQL Server Agent Service Account
    3. Server: SSAS01

  3. Pegue el script TMSL terminado en la ventana Command, nombre el paso apropiadamente y haga clic en OK.

    Haciendo un paréntesis un momento, mencioné al principio que hay un método alternativo para hacer que TMSL se ejecute en una base de datos con un nivel de compatibilidad 1103 o 1100. Así es como funciona ese modo alternativo.

    Ya que TMSL es sólo soportado en SQL Server 2016, usted no podrá configurar este trabajo de SQL Agent como se mostró arriba. Para hacer esto, podemos envolver el código JSON en XMLA, el cual puede ser manejado por un trabajo de SQL Agent 2012 o 2014. Aquí está un ejemplo:

    Con nuestro paso Process DB configurado, ahora queremos revisar el registro y notificación de éxito.

    Queremos proveer información en un formato de correo electrónico que ayudará a los administradores o usuarios saber que la base de datos ha sido procesada. Podemos consultar el motor de SSAS para la última fecha procesada de la base de datos. Esto tendrá que ser una consulta MDX, así que necesitaré hacer que el paso de SQL Agent almacene la salida. El paso final “email” puede ser entonces tomarla y enviarla por correo electrónico.

    Aquí está cómo…

  4. Cree un nuevo paso con los siguientes ajustes:

    1. Type: SQL Server Analysis Services Query
    2. Run As: SQL Server Agent Service Account
    3. Server: SSAS01
    4. Database: Customer Accounts (menú desplegable)

  5. Ahora, deseamos pegar esta consulta en la ventana Command. Esto retorna el nombre de la Base de Datos y su última Fecha procesada. (Usted puede probarlo en una ventana de consultas MDX en la instancia de SSAS).

  6. Ahora, haga clic en Advanced y seleccione la casilla Log to Table.

    Esto registra la salida del paso del trabajo (Nuestra Base de Datos y última fecha procesada) a la tabla [msdb].[dbo].[sysjobstepslogs]. Nosotros añadiremos entonces la lógica al paso del correo electrónico para encontrar y retornar estos valores.

  7. Para el paso final, he recopilado un poco de SQL para consultar la tabla de arriba y enviarla como un correo electrónico HTML.

    1. Siéntase libre de rellenar esto con más opciones, por ejemplo:

      1. Revise si el cubo ha procesado “hoy” primero y envíe un correo electrónico diferente.
      2. Resalte la fecha y hora si la recarga tomó más de XX minutos (asumiendo que sabe el tiempo de inicio).

  8. Cree un nuevo paso con los siguientes ajustes:

    1. Type: Transact-SQL script (T-SQL)
    2. Run As: SQL Server Agent Service Account
    3. Database: msdb

  9. Pegue el código de abajo o una variación dependiendo de sus preferencias de formato: (esto es una variación de mi script SQL de subscripciones fallidas SSRS, el cual utiliza Database Mail para notificar de la compleción).


  10. Usted puede configurar un programa para esto, pero he terminado aquí para probar el script.

La salida de este script debería verse algo como el HTML de salida a continuación, el cual fue generado por la línea SELECT @tableHTMLAll , justo antes de enviar el comando de correo electrónico, en el caso de que desee verificar la salida usted mismo.

Procesamiento Tabular SSAS

Nombre de Base de Datos Tabular Fecha del Último Proceso
Customer Accounts 2017-02-21T08:19:11.083

Esta es una forma muy robusta de automatizar el proceso de su modelo tabular, pero tenga en mente que los errores generados durante el proceso no son capturados, y resultará en un trabajo de Agent fallado. Puede que usted también necesite dividir su procesamiento en múltiples tareas en el trabajo, dependiendo del tamaño de su modelo y la versión de SQL Server que usa. (¡Los modelos tabulares están limitados a usar 16GB en la edición Standard!). Por favor hágame saber si alguien encuentra una manera de capturar errores de procesamiento, o una mejor manera de hacer lo que he descrito. Esto fue un proceso de aprendizaje para mí y espero que ayude a otros.

Referencias

Craig Porteous
168 Views