SQL Tuning Tipp: Bindevariablen

Es fällt für jedes Statement CPU-Aufwand für Hard Parsing an, das im Ergebnis aber nur zu bereits bekannten Aus­füh­rungs­plä­nen führt.

Die Pufferung dieser State­ments und Aus­füh­rungs­plä­ne im Shared Pool bringt keinen Mehrwert, da die Wie­der­ver­wen­dung der State­ments un­wahr­schein­lich ist.

Im Regelfall sind Oracle-Da­ten­ban­ken auf Au­to­ma­ti­sches (Shared) Memory Ma­nage­ment kon­fi­gu­riert. Daher geht ver­schwen­de­ter Shared Pool zu Lasten des Buffer Caches. Das zieht wiederum erhöhten I/O‑Aufwand zum Nachladen ver­dräng­ter Da­ten­blö­cke nach sich.

Dia­gno­se­tools wie AWR, Statspack oder Spotlight über­tra­gen State­ments, Aus­füh­rungs­plä­ne und ‑sta­tis­ti­ken aus dem Shared Pool in ihr Re­po­si­to­ry. Ein mit unnötigen State­ments gefüllter Shared Pool führt damit zu

 * über­pro­por­tio­nal längeren Lauf­zei­ten für die Diagnosesnapshots,

 * über­pro­por­tio­nal höherem Platz­be­darf in den Diagnoserepositories,

 * über­pro­por­tio­nal  höherem Ver­drän­gen von Ap­pli­ka­ti­ons­da­ten aus dem Buffer Cache durch das Über­tra­gen von Dia­gno­se­da­ten in die Repositories.

Im Ex­trem­fall kann die so mittelbar von Dia­gno­se­tools ver­ur­sach­te Last er­heb­li­che Per­for­man­ce­pro­ble­me nach sich ziehen. Die ei­gent­li­che Über­wa­chung der Per­for­mance wird so zum Problem für die Performance.

Sofern eine Ver­bes­se­rung der Ap­pli­ka­ti­on nicht (mehr) oder nicht mit ver­tret­ba­rem Aufwand möglich ist, kann die Ersetzung von Literalen durch Bin­de­va­ria­blen da­ten­bank­sei­tig erzwungen werden.