Sascha Lorenz - with a passion for massive SQL Server workloads

Hier noch mal alle Folien zu meinem Einführungsvortrag PowerShell für SQL Server Administratoren. PowerShell 101 für SQL Administratoren - SQLSaturday #313 Rheinland from Sascha Lorenz    

Ein Kunde hat mir vor ein paar Tagen seinen Kummer mitgeteilt, wie Anwendungsentwickler in einem Projekt mit sogenannten Named-Value bzw .Entity-Attribute-Value Tabellen und deren Abfrage umgegangen sind. Bei einem EAV Modell werden die Werte nicht in expliziten Spalten persistiert, sondern über einen Attributschlüssel verwaltet. Mehr siehe im Link oben (interessant in diesem Link auch der Hinweis auf Sparse columns, wobei ich diese nicht als Alternative sehe!). Gegen die Verwendung von EAV Modellen spricht eigentlich nichts. Ich selbst habe diese Form der Modellierung in einigen Projekten vorgeschlagen, wenn die Herausforderung danach verlangte. Man erkauft sich eine Menge Flexibilität im Datenmodell mit der Last, dass man dieses später wesentlich aufwendiger in der Pflege und Abfrage ist. Nun ja, irgendwas ist ja immer. Sowohl in OLTP als auch in Data Warehouse Projekten trifft man also gern auf so etwas. Im Data Warehouse Umfeld finden wir diese Form der Modellierung für Fakt...

Immer wieder stelle ich fest, dass sowohl kaufmännische Entscheider als auch IT-Leiter in größeren Organisationen die Vorstellung haben, dass ein Data Warehouse auch ein extra Produkt einer Business Intelligence Umgebung sein müsste. Gar nicht so selten sind Zitate wie: “Ach so, sie nutzen den SQL Server auch als Data Warehouse. Nun ja, interessant. Kann man wohl machen… Dennoch…”. Da war das Marketing der Marktbegleiter einfach gut! By the way, bei denen ist das Data Warehouse auch eine relationale Datenbank. Also, ähm, wenn die denn eines einsetzen. Nur diese Diskussion sollten wir an anderer Stelle führen. Okay, ein Satz dazu. Sich gegen ein Data Warehouse zu entscheiden ist keine Frage der Auswahl eines BI Tool Anbieters, sondern eine Architektur Frage, welche gewissenhaft & seriös beantwortet werden muss. </Ende> Nur kurz angemerkt. Wenn wir uns über wirkliche große Szenarien unterhalten, dann ist JEDE relationale Engine JEDER etablierten Datenbank irgendwann am En...

Gestern ist auf Channel 9 der erste Teil einer kleinen Community Webcast Reihe vom Peter Kirchner und mir zum Thema SQL Server speziell für ISVs online gegangen. Die weiteren Teile werden dann ebenfalls in den nächsten Wochen online gehen. Was machen wir in diesen Casts? Hier der “Klappentext”: “ In diesem ersten Teil der Webcast-Reihe von Sascha Lorenz und Peter Kirchner zum SQL Server 2008 R2 erhalten Sie einen kurzen Überblick über die Inhalte dieser Webcast-Reihe sowie als Einstieg in das Thema einige Grundlagen, die jeder besitzen sollte, wer mit dem SQL Server arbeitet. Bereits diese Grundlagen können gängige Fehler in Implementierungen, die den SQL Server betreffen, vermeiden und sogar bereits positive Auswirkungen auf die Performance Ihrer Softwarelösungen haben. Insbesondere das Verständnis für Abfragen soll geschärft werden, beim SQL Server in Mengen anstatt in Datensätzen zu denken. Gerade dieses Thema dürfte für Entwickler, die mit Oracle vertraut sind und nun für den Mi...

Das Geschäft als Berater bzw. als Coach besteht ja auch zum Teil daraus, dass man zur richtigen Zeit den richtigen Spruch bzw. Lehrsatz auf den Lippen hat. “Der Stern, die Schneeflocke oder die Galaxie ist nicht gleichzusetzen mit dem daraus entstehenden multidimensionalem Raum!” Kurzfassung: Der Stern ist nicht der Würfel! Viele Anwender der Analysis Services arbeiten aber gerne mit der Vorstellung , dass das Starschema nicht nur die Quelle darstellt, sondern auch, dass im Cube die Trennung zwischen Dimensionen und Fakten existiert. Dimensions- und Faktentabellen sind aber “nur” relationale Strukturen, welche als Datenquellen für den Würfel dienen. Viele Frontends, wie auch Excel, unterscheiden aber sehr deutlich in der Darstellung zwischen Attributen (Dimensionen) und Measures. Der eigentliche Cube bzw. der, wie ich finde korrektere Ausdruck, multidimensionale Raum haben aber ihre ganz eigene “Logik”. Wie kommen wir da jetzt raus? Muss nun jeder Endanwender eine hocheso...

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 ...

Immer wieder sehe ich bei der Analyse von Anwendungen, dass mit sogenannten Tabellenhinweisen (table hints) gearbeitet wird. Meist ist die Begründung, dass der “doofe” SQL Server einfach nicht verstanden hat, dass es doch extra einen nicht-gruppierten Index für die Abfrage gibt. Den hat der doch einfach ignoriert! Und von anderen Entwicklungsumgebungen sei man ja schließlich auch gewöhnt die Verwendung von Indizes explizit anzugeben. Wo ist also das Problem? Nun ja, das Problem ist, dass die Erfahrung gezeigt hat, dass wenn soweit alles in Ordnung ist, der SQL Server ziemlich genau weiß, was er da so macht bei der Aufbereitung von Abfragen. Und wenn er einen Index nicht nutzen möchte, dann hat er in der Regel einen verdammt guten Grund dafür. Dummerweise wird dieser nicht angeben. Der häufigste Grund dafür, dass der SQL Server einen Index nicht verwendet, ist die Vermeidung von unnötiger Arbeit. Der SQL Server kann nämlich auf Basis der sogenannten Statistiken ziemlich genau abschä...

Häufig bekomme ich zu hören, dass die Adventure Works Datenbank ja zu klein sei, um mal wirklich Performance Tuning Szenarios im stillen Kämmerlein zu testen. Ok, zuerst natürlich die Anmerkung, dass wohl die wenigsten in besagtem Kämmerlein auch eine entsprechende Hardware haben, um “echte” Erlebnisse zu haben und damit Erfahrung zu sammeln. Sowas bekommt Ihr nur im Feld! Aber gut, ich gebe gern zu, dass die Adventure Works Umgebung tatsächlich ein wenig schlank ist. Daher hier ein paar Tipps wie Ihr an wesentlich mehr Daten kommen könnt! Erst mal die Frage an den Hersteller Microsoft, was dieser uns so bietet? Und siehe da, es gibt eine wesentlich größere Datenbank: Microsoft Contoso BI-Demodatensatz für die Einzelhandelsbranche Woher kommen die denn nun? Das ist u. a. das Futter für PowerPivot Demos! :-) Hey, wer sagt da jetzt, dass ihm der Download zu groß ist? Ihr wolltet doch mehr… Ach so, es sollen mehr Datensätze aus dem Nix entstehen und zwar genau jetzt! Auch da...

Das ist häufig eine spontane Antwort, welche ich auf den Vorschlag bekomme eine Anwendung mittel Indizes zu optimieren, wenn so das Gröbste aus dem Weg ist. Sowohl Entwickler als auch Administratoren scheint durchaus bewusst zu sein, dass Indizes und das Laufzeitverhalten einer Datenbank durchaus zusammenhängen (können). Aber ihnen scheint oft nicht die mögliche Tiefe des Themas bewusst zu sein, denn sie suchen häufig den wahren heiligen Gral der Performance Optimierung. Indizes haben sie schon, also muss es da draußen noch etwas anderes geben. Ist doch logisch, oder? :-) Mit diesem Post möchte ich den Leser, welcher sich angesprochen fühlt, dafür sensibilisieren, dass Indizierung viel mehr zu bieten hat, als er sich für den Moment vielleichtnvorstellen kann. Es hat sicherlich auch etwas damit zu tun, welche Rolle Indizes früher gespielt haben. Unter dbase III+ waren Indizes zum Beispiel eigentlich nichts anderes als nur zusätzliche Sortierreihenfolgen, welche auch für eine schne...

Anbei ein Thema, welches mir neulich erst wieder aufs Flipchart kam. Wie errechne ich in einem gruppierten Resultset möglichst einfach Zwischensummen? Nun ja, da sieht der Berater draußen schon recht spannende Konzepte in denen diverse UNION ALL eine entscheidende Rolle spielen! Dabei gibt es dafür in der Abfragesprache SQL extra ein Argument für diese Herausforderung. Kurze Anmerkung dazu, wenn Ihr zum Beispiel mit den Reporting Services unterwegs seit, dann habt Ihr diese Fragestellung sehr wahrscheinlich gar nicht, da dort Zwischensummen durch die Gruppierungsfunktion im Report abgebildet wird. So, der Rest von uns kann nun weiterlesen. Ach ja, und das betrifft jetzt nicht nur den SQL Server, wir bewegen uns da durchaus im ANSI Standard! :-) Wir nehmen unsere gute alte AdventureWorksDW2008. Als Beispiel wollen wir uns den Umsatz aus der FactInternetSales aufgeteilt nach Attributen aus der Dimension Product darstellen lassen. select EnglishProductCategoryName, EnglishProduc...

Hier ein Thema, welches mir immer wieder in Coachings von Einsteigern und Juniorberatern begegnet. Daher speziell für diese Zielgruppe ein paar Grundlagen. Wie messe ich eigentlich, ob dank einer Maßnahme eine Query “schneller” geworden ist? Der eine oder andere mag denken, dass das doch eine überflüssige Frage ist. Die Optimierung war erfolgreich, wenn eine Abfrage schneller fertig ist. Wo ist also das Problem? Und schließlich hat doch das Management Studio in der rechten untern Ecke extra dafür einen Timer. Und im Profiler kann ich mir doch auch die Dauer einer Abfrage anschauen. Damit sollte das Thema doch eigentlich durch sein, oder? Und bei vielen Queries steht da unten doch eh nur 00:00:00, die können also doch gar nicht weh tun. Nun ja, ganz so einfach ist es dann doch nicht. Die Zeit, welche eine Query benötigt, ist immer relativ und kann von vielem abhängig sein. Die wesentlich entscheidendere Größe beim Tuning ist die Anzahl der für die Beantwortung notwendigen Datenba...