In meinem Entwickler-Alltag spielt der Microsoft SQL Server oft eine sehr wichtige Rolle und das schon seit der katastrophal fehlerträchtigen Version 6.0. Zwar habe ich auch mit anderen Datenbanken wie beispielsweise DB2, Oracle oder MySQL zu tun, aber der MS SQL Server hat spätestens seit der stabilen 2000er-Version eine Sonderstellung und ist ein Werkzeug, dem ich einfach überall begegne.
Das hat meiner Meinung nach zwei Gründe:
- MS SQL Server ist kinderleicht ans Rennen zu kriegen
- er wird mehr und mehr zum Komplett-Paket für alle Business Intelligence Belange, und ist (zumindest wenn man einen Großteil der gelieferten Funktionalität auch wirklich einsetzt) einfach kostenmäßig extrem attraktiv.
Der erste Punkt, die problemlose Einrichtung, ist jedoch nicht ganz ungefährlich: Die Einstiegsanforderungen an einen Datenbank-Administrator (kurz: DBA) sind sehr gering, ich kenne sogar Firmen, die auf die dedizierte Rolle DBA weitestgehend verzichten. Stösst man aber irgendwann an die Grenze, an der die Standardkonfiguration ausgereizt ist, wird es ohne DBA schnell kritisch.
Es ist also Vorsicht geboten. Ich möchte darum in diesem Artikel ein paar der Fallstricke aus meinem Projektalltag knapp umreissen.
Es fängt oft mit Trivialitäten an. Die erste Klippe ist der vorhandene Arbeitsspeicher. Solange dieser groß genug ausfällt, ist es möglich, auch mit größeren Tabellen halbwegs performant auszukommen, und das selbst wenn kein einziger Index definiert wurde.
Geht die Performance dann bei steigendem Datenvolumen irgendwann in den Keller, ist das eine Klippe, die man meist mit Programmierern noch lösen kann. Indizes kriegen Entwickler selbstverständlich noch gut in den Griff. Die wenigsten Entwickler kennen jedoch die breite Werkzeugpalette innerhalb MS SQL Servers, die sich diesem Problem analytisch und zum Teil sogar automatisch annimmt.
Sind die Index-Probleme einmal gelöst, kommt bald eine neuer Eisberg auf uns zu. Auf 32Bit-Systemen ist diese Grenze dann erreicht, wenn die erste Tabelle mehr als 2GB Daten umfasst. Ab diesem Punkt spätestens muckt SQL Server auf: Wir haben den Adress-Raum eines 32-Bit-Systems verlassen, einfachste Operationen auf der Tabelle werden langwierig und spannend wie eine Herz-OP, und nichts ist mehr eitel Sonnenschein. Ich sage nicht, dass diese Klippen nicht zu umschiffen sind, aber ab diesem Punkt werden echte DBA-Kenntnisse unabdingbar. Programmierer kriegen diese Problematik in der Regel nicht mehr in den Griff. Es ist einfach kein Software-Problem mehr; ein Index als Zugriffspfad hat noch etwas Entwickler-Nahes, aber die schnöde Probleme Arbeitsspeicher und Plattenplatz haben meiner Meinung nach nichts in Programmierer-Hand zu suchen.
Fazit: Microsoft SQL Server ist kinderleicht einzuführen, das stimmt. Aber man sollte von Anfang an eine DBA Rolle einführen, auch wenn sie zunächst unnötig erscheint.
Ein guter DBA kennzeichnet sich meiner Meinung nach dadurch, dass man seine Arbeit nicht bemerkt. Fehlt er aber, wird das im Falle von MS SQL Server mit gefährlicher Verzögerung offensichtlich. Oft sind eingeführte Systeme dann schon unternehmenskritisch geworden… es ist also Vorsicht geboten!
Es gibt viele Schrauben im Hintergrund von MS SQL Server, aber wenn man sich regelmässig und gewissenhaft mit ihnen beschäftigt, erhält man auch ein auf Dauer stabiles und performantes System.
Links zum Artikel:
