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.

Microfiches als moderne Archivierungsmethoden.

Der Sysadm.in-Oliver aus meiner Oliver-Phalanx schreibt in seinem Blog, dass er beim aktuellen Datenklau der Landesbank Berlin in erster Linie bemängele, dass da Microfiches zum Archivieren genutzt werden. Da er in seinem Blog keine Kommentare zulässt (eine Krankheit, wie ich finde), hier mal eine Antwort von mir:

Microfiches mögen zwar altmodisch sein, sind aber in Sachen Haltbar- und Lesbarkeit jedem eletronischen Datenträgersystem, das derzeit existiert, höchstwahrscheinlich mehrfach überlegen. Bei Microfiches setzt man als Mindesthaltbarkeit (bei korrekter Lagerung) mindestens 400 Jahre an und vor allem ist das Auslesen von Microfiches denkbar einfach – man braucht einfach nur ein optisches Lesegerät. Will man einen bewußten Medienbruch in einem Archivierungskonzept haben, sind Microfiches immer noch unschlagbar in der Langzeitarchivierung.

Ein Traum von Datensicherung.

So hat ein Auftragsprotokoll einer gut konfigurierten und gepflegten Datensicherung auszusehen:

Und so geht das nicht nur drei Wochen, sondern praktisch ständig – nicht eine verpasste Datensicherung, lückenlos über mehrere Wochen hinweg. Das hat zwar die Folge, dass ich immer wieder für den Kunden zu Rückfragen zur Verfügung stehen muss, allerdings ist mir sowas lieber, als wenn wir im Ernstfall mit einer löchrigen Datensicherung einen Server wieder aufsetzen müssen und Datenverlust in Kauf nehmen müssen. Denn bei einer fehlenden oder fehlerhaften Datensicherung steht man auch als Dienstleister, der die Datensicherung mal eingerichtet und erklärt hat, zumindest halb im Licht.

Eine Datensicherung ist einer der Dinge, die man entweder vollständig macht oder im Zweifelsfall lieber ganz bleiben lässt, mit allen damit verbundenen Risiken. Denn es gibt ein paar Dinge zu beachten:

  • Die richtige Sicherungslösung ist das A und O, vor allem aus preislicher Sicht. Muss man das gesamte System sichern oder reicht es, nur ein Verzeichnis oder Laufwerk mit statischen Dateien zu sichern? Bei letzterem genügt in vielen Fällen schon ein einfaches Script zum Kopieren von Dateien auf ein anderes Medium und sei es ein USB-Stick am Rechner oder das Packen in eine Zip-Datei, das Verschlüsseln der Datei und ein Upload auf einen FTP-Server. Ist aber die Sicherung eines kompletten Systems oder das Sichern von Datenbanken mit in der Anforderung, kommt man um eine Sicherungssoftware, die das unterstützt, nicht herum.
  • Was für ein Medium? Das Kopieren auf eine andere Festplatte ist nicht unbedingt das Schlechteste, allerdings bringt es nicht wirklich viel, wenn diese Festplatte im gleichen Computer steckt und die ganze Kiste abraucht. Das Problem hätte möglicherweise auch ein angesteckter USB-Stick. Das Brennen auf eine CD ist zwar in dieser Beziehung hübscher, dafür aber ein CD-Rohling nicht wirklich für Langzeitsicherung gedacht und relativ empfindlich. Bänder wiederum sind handlich, auch für Laien bedienbar und bringen in modernen Systemen auch eine genügend große Speicherkapazität mit, dafür sind Bandlaufwerke – vor allem die jeweils neuesten Systeme und Modelle – nicht gerade die günstigsten.
  • Die Datensicherung muss korrekt konfiguriert sein und das ist schon bei nicht mehr ganz so einfachen Setups ein gar nicht so einfaches Spiel. Zum Sichern von Datenbanken und temporär gesperrten Dateien braucht es Lösungen und die heißt oft genug nicht, einfach mal einen Dump von einer Datenbank zu produzieren, denn die Kunst ist auch, aus gesicherten Datenbankelementen im Ernstfall wieder eine vollständige Datenbank zu bauen. Wer jemals mit einer eiernden Exchange-Datenbank zu kämpfen hatte, versteht das sofort.
  • Kurzzeit- und Langzeitsicherungen beachten! Okay, gut, wenn man einen Stand von letzten Donnerstag zurücksichern kann. Aber wäre es manchmal nicht notwendig, eine Datei zurückzusichern, die mehrere Monate alt ist, ohne dass man gleich hunderte von Sicherungsbänder einlagern muss? Das Generationenprinzip ist hier die Antwort, wenn auch nicht sofort für jeden zu verstehen. Fast schon pure Magie, wenn man mit 20 Bändern ein ganzes Jahr sichern kann.
  • Wer legt das nächste Band ein? Immer ein sehr beliebtes Spiel, denn was nützt die teuerste Anschaffung und die beste Konfiguration, wenn die Datensicherung andauernd fehlschlägt, weil keiner das Band einlegt? Feste Sicherungspläne mit zu unterschreibenden Einlegelisten und ein Plan für Urlaubsvertretungen sorgt hier für mehr Zuverlässigkeit.
  • Protokolle schaut man sich gelegentlich auch einmal an und heftet sie nicht nur ab. Laufwerke können kaputtgehen, Sicherungen können abbrechen, Bänder können sich abnutzen und Lese-/Schreibfehler erzeugen.