Solucionando problemas de relatórios: Desempenho do relatório

O filtro, a classificação e a agregação são mais eficientes na fonte de dados do que durante o processamento de um relatório. Escreva consultas para retornar apenas o nível de detalhes mostrado no relatório. A lista a seguir sugere ideias para avaliar cada consulta no relatório:

• Escreva consultas com cláusulas WHERE ou HAVING que limitem os dados a apenas o que o usuário precisará ver no relatório. Use parâmetros de consulta para restringir dados recuperados em tempo de execução. Os parâmetros de consulta são associados automaticamente aos parÂmetros de relatório correspondentes e permitem que um usuário decida em quais dados está interessado. Para obter mais informações, consulte Filtrando linhas utilizando WHERE e HAVING.

  Quando você cria um relatório de instantâneo que tem parâmetros de relatório que filtram os dados, todos os dados possíveis que poderiam ser exibidos no relatório devem ser salvos no instantâneo. Nesse caso, não use parâmetros de consulta nas consultas de banco de dados. Em vez disso, crie manualmente parâmetros de relatório que você possa usar nas expressões de filtro para permitir que o usuário especifique os dados de relatório desejados.

• Escreva consultas com a cláusula ORDER BY para classificar previamente os dados recuperados para um relatório. Classifique os dados na ordem desejada para o relatório. Os dados previamente classificados melhoram o tempo de processamento de relatório devido ao modo como são armazenados na memória. Muitas tarefas de processamento de relatório não exigem a classificação de dados antes de processá-los. Por exemplo, SUM não depende de ordem. Os dados dentro de instâncias de grupo não são classificados automaticamente. Se for necessário classificar dados no relatório, não defina expressões de classificação no conjunto de dados ou na região de dados. Para obter mais informações, consulte Cláusula ORDER BY [Transact-SQL] e Como classificar dados em uma região de dados (Construtor de Relatórios 3.0 e SSRS).

  Classificar grupos ou classificar por valores agregados é muito mais simples no relatório do que na consulta e, quase sempre mais eficiente também..

• Escreva consultas com GROUP BY para agregar valores na fonte de dados.

  Muitas vezes, a maneira mais efetiva de transmitir informações é agregando valores e exibindo resumos. Você pode calcular algum nível de agregações na fonte de dados e recuperá-las para um conjunto de dados. Os dados "detalhados" no conjunto de dados agora representam agregações calculadas com base na fonte de dados. Para obter mais informações, consulte Resumindo resultados da consulta (Visual Database Tools).

  Depois que esses valores agregados previamente estiverem em um relatório, você poderá continuar agregando os valores, desde que esteja usando uma função agregada matematicamente transitiva, por exemplo, SUM. Por exemplo, vamos supor que você tenha uma conjunto de 6 valores: 1, 2, 3, 4, 5, 6. Se você agrupar os valores em pares, terá um conjunto de 3 valores: 3, 7, 11. Você pode calcular a soma no primeiro conjunto (21) e pode calcular a soma do segundo conjunto (21) e as somas serão iguais, independentemente do agrupamento. Se você calcular a média dos valores nos conjuntos usando a função AVG, obterá um resultado diferente para cada conjunto. A média para o conjunto de 6 é 21/6 ou 3,5. A média para o conjunto de 3 é 21/3 ou 7. AVG não é uma função transitiva.

• Considere a quantidade de dados necessária para um gráfico ou indicador. Desenhar centenas de pontos em alguns pixels em um monitor prejudica o desempenho e não melhora a exibição dos elementos gráficos. Utilizar mais de 7 ou 8 fatias em um gráfico de pizza é questionável. Para obter mais informações, consulte as informações sobre tipos de gráficos específicos em Tipos de gráficos (Construtor de Relatórios 3.0 e SSRS).

• Para reportar itens com visibilidade condicional, o processador de relatório deve aplicar expressões de agrupamento, classificação e filtragem, mesmo que apenas o nível superior de dados esteja visível no início. Embora o processamento por demanda no SQL Server 2008 Reporting Services optimize a avaliação de dados processando apenas os dados visíveis, todos os dados possíveis fazem parte do relatório. Se o usuário estiver interessado somente em visualizar dados detalhados por algum tempo, um relatório de detalhamento é a melhor opção. Para obter mais informações, consulte Tipos de relatórios.

• Considere a criação de instantâneos de execução para um relatório. Um instantâneo de relatório inclui todos os dados de relatório recuperados para os conjuntos de dados na definição do relatório. Para obter mais informações, consulte Criando, modificando e excluindo instantâneos no histórico de relatório.

Os valores de tempo limite de consulta são especificados durante a criação do relatório quando você define um conjunto de dados. O valor de tempo limite é armazenado com o relatório, no elemento Timeout da Consulta. Por padrão, este valor é definido como 30 segundos. Para obter mais informações, consulte Definindo valores de tempo limite para processamento de relatórios e conjuntos de dados compartilhados (SSRS).

Para definir o valor de tempo limite para uma consulta de conjunto de dados, consulte Como criar um conjunto de dados compartilhado ou um conjunto de dados inserido (Report Builder 3.0 e SSRS).

Grandes quantidades de dados passados como tráfego de rede podem introduzir tempos de espera para o usuário. Dependendo da sua base de usuários esperada e do volume esperado de exibições de relatório, você pode selecionar o método apropriado para implantar componentes de servidor de relatório. Para obter mais informações, consulte Planejando uma topologia de implantação.

Por exemplo, as seguintes estratégias talvez ajudem a reduzir os tempos de espera para o usuário:

• Mantenha o catálogo do servidor de relatório no mesmo computador que o servidor de relatório.

  O banco de dados do servidor de relatório, tempdb, gerencia dados de relatório recuperados para cada consulta de conjunto de dados em uma definição de relatório. Manter os dados de relatório no processador de relatório reduz o tráfego de rede que pode tornar lenta a execução do relatório.

• Para fontes de dados de data warehouse, mantenha o data warehouse em um servidor separado do servidor de relatório.

  Embora a recuperação de dados na rede não adicione uma tarefa extra à execução do relatório, ter o data warehouse e o Reporting ServicesServices disputando a memória no mesmo servidor pode prejudicar o desempenho.

Quando você inclui uma referência ao campo interno [&TotalPages], o processador de relatório precisa paginar todo o relatório antes que possa renderizar a primeira página. Se não houver referência a [&TotalPages], a primeira página poderá ser renderizada e retornada ao usuário imediatamente, sem o processamento do resto do relatório. Além disso, o processador de relatório pressupõe que qualquer expressão complexa no cabeçalho ou rodapé da página poderá conter uma referência direta ou indireta a [&TotalPages].

Para evitar que o processador de relatório pagine um relatório longo, não inclua uma referência para [&TotalPages] ou qualquer expressão complexa no cabeçalho ou no rodapé da página.

À medida que um usuário percorre um relatório, o processador do relatório combina dados e informações de layout para cada página do relatório e passa a página ao renderizador de relatório. Para um relatório sem quebras de página, todo ele deve ser processado antes que o usuário possa exibir a primeira página.

Um renderizador de quebra de página flexível, como o visualizador HTML, controla automaticamente a paginação para você. É possível substituir esse comportamento automático e definir o relatório como tendo uma página definindo a propriedade InteractiveHeight do relatório como 0. Para renderizadores de quebra de página não flexíveis, você deve adicionar quebras de página manualmente. Para obter mais informações sobre tipos de renderizadores, consulte Compreendendo os comportamentos de renderização (Construtor de Relatórios 3.0 e SSRS).

Verifique se InteractiveHeight não é 0 e se está definida para algum tamanho de página razoável, por exemplo, 8.5 in. Adicione quebras de página aos itens de relatório ou grupos Tablix para ajudar a organizar o relatório em páginas. Isso reduz a quantidade de dados que devem ser processados para cada página. Para obter mais informações, consulte Como adicionar uma quebra de página (Construtor de Relatórios 3.0 e SSRS).

Muitos níveis de grupos aninhados e adjacentes em uma região de dados Tablix podem afetar o desempenho do processamento do relatório. Considere o nível de agrupamento, o número de instâncias de grupo e o uso de funções agregadas que requerem avaliação após a aplicação de expressões de agrupamento, filtro e classificação. Por exemplo, Previous é uma função agregada 'cara' porque seu valor depende dos elementos classificados de uma região de dados; Sum não depende da ordem e requer menos recursos. Outras agregações pós-classificação incluem First e Last. Para obter mais informações, consulte Referência de funções de agregação (Construtor de Relatórios 3.0 e SSRS).

Avalie o design do seu relatório e considere se alguma agregação de dados pode ocorrer na fonte de dados. A redução da quantidade de dados no relatório talvez seja suficiente para proporcionar um desempenho aceitável sem alterar nenhuma chamada de função agregada.

Entenda as vantagens e desvantagens do uso de sub-relatórios. Cada instância de sub-relatório é uma execução de consulta separada e uma tarefa de processamento de relatório separada.

• Não use sub-relatórios quando houver apenas algumas instâncias de sub-relatórios.

• Não use sub-relatórios dentro de um grupo quando houver muitas instâncias de grupo. Por exemplo, para exibir uma lista de vendas e devoluções de cada cliente, considere o uso de relatórios de detalhamento. Considere se você pode gravar a consulta para unir o cliente com as vendas e devoluções e depois agrupar por ID de cliente.

• Use sub-relatórios quando o sub-relatório tiver uma fonte de dados diferente do relatório principal. Se o desempenho for um problema, considere alterar a consulta de conjunto de dados no relatório principal usando uma das seguintes estratégias de atenuação:

  • Colete dados em um data warehouse e use-o como fonte de dados para um único conjunto de dados.

  • Use servidores vinculados do SQL Server e escreva uma consulta que recupere dados de vários bancos de dados.

  • Use o recurso OPEN ROWSET para especificar bancos de dados diferentes.

Vários aplicativos que competem pelos mesmos recursos de memória em um servidor de relatório podem afetar o processamento do relatório.

Trabalhe com o administrador de sistema para verificar se a configuração de gerenciamento de memória é o modelo correto para o uso do servidor de relatório. Para obter mais informações, consulte Configurando memória disponível para aplicativos do Servidor de Relatório.

Para executar relatórios grandes, há dois tempos limite que você deve ajustar: tempo limite de execução do relatório e tempo limite de ASP.NET.

Os valores de tempo limite de execução de relatório podem ser especificados no servidor de relatório. Para obter mais informações, consulte Definindo valores de tempo limite para processamento de relatórios e conjuntos de dados compartilhados (SSRS).

A política de tempo limite de ASP.NET é controlada pelo arquivo de configuração do servidor de relatório. O local padrão para esse arquivo é <unidade>:\Arquivos de Programa\Microsoft SQL Server\MSRS10_5.MSSQLSERVER\Reporting Services\ReportServer\web.config. Para definir o número máximo de segundos em que uma solicitação pode ser executada, adicione o elemento httpRuntime a esse arquivo:

<configuration>
   . . .
   <system.web.
      . . .
      <httpRuntime executionTimeout="90"/>
      . . .
   </system.web.
   . . .
</configuration>

Dependendo do tamanho do relatório, talvez esse valor tenha que representar várias horas.

Alguns recursos não têm suporte em todos os renderizadores. Se o formato primário para exibição de um relatório for um tipo de arquivo específico, talvez seja necessário modificar o design de relatório para otimizar a experiência de exibição do usuário.

• Adicione quebras de página quando isso fizer sentido. Por exemplo, cada quebra de página define uma nova planilha no Excel. Cada planilha pode ter 65000 linhas, no máximo. Considere esses limites quando definir as quebras de página em um relatório.

• Para exportar para o Excel, não mescle células em uma região de dados Tablix. Em relatórios de forma livre, alinhe os itens verticalmente. As células mescladas e os itens de relatório não alinhados interferem com a funcionalidade do Excel no relatório exportado.

• Analisadores HTML não são eficientes para renderizar páginas HTML muito grandes. Se você tiver dificuldade para renderizar um relatório, selecione um formato que produza um arquivo menor (por exemplo, CSV). Se não puder selecionar outro formato porque a barra de ferramentas de relatório não está disponível, defina uma assinatura para configurar um formato de renderização e entregar o relatório como um documento estático em um compartilhamento de arquivos. Para obter mais informações, consulte Entrega de compartilhamento de arquivos no Reporting Services.