Test con Oracle 11g: parte III

martedì 16 dicembre 2008 alle 16:27 | Pubblicato su 11g, Installation and Configuration, Performance Tuning | 3 commenti
Tag: , , , ,

I miei test interni con Oracle 11g su Linux 64 bit di cui ho già scritto in due post precedenti (questo e questo) sono proseguiti a singhiozzo. Qualche giorno fa sono riuscito a installare la patchset 11.1.0.7.0 e i risultati sono a dir poco sorprendenti, ho rilanciato più volte le stesse query che in precedenza di davano errori ORA-00600 e ORA-07445 e queste hanno girato senza alcun problema. Ho rilanciato altre query di update che hanno girato per ore senza alcun problema. Quindi sembra la patchset 11.1.0.7  sistemi realmente qualche problemino presenta sulla prima “release” di Oracle 11g.

L’update che mi ero inventato è andato a buon fine ed ha fatto ciò che in effetti mi aspettavo, però non era sufficente, quindi ho utilizzato un’altro update utilizzando le funzioni del package DBMS_RANDOM per generare delle stringhe casuali ed avere dei valori più distribuiti.

Alla fine però per riprodurre il comportamento descritto da Christian Antognini ho dovuto utilizzare due metodi alternativi: hint oppure parametro optimizer_mode=first_rows_100.

SQL> select * from customers where cust_last_name like ‘cudiz%’;

Execution Plan
———————————————————-
Plan hash value: 2008213504

——————————————————————————-
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
——————————————————————————-
|   0 | SELECT STATEMENT  |           | 11426 |  1015K|  5625   (2)| 00:01:08 |
|*  1 |  TABLE ACCESS FULL| CUSTOMERS | 11426 |  1015K|  5625   (2)| 00:01:08 |
——————————————————————————-

SQL> select * from customers where cust_last_name like ‘cudiz%’;

Execution Plan
———————————————————-
Plan hash value: 3995041806

—————————————————————————————–
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————————–
|   0 | SELECT STATEMENT            |           |   100 |  9100 |   113   (0)| 00:00:02 |
|   1 |  TABLE ACCESS BY INDEX ROWID| CUSTOMERS |   100 |  9100 |   113   (0)| 00:00:02 |
|*  2 |   INDEX RANGE SCAN          | TEST_IDX  |       |       |    13   (0)| 00:00:01 |
—————————————————————————————–

Francamente trovo curioso come negli esempi di Antognini, in cui crea una tabellina minuscola con 10 record, Oracle 11g vada senza indugio per indice, cosa  apparentemente poco sensata. In realtà mentre scrivevo mi è venuto in mente che probabilmente in questo caso Oracle usa l’istogramma per capire subito che il valore usato dalla query non c’è. Avevo il dubbio che oracle facesse più lavoro andando sul ‘indice per poi dover andare anche sulla tabella, ma non essendoci il valore cercato, il passaggio sulla tabella non c’è. In più ho notato che forzando un full scan sulla tabella oracle fa 3 consistent gets, contro l’1 che fa quando va solo sull’indice, quindi ha ragione lui.

Nel mio caso invece i valori distinti sono oltre due milioni (quasi tutti). Questo fa si che l’istogramma, che può avere al massimo 254 bucket, è per forza approssimato. Rimango perplesso però, perchè dal piano che ho riportato sopra sembra che l’ottimizzatore stimi di estrarre 11426 righe, stima si sbagliata in eccesso, ma che significa comunque meno dell’1% dei numero totale di record presenti nella tabella e nonostante ciò l’ottimizzatore preferisce un full scan. La differenza nei tempi si sente, perchè con l’indice la risposta è pressoché immediata.

Si tratta di test approssimativi, infatti non ho mai avuto problemi con le ricerche per Like sull’applicazione sviluppata nella mia azienda, non è escluso però che si presentino, quindi sicuremente questo test mi tornerà utile e lo approfondirò.

3 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Ciao Cristian

    > Rimango perplesso però, perchè dal piano che ho riportato
    > sopra sembra che l’ottimizzatore stimi di estrarre 11426
    > righe, stima si sbagliata in eccesso, ma che significa
    > comunque meno dell’1% dei numero totale di record
    > presenti nella tabella e nonostante ciò l’ottimizzatore
    > preferisce un full scan.

    Partendo dalle stime del secondo piano d’esecuzione (cost=113-13 per 100 rows) sembra che il clustering factor dell’indice TEST_IDX sia veramente pessimo. Quindi, non mi stupisce che il CBO abbia scelto questa via…

    Saluti,
    Chris

  2. Che dire… i miei complimenti!
    Riporto l’output delle query sulle USER_TABLES e USER_INDEXES (spero venga leggibile):
    BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR
    —— ———– ————- —————–
    2 10761 2055730 2123731

    NUM_ROWS BLOCKS
    ———- ———-
    2123831 20518

    Sembra proprio che il clustering factor sia alto e quindi sfavorevole.
    Grazie mille Christian per la spiegazione

  3. […] pulita, elegante, ma con una fastidiosa quantità di bachi; io ne ho visti solo un paio (ed ho scritto qualcosa qui), non documentati ma risolti dalla patchset 11.1.07 apparentemente. Comunque ora che è uscita la […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: