Monat: November 2014

I/O Landkarte einer Applikation

Betrachten Sie einmal in Ruhe das Statement unten und das zugehörige Resultat. Es handelt sich um eine real existierende Datenbank. Die Tabellennamen habe ich angepasst um meinen Kunden zu schützen, ohne die grundlegende Bedeutung zu verändern. Es hat sich immer wieder als nützlich herausgestellt mit dem Statement unten eine Auswertung über die Verteilung des I/Os in einer Datenbank zu machen. Beim ersten Mal bin ich mehr oder weniger zufällig darauf gestossen, wie sinnvoll eine solche Auswertung ist. Es wenn man es richtig liest eine Art Landkarte einer Applikation. Die obige Darstellung ist typisch. Die Buffer gets ergeben ein Aktivitätsmuster welches den Fokus auf die Tabellen von zentraler Bedeutung für die Anwendung legt. Zudem sehen wir wie die Aktivität im Buffer cache durch das physiche Design (z.B. Indexe) und den Applications code (z.B. die Qualität der SQL/statements) unterstützt wird.  Der I/O konzentriert sich auf einige wenige Tabellen. Wenn wir die Prozentsätze des I/O addieren kommen wir dahinter, dass 97% des physischen I/Os von einigen wenigen Tabellen kommt. Es lohnt sich also, hier nach zu haken. Wie würden Sie vorgehen?


1 select OBJECT_NAME, "logical reads","physical reads",
2 round(ratio_to_report("physical reads") over ()* 100,2) "% physical reads",
3 round(ratio_to_report("logical reads") over ()* 100,2) "% buffergets"
4 from
5 (select OBJECT_NAME, sum(decode(STATISTIC_NAME,'logical reads', value ,null)) "logical reads",
6 sum(decode(STATISTIC_NAME,'physical reads', value ,null)) "physical reads"
7 from v$segment_statistics
8 where owner='VISION9_FK'
9 and STATISTIC_NAME in ('logical reads','physical reads')
10 and OBJECT_TYPE ='TABLE'
11 group by OBJECT_NAME
12 order by "logical reads" desc)
13* where rownum < 11

Bildschirmfoto 2014-07-07 um 13.40.43

 

Advertisements