Olá Thiago, Seguem as informações:
1-) Qual a versão do banco?
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit
2-) Como vc esta coletando estatísticas para essa tabela??? ANALYZE ou
DBMS_STATS ???
Com DBMS_STATS, para todos os usuários através do comando
select 'execute dbms_stats.gather_schema_stats ('''||username||''');' from dba_
users;
3-) Está coletando para os índices também?
Não sei, mas como estou coletando por usuário então acho que deveria ir no bolo
tb. Mas qual o comando para fazer só com os indices??
4-) Está gerando histogramas para as colunas utilizadas nas restrições?
Não. Como faço isso
Obrigado mais uma vez, abs, André
--- Em sex, 20/6/08, Thiago Azevedo <[EMAIL PROTECTED]> escreveu:
De: Thiago Azevedo <[EMAIL PROTECTED]>
Assunto: Re: [oracle_br] Re: [usuarios_oracle] Ajuda novamente com uso de
indices num select banco 10g
Para: oracle_br@yahoogrupos.com.br
Data: Sexta-feira, 20 de Junho de 2008, 10:45
Mande as seguintes informações:
1-) Qual a versão do banco?
2-) Como vc esta coletando estatísticas para essa tabela??? ANALYZE ou
DBMS_STATS ???
3-) Está coletando para os índices também?
4-) Está gerando histogramas para as colunas utilizadas nas restrições?
Abçs
2008/6/20 André Alves <[EMAIL PROTECTED] com.br>:
>
> Olá Amigos, continuo com o problema de execução forçando o indice e sem o
> indice. Alguém poderia me dar mais uma ajuda??
>
> Fiz o seguinte:
>
> Rodei a query abaixo, 4 vezes seguidas, o tempo dela foi na sequencia:
> 05:23, 05:08, 05:38 e 05:40.
>
> select count(1) from tb_cdr_detraf a, tb_cdr b where a.id_cdr = b.id and
> b.data_ini between '20-may-08' and '21-may-08'
>
> Rodei a query abaixo, 4 vezes seguidas, o tempo dela foi na sequencia:
> 02:10, 00:12, 00:13 e 00:13.
>
> select /*+index (b IDX_CDR_UNIQUE) (a TB_CDR_DETRAF_ IND01) */
> count(1) from tb_cdr_detraf a, tb_cdr b where a.id_cdr = b.id and
> b.data_ini between '20-may-08' and '21-may-08'
>
> Minha dúvida: Como o banco está no modo Custo, rodando estatistica,
> teoricamente eu não devo mais utilizar "hint" no select certo ? O banco
> deveria escolher qual jeito mais rápido de executar a query. É isso mesmo ?
> Se for isso mesmo, nesse caso acredito que o banco não está escolhendo
> corretamente como rodar a 1º query, pq a 2º ficou bem mais rápida, ainda
> mais após a 1º execução.
>
> Qualquer ajuda é bem vinda.
> Obrigado, André
>
> --- Em dom, 15/6/08, Maraisa Aparecida Decker <maraisadecker@
> gmail.com<maraisadecker% 40gmail.com> >
> escreveu:
> De: Maraisa Aparecida Decker <maraisadecker@ gmail.com<maraisadecker%
> 40gmail.com>
> >
> Assunto: Re: [usuarios_oracle] Ajuda com uso de indices num select banco
> 10g
> Para: usuarios_oracle@ yahoogrupos. com.br<usuarios_oracle% 40yahoogrupos.
> com.br>
> Cc: "Grupo Oracle 1" <[EMAIL PROTECTED] os.com.br<oracle_br%40yahoog
> rupos.com. br>
> >
> Data: Domingo, 15 de Junho de 2008, 16:37
>
> Bom dia,
>
> pode ocorrer de as estatísticas do oracle não estarem atualizadas, e o
>
> otimizador do oracle acaba por não escolher o melhor plano de execução.
>
> Executa um analyze table para atualizar as statistics.
>
> 2008/6/12 André Alves <[EMAIL PROTECTED] com.br>:
>
> > Olá pessoal, alguém pode me ajudar a entender uma coisa?? Fiz o seguinte
>
> > select num banco 10g
>
> > select count(1) from tb_cdr_detraf a, tb_cdr b where
>
> > a.id_cdr = b.id and b.data_ini between '19-may-08' and '20-may-08'
>
> >
>
> > SELECT STATEMENT, GOAL = ALL_ROWS Cost=593867 Cardinality= 1 Bytes=19
>
> > SORT AGGREGATE Cardinality= 1 Bytes=19
>
> > FILTER
>
> > HASH JOIN Cost=593867 Cardinality= 813000 Bytes=15447000
>
> > INDEX FAST FULL SCAN Object owner=DBTRANS Object name=TB_CDR_
> DETRAF_IND01
>
> > Cost=390 Cardinality= 813000 Bytes=4878000
>
> > PARTITION RANGE ITERATOR Cost=591156 Cardinality= 1650846 Bytes=21460998
>
> > TABLE ACCESS FULL Object owner=DBTRANS Object name=TB_CDR Cost=591156
>
> > Cardinality= 1650846 Bytes=21460998
>
> >
>
> > O plano de execução fez um acesso FULL na tabela TB_CDR. Depois rodei o
>
> > seguinte:
>
> >
>
> > select /*+index (b IDX_CDR_UNIQUE) (a TB_CDR_DETRAF_ IND01) */
>
> > count(1) from tb_cdr_detraf a, tb_cdr b where
>
> > a.id_cdr = b.id and b.data_ini between '19-may-08' and '20-may-08'
>
> >
>
> > SELECT STATEMENT, GOAL = ALL_ROWS Cost=1825205 Cardinality= 1 Bytes=19
>
> > SORT AGGREGATE Cardinality= 1 Bytes=19
>
> > FILTER
>
> > HASH JOIN Cost=1825205 Cardinality= 813000 Bytes=15447000
>
> > INDEX FAST FULL SCAN Object owner=DBTRANS Object name=TB_CDR_
> DETRAF_IND01
>
> > Cost=390 Cardinality= 813000 Bytes=4878000
>
> > TABLE ACCESS BY GLOBAL INDEX ROWID Object owner=DBTRANS Object
> name=TB_CDR
>
> > Cost=1822494 Cardinality= 1650846 Bytes=21460998
>
> > INDEX RANGE SCAN Object owner=DBTRANS Object name=IDX_CDR_ UNIQUE
> Cost=10870
>
> > Cardinality= 1650846
>
> > Fiz o que eu na teoria pensando em regra acho certo, ele usou os devidos
>
> > indices.
>
> >
>
> > A 1º query rodou em 500 segundos. A 2º em 87. Ai vem a questão: se o 1º
>
> > plano o Oracle decidiu pelo uso das estatisticas que o acesso FULL nas
> duas
>
> > tabelas era melhor. Pq não foi ? É isso mesmo ?
>
> >
>
> > Obrigado a todos,
>
> > André
>
> >
>
> > ------------ --------- --------- ---
>
> > Abra sua conta no Yahoo! Mail, o único sem limite de espaço para
>
> > armazenamento!
>
> >
>
> > [As partes desta mensagem que não continham texto foram removidas]
>
> >
>
> >
>
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
>
>
>
>
>
>
>
>
> Abra sua conta no Yahoo! Mail, o único sem limite de espaço para
> armazenamento!
> http://br.mail. yahoo.com/
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
--
Thiago Azevedo
Accenture Brazil
Services - AO Carrefour
Work: 55 11 51888492
Mobile: 55 13 81453524
email: thiago.azevedo@ accenture. com
MSN IM: [EMAIL PROTECTED] com
[As partes desta mensagem que não continham texto foram removidas]
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para
armazenamento!
http://br.mail.yahoo.com/
[As partes desta mensagem que não continham texto foram removidas]
