Dienstag, September 18, 2018

ORA-01723 für DATE-Angaben

Nach langer Zeit mal wieder etwas Selbsterlebtes, das einen Eintrag zu verdienen scheint - wie man eine CTAS-Operation über das nls_date_format torpedieren kann:

SQL> alter session set nls_date_format = 'dd.mm.yyyy hh24:mi:ss';

Session altered.

SQL> create table t as select to_date(null) col1 from dual;
create table t as select to_date(null) col1 from dual
                         *
ERROR at line 1:
ORA-01723: zero-length columns are not allowed

SQL> alter session set nls_date_format = 'DD-MON-RR';

SQL> create table t as select to_date(null) col1 from dual;

Table created.

Somit wird die Tabelle T mit dem einen nls_date_format problemlos angelegt, während das andere Format einen Fehler "ORA-01723: zero-length columns are not allowed" hervorruft. Ist das ein Problem? Vermutlich nicht: sinnvoller wäre hier ohnehin der Einsatz eines CAST-Aufrufs, denn die folgende Variante funktioniert in beiden Fällen:

SQL> create table t as select cast(null as date) col1 from dual;

Montag, September 10, 2018

Detailinformationen zu dbms_stats in 12c

Jonathan Lewis schreibt in seinem jüngsten Blog-Artikel über einige nützliche Funktionen, die zu dbms_stats in 12c ergänzt wurden:
  • report_stats_operations: liefert Basisinformationen zu den Erfassungsläufen der letzten n Tage, etwa die Start- und End-Zeit und die Anzahl erfolgreicher und fehlgeschlagener Tasks. Leider ist eine Filterung der Angaben nicht über Parameter möglich, sondern muss durch einen Pl/SQL Wrapper erledigt werden.
  • report_single_stats_operation: liefert Details zu einem der von der ersten Funktion gelieferten Tasks. Über das detail_level ALL Kann man dann auch die Ursache für eine fehlschlagende Erfassung finden.
So nützlich diese Informationen sind, würde ich mir doch eher entsprechende Dictionary Views wünschen, da die Funktionsausgaben keine weitere Bearbeitung erlauben - etwa, um die Laufzeit einer Operation aus Start- und Endzeit zu ermitteln. Aber ein nützliches Hilfsmittel sind die Funktionen in jedem Fall.

Dienstag, August 21, 2018

Postgres: pg_dump blockiert DDL-Kommandos

Daniel Westermann untersucht im DBI Blog das Verhalten von DDL-Operationen im Rahmen von pg_dump. Dabei zitiert er die Postgres-Dokumentation, in der zu lesen ist:
pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).
Den Ergebnissen der Untersuchung nach ist das aber nicht uneingeschränkt zutreffend: während DML tatsächlich problemlos ablaufen kann, werden DDL-Kommandos offenbar während der Dump-Erstellung blockiert. Laut source code verwendet pg_dump das isolation level "repeatable read" und setzt ein AccessShareLock während der Sicherung. Dieses erlaubt Datenänderungen und auch die Ergänzung on Objekten (etwa Indizes), nicht aber die strukturelle Änderung bereits bestehender Objekte (create index, drop table, truncate table): diese Operationen bleiben bis zum Abschluss der Dump-Erstellung blockiert. Insofern ist die Dump-Erstellung zu Zeitpunkten, in denen keine DDL-Operationen zu erwarten sind, sicher eine sinnvolle Herangehensweise.

Donnerstag, Juli 26, 2018

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.

Freitag, Juli 20, 2018

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...

Dienstag, Juli 17, 2018

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.

Freitag, Juli 06, 2018

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.

Montag, Juli 02, 2018

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.