Ah, detalhe importantíssimo - se o passo zero é saber pelo que o banco está
procurando, o passo 1 na sequência é obter info dos SQLs mais importantes,
sendo principalmente :
- o plano de execução ** REAL ** dos SQLs mais importantes da rotina (tirados
da V$SQL_PLAN e correlatas)
- as estatísticas de execução dos SQLs (tal como tempo gasto, linhas linhas ,
etc), que vc obtém na V$SQL
Comparando essas infos de uma execução "ruim" com uma eventual execução "boa"
certamente deve ser esclarecedor...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchiappa@...> escreveu
>
> Colega, absolutamente ** não tem mágica ** quando se fala de performance
> degradada : o passo ZERO, inicial, é saber exatamente pelo que o processo
> está esperando, não tem por onde - a tool básica para isso é trace+tkprof, e
> ver quais waits vc está tendo...
> Outra boa possibilidade no OWB seria, já que ele pode gerar um stored PL/SQL
> com a rotina (procedure, normalmente) , vc introduzir alguma INSTRUMENTAÇÃO,
> nem que seja coisas simples como adicionar chamadas à
> DBMS_APPLICATION.SET_CLIENT_INFO, tipo :
>
>
> .....
> dbms_application_info.set_client_info('vou entrar loop em:'
> || to_char(sysdate, 'hh24:mi:ss'));
> for r in (select colunachace, outras colunas from tabelas)
> loop
> dbms_application_info.set_client_info('loop1 key#'
> || r.colunachave
> || to_char(sysdate, 'hh24:mi:ss'));
> for i in outrocursorbuscandodetalhes do acima
> loop
> dbms_application_info.set_client_info('loop2 key#'
> || r.colunachave
> || to_char(sysdate, 'hh24:mi:ss'));
> .....
>
>
> Aí numa outra sessão vc vai consultando a coluna CLIENT_INFO da sessão que
> está executando o PL/SQL....
> Outro procedimento muito muito muito aconselhável é vc, no instante que der
> a demora, diversas vezes ir consultando na V$SESSION as colunas de wait, e
> consultar as views de waits, de locks e de estatísticas do sistema, E também
> rodar alguma tool que mostre de modo geral o status do banco
> (statspack/awr/ash, o que vc tiver licenciado na sua versão de banco), que vc
> deve ter umas pistas da causa ....
> Eu digo pistas porque há ** DIVERSAS ** causas possíveis para um cenário tal
> qual vc descreve, que vão desde esperas por locks ou latches até simplesmente
> banco temporariamente sobrecarregado , ou até mesmo picos temporários de rede
> ...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "lrmaross" <lrmaross@> escreveu
> >
> > Amigos preciso de um auxílio.
> >
> > Tenho um processo de ETL entre dois servidores regionalmente separados
> > trocando informações via DBLINK. Este cenário eu já tenho a mais de 5 meses
> > e até então não vinha tendo problemas de performance. Há alguns dias, meu
> > processo de ETL passou a apresentar grandes problemas de performance e de
> > forma intermitente - o mesmo processo fica excessivamente lento e, quando o
> > re-inicio, tudo volta ao normal. Alguns dias nem temos problemas de
> > performance.
> > Já cheguei a deixar um processo executando durante mais de 5 horas e ele
> > não finalizou e, ao executa-lo novamente ele transcorre naturalmente como e
> > nada ocorresse. Acrescento também que o problema não ocorre sempre no mesmo
> > ponto, ele alterna as tabelas do meu processo de ETL.
> > Já coletei estatistica, solicitei uma análise da rede (que esta muito boa),
> > verifiquei indices, alterei parâmetros ARREYSIZE, executei a query criada
> > pelo OWB via SQLPLUS, via TOAD, e a lentidão se manteve igual. Abri um
> > chamado na ORACLE e a resposta que obtive foi de que deveria ser problema
> > de rede. Analisando a parte FISICA da rede não identificamos nada que
> > pudesse estar comprometendo a performance, na realidade a rede esta bem
> > tranquila no momento que os processos executam.
> >
> > O que pode estar acontecendo?
> >
> > Obrigado.
> >
> > Luis R.
> >
>
