Ergänzung im Oracle 12c Scheduler: EXTERNAL_SCRIPTS

Sven Weller erläutert in seinem Blog die Verwendung des Job-Typs EXTERNAL_SCRIPTS, mit dem man - nun ja: externe Skripte ausführen lassen kann: also etwa cmd-Skripte unter Windows und sh-Skripte unter Linux. Das konnte man über den (weiterhin verfügbaren) Typ EXECUTABLE auch schon in älteren Versionen, aber der neue Mechanismus scheint deutlich handlicher zu sein, besitzt eine solide Fehlerbehandlung und setzt nicht voraus, dass das auszuführende Skript lokal auf dem Server vorliegt. Sollte ich mal wieder einen guten Grund finden, ein Skript vom Scheduler ausführen zu lassen, wäre das offenbar der Weg zur Umsetzung.

Semantik der Informationen im SQL Monitor

Mohamed Houri untersucht in einer kleinen Artikelserie die Semantik der Angaben des SQL Monitor:

• ASH, SQL Monitor and Extended trace: untersucht die Angaben zur Fetch-Phase durch Vergleich mit den Aussagen von ASH und SQL Trace und stellt fest, dass diese Phase in der "Elapsed Time" Angabe des "Global Stats" Abschnitts nicht berücksichtigt wird. Eine plausiblere Aussage hinsichtlich der vollständigen Laufzeit liefert "Duration" im Abschnitt "Global Information", was bereits Nenad Noveljic in einem grundlegenden Artikel erläutert hatte.
• SQL Monitor and parsing: betrachtet die Behandlung des Parsings und weist darauf hin, dass nur die Execution Phase im SQL Monitor berücksichtigt wird. Wiederum gilt, dass ein zeitaufwändiges Parsing nur über die "Duration" zu beobachten wäre.

Sollten weitere Artikel folgen, versuche ich, sie zu ergänzen - wobei meine Erfolgsquote bei der Umsetzung solcher Absichtserklärungen zuletzt deprimierend niedrig gewesen ist...

Optische Änderungen

Das Design von Webseiten ist, wie gelegentlichen Besuchern dieses Blogs klar sein dürfte, nicht meine Kernkompetenz. Da ich hier nur noch in Ausnahmefällen Code unterbringe, bin ich jetzt auf ein Blogger-Standard-Design gewechselt. Ich hoffe, die neue Variante stört das ästhetische Empfinden der Besucher zumindest nicht mehr als die vorherige.

ORDER BY in CTEs garantiert keine Sortierung

Dass der einzige Weg, eine Sortierung für Oracle-Queries zu garantieren, die Ergänzung einer ORDER BY Klausel ist, gehört zu den Dingen auf die Tom Kyte regelmäßig hinzuweisen pflegte. In einem aktuellen Artikel zeigt Franck Pachot, dass man sich auch nicht darauf verlassen kann, dass die in einer CTE definierte Sortierung eine entsprechende Sortierung der rahmenden Query bedingt. Seit 12.2 können zur Materialisierung von CTEs "In-Memory Cursor Duration Temp Tables" verwendet werden (die im Exceution Plan mit einem Eintrag "LOAD AS SELECT (CURSOR DURATION MEMORY)" dargestellt werden), und diese Funktionalität kann die Sortierung ausschalten. Vermeiden kann man dieses Feature entweder durch seine Deaktivierung (_in_memory_cdt=off) oder durch Vermeidung der Materialisierung (inline), aber letztlich ist das Verhalten durchaus nicht unschlüssig, da die Sortierung auf globaler Query-Ebene eben nur durch ein dort definiertes ORDER BY garantiert wird.

Clustering Faktor und Index Rebuild

Jonathan Lewis liefert im Scratchpad einen interessanten Hinweis: wenn man für einen Index über dbms_stats.set_table_prefs einen geeigneten table_cached_blocks Wert setzt, um den Clustering Faktor plausibler zu gestalten, dann wirkt sich die Präferenz zwar auf folgende Aufrufe von dbms_stats aus, nicht aber auf ein "alter index ... rebuild". Nach einem Neuaufbau kann der Clustering Faktor somit zunächst massiv in die Irre führen, bis er von einer folgenden Statistikerfassung wieder korrigiert wird, was zu schwer nachvollziehbaren Effekten führen könnte.

Nachtrag 17.07.2017: mit Verweis auf den Scratchpad-Artikel hat Richard Foote einen weiteren Beitrag zum Thema geliefert, der das Verhalten mit eingängigen Beispielen erläutert.