Clique no banner para conhecer e adquirir o meu treinamento de Bancos de Dados no Azure

Analysis Services – Como monitorar o andamento/progresso do processamento dos cubos pelo SQL Server

Visualizações: 218 views
Tempo de Leitura: 18 minutos

Fala pessoal!
Nesse artigo eu quero compartilhar com vocĂªs uma dica que a maioria das pessoas que trabalha com Analysis Services nĂ£o sabe dessa possibilidade, embora sempre quiseram ter algo assim, que Ă© monitorar o andamento/progresso do processamento dos cubos pelo SQL Server.

Atualmente, a maioria dos profissionais de BI apenas monitora quanto tempo demorou para processar o cubo/database como um todo, mas nĂ£o sabe quanto tempo demorou cada dimensĂ£o, cada fato e cada cubo dentro de um database e Ă© isso que vou mostrĂ¡-los como fazer nesse post.

A primeira coisa que iremos fazer, Ă© abrir o SQL Server Profiler para monitorar o processamento do cubo:

Na tela de login, lembre-se de alterar o tipo de conexĂ£o para “Analysis Services”, digitar o nome da instĂ¢ncia que vocĂª irĂ¡ conectar e configurar os dados de autenticaĂ§Ă£o

Lembre-se que o Analysis Services aceita apenas autenticaĂ§Ă£o Windows (Active Directory local) ou Azure Active Directory.

ApĂ³s conectar, vocĂª poderĂ¡ definir um nome pro monitoramento e onde irĂ¡ armazenar (tabela do banco ou arquivo fĂ­sico)

Eu geralmente salvo no disco e depois crio uma rotina de leitura via Job, apenas para nĂ£o ficar gravando dados no banco o tempo todo, mas para traces vindos do Analysis Services, a funĂ§Ă£o ::fn_trace_gettable, que Ă© utilizada para ler os arquivos gerados, nĂ£o funciona:

Msg 567, Level 16, State 9, Line 1
File ‘C:\temp\SSAS.trc’ is not a recognizable trace file.

EntĂ£o recomendo jĂ¡ configurar o monitoramento para salvar os dados numa tabela de banco diretamente.

A tabela de exportaĂ§Ă£o dos dados estĂ¡ configurada:

Agora clique na aba “Event Selection” para selecionar os eventos que irĂ¡ monitorar.

Geralmente eu marco somente os eventos de “Error” e “End” das categorias abaixo:

  • Command Events
  • Errors and Warnings
  • Progress Reports
  • Queries Events
  • Query Processing

VocĂª pode alterar esses eventos capturados conforme o nĂ­vel de detalhe que quer monitorar.

Clicando no botĂ£o “Column filters”, vocĂª pode aplicar filtros como nome do usuĂ¡rio, nome do software, hostname, ID da sessĂ£o, etc.

No caso abaixo, vou aplicar um filtro para retornar apenas as consultas feitas pelo meu usuĂ¡rio. Isso Ă© Ăºtil para evitar capturar eventos de outros usuĂ¡rios acessando o cubo enquanto vocĂª estĂ¡ processando e acabar confundindo os resultados.

Clico em “Run” para iniciar o monitoramento e agora inicio o processamento do cubo.

VocĂª irĂ¡ ver uma tela como essa abaixo, mostrando o resultado do monitoramento.

Embora seja fĂ¡cil visualizar os dados, EU prefiro consultar pelo SQL Server, onde posso agrupar, somar, filtrar e transformar os dados conforme a necessidade.

Fazendo uma consulta bĂ¡sica na tabela criada, jĂ¡ conseguimos visualizar boa parte dos dados:

Mas agora precisamos incluir as descrições das classes e subclasses dos eventos, para facilitar o entendimento dos dados.

Primeiramente, vamos criar 2 tabelas: ProfilerEventClass e ProfilerEventSubClass, que irĂ£o armazenar as descrições dos eventos que ocorrem durante o processamento de um cubo e inserir os tipos de eventos mais comuns.

Script de criaĂ§Ă£o das tabelas e inserĂ§Ă£o dos dados:

Agora jĂ¡ consigo intepretar melhor os resultados juntando os dados da minha tabela de monitoramento com essas 2 criadas, de acordo com o exemplo abaixo:

E me retorna uma tabela igual a essa aqui:

Alguns pontos importantes para destacar sobre os dados retornados:

  • As colunas “Duration” e “CPU Time” sĂ£o medidas em millisegundos
  • A coluna “IntegerData” retorna a quantidade de linhas processadas (funciona apenas em alguns eventos, como ReadData)
  • A coluna “SPID” Ă© o ID da sessĂ£o do usuĂ¡rio que estĂ¡ executando. Ela pode ser utilizada para isolar alguma execuĂ§Ă£o especĂ­fica, quando existem vĂ¡rias operações sendo executadas ao mesmo tempo no servidor
  • NĂ£o incluĂ­ os eventos de “Begin” e nem “Current”, somente os de “End”, pois somente nessa etapa que as colunas de “Duration” e “CPU Time” retornam dados
  • Nos eventos de “End”, a coluna “StartTime” Ă© quando a operaĂ§Ă£o começou, e a coluna “CurrentTime” Ă© quando ela terminou
IMPORTANTE: Ative esse recurso do SQL Profiler apenas para debuggar casos especĂ­ficos. NĂ£o deixe esse recurso ligado sem necessidade, pois ele consome mais recursos do servidor, alĂ©m de espaço em disco para armazenar esses dados.

Preste muita atenĂ§Ă£o para nĂ£o consumir muito espaço em disco com esses logs e isso acabar virando um problema futuramente.

EntĂ£o Ă© isso aĂ­, pessoal!
Espero que tenham gostado dessa dica e agora vocĂªs consigam monitorar seus processamentos de cubo.