Formatierungsoption hint_report für dbms_xplan

Eine schöne Ergänzung für die dbms_xplan.display%-Funktionen in Oracle 19 hat Nigel Bayliss im Oracle Optimizer Blog angesprochen: die Formatierungsoption hint_report. Diese liefert, was bisher nur über Trace Events wie 10053 zu erkennen war: eine Information dazu, welche explizit gesetzten Hints bei der Generierung eines Ausführungsplans tatsächlich berücksichtigt wurden. Die Option liefert einen Abschnitt "Hint Report" unter dem Ausführungsplan (und unterhalb der "Predicate Information") und in diesem Report erscheinen vor den Hints auf einzelne Buchstaben abgekürzte Kategorisierungen:

• E: error - zeigt an, dass der Hint syntaktisch nicht korrekt ist und deshalb ignoriert wurde.
• U: unusued  - zeigt an, dass der Hint zwar syntaktisch korrekt ist, vom Optimizer aber nicht verwendet wurde.

Dass dieses Hilfsmittel zwar nützlich ist, aber nicht alle Fragen beantwortet, zeigt Jonathan Lewis in einem ergänzenden Artikel: in seinem Beispiel erscheint ein Hint mit dem U-Kennzeichen, aber ein anderer Hint "ordered" ist nicht mit U gekennzeichnet, obwohl der resultierende Plan deutlich zeigt, dass die Zugriffsreihenfolge nicht der Reihenfolge der Tabellen in der From-Klausel entspricht. Schuld daran ist eine Query Transformation, die die Reihenfolge in der From-Klausel vor der Planerstellung umstellte. Das Fazit des Herrn Lewis lautet: auch mit dem hint_report wird es Fälle geben, in denen man das 10053er Trace befragen muss. Und: auf den "ordered" Hint sollte man zu Gunsten seines seit 18 Jahren verfügbaren Nachfolgers "leading" verzichten.

Dokumentation für Statspack

Oracle ist ziemlich gut bei der Entwicklung von relationalen Datanbankmanagementsystemen. Weniger gut ist die Firma beim Dokumentieren der eigenen Software - und bei der geeigneten Präsentation dieser Dokumentation im Internet. Ein Stück Dokumentation, das ich auch schon gelegentlich gesucht und nicht gefunden habe, liefert Pierre Forstmann in seinem Blog: die Dokumentation für Statspack. Dass man eine komplexe Dokumentation auch über viele Releases in angemessener Form im Netz präsentieren kann, beweist übrigens Postgres.

Erweiterte pg_stat_statements_reset Funktion in Postgres 12

Auf eine interessante Ergänzung der Funktion pg_stat_statements_reset in Postgres 12 weist Daniel Westermann hin: war es bisher nur möglich, die pg_stat_statements Datenbasis komplett zu löschen, erhält die Funktion in der kommenden Version zusätzliche Parameter, die eine Löschung auf den Ebenen userid, dbid und queryid erlauben. Dadurch wird dann eine bessere Kontrolle der Statistiken zu den im System ablaufenden Queries möglich. Da die pg_stat_statements für mich das zentrale Werkzeug der Performance-Analyse in Postgres darstellt, sind solche Ergänzungen ausgesprochen willkommen.