Comprensione dei risultati di Execute Explain Plan in Oracle SQL Developer

Question

Sto cercando di ottimizzare una query ma non capisco alcune delle informazioni restituite da Spiega il piano. Qualcuno può dirmi il significato delle colonne OPTIONS e COST? Nella colonna OPZIONI, vedo solo la parola FULL. Nella colonna COST, posso dedurre che un costo inferiore significa una query più veloce. Ma cosa rappresenta esattamente il valore di costo e qual è una soglia accettabile?

Answer 1

L'output di EXPLAIN PLAN è un output di debug del query optimiser di Oracle. Il COST è l'output finale del CBO (cost-based optimiser), il cui scopo è selezionare quale tra i diversi possibili piani deve essere utilizzato per eseguire la query. Il CBO calcola un costo relativo per ciascun piano, quindi preleva il piano con il costo più basso.

(Nota: in alcuni casi il CBO non ha abbastanza tempo per valutare ogni possibile piano; in questi casi solo raccoglie il piano con il costo più basso trovato finora)

In generale, uno dei più grandi i contributori a una query lenta sono il numero di righe lette per servire la query (i blocchi, per essere più precisi), quindi il costo sarà basato su nella parte sul numero di righe che dovranno essere lette le stime dell'ottimizzatore.

Per esempio, supponiamo di avere la seguente query: (. La colonna months_of_service ha un vincolo NOT NULL su di essa e un indice normale su di esso)

SELECT emp_id FROM employees WHERE months_of_service = 6; 

Ci sono due piani di base l'ottimizzatore può scegliere qui:

• Piano 1: Leggi tutte le righe della tabella "dipendenti", per ciascuno, controllare se il predicato è vero (months_of_service=6).
• Piano 2: leggere l'indice dove months_of_service=6 (questo risulta in un set di ROWID), quindi accedere alla tabella in base ai ROWID restituiti.

Immaginiamo che la tabella "impiegati" abbia 1.000.000 (1 milione) di righe. Immaginiamo inoltre che i valori per mesi_di_servizio siano compresi tra 1 e 12 e siano distribuiti abbastanza equamente per qualche motivo.

Il costo di Piano 1, che comporta una scansione completa, sarà il costo di leggere tutte le righe della tabella dipendenti, che è approssimativamente uguale a 1.000.000; ma poiché Oracle sarà spesso in grado di leggere i blocchi utilizzando letture multi-blocco, il costo effettivo sarà inferiore (a seconda di come è impostato il database) - ad es. immaginiamo che il conteggio delle letture multi-blocco sia 10 - il costo calcolato della scansione completa sarà di 1.000.000/10; Costo overal = 100.000.

Il costo di Piano 2, che comporta un range index scan e una tabella di ricerca da ROWID, sarà il costo di scansione dell'indice, più il costo di accedere alla tabella ROWID. Non entrerò nel modo in cui sono state calcolate le scansioni del range dell'indice, ma immaginiamo che il costo della scansione dell'indice sia di 1 per riga; ci aspettiamo di trovare una corrispondenza in 1 caso su 12, quindi il costo della scansione dell'indice è 1.000.000/12 = 83.333; più il costo di accesso alla tabella (supponiamo 1 blocco letto per accesso, non possiamo usare letture multi-blocco qui) = 83,333; Costo complessivo = 166.666.

Come si può vedere, il costo del Piano 1 (scansione completa) è MENO del costo del Piano 2 (scansione indice + accesso da rowid) - il che significa che il CBO sceglierebbe la scansione FULL.

Se le ipotesi fatte dall'ottimizzatore sono vere, in effetti il ​​Piano 1 sarà preferibile e molto più efficiente del Piano 2, il che smentisce il mito secondo cui le scansioni FULL sono "sempre male".

I risultati sarebbero molto diversi se l'obiettivo dell'ottimizzatore fosse FIRST_ROWS (n) invece di ALL_ROWS - nel qual caso l'ottimizzatore avrebbe favorito il Piano 2 in quanto spesso restituisce le prime righe più rapidamente, al costo di essere meno efficienti per l'intera query.

Answer 2

Qui è un riferimento per l'utilizzo di EXPLAIN PLAN con Oracle: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm), con informazioni specifiche sulle colonne trovate qui: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i18300

tuo menzione di 'PIENO' indica a me che la query sta facendo una full-tavolo scansione per trovare i tuoi dati. Va bene, in certe situazioni, altrimenti un indicatore di scarsa indicizzazione/scrittura di query.

Generalmente, con i piani di spiegazione, si desidera assicurarsi che la query utilizzi le chiavi, pertanto Oracle può trovare i dati che si stanno cercando con l'accesso al minor numero di righe possibile. In definitiva, a volte puoi arrivare solo lontano con l'architettura dei tuoi tavoli. Se i costi rimangono troppo alti, potrebbe essere necessario pensare di adattare il layout dello schema in modo da renderlo maggiormente basato sulle prestazioni.

Answer 3

FULL si riferisce probabilmente a una scansione completa della tabella, il che significa che non sono in uso indici. Questo di solito indica che qualcosa non va, a meno che la query non debba utilizzare tutte le righe di una tabella.

Il costo è un numero che segnala la somma dei diversi carichi, processore, memoria, disco, I/O e numeri elevati sono in genere negativi. I numeri vengono sommati quando si passa alla radice del piano e ogni ramo deve essere esaminato per individuare i colli di bottiglia.

Si potrebbe anche voler interrogare v $ sql e v $ session per ottenere statistiche sulle istruzioni SQL, e questo avrà metriche dettagliate per tutti i tipi di risorse, tempi ed esecuzioni.

Answer 4

Il CBO crea un albero decisionale, stimando i costi di ogni possibile percorso di esecuzione disponibile per query. I costi sono impostati dal parametro CPU_cost o I/O_cost impostato sull'istanza. E il CBO stima i costi, come meglio può con le statistiche esistenti delle tabelle e degli indici che verranno utilizzati dalla query. Non dovresti mettere a punto la tua query basandoti sui costi. Il costo consente di capire PERCHÉ l'ottimizzatore sta facendo quello che fa. Senza costi si potrebbe capire perché l'ottimizzatore ha scelto il piano che ha fatto. Un costo inferiore non significa una query più veloce. Ci sono casi in cui questo è vero e ci saranno casi in cui questo è sbagliato. Il costo si basa sulle statistiche del tuo tavolo e, se sono sbagliate, il costo sarà errato.

Quando si sintonizza la query, è necessario dare un'occhiata alla cardinalità e al numero di righe di ogni passaggio. Hanno senso? La cardinalità che l'ottimizzatore sta assumendo è corretta? Le righe restituite sono ragionevoli. Se le informazioni presenti sono errate, è molto probabile che l'ottimizzatore non disponga delle informazioni corrette necessarie per prendere la decisione giusta. Ciò potrebbe essere dovuto a statistiche stantie o mancanti sulla tabella e sull'indice nonché su cpu-stats. È meglio avere statistiche aggiornate quando si sintonizza una query per ottenere il massimo dall'ottimizzatore. Anche conoscere il tuo schema è di grande aiuto durante la messa a punto. Sapere quando l'ottimizzatore ha scelto una decisione davvero pessima e indicarlo nel percorso corretto con un piccolo suggerimento può risparmiare un sacco di tempo.

Answer 5

Nelle versioni Oracle recenti il ​​COST rappresenta la quantità di tempo che l'ottimizzatore si aspetta che la query effettui, espressa in unità della quantità di tempo richiesta per una lettura a blocco singolo.

Quindi, se una lettura a blocco singolo richiede 2 ms e il costo è espresso come "250", è probabile che la query richieda 500 ms per essere completata.

L'ottimizzatore calcola il costo in base al numero stimato di letture a blocchi singoli e multiblocco e al consumo di CPU del piano. quest'ultimo può essere molto utile per ridurre al minimo il costo eseguendo alcune operazioni prima di altri per cercare di evitare operazioni con costi elevati della CPU.

Ciò solleva la questione di come l'ottimizzatore sa quanto tempo occorrono per le operazioni. le recenti versioni di Oracle consentono le raccolte di "statistiche di sistema", che non devono assolutamente essere confuse con le statistiche su tabelle o indici. Le statistiche di sistema sono misure delle prestazioni dell'hardware, per lo più importante:

1. quanto tempo un unico blocco di lettura prende
2. quanto tempo una lettura multiblocco prende
3. Quanto è grande un multiblocco leggere è (spesso diverso da il massimo possibile a causa dell'estensione della tabella inferiore al massimo e per altri motivi). prestazioni
4. CPU

Questi numeri possono variare notevolmente a seconda dell'ambiente operativo del sistema, e diversi set di statistiche possono essere conservati per operazioni "OLTP diurna" e "lotti notte reporting" operazioni, e per " alla fine del mese "se lo desideri.

Dato questo insieme di statistiche, un determinato piano di esecuzione di query può essere valutato per il costo in diversi ambienti operativi, che potrebbe promuovere l'uso di scansioni di tabelle complete in alcuni momenti o scansioni di indici in altri.

Il costo non è perfetto, ma l'ottimizzatore migliora con l'autosorveglianza ad ogni rilascio e può fornire un feedback sul costo effettivo rispetto al costo stimato al fine di prendere decisioni migliori per il futuro. questo rende anche più difficile da prevedere.

Si noti che il costo non è necessariamente tempo di orologio, in quanto le operazioni di query parallele consumano una quantità totale di tempo su più thread.

Nelle versioni precedenti di Oracle il costo delle operazioni della CPU veniva ignorato ei costi relativi delle letture a singolo e multiblocco venivano effettivamente riparati in base ai parametri di init.