Translation

The oldest posts, are written in Italian. If you are interested and you want read the post in English, please use Google Translator. You can find it on the right side. If the translation is wrong, please email me: I'll try to translate for you.

venerdì, ottobre 19, 2007

Statspack, forse non tutti sanno che.....

Conosco qualche DBA che dello Statspack ne ha fatto una ragione di vita, come se da esso si potessero individuare e risolvere tutti i problemi di performance legati ad un'istanza.

Premetto di essere il primo ad utilizzarlo per capire cosa c'è che non va studiando l'output che esso genera. Tuttavia, a mio avviso, Statspack deve essere un punto di partenza e non uno di arrivo.

Forse sarebbe più corretto dire che ne determinare problemi di performance, l'output più che guardarlo, andrebbe letto.

Spero di riuscire a chiarire il concetto.


1. Aggregazione dei dati
La funzionalità di base di Statspack è quella di fare due istatntanee dell'istanza in due momenti diversi; quindi si calcolano le differenze ed ne viene mostrato il risultato.

Questo però comporta un'aggregazione di dati. Purtroppo da un aggregato non è possibile estrarre un particolare.

Faccio un esempio. Se ho 100 palline che pesano 100 grammi, dico che ogni pallina pesa 1 grammo. Ma se di queste 100, 99 fossero nere ed 1 bianca, posso ancora dire che una sola pesa 1 grammo? In questo caso, l'informazione aggragata che tutte insieme pesano 100g non è sufficiente: per determinare il peso di ogni singola pallina devo necessariamente pesarle (i).

In Oracle succede una cosa analoga. L'output di Statspack mi dice che ci sono stati problemi di latching, di hard parsing, etc, ma non mi dice chi ne è stato la causa.


2. Heisemberg
Statspack è scritto in PL/SQL: quando vengono calcolati gli snapshot, vengono fatte query sul dizionario dati. In questo modo, secondo il Principio di Indeterminazione di Heisemberg, Statspak (l'osservatore) influenza l'istanza (l'osservato). Oracle 10g, cambia punto di vista: l'RDBMS stesso popola la base dati di AWR (ii).


3. Metriche inesatte
Fino alla versione 10gR1, le informazioni statistiche di uno statement non vengono aggiornate finché questo non si è concluso (iv). O meglio, la sessione aggiorna le statistiche di session e statement alla fine di ogni "database call" (v). Questo vuol dire che la macchina potrebbe star soffrendo a causa di latch contention, ma il nostro snapshot e relativo report non lo segnalano. 10gR2, ha modificato questo comportamento (v), aggiornando le statistiche ogni 5 sec.

4. Statement fantasma
Se il sistema è particolarmente sotto carico, potrebbe succedere che uno statement venga espulso dalla SQL AREA. In questo caso non sarà presente nello snapshot e quindi nel report (commento in v) (vi)


(ii) THE SELF-MANAGING DATABASE
(v) Scoping
(vi) A problem with Statspack

3 commenti:

Cristian Cudizio ha detto...

Ottima analisi. Vorrei aggiungere un anedotto su Heisemberg: recentemente stiamo facendo test con il datatabase di un nuovo cliente, un RAC su Linux a due nodi; un pomeriggio mi è stato segnalato che una particolare procedura sembrava più lenta del solito, allora ho pensato di utilizzare la fantastica interfaccia della DB Console per avere una panoramica su quanto stesse accadendo. Risultava che in quella fascia oraria una delle due istanze fosse stata a lungo molto carica perchè stavano girando i task di ADDM.

Andrea Salzano ha detto...

Ciao Cristian.
Grazie per aver scritto.

Che addirittura un'intera istanza fosse sotto stress a causa di ADDM è davvero incredibile. A volte ho il sospetto che l'unica legge che vale ovunque è quella di Murphy.

Anonimo ha detto...

quello che stavo cercando, grazie