Newsgroup: it.comp.software.database
Titolo: strano CBO per Oracle nelle query

Salve a tutti,
stavo facendo alcuni test sul CBO di Oracle ed ho notato una cosa
strana su delle semplici query su una tabella... sembra che in una
select la clausola LIKE sia nettamente più veloce di una ricerca
diretta.
Mostro le statistiche  (trova_id è una colonna indicizzata):
SQL> select trova_id from ac_ident where trova_id = '171324';
 
trova_id
----------
 
171324
Elapsed: 00:00:00.87
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1
Bytes=5)
   1    0   INDEX (UNIQUE SCAN) OF 'SYS_C002630' (UNIQUE) (Cost=1
Card
          =1
Bytes=5)
Statistics
----------------------------------------------------------
          0  recursive
calls
          0  db block
gets
          2  consistent
gets
          0  physical
reads
          0  redo
size
        374  bytes sent via SQL*Net to
client
        425  bytes received via SQL*Net from
client
          4  SQL*Net roundtrips to/from
client
          0  sorts
(memory)
          0  sorts
(disk)
          1  rows
processed
SQL> select trova_id from ac_ident where trova_id like '171324';
 
trova_id
----------
 
171324
Elapsed: 00:00:00.19
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1
Bytes=5)
   1    0   INDEX (FAST FULL SCAN) OF 'SYS_C002630' (UNIQUE) (Cost=4
C
          ard=1
Bytes=5)
Statistics
----------------------------------------------------------
          0  recursive
calls
          4  db block
gets
        254  consistent
gets
          0  physical
reads
          0  redo
size
        374  bytes sent via SQL*Net to
client
        425  bytes received via SQL*Net from
client
          4  SQL*Net roundtrips to/from
client
          0  sorts
(memory)
          0  sorts
(disk)
          1  rows
processed
sembra che la Fast FULL Scan sull'indice è molto più veloce di un
UNIQUE SCAN. Ho fatto una prova anche usando LIKE '%171324' ed i tempi
di risposta sono sempre molto più bassi di una ricerca diretta.
qualcuno sa spiegarmi il perchè si comporti in questo modo??
grazie mille!
saluti

 saluti
ciao, a nasometro mi viene in mente quanto segue:
1) se la tabella è molto piccola e l'indice è contenuto tutto in un solo
blocco non c'è molta differenza tra un unique scan e un fast full;
2) non appare nell'explain la dicitura [ANALYZED]. Probabilmente non
ci sono statistiche aggiornate e questo può creare problemi al CBO;
3) se la query più lenta è la prima, allora la differenza potrebbe
essere dovuta al fatto che le successive trovano quanto gli serve
già in buffer cache, questo però non mi spiega le 254  consistent
gets del secondo explain.
4) se il db è in produzione, con parecchi accessi condivisi a risorse
e quindi con parecchi latch, differenze di centesimi (ma anche molto di
più) non sono da escludere;
5) sicuramente altre 100 cose che adesso non mi vengono in mente...
ciao

 5) sicuramente altre 100 cose che adesso non mi vengono in mente...
grazie mille per la risposta..
un'ultima cosa, non è che hai qualche buon link dove andare a leggere tutte
queste informazioni sul CBO di Oracle ?
mi interessa molto il tipo di scansione che oracle fa sulla tabella o indice
durante una query
grazie!

 grazie!
Sul sito trovi tutta la documentazione ufficiale
http://www.oracle.com/technology/documentation/index.html
poi ti consiglio di andare a spulciare le risposte di
Kyte:
http://asktom.oracle.com/pls/asktom/f?p=100:1:1275393219191594:::R
buona lettura.
ciao


io direi :
la 1) è improbabile, visti i 254 "consistent gets" del secondo caso;
la 2) pare irrilevante, i piani di esecuzione sono entrambi ottimali,
il fatto che le tabelle (e gli indici) siano analizzati
incide su come il CBO seglie il piano di esecuzione, e dal piano di
esecuzione derivano tempi ottimali.
la 3) non è perchè in entrambi i casi ci sono 0 "phisical reads"
la 4) mi sembra la più  probabile,
in più se la prova la fatta da un client remoto potrebbe esserci anche
qualche latenza di rete (vista la piccola differenza).
Per il resto è del tutto giustificata la perplessita, comunque le
statistiche sono molto più favorevoli nel primo caso: 2 consistent
gets
contro 254, cioè nel primo caso deve accedere solo a 2 blocchi e nel
secondo a 254, per il resto le statistiche che riporti sono uguali.
p.s.
anche Jonathan Lewis la sa lunga sul CBO (http://
jonathanlewis.wordpress.com/
)
Ciao
 Cristian
http://cristiancudizio.wordpress.com