Quanto è preciso il PIANO EXPLAIN di Oracle?

StackOverflow https://stackoverflow.com/questions/829805

Domanda

Esistono buoni modi per misurare oggettivamente le prestazioni di una query in Oracle 10g? C'è una query particolare che sono stato tuning per un pochi giorni Ho ottenuto una versione che sembra funzionare più velocemente (almeno in base ai miei test iniziali), ma il costo di EXPLAIN è all'incirca lo stesso.

  1. Quanto è probabile che al costo EXPLAIN manchi qualcosa?
  2. Ci sono situazioni particolari in cui il costo EXPLAIN è sproporzionatamente diverso dalle prestazioni effettive della query?
  3. Ho usato il suggerimento first_rows su questa query. Questo ha un impatto?
È stato utile?

Soluzione

  

Quanto è probabile che al costo EXPLAIN manchi qualcosa?

Molto improbabile. In realtà, sarebbe un livello 1 bug :)

In realtà, se le tue statistiche sono cambiate significativamente dal momento in cui hai eseguito il EXPLAIN , il piano di query effettivo differirà. Ma fino a quando la query viene compilata, il piano rimarrà lo stesso.

Nota EXPLAIN PLAN potrebbe mostrarti cose che sono probabili ma potrebbero non accadere mai in una vera query.

Ad esempio, se si esegue un EXPLAIN PLAN su una query gerarchica: 

SELECT  *
FROM    table
START WITH
        id = :startid
CONNECT BY
        parent = PRIOR id

con indici sia su id che parent , vedrai un FULL TABLE SCAN che molto probabilmente non accadrà nella vita reale.

Usa STORED OUTLINE per archiviare e riutilizzare il piano, qualunque cosa.

  

Esistono situazioni particolari in cui il costo EXPLAIN è sproporzionatamente diverso dalle prestazioni effettive della query?

Sì, succede molto spesso su query complicate.

CBO (ottimizzatore basato sui costi) utilizza statistiche calcolate per valutare i tempi delle query e scegliere un piano ottimale.

Se hai molti JOIN , sottoquery e simili su cose nella tua query, il suo algoritmo non può prevedere esattamente quale piano sarà più veloce, specialmente quando raggiungi i limiti di memoria.

Ecco la situazione particolare che hai chiesto: HASH JOIN , ad esempio, richiederà diversi passaggi sulla tabella probe se la tabella hash non si adatta a pga_aggregate_table , ma a partire da Oracle 10g , non ricordo che questo sia mai stato preso in considerazione da CBO .

Ecco perché suggerisco ogni query che mi aspetto di eseguire per più di 2 nel peggiore dei casi.

  

Ho usato il suggerimento first_rows su questa query. Questo ha un impatto?

Questo suggerimento consentirà all'ottimizzatore di utilizzare un piano con tempi di risposta più bassi: restituirà le prime righe il prima possibile, nonostante il tempo complessivo della query sia maggiore.

In pratica, quasi sempre significa usare NESTED LOOP invece di HASH JOIN .

I

NESTED LOOP hanno prestazioni complessive inferiori su set di dati di grandi dimensioni, ma restituiscono le prime righe più velocemente (poiché non è necessario creare alcuna tabella hash).

Per quanto riguarda la query dalla domanda originale , vedi la mia risposta qui .

Altri suggerimenti

Q: Esistono buoni modi per misurare obiettivamente le prestazioni di una query in Oracle 10g?

  • La traccia Oracle è il modo migliore per misurare le prestazioni. Eseguire la query e consentire a Oracle di eseguire l'esecuzione. Nell'ambiente SQLPlus, è molto facile usare AUTOTRACE.

http://asktom.oracle.com/tkyte/article1/ autotrace.html (articolo spostato)
http://tkyte.blogspot.com /2007/04/when-explanation-doesn-sound-quite.html
http: // asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:5671636641855

E abilitare la traccia Oracle in altri ambienti non è così difficile.

Q: C'è una query particolare che sto ottimizzando da alcuni giorni. Ho ottenuto una versione che sembra funzionare più velocemente (almeno in base ai miei test iniziali), ma il costo di EXPLAIN è all'incirca lo stesso.

  • L'esecuzione effettiva dell'istruzione è ciò che deve essere misurato. EXPLAIN PLAN fa un buon lavoro nel prevedere il piano di ottimizzazione, ma in realtà non misura le prestazioni.

D: > 1 Quanto è probabile che al costo EXPLAIN manchi qualcosa?

  • Non molto probabilmente, ma ho visto casi in cui EXPLAIN PLAN ha escogitato un piano diverso dall'ottimizzatore.

D: > 2 Esistono situazioni particolari in cui il costo EXPLAIN è sproporzionatamente diverso dalle prestazioni effettive della query?

  • La risposta breve è che non ne ho osservato nessuno. Ma ancora una volta, non c'è davvero una correlazione diretta tra il costo EXPLAIN PLAN e l'effettiva performance osservata. È possibile che EXPLAIN PLAN fornisca un numero molto elevato di costi, ma che la query effettiva venga eseguita in meno di un secondo. EXPLAIN PLAN non misura le prestazioni effettive della query, per questo è necessario Oracle trace.

D: > 3 Ho usato il suggerimento first_rows su questa query. Questo ha un impatto?

  • Qualsiasi suggerimento (come / * + FIRST_ROWS * / ) può influenzare il piano selezionato dall'ottimizzatore.

Il "costo" restituito dal PIANO DI SPIEGAZIONE è relativo. È un'indicazione delle prestazioni, ma non un suo indicatore accurato. Non è possibile tradurre un numero di costo in un numero di operazioni su disco o in un numero di secondi CPU o numero di eventi di attesa.

Normalmente, troviamo che un'istruzione con un costo EXPLAIN PLAN mostrato come 1 verrà eseguita "molto rapidamente" e un'istruzione con un costo EXPLAIN PLAN dell'ordine di cinque o sei cifre richiederà più tempo correre. Ma non sempre.

Quello che sta facendo l'ottimizzatore è il confronto di molti possibili piani di esecuzione (scansione completa della tabella, utilizzo di un indice, join loop nidificato, ecc.) L'ottimizzatore sta assegnando un numero a ciascun piano, quindi selezionando il piano con il numero più basso .

Ho visto casi in cui il piano di ottimizzazione mostrato da EXPLAIN PLAN NOT corrisponde al piano effettivo utilizzato quando viene eseguita l'istruzione. L'ho visto una decina di anni fa con Oracle8, in particolare quando la dichiarazione riguardava le variabili bind, piuttosto che i letterali.

Per ottenere un costo effettivo per l'esecuzione dell'istruzione, attiva la traccia per l'istruzione. Il modo più semplice per farlo è con SQLPlus AUTOTRACE. 

[http://asktom.oracle.com/tkyte/article1/autotrace.html][4]

Al di fuori dell'ambiente SQLPlus, è possibile attivare la traccia Oracle: 

    alter session set timed_statistics = true;
    alter session set tracefile_identifier = here_is_my_session;
    alter session set events '10046 trace name context forever, level 12'
    --alter session set events '10053 trace name context forever, level 1'
    select /*-- your_statement_here --*/ ...
    alter session set events '10046 trace name context off'
    --alter session set events '10053 trace name context off'

Questo inserisce un file di traccia nella directory user_dump_dest sul server. Il file di traccia prodotto avrà il piano di istruzione E tutti gli eventi di attesa. (L'identificatore del file di traccia assegnato è incluso nel nome del file e semplifica la ricerca del file nella directory udump) 

    select value from v$parameter where name like 'user_dump_dest'

Se non si ha accesso al file di traccia, sarà necessario ottenere aiuto dal dba per ottenere l'accesso. (Il dba può creare un semplice script shell che gli sviluppatori possono eseguire su un file .trc per eseguire tkprof e modificare le autorizzazioni sul file di traccia e sull'output tkprof. È inoltre possibile utilizzare il più recente trcanlzr. Ci sono note Oracle metalink su entrambe le cose.

AFAIK, EXPLAIN sta usando alcune statistiche del database per calcolare il costo, quindi può sicuramente differire dalle prestazioni effettive.

Nella mia esperienza EXPLAIN è stato accurato e utile. In caso contrario, potrebbe non essere lo strumento utile che è. Quando è stata l'ultima volta che hai analizzato le tabelle? Ho visto dove il piano Explain era quasi lo stesso prima e dopo un'analisi, ma l'analisi ha fatto un enorme miglioramento delle prestazioni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top