Überblick

Wer das Management-Studio für den SQL Server 2005 verwendet, findet recht bald unter Zusammenfassung verschiedene Berichte, die für die tägliche Arbeit nützlich sein können.

Wie bereits im dem Artikel Woher kommt SQL Trace 1? aufgeführt, werden hier einige recht interessante Operationen durchgeführt.
Bestimmt ist der ein oder andere neugierig geworden, was da so alles im Hintergrund passiert und ob es nicht evtl. auch für eigene Reports zu verwenden wäre. Glücklicherweise gibt uns Paul Mest (Program Manager on SQL Server Relational Engine Manageability Team at Microsoft) im SQL Server Relational Engine Manageability Team Blog einen schönen Einblick. Hier kann man sich auch sämtliche Sourcen für die Reports herunterladen.

Leider sind diese noch nicht sofort lauffähig, da bei einigen Zeilen (declare ...) ein Semikolon am Ende fehlt und bei Kommentaren -- nicht erkannt wird, sondern diese mit /* */ eingeschlossen werden müssen.

Eigene Reports

Aber die Lektüre dieser Reports ist durchaus lohnenswert. So zeigt z. B. der Report Disk Usage.rdl wie der Umgang mit Trace-Files durchgeführt wird. Die Funktion ::fn_trace_gettable liefert die Traces als Tabelle zurück und sie können einfach weiter verarbeitet werden.

Was mir immer noch fehlt, sind Reports für den schnellen Überblick. Im beiliegenden Projekt Verwaltungstools.zip habe ich mal drei definiert, welche die folgenden Fragen beantworten:

• Was sind die zehn größten Datenbanken?
• Wieviel Platz belegen sie?
• Wieviel ist in den Datenbanken noch frei?
• Wieviel Platz habe ich auf den Platten des Servers?

Dies alles beantwortet der Report "Top Ten".

Weiterhin habe ich immer damit zu kämpfen, um mir einen Überblick über die Jobs auf einem Server zu verschaffen. Wir haben durchaus Server, auf denen 20 oder mehr Jobs regelmäßig laufen und hier stellen sich z. B. folgende Fragen:

• Welche Jobs laufen an bestimmten Wochentagen?
• Wann ist in der Nacht mal Zeit den Server (z. B. für Updates) zu booten?
• Wie sind Konsistenzprüfungen und Sicherungen eingeplant?

Hierfür gibt es zwei Reports, einmal für Tagesjobs und einmal auf Monatsbasis.

Für die Jobs habe ich zuerst je eine View auf dem Server angelegt und verwende hierzu z. B. eine Datenbank mit dem Namen AdminTools.

Multi-Server Umgebungen

Der Einfachheit halber, habe ich nur eine Datenquelle verwendet und diese als freigegebene Datenquelle auf dem Reporting-Server hinterlegt. Wenn man dort die Verbindungszeichenfolge ändert, kann man schnell auf andere Server zugreifen. Alternativ müßte man für jeden Server einen eigenen Satz von Reports deployen, was gerade bei Änderungen wieder aufwändig wäre.

Fazit

Die Reporting-Services bieten auch direkt für Administratoren einige nette Features, die man sich durchaus mal näher anschauen sollte. Eigene Reports lassen sich dort schnell realisieren und für mehrere Server verwenden.

Wer weitere interessante Reports hat, oder Wünsche, die vielleicht jemand anders realisieren könnte, sollte sich am besten einen Kommentar hier hinterlassen.