Este alter session está restrito a esta sessão apenas.
Se vc colocar no Report, todo mundo vai gerar trace, então é melhor
gerar só com voce no sistema.

Com poucos usuários no banco, a performance será melhor, mas vc ainda
verá o problema raiz, pode acreditar.


Ricardo Portilho Proni
Coordenador de Bancos de Dados - Solvo S/A
- Oracle Database 10g Administrator Certified Professional (OCP)
- Microsoft Certified Professional (MCP)
- Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)




Em Seg, 2008-10-27 às 21:25 +0000, urubullino escreveu:
> Caro Ricardo,
> antes de tudo obrigado.
> Nao seria interessante colocar o trace no 
> na trigger 'before report' do Reports?
> Poderia ficar assim?
> srw.do_sql('ALTER SESSION SET TRACEFILE_IDENTIFIER =
> "RelatorioLentoQueSoEle"' );
> srw.do_sql('ALTER SESSION SET TIMED_STATISTICS = TRUE');
> srw.do_sql('ALTER SESSION SET EVENTS "10046 trace name context
> forever, level 12");
> 
> alguma coisa no 'after report' ?
> 
> Uma pergunta...Esse alter session está restrito ao usuario solicitante
> do relatorio? Pq nao adiantaria tanto se tiver outros usuarios tambem
> fazendo consultas no banco.
> 
> Falando em acessos, suponho que poucos usuarios acessando o banco, a
> performance seria melhor; enquanto se muitos usuarios estiverem
> acessando , seria pior . Como analisar isso? Eu teria que fazer o
> trace depois do horario de expediente, quando ninguem estaria usando o
> sistema? E depois, como avaliar se a quantidade de acessos estaria
> compromentando a performance. E mais tarde, como melhorar isso, caso
> seja comprovado esse problema?
> 
> Obrigado mais uma vez e desculpe por tantas duvidas
> 
> --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni
> <[EMAIL PROTECTED]> escreveu
> >
> > Oi.
> > 
> > Como um colega já disse aqui, antes de solucionar o problema de
> > performance, você precisa ter certeza onde o TEMPO deste relatório
> está
> > sendo gasto.
> > 
> > Você consegue rodar este relatório com trace?
> > Para isso, uma das formas é colocar isso antes do SELECT que faz
> este
> > relatório:
> > 
> > ALTER SESSION SET TRACEFILE_IDENTIFIER = 'RelatorioLentoQueSoEle';
> > ALTER SESSION SET TIMED_STATISTICS = TRUE;
> > ALTER SESSION SET EVENTS '10046 trace name context forever, level
> 12';
> > 
> > Depois que ele terminar, procure pelo arquivo com
> RelatorioLentoQueSoEle
> > no nome, e execute:
> > 
> > tkprof arquivo
> > 
> > E coloque o resultado aqui pra gente.
> > 
> > 
> > 
> > Ricardo Portilho Proni
> > Coordenador de Bancos de Dados - Solvo S/A
> > - Oracle Database 10g Administrator Certified Professional (OCP)
> > - Microsoft Certified Professional (MCP)
> > - Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)
> > 
> > 
> > 
> > 
> > Em Sáb, 2008-10-25 às 16:30 +0000, urubullino escreveu:
> > > Oi pra todos.
> > > não conheco muita coisa de oracle mas aqui vai um problema que
> nunca
> > > deixou o sistema em que trabalho...
> > > Temos uma aplicacao com inumeras tabelas e muuuiitos registros.
> Usamos
> > > o Oracle Reports e em muitos casos os relatórios demoram uma
> > > eternidade para serem executados, em torno de HORAS...
> > > Por pesquisa cheguei a conclusao que uma view materializada
> poderia
> > > resolver o assunto , o Report iria acessar essa view . Mas o
> usuario
> > > quer ver essa informacao quase que instantaneamente quando a mesma
> é
> > > inserida ou modificada. A view materialized seria mesmo a melhor
> opcao
> > > ou teria outra, mesmo com ferramentas de terceiros ?
> > > Para dar uma acelerada ainda maior , também estou estudando outros
> > > geradores de relatorios que possam executar a tarefa mais rapido
> que o
> > > Oracle Reports... Alguma dica?
> > > 
> > > Obrigado a todos. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> 
> 
> 
> 
> 
>  


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

Responder a