DBMS_XPLAN.DISPLAY_CURSOR vs Spiegare piano se non si utilizza gather_plan_statistics accennano

Question

Basta richiedere alcuni chiarimenti sulla differenza tra il 2. Da quanto ho capito, spiegano piano che dà la teorica piano di esecuzione mentre DBMS_XPLAN.DISPLAY_CURSOR ti dà la reale piano di esecuzione con statistiche di esecuzione per la dichiarazione.

EXPLAIN PLAN memorizza questi dati in PLAN_TABLE mentre DBMS_XPLAN utilizza le visualizzazioni V $ SQL_PLAN, V $ SQL_PLAN_STATISTICS e V $ SQL_PLAN_STATISTICS_ALL per le relative informazioni.

Tuttavia, per DISPLAY_CURSOR per raccogliere le statistiche di runtime effettive per quella statistica, è necessario impostare l'hint /*+ gather_plan_statistics */. Altrimenti, viene compilato solo V $ SQL_PLAN che ti fornirà solo il piano di esecuzione ma non le effettive statistiche di esecuzione. È solo con lo /*+ gather_plan_statistics */ dove V $ SQL_PLAN_STATISTICS è pieno.

Quindi la mia domanda è: se non utilizzo l'hint gather_plan_statistics, SPIEGANO PLAN e DISPLAY_CURSOR mi dà sempre lo stesso piano di esecuzione (per la stessa istruzione)?

Answer 1

Le differenze non sono molto sottili, sono enormi.

Come hai giustamente menzionato, spiega in piano memorizza i dati in plan_table e il piano viene interrogato da tale tabella. Ciò significa che SQL non viene eseguito, solo all'ottimizzatore viene richiesto di consegnare un piano. In tale configurazione, il piano dipende in gran parte dall'ambiente di ottimizzazione della sessione in cui viene eseguito il piano di spiegazione.

Con DBMS_XPLAN.DISPLAY_CURSOR si ottiene il piano come è stato eseguito in precedenza. Il piano non viene memorizzato emettendo DBMS_XPLAN.DISPLAY_CURSOR; è memorizzato nelle strutture v $ perché è stato eseguito.

In una sessione è possibile eseguire

select * from dual; 
select * from table(dbms_xplan.display_cursor); 

La query viene eseguita nel 'scegliere tra duale', questo si traduce anche nella creazione di un piano e che ho conservato nel V $ strutture. il display_cursor trova l'ultimo cursore eseguito e visualizza il piano seguito. Con questo setup/* + gather_plan_statistics */non ha valore aggiunto perché il piano e le sue statistiche sono già presenti in shared_pool.

Un'altra domanda, indipendentemente dal fatto che il piano sia sempre lo stesso dipende da molti fattori. Le variabili sono le stesse ?, stai utilizzando la condivisione del cursore adattiva, stai utilizzando SQL Stability del piano ...

La tua domanda: dare spiegazioni piano e display_cursore lo stesso piano? Non mi affiderei a questo perché con il piano di spiegazione, il piano dipende dall'ambiente di ottimizzazione delle sessioni. display_cursor è il modo migliore e preferibilmente utilizzando un cursore denominato creato dall'applicazione. Se non si utilizza la stabilità del piano SQL, il piano può cambiare quando cambiano le statistiche dell'ottimizzatore. Se si utilizza la condivisione del cursore adattiva, il piano può cambiare quando le variabili cambiano.

Un po 'di buona lettura sull'overhead del campionamento può essere trovato sul blog Jonathan Lewis. Sempre da Jonathan: gather_plan_statistics I è spesso più intelligente usare l'impostazione statistics_level "all" per il debugging anziché utilizzare/* + gather_plan_statistics */hint. Il suggerimento modifica il codice e causa un nuovo sql_id.

Spero che questo aiuti.