Sexta-feira passada foi lançada publicamente mais uma build (May Release) do Data Explorer.

O Data Explorer é um add-in para o Excel para você realizar transformações nos dados de uma forma facilitada (self-service) e passível também de integração com o PowerPivot para análise.

Essa versão de maio contém diversas novidades que podem ser acompanhadas no blog do time de produto do Data Explorer:

http://blogs.msdn.com/b/dataexplorer/archive/2013/05/13/data-explorer-may-update-is-available-now.aspx
Essa ferramenta tem muito potencial, principalmente nos cenários em que a utilização do Integration Services (SSIS) poderia aumentar muito a complexidade da solução.

Fica a dica ;)
Thiago Zavaschi

O tópico de hoje é para servir de base a todos que desejam conhecer um pouco mais de como o servidor do Analysis Services (SSAS) trabalha por trás dos panos.

Existem diversos mecanismos internos que são responsáveis / interagem no processamento de uma query que é enviada ao servidor de análise (o processo detalhado de execução de uma query vou abordar em um tópico futuro específico): XMLA Listener, Formula Engine, Storage Engine e assim por diante.

Esse post abordará sobre o que é e para que servem a Formula e a Storage Engine.

Formula Engine

Toda computação e calculo que uma query precisa realizar é feita pela Formula Engine (FE). Ela faz o processamento de todos os dados e também determina quais dados serão necessários para responder a query que foi enviada.

A FE é single threaded. Isso significa que se for identificado que a sua query está com gargalo na FE, então a solução seria utilizar máquinas/servidores com clock de processamento mais elevado.

Os dados que a FE precisa para responder a uma query são requisitados para a Storage Engine.

Storage Engine

A Storage Engine (SE) é a responsável pela devolução dos dados para as requisições feitas pela Formula Engine. As requisições de dados feitas são chamadas de Subcube Requests (e podem ser observadas através de um trace ou xEvents (no 2012)).

A SE é multi threaded e faz a requisição de dados (subcube requests) em paralelo. É responsável também por verificar se os dados necessários não estão disponíveis em agregações já criadas.

No caso da identificação de que o gargalo no tempo de execução da query é na SE, é possível minimizar com uso mais eficiente de agregações (para mais técnicas de otimização, consultar o Performance Guide do SSAS).

E o cache?

Toda vez que eu disparo uma query contra meu servidor de análise é necessário passar por todas essas etapas?

Não!

Existem diversos níveis de cache internos ao SSAS (fora o cache que pode existir na camada NTFS).

A ordem (simplificada) é a seguinte:

1. Existe um cache para a Formula Engine: A query pode ser respondida usando ele? Se sim, retorna.
2. Existe um cache para a Storage Engine: A FE fez uma requisição que está em cache? Se sim, retorna ela. (Se houverem outros subcube requests – muito comum – o processo é o mesmo).
3. Verifica agora se há uma agregação que responde ao subcube request: Se sim, retorna da agregação.
4. Caso contrário lê dos dados do measure group (opção mais custosa, principalmente se utilizado ROLAP, onde a leitura é contra um servidor externo).

Por hoje era isso. Estes conceitos serão bastante importantes para entender meu próximo post: “Posso utilizar o Query Log – já visto aqui no blog – para fazer auditoria ou contabilização de acesso de usuários?”

Obrigado e até a próxima!

O ponto que quero abordar hoje é sobre a suportabilidade da integração do SharePoint com o Reporting Services.

É de senso comum de quem trabalha com as tecnologias de Business Intelligence da Microsoft saber que o Reporting Services pode ser configurado para trabalhar de modo autônomo (modo nativo) ou em modo integrado ao SharePoint. No entanto nem sempre fica claro quais são as restrições de versões para essa compatibilidade.

Por exemplo: Posso usar o Reporting Services do SQL Server 2008 R2 com o SharePoint 2010? E com o SharePoint 2013? E se for o SQL Server 2008? E a versão dos Add-ins?

Este post serve para elucidar estes casos. Este post é baseado no seguinte pedaço do books online (em inglês): http://msdn.microsoft.com/en-us/library/dc6a3372-db26-43f0-b7aa-f725acc635c2

• Para o SharePoint 2013, você somente pode utilizar a versão do add-in do SSRS do SQL Server 2012 SP1.

• Para o SharePoint 2010, você pode usar o add-in do SQL Server 2012 ou do SQL Server 2008 R2 para o SharePoint 2010. Porém se utilizar a versão do add-in para o SQL Server 2012 SP1, o servidor de relatórios terá que ser o SSRS 2012 SP1 também.

• Para o SharePoint 2007, sempre utiliza o add-in do SQL Server 2008 Reporting Services add-in para SharePoint 2007.

• Servidores de relatórios do SQL Server 2008 R2 (SSRS 2008 R2) são suportados tanto pelo SharePoint 2007 quanto pelo SharePoint 2010.

• Reporting Services do SQL Server 2008 SP1 CU #8 e superiores são suportados com SharePoint 2007 e SharePoint 2010.

• Report servers do SQL Server 2008 são suportados pelo SharePoint 2007.

Para facilitar o entendimento: Report Server x Add-in x SharePoint, temos a tabela abaixo (também extraída do site mencionado anteriormente) de combinações suportadas.

E onde encontrar as versões mencionadas dos addi-ns?

Aqui (em inglês): http://msdn.microsoft.com/en-us/library/069ac476-6336-44a9-a0e7-db1c4888948f

Por hoje a ideia era reforçar estes ambientes quanto a suportabilidade. Cuidado apenas para não confundir suportabilidade com os recursos que cada versão oferece (mapas, Power View, entre outros).
Em caso de dúvidas utilizem o espaço para comentários do post.

Thiago Zavaschi

Uma dúvida comum que sempre surge quando vou atender um caso de SQL Server Integration Services (SSIS) é:

“Ok Thiago desenvolvi 100 (leia-se muitos) pacotes no SSIS, porém toda a vez que vou fazer o deploy destes pacotes em homologação e produção eu tenho que ficar mudando as connection strings. Como proceder?”

O SSIS tem um mecanismo para ajudar neste sentido chamado SSIS Package Configuration, onde é possível salvar a suas configurações em um arquivo XML, variável de ambiente ou até mesmo em uma tabela do SQL Server que contenha os valores.

No artigo de hoje vou abordar apenas a configuração através de arquivo XML.

Mas então, como fazer?

Desenvolva seu pacote normalmente. Utilizando os Data Sources de desenvolvimento e associando os respectivos Connection Managers a eles da forma que for necessária ao seu fluxo.

Agora o que precisamos fazer é criar um arquivo de configuração XML que conterá os dados que os data sources utilizarão ao invés do que você configurou previamente.

Esta configuração você fará para o primeiro pacote e depois reutilizará o mesmo arquivo de configuração para os demais pacotes.

Abra o pacote, vá no menu “SSIS” e depois em “Package Configurations…”

Marque Enable Package Configurations e depois clique em “Add”.

Clique em “Browse…” para selecionar o local onde ficará o arquivo de configuração. Por exemplo: C:\config.dtsConfig.

A extensão do arquvo é .dtsConfig e é nada mais do que um arquivo XML.

Clique Next e na sequência marque a propriedade que deseja que a opção utilizada seja o que está no arquivo de configuração. Para o nosso caso o objetivo é facilitar a configuração da connection string, então vamos marcar ela.

Clique para prosseguir, dê um nome e clique em “Finish”.

No meu exemplo eu tenho dois pacotes e desejo que a fonte de ambos seja a mesma.

Devemos fazer um processo similar.

Abra o segundo pacote, depois, “SSIS” >> “Package Configurations” >> “Enable package configurations” >> “Add”.

Selecione o .dtsConfig já criado para este pacote. Ele irá perguntar se deseja que seja reusado o arquivo já existente ou se o desejado é sobrescrever. Marque para reusar (“Reuse Existing”).

Depois clique para prosseguir, dê um nome e encerre a janela. Pronto!

Agora temos dois pacotes que utilizam o mesmo arquivo de configuração para as connection strings. Mesmo que a execução seja feita através do BIDS, a utilização será sobre o arquivo de configuração.

Ok, e como eu verifico se ele está mesmo utilizando? Simples, execute seu pacote e veja na aba “Progress”.

Você verá a seguinte linha:

“Information: The package is attempting to configure from XML file “arquivo.dtsConfig”.”

Pronto, agora você pode levar os pacotes para homologação/produção e fazer a troca em apenas um ponto.

Há outras formas de fazer isso sem utilizar o arquivo XML, porém essa é a mais utilizada. As outras deixarei para um possível post futuro.

Obrigado!
Thiago Zavaschi

Estando no time de suporte premier da Microsoft recebo muitos chamados de clientes que desejam migrar seu Analysis Services do 2000 para versões mais recentes como o 2008 R2 e 2012.

Uma dúvida comum é sobre as diferenças entre a versão 2000 e as demais.

Hoje falaremos das principais diferenças do query log do SSAS 2000 para os SSAS posteriores.

O SSAS possui capacidade de logar informações sobre as queries que são disparadas contra o servidor (não estou falando do Profiler (traces) e nem do Flight Recorder (que também é um trace)) conhecido como query log.

O SSAS não armazena evetivamente a query executada, porém armazena informações sobre quais atributos e measures foram utilizadas, que mais tarde pode ser utilizada pelo wizard de otimização baseado em uso.

O SSAS 2005 (e os posteriores) não loga as queries na tabela de log de queries por padrão. Para fazer o log você deve explicitamente ativar esse recurso nas propriedades do SSAS.

A partir do SSAS 2005 não é possível utilizar o Access como repositório para o log de queries. Obrigatoriamente você terá de usar uma database do SQL Server para isso.

O SQL Server não precisa residir no mesmo computados que o SSAS.

O Analysis Services não utiliza mais o registro do windows para armazenar suas propriedades. Todas as propriedades do servidor SSAS que controlam o comportamento do query log são acessíveis através do Management Studio ou através da modificação do arquivo de configuração do SSAS.

O formato (campos e tipos de dados) da tabela de log mudou. Se você utiliza para algum outro fim, você precisará ajustar seus scripts personalizados.

Para maiores informações sobre como configurar o query log do SSAS segue o link (em inglês):

http://technet.microsoft.com/en-us/library/cc917676.aspx

Obrigado!

Uma dúvida muito comum que recebo é: posso por o meu servidor de relatórios (Reporting Services) no mesmo servidor de base de dados (database engine). A resposta é: claro que pode…. tecnicamente, mas dependendo da demanda, não é uma boa estratégia quando o objetivo é performance.

O foco aqui será a questão da gestão da memória RAM, mas o fato de usar o mesmo servidor também tem impacto na parte de processamento (vamos deixar isso para um post futuro abordando arquitetura :) ).

É fato que a engine relacional do SQL Server utiliza toda a memória disponível para ele, seja com cache de dados, planos e etc. A questão é que o Reporting Services também tenta fazer isso. E a velha máxima persiste: dois corpos não podem ocupar o mesmo local no espaço ao mesmo tempo.

Ok.. ok… traduzindo: a mesma porção de memória não pode ser ocupada por dois processos ao mesmo tempo.

Ambos são grandes consumidores de memória, mas se mesmo assim você quer colocar no mesmo servidor, ou então quer garantir que o funcionamento do SSRS ocorra sem pressionar a memória de outros processos ou do SO, a solução é configurar os thresholds de uso de memória.

Para a engine relacional, você consegue configurar os limites mínimos e máximos do consumo de memória (MinServerMemory e MaxServerMemory). No SSRS existem 4 parâmetros para isso e é importante além de conhece-los, saber qual o impacto no servidor.

Estes 4 parâmetros são configurados no arquivo de configuração chamado: RSReportServer.config.

A figura abaixo (extraída do BOL) mostra os limites e os parâmetros.

WorkingSetMaximum: Define o máximo de memória (em KBs) que o Reporting Services pode usar.

WorkingSetMinimum: Define o mínimo de memória (em KBs)  que o Reporting Services pode usar.

MemoryThreshold: Define o limite superior (percentual) da sessão de média pressão de memória.

MemorySafetyMargin: Define o limite superior (percentual) da sessão de baixa pressão de memória.

Um exemplo do arquivo de configuração (extraído do BOL) pode ser:

<MemorySafetyMargin>80</MemorySafetyMargin>
<MemoryThreshold>90</MemoryThreshold>
<WorkingSetMaximum>4000000</WorkingSetMaximum>
<WorkingSetMinimum>2400000</WorkingSetMinimum>

O importante de saber ANTES de se configurar/alterar estes parâmetros é entender como o SSRS funciona quando está em uma destas três zonas de pressão: baixa (low), média (medium) ou alta (high).

Baixa (Low): Todas as requisições são processadas, inclusive novas requisições também são aceitas. Requisições que necessitam de processamento em background continuam com uma menor prioridade.

Média (Medium): As requisições que estão executando continuam com seu processamento, enquanto que novas conexões são aceitas caso a caso. Alocações de memória de todos os application domains são reduzidas com grandes reduções dos processamentos em background. É dado prioridade maior aos requests gerados via web services e pela URL.

Alta (High): Não aceita novas requisições, e requisições por memória começam a ser negadas. O servidor inicia o processo de swap do estado para disco e as requisições atuais demoram mais.

Se por ventura atingir o teto máximo, o SQL Server Reporting services vai emitir erro HTTP 503. Em casos extremos o SSRS pode ter que reciclar o application domain.

Maiores informações sobre estas configurações podem ser encontradas aqui:
http://msdn.microsoft.com/en-us/library/ms159206.aspx

E era isso por hoje!

[]s!
Thiago Zavaschi

Assim como a engine do SQL Server e muitos outros produtos (Microsoft ou não), estes possuem um log de trace sobre o que acontece com o aplicativo/serviço, não acontece diferente no Reporting Services.

Os arquivos de trace log do Reporting Services variam de acordo com a versão do SQL Server. Até o SQL Server 2005 (onde ainda tinhamos dependência do IIS para o SSRS) haviam 4 tipos de arquivos de log que por padrão são limitados a 32MB por arquivo e são automaticamente deletados após 14 dias. Estes arquivos são texto plano, então qualquer editor de texto consegue abrir.

São eles:

ReportServerService_<timestamp>.log: Registra detalhes das operações (worker threads), como certas configurações do serviço, status das atividades de pesquisa relacionadas as assinaturas e notificações de entrega.

ReportServerService_main_<timestamp>.log: Registra os dados do serviço windows do Report Server e dos serviços Web (alocação de recursos do servidor, inicialização de configurações definidas nos arquivos de configuração).

ReportServerWebApp_<timestamp>.log: – Trace log do Report Manager.

ReportServer_<timestamp>.log: Trace log para o web service do Report Server.

Como o SSRS 2005 é uma versão antiga (temos 2008, 2008 R2 e 2012 após), não vou focar nela.

Maiores informações sobre os Trace Logs do SSRS 2005 e quais são os arquivos de configuração associados podem ser encontrados aqui: http://msdn.microsoft.com/en-us/library/ms156500(v=sql.90).aspx

O que muda a partir do SSRS 2008?

A partir do Reporting Services do SQL Server 2008, onde já não temos mais a dependência do IIS, os arquivos de trace log foram unificados. As especificações aqui comentadas são válidas para o SSRS 2008, 2008 R2 e 2012.

Os arquivos para o SSRS 2008+ ficam em (assumindo o local padrão):

[Program Files]\Microsoft SQL Server\MSRS<versao>.<nome da instância>\Reporting Services\LogFiles\

Existem alguns parâmetros de configuração para o Trace Log (vamos abordar sobre os arquivos de configuração em um post futuro). O arquivo de configuração para alterar propriedades do trace é o ReportingServicesService.exe.config. Por padrão este arquivo se localiza no diretório:

[Program Files]\Microsoft SQL Server\MSRS<versao>.<nome da instância>\Reporting Services\Report Server\bin\

As duas partes que devemos considerar são: DefaultTraceSwitch e o RSTrace. Um exemplo destas partes pode ser observado abaixo:

<system.diagnostics>

  <switches>

</switches>

</system.diagnostics>

</RStrace>

A propriedade DefaultTraceSwitch define o grau de informação que o arquivo de trace irá conter. O valor padrão é 3 e as possíveis definições se encontram a seguir:

• 0: Desabilita o trace.
• 1: Exceptions e restarts.
• 2: Exceptions, restarts, warnings.
• 3: Exceptions, restarts, warnings, status messages.
• 4: Verbose mode (maior grau de detalhamento).

As especificações para o RSTrace se encontram a seguir:

FileName: Indica a primeira parte do nome do arquivo de log.

FileSizeLimitMb: Tamanho em MB do arquivo de trace. Os valores podem ir de 0 até o máximo de um inteiro. Se especificar 0 ou um valor negativo, o SSRS entenderá como sendo 1.

KeepFilesForDays: Número de dias que os arquivos de trace serão mantidos. Os valores podem ir de 0 até o máximo de um inteiro. Se especificar 0 ou um valor negativo, o SSRS entenderá como sendo 1.

Prefix: É o valor gerado para distinguir um arquivo de log de outro e é concatenado no final do nome do arquivo (após o FileName). Não mexa nesta configuração. Por padrão é concatenado o timestamp.

TraceListeners: Especifica o destino do conteúdo do trace. Você pode especificar mais de um local (separando por vírgula). Os valores válidos são: DebugWindow, File (que é o padrão), StdOut.

TraceFileMode: Especifica que o arquivo de trace terá dados de um período de 24 horas. Você só deve ter um arquivo de log por componente por dia. O valor padrão é unique. Não mexa nesta configuração.

Components: Especifica os componentes para os quais as informações são geradas e o level de detalhe (mesmos da propriedade DefaultTraceSwitch). Um erro comum é achar que “all” se refere a todos os componentes, mas na realidade “all” se refere a tudo fora o que já é coberto pelos componentes específicos. As categorias dos componentes são as definidas a seguir:

• All: trace da atividade geral do report server que não estão inclusas nas demais categorias (mais específicas). Não desabilite este trace.
• RunningJobs: trace dos relatórios sendo executados atualmente.
• SemanticQueryEngine: Trace do processamento das queries semânticas de relatórios baseados em modelos.
• SemanticModelGenerator: usado para fazer trace da geração de modelos.
• http: usado para habilitar o arquivo de log HTTP do Report Server (por padrão não é habilitado. Para maiores informações: Report Server HTTP Log.

Para usar mais de um componente, basta concatenar com virgula. se desejar um grau de detalhamento maior ou menor (ou até mesmo desabilitar para algum componente) do que o configurado em DefaultTraceSwitch, basta utilizar a sintaxe <componente>:<level de trace>. Por exemplo:

<add name="Components" value="all,http:4,SemanticQueryEngine:0" />

Sem o IIS como vejo os logs de HTTP?

Um ponto importante é a questão do log para a parte de HTTP.

Legal, por padrão o log de http não é ativo, para ativá-lo devemos configurar na parte de Components na sessão RSTrace conforme vimos.

Os logs de HTTP depois de habilitados aparecerão junto aos Trace Logs que vimos. Estes logs contém campos padrão W3C, então da pra usar as ferramentas e queries atuais (usadas contra o IIS) para fazer parser destes arquivos.

Ao habilitar o HTTP Trace Log existem outras configurações para adicionarmos ao arquivo de configuração (dentro do <RSTrace>. Uma delas define o prefixo do nome do arquivo e o outro quais switches queremos monitorar. Segue um exemplo:

<add name=”HttpTraceFileName” value=”ReportServerService_HTTP_” />

<add name=”HttpTraceSwitches” value=”date,time,clientip,username,serverip,serverport,host,method,

uristem,uriquery,protocolstatus,bytesreceived,timetaken,

protocolversion,useragent,cookiereceived,cookiesent,referrer” />

Maiores informações sobre Trace Log no SSRS podem ser encontradas aqui: http://msdn.microsoft.com/en-us/library/ms156500(v=sql.110).aspx.

Maiores informações sobre o HTTP Log no SSRS a partir do SQL 2008 podem ser encontradas aqui: http://msdn.microsoft.com/en-us/library/bb630443.aspx.

Bom pessoal, o que queria mostrar hoje para vocês era isso.

[]s,

Thiago Zavaschi

Houveram diversas mudanças com objetivo de facilitar o licenciamento, tanto em cenários virtualizados ou físicos.

A Lívia Sarto que trabalha no time de produto de SQL Server na Microsoft Brasil fez três posts explicando as principais mudanças. Vale a pena a leitura, ainda que sejamos técnicos é algo interessante de se saber ao menos o básico!

Licenciando o SQL Server 2012 – Part I

Licenciando o SQL Server 2012 – Part II

Licenciando o SQL Server 2012 – Part III

Em breve teremos novos posts lá sobre licenciamento, então fiquem ligados. :)

Grande abraço!
Thiago Zavaschi

Hoje irei comentar um pouco sobre hierarquias no Analysis Services, seus benefícios e alguns dos parâmetros importantes quando definimos/criamos uma.

Os elementos que compõem uma dimensão são chamados de atributos. Estas dimensões são responsáveis por dar contexto às medidas (measures) numéricas contidas no cubo (total de vendas, quantidade de vendas ano sobre ano, entre outras de acordo com o seu negócio) e muitas vezes podem conter dezenas de atributos.

Com uma grande quantidade de atributos pode ser complicado a um usuário de uma ferramenta de análise (Excel por exemplo) navegar por estes atributos. Para facilitar esta navegação, podem ser criadas hierarquias dentro destas dimensões. Além de facilitar a navegação (drill down e drill up), o SSAS consegue se utilizar destas hierarquias (desde que os atributos tenham um relacionamento natural) para criar índices e agregações pré-calculadas e assim agilizar o tempo de resposta das queries dos usuários.

Por padrão todos os atributos são organizados em uma hierarquia de dois levels: o level “All” e o level folha. Esta hierarquia padrão pode ser desabilitada setando a opção IsAggregatable para falso (False).

Os tipos de hierarquias existentes são:

Hierarquias balanceadas (Balanced Hierarchies): neste tipo todos os ramos de uma hierarquia descendem de um mesmo level, e o “pai lógico” de cada membro é o level imediatamente superior.

Hierarquias não balanceadas (Unbalanced Hierarchies): os ramos descendem de levels diferentes.

Hierarquias pai-filho (Parent-Child Hierarchies): Hierarquias pai-filho são também hierarquias não balanceadas, pois a profundidade da hierarquia pode variar de acordo com o membro. E que também possuem um relacionamento de auto referência (self-referencing relashionship). O caso clássico desta hierarquia são em organogramas de empresas.

Hierarquias irregulares (Ragged Hierarchies): quando pelo menos o pai de um membro não esta no level imediatamente acima (e que não seja membro raiz, pois nesse caso não teria pai). Este tipo de hierarquia para o usuário final se parece com as do tipo pai-filho, porém os membros são de atributos diferentes.

Existem algumas propriedades muito importantes quando configuramos as dimensões (estas propriedades são setadas para os atributos da dimensão):

A primeira deles já comentamos que é se queremos ou não a utilização da hierarquia padrão: IsAggregatable.

Os próximos são:

AttributeHierarchyOrdered define se a hierarquia será ou não ordenada. Se estiver como falso (e se você apenas a utiliza para ordenar outra hierarquia de atributos) pode reduzir o tempo de processamento.

AttributeHierarchyOptimizedState pode ser configurado para NotOptimized para evitar qeu o SSAS crie indices nesta hierarquia de atributos. Diminui o tempo de processamento, mas irá aumentar o tempo de execução das queries que a utilizam (efeito gangorra).

AttributeHierarchyEnabled se esta propriedade estiver como falso a hierarquia de atributos será desabilitada e o SSAS criará como membro. É útil quando o atributo provê informações, mas você não quer usá-lo como level de agregação.

AttributeHierarchyVisible se essa propriedade estiver como falsa, o atributo só será visível em hierarquias definidas pelo usuário (user-defined hierarchies). Mesmo como falso ainda pode ser referenciado em expressões MDX.

Não preciso dizer que com grandes poderes vêm grandes responsabilidades né? Use estas configurações sabiamente e testem para ver os reais impactos e benefícios!

Bom pessoal, era isso por hoje!

[]s,
Thiago Zavaschi

O servidor de relatórios contido na suíte do SQL Server é muito usado e há uma série de características sobre ele que não usamos ou que desconhecemos que existe.

Hoje vou comentar sobre um dos pontos iniciais a se olhar quando são identificados problemas relacionados a performance no SSRS e indicar um direcionamento para a análise.

O primeiro ponto que podemos olhar é o Execution Log que nos provê dados relacionados às execuções de relatórios no servidor.

Há uma view que mapeia algumas tabelas (que podem ser usadas também, como a ExecutionLogStorage/ExecutionLog) chamada ExecutionLog2 e é encontrada na base de dados principal do Reporting Services (o nome padrão é ReportServer).

Esta view nos traz dados importantes e também já utiliza o hint NOLOCK para minimizar o impacto da sua execução. Entre eles podemos citar:

ReportPath: O caminho do relatório.

TimeStart: Horário de início do processamento. Um jeito interessante de fazer select na view ExecutionLog2 é ordenar por esta coluna.

TimeEnd: Horário de término do processamento. Relatórios que apresentam problemas de não completarem e que a diferença entre TimeEnd e TimeStart seja constante, podem indicar um problema de timeout das execuções.

TimeDataRetrieval: É o tempo que demora para o relatório obter os dados da fonte de dados (seja ela SSAS, SQL Server, Oracle, e assim por diante). Se é encontrado problema de performance neste ponto o indicado é verificar a otimização da query usada para o consumo dos dados e/ou verificar a fonte de dados se está corretamente implementada (índices, estatísticas, etc).

TimeProcessing: O tempo das operações que os relatórios utilizam como ordenação, agregação e filtro é contabilizado aqui (subrelatórios também são contabilizados nesta coluna). Para melhorar deve-se investigar se o relatório está fazendo as operações devidas. Uma boa prática é já passar ao relatório os dados na granularidade que irá precisar ao invés dos dados crus. Uma vez que, em geral, a agregação na fonte poderá ter um melhor desempenho.

TimeRendering: é o tempo que leva para tranformar do formato intermedíario para o formato renderizado. Os formatos mais custosos são Excel (é o mais), PDF, Word e TIFF.

A definição da View é a seguinte:

CREATE VIEW [dbo].[ExecutionLog2]
AS
SELECT
    InstanceName,
    COALESCE(C.Path, 'Unknown') AS ReportPath,
    UserName,
    ExecutionId,
    CASE(RequestType)
        WHEN 0 THEN 'Interactive'
        WHEN 1 THEN 'Subscription'
        ELSE 'Unknown'
        END AS RequestType,
    -- SubscriptionId,
    Format,
    Parameters,
    CASE(ReportAction)       
        WHEN 1 THEN 'Render'
        WHEN 2 THEN 'BookmarkNavigation'
        WHEN 3 THEN 'DocumentMapNavigation'
        WHEN 4 THEN 'DrillThrough'
        WHEN 5 THEN 'FindString'
        WHEN 6 THEN 'GetDocumentMap'
        WHEN 7 THEN 'Toggle'
        WHEN 8 THEN 'Sort'
        ELSE 'Unknown'
        END AS ReportAction,
    TimeStart,
    TimeEnd,
    TimeDataRetrieval,
    TimeProcessing,
    TimeRendering,
    CASE(Source)
        WHEN 1 THEN 'Live'
        WHEN 2 THEN 'Cache'
        WHEN 3 THEN 'Snapshot'
        WHEN 4 THEN 'History'
        WHEN 5 THEN 'AdHoc'
        WHEN 6 THEN 'Session'
        WHEN 7 THEN 'Rdce'
        ELSE 'Unknown'
        END AS Source,
    Status,
    ByteCount,
    [RowCount],
    AdditionalInfo
FROM ExecutionLogStorage EL WITH(NOLOCK)
LEFT OUTER JOIN Catalog C WITH(NOLOCK) ON (EL.ReportID = C.ItemID)

Bom pessoal, era isso que eu queria mostrar hoje. Espero que seja um ponto de partida para avaliar o que pode estar causando gargalos na geração dos seus relatórios.

Edit:

Bom para complementar segue um exemplo extraído aqui da saída da execução da view:

SELECT * FROM ExecutionLog2

InstanceName: SQL2008R2-SSRS\MSSQLSERVER                                ReportPath: /AdventureWorks 2008R2/AdventureWorks2008R2_Base
UserName: DENALI\Administrator  
ExecutionId: oxwvm3vl3n0mnyqlextnkujf                                        
RequestType: Interactive
Format: RPL
Parameters: ShowAll=False
ReportAction: Render
TimeStart: 2012-04-13 11:25:38.997
TimeEnd: 2012-04-13 11:25:40.560
TimeDataRetrieval: 0
TimeProcessing: 348
TimeRendering: 878
Source: Live  
Status: rsSucess
ByteCount: 1913           
RowCount: 0            
AdditionalInfo: <AdditionalInfo><ProcessingEngine>2</ProcessingEngine><ScalabilityTime>
<Pagination>0</Pagination><Processing>0</Processing></ScalabilityTime>
<EstimatedMemoryUsageKB><Pagination>0</Pagination><Processing>0</Processing>
</EstimatedMemoryUsageKB></AdditionalInfo>

E segue também a sugestão do Ildo (feita nos comentários) sobre utilização da view, valeu!

SELECT
[UserName]
,[ReportPath]
,COUNT([ReportPath]) as Executions
,( SELECT MAX(TimeStart) FROM [ReportServer].[dbo].[ExecutionLog2] as clog WHERE clog.UserName = olog.UserName AND clog.ReportPath = olog.ReportPath ) LastExecution
FROM [ReportServer].[dbo].[ExecutionLog2] as olog
WHERE [UserName] NOT IN ( ‘ildo’, ‘TKD-DB\sd’ )
GROUP BY [UserName], [ReportPath]
ORDER BY [UserName], [ReportPath]

[]s!