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_...@...> 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] >
