Solucionando problemas de relatórios: Desempenho do relatório
Quando você exibe um relatório, espera um longo tempo antes de visualizar a primeira página. Para ajudar a determinar em que o tempo de processamento de relatório está sendo gasto, consulte Técnicas de resolução de problemas para problemas de relatório. Após determinar se o tempo de atraso se dá na recuperação de dados, no processamento de relatório ou na renderização do relatório, use este tópico para ajudar a solucionar problemas.
A recuperação dos meus dados demora muito
O processamento do meu relatório demora muito
A renderização do meu relatório demora muito
Dicas de design para otimização do processamento de relatório
A recuperação dos meus dados demora muito.
Mais dados de relatório requerem mais uso de recursos, mais tráfego de rede, mais tempo de processamento e mais armazenamento. Analise os problemas apresentados no seu relatório para determinar a quantidade de dados de que você precisa e recupere apenas esses dados das fontes de dados do relatório.
Mais dados são recuperados para um relatório do que o necessá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 idéias 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 Classificando dados em um relatório.
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 Preparando dados para exibição em uma região de dados do gráfico.
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 só estiver interessado em visualizar dados detalhados por algum tempo, um relatório de detalhamento é uma opção melhor. 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.
Tempo limite de consulta
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.
Para definir o valor de tempo limite para uma consulta de conjunto de dados, consulte Como criar um conjunto de dados (Reporting Services).
Grandes quantidades de tráfego de rede provocam tempos de espera para o usuário
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.
O processamento do meu relatório demora muito.
O processamento de relatório ocorre após a recuperação dos dados para conjuntos de dados de relatório, quando o processador de relatório combina o layout do relatório e os dados para criar um formato de relatório provisório que é passado ao renderizador de relatório. Em geral, o processador de relatório combina dados e layout somente para a página atual exibida pelo usuário. O tempo de processamento de relatório pode ser afetado pelo layout do relatório, paginação e expressões complexas nas áreas de um relatório que têm muitas instâncias.
Use esta seção para ajudar a melhorar o desempenho do processamento de relatório.
Expressões no cabeçalho ou rodapé da página forçam o processamento de todas as páginas
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.
Sem quebras de página no relatório
À 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 Entendendo os comportamentos de renderização.
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 (Reporting Services).
Agrupamento de região de dados Tablix complexo e funções de agregação
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 Usando funções internas de relatório e de agregação em expressões (Reporting Services).
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.
Muitas instâncias de sub-relatórios em uma região de dados Tablix tornam lento o desempenho do relatório
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.
Processos competindo pela mesma memória no servidor de relatório
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.
Tempos limite de execução do 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.
A diretiva 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.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.
A renderização do meu relatório demora muito.
A renderização do relatório ocorre após a combinação dos dados e do layout em um formato provisório e transmissão seguinte a uma extensão de renderização. O tempo de renderização pode ser afetado pela quantidade de dados, pelo número de instâncias de itens do relatório e pela paginação. Quando você exporta um relatório, está passando o formato provisório a um renderizador específico. Se você souber que os usuários exibem um relatório em um determinado formato, otimize o relatório para esse renderizador. Para obter mais informações, consulte Exportando relatórios e Entendendo os comportamentos de renderização.
Use esta seção para ajudar a melhorar o desempenho de renderização de um relatório.
O relatório não está otimizado para o formato de renderização escolhido
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.
Dicas de design para otimização do processamento de relatório
Se o desempenho do relatório for sua preocupação principal, use as seguintes informações para ajudá-lo a otimizar o tempo necessário para processar o relatório:
Para relatórios que tenham muitas instâncias de caixas de texto, defina CanGrow e CanShrink nas caixas de texto como FALSE. Por padrão, cada célula em uma região de dados Tablix contém uma caixa de texto, para que o número total de caixas de texto que precisam ser renderizadas possa crescer rapidamente.
Para relatórios que tenham muitas imagens, defina AutoSize nas imagens com um valor diferente, como Fit.
Para caixas de texto, evite definir a propriedade TextAlign como General. Esse valor requer processamento condicional, dependendo do conteúdo da caixa de texto.
Evite quebras de página horizontais quando isso não for necessário. Examine as margens, a largura das colunas e o espaço em branco em um relatório. Por exemplo, renderize o relatório para um arquivo .TIFF e exiba-o no Visualizador de Fax e Imagens do Microsoft Windows para determinar se páginas extras estão sendo renderizadas.
Defina a propriedade KeepTogether em membros de Tablix somente quando for necessário controlar o comportamento de renderização específico de uma região de dados Tablix. O recurso KeepTogether requer processamento extra durante o cálculo das quebras de página.