Beispiel

• Stellen Sie sich vor, Sie wurden am 26. Mai über einige Performance-Probleme von gestern informiert.
• Sie beschlossen, dies anhand der Grafik der Events aus der ASH (active session history) zu überprüfen.

• Wenn Ihr System überdimensioniert oder im Leerlauf ist (wie in unserem Fall), kann es nicht so einfach sein, ein Problem auf der Event-Eebene zu erkennen.
• In solchen Fällen empfehlen wir, eine Überprüfung auf Segmentebene vorzunehmen

• Auf dieser Grafik können Sie leicht 2 Probleme erkennen. Das erste lag zwischen 15 und 17 Uhr und das zweite zwischen 19 und 20 Uhr.
• Lassen Sie uns das erste Problem analysieren. TuTool bietet eine sehr nützliche Funktion zum Auffinden von SQL, welche Spitzen von logischen oder physischen Lesevorgängen auf Datensegmentebene verursachen. Dies ist die Ausgabe des entsprechenden Skripts.

• Das obere SQL hat eine Menge buffer gets benötigt, um eine Zeile zu finden. Aber es ist schwierig zu sagen, ob der FTS (full table scan) in seinem Ausführungsplan eine gute Wahl des Optimierers war oder nicht, da dieses SQL eine Aggregation hat.
• Wir müssen also die Laufzeitstatistiken im Ausführungsplan überprüfen, um dies zu entscheiden.
• Leider stellt AWR keine Laufzeitstatistiken in Ausführungsplänen zur Verfügung.
• Die nächste Möglichkeit, Laufzeitstatistiken zu erhalten, wäre also ein SQL-Monitoring-Report gewesen, aber wir konnten keine finden. Denn unser SQL ist zu schnell, um überwacht zu werden.
• Also müssen wir das problematische SQL ausführen, um die Laufzeitstatistiken zu erhalten.
• Extrahieren wir die Bind-Werte für den obigen Plan aus AWR. Zu diesem Zweck benötigen wir 3 Eingabeparameter, die wir der letzten AWR-Ausgabe entnehmen können.

• Das obige Skript extrahiert zusätzlich zu den Bind-Werten einen SQL-Text.
• Nun können wir die gefundenen Bind-Werte in das Prescript von TuTool einfügen und das SQL ausführen.

• FTS mit 878 Buffer-Gets für nur 3 Zeilen ist nicht die schnellste Lösung. Vielleicht gibt es keinen geeigneten Index für die Tabelle T1. Überprüfen wir das.

• Es gibt einen unsichtbaren Index auf der Spalte A. Für einen Fall können wir prüfen, ob diese Spalte selektiv ist.

• Ja, diese Spalte scheint selektiv zu sein. Wir können nun die Verwendung von unsichtbaren Indizes in unserer Session zulassen und das problematische SQL noch einmal ausführen.

• Die zweite Ausführung mit dem Indexzugriff ist viel besser als die erste mit FTS. Jetzt haben wir zwei Möglichkeiten, unser Problem zu lösen: entweder den Index I_T1 allgemein sichtbar zu machen oder ihn nur für unser SQL sichtbar zu machen.
• Lassen Sie uns die zweite Lösung implementieren. Dazu können wir ein SQL-Profile mit einem versteckten Hint USE_INVISIBLE_INDEXES erstellen. Dazu muss man nur den Hint eingeben, den Rest macht das Tool selbst.