Fabão, acredito que voce esteja falando sobre o artigo de ontem
(Histograma - introdução).
1) A query que tem um monte de registro vai por FTS. Achei que tinha
ficado claro quando executei a primeira query com x_hist = 5 (sem
histogramas corretos) que fez full table scan. Mesmo assim aqui
está o resultado do autotrace traceonly.
SQL> select * from t where x_hist = 2;
1835197 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2986 Card=1834400
Bytes=45860000)
1 0 TABLE ACCESS (FULL) OF 'T' (Cost=2986 Card=1834400
Bytes=45860000)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
49556 consistent gets
31045 physical reads
360 redo size
54405784 bytes sent via SQL*Net to client
202512 bytes received via SQL*Net from client
18353 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1835197 rows processed
SQL> select * from t where x_hist = 5;
10 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=25)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=4 Card=1
Bytes=25)
2 1 INDEX (RANGE SCAN) OF 'T_IDX' (NON-UNIQUE) (Cost=3
Card=1)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
6 consistent gets
0 physical reads
0 redo size
920 bytes sent via SQL*Net to client
651 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10 rows processed
2) Baixa seletividade não é o único argumento para criação de bitmap
index. Já imaginou se mesmo com baixa seletividade, o sistema
sofre intensa manutenção? Pra onde vai sua performance? Mas sim,
seria uma alternativa (desde que bem avaliada em seus efeitos
colaterais). no artigo de hoje eu ressalto isso:
Pedaço do artigo em
<http://mportes.blogspot.com/2005/11/histograma-definio-size.html>
E agora, quando usar histogramas?
Sempre que NÃO exista uniformidade na distribuição de valores
sobre o grupo. Voltando ao exemplo dos torcedores, se em nosso
conjunto não tivéssemos os torcedores do VOCEM, não seria
interessante usar histogramas, porque não ganharíamos nada,
haveria necessidade de estudar melhor os dados e talvez usar
bitmap, cluster, etc. Tudo depende, mas se há distruibuição
^^^^^^ ^^^^^^^ ^^^
uniforme no grupo ou constante variação de valores distintos, a
coluna não é candidata ao histograma. Outra ocasião onde
deveríamos evitar o histograma é quando a coluna é comparada com
bind variable. De novo o exemplo, se o campo torce_para for
comparado com bind variable, ele não é candidado a histogramas. O
otimizador precisa conhecer o valor literal da comparação para
percorrer os buckets(endpoint_number, endpoint_value).
3) Só lembrando que o propósito do artigo foi dar uma introdução de
histograma, onde um colega da lista perguntou qual a vantagem de
usá-lo. O artigo foi elaborado para demonstrar a aplicabilidade do
histograma.
Mas, vamos a criação do índice e teste.
SQL> create bitmap index t_bm on t ( x_hist ) parallel nologging;
Index created.
SQL> exec dbms_stats.gather_index_stats( user, 'T_BM' )
PL/SQL procedure successfully completed.
SQL> set autotrace traceonly
SQL> select * from t where x_hist = 2;
1835197 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2986 Card=1834400
Bytes=45860000)
1 0 TABLE ACCESS (FULL) OF 'T' (Cost=2986 Card=1834400
Bytes=45860000)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
49551 consistent gets
30842 physical reads
0 redo size
54405784 bytes sent via SQL*Net to client
202512 bytes received via SQL*Net from client
18353 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1835197 rows processed
Deixando o otimizador trabalhar com as estatísticas coletadas ele
achou melhor fazer FTS.
Mas vamos forçar o índice.
SQL> select /*+ index(t, t_bm) */ * from t where x_hist = 2;
1835197 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=15420 Card=1834400
Bytes=45860000)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=15420
Card=1834400 Bytes=45860000)
2 1 BITMAP CONVERSION (TO ROWIDS)
3 2 BITMAP INDEX (SINGLE VALUE) OF 'T_BM'
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
49475 consistent gets
29340 physical reads
72 redo size
54405784 bytes sent via SQL*Net to client
202512 bytes received via SQL*Net from client
18353 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1835197 rows processed
Praticamente o mesmo esforço, embora o custo tenha sido maior do
índice em relação ao FTS - (Cost=15420) contra (Cost=2986) na mesma
cardinalidade 1834400. Acho que seria necessário um tkprof aqui para
análise mais a fundo, mas como o propósito não era investigar bitmap
index, vou deixar o script que eu usei para fazer o teste e voce pode
realizá-lo e postar aqui mais tarde.
drop table t;
create table t nologging as
select object_id, object_name, mod(rownum, 4) x_hist
from all_objects
/
insert /*+ append */ into t
select * from t;
commit;
insert /*+ append */ into t
select * from t;
commit;
insert /*+ append */ into t
select * from t;
commit;
insert /*+ append */ into t
select * from t;
commit;
insert /*+ append */ into t
select * from t;
commit;
update t set x_hist = 5 where rownum <= 10;
select x_hist, count(*)
from t
group by rollup(x_hist)
/
create index t_idx on t (x_hist) parallel 8 nologging;
begin
dbms_stats.gather_table_stats(
user,
'T',
estimate_percent => 10,
method_opt => 'for columns x_hist size 10',
cascade => true,
degree => 8 );
end;
/
--- Em oracle_br@yahoogrupos.com.br, falmeida <[EMAIL PROTECTED]> escreveu
> Ola Marcio,
>
> Também gostei muito, mas tenho as seguintes perguntas, a saber:
>
> 1) Você após ter aplicado o 2 metodo de coleta de estatísticas você
só
> rodou a query abaixo:
>
> select * from t 2 where x_hist = 5
>
> Não seria legal também demonstrar como ficaria com a query que tem
um
> monte de registros?
>
> select * from t 2 where x_hist = 4
>
> 2) Não seria melhor criar um bitmap index, dado que você tem baixa
> seletividade nesta coluna?
>
> 3) Já que você tem estes dados na tabela t poderia criar um indice
> bitmap e mostrar o resultado aqui?
>
> Desde já agradeço,
>
> Fabão.
>
>
> Em 24/11/05, Rosiano Vieira de Sales<[EMAIL PROTECTED]> escreveu:
> > Marcio... dei uma lida no seu blog a respeito e gostei muito da
nota que vc publicou ....contudo fiquei com uma dúvida ....qual o
critério para definir o size do historgrama ??? .... se tiver algo a
respeito envie para o grupo .. vai ser de muito proveito .....
> >
> > abç.
> >
> > Rosiano
> >
> > -----Mensagem original-----
> > De: oracle_br@yahoogrupos.com.br em nome de Marcio Portes
> > Enviada: qua 23/11/2005 15:06
> > Para: oracle_br@yahoogrupos.com.br
> > Cc:
> > Assunto: [oracle_br] Re: Histogramas.????
> >
> >
> >
> > Welvis, tomei a liberdade de escrever uma pequena
introdução para sua
> > dúvida no meu blog.
> > Se interessar:
> > http://mportes.blogspot.com/2005/11/histograma-
introduo.html
> >
> > abraços,
> >
> > --- Em oracle_br@yahoogrupos.com.br, Welvis Douglas Silva
Moreto
> > <[EMAIL PROTECTED]> escreveu
> > > Quando devo estar utilizando Histogramas.... quais
> > > beneficios terei utilizando o.
> > >
> > >
> > > att,
> > >
> > > Welvis Douglas
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________________
> > > Yahoo! Acesso Grátis: Internet rápida e grátis.
> > > Instale o discador agora!
> > > http://br.acesso.yahoo.com/
> >
> >
> >
> >
> >
> > -----------------------------------------------------------
---------------------------------------------------------------
> > Atenção! As mensagens deste grupo são de acesso
público e de inteira responsabilidade de seus remetentes.
> > Acesse: http://www.mail-
archive.com/oracle_br@yahoogrupos.com.br/
> > -----------------------------------------------------------
---------------------------------------------------------------
_____________________________________________________________________
> > Area de download do grupo -
http://www.4shared.com/dir/101727/a4dcc423
> > Links do Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------------------------------------
--------------------------------------------------------
> > Atenção! As mensagens deste grupo são de acesso público e de
inteira responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> > ------------------------------------------------------------------
--------------------------------------------------------
_____________________________________________________________________
> > Area de download do grupo -
http://www.4shared.com/dir/101727/a4dcc423
> > Links do Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Fábio Martinho de Almeida
> Niterói-RJ-Brasil
>
> Visite o fotolog: http://fotolog.net/canon_a300
--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------_____________________________________________________________________
Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423
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:
[EMAIL PROTECTED]
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
