Bind Peeking e lista dei desideri
lunedì 30 luglio 2007 alle 30:00 | Pubblicato in Diario, Performance Tuning | 4 commentiOggi 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.
4 commenti »
RSS feed dei commenti a questo articolo. TrackBack URI
Lascia un Commento
Bookmarking
Commenti recenti
Nicola su Concorrenza e consistenza in… Cristian Cudizio su Inghippi con il Character… Alessandro su Inghippi con il Character… Alessandro su Il comando MERGE Alessandro su Inghippi con le date -
English Blog
Read Translated version of this blog
Blog su WordPress.com. | Tema: Pool di Borja Fernandez.
Voci e commenti feeds.
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
Comment by Alessandro Deledda— martedì 7 agosto 2007 #
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
:= 42;
SQL> exec
PL/SQL procedure successfully completed.
SQL> select * from t where 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.
Comment by Alberto Dell'Era— domenica 30 dicembre 2007 #
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.
Comment by cristiancudizio— lunedì 31 dicembre 2007 #
[...] 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 [...]
Pingback by Bind Variable Peeking « Oracle and other— lunedì 31 dicembre 2007 #