Archiv der Kategorie: Allgemein

Polymorphic Table Functions (PTF), Part 4 – Table Semantic PTF

In the first three parts of the series we have seen how a PTF basically works, but we have focused on row-semantic PTF only. In this part we’ll look at the table semantic PTF. As a reminder, the main difference to row-semantic PTF is that it is not enough to look at the currently processed row to produce the result. With table semantic PTF we often also need some summarized state from the previously processed rows. They are useful to implement user defined aggregate or window functions. Let’s first try to implement a very basic example of table semantic PTF and learn more theory as we go. 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

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

MERGE and ORA-30926 – Teil 2 oder Unterschiede bei der Schreibkonsistenz zwischen Merge und Update

Im ersten Teil haben wir gesehen, wie Oracle ein Merge-Statement drei Mal ausführt, wenn es zu einem ORA-30926-Fehler kommt. Um zu verstehen, was dabei eigentlich passiert, sollten wir das Verständnis für das Konzept hinter „update restarts“ oder auch manchmal „mini rollbacks“ genannt, auffrischen. Das Konzept ist sehr gut von Tom Kyte beschrieben: Teil I, Teil II and Teil III. Wenn der Begriff „write consistency“ für Sie unbekannt ist, empfehle ich sehr, ertsmal diesen Links zu folgen. Weiterlesen

Zusammenführen der Zeitintervalle mit MATCH_RECOGNIZE

Vor einiger Zeit hat mein Kollege Philipp Salvisberg ein paar interessante Beiträge zum Thema Joinen und Mergen der Zeitintervalle gepostet. Neulich war ich auf der Suche nach Anwendungsbeispielen für die neue MATCH_RECOGNIZE Klausel, die in der 12c Datenbank eingeführt wurde und fand heraus, dass die Abfragen damit deutlich vereinfacht werden.
Weiterlesen