Bom dia Chiappa

Primeiramente, muito obrigado pela resposta...

Onde eu escrevi DBA, leia-se que na empresa onde trabalho, apesar de a 
atribuição principal dos referidos profissionais é ser administrador de banco 
de dados, os mesmos são responsáveis por toda a infra-estrutura dos ambientes 
de informática, desde configuração do banco de dados propriamente dito até a 
configuração dos servidores e tudo mais o que é implicado com a configuração da 
infra-estrutura dos ambientes. A mim me parece que tais atribuições andam 
frequentemente juntas, mas no entanto peço desculpas se a regra de fato é que 
essa não é uma atribuição de um DBA.

Eu de fato mesmo procurei pra ver se existiam documentos que referenciassem 
como esse timeout pudesse ser aumentado. De cara encontrei esse documento:
http://download.oracle.com/docs/cd/B14099_19/core.1012/b13996/reports.htm
No entanto, como essa parte de configuração de ambiente e infra-estrutura não é 
especificamente minha praia, procurei o grupo em busca de respostas de 
profissionais mais ligados ao contexto. Foi esse meu intuito.

Quanto a otimização do relatório, o mesmo já foi otimizado o máximo possível e 
não estamos obtendo mais resultados significativos. A massa de dados é 
estratosférica, e rodar em menos de 10 minutos, que é a atual situação já é uma 
performance excepcional, no entanto, ainda insuficiente considerando a questão 
do timeout. Views materializadas não se aplicam aqui devido ao fato da 
necessidade do relatório apresentar dados on-line. 

Quanto a abordagem de rodar via job, parece interessante, mas pergunto: a 
funcionalidade web "schedularia" o job, que levaria em torno de 5 a 10 minutos 
para rodar... Como fazer para que depois desse tempo, o relatório seja 
disponibilizado para o utilizador? Vale ressaltar que já tentamos a seguinte 
abordagem: antes do relatório, chamar uma procedure que popula a tabela de 
resultados, e depois chamar o report. No entanto, acaba dando timeout na página 
do navegador durante o processo de inserção dos dados via append na tabela de 
resultados, ou seja, antes da chamada do reports server. Nesse caso, o timeout 
ocorre na atual sessao do portal. Esse timeout também é configurável? (reitero 
novamente minha "ignorancia" neste assunto, e a intenção de um grupo como esse 
é a troca de informações e experiências)...

Abraços

Davi

Ps: Solicitei ao administrador que fizesse a alteração do parametro referido no 
documento abaixo, posto aqui se houve resultado ou não...

Re: [EMAIL PROTECTED] 


     
Colega, primeiro eu tenho que dizer que era mesmo ** DUVIDOSO ** que
os DBAs pudessem te ajudar - veja só, por definição um DBA é
Administrador de Banco de dados, especialista em tecnologias de **
Banco de Dados ** e uma página web roda FORA do banco de dados, é
algo normalmente fora do escopo de atuação de um DBA.... O que um DBA
poderia (e mesmo deveria) ter feito por vc , SE a tua Empresa tem
Contrato de Suporte válido para o reports seria abrir um chamado, e se
tem para outro produto Oracle qualquer poeria ao menos ter consultado
a documentação extendida/artigos extras em metalink.oracle.com
Sem ser DBA, o que vc poderia ter feito é consultar a Documentação do
Reports, ela está online em tahiti.oracle.com e é de grátis pra
todos... Numa consulta rápida, de cara caí em
http://www.oracle.com/webapps/online-help/reports/10.1.2/state/content/navId.3/n\
avSetId._/vtTopicFile.rptoem_hs%7Ctasks%7Crptoem_configure_repsrvr~html/
, nessa página do manual no item Viewing and Changing the Reports
Server Configuration Files ele fala do parâmetro de idle timeout, deve
ser isso o que vc quer.... O ponto só é que isso implica em alterar
arqs no servior, e normalmente um servidor de produção (deve ser o
caso, imagino) fica sob responsabilidade de um sysadmin, vc
provavelmente terá que pedir pra que ele o faça...
Afora isso, duas outras dicas :

a) hoje não sou mais Desenvolvedor, mas na minha época muitas vezes
usei tabela de resultados no reports : veja vc, se esse relatório
demora um montão, certamente ele tem no data model uma query
ultra-complexa e/ou mexe com tabelas muito muito grandes, certo ? Ora,
num caso desses ao invés de fazer o Reports (ou o reports Server, no
caso) ficar trabalhando, às vezes é mais interessante vc ter uma
tabela com as mesmas colunas que a query do report precisa e fazer a
tela que dispara o Report executar uma PROCEDURE de banco (em
background via DBMS_JOB se for o caso), que roda a query real e bota
os resultados na tabela de resultados via INSERT append, o Report
passa a ser um simples SELECT * FROM tabeladeresultados ....

b) NÃO deixe de trabalhar junto com o DBA no ajuste desse SQL, há
diversos objetos de banco (como Views materializadas, índices de
função, analytics) que podem te ajudar em muito, mas quase todos
exigem algum setup/ajuste/concessão de permissão por parte do DBA

[]s

Chiappa

===========================================================
Participe do ENPO - Encontro de Profissionais Oracle 2008 !
Informações e inscrições em http://www.enpo-br.org
José Laurindo Chiappa, Palestrante ENPO-2008
===========================================================

--- Em [EMAIL PROTECTED], "Davi Martinelli Benedetti
- Yahoo" <[EMAIL PROTECTED]> escreveu
>
> Boa tarde a todos
>
> Trabalho como desenvolvedor em ambiente Oracle Portal. É um mix de
pl/sql, html, ajax, javascript, css, xml e por ai vai. Buenas. A
questão é o seguinte. Temos diversos relatórios, alguns pesados, e que
acabam por demorar mais que 5 minutos, ocasionando num timeout, e
dando erro de página não encontrada.
>
> Pergunta: como configurar o tempo de timeout para o reports server,
evitando que dê erro de pagina nao encontrada? ( e por consequencia,
aumentando o tempo de processamento e mostrando o relatorio para o
usuario)...
>
> A proposito, o processo no reports server nao morre, continua
executando em background após esses 5 minutos (atual tempo de
timeout), mas não é possivel de ser visualizado pelo usuario.
>
> Ps: Sou desenvolvedor, e gostaria de trocar uma idéia se é possivel
aumentarmos esse tempo de timeout e como fazelo, tendo em vista que os
dbas da empresa q trabalho não conseguiram achar uma solução.
>
> Forte abraço
>
> Davi
>
> [As partes desta mensagem que não continham texto foram removidas]
>



[As partes desta mensagem que não continham texto foram removidas]

Responder a