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 bruni...@gmail.com To: oracle_br@yahoogrupos.com.br 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 daniloh2...@yahoo.com.brescreveu: 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 oracle_br%40yahoogrupos.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 oracle_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 é : 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
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 bruni...@gmail.com bruniera%40gmail.com
To: oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br
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
daniloh2...@yahoo.com.brdaniloh2000%40yahoo.com.br
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
oracle_br%40yahoogrupos.com.broracle_br%
40yahoogrupos.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
oracle_br%40yahoogrupos.com.broracle_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 é :
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
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 daniloh2...@yahoo.com.brescreveu: 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 oracle_br%40yahoogrupos.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 oracle_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 é : 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 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 oracle_br%40yahoogrupos.com.br, Márcio Ricardo Alves da Silva marcio_cbj@
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 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=
