Bom dia Senhores,
Chiappa o que pode causar modificações no plano de execução de uma query?
Já tive um problema semelhante ao do Marcio, uma select que executava em 3
minutos apos uma coleta de estatisticas passou a demorar 30 minutos, no meu
caso a query foi desabilitada pois as informações que eram geradas não estavam
sendo mais utilizadas.
Obrigado,
Danilo
--- Em oracle_br@yahoogrupos.com.br, Márcio Ricardo Alves da Silva
escreveu
>
> Chiappa, foi me liberada uma máquina, identica a que tenho em produção, com o
> mesmo SO (HP-UX B.11.23) e seguirei a sua dica, darei uma estudada no patch
> para posteriormente atualizar em produção.
>
> Sobre o problema, suspeito também que possa ser o Plano de Execução, mas não
> sabia/sei como proceder para verificar.
>
> Onde eu trabalho, não temos um sysadmin, o pessoal que toma conta da infra
> não tem o conhecimento suficiente que deveria para administrar o SO.
>
> Como eu faço para ter os Planos de Execução guardados? Tenho várias querys
> grandes.
>
> Vou gerar o trace da maneira correta, e ver se me dá alguma luz.
>
> Grato,
> Márcio.
>
>
> - Original Message -
> From: José Laurindo
> To: oracle_br@yahoogrupos.com.br
> Sent: Wednesday, June 02, 2010 4:15 PM
> Subject: [oracle_br] Re: RES: [GPOracle] query de repente ficou
> muito demorada
>
>
>
> Algumas obs :
>
> 1) se vc está inseguro, estude e faça o patch apply pra 10.2.0.4 (saindo do
> 10.2.0.1 ** não ** é migração full, só o patch já resolve) , patcheando em
> bases de testes, na de homologação, antes de ir pra Prod... Mas imho é algo
> meio que Urgente vc ter a prod em versão - não é grande a chance de bug já
> corrigido estar causando o seu prob, mas até pode ser, E ao mesmo tempo há
> n+1! bugs Críticos corrigidos nos últimos patchsets, isso pode se solucionar
> OUTROS problemas com certeza
>
> 2) se apereceu "0 unique SQL statements in trace file.", vc COM CERTEZA fez
> errado o trace, o correto é :
>
> a) quando a sessão ABRE a conexão mas ANTES dela enviar os SQLs vc ativa o
> trace
> b) só com o trace Ativado vc executa, NA SESSÃO, os SQLs que te interessam
> c) vc TEM QUE ter os cursores fechados , GERANDO assim entradas no arquivo
> de trace - normalmente vc encerra a sessão para isso...
> http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:6793026818923
> mostra Exatamente um caso aonde o DBA falhou por isso
> d) o trace padrão traceja APENAS uma sessão, se o seu Aplicativo abre
> múltiplas sessões (por exemplo, gera relatórios chamando tool de relatórios
> que abre nova sessão, ou usa um POOL de conexões) evidentemente o evento
> 10046 sozinho não vai cobrir esses casos, como vc tá em 10g DBMS_MONITOR e
> TRCSESS vão ser as tools,
> http://www.oracle-base.com/articles/10g/SQLTrace10046TrcsessAndTkprof10g.php
> tem um exemplinho
>
> 3) O IDEAL seria vc ter os Planos de Execução de antes do fim de semana (na
> verdade a boa recomendação é vc SEMPRE ter os planos atuais para qquer SQL
> que leve mais de 30s/1minuto), com isso seria BICO se verificar se o plano
> mudou ou não, mas pelo cenário geral Imagino que isso não está disponível.
> Assim, penso que a análise de plano de execução vai ter que ser do modo
> difícil, ie, obtendo o Plano real dum trace, analisando se há como se redizir
> os LIOs (Logical IOs), por exemplo testando outros possíveis planos via
> HINTs...
>
> 4) O fato de vc dizer que está fazendo acesso por índice é INSUFICIENTE
> para concluirmos, nem sempre acesso por índice = melhor plano possível,
> TRANQUILAMENTE pode ser (por exemplo) que durante a outage de fim de semana
> que vc mencionou não foi feita a coleta de estatísticas adequada (digamos) ,
> aí o Plano mudou e passou a escolher um índice de uma das tabelas "grandes"
> ao invés do mais apropriado FTS paralelo na tabela grande... Como eu
> mencionei em 3) , em vc não tendo o plano anterior vc não tem base de
> comparação, então vais ter que testar Possibilidades
>
> 5) Até há alguma chance de o timeout/probs do fim de semana terem
> interferido no hardware, até indiretamente - por exemplo, não usaram as
> opções de CACHE ou de DIRECT ACCESS adequadas na hora de subir os
> filesystems, ou algum pau de hardware desabilitou o cache da controladoa...
> Já vi isso acontecer, mas é um caso RARO PRACAS - vc vai SIM checar com os
> sysadmins e o pessoal de storage possibilidades do tipo, MAS ainda acho que a
> mais provável é sim Plano de execução alterado...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, Márcio Ricardo Alves da Silva
> escreveu
> >
> > Pessoal, habilitei o trace e depois o TKPROF.
> >
> > no trace deu esse resultado:
> > Dump file /dsk1/wickbold/admin/udump/wickbold_ora_15630.trc
> >
> > Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
> >
> > ORACLE_HOME = /oracle/app/oracle/product/10.2.0
> >
> > System name:
