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 <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
>>>>>
>>>>>
>>>>
>>>
>>
>
>
