Freitag, Januar 18, 2019

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.

Mittwoch, Januar 16, 2019

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.

Freitag, Januar 11, 2019

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.

Mittwoch, November 28, 2018

Verhalten von Index Splits

Wieder mal bin ich spät dran und exzerpiere relevante Artikel, kurz bevor sie aus dem 30-Tage-Korridor meines Blog Aggregators fallen. Und wieder mal ist es der zur Zeit ungeheuer produktive Jonathan Lewis, dessen Beiträge ich zusammenfasse. In den fraglichen Artikel beschäftigt sich der Herr Lewis mit dem Verhalten von "Index Splits", die auftreten, wenn ein neuer Index-Eintrag nicht mehr in den vorgesehenen Block der Index-Struktur passt:
  • Index splits: erläutert den Unterschied zwischen dem 50:50-Split (den die Statistik "leaf node splits" erfasst) und dem 90:10-Split (erfasst unter "leaf node 90-10 splits"): letzterer tritt auf, wenn der neue Eintrag oberhalb aller bisher bekannten Werte liegt - und in diesem Fall wird nur der neue Eintrag in einen eigenen Block geschrieben (weshalb der Split eher als 100:0 zu bezeichnen wäre). Theoretisch könnte der zweite Fall (also der Sonderfall) effizienter sein als er erste - er ist es aber nicht, wie der im Artikel vorgestellte Test zeigt: die Erzeugung von undo und redo sind in beiden Fällen nahezu identisch. Die Ursache dafür ist, dass beide Fälle intern gleich behandelt werden: der alte Block wird gesichert, ein neuer Block ergänzt und dann werden beide Blocks gefüllt. Die Ursache dafür ist wahrscheinlich, dass die Entwickler bei Oracle den Code nicht komplizierter machen wollten als notwendig, obwohl hier vermutlich ein gewisses Optimierungspotential existieren würde.
  • Index Splits – 2: liefert einen Test-Fall, der eine Erklärung für das im ersten Artikel beobachtete Verhalten liefert: die dabei durchgeführte Änderung am Index ändert das row directory des Blocks. Demnach ändert sich zwar nicht der Inhalt, aber die Sortierung des Blocks - und lässt das vollständige Schreiben beider Blocks sinnvoll erscheinen.
  • Index Splits – 3: liefert ergänzendes Material.

    Mittwoch, November 21, 2018

    Column Groups und NULL Werte

    Bereits vor einigen Wochen hat Jonathan Lewis auf eine Problem hingewiesen, das sich bei Verwendung von Column Groups ergeben kann: wenn der Anteil der NULL-Werte in einer Spalte sehr groß ist, dann ist das für den Optimizer über die NUM_NULLS-Information erkennbar. Da Column Groups intern über eine virtuelle Spalte abgebildet werden, die die Informationen zu den in der Gruppe enthaltenen Spalten zusammenfasst, verliert die NUM_NULLS-Information auf dieser Ebene ihre Aussagekraft, da die Spaltenkombination insgesamt nicht mehr als NULL betrachtet werden kann. Dadurch ergeben sich im Beispiel extreme Fehleinschätzungen bei der Cardinality.

    Dienstag, November 06, 2018

    Join Cardinality und Histogramme

    Jonathan Lewis hat zuletzt eine Artikelserie veröffentlicht, die sich damit beschäftigen, wie sich die Existenz unterschiedlicher Histogramm-Typen auf die Bestimmung der Join-Cardinality auswirkt. Seine Überlegungen basieren dabei auf einem umfangreicheren Artikel von Chinar Aliyev aus dem Jahr 2016. Da der Herr Lewis da natürlich sehr viele Details beleuchtet, verzichte ich weitgehend auf die Zusammenfassung und beschränke mich auf die Erfassung der Links, um die Hoffnung zu erhalten, sie bei Bedarf wiederfinden zu können:
    Wahrscheinlich wird die Artikelserie noch umfangreicher - und vielleicht erweitere ich dann auch die vorliegende Liste.

    Montag, November 05, 2018

    DAX Studio für Microsoft BI

    Zwar sind die Zeiten, in denen ich mich mit Microsofts BI-Landschaft intensiver beschäftigt habe, schon lange vorbei, aber sollte ich jemals wieder damit anfangen, dann wäre das DAX Studio sicher ein Werkzeug, das zu berücksichtigen wäre. Vincent Rainardi verweist in seinem zugehörigen Artikel auch auf eine nützliche Liste weiterer BI Tools, die unter https://www.sqlbi.com/tools/ gepflegt wird. Ich erinnere mich noch gut daran, wie ich nach der Abwanderung von Mosha Pasumansky auf eine Weiterentwicklung des ungeheuer nützlichen MDX Studios hoffte, aber leider ist daraus offenbar nie etwas geworden.

    Mittwoch, Oktober 31, 2018

    Indizierung von Foreign Keys in Oracle und Postgres

    Dass nicht indizierte Foreign Keys in Oracle massive Locking-Probleme hervorrufen können, habe ich vermutlich zum ersten Mal vor mehr als 15 Jahren bei Tom Kyte gelesen (ohne dass ich dazu gerade eine passende Textstelle liefern könnte). Franck Pachot hat jetzt darüber geschrieben, wie das Verhalten unter entsprechenden Bedingungen in Postgres aussieht - eine Frage, die eigentlich auf der Hand liegt, der nachzugehen mir bisher aber noch nicht in den Sinn gekommen war. Das Ergebnis lautet: bei Postgres ist die Indizierung der Foreign Keys nicht zur Vermeidung von Locks erforderlich, sondern nur zur Optimierung der Navigation von Parent zu Child. Grundlage dieses Verhaltens ist die Verfügbarkeit von "shared row locks" in Postgres (die es in Oracle nicht gibt). Die Details der Erklärung erzähle ich hier nicht nach - mir genügt die Erinnerung, dass beide RDBMS sich in diesem Punkt unterschiedlich verhalten.