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 <marcio_...@...> 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 > muuuuuuuuuuuuuito 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:0::::P11_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 > <marcio_cbj@> 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: HP-UX > > > > Node name: hp_wk2 > > > > Release: B.11.23 > > > > Version: U > > > > Machine: ia64 > > > > Instance name: wickbold > > > > Redo thread mounted by this instance: 1 > > > > Oracle process number: 246 > > > > Unix process pid: 15630, image: oraclewickb...@hp_wk2 > > > > *** 2010-06-02 11:42:36.219 > > > > *** SERVICE NAME:(wickbold) 2010-06-02 11:42:36.218 > > > > *** SESSION ID:(277.31363) 2010-06-02 11:42:36.218 > > > > WAIT #16: nam='latch: cache buffers chains' ela= 20 > address=-4611686016021434152 number=122 tries=0 obj#=480259 tim=234511061104 > > > > *** 2010-06-02 11:42:53.407 > > > > WAIT #16: nam='latch: cache buffers chains' ela= 17 > address=-4611686016023487640 number=122 tries=0 obj#=480259 tim=234527847524 > > > > *** 2010-06-02 11:46:14.973 > > > > WAIT #16: nam='db file sequential read' ela= 4116 file#=55 block#=67427 > blocks=1 obj#=480935 tim=234724689089 > > > > *** 2010-06-02 11:46:56.627 > > > > WAIT #16: nam='db file sequential read' ela= 3886 file#=55 block#=20199 > blocks=1 obj#=480935 tim=234765367039 > > > > *** 2010-06-02 11:52:34.434 > > > > WAIT #16: nam='db file sequential read' ela= 2772 file#=54 block#=1051293 > blocks=1 obj#=480259 tim=235095256776 > > > > *** 2010-06-02 11:54:56.491 > > > > WAIT #16: nam='db file sequential read' ela= 4159 file#=55 block#=161108 > blocks=1 obj#=480935 tim=235233983662 > > > > *** 2010-06-02 11:57:21.895 > > > > WAIT #16: nam='db file sequential read' ela= 2883 file#=74 block#=13114 > blocks=1 obj#=480255 tim=235375979540 > > > > > > no TKPROF me apresentou isso: > > > > TKPROF: Release 10.2.0.1.0 - Production on Wed Jun 2 12:01:23 2010 > > > > Copyright (c) 1982, 2005, Oracle. All rights reserved. > > > > Trace file: /dsk1/wickbold/admin/udump/wickbold_ora_15630.trc > > > > Sort options: default > > > > > ******************************************************************************** > > > > count = number of times OCI procedure was executed > > > > cpu = cpu time in seconds executing > > > > elapsed = elapsed time in seconds executing > > > > disk = number of physical reads of buffers from disk > > > > query = number of buffers gotten for consistent read > > > > current = number of buffers gotten in current mode (usually for update) > > > > rows = number of rows processed by the fetch or execute call > > > > > ******************************************************************************** > > > > Trace file: /dsk1/wickbold/admin/udump/wickbold_ora_15630.trc > > > > Trace file compatibility: 10.01.00 > > > > Sort options: default > > > > 1 session in tracefile. > > > > 0 user SQL statements in trace file. > > > > 0 internal SQL statements in trace file. > > > > 0 SQL statements in trace file. > > > > 0 unique SQL statements in trace file. > > > > 29 lines in trace file. > > > > 0 elapsed seconds in trace file. > > > > > > > > Estou estudando para migrar para a versão 10.2.0.4, nunca apliquei patch > e não tenho segurança ainda para migrar. Mas independente de migrar, há 10 > dias atrás essa query demorava 5 minutos, agora passam de duas horas e nada. > Não sei se poderia ter algum problema com o SO ou disco. > > > > Grato, > > > > Márcio. > > > > ----- Original Message ----- > > From: Ricardo Cardoso de Sá > > To: gpora...@yahoogrupos.com.br ; oracle_br@yahoogrupos.com.br > > Sent: Tuesday, June 01, 2010 11:04 AM > > Subject: [oracle_br] RES: [GPOracle] query de repente ficou > muuuuuuuuuuuuuito demorada > > > > > > > > Márcio, > > > > Seria interessante voce coletar um trace extendido pelo tkprof > > > > Algo estranho notado, é a versão do seu banco 10.2.0.1, pois estamos na > > 10.2.0.4 + alguns mini-patchs. Não seria o caso de realizar upgrade neste > > release. > > > > Att.: > > > > Rjcard > > > > _____ > > > > De: gpora...@yahoogrupos.com.br [mailto:gpora...@yahoogrupos.com.br] Em > nome > > de Márcio Ricardo Alves da Silva > > Enviada em: terça-feira, 1 de junho de 2010 08:50 > > Para: oracle_br@yahoogrupos.com.br; gpora...@yahoogrupos.com.br > > Assunto: [GPOracle] query de repente ficou muuuuuuuuuuuuuito demorada > > Prioridade: Alta > > > > Boas. > > > > Tenho uma consulta em minha instância que geralmente demorava 5 minutos > para > > trazer a informação para o usuário. Ontem o usuário foi executar essa > > consulta, e a mesma passa de duas horas e não trás nada. > > > > Fica em esperda de db file sequential read, e as vezes latch free. Esse > > final de semana teve manutenção de energia, e o servidor foi desligado, > > teria alguma coisa com o SO(HP-UX 11.23)? > > > > A query utiliza algumas tabelas grandes, mas estão todas utilizando > índices > > sem forçar com os hints. > > > > Não sei mais onde eu posso olhar para corrigir ou achar o verdadeiro > > problema, alguém poderia me dar uma ajudinha? > > > > Oracle 10.2.0.1 > > > > Márcio. > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
