Wie in Teil 1 erwähnt, stehen Sie und wir oft vor der Frage, welche Festplatte wie performant sein muss, um den Ansprüchen eines Systems zu genügen.

Die für unsere Analyse notwendigen Daten werden von dem Programm SQLio von Microsoft erhoben:

Sie sehen in den Abbildungen die Analyse für 4 Festplatten. Jeweils die oberen vier Balken pro Diagramm spiegeln Daten für Lesezugriffe und die unteren vier für Schreibzugriffe wieder, wobei diese wiederum in vier Blockgrößen – 8, 64, 128 und 256 kB – unterteilt sind. Wie Sie vielleicht schon bemerkt haben, sind dies Werte, mit denen der SQL Server ebenso auf die Festplatte zugreift.

Auf jeder Abbildung sind die Analysen nach weiteren Datenreihen aufgeteilt: Die Datentransferrate in MB/s oder die Zugriffsrate in IO/s. Dies alles wieder wiederum nach sequenziell und zufällig verteilt aufgetrennt. So haben Sie einen direkten Vergleich, unter welchen Bedingungen eine Festplatte gut oder nicht so gut abschneidet.

In den Beispielabbildungen (nennen wir die Festplatten FP1 bis FP4 in der Reihenfolge eines “Z”) sehen Sie eine interessante Analyse.

Abb. 1                             Abb. 2

Abb. 1 und 2 zeigen den Vergleich der Festplatten 2-4 zu der Festplatte 1 für IO und MB pro Sekunde bei einer zufälligen Verteilung der zu lesenden/schreibenden Datenblöcke auf der Platte (eine Datei wird also nicht in einem Rutsch geschrieben, sondern auf der Festplatte verteilt). Die Festplatte 1 ist also die Referenz und wird sie während dieser Analyse auch bleiben. Festplatte 2 ist pro Blockgröße etwas stärker oder schwächer, aber hat keine überwiegenden Auswüchse. Festplatte 3 dagegen scheint deutlich mehr IO und MB pro Sekunde zu erreichen und hat nur bei Blockgrößen von 8 kB eine Schwäche. Festplatte 4 ist generell deutlich schwächer als unsere Referenzfestplatte.

Abb. 3                            Abb. 4

Schauen Sie sich die anderen beiden Abbildungen (3 und 4) an, die nicht eine zufäillige Verteilung der Datenblöcke lesen/schreiben sondern immer sequenziell. Sie stellen fest, dass sich die Festplatten 3 und 4, also die unteren beiden, im wesentlichen ebenso gut abschneiden wie bei den vorherigen Abbildungen.

Die Festplatte 2 jedoch zeigt einen massiven Performanzeinbruch auf, was durch die langen roten Balken signalisiert wird. Im sequenziellen Schreiben und Lesen ist diese Platte also deutlich schlechter als andere Festplatten, obwohl sie sich bei zufälligem Datenblocklesen/-schreiben wie erwartet verhält.

An dieser Stelle ist das Ziel erreicht, Problemfälle der Festplatten deutlich zu machen oder eine Möglichkeit zu zeigen, wieso ein System sehr langsam ist.

Wieso die Festplatte 2 gerade unter diesen Bedingungen sehr schlechte Werte hat, kann viele Gründe haben. Bei einer Festplatte, die bereits im Einsatz ist, könnte es sein, dass eine Festplatte so stark fragmentiert ist, dass sie sehr ähnliche Werte für die zufällige und sequenzielle Datenblockverteilung erreicht, da die Testdaten nirgends hintereinander geschrieben werden können.

Ich hoffe, jeder Leser dieses Blogs hat beim Datenbank-Design gut aufgepasst, dann wissen sie oder er ja, dass man keine unendlich breiten Tabellen erzeugen soll. Aber gut, mal unter uns und nicht weitersagen: manchmal geht es eben nicht anders, aber dann auf eigenes Risiko! Mitunter wird der SQL Server nur als so eine Art »Excel auf dem Server« missbraucht, und seit Excel 2007 jetzt auch 16.384 Spalten speichern kann (statt vorher nur 256) ist natürlich die Frage: kann der SQL Server das auch? Nun, bis zur Version 2008 kann er das nicht, da beherrscht er »nur« 1024 Spalten. Jetzt kann er diese Grenze sprengen, aber nur, wenn die zusätzlichen Spalten nur spärlich (»sparse«) gefüllt sind!

Aber zurück zum Design! Es ist wirklich eine Lücke im relationalen Modell: Ich entwerfe für Backwaren eine Produkttabelle, in der will ich etwa für Berliner (oder wenn man mich als Berliner fragt: Pfannkuchen) die Füllung abspeichern; Pflaumenmus, Eierlikör, etc. Für Croissants passt das dann auch noch, aber bei Brötchen und Brot ist diese Spalte natürlich immer leer, also NULL! Andersherum ist es mit dem Belag: bei Brötchen mag da noch manchmal Sesam, Mohn oder Kürbiskern drin stehen, aber die Mehrzahl der Produkte ist natürlich überhaupt nicht belegt, also bleibt die Belag-Spalte NULL.

Gängige Lösungen für dieses Design-Problem wären etwa eine Zusatz-Tabelle mit den Spalten Produktnummer – Attribut (Inhalt z.B. »Belag«) – Wert (Inhalt z.B. »Sonnenblumenkerne«). Diese Tabelle ist aber relational etwas schwer auszuwerten, außer mit dem PIVOT-Operator. Man könnte auch eine Spalte mit dem unten beschriebenen XML-Datentyp anhängen, aber leider ist ein großes XML-Schema nicht besonders effektiv, wenn es fast immer leer ist. Im SQL Server 2008 kann man nun solche spärlich gefüllten Spalten von Anfang an als SPARSE bezeichnen, dann nehmen sie, wenn sie leer bleiben, keinen Platz weg. Und so kann man dann auch viele tausend zusätzliche Spalten anhängen!

CREATE TABLE dbo.Produkte(
  ProduktID                int              PRIMARY KEY IDENTITY
, Produktnummer             char(12)          NOT NULL
, Produktbezeichnung        nvarchar(255)      NOT NULL
, Belag                   nvarchar(30)       SPARSE NULL
, Füllung                  nvarchar(30)       SPARSE NULL
, Fettanteil               numeric(3,1)       SPARSE NULL
/* …hier noch viele hundert SPARSE-Spalten */)

Verdammt – nun ist es passiert: Unsere hoch geschätzte SQL Server “Indexing Diva” Kimberly Tripp ist unter der Haube (wie man dem Bild unschwer entnehmen kann).

Geheiratet hat sie den seinerseits hochverehrten SQL Server Storage Engine Spezi Paul Randal. Dieser hat sich jahrelang mit der Weiterentwicklung des SQL Server Befehls DBCC herumgeschlagen und einen schönen Blog zu den SQL Server Innereien betrieben: http://blogs.msdn.com/sqlserverstorageengine. Damit ist es jetzt vorbei, da Paul in Kimberlys Firma SQLSkills eingestiegen ist und Microsoft verlässt.

Dem Leser zum Trost: Der Storage Engine-Blog lebt weiter. Und erfreut sich bester Gesundheit. Unter anderem schreibt dort ein gewisser Sunil Agarwal kenntnisreiche Beiträge. Unbedingt lesen!

Soviel für heute aus der Welt der Schönen und Reichen, Ihr ixto-Gesellschaftsreporter Georg Urban!

Wenn Sie schon einmal versucht haben herauszufinden, durch welche Features sich die Enterprise Version vom Rest der Bande unterscheidet, bevor Sie den Server angeschafft haben, dann wissen Sie: Es ist ein Kreuz! Die Onlinedokumentation geht nur sporadisch auf dieses Thema ein und die Quellen auf der Microsoft Site waren lange Zeit recht ungenau. Dabei ist es natürlich wichtig zu wissen, welche Funktionen  auf der Zielplattform einer Entwicklung zur Verfügung stehen. Sonst kann es beim Deployment unangenehme Überraschungen  geben.

Whitepapers zu den Enterprise Edition Features

Auf der Deutschen MS Website stehen inzwischen zwei übersetzte Whitepapers zur Verfügung, die nützliche Informationen über die Unterschiede zwischen Standard- und Enterprise-Edition bieten. Diese Whitepapers finden Sie über diesen Link (das ist Brad Nelsons Featurevergleich) und über diesen Link (offenbar dieselben Informationen, etwas schematischer aufbereitet).

Für den ersten Überblick tut es auch der Vergleich auf der Produktwebsite. Aber seien Sie vorsichtig: Der Teufel steckt evtl. im Detail. Und einen Lizenz-Upgrade von der Standard- zur Enterprise-Edition gibt es nicht. Schlimmstenfalls müssen Sie die Lizenzen komplett neu erwerben.

Viel Spaß beim Studieren der Whitepapers!

Die SQL Server Reporting Services enthalten eine Funktionalität, die es ermöglicht Berichte automatisiert an verschiedene Empfänger zu verschicken und pro Empfänger mit individuellen Parametern zu versehen, sowie das Ausgabeformat pro Empfänger festzulegen. Gesteuert wird das Ganze aus dem Ergebnis einer beliebigen Abfrage – deswegen hat diese Funktion auch den wunderschönen Namen Datengesteuertes Abonnement. Ein prima Sache, wenn man viele (viele!) Berichte versenden will und dafür nicht gleicht etwas selbst programmieren möchte.

Leider gibt es einen Haken. Diese Art der Abonnements steht nur in der Enterprise Edition des SQL Servers zur Verfügung. Schade!

Ich bin hin und wieder bei Reporting Services-Workshops von Kunden gefragt worden, ob es eine Alternative gibt. Nicht jeder möchte gleich die Enterprise Edition einsetzen (und bezahlen!), nur weil diese eine Funktion fehlt.

Mein Alternativvorschlag lautet: Integration Services einsetzen!

Integration Services Pakete, die Reporting Services Berichte versenden können

Die Integration Services enthalten alle Bausteine, die man für den selbst gemachten Berichtsversand benötigt:

• Die Möglichkeit eine SQL Server-Steuertabelle auszuwerten, in der die Abonnementsinformationen stehen
• Die Möglichkeit den Reporting Services Webservice anzusprechen, um Berichte remote rendern zu lassen
• Die Möglichkeit die gerenderten Berichte per eMail-Task an die Empfänger zu verschicken
• …und natürlich die passenden Ablaufsteuerungselemente, um die Programmlogik zu implementieren

Ich habe seit längerer Zeit ein SSRS-Paket im Einsatz, welches Berichte effektiv und stabil versendet.

Im zweiten Teil dieser Blogserie erfahren Sie mehr darüber. Da wird es um den Aufruf des Reporting Services Dienstes aus SSIS heraus gehen.

Viele Controller kennen und lieben sie aus Excel: die Trendlinie. Mal eben die Umsätze der letzten Quartale als Balkendiagramm betrachtet und mit zwei Klicks den Trend visualisiert.

Um so verwirrter guckt dann dieser Controller, wenn man ihm versucht zu erklären, dass das mit den Reporting Services nicht möglich ist. Zum Glück stimmt das auch nicht ganz.

Mit Hilfe von Dundas Chart für Reporting Services ist dies fast so einfach wie in Excel. Der Haken liegt dann nur noch bei den Lizenzkosten.

Aber auch ohne zusätzliche Software sind einfache Trendlinien mit SSRS möglich, denn genaugenommen ist das ja nichts weiter als ein “bisschen” Mathematik.

Grundlage für die oben gezeigte gerade Trendlinie ist die einfache lineare Regression. Und dafür gibt es in MDX Funktionen, die sich nutzen lassen, um diesen Trend zu berechnen. Die Grundlagen dieser MDX Funktionen und der mathematischen Konzepte dahinter hat Mosha bereits vor einigen Jahren in seinem Blog veröffentlicht.

Nun aber zurück zum eigentlichen Thema, das Erzeugen der oben gezeigten Grafik in den Reporting Services:

Mit dem Assistenten erstellen wir einen neuen Bericht auf den Adventure Works Cube aus der Adventure Works DW Datenbank. Nach dem Umschalten des Designmodes kommt für das Dataset folgender Quellcode zum Vorschein:

SELECT

NON EMPTY { [Measures].[Sales Amount] } ON COLUMNS,

NON EMPTY { ([Date].[Calendar].[Calendar Quarter].ALLMEMBERS) } ON ROWS

FROM [Adventure Works]

Um später die Lesbarkeit des Codes zu erhöhen, erstellen wir uns als erstes ein Set, dass alle Quartale enthält, die wir auch der Achse anzeigen wollen.

WITH

SET

myMonate AS ([Date].[Calendar].[Calendar Quarter].ALLMEMBERS)

Nun müssen wir für jede Zeile den Wert ermitteln, der für das jeweilige Quartal auf der Trendlinie liegt. Dazu nutzen wir die MDX-Funktion: LinRegPoint.

LinRegPoint(Slice_Expression_x, Set_Expression, Numeric_Expression_y [ ,Numeric_Expression_x ] )

Slice_Expression_x: Hier wird ein numerischer Ausdruck erwartet, der als x-Wert genutzt werden soll. Da die Quartale nicht numerisch sind, können wir diese hier nicht direkt benutzen. Wir können jedoch die RANK-Funktion nutzen, um die Position des jeweiligen Quartales auf der X-Achse zu ermitteln. Diesen merken wir uns in einem eigenen Member:

MEMBER

Measures.myX AS Rank([Date].[Calendar].CurrentMember, [Date].[Calendar].CURRENTMEMBER.LEVEL.MEMBERS)

Set_Expression: An dieser Stelle wird definiert, über welches Set der Trend-Wert berechnet werden soll. Hier könnte z.B. die letzten 10 Perioden gewählt werden, oder ein Set, das von Berichtsparametern abhängig ist, genutzt werden. In unserem Fall wollen wir einfach alle Quartale zur Berechnung heranziehen und nutzen deshalb das eben erstellte Set myMonate.

Numeric_Expression_y: Der gewünschte y-Wert ist einleuchtend: [Measures].[Sales Amount], dafür machen wir das ganze ja schließlich.

Numeric_Expression_x: Hier wird die Formel erwartet, die genutzt werden kann, um die x-Werte der anderen Punkte “vorauszusagen”. Wir können hier einfach den gleichen Ausdruck benutzen, wie bei Slice_Expression_x: myX

Wenn wir das alles einsetzen und dem Ganzen dann noch einen Namen geben, erhalten wir folgenden Ausdruck:

MEMBER

Measures.[Sales Trend] AS LinRegPoint(Measures.myX, myMonate, [Measures].[Sales Amount], Measures.myX)

Unsere Quelle für das Berichts-Dataset sieht nun also folgendermaßen aus:

WITH

SET

myMonate AS ([Date].[Calendar].[Calendar Quarter].ALLMEMBERS)

MEMBER

Measures.myX AS Rank([Date].[Calendar].CurrentMember, [Date].[Calendar].CURRENTMEMBER.LEVEL.MEMBERS)

MEMBER

Measures.[Sales Trend] AS LinRegPoint(Measures.myX, myMonate, [Measures].[Sales Amount], Measures.myX)

SELECT

NON EMPTY { [Measures].[Sales Amount],Measures.[Sales Trend] } ON COLUMNS,

NON EMPTY {myMonate} ON ROWS

FROM [Adventure Works]

Und wenn wir das ganze als Grafik anzeigen, dann sieht das in etwa so aus:

Wenn das unseren Controller nicht glücklich macht

An dieser Stelle sollte noch angemerkt werden, dass die LinRegPoint-Funktion mit Rekursion arbeitet und damit, vor allem bei vielen Zeit-Werten, eine potentielle Performancebremse ist. Wer also beim Darstellen des Trends mit diesem Verfahren an die Grenzen stößt, der sollte dann doch mal Dundas ausprobieren, oder auf die nächste Version des SQL Servers (2008) hoffen.

Unsere Kunden fragen sich häufig, ob die Hardware, die für die Systemlösungen zur Verfügung stehen oder gekauft werden soll, für ihre Anforderungen ausreicht. Umgekehrt möchten wir, dass wir und der Kunde uns während der Entwicklung der Systemlösungen wohlfühlen und wir somit eine Sensibilisierung für dieses Thema anstreben.
Wir haben bei ixto eine Analysereihe gestartet, die Werte von Festplatten bzw. Festplattenverbünden mittels eines Werkzeuges ermittelt und diese optisch auswertet. Ziel dabei ist es festzustellen, ob Festplattenverbünde den Anforderungen an das spätere System gewachsen sind.
Es werden Daten gewonnen wie beispielsweise Datentransferrate bei verschiedenen Blockgrößen, fragmentierter Festplatte und in Bezug auf Lesen und Schreiben von Daten, und vieles mehr.
Die Analyse lehnt sich stark an unseren allgemeinen Leitfaden des Berichtbaus an und gibt daher auf optischem Wege eine schnelle und deutliche Hilfe für weitere Entscheidungen in der Hardwarestrategie. Die Vergleiche können den individuellen Wünschen angepasst werden, so dass Aussagen im Vergleich zu Zielwerten oder bereits vorhandenen Festplatten getroffen werden können.
Zusätzlich fördert die Auswertung der Ergebnisse das Vertrauen des Kunden in die eigene Hardware und einem erfolgreichen Projekt steht in dieser Hinsicht nichts mehr im Wege.

Im nächsten Teil geht es mit Beispielen und der konkreten technischen Umsetzung weiter.