[oracle_br] Re: RES: [GPOracle] query de repente ficou muuuuuuuuuuuuuito demorada
te ajudar, talvez... > > Sobre o problema, suspeito também que possa ser o Plano de Execução, mas não sabia/sei como proceder para verificar. Já que (pelo jeito) vc não tem os Planos anteriores guardados para comparar com o atual, qquer análise de por que o plano mudou (e mesmo SE mudou, cfrme eu disse acima até pode ter piora de performance com o mesmo plano) fica impossibilitada... Em outra ocasião vc perguntou como se faz pra guardar os planos dos SQLs mais importantes, isso varia, dependendo se é um aplicativo extenso (com dezenas de relatórios e centenas de telas de consulta) ou não, se podem haver SQLs ad-hoc ou não , mas vc pode ter um JOB que coleta os SQLs que julgar importantes pro negócio os respectivos planos e grava em tabelas suas a partir da V$SQL / V$SQL_PLAN / V$SQL_PLAN_STATISTICS, OU pode executar o sistema com trace 10046 ativos e guardar os arqs gerados, OU mesmo se forem poucos SQLs os tracejar manualmente, fica a critério. Na situação atual, sem essa info, eu sugiro que vc tente obter planos diferentes pro SQL em questão , pra isso vc : a. tente SIMPLIFICAR o SQL ao extremo mas ainda tendo demora : muito provavelmente ele deve ser um monstrengo que envolve N tabelas, tenta ir tirando as tabelas secundárias e menores de lookup,tira UNION, ORDER BY, etc, deixa só o "osso", só o 'tópico principal' do SQL b. tenta dar mais informação pro CBO, ie : recoletar as estatísticas com um AUMENTO no estimate (ou mesmo com COMPUTE), aumentar o SIZE dos seus histogramas, coletar as estatísticas de sistema (dbms_stats.get_system_stats) c. tenta alterar o ambiente (via ALTER SESSION que seja) aumentando quantidade de blocos lidos por vez, tamanho de áreas de HASH e sort Se nada resultou num plano aceitável, aí sim vc pode tentar ir pros HINTs, mas (como eu disse em outra msg) isso *** não *** quer dizer só escrever um /*+ INDEX nomedatabela,nomedoindice */, é ** mais profundo ** que isso : pelo jeito que vc descreve, o que deve estar acontecendo é que o SQl deve estar fazendo nested loops (ie, lê uma linha da tabela drive, busca os detalhes via índice, le outra linha, busca os detalhes pra essa linha, assim por diante varrendo a tabela drive até o final) : isso é Excelente se a tabela escolhida é pequena, e Horroroso se a tabela-drive for grande, aí seria o caso de tentar um hint indicando o MËTODO DE ACESSO ALTERNATIVO que o CBO deve usar (um HASH join, um SORT-MERGE join, o que for) e não apenas o nome do índice envolvido... Acho que nas restrições de tempo/esforço aqui do Fórum, acho que esses são os conselhos que poderia te dar - e claro, mais referências para valores que podem ser alterados para influcenciar COB, como coletar estatísticas de forma mais completa e considerações do tipo , goto documentação Oracle, em especial o manual de Tunning. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "daniloh2000" escreveu > > 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
Re: [oracle_br] Re: RES: [GPOracle] query de repente ficou muuuuuuuuuuuuuito demorada
brother voce roda como
vou mandar um ai pra voce de como eu faço pra ver se ajuda, esse query gera
o comando para todas as tables.
---
SELECT 'exec dbms_stats.gather_table_stats(ownname=>' || CHR(39) || ds.owner
||
CHR(39) || ',tabname=>' || CHR(39) || ds.segment_name || CHR(39) ||
',estimate_percent => 100' || ',cascade => TRUE' ||
',degree=> 8' ||',granularity=> ' || CHR(39) || 'AUTO' || CHR(39) ||
',method_opt=>' || CHR(39) ||
' FOR ALL COLUMNS SIZE 1' || CHR(39) || ' );' "analyze"
from dba_segments ds
where ds.owner in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5','SCHEMA6','SCHEMA7')
and ds.segment_type = ('TABLE')
order by ds.bytes desc;
---
Em 7 de junho de 2010 08:07, Márcio Ricardo Alves da Silva <
marcio_...@yahoo.com.br> escreveu:
>
>
> Duilio, as tabelas com pequenas faço as coletas todos os dias. As tabelas
> que tenho milhões de registros, faço um dia sim e outro não.
>
> Fiz o procedimento de shrink em algumas tabelas e índices, sugeridos pelo
> EM, e após isso coletei as estatísticas do schema todo.
>
> Márcio.
>
> - Original Message -
> From: "Duilio Bruniera Junior" >
> To: >
> Sent: Sunday, June 06, 2010 3:35 AM
> Subject: Re: [oracle_br] Re: RES: [GPOracle] query de repente ficou
> muito demorada
>
> pessoal, sem querer parecer imbecil uma vês alguém comentou um script de
> coleta de statistica da crontab depois de 4 dias algumas querys de
> instantâneas passaram há 3 horas. Marcio voce ja olhou quando foi a ultima
> vês que você fez uma coleta de estatisca na sua base/schema ?
>
> Em 4 de junho de 2010 09:06, daniloh2000
>
> >escreveu:
>
> >
> >
> > 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
> > 40yahoogrupos.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
> > > 40yahoogrupos.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 é :
> &
Re: [oracle_br] Re: RES: [GPOracle] query de repente ficou muuuuuuuuuuuuuito demorada
Duilio, as tabelas com pequenas faço as coletas todos os dias. As tabelas que tenho milhões de registros, faço um dia sim e outro não. Fiz o procedimento de shrink em algumas tabelas e índices, sugeridos pelo EM, e após isso coletei as estatísticas do schema todo. Márcio. - Original Message - From: "Duilio Bruniera Junior" To: Sent: Sunday, June 06, 2010 3:35 AM Subject: Re: [oracle_br] Re: RES: [GPOracle] query de repente ficou muuuuuito demorada pessoal, sem querer parecer imbecil uma vês alguém comentou um script de coleta de statistica da crontab depois de 4 dias algumas querys de instantâneas passaram há 3 horas. Marcio voce ja olhou quando foi a ultima vês que você fez uma coleta de estatisca na sua base/schema ? Em 4 de junho de 2010 09:06, daniloh2000 escreveu: > > > 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:6793026818923mostra > > 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.phptem > > 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
Re: [oracle_br] Re: RES: [GPOracle] query de repente ficou muuuuuuuuuuuuuito demorada
pessoal, sem querer parecer imbecil uma vês alguém comentou um script de coleta de statistica da crontab depois de 4 dias algumas querys de instantâneas passaram há 3 horas. Marcio voce ja olhou quando foi a ultima vês que você fez uma coleta de estatisca na sua base/schema ? Em 4 de junho de 2010 09:06, daniloh2000 escreveu: > > > 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:6793026818923mostra > 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.phptem > 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
[oracle_br] Re: RES: [GPOracle] query de repente ficou muuuuuuuuuuuuuito demorada
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, ha
Re: [oracle_br] Re: RES: [GPOracle] query de repente ficou muuuuuuuuuuuuuito demorada
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: 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=
[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: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: 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
