Limitação de Páginas em Relatório

Question

Boa tarde,

Gostaria de saber se eu tiver uma consulta que gere um relatório no Reporting Services de, por exemplo, 500.000 páginas..
Quais os problemas que terei para trazer esse resultado para o Reporting Services?

Outra dúvida é: o Reporting Services recebe o result inteiro do Engine e ele faz a paginação, ou o engine faz a paginação e devolve para o Reporting Services já paginado? Ex. Estou visualizando a página 1 do relatório. Quando peço a página 2, os dados todos estão em memória e o SSRS irá acessar a memória para trazer os dados, ou ele irá requisitar ao Engine aquele grupo de dados?



Obrigada pela ajuda!

---

Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

Answer 1

Boa tarde Mariana,

O único problema que você terá ao gerar um relatório de 500.000 páginas é questão de desempenho. Demorará algum tempo para gerar o relatório.

Quanto a sua outra pergunta, o relatório é gerado integral, as outras páginas ficam em cash. Porém, como a quantidade de dados é grande, demorará também para passar de página por página.

---

Rodrigo Ataíde.

Answer 2

Mariana, tudo depende da estrutura do seu relatorio.

Quando o reporting services precisar dos dados de um dataset para calcular uma data region, ele vai executar a query e ler o dataset por inteiro. Alguns calculos seram feitos no momento e outros somente quando requisitados. O reporting services vai processar o necessario para gerar a pagina que o usuario esta vendo, e ele mantera na sessao os dados do dataset, mas nao as paginas restantes, essas paginas seram processadas quando requisitadas. Se voce tem varias dataregions que dependem de datasets diferentes (por exemplo, pagina 1->10 vem do dataset1, paginas 11->21 do dataset2) os datasets podem ser executados somente quando voce chegar naqula pagina.

Eu acredito que um relatorio de 500.000 paginas nao sera muito pratico para um usuario, a recomendacao seria voce quebrar o seu relatorio usando parametros para que o seu usuario possa visualizaqr somente as partes que interessam a ele. Em alguns casos onde voce precisa arquivar relatorios grandes a performance nao eh um problema tao grande se voce usar subscriptions, fazendo com que o relatorio seja gerado no background.

O post abaixo do Robert explica um pouco como a on-demand engine funciona.

http://blogs.msdn.com/b/robertbruckner/archive/2008/08/11/on-demand-report-processing-in-rs-2008.aspx

Um detalhe, isso eh valido para os relatorios tradicionais, no caso do powerview que voce estava perguntando antes, o rs normalmente requisite dados paginados do analisys services.

Att

Boreki

---

Boreki[MSFT] - SQL Server Reporting Services

Answer 3

Boreki, muito obrigada novamente pela excelente resposta.

O que acontece é que meu cliente quer gerar e armazenar um relatório como um "livro fiscal". Então realmente o relatório deverá ser bem grande.

Se eu fizer por subscription e, por exemplo, salvar esse relatório como PDF em algum local da rede, esse relatório será processado totalmente de uma só vez e será salvo no local. Nesse momento, em termos de recurso do servidor, tenho que me preocupar principalmente com memória? Ou o uso da CPU é tão onerado quanto memória no processamento desse relatório?

Obrigada.

---

Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

Answer 4

Boreki, mais uma dúvida.

Se eu estiver usando um Dataset apenas, que irá gerar esse relatório imenso.

Posso ter erro no processamento desse relatório por falta de memória no servidor?

Obrigada!

---

Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

Answer 5

Mariana,

Sim, voce pode ter erro na geracao do relatorio se faltar memoria no servidor. Se voce estiver usando subscriptions o arquivo nao sera gerado (o RS nao vai gerar um arquivo parcial com as paginas processadas, ele ira descartar o arquivo).

Na geracao de arquivos grandes, o RS ira consumir tanto memoria quanto CPU. No caso de CPU o efeito colateral sera somente no tempo para gerar o relatorio (se voce estiver gerando outros relatorios por exemplo), dependendo do tamanho isso pode atingir timeout de geracao (por padrao se nao me engano sao 10 minutos). A politica do RS eh dar prioridade a requests de relatorios menores, entao se o seu relatorio estiver demorando muito e outros pedidos entrarem na fila, o RS pode reduzir a prioridade desse request para attender aos outros menores antes. A vantage eh que com subscriptions voce pode configurar para gerar o relatorio de madrugada, onde o servidor deve estar com menos carga.

Com relacao a geracao para PDF e outros formatos, nesse caso voce nao vai usar o on-demand processing, porque o arquivo inteiro tem que ser gerado antes do cliente poder fazer download.

Essa pagina discute algumas estrategias para trabalhar com relatorios grandes, recomendo dar uma lida:

http://msdn.microsoft.com/en-us/library/bb522786.aspx

Eu ainda acho recomendavel a voce quebrar o seu relatorio em pedacos menores, para ter tamanhos de arquivos mais gerenciaveis. Imagine como alguem iria abrir e trabalhar com um arquivo de 500k paginas no acrobat reader :)

Outro recurso que voce pode usar sao os report snapshots, cuja funcionalidade eh exatamente para arquivamento. O snapshot armazena os dados dos datasets e os dados de layout na base do reporting services, assim no future se voce precisar exporter esse relatorio novamente, mesmo que o datasource nao exista mais, o rs consegue exporter o mesmo relatorio.

Att

Boreki

---

Boreki[MSFT] - SQL Server Reporting Services

Answer 6

Muito obrigada!!

---

Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */