Re: [oracle_br] Índices no Oracle
Sim, as estatísticas são atualizadas automaticamente 1 vez por dia (se tiver alteração de registros, claro), só não respondi ainda porque não estudei como ver o tipo de estatística (chiappa me pediu isso). Em 4 de fevereiro de 2014 19:01, Milton Bastos Henriquis Jr. < miltonbas...@gmail.com> escreveu: > > > Vc está pelo menos com estatísticas atualizadas? > Quando vejo algum tipo de lentidão, é a primeira coisa que verifico. > > > > > Em 4 de fevereiro de 2014 14:23, Yuri Menon escreveu: > > >> >> Chiappa, terei de fazer todo um estudo para responder seus >> questionamentos (tendo em vista que nunca ouvi falar nem de E-ROW, por >> exemplo), mas responderei, ok? >> >> Milton, de imediato você sabe me responder se é possível reduzir o tempo >> dessa consulta utilizando algum procedimento no qual eu não precise alterar >> a estrutura da consulta SQL? Ou você precisa que eu responda primeiro as >> perguntas do chiappa? obs: não tenho acesso a programação da ferramenta >> entende? Por isso, se me pedirem para eu colocar um HINT no meio dessa SQL >> não vai ser possível, já se pedirem para eu criar um índice, vai ser >> tranquilo porque acesso ao banco eu tenho. >> >> >> Em 4 de fevereiro de 2014 13:31, Milton Bastos Henriquis Jr. < >> miltonbas...@gmail.com> escreveu: >> >> >>> >>> Como eu imaginava! Por isso lá no meu primeiro e-mail eu perguntei >>> quantos registros tinha no total dessa tabela. >>> >>> Vc tá retornando 12858 registros, num universo de 71933. É uma >>> porcentagem muito alta. >>> Não vale a pena usar índice, por isso o Oracle está fazendo full scan. >>> >>> Mas por que ele usa índice quando pede só essa coluna? >>> Porque os próprios valores que vc quer já estão no índice - e daí fica >>> muito menos custoso consultar apenas a estrutura de índice, pois nela já >>> contém todos os valores que vc quer. >>> >>> >>> Em 4 de fevereiro de 2014 11:28, Yuri Menon escreveu: >>> >>> Banco: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production PL/SQL Release 11.2.0.3.0 - Production CORE 11.2.0.3.0 Production TNS for 64-bit Windows: Version 11.2.0.3.0 - Production NLSRTL Version 11.2.0.3.0 - Production Fábio Prado, explain plan do SELECT * FROM TMOV WHERE CODCXA = '401609' Plan hash value: 235420782 -- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -- | 0 | SELECT STATEMENT | | 12936 | 4737K| 1377 (1)| 00:00:17 | |* 1 | TABLE ACCESS FULL| TMOV | 12936 | 4737K| 1377 (1)| 00:00:17 | -- Explain Plan do SELECT CODCXA FROM TMOV WHERE CODCXA = '401609': Plan hash value: 3125576660 | Id | Operation| Name| Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT STATEMENT | | 12936 | 90552 |34 (0)| 00:00:01 | |* 1 | INDEX RANGE SCAN| IDX_TMOV_CODCXA | 12936 | 90552 |34 (0)| 00:00:01 | Outras consultas: SQL>SELECT COUNT(1) FROM TMOV 71933 SQL>SELECT COUNT(1) FROM TMOV WHERE CODCXA = '401609' 12858 SQL>SELECT DISTINCT CODCXA FROM TMOV 44 resultados Muito obrigado pessoal, estou lendo e compreendendo (o que é mais importante, claro) todas as respostas. Em 3 de fevereiro de 2014 22:54, escreveu: > > Colega, tudo jóia ? Sim, ainda estou vivo , e de vez em quando ainda > passo por aqui :) > > Sobre as suas perguntas , seguinte : NÃO, não é verdade que > Obrigatoriamente um SELECT * "força" um full-table scan, e para a idéia de > que seria preciso indexar todas as colunas para que um SELECT * usar > índice, a resposta é : bullshit, bobeira, absurdo, ridículo, siiim ?? > Aliàs, antes de demonstrar, vamos pensar juntos : um índice ** não > ** acelera uma consulta por magia de unicórnio ou pó de pirlimpimpim : > entre outras coisas (como a questão de organização interna que permite > busca por 'poda' de valores), o fato é que um índice simplesmente é uma > "tabela reduzida", que tem só as colunas-chave e o rowid de cada linha, > assim é por isso que uma busca no índice é mais rápida, o índice é > MUITÍSSIMO MENOR, né ?? Vc não acha que s
Re: [oracle_br] Índices no Oracle
Vc está pelo menos com estatísticas atualizadas? Quando vejo algum tipo de lentidão, é a primeira coisa que verifico. Em 4 de fevereiro de 2014 14:23, Yuri Menon escreveu: > > > Chiappa, terei de fazer todo um estudo para responder seus questionamentos > (tendo em vista que nunca ouvi falar nem de E-ROW, por exemplo), mas > responderei, ok? > > Milton, de imediato você sabe me responder se é possível reduzir o tempo > dessa consulta utilizando algum procedimento no qual eu não precise alterar > a estrutura da consulta SQL? Ou você precisa que eu responda primeiro as > perguntas do chiappa? obs: não tenho acesso a programação da ferramenta > entende? Por isso, se me pedirem para eu colocar um HINT no meio dessa SQL > não vai ser possível, já se pedirem para eu criar um índice, vai ser > tranquilo porque acesso ao banco eu tenho. > > > Em 4 de fevereiro de 2014 13:31, Milton Bastos Henriquis Jr. < > miltonbas...@gmail.com> escreveu: > > >> >> Como eu imaginava! Por isso lá no meu primeiro e-mail eu perguntei >> quantos registros tinha no total dessa tabela. >> >> Vc tá retornando 12858 registros, num universo de 71933. É uma >> porcentagem muito alta. >> Não vale a pena usar índice, por isso o Oracle está fazendo full scan. >> >> Mas por que ele usa índice quando pede só essa coluna? >> Porque os próprios valores que vc quer já estão no índice - e daí fica >> muito menos custoso consultar apenas a estrutura de índice, pois nela já >> contém todos os valores que vc quer. >> >> >> Em 4 de fevereiro de 2014 11:28, Yuri Menon escreveu: >> >> >>> >>> Banco: >>> Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit >>> Production >>> PL/SQL Release 11.2.0.3.0 - Production >>> >>> CORE 11.2.0.3.0 Production >>> >>> TNS for 64-bit Windows: Version 11.2.0.3.0 - Production >>> >>> NLSRTL Version 11.2.0.3.0 - Production >>> >>> >>> Fábio Prado, explain plan do SELECT * FROM TMOV WHERE CODCXA = '401609' >>> >>> >>> Plan hash value: 235420782 >>> >>> >>> -- >>> >>> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time >>> | >>> -- >>> >>> >>> | 0 | SELECT STATEMENT | | 12936 | 4737K| 1377 (1)| 00:00:17 >>> | >>> >>> |* 1 | TABLE ACCESS FULL| TMOV | 12936 | 4737K| 1377 (1)| 00:00:17 >>> | >>> -- >>> >>> >>> Explain Plan do SELECT CODCXA FROM TMOV WHERE CODCXA = '401609': >>> >>> Plan hash value: 3125576660 >>> >>> >>> >>> | Id | Operation| Name| Rows | Bytes | Cost >>> (%CPU)| Time | >>> >>> | 0 | SELECT STATEMENT | >>> | 12936 | 90552 |34 (0)| 00:00:01 | >>> |* 1 | INDEX RANGE SCAN| IDX_TMOV_CODCXA | 12936 | 90552 |34 >>> (0)| 00:00:01 | >>> >>> >>> >>> >>> Outras consultas: >>> SQL>SELECT COUNT(1) FROM TMOV >>> 71933 >>> >>> SQL>SELECT COUNT(1) FROM TMOV WHERE CODCXA = '401609' >>> 12858 >>> >>> SQL>SELECT DISTINCT CODCXA FROM TMOV >>> 44 resultados >>> >>> >>> >>> Muito obrigado >>> pessoal, estou lendo e compreendendo (o que é mais importante, claro) todas >>> as respostas. >>> >>> >>> >>> Em 3 de fevereiro de 2014 22:54, escreveu: >>> >>> Colega, tudo jóia ? Sim, ainda estou vivo , e de vez em quando ainda passo por aqui :) Sobre as suas perguntas , seguinte : NÃO, não é verdade que Obrigatoriamente um SELECT * "força" um full-table scan, e para a idéia de que seria preciso indexar todas as colunas para que um SELECT * usar índice, a resposta é : bullshit, bobeira, absurdo, ridículo, siiim ?? Aliàs, antes de demonstrar, vamos pensar juntos : um índice ** não ** acelera uma consulta por magia de unicórnio ou pó de pirlimpimpim : entre outras coisas (como a questão de organização interna que permite busca por 'poda' de valores), o fato é que um índice simplesmente é uma "tabela reduzida", que tem só as colunas-chave e o rowid de cada linha, assim é por isso que uma busca no índice é mais rápida, o índice é MUITÍSSIMO MENOR, né ?? Vc não acha que se vc criar um índice com TODAS as colunas da tabela, vc não acaba tendo uma estrutura de tamanho + ou - similar à da tabela ??? Que vantagem Maria leva Segundo ponto : o RDBMS Oracle (ao menos desde a versão 8i, mas principalmente a partir do 9i) largou mão de otimização RBO e adotou a CBO, ie : ele ** não ** adivinha, ** não ** usa "regras" para decidir se usa ou não o índice, se é mais vantajoso ler a t
Re: [oracle_br] Índices no Oracle
Chiappa, terei de fazer todo um estudo para responder seus questionamentos (tendo em vista que nunca ouvi falar nem de E-ROW, por exemplo), mas responderei, ok? Milton, de imediato você sabe me responder se é possível reduzir o tempo dessa consulta utilizando algum procedimento no qual eu não precise alterar a estrutura da consulta SQL? Ou você precisa que eu responda primeiro as perguntas do chiappa? obs: não tenho acesso a programação da ferramenta entende? Por isso, se me pedirem para eu colocar um HINT no meio dessa SQL não vai ser possível, já se pedirem para eu criar um índice, vai ser tranquilo porque acesso ao banco eu tenho. Em 4 de fevereiro de 2014 13:31, Milton Bastos Henriquis Jr. < miltonbas...@gmail.com> escreveu: > > > Como eu imaginava! Por isso lá no meu primeiro e-mail eu perguntei quantos > registros tinha no total dessa tabela. > > Vc tá retornando 12858 registros, num universo de 71933. É uma > porcentagem muito alta. > Não vale a pena usar índice, por isso o Oracle está fazendo full scan. > > Mas por que ele usa índice quando pede só essa coluna? > Porque os próprios valores que vc quer já estão no índice - e daí fica > muito menos custoso consultar apenas a estrutura de índice, pois nela já > contém todos os valores que vc quer. > > > Em 4 de fevereiro de 2014 11:28, Yuri Menon escreveu: > > >> >> Banco: >> Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit >> Production >> PL/SQL Release 11.2.0.3.0 - Production >> >> CORE 11.2.0.3.0 Production >> >> TNS for 64-bit Windows: Version 11.2.0.3.0 - Production >> >> NLSRTL Version 11.2.0.3.0 - Production >> >> >> Fábio Prado, explain plan do SELECT * FROM TMOV WHERE CODCXA = '401609' >> >> >> Plan hash value: 235420782 >> >> >> -- >> >> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time >> | >> -- >> >> >> | 0 | SELECT STATEMENT | | 12936 | 4737K| 1377 (1)| 00:00:17 >> | >> >> |* 1 | TABLE ACCESS FULL| TMOV | 12936 | 4737K| 1377 (1)| 00:00:17 >> | >> -- >> >> >> Explain Plan do SELECT CODCXA FROM TMOV WHERE CODCXA = '401609': >> >> Plan hash value: 3125576660 >> >> >> >> | Id | Operation| Name| Rows | Bytes | Cost (%CPU)| >> Time | >> >> | 0 | SELECT STATEMENT | >> | 12936 | 90552 |34 (0)| 00:00:01 | >> |* 1 | INDEX RANGE SCAN| IDX_TMOV_CODCXA | 12936 | 90552 |34 (0)| >> 00:00:01 | >> >> >> >> >> Outras consultas: >> SQL>SELECT COUNT(1) FROM TMOV >> 71933 >> >> SQL>SELECT COUNT(1) FROM TMOV WHERE CODCXA = '401609' >> 12858 >> >> SQL>SELECT DISTINCT CODCXA FROM TMOV >> 44 resultados >> >> >> >> Muito obrigado pessoal, >> estou lendo e compreendendo (o que é mais importante, claro) todas as >> respostas. >> >> >> >> Em 3 de fevereiro de 2014 22:54, escreveu: >> >> >>> >>> Colega, tudo jóia ? Sim, ainda estou vivo , e de vez em quando ainda >>> passo por aqui :) >>> >>> Sobre as suas perguntas , seguinte : NÃO, não é verdade que >>> Obrigatoriamente um SELECT * "força" um full-table scan, e para a idéia de >>> que seria preciso indexar todas as colunas para que um SELECT * usar >>> índice, a resposta é : bullshit, bobeira, absurdo, ridículo, siiim ?? >>> Aliàs, antes de demonstrar, vamos pensar juntos : um índice ** não ** >>> acelera uma consulta por magia de unicórnio ou pó de pirlimpimpim : entre >>> outras coisas (como a questão de organização interna que permite busca por >>> 'poda' de valores), o fato é que um índice simplesmente é uma "tabela >>> reduzida", que tem só as colunas-chave e o rowid de cada linha, assim é por >>> isso que uma busca no índice é mais rápida, o índice é MUITÍSSIMO MENOR, né >>> ?? Vc não acha que se vc criar um índice com TODAS as colunas da tabela, vc >>> não acaba tendo uma estrutura de tamanho + ou - similar à da tabela ??? Que >>> vantagem Maria leva >>> >>> Segundo ponto : o RDBMS Oracle (ao menos desde a versão 8i, mas >>> principalmente a partir do 9i) largou mão de otimização RBO e adotou a CBO, >>> ie : ele ** não ** adivinha, ** não ** usa "regras" para decidir se usa ou >>> não o índice, se é mais vantajoso ler a tabela de uma vez ou se é melhor >>> ler o índice : ele usa as ESTATÍSTICAS que indicam quantos registros serão >>> retornadas ao se filtrar por cada coluna COM o valor indicado no WHERE, >>> okdoc ?? >>> ENTÃO, necessariamente se o seu índice não está sendo usado, MUITO >>> RPOVAVELMENTE o valor que vc informou retorn
Re: [oracle_br] Índices no Oracle
Como eu imaginava! Por isso lá no meu primeiro e-mail eu perguntei quantos registros tinha no total dessa tabela. Vc tá retornando 12858 registros, num universo de 71933. É uma porcentagem muito alta. Não vale a pena usar índice, por isso o Oracle está fazendo full scan. Mas por que ele usa índice quando pede só essa coluna? Porque os próprios valores que vc quer já estão no índice - e daí fica muito menos custoso consultar apenas a estrutura de índice, pois nela já contém todos os valores que vc quer. Em 4 de fevereiro de 2014 11:28, Yuri Menon escreveu: > > > Banco: > Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit > Production > PL/SQL Release 11.2.0.3.0 - Production > > CORE 11.2.0.3.0 Production > > TNS for 64-bit Windows: Version 11.2.0.3.0 - Production > > NLSRTL Version 11.2.0.3.0 - Production > > > Fábio Prado, explain plan do SELECT * FROM TMOV WHERE CODCXA = '401609' > > > Plan hash value: 235420782 > > > -- > > | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | > > -- > > > | 0 | SELECT STATEMENT | | 12936 | 4737K| 1377 (1)| 00:00:17 | > > > |* 1 | TABLE ACCESS FULL| TMOV | 12936 | 4737K| 1377 (1)| 00:00:17 | > > -- > > > Explain Plan do SELECT CODCXA FROM TMOV WHERE CODCXA = '401609': > > Plan hash value: 3125576660 > > > > | Id | Operation| Name| Rows | Bytes | Cost (%CPU)| > Time | > > | 0 | SELECT STATEMENT | > | 12936 | 90552 |34 (0)| 00:00:01 | > |* 1 | INDEX RANGE SCAN| IDX_TMOV_CODCXA | 12936 | 90552 |34 (0)| > 00:00:01 | > > > > > Outras consultas: > SQL>SELECT COUNT(1) FROM TMOV > 71933 > > SQL>SELECT COUNT(1) FROM TMOV WHERE CODCXA = '401609' > 12858 > > SQL>SELECT DISTINCT CODCXA FROM TMOV > 44 resultados > > > > Muito obrigado pessoal, > estou lendo e compreendendo (o que é mais importante, claro) todas as > respostas. > > > > Em 3 de fevereiro de 2014 22:54, escreveu: > > >> >> Colega, tudo jóia ? Sim, ainda estou vivo , e de vez em quando ainda >> passo por aqui :) >> >> Sobre as suas perguntas , seguinte : NÃO, não é verdade que >> Obrigatoriamente um SELECT * "força" um full-table scan, e para a idéia de >> que seria preciso indexar todas as colunas para que um SELECT * usar >> índice, a resposta é : bullshit, bobeira, absurdo, ridículo, siiim ?? >> Aliàs, antes de demonstrar, vamos pensar juntos : um índice ** não ** >> acelera uma consulta por magia de unicórnio ou pó de pirlimpimpim : entre >> outras coisas (como a questão de organização interna que permite busca por >> 'poda' de valores), o fato é que um índice simplesmente é uma "tabela >> reduzida", que tem só as colunas-chave e o rowid de cada linha, assim é por >> isso que uma busca no índice é mais rápida, o índice é MUITÍSSIMO MENOR, né >> ?? Vc não acha que se vc criar um índice com TODAS as colunas da tabela, vc >> não acaba tendo uma estrutura de tamanho + ou - similar à da tabela ??? Que >> vantagem Maria leva >> >> Segundo ponto : o RDBMS Oracle (ao menos desde a versão 8i, mas >> principalmente a partir do 9i) largou mão de otimização RBO e adotou a CBO, >> ie : ele ** não ** adivinha, ** não ** usa "regras" para decidir se usa ou >> não o índice, se é mais vantajoso ler a tabela de uma vez ou se é melhor >> ler o índice : ele usa as ESTATÍSTICAS que indicam quantos registros serão >> retornadas ao se filtrar por cada coluna COM o valor indicado no WHERE, >> okdoc ?? >> ENTÃO, necessariamente se o seu índice não está sendo usado, MUITO >> RPOVAVELMENTE o valor que vc informou retorna uma grande qtdade de linhas e >> então compensa mais partir pro FTS, ** OU ** as estatísticas não registram >> a distribuição de dados corretas >> >> A minha demonstração (num banco 10.2.0.5 EE no caso) : >> >> => crio a tabela e preencho com dados : >> >> SQL> set lines 200 pages 5 >> >> SQL> create table TAB_TESTE as (select * from dba_objects where 1=2); >> >> Tabela criada. >> >> SQL> alter table TAB_TESTE parallel 4; >> >> SQL> insert /*+ APPEND */ into TAB_TESTE (select * from dba_objects); >> >> 51496 linhas criadas. >> >> SQL> commit; >> >> Commit concluido. >> >> SQL> insert /*+ APPEND */ into TAB_TESTE (select * from dba_objects); >> >> 51496 linhas criadas. >> >> SQL> commit; >> >> Commit concluido. >> >> >> ==> okdoc , vamos ter na coluna indexada um valor RARO, que traz >> POUQUÍSSIMAS linhas, e assim vale a pena ser recuperado por
Re: [oracle_br] Índices no Oracle
E óbvio : além de ** TUDO ** o que falei antes, uma consulta na v$sesstat para a sessão que está fazendo os testes imediatamente ANTES e DEPOIS de cada execução de cada query (pra gente ver as diferenças causadas pela execução de cada query) poderia ser Excepcionalmente interessante/útil, especialmente nas estatísticas de performance referentes ao acesso físico, como table fetch by rowid , table fetch continued row, table scan blocks gotten, %consistent read%, %table scan%, %DBWR% ... Poderia ser um script que mostra a diff antes e depois, tipo como feito em http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701 : a idéia é ver a diferença de stats causada pela execução da query com FTS e a diferença de stats causada pela execução da query que lê o índice , para vermos se há diferença física consistente entre os dois acessos o consumo/waits.. []s Chiappa
Re: [oracle_br] Índices no Oracle
O mais importante são mesmo os conceitos : se vc está os compreendendo, entendeu porque não faz sentido nem sequer pensar em indexar todas as colunas de uma tabela, entendeu (nas linhas gerais básicas citadas) o mecanismo do CBO, maravilha, isso é o importante... Sobre a investigação em questão, além de reforçar a necessidade de obter o plano de execução EXTENDIDO, com A-ROWs e E-ROWS (o plano de execução básico não serve de nada quando vc investiga planos diferentes para valores diferentes), seria Ótimo quando vc for re-executar as queries com o hint de gather stats para obter o plano extendido, Também pedir antes no sqlplus um SET TIME ON TIMING ON, para que a gente veja o tempo total gasto nos dois casos (via índice e via fts) para se receber todos os resultados no cliente, que no caso será o sqlplus E repetindo um pouco, como tá a Qualidade das estatísticas ? Elas estão sendo coletadas de que modo, com que frequência ? A coleta é FOR ALL COLUMNS, ou FOR ALL INDEXED COLUMNS, ou o que ? Com qual SIZE ?? Este último ponto é Crítico, pois se vc tem uma distribuição Totalmente Irregular ( como parece ser o caso, já que CODCXA = '401609' vc diz que o COUNT retornou 12858 linhas e para o original CODCXA = '12345' na msg original retornava 3500 registros, quase 4x menos), é justamente o HISTOGRAMA gerado pelo SIZE que vai subsidiar a escolha do CBO para cada valor possível Pode valer a pena indicar um SIZE maior para essa coluna, se hoje vc está usando a opção SIZE AUTO e/ou não usa size nenhum... Além disso, vc necessariamente deve olhar o armazenamento interno (físico e lógico) para essa tabela : eu tenho um feeling, alguma coisa me diz que o CBO pode estar superestimando a performance do FTS, que na prática pode estar sendo Reduzida por causa de chaining rows, white space, tamanho de extents largamente diferentes entre si, grau de paralelismo inadequado/inexistente Dá uma pesquisadinha nisso, plz... E finalmente : ** necessariamente ** o HINT de INDEX deveria ter funcionado causando um index range scan : mostra pra gente a sintaxe que vc usou, de repente tá com erro e por isso o hint não foi aceito... []s Chiappa
Re: [oracle_br] Índices no Oracle
Banco:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit
Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
Fábio Prado, explain plan do SELECT * FROM TMOV WHERE CODCXA = '401609'
Plan hash value: 235420782
--
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--
| 0 | SELECT STATEMENT | | 12936 | 4737K| 1377 (1)| 00:00:17 |
|* 1 | TABLE ACCESS FULL| TMOV | 12936 | 4737K| 1377 (1)| 00:00:17 |
--
Explain Plan do SELECT CODCXA FROM TMOV WHERE CODCXA = '401609':
Plan hash value: 3125576660
| Id | Operation| Name| Rows | Bytes | Cost (%CPU)|
Time |
| 0 | SELECT STATEMENT |
| 12936 | 90552 |34 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| IDX_TMOV_CODCXA | 12936 | 90552 |34 (0)|
00:00:01 |
Outras consultas:
SQL>SELECT COUNT(1) FROM TMOV
71933
SQL>SELECT COUNT(1) FROM TMOV WHERE CODCXA = '401609'
12858
SQL>SELECT DISTINCT CODCXA FROM TMOV
44 resultados
Muito obrigado pessoal,
estou lendo e compreendendo (o que é mais importante, claro) todas as
respostas.
Em 3 de fevereiro de 2014 22:54, escreveu:
>
>
> Colega, tudo jóia ? Sim, ainda estou vivo , e de vez em quando ainda
> passo por aqui :)
>
> Sobre as suas perguntas , seguinte : NÃO, não é verdade que
> Obrigatoriamente um SELECT * "força" um full-table scan, e para a idéia de
> que seria preciso indexar todas as colunas para que um SELECT * usar
> índice, a resposta é : bullshit, bobeira, absurdo, ridículo, siiim ??
> Aliàs, antes de demonstrar, vamos pensar juntos : um índice ** não **
> acelera uma consulta por magia de unicórnio ou pó de pirlimpimpim : entre
> outras coisas (como a questão de organização interna que permite busca por
> 'poda' de valores), o fato é que um índice simplesmente é uma "tabela
> reduzida", que tem só as colunas-chave e o rowid de cada linha, assim é por
> isso que uma busca no índice é mais rápida, o índice é MUITÍSSIMO MENOR, né
> ?? Vc não acha que se vc criar um índice com TODAS as colunas da tabela, vc
> não acaba tendo uma estrutura de tamanho + ou - similar à da tabela ??? Que
> vantagem Maria leva
>
> Segundo ponto : o RDBMS Oracle (ao menos desde a versão 8i, mas
> principalmente a partir do 9i) largou mão de otimização RBO e adotou a CBO,
> ie : ele ** não ** adivinha, ** não ** usa "regras" para decidir se usa ou
> não o índice, se é mais vantajoso ler a tabela de uma vez ou se é melhor
> ler o índice : ele usa as ESTATÍSTICAS que indicam quantos registros serão
> retornadas ao se filtrar por cada coluna COM o valor indicado no WHERE,
> okdoc ??
> ENTÃO, necessariamente se o seu índice não está sendo usado, MUITO
> RPOVAVELMENTE o valor que vc informou retorna uma grande qtdade de linhas e
> então compensa mais partir pro FTS, ** OU ** as estatísticas não registram
> a distribuição de dados corretas
>
> A minha demonstração (num banco 10.2.0.5 EE no caso) :
>
> => crio a tabela e preencho com dados :
>
> SQL> set lines 200 pages 5
>
> SQL> create table TAB_TESTE as (select * from dba_objects where 1=2);
>
> Tabela criada.
>
> SQL> alter table TAB_TESTE parallel 4;
>
> SQL> insert /*+ APPEND */ into TAB_TESTE (select * from dba_objects);
>
> 51496 linhas criadas.
>
> SQL> commit;
>
> Commit concluido.
>
> SQL> insert /*+ APPEND */ into TAB_TESTE (select * from dba_objects);
>
> 51496 linhas criadas.
>
> SQL> commit;
>
> Commit concluido.
>
>
> ==> okdoc , vamos ter na coluna indexada um valor RARO, que traz
> POUQUÍSSIMAS linhas, e assim vale a pena ser recuperado por índice :
>
>
> SQL> insert into TAB_TESTE (owner) values('CHIAPPA');
>
> 1 linha criada.
>
>
> SQL> commit
> 2 ;
>
> Commit concluido.
>
> => crio o índice :
>
> SQL> create index IDX_TESTE_OWNER on TAB_TESTE(owner);
>
> Indice criado.
>
> > Óia isso : select * usando o índice :
>
> SQL> set autotrace on
> SQL> select * from TAB_TESTE where owner='CHIAPPA';
>
> OWNER
> --
> OBJECT_NAME
>
>
> SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE
> -- -- --
> ---
> CREATED LAST_DDL TIMESTAMP STATUS T G S
> --
Re: [oracle_br] Índices no Oracle
Colega, tudo jóia ? Sim, ainda estou vivo , e de vez em quando ainda passo por
aqui :)
Sobre as suas perguntas , seguinte : NÃO, não é verdade que Obrigatoriamente
um SELECT * "força" um full-table scan, e para a idéia de que seria preciso
indexar todas as colunas para que um SELECT * usar índice, a resposta é :
bullshit, bobeira, absurdo, ridículo, siiim ??
Aliàs, antes de demonstrar, vamos pensar juntos : um índice ** não ** acelera
uma consulta por magia de unicórnio ou pó de pirlimpimpim : entre outras coisas
(como a questão de organização interna que permite busca por 'poda' de
valores), o fato é que um índice simplesmente é uma "tabela reduzida", que tem
só as colunas-chave e o rowid de cada linha, assim é por isso que uma busca no
índice é mais rápida, o índice é MUITÍSSIMO MENOR, né ?? Vc não acha que se vc
criar um índice com TODAS as colunas da tabela, vc não acaba tendo uma
estrutura de tamanho + ou - similar à da tabela ??? Que vantagem Maria leva
Segundo ponto : o RDBMS Oracle (ao menos desde a versão 8i, mas principalmente
a partir do 9i) largou mão de otimização RBO e adotou a CBO, ie : ele ** não **
adivinha, ** não ** usa "regras" para decidir se usa ou não o índice, se é mais
vantajoso ler a tabela de uma vez ou se é melhor ler o índice : ele usa as
ESTATÍSTICAS que indicam quantos registros serão retornadas ao se filtrar por
cada coluna COM o valor indicado no WHERE, okdoc ??
ENTÃO, necessariamente se o seu índice não está sendo usado, MUITO
RPOVAVELMENTE o valor que vc informou retorna uma grande qtdade de linhas e
então compensa mais partir pro FTS, ** OU ** as estatísticas não registram a
distribuição de dados corretas
A minha demonstração (num banco 10.2.0.5 EE no caso) :
=> crio a tabela e preencho com dados :
SQL> set lines 200 pages 5
SQL> create table TAB_TESTE as (select * from dba_objects where 1=2);
Tabela criada.
SQL> alter table TAB_TESTE parallel 4;
SQL> insert /*+ APPEND */ into TAB_TESTE (select * from dba_objects);
51496 linhas criadas.
SQL> commit;
Commit concluido.
SQL> insert /*+ APPEND */ into TAB_TESTE (select * from dba_objects);
51496 linhas criadas.
SQL> commit;
Commit concluido.
==> okdoc , vamos ter na coluna indexada um valor RARO, que traz POUQUÍSSIMAS
linhas, e assim vale a pena ser recuperado por índice :
SQL> insert into TAB_TESTE (owner) values('CHIAPPA');
1 linha criada.
SQL> commit
2 ;
Commit concluido.
=> crio o índice :
SQL> create index IDX_TESTE_OWNER on TAB_TESTE(owner);
Indice criado.
> Óia isso : select * usando o índice :
SQL> set autotrace on
SQL> select * from TAB_TESTE where owner='CHIAPPA';
OWNER
--
OBJECT_NAME
SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE
-- -- -- ---
CREATED LAST_DDL TIMESTAMP STATUS T G S
--- --- - - -
CHIAPPA
Plano de Execuc?o
--
Plan hash value: 1974746346
---
| Id | Operation | Name| Rows | Bytes | Cost (%C
PU)| Time |
---
| 0 | SELECT STATEMENT| | 1 | 177 | 2
(0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TAB_TESTE | 1 | 177 | 2
(0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_TESTE_OWNER | 1 | | 1
(0)| 00:00:01 |
---
Predicate Information (identified by operation id):
---
2 - access("OWNER"='CHIAPPA')
Note
-
- dynamic sampling used for this statement
Estatistica
--
9 recursive calls
0 db block gets
74 consistent gets
1 physical reads
0 redo size
1354 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
==> agora a contra-prova : um valor do índice que SEI que é repetido milhares
de vezes :
SQL> select * from TAB_TESTE where owner='SYS';
.
SYS
/a7359489_XDBServletContainer
38589JAVA CLASS
08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
SYS
oracle/xdb/spi/XDBResource
38590JAVA CLASS
08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
SYS
oracle/xdb/spi/Resource
Re: [oracle_br] Índices no Oracle
Sergio, é por isso mesmo que eu perguntei no e-mail anterior qual era a quantidade total de linhas dessa tabela! De repente é por isso que o índice não esteja sendo utilizado. Em 3 de fevereiro de 2014 17:24, Sérgio Luiz Rodrigues Chaves < sergio.cha...@elumini.com.br> escreveu: > > > Yuri, > > Veja também em http://www.devmedia.com.br/tuning-no-oracle-parte-02/16297. > Nota 4 > > "Nota 4. Seletividade de uma consulta > > Podemos chamar seletividade como sendo a relação estabelecida entre a > quantidade de linhas de uma tabela retornadas por uma consulta com a > quantidade total de linhas da mesma tabela. É exatamente através da análise > dessa seletividade que o Oracle decide entre usar um índice ou varrer todos > os blocos de uma tabela. Por exemplo, imaginemos uma tabela com 1 milhão de > linhas: se uma consulta na mesma retorna 900 mil linhas é muito mais rápido > o Oracle varrer a tabela toda do que utilizar um índice. Apenas para termos > um parâmetro, qualquer seletividade acima de 10% do valor total de linhas > de uma tabela é considerada alta, e dificilmente o Oracle utilizará um > índice nessa consulta.". > > Atenciosamente, > > Sérgio Chaves . > > - Mensagem original - > De: Sérgio Luiz Rodrigues Chaves > Para: oracle br > Enviadas: Mon, 03 Feb 2014 14:26:40 -0200 (BRST) > Assunto: Re: [oracle_br] Índices no Oracle > > > Yuri, > > É importante informar qual a sua versão de Banco de Dados. Há muitas > mudança significativas entre elas: > "Features > Index fast full scan > Consideration of bitmap access to paths for tables with only B-tree indexes > Complex view merging > Peeking into user-defined bind variables > Index joins > Dynamic sampling > Query rewrite enables > Skip unusable indexes > Automatically compute index statistics as part of creation > Cost-based query transformations > Allow rewrites with multiple MVs and/or base tables > Adaptive cursor sharing > Use extended statistics to estimate selectivity > Use native implementation for full outer joins > Partition pruning using join filtering > Group by placement optimization > Null aware antijoins " > As 6 últimas somente no Oracle 11g. > > Também é importante saber se o Banco de dados foi configurado para OLAP ou > OLTP, visto que o otimizador e os parameters do banco são diferentes para > cada um deles. > > Verifique também se as estatísticas da tabela estão sendo coletadas. > > Nos passe o plano de execução e as informações: > Selectivity = Number of rows satisfying a condition / Total number of rows > "Selectivity is the estimated proportion of a row set retrieved by a > particular predicate or combination of predicates. > It is expressed as a value between 0.0 and 1.0: > High selectivity: Small proportion of rows > Low selectivity: Big proportion of rows > Selectivity computation: > If no statistics: Use dynamic sampling > If no histograms: Assume even distribution of rows > Statistic information: > DBA_TABLES and DBA_TAB_STATISTICS (NUM_ROWS) > DBA_TAB_COL_STATISTICS (NUM_DISTINCT, DENSITY, HIGH/LOW_VALUE,...) > " > Cardinality = Selectivity * Total number of rows > > Expected number of rows retrieved by a particular operation in the > execution plan > Vital figure to determine join, filters, and sort costs > Simple example: > > SELECT days FROM courses WHERE dev_name = 'ANGEL'; > > The number of distinct values in DEV_NAME is 203. > The number of rows in COURSES (original cardinality) is 1018. > Selectivity = 1/203 = 4.926*e-03 > Cardinality = (1/203)*1018 = 5.01 (rounded off to 6) > > Att. > > Sérgio Chaves. > > - Original Message - > From: "Yuri Menon" > To: "oracle br" > Sent: Segunda-feira, 3 de Fevereiro de 2014 13:22:14 > Subject: [oracle_br] Índices no Oracle > > Boa tarde pessoal! > > Podem me auxiliar por favor? > > A seguinte consulta: > > SELECT * > FROM TMOV > WHERE CODCXA = '12345' > > Retorna 3500 registros e está muito lenta. > > Em conta disso, criei um índice que aponta para TMOV.CODCXA > > No entanto, esse índice só é utilizado quando dou APENAS um: > SELECT CODCXA FROM TMOV WHERE CODCXA = '12345' > não é utilizado para: > SELECT * FROM TMOV WHERE CODCXA = '12345' > > A minha dúvida: > É normal isso no Oracle? > > Se eu quiser fazer SELECT * terei de criar um índice que "enxergue" todos > os campos? > > Obs: tentei passar com HINT pra tentar "forçar", mas não foi. > > Desde já agradeço! > > >
Re: [oracle_br] Índices no Oracle
Yuri, Veja também em http://www.devmedia.com.br/tuning-no-oracle-parte-02/16297. Nota 4 "Nota 4. Seletividade de uma consulta Podemos chamar seletividade como sendo a relação estabelecida entre a quantidade de linhas de uma tabela retornadas por uma consulta com a quantidade total de linhas da mesma tabela. É exatamente através da análise dessa seletividade que o Oracle decide entre usar um índice ou varrer todos os blocos de uma tabela. Por exemplo, imaginemos uma tabela com 1 milhão de linhas: se uma consulta na mesma retorna 900 mil linhas é muito mais rápido o Oracle varrer a tabela toda do que utilizar um índice. Apenas para termos um parâmetro, qualquer seletividade acima de 10% do valor total de linhas de uma tabela é considerada alta, e dificilmente o Oracle utilizará um índice nessa consulta.". Atenciosamente, Sérgio Chaves . - Mensagem original - De: Sérgio Luiz Rodrigues Chaves Para: oracle br Enviadas: Mon, 03 Feb 2014 14:26:40 -0200 (BRST) Assunto: Re: [oracle_br] Índices no Oracle Yuri, É importante informar qual a sua versão de Banco de Dados. Há muitas mudança significativas entre elas: "Features Index fast full scan Consideration of bitmap access to paths for tables with only B-tree indexes Complex view merging Peeking into user-defined bind variables Index joins Dynamic sampling Query rewrite enables Skip unusable indexes Automatically compute index statistics as part of creation Cost-based query transformations Allow rewrites with multiple MVs and/or base tables Adaptive cursor sharing Use extended statistics to estimate selectivity Use native implementation for full outer joins Partition pruning using join filtering Group by placement optimization Null aware antijoins " As 6 últimas somente no Oracle 11g. Também é importante saber se o Banco de dados foi configurado para OLAP ou OLTP, visto que o otimizador e os parameters do banco são diferentes para cada um deles. Verifique também se as estatísticas da tabela estão sendo coletadas. Nos passe o plano de execução e as informações: Selectivity = Number of rows satisfying a condition / Total number of rows "Selectivity is the estimated proportion of a row set retrieved by a particular predicate or combination of predicates. It is expressed as a value between 0.0 and 1.0: High selectivity: Small proportion of rows Low selectivity: Big proportion of rows Selectivity computation: If no statistics: Use dynamic sampling If no histograms: Assume even distribution of rows Statistic information: DBA_TABLES and DBA_TAB_STATISTICS (NUM_ROWS) DBA_TAB_COL_STATISTICS (NUM_DISTINCT, DENSITY, HIGH/LOW_VALUE,…) " Cardinality = Selectivity * Total number of rows Expected number of rows retrieved by a particular operation in the execution plan Vital figure to determine join, filters, and sort costs Simple example: SELECT days FROM courses WHERE dev_name = 'ANGEL'; The number of distinct values in DEV_NAME is 203. The number of rows in COURSES (original cardinality) is 1018. Selectivity = 1/203 = 4.926*e-03 Cardinality = (1/203)*1018 = 5.01 (rounded off to 6) Att. Sérgio Chaves. - Original Message - From: "Yuri Menon" To: "oracle br" Sent: Segunda-feira, 3 de Fevereiro de 2014 13:22:14 Subject: [oracle_br] Índices no Oracle Boa tarde pessoal! Podem me auxiliar por favor? A seguinte consulta: SELECT * FROM TMOV WHERE CODCXA = '12345' Retorna 3500 registros e está muito lenta. Em conta disso, criei um índice que aponta para TMOV.CODCXA No entanto, esse índice só é utilizado quando dou APENAS um: SELECT CODCXA FROM TMOV WHERE CODCXA = '12345' não é utilizado para: SELECT * FROM TMOV WHERE CODCXA = '12345' A minha dúvida: É normal isso no Oracle? Se eu quiser fazer SELECT * terei de criar um índice que "enxergue" todos os campos? Obs: tentei passar com HINT pra tentar "forçar", mas não foi. Desde já agradeço!
Re: [oracle_br] Índices no Oracle
Yuri, É importante informar qual a sua versão de Banco de Dados. Há muitas mudança significativas entre elas: "Features Index fast full scan Consideration of bitmap access to paths for tables with only B-tree indexes Complex view merging Peeking into user-defined bind variables Index joins Dynamic sampling Query rewrite enables Skip unusable indexes Automatically compute index statistics as part of creation Cost-based query transformations Allow rewrites with multiple MVs and/or base tables Adaptive cursor sharing Use extended statistics to estimate selectivity Use native implementation for full outer joins Partition pruning using join filtering Group by placement optimization Null aware antijoins " As 6 últimas somente no Oracle 11g. Também é importante saber se o Banco de dados foi configurado para OLAP ou OLTP, visto que o otimizador e os parameters do banco são diferentes para cada um deles. Verifique também se as estatísticas da tabela estão sendo coletadas. Nos passe o plano de execução e as informações: Selectivity = Number of rows satisfying a condition / Total number of rows "Selectivity is the estimated proportion of a row set retrieved by a particular predicate or combination of predicates. It is expressed as a value between 0.0 and 1.0: High selectivity: Small proportion of rows Low selectivity: Big proportion of rows Selectivity computation: If no statistics: Use dynamic sampling If no histograms: Assume even distribution of rows Statistic information: DBA_TABLES and DBA_TAB_STATISTICS (NUM_ROWS) DBA_TAB_COL_STATISTICS (NUM_DISTINCT, DENSITY, HIGH/LOW_VALUE,…) " Cardinality = Selectivity * Total number of rows Expected number of rows retrieved by a particular operation in the execution plan Vital figure to determine join, filters, and sort costs Simple example: SELECT days FROM courses WHERE dev_name = 'ANGEL'; The number of distinct values in DEV_NAME is 203. The number of rows in COURSES (original cardinality) is 1018. Selectivity = 1/203 = 4.926*e-03 Cardinality = (1/203)*1018 = 5.01 (rounded off to 6) Att. Sérgio Chaves. - Original Message - From: "Yuri Menon" To: "oracle br" Sent: Segunda-feira, 3 de Fevereiro de 2014 13:22:14 Subject: [oracle_br] Índices no Oracle Boa tarde pessoal! Podem me auxiliar por favor? A seguinte consulta: SELECT * FROM TMOV WHERE CODCXA = '12345' Retorna 3500 registros e está muito lenta. Em conta disso, criei um índice que aponta para TMOV.CODCXA No entanto, esse índice só é utilizado quando dou APENAS um: SELECT CODCXA FROM TMOV WHERE CODCXA = '12345' não é utilizado para: SELECT * FROM TMOV WHERE CODCXA = '12345' A minha dúvida: É normal isso no Oracle? Se eu quiser fazer SELECT * terei de criar um índice que "enxergue" todos os campos? Obs: tentei passar com HINT pra tentar "forçar", mas não foi. Desde já agradeço!
Re: [oracle_br] Índices no Oracle
Qual o TOTAL de registros dessa tabela? Em 3 de fevereiro de 2014 13:43, Ivan Ricardo Schuster escreveu: > > > Yuri, > > Por acaso "CODCXA" não é do tipo number? > Se for, retire as aspas simples ao realizar a consulta: > > > SELECT * FROM TMOV WHERE CODCXA = 12345 > > Caso não resolva, mande pra gente o ddl de criação da tabela e do índice > para facilitar a análise. > > Abraço > > > 2014-02-03 Fabio Prado : > > >> >> Yuri, se o índice foi utilizado na 1a. situação ele tbém deve estar sendo >> utilizado na 2a. situação, mas na primeira ele acessa somente o índice, na >> 2a. o otimizador acesso o índice, recupera o rowid da linha e vai para a >> tabela recuperar os dados das demais colunas. Para verificarmos isso com >> certeza, passe para nós o plano de execução. >> >> []s >> >> Fábio Prado >> www.fabioprado.net >> >> >> Em 3 de fevereiro de 2014 13:22, Yuri Menon escreveu: >> >> >>> >>> Boa tarde pessoal! >>> >>> Podem me auxiliar por favor? >>> >>> A seguinte consulta: >>> >>> SELECT * >>> FROM TMOV >>> WHERE CODCXA = '12345' >>> >>> Retorna 3500 registros e está muito lenta. >>> Em conta disso, criei um índice que aponta para TMOV.CODCXA >>> No entanto, esse índice só é utilizado quando dou APENAS um: >>> SELECT CODCXA FROM TMOV WHERE CODCXA = '12345' >>> não é utilizado para: >>> SELECT * FROM TMOV WHERE CODCXA = '12345' >>> >>> A minha dúvida: >>> É normal isso no Oracle? >>> Se eu quiser fazer SELECT * terei de criar um índice que "enxergue" >>> todos os campos? >>> >>> Obs: tentei passar com HINT pra tentar "forçar", mas não foi. >>> >>> Desde já agradeço! >>> >>> >> >> >> -- >> Fábio Prado >> www.fabioprado.net >> "Compartilhando conhecimentos e treinando profissionais em Bancos de >> Dados Oracle" >> >> >> >> > >
Re: [oracle_br] Índices no Oracle
Yuri, Por acaso "CODCXA" não é do tipo number? Se for, retire as aspas simples ao realizar a consulta: SELECT * FROM TMOV WHERE CODCXA = 12345 Caso não resolva, mande pra gente o ddl de criação da tabela e do índice para facilitar a análise. Abraço 2014-02-03 Fabio Prado : > > > Yuri, se o índice foi utilizado na 1a. situação ele tbém deve estar sendo > utilizado na 2a. situação, mas na primeira ele acessa somente o índice, na > 2a. o otimizador acesso o índice, recupera o rowid da linha e vai para a > tabela recuperar os dados das demais colunas. Para verificarmos isso com > certeza, passe para nós o plano de execução. > > []s > > Fábio Prado > www.fabioprado.net > > > Em 3 de fevereiro de 2014 13:22, Yuri Menon escreveu: > > >> >> Boa tarde pessoal! >> >> Podem me auxiliar por favor? >> >> A seguinte consulta: >> >> SELECT * >> FROM TMOV >> WHERE CODCXA = '12345' >> >> Retorna 3500 registros e está muito lenta. >> Em conta disso, criei um índice que aponta para TMOV.CODCXA >> No entanto, esse índice só é utilizado quando dou APENAS um: >> SELECT CODCXA FROM TMOV WHERE CODCXA = '12345' >> não é utilizado para: >> SELECT * FROM TMOV WHERE CODCXA = '12345' >> >> A minha dúvida: >> É normal isso no Oracle? >> Se eu quiser fazer SELECT * terei de criar um índice que "enxergue" todos >> os campos? >> >> Obs: tentei passar com HINT pra tentar "forçar", mas não foi. >> >> Desde já agradeço! >> >> > > > -- > Fábio Prado > www.fabioprado.net > "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados > Oracle" > > > > >
Re: [oracle_br] Índices no Oracle
Yuri, se o índice foi utilizado na 1a. situação ele tbém deve estar sendo utilizado na 2a. situação, mas na primeira ele acessa somente o índice, na 2a. o otimizador acesso o índice, recupera o rowid da linha e vai para a tabela recuperar os dados das demais colunas. Para verificarmos isso com certeza, passe para nós o plano de execução. []s Fábio Prado www.fabioprado.net Em 3 de fevereiro de 2014 13:22, Yuri Menon escreveu: > > > Boa tarde pessoal! > > Podem me auxiliar por favor? > > A seguinte consulta: > > SELECT * > FROM TMOV > WHERE CODCXA = '12345' > > Retorna 3500 registros e está muito lenta. > Em conta disso, criei um índice que aponta para TMOV.CODCXA > No entanto, esse índice só é utilizado quando dou APENAS um: > SELECT CODCXA FROM TMOV WHERE CODCXA = '12345' > não é utilizado para: > SELECT * FROM TMOV WHERE CODCXA = '12345' > > A minha dúvida: > É normal isso no Oracle? > Se eu quiser fazer SELECT * terei de criar um índice que "enxergue" todos > os campos? > > Obs: tentei passar com HINT pra tentar "forçar", mas não foi. > > Desde já agradeço! > > > -- Fábio Prado www.fabioprado.net "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle"
