Visualisierung der page Inhalte in postgres

Bertrand Drouvot, von dem ich schon viele interessante Artikel zu Oracle-Fragestellungen gelesen habe, hat in zwei Artikeln sein Tool "pgdfv" (PostgreSQL data file visualizer) vorgestellt, das zur Darstellung der Verteilung von Datensätzen innerhalb einer page bzw. eines files dient:

• Welcome to pgdfv: PostgreSQL data file visualizer:  zeigt die Ergebnisse für eine page einer Tabelle
• Visualize PostgreSQL index file with pgdfv: zeigt die Ergebnisse für eine page eines Index 

Diese Repräsentation erlaubt es auch sehr gut, die Effekte von vacuum-Operationen zu beobachten. Im ersten Artikel verweist der Autor auf Frits Hooglands Darstellung des Dateiaufbaus in postgres, die man nicht oft genug erwähnen kann.

Probleme mit der automatischen Statistikerfassung in 12c

Mohamed Houri zeigt einen interessanten Fall, in dem das in 12c ergänzte Feature der automatischen Erstellung von Optimizer Statistiken für eine zuvor leere Tabelle unerfreuliche Effekte mit sich bringt. Im geschilderten Fall erfolgt das zugehörige INSERT /*+ append */ auf Basis einer remote Tabelle und die automatische Statistikerfassung verlängerte die Laufzeit der Operation auf mehrere Tage. Das Feature wurde dabei nicht aktiv, wenn aus der Spaltenliste einzelne Spalten ausgeschlossen wurden. Zudem kann es über den Hint no_gather_optimizer_statistics deaktiviert werden. Ich muss gestehen, dass mir nicht völlig klar ist, warum die Statistikerfassung im vorgestellten Fall solche Probleme bereitet, aber die Erinnerung daran, dass man es unter Umständen unterdrücken sollte, könnte gelegentlich nützlich sein.

Extended Statistics und dynamic sampling

Eigentlich ist dynamic sampling eine Standardantwort auf falsche cardinalities für komplexe Queries mit hoher Laufzeit, bei denen das Parsing gegenüber der Gesamtlaufzeit in den Hintergrund tritt. Leider ist das Zusammenspiel zwischen dynamic sampling und statischen Statistiken noch ausbaufähig: aktuell werden z.B. extended statistics beim Einsatz von dynamic sampling komplett ignoriert - wie Franck Pachot in seinem Blog zeigt. Besonders gut gefällt mir das Fazit:

In this case, Adaptive Dynamic Sampling is a good approximation. But it would be better to have a level of dynamic sampling that does not consider a predicate as a complex one when the extended statistics exactly match the predicate. Before there is enough artificial intelligence to cope with this, the best recommendation is to focus on design. In this case, ensuring that we have only uppercase values is the best way to keep queries and estimations simple.

Ich denke, dass genau solche Effekte dafür sorgen, dass auch in Zeiten von "self-driving databases" in absehbarer Zeit nicht damit zu rechnen ist, dass Datenbankspezialisten über Umschulungen nachdenken müssen.

Verhalten der auto_sample_size in 12c

Nigel Byliss erläutert im Oracle Optimizer Blog, die erfreulichen Änderungen, die für die auto_sample_size in 12c eingeführt wurden. Dabei ist die auto_sample_size der default-Wert für den Parameter estimate_percent der dbms_stats.gather_*_stats Prozeduren. Obwohl sie für viele Statistiken tatsächlich bereits seit ihrer Einführung sehr gute Ergebnisse lieferte, gab es einen Bereich, in dem ihre Ergebnisse recht erbärmlich ausfallen konnten, nämlich die Erstellung von Histogrammen, denn dafür wurde stets ein mikroskopisches Sample von gerade einmal 5500 Datensätzen verwendet.

In 12c wird nun folgendes Verfahren verwendet:

• es erfolgt ein full table scan (also 100% Sample).
• die Ermittlung von NDV-Werten (sprich: number of distinct values) erfolgt ohne Sortierung, sondern verwendet einen "approximate NDV algorithm", der mit Hash Werten arbeitet. Die Genauigkeit dieses Algorithmus ist dicht an 100%.
• frequency und top frequency Histogramme werden mit den Daten des full table scans aufgebaut - also nicht mehr auf Basis einer minimalen Stichprobe. Zur Erinnerung: ein top frequency Histogramm kommt in Frage wenn die top 254 Werte mehr als 99% aller not null Werte ausmachen.
• hybrid histograms verwenden weiterhin ein kleineres Sample: dieser Schritt ist also von der Basiserfassung getrennt.
• Index-Statistiken werden mit einer automatisch ermittelten Stichprobengröße erzeugt.

Da mir die 5500 (non null) Zeilen in der Vergangenheit regelmäßig Ärger bereitet haben, halte ich diese Veränderung für ausgesprochen vorteilhaft.

CTAS-Statement-Texte in 12.2 Trace-Files nicht mehr gekürzt

Der Titel ist beinahe länger als der folgende Text, aber was tut man nicht alles, um den eigenen Blog nicht völlig einschlafen zu lassen: Martin Bach weist in seinem Blog darauf hin, dass die Texte in der SQL-Trace-Ausgabe für "create table as select" (aka CTAS) in 12.2 nicht mehr auf 20 Zeichen gekürzt werden, was in älteren Releases der Fall war und die Analyse solcher Operationen über Trace erschweren konnte. Darüber war ich in älteren Versionen auch schon gelegentlich gestolpert.

Mehrere SQL_IDs zu einem Query-Text

Jonathan Lewis erläutert in seinem Blog ein - zumindest für mich überraschendes (sprich: bisher unbekanntes oder wieder vergessenes) Phänomen: zum gleichen SQL Text kann es mehrere unterschiedliche SQL_IDs geben. Eine relativ bekannte Ursache dafür ist offenbar, dass die Länge der in einer Query verwendeten Bindevariablen einen Einfluss auf die Erzeugung der SQL_IDs hat, was vermutlich ein Effekt des internen library Mechanismus ist und keine Design-Entscheidung.

Darüber hinaus erwähnt der Autor die Möglichkeit, ein Statement über die Prozedur dbms_shared_pool.markhot() - nun ja: als "hot" zu markieren, was dann sinnvoll ist, wenn sehr viele Sessions permanent die gleiche Query ausführen, so dass sehr viele Zugriffe auf den gleichen child cursor erfolgen. In diesem Fall wird eine neues Attribut in v$db_objct_cache ergänzt, dass als zusätzlicher Textbestandteil hinzukommt und damit einen neuen Hash-Wert und eine neue SQL_ID hervorruft. Dazu gibt es auch eine entsprechende unmark-Routine, mit der man die Kopien wieder reduzieren kann.

Performance Feedback Optionen in 12c aktivieren und deaktivieren

Christian Antognini erläutert in seinem Blog, welche Schwierigkeiten sich in 12c ergeben, wenn man das "Performance Feedback" aktivieren oder deaktivieren möchte. Zur Erinnerung: das Performance Feedback ist ein adaptives Feature und dient zur automatischen Prüfung, ob ein initial gewählter Parallelisierungsgrad tatsächlich vorteilhaft ist. Relativ harmlos ist bei der Konfoiguration noch der Faktor, dass sich der zugehörige Parameter in 12.1 OPTIMIZER_ADAPTIVE_FEATURES nennt, während er in 12.2 (bzw. auch in 12.1, wenn man den passenden Patch installiert hat) auf den Namen OPTIMIZER_ADAPTIVE_STATISTICS hört. Daneben muss in beiden Versionen zusätzlich noch der Parameter PARALLEL_DEGREE_POLICY auf true gesetzt werden, um das Performance Feedback zu aktivieren. Weniger schön ist, dass die Reihenfolge der Setzung der Parameter eine Rolle spielt - und darüber hinaus der interne Parameter _OPTIMIZER_PERFORMANCE_FEEDBACK. Die Nacherzählung der Effekte der Reihenfolge spare ich mir an dieser Stelle.

Änderungen an v$diag_alert_ext in 12.2

Vor kurzem hat Markus Flechtner in seinem Blog auf einige Änderungen hingewiesen, die sich in 12.2 für die View v$diag_alert_ext ergeben haben, mit der man die Inhalte aus alert.log und weiteren Log-Dateien via SQL abfragen kann. Was sich leider anscheinend nicht geändert hat, ist, dass dieser Zugriff weiterhin deutlich langsamer erfolgt als der über die X$-View X$DBGALERTEXT. Dafür ist v$diag_alert_ext aber in 12.2 offiziell dokumentiert, was ihre Verwendung an Stelle des X$-Objekts interessanter macht. Wichtiger ist wahrscheinlich noch, dass v$diag_alert_ext inzwischen sinnvolle Werte in der Spalte con_id enthält und dass die View in einer PDB jeweils nur die Einträge des entsprechenden Containers anzeigt. Und für mich ist noch interessanter, dass die ergänzende View V$DIAG_TRACE_FILE einen SQL-Zugriff auf Trace-Dateien ermöglicht. In Summe sieht es danach aus, dass diese Teile der Infrastruktur inzwischen eine recht hohe Stabilität gewonnen haben - in 11.2.0.3 konnte der Zugriff auf die View noch zu recht harten ORA-07445-Fehlern führen und war daher nicht unbedingt ratsam.