Commenti a: Oracle 11g, Istogrammi e DBMS_STATS.AUTO_SAMPLE_SIZE

Di: cristiancudizio

cristiancudizio — Thu, 24 Jul 2008 09:15:07 +0000

Ciao Alessandro,
evidentemente Askimet guarda la lunghezza e la presenza di link nei commenti con sospetto
Per quanto riguarda il contenuto del commento, effettivamente il “tutto automatico” può funzionare in condizioni “normali”, ma i la conformazioni dei dati dipende dalle applicazioni, quindi può avere distribuzioni a cui i default utilizzati non vanno bene. Ora devo trovare un attimo per leggere con calma i due link che segnali.

Di: Alessandro Deledda

Alessandro Deledda — Thu, 24 Jul 2008 08:10:15 +0000

Ciao Cristian,
ho provato a postare un commento ma non viene pubblicato

Alessandro

Di: Alessandro Deledda

Alessandro Deledda — Wed, 23 Jul 2008 14:39:51 +0000

“Insomma ci sono molte cose che si possono fare per parametrizzare CBO, ma richiedono competenza, test e tempo.”

sicuramente,
ma questo perchè fondamentalmente ogni approccio è da verificarsi caso per caso…..

nel mio caso specifico mantengo la raccolta di statistiche di default (il default di 9i però) e solo per quelle tre colonne della tabella agisco come ti ho indicato e, così facendo, anche se la tabella è grossa non ci metto molto

rimango dell’avviso che il tutto automatico non va, preferisco raccoglierle di mio le statistiche e secondo i miei criteri valutati analizzando bene dati e applicazione, e comunque se le statistiche vanno bene le salvo quindi, in caso di problemi, ripristino una situazione che porta l’ottimizzatore ad utilizzare i piani che davano migliori performance e del resto in questo senso non sono stato l’unico a mettersi il problema :

http://www.oracleportal.it/oipforum/thread.jspa?forumID=17&threadID=5487&messageID=23466#23466

Dave Ensor’s dbms_stats paradox:
“it is only safe to gather statistics when to do so will make no difference”

http://wedonotuse.blogspot.com/2005/11/how-often-should-stats-be-collected.html

Alessandro

Di: cristiancudizio

cristiancudizio — Wed, 23 Jul 2008 14:00:12 +0000

Però sono perplesso. Nel mio caso è molto più facile modificare il codice dell’applicazione ed aggiungere un hint alla query. Altrimenti ritengo che gestire questi casi sia complicato. Ciò che mi viene in mente è che non mi riusulta sia possibile definire ad esempio un parametro personalizzato sulla percentuale di campionamento a livello di tabella. Ad esempio impostare per la tabella TABELLAX del mio caso ESTIMATE_PERCENT=>100. Essendo quella tabella relativamente piccola non sarebbe un problema. Questo permetterebbe di toccare il meno possibile e lasciando quindi quasi tutto automatico come suggerito da Oracle. Le alternative sono leggermente più “onerose”, ad esempio schedulare un task personalizzato, in coda a quello predefinito di ricalcolo delle statistiche, che ricalcoli le statistiche su quella tabella con il parametro voluto. Oppure lanciare il calcolo delle statisiche e poi “lockare” le statistiche su quella tabella. Questa soluzione però è rischiosa, i dati potrebbero cambiare in modo significativo nel tempo (sicuramente se ci sono di mezzo date).
Insomma ci sono molte cose che si possono fare per parametrizzare CBO, ma richiedono competenza, test e tempo.

Di: Alessandro Deledda

Alessandro Deledda — Tue, 22 Jul 2008 15:03:13 +0000

Ciao Cristian,
confermo l’esperienza di Rudy per quanto riguarda la necessità di analizzare in compute gli istogrammi rispetto a degli istogrammi in gioco;
nel mio caso come nel tuo Oracle stimava come ottimale una full table scan su di un tabella (ma sbagliando nel mio caso) e ignorava l’indice composto su 3 colonne in cui sapevo indagando che la distribuzione del dato in almeno due di esse non era uniforme rispetto al dominio di valori possibili;
con l’utilizzo dell’indice però i tempi di esecuzione diventavano ottimi considerando anche il fatto che, rispetto al bind variable peeking, ero fortunato essendo già rappresentativi i valori passati alle bind variables al primo run

quindi per queste 3 colonne utilizzai:

estimate_percent => null (compute)

method_opt => ‘for columns size skewonly C1,C2.C3′

e da qui l’utilizzo dell’indice nella successiva stima del piano di esecuzione

il miglioramento su 11G rispetto al DBMS_STATS.AUTO_SAMPLE_SIZE vorrei proprio provarlo per il mio caso e vedere un pò come va, mi riprometto di farlo quando avrò spazio per un’istanza 11G

Ciao
Alessandro

Di: Rudy

Rudy — Fri, 18 Jul 2008 14:26:58 +0000

Jonathan Lewis li chiama “Deadly Defaults”.

Per quanto riguarda l’istogramma, se non fai un sampling al 100% della tabella, sarà sempre sicuramente inutile e dannoso.

Esempio: tabella con 64178 righe e 1 colonna, tutte uguali a 1 tranne 10 che vanno da 1001 a 1010, colonna dd.

SQL> explain plan for select * from distrib where dd = 1006;

Explained.

Elapsed: 00:00:00.09
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
—————————————————————————————————————————————————————-
Plan hash value: 527318038

—————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————–
| 0 | SELECT STATEMENT | | 32101 | 96303 | 16 (7)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DISTRIB | 32101 | 96303 | 16 (7)| 00:00:01 |
—————————————————————————–

Predicate Information (identified by operation id):
—————————————————

1 – filter(“DD”=1006)

Chiaramente sbagliato il computo delle righe, ma:

SQL> exec dbms_stats.gather_table_stats(user, ‘DISTRIB’, estimate_percent => 100);

SQL> explain plan for select * from distrib where dd = 1006;

Explained.

Elapsed: 00:00:00.00
16:15:29 SQL> select * from table(dbms_xplan.display);

—————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 3 | 16 (7)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DISTRIB | 1 | 3 | 16 (7)| 00:00:01 |
—————————————————————————–

Predicate Information (identified by operation id):
—————————————————

1 – filter(“DD”=1006)

13 rows selected.

SQL> explain plan for select * from distrib where dd = 1;

Explained.

Elapsed: 00:00:00.01
SQL> select * from table(dbms_xplan.display);

—————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————–
| 0 | SELECT STATEMENT | | 64168 | 187K| 16 (7)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DISTRIB | 64168 | 187K| 16 (7)| 00:00:01 |
—————————————————————————–

Predicate Information (identified by operation id):
—————————————————

1 – filter(“DD”=1)

13 rows selected.

Bye