Bind Peeking e lista dei desideri

lunedì 30 luglio 2007 alle 30:00 | Pubblicato su Diario, Performance Tuning | 4 commenti

Oggi rileggendo attentamente l’ultimo post di Jonathan Lewis ho ricordato un mio vecchio problema e cruccio, un problema di “performance tuning” che ho avuto tempo fa e di cui ho già accennato in questo post. Il problema si verificava con l’applicazione Java sviluppata nell’azienda per la quale lavoro: ogni tanto Oracle elaborava per una query (eseguita fra l’altro molto frequentemente di giorno) un piano di esecuzione sballato. La query era particolare e un piano di esecuzione sensato poteva essere elaborato solo usando il bind peeking o i valori letterali (cioè non variabili di sostituzione che facilitano il riuso del testo della query). Secondo il programmatore la query veniva (e viene) lanciata sempre con valori sensati per cui il piano di esecuzione corretto è ottimale. Sta di fatto che di tanto in tanto Oracle elaborava un piano di esecuzione sballato ed un “ALTER SYSTEM FLUSH SHARED_POOL” era sufficiente a fargli elaborare il piano di esecuzione corretto. Purtroppo il problema non era facilemente riproducibile (in test non si è mai verificato), quindi attivare il trace dell’evento 10053 per avere dei dettagli non era una soluzione fattibile, avrei potuto trovarmi con GigaByte di trace da analizzare. Questa esperienza mi ha fatto riflettere molto su un’informazione che avrei voluto avere ma che Oracle non da tramite alcuna vista di sistema: il valore delle variabili usato con il meccanismo del bind peeking durante l’elaborazione del piano di esecuzione, un’informazione da collegare in qualche modo alla vista di sistema V$SQL_PLAN. Invece Oracle aggiunge sempre nuove fantastiche caratteristiche, AWR, SQL Profiles, eccetera eccetera. Cose da pagare salate perchè in dotazione solo all’Enterprise Edition. Mentre i miserabili che comprano solo Standard Edition devono arraggiarsi, oppure, ancora meglio, comprare costose consulenze. Nella mia lista dei desidere delle  caratteristiche del neonato 11g (sicuramente un po’ in ritardo) quindi io metterei questa estensione della V$SQL_PLAN.

About these ads

4 commenti »

RSS feed dei commenti a questo articolo. TrackBack URI

  1. se ti va ti suggerisco di esplorare, sotto la tua assolutà responsabilità ovviamente ;-), le possibilità offerte dal package dbms_advanced_rewrite (e la nota Metalink 392214.1) questo ti dovrebbe consentire di invalidare un numero minore di cursori rispetto al flush della pool

    Alessandro

  2. In 10g, il valore delle bind variables al momento del parse (“peeked binds”) è presente nella v$sql_plan.other_xml nella riga con id=1.

    Recentemente ho scoperto che si possono leggere facilmente con un valore non documentato della dbms_xplan.display() e sorelle:

    SQL> create table t (x) as select rownum from dual connect by level create index t_idx on t(x);

    Index created.

    SQL> exec dbms_stats.gather_table_stats (user, 't', cascade=>true, method_opt=>'for all columns size 1');

    PL/SQL procedure successfully completed.

    SQL> variable x number
    SQL> exec :x := 42;

    PL/SQL procedure successfully completed.

    SQL> select * from t where x = :x;

    X
    ----------
    42

    SQL> select * from table (dbms_xplan.display_cursor (null, null, 'ADVANCED'));
    ...
    Peeked Binds (identified by position):
    --------------------------------------

    1 - :X (NUMBER): 42
    ...

    Puoi certamente anche estrarre i valori dalla other_xml direttamente, non è difficile – se cerchi su google la mia utility sga_xplan vedi un esempio di come le estraggo io.

  3. FANTASTICO!,
    grazie Alberto! Secondo me questa è un’informazione di grandissimo valore. Anche recentemente mi sono trovato a discutere sui pro e contro dell’ottimizzatore COST BASED accoppiato all’uso di bind variables. Il meccanismo del bind peeking è stata una buona soluzione, ma non completa. Secondo me capitano abbastanza spesso problemi, come sono capitati a me, in cui l’ottimizzatore fa delle scelte sbagliate e non si capisce se la causa è un comportamento errato dell’ottimizzatore (bachi difficili da trovare) o se l’applicazione ha lanciato query con valori poco selettivi. Poter recuperare l’informazione sul contenutto delle “peeked binds” può aiutare molto nella diagnosi di questi problemi.

  4. [...] 31 Dicembre 2007 Oggi ho trovato un bel regalo di fine anno fra le mie mail un commento di Alberto Dell’Era a un mio post di qualche mese fa su cui mi interrogavo sulla possibilità di reperire i valori [...]


Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com. | The Pool Theme.
Entries e commenti feeds.

Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.

Unisciti agli altri 71 follower

%d blogger cliccano Mi Piace per questo: