Sascha Lorenz - with a passion for massive SQL Server workloads

Hier ein kleiner Kniff aus der Coaching Praxis! Da erkläre ich einem Kunden im Coaching lang und breit in Farbe und 3D, dass Attribute das A bis Z in einer multidimensionalen Datenbank sind und, ganz ganz wichtig, bitte als Keys bitte nur Integer Spalten verwendet werden sollten. So von wegen Performance und so! Ok, haben die meisten von Euch wohl auch schon von gehört bzw. gelesen. Ist bei größeren und komplexeren Umgebungen wirklich wichtig! Ehrlich! Natürlich kommt vom Kunden die Aussage, dass sie das ganz sicher bedacht hätten. Ich hatte da so meine Zweifel, aber keinerlei Tools zur Hand bzw. auf dem Kundenserver, um das nun kurz mal zu überprüfen. Alternative wäre ein manuelles Suchen gewesen. Da fiel mir etwas ein! Mit der Power der Kommandozeile lässt sich das nämlich herausfinden! Es folgt dieses magische Kommando: dir *.ksstore /s Und schon werden alle Attribute & die Dimensionen angezeigt, welche einen String im Key haben! Da ich die Kundendatenbank nicht nehmen...

Im Rahmen der von mir durchgeführten Coachings & Trainings für die SQL Server Analysis Services stelle ich immer wieder fest, dass sich viele Anwender/Entwickler damit zufrieden geben einen “Cube” auf einem Server zu verarbeiten und diesen von dort aus zu nutzen bzw. die Anwender darauf zugreifen zu lassen. In vielen Umgebungen ist dieses Vorgehen, um die Anforderungen zu erfüllen, völlig ausreichend. Für komplexere Umgebungen und mit mehr Last und/oder keinem echten Wartungsfenster sind die Anforderungen aber deutlich höher. Die Arbeit mit mehreren SSAS Instanzen wird dabei durchaus in Betracht gezogen, aber das Deployment der SSAS DB wird häufig manuell durchgeführt bzw. es wird “nur” das Projekt verschoben. Resümee ist, dass multidimensionale Datenbanken häufig auf jedem Server aufs Neue verarbeitet werden. Dabei hat Microsoft den SSAS einige sehr nützliche Funktionen auf den Weg gegeben, um genau das zu vermeiden. Eine davon ist die Synchronisation von SSAS Datenbanken. Hier...

Noch ein wenig was zum Thema Data Warehouse Design. Diese Woche hatte ich u. a. ein Meeting, bei dem erwähnt wurde, dass der Begriff Landing Zone bzw. Landing Area im Zusammenhang mit Data Warehouse Architekturen bisher den Teilnehmern nicht bekannt war. Für mich ist die Nutzung einer Landing Area in einer Data Warehouse Umgebung ein wesentliches Element, um eine beherrschbare Lösung zu erstellen. Ihr erinnert Euch vielleicht, dass für mich die spätere “Beherrschung” der Business Intelligence Lösung ein elementarer Punkt ist und mir meist wichtiger ist, als irgendwelche technischen Spielereien auf der “Bit-Ebene…”. Und daher hier kurz eine Erläuterung meiner Sicht auf eine Landing Zone, welche gerne auch mal Landing Area heißt. Die Aufteilung eines ETL Prozesses in sogenannte Stages ist mittlerweile relativ bekannt. Also die Daten, welche für das Data Warehouse benötigt werden, durchlaufen im Datenbewirtschaftungsprozess diverse Schritte (Stages) zur Überprüfung und Verarbeitung, ...

In meinem letzten Blogpost habe ich ja ein wenig über Vorschläge für den Entwurf von Data Warehouse Umgebungen im Kontext SQL Server geschrieben. Und mir war klar, dass ich polarisieren werde. Hab es ja so gewollt. Gab dann ja auch schön Feedback von der Community zurück. Daher hier nun weitere Erläuterungen zu dem Thema. Ein Punkt, welcher Inhalt des Feedbacks an mich war, ist das Thema Presentation Layer im Data Warehouse. Dazu wird viel in der begleitenden Literatur geschrieben und ich habe auch schon viel PowerPoint dazu gesehen. Teilweise wird sowohl in Form eines Prozesses von einem Presentation Layer gesprochen wird als auch bei einer statischen Architektur. Da sehe ich aber durchaus einen Unterschied! Hier zur Visualisierung ein paar Beispiele: Bei der Prozessdarstellung kommt der Presentation Layer meist “am Ende” des Prozesses, als der Teil, welcher dann von “Außen” sichtbar sein wird. Der Presentation Layer wird zum Beispiel im Rahmen eines ETL Prozesses am Ende “erze...

Heute Abend ist zwar schon wieder ein Treffen der Hamburger SQL Server Community (PASS Chapter), aber ich kam noch gar nicht dazu das letzte Treffen zu reflektieren. War ein super Treffen, viele Leute, gute Diskussionen und eine klasse Lokation! Bei dem Treffen habe ich eine lockere Liste von Punkten vorgestellt, welche aus meiner Sicht wichtig für den Erfolg von komplexeren Data Warehouse & Business Intelligence Projekten sind. Ein Punkt dabei war, dass ich vorgeschlagen habe, beim Entwurf für ein Data Warehouse ganz bewusst zwischen dem Presentation Layer und der eigentlichen technischen Implementierung in der Datenbank zu unterscheiden. Ich ging dabei soweit, dass ich vorschlagen habe für die physische Modellierung der Dimensionen sogenannte Key-Value-Tabellen einzusetzen. Dabei geht mein Ansatz wieder vom Attribut als Mittelpunkt aus . Das löste natürlich Diskussionen aus! Wobei ich immer sage, dass es ja KEINE Silver Bullet gibt! Also eine universelle wirklich für jeden pa...

Gestern Abend hatten wir in Hamburg ein volles Haus! Vielen Dank an alle aktiven Teilnehmer unser Community! Hier meine gestrige Liste der Ratschläge für komplexere und anspruchsvollere Business Intelligence Projekte. Ich hoffe, dass für jeden was dabei war. Das eine oder andere Thema werden wir sicherlich in den nächsten Monaten noch vertiefen. Es gab gestern ja schon einge sehr gute Diskussionen. Hat Spaß gemacht! 10. Think big, act small 9. (Be)herrsche und teile 8. Denke und spreche in Pattern 7. Wähle ein „quasi“ wiederverwendbares Datenbank Schema 6. RAW & Staging nutzen 5. Vermeide Optimierungen 4. Lerne alles über Partitionen! 3. Arbeite mit Queues / sein immer asynchron unterwegs 2. Paketausführung extern steuern & verhindern 1. Nutze den „ganzen“ Microsoft Technologie Stack

Morgen ist es ja schon wieder soweit! Unser reguläres Märztreffen für die SQL Server Community in Hamburg seht für Morgen Abend an. Thema wird sein “Best Practices für die Arbeit mit SSIS & SSAS in komplexen und anspruchsvolleren Umgebungen”. Dabei werden wir uns 10 Ratschläge aus der Projektpraxis anschauen. Details zum Treffen findet Ihr auf www.sqlpass.de unter der Regionalgruppe Hamburg. Freue mich möglichst viele von Euch auf dem Treffen zu sehen!

Heute noch schnell eine Antwort auf eine Frage aus der Community. In meinen “ The Developer Side of Microsoft Business Intelligence ” Vorträgen verweise des Öfteren darauf, dass es möglich ist die Eigenschaften eines SSIS Paketes bzw. eines Taskhosts eines Paketes auszulesen. Hier meine übliche Folie dazu.   Nur wie können nun die Eigenschaften ausgelesen werden ohne, dass man weiß wie die Eigenschaften denn nun im Detail jeweils heißen? Da hilft mein bester Freund, die “foreach” Schleife, weiter! Und ein klein wenig müssen wir auch mit Try-Catch arbeiten. Hier der Code, um die grundlegenden Eigenschaften eines Paketes auszulesen: Microsoft.SqlServer.Dts.Runtime.Application app = new Microsoft.SqlServer.Dts.Runtime.Application();            DialogResult result = openFileDialog1.ShowDialog();            if(result == DialogResult.OK)    ...

Und schon wieder steht ein PASS Treffen vor der Tür! Nächste Woche (Mittwoch, den 9.3.2011) treffen wir uns wieder. Laut meinen letzten Infos treffen wir uns direkt in der Innenstadt. Der genaue Ort kommt mit der Einladung. Wie kommt Ihr an eine solche? Einfach auf www.sqlpass.de für die RG Hamburg registrieren! :-) Dieses Mal bin ich mal wieder der Sprecher. Thema meines Community Vortrags wird sein “ Best Practices für SSIS & SSAS in komplexen MS BI Umgebungen ”. Es werden sowohl technische Hinweise gegeben als auch Ratschläge für die Vorgehensweise in BI Projekten gegeben. Hoffe, dass viele von Euch die Zeit finden vorbei zu kommen! Des Weiteren bitte ich Euch den Abend des 21.3.2011 schon mal zu blocken. Denn dort ist ein Extra PASS Event in Hamburg geplant. Wir werden wieder mal Besuch von “Ausserhalb” bekommen und ein super Community Abend steht uns allen bevor! Details folgen wieder per Einladung.