Samstag, 26. Februar 2011

Was ist hier eigentlich installiert? SQL Server Versionen, Editionen etc. im Überblick

Häufig treffe ich im Rahmen meines Jobs auf mir unbekannte SQL Server Installationen. Da macht es durchaus Sinn sich mal schnell einen groben Überblick über die installierten Instanzen, Versionen, Edition, Features etc. zu verschaffen.

Wie kommt man nun schnell und einfach an diesen Überblick? Welche kryptische DMV hilft? :-)

Es geht viel einfacher! Auf der SQL Server 2008 R2 DVD befindet das SQL Server-Installationscenter, welches nichts anderes ist als das SQL Server Setup. Das werden die meisten Leser schon mindestens einmal gesehen haben. Auf der linken Seite befindet sich ein Menü. Dort den Punkt Extras auswählen (im Englischen Tools). Nun kann der Bericht zur Ermittlung installierter SQL Server-Funktionen aufgerufen werden.

image

Es folgt der Microsoft SQL Server 2008 R2 Setup Discovery Report ! Dieser zeigt übrigens auch Details über SQL Server 2000 & SQL Server 2005 Installationen an.

Hier ein Beispiel:

image

Freitag, 25. Februar 2011

Coaches’ Hell: Wie entwickle ich denn jetzt so ein Vorgehensmodell für Microsoft Business Intelligence Projekte?

Kaum schreibe ich ein wenig aus der Praxis als Coach, schon kommen die Fragen. Bin ja selbst schuld.

Der Hinweis, doch bitte ein Vorgehensmodell zu nutzen, hat Wellen geschlagen. Denn wie kommt denn nun der interne als auch externe BI Entwickler/Implementierer/Berater an ein solches Vorgehensmodell. Oder fassen wir die Frage ein wenig allgemeiner: Wie kommt ein Unternehmen, welches den Microsoft Business Intelligence Stack einführen möchte, an einen entsprechenden Plan?

Und was ist überhaupt so ein Modell? Ein Projektplan? Nein, ist es nicht, sondern eher eine Art Handlungsanweisung zur Erreichung des Ziels. Nenne wir es mal nicht Karte sondern Kompass! Dieser Vergleich leuchtet vielen meist schnell ein! Projektplan ist die Karte, Modell der Kompass!

Eine Lösung kann natürlich sein, sich einen entsprechenden Partner zu suchen, welcher ein fertiges Modell liegen hat. Grundsätzlich ein guter Plan! Eine Sache gebe ich aber zu bedenken bzw. mit auf den Weg. Ruhig mal fragen, ob die Kollegen denn mehr als ein Modell dabei haben. Wenn schon von der Stange, dann bitte auch in der richtigen Größe und Farbe kaufen. Nicht jedem passt ja schließlich jedes Modell!

Und wenn man nun selbst drauf kommen muss! Was dann? Woher nehme ich meinen Kompass?

Puh… weites Feld, gibt viel zu tun!

Wie fängt man denn nun an? Es gibt eine Business Seite und eine Technik Seite. Da das hier ein SQL Server orientierter Blog ist, bleibe ich mal bei der technischen Seite. Und einigen wir uns kurz mal, dass die Einführung Projektmanagement auch übersprungen wird. :-)

Was bleibt? Genau, fast zu viel! Zum Beispiel die Definition des Ziels bzw. der Modellierung eines Cubes. Immer ein super spannendes gruppendynamisches Erlebnis für die ganze Arbeitsgruppe!

Ein Punkt, welcher Teilnehmer häufig weiterbringt, ist eine für sie verständliche Vorstellung des Ziels. Gerade für Einsteiger in das Thema BI sind Konzepte wie ein OLAP Cube doch recht abstrakt, oder? Da hilft für den Anfang dann eine vereinfachte Sicht auf die Dinge oft weiter. Das gilt besonders für Kollegen aus den kaufmännischen Abteilungen, welche spontan dem Projektteam zugeordnet wurden. Ihr seit uns herzlich willkommen!

Nur wie kann man sich nun so einen Cube vorstellen? Anwender als auch Berater schauen sich dann gern in Excel einen fertigen Cube an. Ja, das ist das Endergebnis, welches in einer GUI aufbereitet vorliegt. Meiner Erfahrung nach kommen aber gerade Anwender von diesem Standort aus schwer auf die notwenige abstrakte Ebene. Da wird sich mit Händen und Füssen an Excel geklammert. Bringt keinen Spaß.

Auch ein Sterndiagramm hilft hier meist nur bedingt weiter. Da es ja nun mal nicht wirklich einen Cube beschreibt, sondern die perfekte Quelle. Es muss eine Vorstellung des multidimensionalen Raums her.

Ok, bei drei Achsen usw. ist das ja noch fast kein Problem. Dummerweise haben Cubes häufig wesentlich mehr Achsen, sprich Dimensionen. Ein Ansatz aus meinen Coachings ist, dass sich die Teilnehmer diesen doch bitte mal als ein mehrdimensionales Array vorstellen sollen. Was ist ein Array? Das kennen die jüngeren noch aus dem Programmierkurs in der Schule.

Das hier

Array[i] = Wert

wird vielen bekannt vorkommen. Ist ein eindimensionales Array. Das “Teil” hat einfach mehrere Schubladen, welche durchnummeriert sind und wir sagen über i welche Schublade es sein darf.

Werden wir hiermit komplexer

Array[x,y] = Wert .

Das ist jetzt ein zweidimensionales Array. Ideal für einfache Koordinatensysteme.

Wie kommen wir jetzt zum Cube?

Das hier ist vereinfacht ausgedrückt ein Cube

Cube[a1,a2,a3,a4,….an] = Wert .

Jede Dimension in unserem Array steht nun für ein Attribut innerhalb des Cubes! Das lässt sich übrigens super am Flip Chart oder Whiteboard live entwickeln! :-)

Warum jetzt Attribut? Weil, hier werden sich jetzt die Älteren von uns dran erinnern können, wir ab spätestens SQL Server Analysis Services 2005 von einem attributsorientierten OLAP Cube sprechen. Das Attribut steht im Vordergrund. Was ist ein Attribut? Eine Eigenschaft innerhalb einer Dimension. Zum Beispiel eine Produktnummer, eine Produktgruppe oder ein Produktsegment. Alles Beispiele für Attribute. Und diese Attribute haben Ausprägungen. Also zum Beispiel “Holzschrauben” und “Metallschrauben” als Produktgruppen.

Wenn also a1 die Produktgruppe ist und a2 die Produktnummer, dann sieht unser Array nun so aus

Cube[Holzschrauben,4711-42,a3,a4,…an] = Wert

Unsere a1 & a2 beschreiben eine sehr sehr einfache Dimension Produkte. Und a3 & a4 sind einfach mal Dimension Zeit mit Jahr und Quartal.

Cube[Holzschrauben,4711-42,2011,Q1,…an] = Wert

Schon bauen wir uns einen sehr einfachen Cube. Durch weitere Klammern, können wir nun noch die Dimensionen kenntlich machen.

Cube[ (Holzschrauben,4711-42) , (2011,Q1) ,…an] = Wert

Denke mal, dass die Idee verstanden ist. Und was ist Wert? Unsere Measure? Nein! Hier werden wir gleich ein wenig technischer im Modell und weisen drauf hin, dass Measures ja am Ende auch “nur” eine Dimension sind. Also unsere an ist die Measure Dimension.

Cube[ (Holzschrauben,4711-42) , (2011,Q1) , Umsatz in Euro] = Wert

Auf Basis dieses Modells können wir nun mit dem Würfel spielen. Zum Beispiel den Umsatz für eine andere Schraubenart abrufen.

Cube[ (Holzschrauben,0815-05) , (2011,Q1) , Umsatz in Euro] = Wert

Und uns auch in der Zeit bewegen.

Cube[ (Holzschrauben,0815-05) , (2011,Q2) , Umsatz in Euro] = Wert

Und auch andere Measures abfragen.

Cube[ (Holzschrauben,0815-05) , (2011,Q2) , Menge in Stück] = Wert

Damit wird auch dem Laien im übrigen schnell deutlich, dass ein multidimensionaler Raum sehr wahrscheinlich recht dünn besiedelt ist. Hilft auch bei vielen Diskussionen! Glaubt mir!

So, aber genug dazu. Damit stellt Ihr das Attribut in den Mittelpunkt. Wenn Ihr nun Eurer eigenes Vorgehensmodell definieren wollt oder müsst, dann orientiert Euch daran, dass Ihr die Attribute wirklich sauber definieren müsst. Sowohl für einen OLAP Cube als auch schon im Data Warehouse. Das ist natürlich einfach so dahin geschrieben. Es ist in Projekten oft eine echte Herausforderung!

Mit den Cube = Array Modell kann aber zumindest relativ schnell über das Wesentliche diskutiert werden. Klar, jetzt fehlen noch ein paar Seiten Projektmanagement dazu. Des Weiteren macht häufig ein Reifegradmodell für eine saubere projektübergreifende Strategie Sinn.

Ich hoffe mal, dass Euch dieser Kompass und die Dialogvorlage aus der Praxis ein klein wenig den Weg in Richtung Vorgehensmodell gewiesen hat.

Mittwoch, 23. Februar 2011

Coaches’ Diary: Wie verwende ich SSIS & SSAS in Business Intelligence Projekten mit dem SQL Server denn nun wirklich richtig?

Eine Frage höre ich im Verlauf von Coachings und Workshops immer wieder:

„Wie setzen wir denn nun die Werkzeuge bzw. die Dienste rund um den SQL Server wirklich richtig ein?“

Häufig stehen dabei die Werkzeuge wie das SSMS und das BIDS im Kontext von Business Intelligence Projekten im Vordergrund.

Es geht um die klassische Frage: Was ist richtig, was ist falsch? Und schon wird es alles andere als einfach!

Die Verantwortlichen in den Unternehmen für BI Projekte möchten nach Möglichkeit schnell zum Ziel kommen. Möglichst wenig Schleifen fliegen müssen. Zeit und damit Geld soll möglichst wenig verbrannt werden. Idealerweise soll schon vor dem Start klar sein wo, wann und wie die Ladung stattfindet und was während des Fluges so alles gereicht wird. Alles äußerst löbliche Ziele für ein Projekt! Wenn da das „aber“ nicht wäre.

Genaugenommen ist unser „aber“ hier ein „Randbedingungen“.

Jedes Projekt hat Randbedingungen. Und jeder Kunde definiert diese anders. Dazu kommt, dass diese Definition in den seltensten Fällen ein zu 100% bewusster Prozess ist.

Die Randbedingungen in Projekten bestimmen in der Regel, was sich später als falsch oder richtig herausstellen wird. Genau, das wird auch erst später deutlich! Dabei müssen doch jetzt Entscheidungen getroffen werden. Idealerweise noch vor dem Start eines Projektes! Und schon sind wir in der Schublade mit den Herausforderungen des klassischen Projektmanagements gelandet. Ein wenig muffig hier.

Wie kommen wir hier wieder raus?

Reduzieren wir das Ganze doch erst mal auf den technischen Aspekt. Technik wird sich ja wohl nur richtig oder falsch anwenden lassen, oder? Das trifft auf viele technische Werkzeuge zu. Bestimmt auch auf die eine oder andere Software, vielleicht sogar auf einige BI Lösungen. Nur bestimmt nicht auf den Business Intelligence Stack von Microsoft.

Der Microsoft BI Stack ist ein ehrlicher und gut ausgestatteter Werkzeugkasten, welcher keine falsche Versprechungen macht. Mittlerweile zieht der Vergleich mit dem Werkzeugkasten auch nicht mehr, eigentlich müssten wir hier schon von einem ganzen Schrank sprechen. Nehmen wir zum Beispiel auch noch die SharePoint Welt mit auf, dann sind wir sinnbildlich schon fast bei einer ganzen Garage. Und wurden in diesen nicht die innovativsten Lösungen entwickelt? Aber wir schweifen ab.

Was ist denn nun richtig oder falsch? Hier möchte ich kurz das Bild des Golfers bemühen. Ja, genau diese Gattung Mensch, welche einen kleinen Ball mit einem teilweise wirklich nicht ergonomischen Schläger in einem unübersichtlichem Gelände in ein viel zu kleines Loch befördern möchte. Wenn man es genau bedenkt, dann ist der Vergleich zum BI Projekt gar nicht so weit, oder? Und diese Golfer nehmen Stunden bei Golftrainern. So weit, so gut. Nun ist es aber so, dass es beim Golfen kein falsch oder richtig gibt. Wie kommst? Da steht nun der ehrgeizige Golfer. Möchte seinen Schlag verbessern, was in der Regel bedeutet, weiter und öfter mal dahin wo er ihn hinhaben will. Der Trainer gibt Tipps. Mehr Gewicht nach links, weniger das Handgelenk bewegen usw. Was passiert beim ersten Schlag? Geht völlig quer. Warum? Weil der letzte Trainer, den man hatte, genau das Gegenteil geraten hat. Mehr Gewicht nach rechts, Schwung aus der Schlägerhaltung usw. Wer hat nun Recht? Das fragt sich unser Golfer und zahl ein wenig zerknirscht die Trainerstunde. Beide Trainer schlagen im Übrigen total tolle Bälle und haben ein traumhaftes Handicap. Sie haben jeweils ihren eigenen Stil beim Abschlag und diesem bleiben sie treu. Wir könnten hier auch von einem Plan sprechen. Und wer sich mal mit einem professionellen Golfer unterhalten hat, der bekommt auch eine Impression davon wie komplex dieser Plan sein kann. Und wenn wir nun munter zwischen diesen Stilen bzw. Plänen wechseln, nun ja, klar, dass es uns da den Abschlag verhagelt. Angeblich erkennt man einen guten Golftrainer auch daran, dass er nicht versucht dem Golfer seinen Stil aufzudrücken, sondern bestrebt ist die vorhandene Technik zu verbessern.

Also gibt es kein richtig oder falsch. Nur ein “passt zum Plan” oder “passt nicht zum Plan”! Was ist nun in unserem BI Projekt der Plan? Nennen wir es mal Konzept.

Und was lernen wir da draußen an der Projektfront? Eine deutliche Unterschätzung bzw. Abwertung von klassischen konzeptionellen Phasen. Mitunter kommt sogar das Gefühl auf, dass „das Konzept“ bereits ein Unwort geworden ist. Alles muss mittlerweile pragmatisch und agil sein. Nicht, dass diese Ansätze falsch wären, aber auch hier ist ein mehr oder weniger klar definiertes Ziel von Vorteil.

Aber kommen wir zur Ausgangsfrage zurück: Wie verwende ich SSIS & SSAS denn nun richtig?

Unterscheiden wir mal zwischen allgemeinen Best Practices, welche sich um Performance Fragen drehen, und Architekturen, welche das Gesamtbild der späteren Lösung entscheidend bestimmen.

Best Practices gibt es mittlerweile viele. Und die meisten sind auch in den häufigsten Fällen allgemein genug, um sie fast immer anzuwenden.

Kommen wir zur Architektur. Hier stellt sich die Frage: Wie viel Feenstaub darf es denn sein?

Hier hilft eine klare und möglichst realistische Vorstellung des Ziels deutlich weiter. Klare Antworten auf Fragen wie „Wer arbeitet später mit dem System?“ oder „Wie viele arbeiten später damit?“. Auch immer gern im Vorwege gewusst: „Warum arbeiten die überhaupt damit?“. Viel zu häufig wird davon ausgegangen, dass das doch klar ist. Fragen lohnt sich hier auf jeden Fall. Allein schon der Antworten wegen.

Ok, Versuch es auf den Punkt zu bringen. :^)

Der Microsoft BI Stack ist eine erwachsende Umgebung, welche neben einer gewissen technischen Expertise auch einen belastbaren Plan benötigt, um ans Ziel zu kommen!

Dieser Plan darf durchaus mehrstufig sein. Ich mag ja die Worte Grob- und Feinkonzept kaum schreiben.

Des Weiteren ist es in Projekten gar nicht so unüblich, dass Entscheidungen unterwegs mal zurückgenommen werden. Alles gut, ehrlich. Es muss nur in geordneten Bahnen verlaufen. Viel zu häufig wird Projektmanagement mit dem Abarbeiten eines unveränderlichen Plans verwechselt.

Es gibt eine ganze Reihe von Randbedingungen, welche für die Auswahl der jeweiligen Methode, Vorgehensweise, Vorgangs- und Reifegradmodells berücksichtigt werden müssen.

Hier ein paar Tipps aus der Coaching Praxis:

Stellt Euch die Frage, welche Entscheidungen getroffen werden müssen. Das fängt schon mit der Wahl der SQL Edition an. Entwickelt im Dialog einen Entscheidungsbaum, welcher die jeweiligen Entscheidungen beinhaltet. Dokumentiert damit, welche Auswirkungen auf ein Projekt die jeweilige Entscheidung hat. Visio hilft hier gern.

Spiegelt an diesem Entscheidungsbaum später Eure Anforderungen. Also so etwas wie 24x7 Betrieb oder auch near-real time latency der Daten. Natürlich ist auch das erwartete Datenvolumen wichtig. Sprechen wir über 80 GB oder 8 TB? Der SQL Server kann beides stemmen. Nur der Weg ist halt ein anderer.

Berücksichtigt die Rahmenbedingungen des Projektes. Also zum Beispiel: Wie viele Berater sollen, müssen oder können parallel was zum Erfolg beitragen? Die Antwort ist meist erschreckend.

Bei uns kommt zum Beispiel noch die Frage dazu, ob wir in dem Projekt mit Repositories für SSIS & SSAS arbeiten oder nicht. Das passt auch nicht immer.

Wir sehen, dass der Plan (und ja, ich nenne es Konzept) den Einsatz der Werkzeuge bestimmt und nicht umgekehrt.

„It depends!“

(Alte Beraterweisheit, welche sicherlich schon beim Bau der Pyramiden ein alter Hut war.)

Sonntag, 6. Februar 2011

Analysis Services Scale-out Vortrag auf der SQLBits 8 in Brighton, UK

Wie die Zeit doch rennt! Gerade erst wurde auf der SQLBits Site mein Vortrag von der SQLBits 7 Konferenz als Video veröffentlicht, schon gibst die SQLBits 8 ! Die Engländer geben da echt Gas.

Und ich bin stolz berichten zu dürfen, dass ich wieder als Sprecher dabei sein darf! Bin wieder als Sprecher für den Freitag ausgewählt worden. Ihr wisst ja noch, dass die SQLBits Konferenz aus drei Tagen besteht:

  • Pre Conference full day training seminars
  • Pay Friday (content is hand picked) <- da bin ich bei… :-)
  • free Community Saturday

Dieses Mal darf ich von meinen Erfahrungen mit Scale-Out Szenarien mit Analysis Services (und ein wenig SSIS) berichten. Weiter unten ist mein Abstract für die Session.

Wie ich ja schon mal geschrieben habe: Die SQLBits Konferenzen lohnen sich auf jeden Fall für jeden SQL Server Pro! UK ist günstig zu erreichen und man mal gar nicht mehr so teuer wie früher. Daher, kommt vorbei und besucht die SQLBits! Vielleicht kommen die Deutschen vor Ort dieses Mal sogar in den zweistelligen Bereich. Ich freu mich drauf!

28 Weeks later - How to scale-out your MS Business Intelligence environment
This session will demonstrate possibilities to scale-out your existing Microsoft Business Intelligence environment. The SQL Server provides much functionality that increases the scalability and flexibility of your solution by distributing data and jobs among low-priced commodity servers.
We will explore the ways how to use link dimensions, link measure groups and remote-partitions in Analysis Services. With the approach of synchronization and load balancing we can increase the high availability of the service.
We also take a close look on the Shared Scalable Database feature and how to use your SAN environment wisely.
This session will demonstrate an approach how to use Analysis Management Objects (AMO) to manage our scalable environment very flexible and without much pain.
But wait, there's much more, because our ETL Jobs also need assistance to scale out. This session will provide an approach to build an alternative decentralized SSIS scheduling system. This approach is also cloud ready!
This session delivers many samples and source code to demonstrate the approaches.

SQLBitsLogo[1]