Monitorare Analysis Services con eventi estesi di SQL Server

Si applica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Gli eventi estesi (xEvents) rappresentano un sistema di monitoraggio delle prestazioni e di traccia leggero, che usa una quantità molto limitata di risorse di sistema. Sono quindi uno strumento ideale per la diagnosi dei problemi, sia nei server di produzione che in quelli di prova. È anche altamente scalabile, configurabile e in SQL Server 2016, più facile da usare tramite il nuovo supporto predefinito degli strumenti. In SQL Server Management Studio (SSMS) nelle connessioni alle istanze di Analysis Services è possibile configurare, eseguire e monitorare una traccia in tempo reale, analogamente all'uso di SQL Server Profiler. L'aggiunta di strumenti migliori dovrebbe rendere XEvents una sostituzione più ragionevole per SQL Server Profiler e creare maggiore simmetria per le modalità di diagnosi dei problemi nel motore di database e nei carichi di lavoro di Analysis Services.

Oltre SQL Server Management Studio, è anche possibile configurare SQL Server Analysis Services sessioni degli eventi estesi nel modo precedente, tramite script XMLA, come è stato supportato nelle versioni precedenti.

Tutti gli eventi di Analysis Services possono essere acquisiti e indirizzati a consumer specifici, come definito in Eventi estesi.

Usare SSMS per configurare Analysis Services

Per le istanze tabulari e multidimensionali, SSMS visualizza una cartella di gestione che contiene sessioni xEvent avviate dall'utente. È possibile eseguire più sessioni contemporaneamente. Nell'implementazione corrente, tuttavia, l'interfaccia utente SQL Server Analysis Services eventi estesi non supporta l'aggiornamento o la riproduzione di una sessione esistente.

La cartella Gestione non è supportata quando si usa SSMS per connettersi a un'area di lavoro Power BI Premium.

Scegliere gli eventi

Se si conoscono già gli eventi da acquisire, cercarli è il modo più semplice per aggiungerli alla traccia. In caso contrario, gli eventi seguenti sono comunemente usati per le operazioni di monitoraggio:

• CommandBegin e CommandEnd.

• QueryBegin, QueryEnde QuerySubcubeVerbose (visualizza l'intera query MDX o DAX inviata al server), oltre a ResourceUsage per statistiche sulle risorse usate dalla query e il numero di righe restituite.

• ProgressReportBegin e ProgressReportEnd (per operazioni di elaborazione).

• AuditLogin e AuditLogout (acquisisce l'identità dell'utente con cui un'applicazione client si connette ad Analysis Services).

Scegliere l'archiviazione dei dati

È possibile visualizzare una sessione in tempo reale in una finestra in Management Studio oppure salvarla in un file per analisi successive tramite Power Query o Excel.

• event_file archivia i dati della sessione in un file con estensione xel.

• event_stream abilita l'opzione Controlla i dati dinamici in Management Studio.

• ring_buffer archivia i dati della sessione in memoria fino a quando il server è in esecuzione. In caso di riavvio del server, i dati della sessione vengono eliminati.

Aggiungere campi evento

Assicurarsi di configurare la sessione in modo da includere campi evento, per poter visualizzare facilmente le informazioni di interesse.

Configura è un'opzione all'estrema destra della finestra di dialogo.

Nella configurazione, nella scheda Campi evento, selezionare TextData in modo da visualizzare il campo accanto all'evento per mostrare i valori restituiti, incluse le query in esecuzione nel server.

Dopo aver configurato una sessione per gli eventi e l'archiviazione dati desiderati, è possibile fare clic sul pulsante script per inviare la configurazione a una delle destinazioni supportate, tra cui un file, una nuova query in SQL Server Management Studio e gli Appunti.

Aggiornare le sessioni

Dopo aver creato la sessione, assicurarsi di aggiornare la cartella Sessioni in Management Studio per visualizzare la sessione appena creata. Se è stata configurata l'opzione event_stream, è possibile fare clic con il pulsante destro del mouse sul nome della sessione e scegliere Controlla dati dinamici per monitorare l'attività del server in tempo reale.

Script XMLA da avviare

La traccia di eventi estesi viene abilitata utilizzando una specifica XMLA simile per creare un comando script dell'oggetto come illustrato di seguito:

<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>  

A seconda delle necessità di traccia, gli elementi seguenti devono essere definiti dall'utente:

trace_id
Consente di definire l'identificatore univoco per questa traccia.

trace_name
Nome fornito a questa traccia; generalmente una definizione leggibile della traccia. È pratica comune usare il valore trace_id come nome.

AS_event
Evento di Analysis Services da esporre. Vedere Eventi di traccia di Analysis Services per i nomi degli eventi.

data_filename
Nome del file in cui sono contenuti i dati degli eventi. Nel nome è incluso un suffisso timestamp per evitare la sovrascrittura dei dati qualora la traccia venga inviata ripetutamente.

metadata_filename
Nome del file in cui sono contenuti i metadati degli eventi. Nel nome è incluso un suffisso timestamp per evitare la sovrascrittura dei dati qualora la traccia venga inviata ripetutamente.

Script XMLA da arrestare

Per arrestare l'oggetto traccia di eventi estesi è necessario eliminare tale oggetto utilizzando una specifica XMLA simile per eliminare un comando script dell'oggetto come illustrato di seguito:

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

A seconda delle necessità di traccia, gli elementi seguenti devono essere definiti dall'utente:

trace_id
Consente di definire l'identificatore univoco della traccia da eliminare.

Vedi anche

SQL Server eventi estesi