SQL Request (Shared SQL Area)
Verwendung
Die Ausführung einer einzigen SQL-Anweisung kann manchmal für alle Anwender negative Auswirkungen auf die Performance haben. Dies ist beispielsweise möglich, wenn die durchsuchte Datenmenge sehr groß ist oder wenn die zurückgekommenen Daten in großem Maße bearbeitet (etwa sortiert) werden müssen. Derartige Anweisungen nutzen die CPU-Zeit ineffektiv, und die Datenbankpuffer und Platten-E/A-Operationen verschlechtern die Performance für sämtliche Anwender. Es gehört zu den Aufgaben des Datenbank-Administrators, den Shared Cursor Cache (auch Shared SQL-Bereich oder Shared SQL-Area) zu überwachen, um ressourcenintensive Anweisungen zu identifizieren und zu bestimmen, wie vorzugehen ist, um deren Performance zu verbessern.
Vorgehensweise
Um den Shared Cursor Cache zu überprüfen, gehen Sie wie folgt vor:
...
1. Wählen Sie Werkzeuge → Administration → Computing Center → Management System → Control → Performance Menu → Database → Activity.
Verwenden Sie alternativ den Transaktionscode ST04.
2. Wählen Sie Detail analysis menu und anschließend SQL Request. Auf Wunsch können Sie die vorgeschlagenen Selektionskriterien (Buffer gets >= 100.000, Disk Reads >= 10.000) ändern.
Die für den Datenbank-Administrator zunächst interessantesten Angaben sind:
· Total Executions - Häufigkeit der Ausführung einer Anweisung
· Disk reads - Anzahl der für die Anweisung von der Festplatte gelesenen Oracle-Blöcke
· Buffer gets - Anzahl der für die Anweisung aus dem Datenpuffer gelesenen Oracle-Puffer-Blöcke
· Records processed - Anzahl der für die Anweisung an den R/3-Workprozess zurückgegebenen Tabellen-Zeilen
Die SQL-Anweisung selbst können Sie in der Spalte SQL Text sehen und mittels Doppelklick auf die Zeile vollständig einblenden.
Um einen Überblick über die oft im Cursor Cache ausgeführten Anweisungsarten zu erhalten, können Sie die Anzeige mit Sort nach den verschiedenen Bereichen ordnen.
Eine hoher Wert unter Total Executions ist nicht in jedem Fall beunruhigend, da einige Anweisungen häufig ausgeführt werden müssen. Wenn dagegen eine wiederholt ausgeführte SQL-Anweisung bei jeder Ausführung eine hohe Anzahl an Reads oder Gets hat, sollten Sie eine detailliertere Analyse anstreben. Überprüfen Sie, ob Indizes fehlen oder ob vorhandene Indizes fragmentiert sind. Oftmals greifen ressourcenintensive SQL-Anweisungen auf Tabellen zu, für die das Anlegen eines neuen Sekundärindex günstig wäre. Eventuell existieren Indizes zu der Tabelle, die SQL-Anweisung ist jedoch so geschrieben, daß sie diese nicht richtig nutzen kann.
Auf diesem Bildschirm ist nicht ersichtlich, welcher Benutzer bzw. welches ABAP-Programm für die ressourcenintensive Anweisung verantwortlich ist. Der Weg von der Erkenntnis, daß in einer Tabelle ressourcenintensive Anweisungen vorliegen, bis zum Auffinden des diese Anweisungen enthaltenden Programms ist mitunter recht beschwerlich. Über das Dictionary-Info-System erhalten Sie eine Beschreibung einer gegebenen Tabelle. Sie können ebenfalls ermitteln, wo diese Tabelle genutzt wird. Diese Informationen sollten Ihnen bei der Eingrenzung der Suche behilflich sein.
Siehe auch:
Überwachen der Shared-SQL Area (Oracle)