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 <yuri.me...@gmail.com> 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 <yuri.me...@gmail.com>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, <jlchia...@yahoo.com.br> 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 50000
>>>>
>>>> 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
>>>> 38589 JAVA CLASS
>>>> 08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
>>>>
>>>> SYS
>>>> oracle/xdb/spi/XDBResource
>>>> 38590 JAVA CLASS
>>>> 08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
>>>>
>>>> SYS
>>>> oracle/xdb/spi/Resource
>>>> 38591 JAVA CLASS
>>>> 08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
>>>>
>>>> SYS
>>>> /734d62fb_XDBContextFactory
>>>> 38592 JAVA CLASS
>>>> 08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
>>>>
>>>> SYS
>>>> /827b8b61_XDBResourceContext
>>>> 38593 JAVA CLASS
>>>> 08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
>>>>
>>>> SYS
>>>> oracle/xdb/spi/XDBNameParser
>>>> 38594 JAVA CLASS
>>>> 08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
>>>>
>>>> SYS
>>>> /8d00b602_XDBNamingEnumeration
>>>> 38595 JAVA CLASS
>>>> 08/07/13 08/07/13 2013-07-08:17:21:51 VALID N N N
>>>>
>>>>
>>>> 45920 linhas selecionadas.
>>>>
>>>>
>>>> Plano de Execuc?o
>>>> ----------------------------------------------------------
>>>> Plan hash value: 3685423756
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>> -------------------------------
>>>>
>>>> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
>>>> Time
>>>> | TQ |IN-OUT| PQ Distrib |
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>> -------------------------------
>>>>
>>>> | 0 | SELECT STATEMENT | | 35537 | 6142K| 87 (0)|
>>>> 00:00:02
>>>> | | | |
>>>>
>>>> | 1 | PX COORDINATOR | | | | |
>>>> | | | |
>>>>
>>>> | 2 | PX SEND QC (RANDOM)| :TQ10000 | 35537 | 6142K| 87 (0)|
>>>> 00:00:02
>>>> | Q1,00 | P->S | QC (RAND) |
>>>>
>>>> | 3 | PX BLOCK ITERATOR | | 35537 | 6142K| 87 (0)|
>>>> 00:00:02
>>>> | Q1,00 | PCWC | |
>>>>
>>>> |* 4 | TABLE ACCESS FULL| TAB_TESTE | 35537 | 6142K| 87 (0)|
>>>> 00:00:02
>>>> | Q1,00 | PCWP | |
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>> -------------------------------
>>>>
>>>>
>>>> Predicate Information (identified by operation id):
>>>> ---------------------------------------------------
>>>>
>>>> 4 - filter("OWNER"='SYS')
>>>>
>>>> Note
>>>> -----
>>>> - dynamic sampling used for this statement
>>>>
>>>>
>>>> Estatistica
>>>> ----------------------------------------------------------
>>>> 33 recursive calls
>>>> 0 db block gets
>>>> 1759 consistent gets
>>>> 6 physical reads
>>>> 708 redo size
>>>> 2352373 bytes sent via SQL*Net to client
>>>> 34163 bytes received via SQL*Net from client
>>>> 3063 SQL*Net roundtrips to/from client
>>>> 1 sorts (memory)
>>>> 0 sorts (disk)
>>>> 45920 rows processed
>>>>
>>>> SQL>
>>>>
>>>> Tá-ráhhh : sacou o lance ?? NO exemplo acima, o CBO estava com as
>>>> informações corretas, então ele FEZ a coisa certa nos dois casos , sim ??
>>>> Veja aí no SEU caso a qualidade da estimativa feita pelas
>>>> estatísticas, esse é o primeiro passo QUASE SEMPRE, ok ? Pra isso :
>>>>
>>>> - PERGUNTE pra quem saiba qual é a distribuição de dados esperada para
>>>> o valor em questão
>>>> - COMPARE essa informação com a estimativa do CBO :
>>>> https://blogs.oracle.com/optimizer/entry/how_do_i_know_if mostra uma
>>>> opção Fácil para isso, via Plano de Execução extendido....
>>>>
>>>> []s
>>>>
>>>> Chiappa
>>>>
>>>>
>>>
>>
>
>
