Database Reference
In-Depth Information
Die in SQL*Plus definierten Variablen sind beispielsweise folgendermaßen zu setzen:
64/!YDUDYDUFKDU
64/!YDUEQXPEHU
64/!H[HFD 7HVWE
3/64/SURFHGXUHVXFFHVVIXOO\FRPSOHWHG
L.: „ Wenn es nicht möglich ist, eine Variable in SQL*Plus zu definieren ( z. B. eine Variable
von einem benutzerdefinierten Typ ) , muss man einen PL/SQL-Block schreiben, wo man diese
Variable mit den Daten füllt .“
P.: „ Was machst Du, wenn die problematische SQL-Anweisung ein Langläufer ist?
L.: „ Wenn die Ausführung der SQL-Anweisung zu lange dauert, kann man sie abbrechen
und danach den jeweiligen Cursor mit Laufzeitstatistiken in der SQL-Area ermitteln, um die
kritischen Schritte des jeweiligen Ausführungsplans zu finden. Dieser Abbruch ist notwendig,
um die Ausführungsplanstatistiken ermitteln zu können, weil sie erst nach dem Beenden der
SQL-Anweisung in der View V$SQL_PLAN_STATISTICS erscheinen. Alternativ kann man
das SQL-Monitoring ( s. im Abschn. 6.2 ) für die Langläufer benutzen. In diesem Fall ist kein
Abbruch notwendig, weil die Laufzeitstatistiken beim SQL-Monitoring ständig aktualisiert
werden .“
P.: „ Wie machst Du SQL-Tuning für SQL-Anweisungen mit parallelen Operationen?
L.: „ Falls alle parallelen Sklavenprozesse auf einer Datenbankinstanz laufen, kann man
die jeweiligen Cursor mit Laufzeitstatistiken in der SQL-Area wie bei einer sequenziellen
Ausführung ermitteln. Wenn das jeweilige System aber ein RAC ist und so parametrisiert ist,
dass die Sklavenprozesse über mehrere RAC-Knoten verteilt werden können, ist es am besten,
das SQL-Monitoring einzusetzen .“
Beim formalen SQL-Tuning ist es äußerst wichtig, alle Ausführungen der problema-
tischenSQL-Anweisungzuprotokollieren,umdieseAbläufejederZeitmiteinanderver-
gleichen zu können. Die Ausführung einer SQL-Anweisung beinhaltet normalerweise
einigeAusführungenderrekursivenCursor.Eskannsein,dassgeradedieserekursiven
CursordasjeweiligePerformanz-Problemverursachen.DadieAusführungsplanstatisti-
kenkeineStatistikenderrekursivenCursorbeinhalten,istessinnvoll,diejeweiligenCur-
sor-StatistikenzusätzlichzudenAusführungsplanstatistikenzuermitteln.Einigedieser
Cursor-Statistiken(z. B.DISK_READS,BUFFER_GETS,CPU_TIME,ELAPSED_TIME,
etc.) schließen die Statistiken der rekursiven Cursor ein. Wenn man sieht, dass diese Sta-
tistikennichtzuderjeweiligenSQL-Anweisungpassen,kannmanProblememitdenre-
kursiven Cursorn mutmaßen. Die problematischen rekursiven Cursor kann man dann mit
einem SQL-Tracing ermitteln. Die Cursor-Statistiken erlauben auch wahrzunehmen, wo
dasHauptproblemderjeweiligenSQL-Anweisungliegt:imCPU-oderimWartebereich
(sogar in welcher Warteklasse), was beim SQL-Tuning helfen kann. Mit den Ausführungs-
planstatistikenistdasnichtmöglich,weilsiekeineInformationenüberdieCPU-Zeitund
überdiejeweiligenWartezuständeumfassen.
Esistauchhilfreich,diejeweiligenSession-StatistikenunddieSession-Wartezustände
zu ermitteln. Anhand der Session-Statistiken kann man beispielsweise feststellen, dass das
Search WWH ::




Custom Search