News zu Oracle

SQL Tuning Tipp: Bindevariablen

Die Nutzung von Literalen führt dazu, dass an sich gleiche (d.h. sich nur durch Literale unter­schei­dende) 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 unwahr­scheinlich ist.

  • Im Regelfall sind Oracle-Datenbanken auf Automatisches (Shared) Memory Management konfi­gu­riert. Daher geht verschwen­deter 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 ‑statis­tiken aus dem Shared Pool in ihr Repository. Ein mit unnötigen Statements gefüllter Shared Pool führt damit zu

     * überpro­por­tional längeren Laufzeiten für die Diagnosesnapshots,

     * überpro­por­tional höherem Platzbedarf in den Diagnoserepositories,

     * überpro­por­tional  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 verur­sachte Last erheb­liche Performanceprobleme nach sich ziehen. Die eigent­liche Überwachung der Performance wird so zum Problem für die Performance.

  • Sofern eine Verbesserung der Applikation nicht (mehr) oder nicht mit vertret­barem Aufwand möglich ist, kann die Ersetzung von Literalen durch Bindevariablen daten­bank­seitig erzwungen werden.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email