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
> 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.br<daniloh2000%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.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><oracle_br%
> 40yahoogrupos.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: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><oracle_br%
> 40yahoogrupos.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
> > > > <GPOracle%40yahoogrupos.com.br><GPOracle%
> 40yahoogrupos.com.br> ;
> > oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br><oracle_br%
> 40yahoogrupos.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 <GPOracle%40yahoogrupos.com.br>
> > > > <GPOracle%40yahoogrupos.com.br>[mailto:
> > gpora...@yahoogrupos.com.br <GPOracle%40yahoogrupos.com.br> <GPOracle%
> 40yahoogrupos.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
> > > > <oracle_br%40yahoogrupos.com.br><oracle_br%
> 40yahoogrupos.com.br>;
> > gpora...@yahoogrupos.com.br <GPOracle%40yahoogrupos.com.br> <GPOracle%
> 40yahoogrupos.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]
> > >
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> ------------------------------------
>
>
> ----------------------------------------------------------
> >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de
> inteira
> >responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> ----------------------------------------------------------
> >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package »
> >Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO
> ESPAÇO!
> >VISITE: http://www.oraclebr.com.br/
> ----------------------------------------------------------
> Links do Yahoo! Grupos
>
>
>
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
--------------------------------------------------------------------------------------------------------------------------
>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira
>responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------
>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure »
>Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE:
>http://www.oraclebr.com.br/
------------------------------------------------------------------------------------------------------------------------
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
<*> Para sair deste grupo, envie um e-mail para:
oracle_br-unsubscr...@yahoogrupos.com.br
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
