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: 442 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.