if (not) exists für DDL in Oracle 23c

Noch ein nützliches Detail, das es in Oracle 23c geschafft hat - und das bei anderen RDBMS schon länger im Spiel war: die Möglichkeit, Fehler in SQL Skripten zu vermeiden, die sich aus der Existenz oder Nicht-Existenz von Objekten ergeben:

• create ... if not exists
• drop ... if exists

Bisher benötigte man in solchen Fällen eine relativ aufwändige Prüfung, die man sich nun sparen kann. Natürlich birgt das auch ein gewisses Risiko, da man damit natürlich wunderbar produktive Objekte beseitigen kann, aber bei DDL sollte man ohnehin immer vorsichtig sein. Eine detaillierte Erläuterung liefert - natürlich - Tim Hall: https://oracle-base.com/articles/23c/if-not-exists-ddl-clause-23c.

Group By Erweiterung in Oracle 23c

Nein, ich schreibe hier nichts mehr, aber eben habe ich eine interne SQL Schulung gehalten und darin behauptet, dass Oracle eine Positionsangabe im group by nicht unterstützt:

cdb$root@SYS:some-system > select username, count(*) from v$session group by 1;
select username, count(*) from v$session group by 1
       *
FEHLER in Zeile 1:
ORA-00979: Kein GROUP BY-Ausdruck

Mit Oracle 23c ändert sich das offenbar, wie Dani Schnider in https://danischnider.wordpress.com/2023/04/07/group-by-extensions-in-oracle-23c/ erläutert. Natürlich spendiert Oracle dafür auch noch einen Parameter group_by_position_enabled, den man auf true setzen muss, wenn man das Feature auch noch nutzen möchte.

Postgres Links: selten genutzte Features und Tipps zur Massendatenbehandlung

Nur, damit ich die Artikel - vielleicht - wieder finde: 

Der Artikel "Lesser Known PostgreSQL Features" von Haki Benita stellt - nun ja: ein paar weniger bekannter Postgres Features vor... An mir vorbei gegangen war unter anderem gen_random_uuid, womit man seit Version 13 uuid-s erzeugen kann, ohne die uuid.ossp extension installieren zu müssen.

Auf interessant ist "Common DB schema change mistakes" von Nikolay Samokhvalov, der erläutert, was man bei Massendatenoperationen besser vermeiden sollte. Hier finde ich den Hinweis auf "drop index concurrently" interessant: das hatte ich nicht mehr in Erinnerung.

Oracle Transformationen

 Jonathan Lewis hat bei Redgate eine Serie zu Transformationen des Oracle Optimizers gestartet:

• Transformations by the Oracle Optimizer: erläutert das unnesting von IN-Listen, die zu inline Views umgewandelt werden, die dann in einen Join einbezogen werden können. Außerdem werden die query blocks angesprochen, die in den Ausführungsplänen erscheinen und zur Hint-Definition eingesetzt werden können.
  
• The effects of NULL with NOT IN on Oracle transformations: erklärt (noch mal), warum es nicht immer möglich ist, NOT IN zu NOT EXISTS umzuwandeln, und inwieweit NOT NULL Constraints das ändern können. Zur Analyse des Verhaltens können die Suffixe "NA" (null-aware/accepting) und "SNA" (single null-aware/accepting) bei den Joins im Ausführungsplan herangezogen werden.

Früher habe ich an dieser Stelle gerne behauptet, dass ich folgende Artikel später ergänzen würde - aber da das schon optimistisch war, als ich noch mehr Zeit hatte, spare ich mir diese Absichtserklärung jetzt.

Rekursive CTEs

 Ja, mir ist schon klar, dass 2021 nicht das beste Jahr für diesen Blog war - wofür der Grund der übliche war: jede Menge Arbeit. Und, ich nehme es vorweg, 2022 wird nicht viel besser. Aber völlig einschlafen soll er auch nicht, so dass ich vor dem Jahresende schnell noch Franck Pachot mit seinem Artikel "Learn how to write SQL recursive CTE in 5 steps" erwähne, in dem er hübsch kompakt erklärt, wie man sich eine rekursive CTE aufbaut und wozu die Einzelteile gut sind. Auch als Apostel des yubabytedb Kults bleibt der Herr Pachot extrem lesenswert.

Oracle Performance-Gründe gegen "select *"

Nichts Neues ist, dass der Zugriff auf Tabellen ohne eine explizite Angabe der relevanten Spalten - also mit: select * from table - aus sehr vielen Gründen in der Regel keine gute Idee ist. Tanel Poder hat jetzt eine schöne Liste mit Punkten erstellt, die im Oracle-Kontext die Performance-Aspekte des Themas betreffen. Einige dieser Punkte sind auch für andere RDBMS in gleicher oder ähnlicher Weise relevant.

Postgres Performance seit Version 8.3

Ja, es ist eine Weile her, seit ich hier zuletzt etwas geschrieben habe. Und so richtig viel Neues kommt auch jetzt nicht. Nur der Link auf eine interessante Untersuchung von Tomas Vondra von 2ndQuadrant, der die Performance von Postgres beim TPC-H Benchmark für die Versionen 8.3 bis 13 untersucht. Die Ergebnisse sind in vielen Details sehr interessant und zeigen unter anderem die Rolle, die die Parallelisierung bei den neueren Releases spielt. Aus den Graphen würde ich ableiten, dass die letzten Releases seit Version 10 keine extrem spektakulären Performance-Verbesserungen mehr gebracht haben, aber durchaus eine positive Entwicklung. Das mag aber auch an der Skalierung liegen, da die Verbesserungen davor sehr deutlich sichtbar waren.

Join-Performance in relationalen Datenbanken

Damit ich den Artikel in Zukunft wiederfinde, um darauf verweisen zu können: Franck Pachot beschäftigt sich in seinem jüngsten Artikel mit dem Mythos der langsamen Joins in relationalen Datenbanken. Die dahinter stehende Vorstellung, die in den Kreisen der reinen NoSQL Enthusiasten häufig geäußert wird, ist, dass Join-Operationen in relationalen Datenbanken langsam sein müssen, da hier große Datenmengen verknüpft werden müssen, was zu einer hohen Komplexität, CPU-Last etc. führen muss, die sich abhängig von der Größe der Tabellen erhöhen.

Franck Pachot erklärt, dass diese Annahme übersieht, dass alle relationalen Datenbanken über B*Tree Indizes verfügen und die den key-values Stores vergleichbaren kleineren Suchoperationen in aller Regel mit Nested Loop Joins abbilden, wodurch die Größe der Objekte keine Rolle spielt. Er zeigt auch - am Beispiel von Postgres -, dass der Optimizer des RDBMS hier nicht als Black Box agiert (auch das ein üblicher Einwand gegen die relationalen Datenbanken), sondern Pläne über Explain Kommandos darstellen kann.

Sehr schön am Artikel ist auch, dass er sehr sachlich bleibt - und Alex DeBrie, der Autor des Artikels aus der NoSQL-Gemeinde, auf den Franck Pachot sich bezieht (und in dem sich der Abschnitt "Why relational databases don't scale" findet) in Twitter den schönen Satz "really great post by Franck Pachot, and I'm grateful for the conversation" schreiben kann. Wobei ich insgesamt den Eindruck habe, dass heute solche technischen Auseinandersetzungen in vielen Fällen etwas zivilisierter ausgetragen werden, als das in früheren Zeiten (sagen wir: vor 10, 15 Jahren) der Fall war.