Wie ich am schnellsten einen SQL-Server ruiniere.

Würde mich jemand fragen (was natürlich niemand tut, sondern selbst ausprobiert), wie man am schnellsten und effektivsten einen SQL-Server so richtig in Schwierigkeiten reinreiten möchte, dann würde ich das so machen:

1. Eine völlig blöde Konfiguration voraussetzen, beispielsweise alles auf einer Festplatte und alles auf einer Partition: Betriebssystem, SQL-Server-Software, Datenbankdateien, Protokolldateien. Das macht so richtig Spaß, denn wenn ein Teil dieser vier Komponenten heftig zu tun hat, dann hält es einfach alle anderen mit auf. Und wenn die Platte stirbt, wechselt dann auch einfach gleich alles das Ufer des Rubikon.
2. Server beschäftigen und zwar in ganz großem Stil. Das macht man auf Datenbankservern gern mit „Optimierungsprogrammen“ wie Defragmentieren oder Virenscannern und lässt die dann auf Datenbank- und Protokolldateien los.
   1. Der Virenscanner wird sich redlich bemühen, gigantisch Arbeitsspeicher fressen, die Festplatte polieren und in der Regel nie etwas finden können. Denn selten liegen die Muster, nach denen ein Virenscanner sucht, genau so in einer Datenbankdatei – eine Datenbankdatei ist immer fragmentiert, hat ein eigenes Speicherformat und ist gesperrt. Besonders clevere Virenscanner setzen sich über die Sperrung hinweg und nudeln den Server auf diese Weise sehr effizient in die 386er-Klasse herunter.
   2. Der Defragmentierer wird loslegen und Teile zusammenpuzzeln wollen, die allerdings ständig in Bewegung sind. Datenbankdateien wird jeder vernünftige Defragmentierer nicht anfassen wollen, wenn sie gesperrt sind, aber an den Protokolldateien kann er sich austoben. Dabei sind Protokolldateien noch viel stärker im Fluss, denn in der Regel werden Protokolldateien von einer Datensicherung bis zum Sicherungspunkt eh wieder gelöscht oder es existiert auf einem SQL-Server, der nicht datengesichert wird (brutaler Fehler) eine Umlaufprotokollierung (noch brutalerer Fehler), d.h. ältere Protokolldateien werden gelöscht, wenn neue angelegt werden. Und wenn dann noch Mist passiert und Protokolldateien beschädigt werden, verbaut man sich damit den allerletzten Notnagel, denn Protokolldateien sind eigentlich dazu da, Operationen auf den Datenbankdateien zu protokollieren. Ohne Protokolldatei ist eine defekte Datenbankdatei nicht mehr wiederherstellbar.
   3. Datensicherungen tagsüber laufen lassen, richtig schön bei Spitzenzeiten. Dann hat auch gleich jeder etwas davon.
3. SQL-Server-Dienste abschießen („Mann, der SQL-Server hängt aber!“) oder auch einfach den Server hart aus- und einschalten („Mann, ist die Kiste lahm“). Gern mehrfach. Ja, das Herunterfahren eines Servers, auf dem Datenbankdienste laufen, kann manchmal sehr lange dauern. Das liegt vor allem daran, dass eine gut konfigurierte Datenbank Inhalte nicht sofort in ihre Datenbankdateien kratzt, sondern im Arbeitsspeicher vorhält. Will ein Dienst beendet oder ein Server neu gestartet werden, müssen diese Inhalte möglichst logisch auf in die Datenbankdateien und das dauert. Wer hier abschießt, der wird büßen. Im günstigsten Fall rattert beim nächsten Start der SQL-Server eine ganze Weile, weil die Datenbankdateien „dirty“ geschlossen wurden, im ungünstigsten Fall erleidet man Datenverlust, weil nicht fertiggeschrieben werden konnte.
4. Keine Datensicherung haben. Mir kann niemand erzählen, ihm wären die Daten in einer Datenbank nicht so wichtig genug, als dass man sie sichern müsste. Wären sie unnötig, hätte man keine Datenbank, fertig. Und hat man eine Datenbank, hat man sie zu sichern. Dabei genügt es nicht, einfach die Dateien zu sichern, denn ein Datenbank-Server läuft in der Regel ständig und hat, wie bereits geschrieben, gerade die Datenbankdateien exklusiv geöffnet, lässt diese also auch nicht einfach „flach“ sichern. Es braucht also entweder eine (ziemlich peinliche) Notlösung, während der Sicherung den Datenbankdienst vorübergehend zu stoppen oder es braucht eine intelligentere Datensicherungslösung, die die Datenbank auf Transaktionsebene sichert. In der Regel nicht trivial, allerdings eine Lebensversicherung. Und selbstverständlich sichert man nicht gerade dann, wenn am meisten los ist und die Datenbank auch schon ohne Datensicherung unter Druck steht, sondern verschiebt das auf eher ruhige Tageszeiten. Und ja, man testet auch gelegentlich mal, ob die Datensicherung überhaupt sichert.