Bem Vindo a Comunidade Oracle no Brasil Bom dia... O problema era realmente a configuração do apache, que conforme foi falado pelo Luis, estava em 5 minutos...
Chiappa: Obrigado pelas informações e pela "discussão", todas foram extremamente utéis. Obrigado a todos ----- Original Message ----- From: oracle_br@yahoogrupos.com.br To: oracle_br@yahoogrupos.com.br Sent: Thursday, March 27, 2008 12:08 AM Subject: [oracle_br] Resumo 4799 Mensagens 1.1. Re: Timeout ao chamar reports server Enviado por: "Luis" [EMAIL PROTECTED] lcscabral Qua, 26 de Mar de 2008 10:38 am Ola Nao conheco a configuracao do Portal em detalhes, mas no Apache tem um parametro que controla o timeout, no arquivo Apache/conf/httpd.conf. O valor default sao 5 minutos: Timeout 300 Nao sei se vai ajudar, mas tente aumentar esse limite para ver se resolve seu problema. Isso resolveu pra mim, mas no meu caso a aplicacao era feita em Apex. Luis --- Em oracle_br@yahoogrupos.com.br, "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] > Voltar ao topo | através de email | Responder através da web Mensagens neste tópico (2) 2.1. Re: Timeout Reports Enviado por: "Davi Martinelli Benedetti - Yahoo" [EMAIL PROTECTED] davi_1710 Qua, 26 de Mar de 2008 10:58 am 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] Voltar ao topo | através de email | Responder através da web Mensagens neste tópico (2) 2.2. Re: Timeout Reports Enviado por: "jlchiappa" [EMAIL PROTECTED] jlchiappa Qua, 26 de Mar de 2008 7:11 pm Seguemn as respostas/comments para cada item : > > Onde eu escrevi DBA... os mesmos são responsáveis por ** toda ** a infra-estrutura dos ambientes de informática.... ohmygod, além de cuidar de banco, que normalmente já tem seus probleminhas. e de dar suporte/auxílio/mentoring em tecnologia de banco (não desenvolver, mas dar as dicas e estabelecer políticas) pros desenvolvedores/utilizadores, que é parte integrante de qquer dba (em diferentes porcentagens, mas enfim) os seus DBAs ainda cuidam de infra-estrutura ?? rapaaaz, eses merecem o que ganham :) > . 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. De modo algum desculpas são necessárias, só vejo como difícil um DBA normalmente já preocupado com tuning/segurança/backup/políticas de uso/monitoração e tudo o mais que um banco omplexo de Produção exige ter como fazer esse tipo e trabalho extra, mas se na sua empresa é assim, então tá.... Normalmente pelo que conheço não é tanto assim, por isso que sugeri que o DBAs não seriam o primeiro recurso a acionar... > > Eu de fato mesmo procurei pra ver se existiam documentos que referenciassem como esse timeout pudesse ser aumentado.... 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. OK, mas já que vc ** não ** disse explicitamente o que tinha feito, o que tinha lido, por isso indiquei a documentação : na bem da verdade, sempre que vc abrir uma thread no fórum, se vc já disser o que fez, o que leu, o resultado da sua tentativa em aplicar o que leu/estudou, coisas do tipo, isso SEMPRE adianta o expediente.... > > 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. Pra podermos dizer que realmente um SQL foi explorado ao máximo, vc ** REALMENTE ** aplicou os recursos "avançados" de SQL, tal como analytics, WITH clause, subquery factoring ?? Vc ** realmente **, junto com o DBA, testou a aplicação de planos alternativos, via hints ? Vc testou os alteradores de comportamento de um SQL via ALTER SESSION, tais como db_file_multiblock_read, OPTIMIZER_MODE, params controladores de SGA/PGA ?? VC desmontou o SQL ? Com "desmontar" quero dizer, normalmente num join há um conjunto restrito de tabelas que trazem o "core" dos dados, as outras trazem algum lookup, coisa do tipo : reduzir o SQL ao mínimo num primeiro momento tirando as tabs acessórias é uma técnica comum de estudo... Parallel SQL pode ser uma boa, ependendo do caso... Ebfim, para declarar um SQL como totalmente otimizado, ao menos essas coisas todas eu tentaria/pediria pra verificar junto com os DBAs.... > Views materializadas não se aplicam aqui devido ao fato da necessidade do relatório apresentar dados on-line. Aqui saímos do tuning de SQL em si e vamos para a área de melhoria de storage dos dados, mas é comum isso acontecer,uma pode influenciar a outra... ==> Primeiro, é Assertiva absolutamente *** FALSA *** essa de que VMs só servem para snapshot de dados com atraso, há anos vc já pode especificar um VM com REFRESH ON COMMIT, aí a vm é atualizada ONLINE, EM CONJUNTO com a tabela, representado os dados absolutamente REAIS e ÚLTIMOS da tabela... veja vc, com certeza se a massa de dados é grande vc NÂO DEVE estar lendo/apresentando linha a linha no seurelatório, FATALMENTE vc faz algum tipo de agrupação/contagem, yes ? A idéia da vm é vc ter uma vm ATUALIZADA, que já contenha a agrupação desejada, assim AO INVÉS DE vc ter que ler os não sei quantos milhões de linhas para descobrir o resultao, a vm JÀ CONTÉM o resultado prontinho.... NEM SEMPRE isso é totalmente possível, principalmente se o relatório é dinâmico e a cada vez o usuário quer agrupar por coisas diferentes, mas SE houver como se definir isso á priori, a vm é mão na roda total...Obviamente, além de tudo a vm é um objeto FÌSICO, que ocupa espaço, e além disso há um pequeno OVERHEAD pra que ela seja atualiada, mas de forma alguma elas deveriam ter sido descartadas e antemão, se o foram reveja isso, junto com o DBA...Eu digo DBA, porque normalmente é ELE quem conhece em profundidade os etups/privs/etc necessários para se usar uma dada feature. ==> Segundo, reforço aqui que além de evitar leitura para operações que vc já poderia saber a resposta com a vm, a outra idéia quando se fala em massa "estratosférica" é vc "separar" os dados que precisa : assim, se particionando os dados vc evitar ter que acessar N partições, ok... Ou ainda, tal como eu falei na msg anterior, índices condicionais podem ser uma boa : afinal, normalmente não são exatamente TODOS os dados da tabela-monstro X ou Y que vc quer, normalmente há uma flag ou alguma coluna com algum domínio especial que vc quer, ** SE ** vc criar um índice aonde só esses registros entrem puff, vc evitou um monte de I/O por linhas que ao final as WHEREs descartariam.... Num cliente anterior (por exemplo) numa tabela de dezenas de milhões era só umas poucas centenas de milhares que eu precisava acessar (de acordo com uma coluna de STATUS, com um domínio próprio) : o pessoal tinha criado um índice normal, não adiantou picas, pois um index range scan num índice de dezenas de milhões ainda é horroroso, daí eu criei um ídnice aonde só entravam os registros que eu queria e mandei brasa num index fast full scan desse índice (que ficou minúsculo), foi um susto pro pessoal a performance que deu... da mesma forma, Clusters, índices bitmap, star-joins, todos esses recursos podem providenciar algum "grau" de separação... > > 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? O que eu propus é : a tela que hoje dispara o reports diretamente passaria a, via DBMS_JOB, disparar uma PROCEDURE em background (assim a tela pode até ** DESCONECTAR ** do banco, evitando timeouts, poupando recursos !!), e essa procedure após preencher a tabela de resultados ela sinaliza esse término pra tela, que aí sim dispara o report, que como eu diosse vai ser rapidinho já que vai fazer só um SELECT * FROM tabeladeresultados.... Há n+1! maneiras de uma procedure se "comunicar" com um programa externo ao banco, uma low-tech poderia simplesmente ser que ela GRAVE um arquivo-texto via utl_file num local a que a tela do usuário possa ler em pooling, sendo que em modo web na verdade reside lá no servidor web, via de regra permissão/mapeamento de pastas entre duas máquinas não é problemático... Ou ainda, a procedure poderia popular uma linha duma tabela de jobs quando terminar, e a tela de usuário a cada minuto abre uma conexão, testa a tabela, se não existe evolve a conexão e "dorme" por mais um minuto, coisa assim... > ...No entanto, acaba dando timeout na página do navegador durante o processo de inserção dos dados via append na tabela de resultados... é óbvio, é o que eu falei acima, o truque é vc fazer o trabalho DENTRO do banco via job, não disparar de FORA via conexão externa que tem que ser mantida... Blz ? Bom, de modo geral, sem detalhar muito, é + ou - isso que eu queria dizer, espero que as idéias que te passei sejam de alguma forma úteis, esse é sempre o objetivo de todos aqui, bater papo, dar sugestões, dar dicas sobre tecnologia de banco de dados Oracle, é por aí... []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 =========================================================== Voltar ao topo | através de email | Responder através da web Mensagens neste tópico (2) [As partes desta mensagem que não continham texto foram removidas]
