Bei ixto sind wir meistens sehr mit der Produktqualität von Microsoft zufrieden und auch SQL Server 2008 macht auf den ersten Blick einen ausgezeichneten Eindruck. Wir, das Team der Berichtsdesigner, sahen uns allerdings schnell an unsere Toleranzgrenzen gebracht als wir den neuen Abfrage-Designer für MDX im Berichtsdesigner erleben durften.

Nun, nicht jeder von uns schreibt sein MDX selbst, sondern benutzt den sehr komfortablen grafischen Editor. Performance spielt bei vielen Abfragen und natürlich für den Benutzer eine Rolle, also tunen wir gelegentlich die generierten Abfragen manuell, d.h. wir greifen direkt in die MDX-Syntax ein und verändern diese. Manchmal ist eine Modifizierung grundsätzlich notwendig, wenn man beispielsweise in einer Hierarchie nur bis zu einer bestimmten Ebene Daten abfragen möchte.

Wir haben folgende Problemstellen mit dem MDX Abfrage-Designer identifiziert und Microsoft dazu befragt:
 
Verlorene Formatierungen

Modifizierte und formatierte MDX-Abfragen verlieren jegliche Formatierungen, wie z.B. Zeilenumbrüche und Einrückungen, nachdem man den Bericht komplett geschlossen und dann bis zur Abfrage wieder geöffnet hat. Jeder, der sich schon mal die Abfrage eines vom Visual Studio 2005 generierten Parameters angesehen hat, weiß, wie unlesbar dieser Code ist.

Die Zeilenumbrüche finden sich allerdings im RDL direkt wieder. Nur ist diese Tatsache wenig hilfreich, wenn die Zeilenumbrüche im Abfrage-Designer nicht angezeigt werden.
Der Bug scheint bisher keine Beachtung bei den Entwicklern gefunden zu haben.
 
Kein Syntax Highlighting

Schon schlimm genug, dass die Formatierung immer verloren geht, da wurde das Syntax Highlighting auch noch Opfer von Integrationsproblemen. Wie im Screenshot zu sehen, ist die Abfrage im neuen Editor so gut wie unlesbar.

Es heißt, dass es ein Visual Studio Integrationsproblem war, welches bis zum Release von SQL Server 2008 nicht behoben werden konnte. Es wird angestrebt, es in einer zukünftigen Version zu beheben.

Sonderzeichen

In der englischen Version ist das Problem mit den Formatierungen noch gravierender. Hier entstehen Sonderzeichen, die die Zeilenumbrüche sein sollen, aber nicht entsprechend angezeigt werden.

Auch dieser Bug scheint bei den Entwicklern noch nicht wirklich angekommen zu sein.

Für die Punkte 1 bis 3 gibt es den Workaround, die MDX-Abfrage in eine Abfrage im Management Studio zu kopieren. Hier hat man die Formatierung und das Syntaxhighlighting wieder. Durch zurückkopieren erhält man jetzt auch im Designer die Formatierung zurück.
Leider kann das Management Studio nicht mit den Parametern in der Abfrage umgehen, daher würden wir das MDX Studio von Mosha Pasumansky empfehlen, denn mit dieser Anwendung gewinnen Sie nicht nur das Syntax Highlighting zurück und haben eine Autoformatierungsfunktion, sondern es ist auch möglich Parameter via XML-Tags in die Abfrage einzubinden.
Das MDX Studio ist auf der Seite http://www.mdxstudio.com/ zu finden.
Um sich das Schreiben der einzelnen XML-Tags für die Parameter, es können ja doch manchmal ganz schön viele sein, zu ersparen, kann die Abfrage mit dem SQL-Profiler “mitgeschnitten” und dann direkt in das MDX Studio kopiert werden.

Automatisch überschriebene Parameterdatasets

Die Probleme, die bis jetzt beschrieben wurden, hatten nur etwas mit der Benutzerfreundlichkeit zu tun, das jetzt beschriebene Verhalten kann aber zu richtigen Fehlern führen, wie es unbemerkt bleibt.

Wie auch bei SSRS 2005 werden Datasets für Parameter automatisch generiert, wenn sie in der Hauptabfrage erzeugt werden. Das Problem entsteht, wenn man die Abfrage für die Parameter anpasst, da man vielleicht einige Elemente nicht benötigt, und danach noch mal die Hauptabfrage ändert, wird wieder das “Default” Dataset für den Parameter erstellt und die eigenen Anpassungen gehen verloren.

Was möglicherweise gut gemeint ist, und das manuelle generieren von Parameterdatasets abnehmen soll, führt unter diesen Umständen zu mehrfachem Wiederholen derselben Arbeit oder sogar zu Fehlern, wenn die automatische Änderung unbemerkt bleibt.

Dieses Problem haben die Entwickler wohlwollend aufgenommen und scheint zur Diskussion zu stehen.

Ein Workaround das automatische Überschreiben der Parameterdatasets zu unterbinden ist, die Bindungen an die Dimensionen zu entfernen. Als Standardwerte muss man Elemente in MDX-Syntax setzen, was natürlich die Funktionalität des Assistenten einschränkt und das Ändern der Standardwerte stark erschwert.

Mit den hier beschriebenen Workarounds ist es aber auch für MDX-Fans durchaus sinnvoll mit dem SSRS 08 zu arbeiten und die neuen Features, wie Tablix und erweiterte Gruppierbarkeit zu nutzen.

Eine Migration von Berichten mit Dundas Charts von Reporting Services (RS) 2005 nach 2008 funktioniert dank der neu integrierten Diagrammfunktionalitäten in RS 2008 relativ problemlos.

Einige Konvertierungen mit Diagrammen von Dundas laufen allerdings darauf hinaus, dass sie in RS 2008 als fehlerhaft gemeldet werden und auch nicht ersichtlich ist, woran es liegt. Visual Studio bietet an, den Code zu sichten, aber wer möchte gerne seitenlanges XML durchforsten auf der Suche nach möglichen Fehlern?

Empirisch gelangten wir zu dem Schluss, dass in jedem letztlich fehlerhaften Bericht die Dundas Charts in einer Tabelle eingebettet waren. Nun ist die Lösung ganz einfach: in RS 2005 die Charts aus der Tabelle herausschneiden und im Bericht außerhalb der Tabelle einfügen. Der Bericht muss gespeichert und als nächstes in Visual Studio 2008 erneut geöffnet werden. Dieses Mal war die Konvertierung erfolgreich! Der Entwickler braucht nur noch die Charts wieder in die Tabelle an die ursprüngliche Stelle einfügen und umgeht damit einen zeitaufwendigen Neubau.

Vor einer Konvertierung mit Dundas Charts in einer Tabelle die Diagramme also aus der Tabelle herausnehmen und alles wird gut.

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.

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.