Einsatz von Merge bei Historisierung von Attributen (Teil 2)

In meinem letzten Beitrag lernten wir wie die Inhalte zweier Tabellen, mit Hilfe von “MERGE”, synchronisiert werden können. Heute schauen wir uns an, wie “MERGE” uns bezüglich Historisierung der Daten behilflich sein kann.
Sicher können Sie sich noch an die Historisierung von Attributen erinnern? (Beitrag vom Juni 2011: Historische Betrachtung von Stammdaten im Data Warehouse).
Dort wurde zusätzlich zu mehreren Lösungsansätzen auch der optimale Ansatz vorgestellt, nämlich das Historisieren durch Zeitbetrachtung. Dabei kamen Update- und Insert-Statements zum Zuge.
Die Ansätze, um Änderungen in Dimensionstabellen zeitbezogen zu erfassen und gegebenenfalls historisch zu dokumentieren, sind auch unter dem Begriff “Slowly Changing Dimensions” Typ 2 (deutsch: sich langsam verändernde Dimensionen) bekannt.
Man kann mit dem MERGE-Befehl von SQL Server 2008 die Pflege einer Typ 2 Slowly Changing Dimension (SCD) in einem Data Warehouse in nur einem Befehl erledigen.
Schauen wir uns einmal alle möglichen Fälle bei einem “Slowly Changing Dimensions” (SCD2) an. weiterlesen…

NOT IN = NOT EXPECTED

Da programmiert man schon Jahrzehnte lang T-SQL und erlebt doch noch Überraschungen bei vermeintlich einfachen Befehlen. Jüngst haben wir in einer Kundenumgebung verschiedene Optimierungen durchgeführt und unter anderem NOT IN Befehle durch LEFT JOINs ausgetauscht. Erwartet haben wir ein identisches Abfrageergebnis bei deutlich besserer Performance. Aber weit gefehlt. Aus einem uns zu dem Zeitpunkt noch nicht bekannten Grund lieferte die „linke Verbindung“ ein vollkommen anderes Ergebnis als das zuvor verwendete IN-Kommando. Nach einer langwierigen Suche, mit wiederholten Zweifeln an der eigenen Fachkompetenz, haben wir den Grund schließlich gefunden. Und wie sich herausgestellt hat, ist dieser selbst für viele „alte Hasen“ überraschend. Also lassen auch Sie sich überraschen und nicht traurig sein – Sie sind in bester Gesellschaft… ;o) weiterlesen…

Partitionierte Tabellen – Faktenladen mit „Fast = TRUE“ (Teil 2)

Uuuund Action! Wie im ersten Teil dieses Beitragsthemas beschrieben, schauen wir uns heute die vorbereiteten partitionierten Tabellen in Aktion an. Im ersten Teil haben wir im SQL Server die notwendigen Partitionierungsobjekte angelegt und diese bereits auf eine Faktentabelle angewendet. Im zweiten Teil versuchen wir jetzt, neue Daten in die Faktentabelle zu importieren. Dies geschieht nicht wie sonst üblich per DELETE und INSERT, sondern mit einem sogenannten „Partition Swap“. Der vorliegende Artikel zeigt die notwendige Syntax, beleuchtet die Restriktionen und zeigt wie viel Optimierung die Partitionierung wirklich bringt. weiterlesen…

Partitionierte Tabellen – Faktenladen mit „Fast = TRUE“ (Teil 1)

Das sagenumwobene Flag „Fast = TRUE“ hat sich wohl jeder IT-ler in seinem Leben schon einmal gewünscht. Microsoft verspricht spätestens ab SQL-Server-Version 2005 eine Option, die diesem Flag schon ziemlich nahe kommt. Die Rede ist hier von der Möglichkeit, Tabellen zu partitionieren. Dies soll deutliche Performancegewinne insbesondere beim Laden und Verwalten von umfangreichen Faktendaten ermöglichen. Der Clou daran ist, dass einzelne Tabellenpartitionen einer Faktentabelle einfach gegen eine strukturidentische Deltatabelle ausgetauscht werden können. Bei dieser Operation werden lediglich Metadaten verändert, was nur einen Bruchteil der Zeit eines echten Datenimports benötigen soll.
Die Restriktionen, das allgemeine Vorgehen sowie die tatsächlichen Performancegewinne beim Partitionieren werden in Teil 1 und 2 des nachfolgenden Artikels betrachtet. weiterlesen…