[SQL - Oracle] - La plan table e l'execution plan.

[w.tommasi]

Ciao ragazzi.

Qualcuno mi sa dare più indicazioni possibili su come leggere il risultato di una execution plan per capire se la query è efficiente o no ?

DENGHIU !

;)

[w.tommasi]

Uppete !

;)

[Emyl]

Be' e' un po vaga come domanda....

Non esiste una query efficiente per definizione. Dipende da quanto sono grandi le tabelle, quanti dati recuperi, se ci sono o meno indici, statistiche...

In linea di massima controlla che, se ci sono, vengano utilizzati gli indici, che le consistent gets siano adeguate alla quantita' di dati che la query deve restituirti, che non ci siano troppe physical reads, ovvero accessi diretti sul disco.

Se pensi che poi la query non sia efficiente... be' andrebbe visto caso per caso... se hai bisogno prova a fare un fischio.

Ciao ;)

[w.tommasi]

Inannzitutto grazie della risposta.

Lo so che non esiste una query efficiente sempre e comunque. Io volevo semplicemente conoscere quali messaggi della plan_table devono farti drizzare i capelli e quindi riscrivere la query (es. TABLE ACCESS FULL, CARTESIAN PRODUCT e compagnia bella) e quali possono invece farti capire che la tua query sta lavorando bene (es. TABLE ACCCESS BY INDEX RANGE SCAN, ecc.)

DENGHIU !

;)

[Emyl]

Ci sono varie scuole di pensiero. Ad esempio una FULL SCAN la maggior parte delle volte sarebbe da evitare. In alcuni casi pero' puo' essere piu' efficiente anche di un indice. Sicuramente se la tabella e' grande sarebbe ottimale accederci sempre tramite indici, o partizionarla e sfruttare il partition pruning.
Viceversa un prodotto cartesiano solo in casi particolari e' utile, percio' a meno di esigenze strane identifica un errore nella query, ed e' secondo me da evitare.

Personalmente utilizzo come base per il tuning le physical reads. Se sono tante la query e' SEMPRE lenta, percio' sarebbe sempre il caso di limitarle al minimo, usando tutti i mezzi a ns. disposizione (indici, partizioni, materialized view + query rewrite, buffer di memoria...)

Per capirsi, se ho una query con una full scan che fa solo consistent gets non mi ci perdo troppo nell'ottimizzarla, l'accesso alla memoria e' di per se molto veloce.

Altre tecniche di tuning (dimensione dei buffer, eventi di attesa, cpu) sono secondo me subordinate a quanto detto sopra, ed il guadagno e' senz'altro meno evidente.

Buon lavoro! ;)

[w.tommasi]

Grande !!! Mi sei stato d ottimo aiuto !

Quindi quello che secondo te pesa di + sono gli accessi al disco (physical reads) giusto ?

;)