In früheren Versionen der Software konnte man die Sortierreihenfolge nur auf der Serverebene festlegen – sie galt damit für alle Datenbanken und alle Tabellen einheitlich, die auf dem Server abgelegt waren. Zusätzlich entschied diese Einstellung darüber, welche Datenbanken man überhaupt auf dem Server betreiben konnte: Hatte man eine Datenbank auf einem Server mit Sortierung A eingerichtet, konnte es passieren, dass man diese auf einem anderen Server mit Sortierung B nicht einsetzen konnte.

In aktuellen Versionen unterstützt SQL Server unterschiedliche Sortierreihenfolgen auf verschiedenen Ebenen. Die Einstellung auf Serverebene (die man direkt bei der Installation festlegt!) gibt für die Systemdatenbanken (insbesondere “master” und “msdb”) sowie als Vorgabe für alle neuen Datenbanken. Legt man Datenbanken an, kann man dort eine eigene (auch abweichende) Sortierreihenfolge definieren. Und schließlich darf man mittlerweile auch für einzelne Tabellenspalten die Sortierreihenfolge auswählen.

Auswahl der Sortierreihenfolge für eine neue Datenbank. Diese Festlegung kann man später nicht ändern!

Im Installationsumfang von SQL Server finden sich hunderte Sortierreihenfolgen für verschiedene Sprachen. Sie unterscheiden sich nach dem Grundprinzip, ob sie Zeichen binär (nach ihrem Zeichencode) oder lexikalisch (also in alphabetisch korrekter Folge) interpretieren, daneben aber vor allem in der Unterscheidung von Groß- und Kleinschreibung, von Akzenten oder weiteren sprachlichen Eigenschaften. Eine Idee davon vermittelt das folgende Dialogfeld, das die Auswahl ermöglicht:

Sortieroptionen für eine einzelne Spalte

Ein Beispiel soll die Auswirkungen verschiedener Sortierreihenfolge auf die Daten verdeutlichen, die SQL Server auf eine Abfrage zurückgibt. Betrachten wir eine simple Tabelle mit zwei Textspalten. Für die erste Spalte “WertCS” gibt eine Sortierung mit Unterscheidung nach Groß-/Kleinschreibung (“Case Sensitive”) sowie nach Akzent (“Accent Sensitive”). In der zweiten Spalte “WertCI” gilt keine Unterscheidung dieser beiden Kriterien. (Anmerkung: Dies weicht von der Standardeinstellung ab, die SQL Server von sich aus vorschlägt: Dort gilt keine Unterscheidung nach Groß-/Kleinschreibung (“Case Insensitive”), Akzente werden aber unterschieden (“Accent Sensitive”).

In beide Spalten tragen wir nun Werte ein. Damit man die Auswirkungen sieht, stehen in jeder Spalte Wertpaare: Derselbe Wert einmal mit und ohne Großbuchstaben sowie derselbe Eintrag mit und ohne Akzent.

Daten in der Testtabelle

Nun folgen ein paar Abfragen. Die Komplettabfrage gibt natürlich die ganze Tabelle aus:

SELECT * FROM WerteCSCI

Abfrage der ganzen Tabelle

Die zweite Abfrage sucht einen Wert und gibt diesen nur mit Kleinbuchstaben an. Das Ergebnis der ersten Spalte (“Case Sensitive”):

SELECT WertCS FROM WerteCSCI WHERE WertCS = 'hurz'

Abfrage der Case-Sensitive-Spalte

Und das Ergebnis für die zweite Spalte (“Case Insensitive”):

SELECT WertCI FROM WerteCSCI WHERE WertCI = 'hurz'

Abfrage der Case-Insensitive-Spalte

Der Unterschied ist deutlich sichtbar. Bei einer Sortierreihenfolge ohne Unterscheidung nach Groß- und Kleinschreibung (dies ist der Standard, wenn man die Definition nicht ausdrücklich ändert) gibt SQL Server die Daten unabhängig von der Schreibung zurück. Das ist in den meisten Situationen das erwartete Verhalten.

Dasselbe Phänomen zeigt sich auch bei den Akzenten. Hier allerdings ist die Installationsvorgabe anders: Standardmäßig unterscheidet SQL Server nach der Akzentuierung. In diesem Fall entspricht also das erste Beispiel dem “normalen” Verhalten.

SELECT WertCS FROM WerteCSCI WHERE WertCS = 'baba'

Abfrage der Accent-Sensitive-Spalte

Und das Ergebnis für die zweite Spalte (“Case Insensitive”):

SELECT WertCI FROM WerteCSCI WHERE WertCI = 'baba'

Abfrage der Accent-Insensitive-Spalte

Verwandte Beiträge:

1. Sharepoint-Neuinstallation: Suchdatenbank neu erzeugen
   Bei der Neuinstallation eines Sharepoint-Servers kann es erforderlich sein, eine...
2. Exchange-Server verweigert Deinstallation
   Beim Versuch, einen Exchange-Server (ab 2000) zu deinstallieren, kann es...
3. Hyper-V mit Windows Server Core 2008
   Am Donnerstag, 26. Juni 2008, hat Microsoft Hyper-V als RTM-Version...

Aber Vorsicht: Anders als die meisten Mitbewerber erlaubt Hyper-V auch weiterhin kein “Overcommit” des Arbeitsspeichers. Mehr als physisch im Host steckt, lässt sich nicht an die VMs verteilen, auch nicht mit Dynamic Memory. Das hat auch seinen guten Grund, denn bei allen Mitbewerbern leidet die Performance aller VMs dramatisch, wenn die virtuellen Maschinen tatsächlich mehr RAM brauchen als vorhanden ist.

Bei leistungshungrigen Server-Applikationen sollte man zudem abwägen, ob man Dynamic Memory wirklich nutzen möchte. Nicht jede Anwendung ist in jeder Situation dazu geeignet. In den kommenden Wochen und Monaten werden wir sicher Erfahrungen und Best Practice dazu von den Herstellern finden. Zwei Beispiele gibt es schon jetzt: Exchange Server 2010 und SQL Server.

Während Microsoft für Exchange Server 2010 komplett vom Einsatz von Dynamic Memory (und allen “Overcommit”-Funktionen anderer Virtualisierer) abrät, ist die Lage beim SQL Server differenzierter. Hier zwei einschlägige Links:

[Exchange 2010 System Requirements: Exchange 2010 SP1 Help]
http://technet.microsoft.com/en-us/library/aa996719.aspx?wt.svl=overview

• dort ganz unten schauen: Exchange Server Memory Requirements and Recommendations

[SQL Server Hyper-V Dynamic Memory - SQLOS Team Blog - Site Home - MSDN Blogs]
http://blogs.msdn.com/b/sqlosteam/archive/tags/hyper_2d00_v+dynamic+memory/

Verwandte Beiträge:

1. Hyper-V Dynamic Memory: Reservierung für den Parent
   Toni Pohl vom österreichischen TechNet-Team weist auf einen Umstand hin,...
2. Hyper-V, das SP1 und Dynamic Memory
   Das Service Pack 1 für Windows Server 2008 R2 ist...
3. Whitepaper: Dynamic Memory in Hyper-V 2.0 SP1
   Microsoft hat vor einigen Wochen ein Whitepaper veröffentlicht, das das...

Die Datenablage ist eine der wichtigsten Funktionen eines Datenbankservers: Nicht nur sollen die Daten zuverlässig auf der Festplatte landen, sondern das soll auch noch möglichst schnell geschehen. Und schließlich sollen die Daten meist nicht nur auf der Platte stehen, sondern in regelmäßigen Abständen zur Datensicherung auch auf ein Band oder ein anderes externes Medium kopiert werden.

Microsofts SQL Server setzt hierfür einige Mechanismen ein, die sich schon seit mehr als einem Dutzend Jahren nicht prinzipiell verändert haben. Trotzdem sind diese Grundlagen den meisten Admins weitgehend unbekannt. Dieser Artikel gibt ein wenig Überblick.

Das Protokoll-Prinzip

Mit vielen anderen Datenbanksystemen teilt sich SQL Server das Prinzip des “Write-ahead logging”, um die Konsistenz seiner Transaktionen auch über mögliche Systemausfälle hinweg zu gewährleisten. Hinter diesem hochtrabenden Namen verbirgt sich eine recht einfache Idee: SQL Server bestätigt die Annahme von Daten von einem Client erst dann, wenn er sie sicher auf die Festplatte geschrieben hat. Dabei bedient er sich allerdings noch eines – ebenfalls weit verbreiteten – Tricks: Der Server schreibt die Daten nicht sofort in die Datenbank-Datei. Solche Dateien können nämlich sehr groß werden, und sie sind intern in einer Weise organisiert, die insbesondere effiziente Lese- und Suchvorgänge unterstützt. Im Effekt muss der Datenbankserver daher die Daten innerhalb einer möglicherweise riesigen Datei an einer ganz bestimmten Stelle speichern, die er zunächst identifizieren muss, und gleich darauf muss er an eine ganz andere Stelle schreiben, um das nächste Datenpaket loszuwerden. Und das alles nur, um Daten zu speichern, die im nächsten Moment vielleicht schon wieder geändert sind.

Aus diesem Grund versuchen die meisten Datenbanksysteme, den Schreibzugriff auf die Datenbank-Datei so selten wie möglich auszuführen. Sie fassen mehrere einzelne Schreibvorgänge zu einem größeren zusammen, wobei sich oft auch der Effekt ergibt, dass Daten, die bereits von anderen Daten ersetzt sind, nur einmal und nicht mehrfach geschrieben werden müssen. Dieses Prinzip nennt man auch “Lazy Writer”.

Damit die Daten nun also einerseits sofort nicht-flüchtig auf der Platte stehen, andererseits aber der Zugriff auf die komplexe Datenbankdatei so selten wie möglich erfolgt, haben Datenbanken dieser Art eine zweite Datei, nämlich die Log-Datei (auch: Transaktionsprotokoll-Datei). Dort protokolliert der Server jede einzelne Transaktion ohne weitere Rücksicht auf spätere Lesevorgänge. Diese Log-Datei lässt sich also einfach sequenziell beschreiben: Alle Transaktionen protokolliert das System vollständig, indem es sie – vereinfacht gesagt – am Ende der Log-Datei anfügt.

Tatsächlich sind es also zwei Dateien bzw. zwei Sätze von Dateien, die eine derartige Datenbank zur Speicherung benötigt. Dabei wird deutlich, dass die Log-Datei ganz entscheidend über die Geschwindigkeit der Transaktionsverarbeitung (also aller Änderungen an der Datenbank) entscheidet, denn jede Änderung wird erst in der Datei protokolliert und dann bestätigt. Hochdynamische Datenbanken brauchen daher für die Log-Dateien ein Plattensystem, das eine hohe Verarbeitungsgeschwindigkeit für sequenzielle Schreibvorgänge ermöglicht. Es ist durchaus keine Seltenheit, dass man dafür Stripe-Sets aus kleinen, schnellen Platten einsetzt (gern gespiegelt – also z.B. RAID 10). Das ist allerdings längst nicht für jede Datenbank nötig, sondern nur für solche, die richtig hohe Schreibleistung brauchen. Die meisten Datenbanken für “übliche” Anwendungen (auch ERP-Systeme im Mittelstand) werden mit weniger I/O-Leistung auskommen und daher auf “normalen” Plattensystemen zufriedenstellend arbeiten.

Wenn man das Logging richtig behandelt (mehr dazu siehe unten), werden die Log-Dateien für die meisten Datenbanken im Vergleich zur vollständigen Datenbankgröße eher überschaubar sein. Es kann aber durchaus vorkommen, dass die Protokolldateien plötzlich stark anwachsen, und zwar dann, wenn es viele oder sehr große Transaktionen in kurzer Zeit gibt. Eine typische Situation dieser Art sind umfangreiche Import-Vorgänge in die Datenbank – jeder importierte Datensatz wird natürlich einzeln protokolliert.

Auf jeden Fall aber sind die Transaktionsprotokolle produktionskritisch: Ohne Protokoll keine Veränderung in der Datenbank. Als Hintergrund halte man sich den Sinn des Transaktionsprotokolls vor Augen: Es ist der ausschlaggebende Mechanismus, der gewährleistet, dass man sich auf die Datenbank verlassen kann. In einer komplexen Transaktion, die aus vielen einzelnen, aber zusammenhängenden Änderungen besteht, muss die Applikation gewährleisten, dass der Vorgang entweder vollständig oder aber gar nicht stattfindet. Man stelle sich vor, bei einer Bank-Überweisung, die aus den beiden Schritten “Abbuchen von 100.000 Euro von Konto X und Gutschreiben derselben Summe auf Konto Y” besteht, findet nur der erste Schritt statt, der zweite aber nicht. Die Bank freut sich – aber gleich zwei Kunden haben Grund zur Klage. Das Datenbanksystem muss also sicherstellen, dass eine unterbrochene Transaktion vollständig widerrufen wird, damit sie sauber neu ausgeführt werden kann. Umgekehrt muss eine Transaktion, die das System bestätigt hat, auch zuverlässig in der Datenbank vermerkt sein.

Daher kann bei einem transaktionsgeschützten System kein Vorgang ohne Protokoll stattfinden. Steht das Protokoll nicht zur Verfügung, ist der Server also gezwungen, die ganze Datenbank offline zu nehmen. Der korrekte Umgang mit den Log-Dateien ist also eine Kernaufgabe des Datenbank-Operating.

Wie SQL Server Änderungen verarbeitet

Hier noch einmal eine kurze (und vereinfachte) Zusammenfassung, wie SQL Server Änderungen an einer Datenbank verarbeitet.

1. Ein Client fordert eine bestimmte Änderung von Daten an.
2. SQL Server prüft, ob sich die betroffenen Daten (genauer: Die Speicherbereiche der Datenbank, auf denen sich die Daten befinden – auch als “Datenbank-Seiten” bezeichnet) bereits im Arbeitsspeicher befinden. Falls nicht, lädt er die Seiten ins RAM.
3. SQL Server protokolliert die Änderungen im Transaktionsprotokoll.
4. SQL ändert die Datenbank-Seiten im Arbeitsspeicher.
5. SQL Server gibt dem Client die Bestätigung über die Transaktion.
6. Beim nächsten sog. Checkpoint-Vorgang schreibt SQL Server die geänderten Datenbank-Seiten aus dem Arbeitsspeicher in die Datenbankdatei auf der Festplatte. Den Checkpoint vermerkt das System im Transaktionsprotokoll: Alle Transaktionen vor dem Checkpoint sind in der Datenbank fixiert, die betreffenden Transaktionen sind im Protokoll also nicht mehr aktiv.

Was SQL Server nun als nächstes mit dem Transaktionsprotokoll tut, hängt davon ab, wie die Datenbank konfiguriert ist. Entscheidend ist dabei das “Recovery Model” (Wiederherstellungsmodell), das als Datenbankoption durch den Administrator konfigurierbar ist. Steht es auf “Vollständig” (Full), so lässt SQL Server alle inaktiven Transaktionen im Transaktionsprotokoll stehen und schreibt neue Transaktionen ans Ende der Protokolldatei. Erst wenn der Admin eine Protokollsicherung (Log Backup) ausführt, gibt SQL Server die “alten”, inaktiven Transaktionen frei, und das System kann den Platz innerhalb der Datei wieder nutzen. Der Vorteil: Auf diese Weise lassen sich die Transaktionsprotokolle auch zur Wiederherstellung nach einem Datenverlust einsetzen, denn sie enthalten ja sämtliche Änderungen am Datenbestand (siehe unten). Der Nachteil: Sorgt man nicht für ein regelmäßiges Backup der Logs, so wachsen diese endlos an, bis die Platte voll ist. Als Folge bleibt dann die ganze Datenbank stehen – denn ohne Protokoll kein Zugriff.

Im Modell “Einfach” (Simple) hingegen gibt SQL Server den Platz innerhalb der Datei bei jedem Checkpoint wieder frei. Dadurch kann die Datei nicht unkontrolliert anwachsen und stellt im Normalfall kein Risiko für die Plattenbelegung und den Online-Status der Datenbank dar. Allerdings lassen sich die Transaktionsprotokolle in diesem Fall auch nicht für das Restore von Daten einsetzen, weil sie ja nicht lückenlos vorliegen.

“Recovery” und “Restore” – hier nicht dasselbe!

Eine Besonderheit bringt der SQL Server mit: Die Begriffe “Recovery” und “Restore”, die man sonst oft synonym verwendet, bezeichnen hier völlig unterschiedliche Dinge. Man sollte sie auseinanderhalten, wenn man verstehen möchte, was SQL Server in welcher Situation tut. Ungünstigerweise übersetzt die meiste deutschsprachige Dokumentation beide Begriffe mit demselben Wort “Wiederherstellung” …

Recovery: Automatisch beim Systemstart

Der “Recovery”-Vorgang läuft immer automatisch beim Systemstart ab bzw. wenn SQL Server eine Datenbank online stellen soll. In diesem Moment muss das System sicherstellen, dass die Datenbank sich in einem konsistenten Zustand befindet. Dazu überprüft der Server das Transaktionsprotokoll der Datenbank, ob sich dort nach dem letzten Checkpoint noch Transaktionen befinden. Falls ja, schreibt das System die abgeschlossenen Vorgänge (“committed transactions”) in die Datenbank. Dies nennt sich “rollforward”. Die nicht abgeschlossenen Vorgänge, die also z.B. durch einen Ausfall des Servers unterbrochen wurden (“uncommitted transactions”) entfernt der Server aus dem Protokoll. Dies nennt man “rollback”.

Erst nach dem Abschluss dieses Prozesses kann SQL Server die Datenbank online schalten und für lesende oder schreibende Zugriffe freigeben. Da der Recovery-Prozess bei großen und sehr aktiven Datenbanken durchaus eine längere Weile dauern kann, gibt es in jüngeren Programmversionen des SQL Server einige Optimierungen dazu. Das Recovery erfolgt beispielsweise auch beim Failover eines SQL-Clusterservers, wodurch die Umschaltzeit auf den Failover-Knoten manchmal unerwartet lang dauern kann.

Restore: Manuell nach Datenverlust

Der “Restore”-Prozess bezeichnet die manuelle Wiederherstellung einer SQL-Server-Datenbank nach einem Datenverlust, also das Gegenstück zum Backup. Hierzu gibt es eine Reihe von Methoden, aus denen der Admin je nach Situation die geeignete auswählen muss.

Daten sichern und wiederherstellen

Für Datensicherung und -wiederherstellung bietet SQL Server mehrere Methoden, die teilweise auf dem Transaktionsprotokoll beruhen. Alle Methoden eignen sich für das Online-Backup, ohne dass SQL Server angehalten werden muss.

Vollständiges Backup

Das vollständige Backup sichert alle Seiten (Pages) der Datenbank auf das Sicherungsmedium und liest diese dazu direkt von der Festplatte. Durch eine leistungsfähige Priorisierung sorgt der Prozess dafür, dass Änderungen an Datenbankseiten erst dann erfolgen können, wenn die Seiten bereits gesichert wurden. Das führt natürlich dazu, dass während des Sicherungsvorgangs nicht die gesamte Performance des Datenbankservers zur Verfügung steht. Trotzdem bildet die vollständige Datensicherung die Grundlage für alle Sicherungsverfahren und sollte daher regelmäßig ausgeführt werden.

Dieser Sicherungstyp lässt sich über die grafischen Verwaltungstools oder per SQL-Kommando ausführen. Die Grundsyntax zur Ad-hoc-Sicherung in eine Datei lautet:

BACKUP DATABASE NameDerDatenbank TO DISK = 'C:\Pfad\Dateiname.bak'

Differenzielles Backup

Das differenzielle Backup sichert alle Seiten der Datenbank, die sich seit dem letzten vollständigen Backup geändert haben. Der eigentliche Sicherungsprozess entspricht dem der vollständigen Sicherung. Aufgrund des Prinzips wird der Umfang der Datensicherung tendenziell um so größer, je länger das Full Backup zurückliegt.

Auch dieser Sicherungstyp lässt sich grafisch oder per Code ausführen. Die Grundsyntax ist in diesem Fall:

BACKUP DATABASE NameDerDatenbank TO DISK = 'C:\Pfad\Dateiname.bak'
WITH DIFFERENTIAL

Transaktionsprotokoll-Backup

Die Datensicherung der Transaktionsprotokolle erfolgt auf gänzlich andere Weise. Hier sichert der Server nicht die eigentlichen Datenbank-Seiten, sondern den Inhalt des Transaktionsprotokolls. Dafür gibt es drei zwingende Voraussetzungen:

1. Das Wiederherstellungsmodell der Datenbank ist “Vollständig” (oder “Massenprotokolliert”, was aber noch einige Besonderheiten nach sich zieht)
2. Es hat mindestens eine vollständige Datenbank-Sicherung stattgefunden, seit der Modus “Vollständig” aktiviert wurde
3. Die Transaktionsprotokoll-Sicherungen erfolgen in einer Reihe ohne Unterbrechung. (Sollte einmal eine Unterbrechung nötig sein – etwa weil das Log vollgelaufen war und manuell gekürzt werden musste –, so ist zunächst wieder eine vollständige Datenbank-Sicherung nötig.)

Die Transaktionsprotokoll-Sicherung entspricht dem “inkrementellen Backup” in klassischen Umgebungen, denn sie bezieht sich immer auf die vorangegangene Protokollsicherung. Je häufiger man einen solchen Sicherungsprozess ausführt, desto geringer ist tendenziell der Umfang der einzelnen Sicherung. Damit eignet sich das Verfahren auch für Strategien mit sehr hoher Frequenz, beispielsweise alle 15 Minuten.

Natürlich lässt sich auch dieses Verfahren grafisch oder per Kommando ausführen. Die Syntax ist etwas anders als bei den anderen Varianten:

BACKUP LOG NameDerDatenbank TO DISK = 'C:\Pfad\Dateiname.bak'

Wiederherstellung

Die Wiederherstellung einer Datenbank hängt bezüglich des einzusetzenden Verfahrens von zahlreichen Faktoren ab – dazu gehören natürlich die Methoden, die für das Backup genutzt wurden. Da aber auch viele andere Besonderheiten zu berücksichtigen sind, beschränken wir uns hier absichtlich auf einige grundlegende Hinweise.

Wiederherstellung eines “Full Backup”

Der einfachste Restore-Vorgang ist die Wiederherstellung von einer vollständigen Datensicherung. Dadurch setzt man die Datenbank auf den Stand zurück, den sie beim Backup hatte. Alle Daten also, die zwischen dem Backup und dem Eintritt des Schadens geändert wurden, sind damit verloren.

“Maximale” Wiederherstellung

Um mehr als nur das letzte “Full Backup” wiederherzustellen, benötigt man als Datenbasis ein differenziertes Sicherungssystem, idealerweise kombiniert aus vollständigen und protokollbasierten Sicherungen; je nach Größe der Datenbank ggf. ergänzt um differenzielle Sicherungen. Im Fall des Falles verläuft der prinzipielle Restore-Vorgang so:

1. Wiederherstellen des letzten Full Backup
2. Falls vorhanden, wiederherstellen des letzten Differenziellen Backup
3. Wiederherstellen aller Transaktionsprotokolle, die nach dem Differenziellen Backup gesichert wurden

Wichtig dabei: Schritt 3 muss lückenlos erfolgen. Wichtig ebenso: In diesem Prozess darf der sog. “Recovery-Prozess” (siehe oben) erst nach dem letzten wiederhergestellten Transaktionsprotokoll erfolgen, er muss also vorher unterdrückt werden.

Weitere Details finden sich in der Online-Hilfe des SQL Server. Die nötigen Schritte des Restore-Prozesses sollte man regelmäßig und ausführlich üben!

Ein bisschen Best Practice

Die folgenden Hinweise verstehen sich ausdrücklich nicht als feste Empfehlungen für jede Situation, sondern nur als Faustregeln für typische, überschaubare Anforderungen.

• Für eher “einfache” Datenbanken ist es durchaus sinnvoll, das Wiederherstellungsmodell auf “Einfach” zu stellen (Recovery Model “Simple”). Auf diese Weise ist sichergestellt, dass die Log-Dateien nicht überlaufen. Die nachteilige Folge ist, dass man von solchen Datenbanken nur vollständige Backups (sowie differenzielle Backups) erzeugen kann, die Transaktionsprotokolle lassen sich in diesem Zustand nicht sichern und damit auch nicht für die Wiederherstellung einsetzen. Für viele Datenbanken ist das aber auch gar nicht nötig: Rein administrative Datenbanken etwa enthalten oft nur Konfigurationsinformationen oder statistische Daten. Im Fall eines Falles wäre es hier durchaus denkbar, nur auf den Stand des letzten Full Backup zurückkehren zu können.
• Für wirklich kritische Datenbanken hingegen ist das Wiederherstellungsmodell “Vollständig” besser geeignet – allerdings auch nur dann, wenn man einen dazu passenden Backup- und Restore-Plan implementiert (siehe oben). Ein typisches Beispiel sind hochdynamische ERP-Datenbanken, für die ein Unternehmen den Datenverlust so gering wie möglich halten muss.
• Vorsicht: Sobald das Wiederherstellungsmodell auf “Vollständig” steht, ist man verpflichtet, für ein regelmäßiges Log-Backup zu sorgen, weil sonst die Log-Dateien unweigerlich voll laufen werden. Hierzu also:
  • Direkt im Anschluss an das Umschalten auf das “vollständige Wiederherstellungsmodell” eine Komplettsicherung (Full Backup) der Datenbank erzeugen
  • Direkt danach einen regelmäßigen Log-Backup-Plan einrichten (min. einmal täglich, vielleicht öfter) – hierzu eignet sich der SQL Server Agent
  • Den entsprechenden Recovery-Plan dafür entwerfen und dokumentieren
  • Das Log Volume ständig überwachen, ob es nicht trotzdem vollläuft (je nach Transaktionsart kann es durchaus auch mal zu einem plötzlichen deutlichen Anwachsen der Logs kommen, z.B. bei Daten-Imports in eine Datenbank)

Verwandte Beiträge:

1. Exchange Server 2007 SP1 und Remote Streaming Backup
   Um eine Exchange Server Datenbank zu sichern, wird in den...
2. Windows Server Backup verstehen und nutzen
   Windows Server Backup ist das Werkzeug, das seit Windows Server...
3. Automatische Backups für SQL Server Express
   Die Express-Edition des SQL Server 2005 erfreut sich ähnlich großer...

Es gibt aber eine Lösung dafür, die ich hier gefunden habe:

[SQL Server 2008: Forgot to add an administrator account? - Chris Randall's SQL Blog - AmeriTeach Instructor Blogs]
http://blogs.ameriteach.com/chris-randall/2009/12/11/sql-server-2008-forgot-to-add-an-administrator-account.html?lastPage=true&postSubmitted=true

Weiteres Problem: Das Ganze funktionierte nicht mit einer Installation von SQL Server Express. Ich habe aber rausgefunden, warum, daher hier noch einmal die wesentlichen Schritte.

• Anmelden am Server mit einem lokalen Administrator.
• Aufrufen eines CMD-Fensters als Administrator (!).
• Beenden des SQL-Server-Dienstes:
  net stop MSSQLServer
  Für SQL Express: net stop MSSQL$SQLEXPRESS
• Wechseln in das BINN-Verzeichnis der Installation
  z.B.: cd C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Binn
• Starten des SQL-Server-Binary mit der Option -m für den Einzelbenutzermodus – dort hat der lokale Admin dann Adminrechte …
  • Wichtig: In früheren Versionen konnte man auch den Dienst mit dem Schalter -m starten – das geht nun nicht mehr!
  • sqlserv.exe -m
  • Für SQL Express muss man die Instanz angeben, also: sqlserv.exe -m -sSQLEXPRESS
  • Nun gibt der SQL Server viele, viele Zeilen aus. Das ist okay.
  • Wichtig: Dieses CMD-Fenster nicht schließen! Stattdessen ein neues öffnen!
• In dem neuen CMD-Fenster (als Administrator gestartet!) eingeben (nur den fetten Text):
  • osql -E -s SERVERNAME (mit Leerzeichen nach dem s!), also:
    osql -E -s MeinServer
    Für SQL Express: osql -E -s MeinServer\SQLEXPRESS
  • 1> CREATE LOGIN [DOM\Username] FROM WINDOWS
  • 2> go
  • 1> exec sp_addsrvrolemember 'DOM\Username', 'sysadmin'
  • 2> go
  • 1> exec sp_helpsrvrolemember 'sysadmin'
  • 2> go
  • (nun sollte in der Ausgabe der eben zugewiesene Windows-Account erscheinen)
  • 1> quit
• Nun in dem anderen CMD-Fenster Strg-C drücken und die Nachfrage mit “y” beantworten.
• Den SQL Server neu starten:
  net start MSSQLServer
  bzw. net start MSSQL$SQLEXPRESS
• Fertig. Nun sollte ein Login mit diesem Account glücken und über SQL-Adminrechte verfügen.

Verwandte Beiträge:

1. SQL Server Express: Authentisierungsmodus umschalten
   SQL Server kennt seit jeher zwei Authentisierungsmodi: “Windows-Authentifizierungsmodus” und “SQL...
2. Windows Server 2008 R2: Keine Vertrauensstellung zu NT4 möglich
   In Domänen, die unter Windows Server 2008 R2 laufen, ist...
3. Warum kann ein Benutzer Dateien ändern, für die er keine Rechte hat?
   Benutzer können Dateien löschen, auf die sie keinen Zugriff haben....

Leider ist der Weg dahin etwas steinig. Hier die wichtigen Dinge:

• Der Name der Datenbank ist technisch nicht wichtig, man sollte ihn aber wiedererkennen können. Darauf achten, dass die Datenbank und die Logs an der richtigen Stelle (Platten, die dafür vorgesehen sind) gespeichert werden.
• Wichtig ist die Sortierreihenfolge (Collation). Sie muss auf “Latin1_General_CI_AS_KS_WS” stehen.
  Sollte man das beim Anlegen übersehen, so kann man es nachträglich ändern. Im SQL Server Management Studio in einer neuen Abfrage auf Ebene der master-Datenbank eingeben:
  alter database <Datenbankname> collate Latin1_General_CI_AS_KS_WS
• Der Owner der Datenbank muss das SQL-Zugrifsskonto des Sharepoint-Servers sein.
  Um dies ggf. zu ändern: Neue Abfrage auf Ebene der neuen Search-Datenbank, dort:
  exec sp_changedbowner 'DOMÄNE\Loginname'
• Drei Konten benötigen dbo-Rechte in der Datenbank. Hierzu in der Datenbank unter “Sicherheit/Benutzer” die Logins als Benutzer hinzufügen und in die Rolle “db_owner” aufnehmen.
  • Das Konto für den Applikationspool
  • Das Konto für die Inhaltsindizierung
  • Das Konto für den Suchdienst

Verwandte Beiträge:

1. Sharepoint 2007 unter 2008 R2: Bei Neuinstallation wird “Erweitert” nicht angeboten
   Muss man Sharepoint 2007 aus irgendeinem Grund völlig neu installieren,...
2. Sharepoint: DCLauncher und DCLoadBalancer starten nicht
   In einer Sharepoint-Installation (MOSS 2007) wollte der Dienst DCLoadBalancer (Document...
3. Warum kann ich einen User nicht mit dem "memberOf"-Attribut einer Gruppe hinzufügen?
   Das Feld "memberOf" ist ein sog. "Backlink"-Feld, das zur Abfragezeit...

Da SQL-interne Konten weniger gut geschützt sind als Windows-Konten, richtet das Setup-Programm des SQL Server (auch SQL Server Express) den Authentisierungsmodus standardmäßig nur für Windows-Konten ein. Leider ist es aber so, dass viele Applikationen partout nur mit der SQL-Authentisierung arbeiten wollen (auch wenn es meist technisch keinen Grund dafür gibt). Hat man hier bei der Installation nicht aufgepasst (oder ist die SQL-Installation automatisiert durchgelaufen), so muss man den Modus nachträglich umstellen.

Die grafische Methode

Am einfachsten geht das natürlich per GUI. Je nach Situation ist das grafische Verwaltungsprogramm allerdings gar nicht installiert. Wer den SQL Server Express intensiver nutzen möchte, sollte sich daher durchaus das Express-GUI installieren.

[SQL 2005: Microsoft SQL Server Management Studio Express]
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c243a5ae-4bd1-4e3d-94b8-5a0f62bf7796

[Microsoft SQL Server 2008 Management Studio Express]
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=08e52ac2-1d62-45f6-9a4a-4b76a8564a2b

Dort ruft man per Rechtsklick auf den Server dessen Eigenschaften auf.Sodann befindet sich die gesuchte Einstellung unter “Sicherheit”.

Wichtig: Nach dem Umstellen muss man den Dienst “SQL Server” neu starten!

Außerdem ist es nötig, das sa-Konto zu aktivieren und mit einem Kennwort zu versehen. Alternativ kann man auch ein neues Konto erzeugen.

sa-Konto aktivieren

Das geht im GUI über den Eintrag “Sicherheit/Anmeldungen”:

sa-Konto mit neuem Kennwort versehen …

… und aktivieren.

Neues SQL-Adminkonto einrichten

Auch hierzu im GUI nach “Sicherheit/Anmeldungen” navigieren und per Rechtsklick eine “Neue Anmeldung” erzeugen. Dort zunächst Name, SQL-Anmeldemodus und Kennwort wählen …

… und dann unter “Serverrollen” die Rolle “sysadmin” zuweisen.

Die nichtgrafische Methode

Wer sich die Installation des Management Studio für diesen Zweck ersparen will, hat aber auch eine Möglichkeit. Die Anleitung gilt für SQL 2005 und SQL 2008 Express.

• Registry-Editor starten.
• Navigieren zu: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server
• Dort den Unterschlüssel für die gewünschte Instanz heraussuchen (in meinem Fall: MSSQL10.SQLEXPRESS).
• darunter in den Schlüssel MSSQLServer wechseln. In den Details steht der Eintrag “LoginMode”.
• Der Modus steht standardmäßig auf 1 (Windows-Authentisierung). Diesen ändern auf 2 (SQL- und Windows-Authrntisierung).
• Registry-Editor beenden.
• Dienst SQL Server neu starten.

Damit ist man aber leider noch nicht fertig. Nun muss das sa-Konto noch aktiviert und mit einem Kennwort versehen werden. Je nach Applikation kann man das sa-Konto ggf. auch inaktiv lassen und stattdessen ein neues Konto erzeugen.

sa-Konto aktivieren

Das sa-Konto kann man in SQL 2005 und SQL 2008 mit dem Kommandozeilenprogramm osql bearbeiten. Vorsicht, das ist etwas eigen.

Lautet der Name der SQL-Server-Instanz “SQLEXPRESS” (das ist Standard), so startet man osql mit folgender Kommandozeile:

osql –E –S .\SQLEXPRESS

Dann führt man dort folgende Kommandofolge aus (nur die roten Teile eintippen!):

1> ALTER LOGIN sa ENABLE
2> GO
1> ALTER LOGIN sa WITH PASSWORD = 'Mein geheimes Kennwort!'
2> GO
1> quit

Nun sollte der Login als sa mit dem vergebenen Kennwort (bitte ein starkes Kennwort wählen!) möglich sein.

Neues SQL-Adminkonto einrichten

Statt den sa-Account zu nutzen, kann man auch ein neues Adminkonto erzeugen. Das geht so:

Lautet der Name der SQL-Server-Instanz “SQLEXPRESS” (das ist Standard), so startet man osql mit folgender Kommandozeile:

osql –E –S .\SQLEXPRESS

Dann führt man dort folgende Kommandofolge aus (nur die roten Teile eintippen!):

1> EXEC sp_addlogin 'MeinAdmin', 'Mein supergeheimes Kennwort!'
2> GO
1> EXEC sp_addsrvrolemember 'MeinAdmin', 'sysadmin'
2> GO
1> quit

Jetzt sollte man sich mit diesem neuen Konto auf SQL-Ebene anmelden können.

Referenz

[HOWTO: Configure Microsoft SQL Server for Mixed Mode Authentication - Eduzine©]
http://eduzine.edujini-labs.com/archives/24-HOWTO-Configure-Microsoft-SQL-Server-for-Mixed-Mode-Authentication.html

Verwandte Beiträge:

1. Automatische Backups für SQL Server Express
   Die Express-Edition des SQL Server 2005 erfreut sich ähnlich großer...
2. SQL Server 2008: Admins haben keine sysadmin-Rechte
   Mit SQL Server 2008 hat Microsoft das Sicherheitsmodell seines Datenbankservers...
3. sa-Konto absichern
   Eigentlich ist es seit Jahren bekannt …… aber immer wieder...

Warum irrt er?

Zum einen: für mich ist "kein Herstellersupport" ein schlagendes Sachargument, denn ich habe schon zahlreiche Situationen erlebt, in denen man ohne den Hersteller das jeweilige System hätte einstampfen können.

Zum anderen aber – technisch argumentiert: Eine Datenbank wie SQL Server (aber auch alle anderen) arbeitet nach dem "Lazy Writer"-Prinzip. Das bedeutet folgenden Ablauf (schematisch vereinfacht):

1. Eine Applikation fordert eine Änderung von Daten an (UPDATE oder INSERT usw.).
2. SQL Server lädt die betreffenden Datenbankseiten in den Cache (=RAM) bzw. lokalisiert sie dort.
3. SQL Server schreibt die Änderung ins Transaktionsprotokoll.
4. SQL Server ändert die Seiten im Cache (=RAM).
5. SQL Server sendet der Applikation ein Acknowledge über die Änderung.
6. Erst beim nächsten Intervall schreibt SQL Server die Daten in die Datenbankdatei, aber im Regelfall nicht sofort. (Steigert Performance, weil es Random Writes einspart.)

Wenn nun nach Schritt 5 der Strom weg ist – oder man eben einen Snapshot macht -, entsprechen die Daten auf der Platte nicht dem Stand, der an die Applikation berichtet wurde. Nun könnte man argumentieren: Kein Problem, dafür hat man ja das Transaktionsprotokoll. Richtig, hat man auch, und genau dafür ist es da. Das setzt aber voraus, dass das Protokoll auch nutzbar ist – und sich auf exakt demselben Stand (hier also Schritt 3) befindet. Nun liegt das Log aber i.d.R. auf einer anderen LUN als die Datenbank. Ist es also im Falle des "Hot Backups" per Snapshot (oder wie immer) auf demselben Stand? Das wage ich energisch zu bezweifeln.

Selbst in einem normalen Strom-weg-Szenario ohne Snapshot bleibt hier ein Risiko, denn es kann ja sein, dass das Transaktionsprotokoll beschädigt ist. Wenn man hier noch ein Risiko in seinem Backup hat, macht das aus meiner Sicht ein bisschen viel Risiko für einen sensiblen Bereich.

Man kann das auch variieren: Eine Datenbank kann ja auch selbst auf mehrere LUNs verteilt sein – gerade bei großen Datenbanken gibt es mehrere Gründe dafür. Nun betrifft ein Update beispielsweise mehrere Tabellen, die in Datenbankdateien auf mehreren LUNs liegen. Es muss hierbei schon mit schwarzer Magie zugehen, wenn man erwartet, dieses Szenario in einem "Hot Backup" konsistent hinzubekommen. Wir reden ja u.U. von High-Performance-Datenbanken, in der tausende Transaktionen in einer Sekunde verarbeitet werden.

Das muss man aber gar nicht so weit führen. Auch eine Transaktion in einer “ganz normalen” Datenbank, die nicht über mehrere LUNs verteilt ist, kann Datenbankseiten auf ganz unterschiedlichen Plattenbereichen betreffen. Natürlich müssen diese Änderungen alle gemeinsam geschrieben werden (oder eben gar nicht). Ein “Hot Backup” wie ein Snapshot kann aber nicht wissen, wann eine Transaktion abgeschlossen ist und “fotografiert” einfach mitten rein. Hier kann ein weiteres Problem auftreten: Eine Datenbankseite wird gar nicht vollständig geschrieben (“Torn Page”). Ein solches Problem wird u.U. nicht beim anschließenden Durchlauf der Transaktionsprotokolle beim Neustart der Datenbank behoben und bleibt unentdeckt. Je nach Konfiguration der Datenbank hat man also das Risiko unbrauchbarer Daten – oder die Datenbank hält an, weil sie das Problem bemerkt hat (“Torn Page Detection”) und fordert zum Restore aus einem Backup auf. Dumm, wenn das Restore gerade der Grund für das Problem war.

Auch der manchmal vorgeschlagene “Ausweg”, Datenbank- und Transaktionsprotokolldateien auf dieselbe LUN zu legen, um mit einem einzigen Snapshot arbeiten zu können, ist also kein echter Ausweg. Zumal man dies bei belasteten Datenbanken schon deshalb nicht machen wird, weil ein Transaktionsprotokoll auch mal plötzlich sehr stark anwachsen kann und auf einer separaten LUN besser aufgehoben ist.

Und das Argument mit "unwahrscheinlich" wird schon von der Praxis widerlegt, denn im Support gibt es ständig Anwenderprobleme, die auf Inkonsistenzen durch falsche Datenbanksicherungen zurückzuführen sind. Das hat z.B. überhaupt nichts mit der Dauer zu tun, die ein Snapshot zum Erzeugen braucht, sondern liegt einfach in der Art, wie relationale Datenbanken ihre Daten ablegen.

Schließlich bleibt das Nutzenargument: SQL Server hat etwa mit der VSS-Schnittstelle eine eingebaute (und supportete) Möglichkeit, für Backupzwecke eine Konsistenz zu erzeugen. Warum darauf verzichten und ein noch so kleines Risiko eingehen?

Verwandte Beiträge:

1. MS SQL 2005: Transaction Log von der Datenbank trennen
   Mit dem "MS SQL Server Management Studio" ist es nicht...
2. SCVMM: VM aus der Datenbank entfernen
   In einer speziellen Situation ergab sich die Anforderung, eine virtuelle...
3. Warum Images nicht als Datensicherung taugen
   Images sind sehr beliebt. Die Technik, eine ganze Festplatte oder...

1.  "MS SQL Server Management Studio" mit einer Verbindung zur Datenbank öffnen.
2. Falls nicht schon vorhanden, ein "Query with Current Connection" öffnen (STRG+N).
3. Folgendes Script einfügen und den Datenbanknamen anpassen:
   use master
   go
   sp_detach_db 'Datenbank_Name'
   go
4. Jetzt können die beiden Datenankdateien (*.mdf & *_log.ldf) verschoben werden.
5. Folgendes Script einfügen, Datenbankname und Verzeichnispfade anpassen:
   use master
   go
   sp_attach_db 'Datenbank_Name','D:\Verzeichnis\Datenbank_Name.mdf','E:\Verzeichnis\Datenbank_Name_log.ldf'
   go

Erklärung:

Im dritten Schritt wirde die Datenbank vom MS SQL Server abgetrennt. Sobald die Datenbank abgetrennt wurde, kann man die eigentlichen Datenbankdateien verschieben und die Transactionsprotokolldatei (*_log.ldf) z.B. auf eine andere Partition verschieben.

Im fünften Schritt wird die Datenbank wieder angefügt, jedoch wird beim Anfügen dem MS SQL Server mitgeteilt, wo die entsprechenden Datenbankdateien sich befinden.

Verwandte Beiträge:

1. Warum muss eine Datenbank zum Backup konsistent sein?
   Aus einer Diskussion: Ein Berater ist der Ansicht, ein sog....
2. SCVMM: VM aus der Datenbank entfernen
   In einer speziellen Situation ergab sich die Anforderung, eine virtuelle...
3. Große Datenbank
   Wir hatten mal einen Kunden, der sich (wie auch immer)...

Die Vorträge sind in guter Qualität im Split-Screen-Verfahren aufgenommen worden: Links ein kleines Video des Redners, rechts groß der Bildschirminhalt (wichtig bei Demos). Da der Ton natürlich direkt vom Sprechermikro aufgenommen wurde, dürfte in manchen Fällen der Sprecher sogar besser verständlich sein als vor Ort, denn in den Messehallen war die Akustik teils nicht ganz so toll.

Hier der Link:

[Microsoft Launch 2008 – Home]
http://www.microsoft.com/germany/msdn/launch2008/default.mspx

Viel Spaß!

(Interessant für mich übrigens, mal selbst zu sehen, wie sehr ich den Kameramann auf Trab gehalten habe …)

Verwandte Beiträge:

1. So war der Launch: Exklusive Session-Videos
   Vor wenigen Wochen hat Microsoft in Deutschland seine neuen Produkte...
2. ice:2011: Die Videos sind online
   Ein Teil der diesjährigen ice:2011 in Lingen wurde von Microsoft...
3. Windows Server 2008 und Vista SP1 sind fertig!
   Mittlerweile pfeifen es schon viele Spatzen von den Dächern: Seit...

Neben den funktionalen Einschränkungen – die Größe der verwaltbaren Datenbanken ist begrenzt, und es können nur wenige Benutzer gleichzeitig performant arbeiten – gibt es aber auch in der Verwaltung der Datenbanken einige Hindernisse. Das Verwaltungswerkzeug SQL Server Management Studio fehlt, und auch die Automatisierungskomponente SQL Server Agent ist bei der Express Edition nicht ohne Weiteres nutzbar. Wenn man weiß, was zu tun ist, lässt sich diese Lücke aber für viele Fälle mit dem Windows-eigenen Taskplaner und ein paar Skripts überbrücken.

Ein großes Problem in der Praxis ist, dass viele Express-Datenbanken faktisch nie richtig gesichert werden. Ein Serverausfall hat so unter Umständen kritische Auswirkungen, denn die Daten sind weg. Dabei bringt SQL Server selbst schon alles mit, was man für eine ordentliche Datensicherung braucht – auch die Express Edition kann das. Man muss nur wissen, wie.

SQL-Sicherung mit Bordmitteln

Das folgende Skript sichert sowohl die Datenbank selbst als auch die Transaktionsprotokolle in jeweils eine Datei. Letzteres ist wichtig, falls das "Wiederherstellungsmodell" der Datenbank auf "Vollständig" steht. Wird in diesem Fall keine regelmäßige Transaktionsprotokollsicherung durchgeführt, kann die Serverfestplatte volllaufen. Im Beispiel heißt die Datenbank "MeineDB".

BACKUP DATABASE [MeineDB] TO DISK='C:\Backup\MeineDB_sich.bak'
WITH  INIT, NAME = N'MeineDB_Sicherung'

BACKUP LOG [MeineDB] TO DISK='C:\Backup\MeineDB_Log_sich.bak'
WITH INIT, NAME = N'MeineDB_Log_Sicherung'

Die Option "with init" sorgt dafür, dass die Sicherungsdatei bei jedem Backup überschrieben wird. In der Datei ist so nur die letzte Sicherung enthalten. Diese Datei wird gespeichert als "MeineDB-Fullbackup.sql". Wer in einem separaten Job nur die Transaktionprotokolle sichern möchte, teilt die Datei in zwei und setzt jeweils nur das "backup database"- bzw. das "backup log"-Kommando in eine Datei. Der folgende Code bildet die Batchdatei, die z.B. täglich mit dem Windows-Taskplaner aufgerufen wird:

@echo off
rem Ausführen eines Full Backup der MeineDB-Datenbank
rem !! das Folgende ist eine einzige Zeile!
"C:\Programme\Microsoft SQL Server\90\Tools\binn\SQLCMD.EXE" -S DBSERVER
   -E -i C:\Backup\MeineDB-FullBackup.sql -o C:\Backup\BackupLog.txt
rem !! ab hier wieder normal

rem Zeitstempel erzeugen
for /f "tokens=1-4 delims=. " %%i in ("%date%") do (
  set day=%%i
  set month=%%j
  set year=%%k
)

for /f "tokens=1-4 delims=.:, " %%i in ("%time%") do (
 set hour=%%i
 set minute=%%j
 set second=%%k
 set hundredth=%%l
)

rem Log-Datei mit Zeitstempel umbenennen
ren C:\Backup\BackupLog.txt FullBackup-%year%-%month%-%day%-%hour%-%minute%.txt

Diese Batchdatei ruft das SQL-Sicherungsskript mit dem Hilfsprogramm sqlcmd.exe auf, das den SQL Server auf der Kommandozeile ansteuern kann. Der Datenbankserver trägt hier den Namen "DBSERVER". Zur besseren Nachverfolgung schreibt die Batchdatei die Ausgaben des sqlcmd-Kommandos in eine Logdatei, die dann mit dem aktuellen Zeitstempel umbenannt wird.

Dieses Verfahren funktioniert (voraussichtlich) auch mit SQL Server 2008 Express Edition. Natürlich kann man so auch Datenbanken eines "echten" SQL Server sichern, nur ist es in dem Fall sinnvoller, das SQL-Backupskript gleich über den mitgelieferten SQL Server Agent auszuführen, der sich zur SQL-Automatisierung noch besser eignet.

Verwandte Beiträge:

1. SQL Server Express: Authentisierungsmodus umschalten
   SQL Server kennt seit jeher zwei Authentisierungsmodi: “Windows-Authentifizierungsmodus” und “SQL...
2. Exchange Server 2007 SP1 und Remote Streaming Backup
   Um eine Exchange Server Datenbank zu sichern, wird in den...
3. Automatische Systemwiederherstellung (ASR)
   Die automatische Systemwiederherstellung (ASR = Automated System Recovery) sollte die...