News zu Oracle
Die Nutzung von Literalen führt dazu, dass an sich gleiche (d.h. sich nur durch Literale unterscheidende) Statements nicht als solche erkannt, sondern jeweils einzeln behandelt. Und dann werden sie auch jeweils im Shared Pool gepuffert. Daraus ergeben sich folgende Nachteile:
Es fällt für jedes Statement CPU-Aufwand für Hard Parsing an, das im Ergebnis aber nur zu bereits bekannten Ausführungsplänen führt.
Die Pufferung dieser Statements und Ausführungspläne im Shared Pool bringt keinen Mehrwert, da die Wiederverwendung der Statements unwahrscheinlich ist.
Im Regelfall sind Oracle-Datenbanken auf Automatisches (Shared) Memory Management konfiguriert. Daher geht verschwendeter Shared Pool zu Lasten des Buffer Caches. Das zieht wiederum erhöhten I/O‑Aufwand zum Nachladen verdrängter Datenblöcke nach sich.
Diagnosetools wie AWR, Statspack oder Spotlight übertragen Statements, Ausführungspläne und ‑statistiken aus dem Shared Pool in ihr Repository. Ein mit unnötigen Statements gefüllter Shared Pool führt damit zu
* überproportional längeren Laufzeiten für die Diagnosesnapshots,
* überproportional höherem Platzbedarf in den Diagnoserepositories,
* überproportional höherem Verdrängen von Applikationsdaten aus dem Buffer Cache durch das Übertragen von Diagnosedaten in die Repositories.
Im Extremfall kann die so mittelbar von Diagnosetools verursachte Last erhebliche Performanceprobleme nach sich ziehen. Die eigentliche Überwachung der Performance wird so zum Problem für die Performance.
Sofern eine Verbesserung der Applikation nicht (mehr) oder nicht mit vertretbarem Aufwand möglich ist, kann die Ersetzung von Literalen durch Bindevariablen datenbankseitig erzwungen werden.
Share this article