Conditional Logic in SQL

A few days ago Sven Weller has published an excellent post about writing conditional logic in SQL and it reminded me of an example I used in one of my presentations. It is also about conditional logic in SQL but maybe some less obvious use cases in context of function calls and sorting. Weiterlesen

Polymorphic Table Functions Example – (NOT) Transposing Rows to Columns

It was not possible for me to write a follow-up to my last post about Transposing Columns To Rows with PTF showing an opposite task of transposing rows to columns right next weekend as I thought. Partly because of our awesome Trivadis TechEvent which took place back then and partly because this kind of the exercise turned out to be much more difficult one as supposed. Actually it is a nice example to see the limitations of the new feature. Weiterlesen

Polymorphic Table Functions Example – Transposing Columns To Rows

Hey, Oracle 18c is now available on the cloud and for engineered systems! For more than a week now. That also means you can play with it at LiveSQL. And of course you can try polymorphic table functions (PTF)! At least I’ve done that this weekend 😉 And here is my first working example. Weiterlesen

Polymorphe Tabellenfunktionen

Letzten Monat konnte ich an der DOAG-Jahreskonferenz in Nürnberg teilnehmen. Wie immer ein tolles Event, großartige Community und exzellente Vorträge. Und es scheint so zu sein, als hätte ich mein Lieblings-Feature der neuen Datenbank 18c gefunden. Keith Laker (@ASQLBarista), Oracle’s Produkt Manager für Analytisches SQL, sparch über „Building Agile Self-Describing SQL Functions For Big Data“. Der Vortragstitel war sehr vielversprechend und natürlich war ich nicht enttäuscht. Danke für sehr interessante Präsentation!

Dieser Beitrag ist wohl etwas ungewöhnlich, weil ich noch kein echtes Know-How teilen kann, sondern erstmal meine Begeisterung über die Mächtigkeit und Flexibilität von dem neuen Feature. Worum geht es bei dem Begriff „Polymorphic Table Functions“? Weiterlesen

ILM – ist es möglich, ADO-Policies für Compression und Storage zu mischen?

Ich hätte nie gedacht, dass ich oft über Information Lifecycle Management schreiben werde, da ich eigentlich ein Entwickler bin und kein DBA. Ich denke, ILM ist schon ein Thema, das mehr für die DBA’s Relevanz hat. Auf der anderen Seite ist es immer eine gute Sache, wenn Entwickler und DBA’s die Arbeit von einander verstehen, oder? In unserem Training „12c New Features für Entwickler“, von dem ich einer der Referenten bin, geben wir einen Einblick in die ILM Features. Das ist auch der Grund, warum ich mittlerweile schon den dritten Post darüber schreibe: um einige unklar dokumentierte Fragen auch für mich selber zu klären.

Nachdem wir uns in vorherigen Beiträgen die ADO Bedingungen für Storage Tiering Policies sowie die Verwendung von benutzerdefinierten ILM ADO Bedingungen mit PL/SQL angeschaut haben, wollte ich die Frage klären, ob es möglich ist, die Storage und Compression Policies für ein Datensegment zu mischen? Es könnte durchaus Sinn ergeben, z.B. Daten auf ein kostengünstigeren Datenträger zu verschieben und gleichzeitig zu komprimieren. Ich bin schon paar Mal über die Aussage gestolpert, das wäre nicht möglich. Es ist aber sehr einfach zu prüfen. So geht das: Weiterlesen

Benutzerdefinierte ILM ADO Bedingungen mit PL/SQL

In meinem post über ILM storage tiering habe ich über ADO-Bedingungen geschrieben, die wir für Storage Tiering Policies angeben können, wenn Datensegmente in einen Read Only Tablespace verschoben werden. Andere Möglichkeit, Storage Tiering mit einer Bedingung zu versehen wäre eine benutzerdefinierte PL/SQL-Funktion, die einen Boolean-Wert zurückgibt. Wie funktioniert das? Und können wir auf die Heat Map Information zurückgreifen? Weiterlesen

ILM storage tiering

Information Lifecycle Management ist zwar kein neuer Begriff in der Version 12c, wurde aber um zwei sehr praktische Features bereichert: Heat Map and ADO (Automatic Data Optimization). das letztere erlaubt es, die Regeln (Policies) für Datensegmente zu definieren, die wiederum aus Bedingungen und Aktionen bestehen. Die Bedingungen werden grundsätzlich anhand der mit Heat Map gesammelten Informationen überprüft und dann werden die definierten Aktionen ausgeführt: Daten komprimieren (compression tiering) oder Daten verschieben (storage tiering). „Grundsätzlich“, weil man zum einen benutzerdefinierte Bedingungen (PL/SQL-Funktionen) verwenden kann, die nicht zwingend auf die Heat Map Informationen zurückgreifen, und zum zweiten, weil es eine Art Unklarheit herrscht, wie und ob man die Bedingungen für Storage Tiering auch angeben kann. Weiterlesen

Debugging SCD2

Dieser Beitrag ist wieder über Slowly Changing Dimensions Type 2, betrachtet aber eine andere Fragestellung. Wie kann man die Erkennung der Änderungen validieren? Wenn wir mehrere Versionen derselben Daten haben, wie kann man prüfen, welche Felder sich von Version zu Version geändert haben? In Kundeprojekten, wo ich mit Systemen wie Siebel CRM gearbeitet habe, die in einigen Tabellen mehr als 500 Spalten haben, fand ich diese Möglichkeit oft sehr nützlich.
Natürlich kann man mit PL/SQL-Mitteln in einer Schleife über die Spalten ihre Werte vergleichen. Ich habe mich spaßeshalber gefragt, ob es auch in „pure SQL“ ginge – hier ist die Lösung. Weiterlesen

Datenhistorisierung II

Im vorherigen Post habe ich die Möglichkeit gezeigt, wie man eine Kombination aus UNION ALL und GROUP BY nutzen kann, um die Daten als Slowly Changing Dimension Type 2 zu historisieren. Seitdem habe ich einige Performance-Tests durchgeführt, um diesen Ansatz mit herkömmlichen Vorgehensweisen in verschiedenen Situationen zu vergleichen. Weiterlesen

Wie vereinfache ich die Historisierung der Daten?

Die Historisierung der Daten ist eine typische aber auch rechen- und zeitintensive Aufgabe im Data Warehouse Umfeld. Man hat damit beim Beladen von historisierter Core-Schicht (auch bekannt als Enterprise Data Warehouse or Foundation Layer), Data Vault Datenmodellen, Slowly Changing Dimensions, etc. zu tun. Typische Methoden führen einen Outer Join und eine Art der Deltaerkennung aus. Diese Deltaerkennung ist wohl der kniffligste Teil, denn man muss die Null-Werte besonders beachten. Eine sehr gute Übersicht der verwendeten Techniken hat Dani Schnider in seinem Blog zusammengestellt: Delta Detection in Oracle SQL

Auf der anderen Seite bietet die SQL-Standardfunktionalität genau das Verhalten an, das hier gebraucht wird: die Group By Klausel oder Partitioning-Klausel bei analytischen Funktionen. Kann man das ausnutzen? Macht es Sinn? Wie wird dann der ETL Prozess aussehen? Können wir eventuell das Laden durch Partition Exchange weiter beschleunigen? Ich werde diese Fragen in den nächsten Beiträgen beleuchten. Weiterlesen