Instance Efficiency Indicators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 99.99
Buffer Hit %: 99.99 Optimal W/A Exec %: 100.00
Library Hit %: 93.59 Soft Parse %: 93.83
Execute to Parse %: -43.82 Latch Hit %: 99.54
Parse CPU to Parse Elapsd %: 98.17 % Non-Parse CPU: 96.70
Was steckt jedoch wirklich hinter dieser negativen Zahl?Die Anwendung, die diese Datenbank benutzt, hält nicht viel von Bind-Variablen. Deshalb war zu erwarten, dass dieser Wert gegen "0" geht. Ein negativer Wert bedeutet jedoch das Folgende:
Der Wert setzt sich zusammen aus [geparste SQLs]/[ausgeführte SQLs]*100. Normaler Weise sind die ausgeführten SQLs deutlich höher als die geparsten. Deshalb geht der Wert auch eher gegen 100% statt gegen 0%. In diesem Fall war aber die Anzahl der geparsten SQLs deutlich höher als die Anzahl der ausgeführten SQLs. Mit anderen Worten, die Anwendung lässt SQLs von der Datenbank parsen, die aber nie ausgeführt werden. Es werden hier also Datenbankressourcen verschwendet mit Operationen die niemand benötigt.
Was hier zu tun ist, liegt auf der Hand. Die Anwendung muss untersucht und bereinigt werden.
Update 2015-08-27:
Dieses Phänomen habe ich mittlerweile bei mehreren Datenbanken beobachtet. Wann immer die Entwickler der Anwendungen damit konfrontiert wurden, wurde dieses Verhalten der Anwendung vehement abgestritten. Meistens wird behauptet, dass SQLs nicht "prepared" werden und deshalb keine negative Zahl erscheinen kann. Es muss also mehr dahinter stecken als nur diese einfache Rechnung. Fakt ist, dass in der Datenbank etwas nicht ordnungsgemäß läuft.
Updates folgen...
Thrat's IT
