Supervisar Analysis Services con SQL Server Extended Events

Se aplica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Extended Events (xEvents) es un sistema ligero de seguimiento y supervisión del rendimiento que usa muy pocos recursos del sistema, lo que lo convierte en una herramienta ideal para diagnosticar problemas en servidores de producción y de prueba. También es altamente escalable, configurable y en SQL Server 2016, más fácil de usar a través de la nueva compatibilidad con herramientas integradas. En SQL Server Management Studio (SSMS), en las conexiones a instancias de Analysis Services, puede configurar, ejecutar y supervisar un seguimiento activo, de forma similar al uso de SQL Server Profiler. La adición de mejores herramientas debería convertir a xEvents en un reemplazo más razonable para SQL Server Profiler y crea más simetría en la forma de diagnosticar problemas en el motor de base de datos y las cargas de trabajo de Analysis Services.

Además de SQL Server Management Studio, también puede configurar SQL Server Analysis Services sesiones de eventos extendidos de la manera anterior, a través del scripting XMLA, como se admitía en versiones anteriores.

Todos los eventos de Analysis Services se pueden capturar y destinar a usuarios específicos, según se define en Eventos extendidos.

Uso de SSMS para configurar Analysis Services

En el caso de las instancias tabulares y multidimensionales, SSMS muestra una carpeta de administración que contiene sesiones xEvent iniciadas por el usuario. Puede ejecutar varias sesiones a la vez. Sin embargo, en la implementación actual, la interfaz de usuario de eventos extendidos de SQL Server Analysis Services no admite la actualización ni la reproducción de una sesión existente.

La carpeta Administración no se admite cuando se usa SSMS para conectarse a un área de trabajo de Power BI Premium.

Elección de eventos

Si ya sabe qué eventos desea capturar, buscarlos es la manera más fácil de agregarlos al seguimiento. De lo contrario, los eventos siguientes se usan habitualmente para supervisar operaciones:

• CommandBegin y CommandEnd.

• QueryBegin, QueryEndy QuerySubcubeVerbose (muestra la consulta MDX o DAX completa enviada al servidor), además de ResourceUsage para estadísticas sobre recursos usados por la consulta y el número de filas devueltas.

• ProgressReportBegin y ProgressReportEnd (para operaciones de procesamiento).

• AuditLogin y AuditLogout (captura la identidad del usuario con la que una aplicación cliente se conecta a Analysis Services).

Elección del almacenamiento de datos

Una sesión se puede transmitir en directo a una ventana de Management Studio o guardarse en un archivo para su análisis posterior mediante Power Query o Excel.

• event_file almacena datos de sesión en un archivo .xel.

• event_stream habilita la opción Observar datos en directo de Management Studio.

• ring_buffer almacena datos de sesión en memoria mientras el servidor se esté ejecutando. Al reiniciar el servidor, los datos de sesión se descartan.

Agregar campos de evento

Asegúrese de configurar la sesión de modo que incluya campos de evento para poder ver fácilmente la información interesante.

Configurar es una opción del extremo del cuadro de diálogo.

En Configuración, en la pestaña Campos de evento, seleccione TextData para que este campo aparezca junto al evento y muestre los valores devueltos, incluidas las consultas que se están ejecutando en el servidor.

Después de configurar una sesión para los eventos y el almacenamiento de datos deseados, puede hacer clic en el botón script para enviar la configuración a uno de los destinos admitidos, incluido un archivo, una nueva consulta en SQL Server Management Studio y el Portapapeles.

Actualizar sesiones

Una vez creada la sesión, asegúrese de actualizar la carpeta Sesiones de Management Studio para ver la sesión que acaba de crear. Si configuró un event_stream, puede hacer clic con el botón derecho en el nombre de la sesión y seleccionar Observar datos en directo para supervisar la actividad del servidor en tiempo real.

Script XMLA que se va a iniciar

El seguimiento de Eventos extendidos se habilita mediante un comando de script de objeto de creación XMLA similar como se muestra a continuación:

<Execute ...>  
   <Command>  
      <Batch ...>  
         <Create ...>  
            <ObjectDefinition>  
               <Trace>  
                  <ID>trace_id</ID>  
                  <Name>trace_name</Name>  
                  <ddl300_300:XEvent>  
                     <event_session ...>  
                        <event package="AS" name="AS_event">  
                           <action package="PACKAGE0" .../>  
                        </event>  
                        <target package="PACKAGE0" name="asynchronous_file_target">  
                           <parameter name="filename" value="data_filename.xel"/>  
                           <parameter name="metadatafile" value="metadata_filename.xem"/>  
                        </target>  
                     </event_session>  
                  </ddl300_300:XEvent>  
               </Trace>  
            </ObjectDefinition>  
         </Create>  
      </Batch>  
   </Command>  
   <Properties></Properties>  
</Execute>  

Donde el usuario definirá los siguientes elementos, según las necesidades del seguimiento:

trace_id
Define el identificador único de este seguimiento.

trace_name
El nombre proporcionado a este seguimiento; normalmente una definición legible del mismo. Es una práctica común usar el valor de trace_id como nombre.

AS_event
El evento de Analysis Services que se expondrá. Consulte Eventos de seguimiento de Analysis Services para ver los nombres de los eventos.

data_filename
El nombre del archivo de datos que contiene los datos de los eventos. Este nombre se añade como sufijo con una marca de tiempo para evitar sobrescribir los datos si el seguimiento se envía repetidamente.

metadata_filename
El nombre del archivo de datos que contiene los metadatos de los eventos. Este nombre se añade como sufijo con una marca de tiempo para evitar sobrescribir los datos si el seguimiento se envía repetidamente.

Script XMLA para detener

Para detener el objeto de seguimiento de Eventos extendidos, debe eliminar el objeto utilizando un comando de script de objeto de eliminación XMLA como se muestra a continuación:

<Execute xmlns="urn:schemas-microsoft-com:xml-analysis">  
   <Command>  
      <Batch ...>  
         <Delete ...>  
            <Object>  
               <TraceID>trace_id</TraceID>  
            </Object>  
         </Delete>  
      </Batch>  
   </Command>  
   <Properties></Properties>  
</Execute>  
  

Donde el usuario definirá los siguientes elementos, según las necesidades del seguimiento:

trace_id
Define el identificador único para el seguimiento que se va a eliminar.

Consulte también

eventos extendidos de SQL Server