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

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

MERGE and ORA-30926

Wenn Sie häufiger mal ein MERGE statment verwendet haben, dann kommt Ihnen der folgende Fehler wahrscheinlich bekannt vor: ORA-30926 – unable to get a stable set of rows in the source tables. Möglicherweise haben Sie auch gemerkt, dass die Abfrage in diesem Fall länger dauert. Dreimal länger, um genauer zu sagen, denn die ganze Abfrage wird drei Mal ausgeführt, wie die folgdenden Tests zeigen. 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