Database Reference
In-Depth Information
64/!VHOHFWVTOBLGPDPL6HFIURPVHOHFWVTOBLG
PLQHODSVHGBWLPHBGHOWDGHFRGHH[HFXWLRQVBGHOWDH[HFXWLRQVBGHOWDPL
PD[HODSVHGBWLPHBGHOWDGHFRGHH[HFXWLRQVBGHOWDH[HFXWLRQVBGHOWDPDIURPZUKBVTOVWDW
ZKHUH3$56,1*B6&+(0$B,' DQGHODSVHGBWLPHBGHOWD!JURXSE\VTOBLGRUGHUE\PDPLGHVF
ZKHUHURZQXP DQGPLDQGPDPL
64/B,'6(&
NMEKJGSDZEW\
JDUIM[W[
SSEZX]YW
IGJPEFY]X
MTE[[ZXQ
KX\PWYSKJMMS
DJF]]YENG
FJJUXGESPN
JJSVQ\VG
QFWVS[G
IGK\NWN[]
64/B,'6(&
I\MY]NF
GETT]UXTW
K]DJSMYQF
GQYKIQQ
EZQ\V][WPMY
NMPPJVS
ZUUIIPZZM\
JY]WTE[X
M\EGPZQ[IFJ
URZVVHOHFWHG
Zu meinem Erstaunen fand ich gar nicht so viele SQL-Anweisungen. Das Problem war also
nicht hoffnungslos. Als ich einige Kandidaten aus der obigen Ausgabe mit den Laufzeit-
differenzen von etwa 50 s genauer untersuchen wollte, meldete sich der Datenbankadmi-
nistrator. Er hatte bereits versucht, dieses Problem selber zu lösen, und hatte alle Cursor
des jeweiligen Prozesses ermittelt. Ich schlug vor, unsere Ergebnisse miteinander zu ver-
gleichen. Unsere Cursor-Listen hatten zum Glück eine einzige Überschneidung, nämlich
den Cursor mit der SQL Id 'fdh3yk0tk3×5z'
Als nächstes ermittelte ich den jeweiligen Cursor mit den Laufzeitstatistiken aus der
SQL-Area. Dafür benutzte ich das Skript one_exec_plan_sqlarea102.sql. Die untere Aus-
gabe zeigt, dass dieser Cursor sehr performant war.
