WICHTIG: Zu diesen Routineaufgaben gehören SQL Server-Wartungsvorgänge, die dafür sorgen, dass die Datenzugriffe und das SQL-Modul ordnungsgemäß funktionieren und die Daten gesichert werden, um nach einem Ausfall eine Wiederherstellung zu ermöglichen. Diese Informationen richten sich nur an Datenbank-Administratoren (DBA) und ePO-Administratoren. Verwenden Sie das folgende Verfahren auf eigene Gefahr. Intel Security übernimmt keine Verantwortung für etwaige Schäden, die durch die Befolgung dieser Anleitung entstehen.

Hintergrund:
SQL Server nutzt das Konzept des Write Ahead Logging (WAL), bei dem jeder Datenänderungsvorgang (Insert, Update, Delete und weitere Vorgänge, wie z. B. die Neuerstellung der Indizes und Reorganisierungen) zunächst aus dem Speicher (Puffer-Pool) in das Transaktionsprotokoll (.LDF) geschrieben und als Teil des CheckPoint-Prozesses regelmäßig auf die Festplattendatendatei (.MDF) ausgelagert wird. Einer der wichtigsten Gründe für die Verwendung eines Transaktionsprotokolls besteht darin, dafür zu sorgen, dass Sie die Datenbank nach einem Ausfall, z. B. nach einem schweren Hardware- oder Benutzerfehler, mit geringem Datenverlust in einem früheren Zustand wiederherstellen können.

Vollständiges Wiederherstellungsmodell:
Beim vollständigen Wiederherstellungsmodell markiert SQL Server die gesicherten Datensätze als "Inaktiv" (Kürzen des Protokolls), nachdem eine Sicherung des Transaktionsprotokolls mithilfe des vollständigen Wiederherstellungsmodells durchgeführt wurde. Dadurch können neue protokollierte Vorgänge diesen Platz durch Überschreibung inaktiver Einträge im Transaktionsprotokoll wiederverwenden, sodass die Protokolldatei nicht zu groß wird.

Wenn das Transaktionsprotokoll nicht regelmäßig gesichert wird, wächst das Transaktionsprotokoll so lange, bis der gesamte Speicherplatz belegt ist. Daher müssen regelmäßige Sicherungen des Transaktionsprotokolls durchgeführt werden, um seine Größe in Grenzen zu halten, wenn die ePO-Datenbank für die Verwendung des vollständigen Wiederherstellungsmodells konfiguriert ist.

Einfaches Wiederherstellungsmodell:
Im einfachen Wiederherstellungsmodus wird das Transaktionsprotokoll von SQL Server nach dem CheckPoint gekürzt, und die Datensätze werden auf die Festplatte übertragen. Auf diese Weise wird Speicherplatz in der Transaktionsprotokolldatei freigegeben. Das Transaktionsprotokoll wird daher nicht größer, solange genügend Speicherplatz für die laufenden Transaktionen verfügbar ist.

Beim einfachen Wiederherstellungsmodell wird das Konzept der Sicherung des Transaktionsprotokolls daher also nicht verwendet, da Sie nur eine regelmäßige vollständige Sicherung der ePO-Datenbank durchführen. Nach einem Ausfall können Sie nur die letzte vollständige Sicherung wiederherstellen. Alle danach aufgetretenen Änderungen gehen verloren.

Für die meisten Enterprise-Kunden ist die Verwendung des einfachen Wiederherstellungsmodells eine brauchbare Lösung, da nach einem Ausfall hauptsächlich nur die Ereignisinformationen seit der letzten Sicherung verloren gehen. Beim vollständigen Wiederherstellungsmodell fällt zusätzlicher Verwaltungsaufwand an, da das Transaktionsprotokoll für die ePO-Datenbank regelmäßig gesichert werden muss.

Aus diesem Grund empfiehlt Intel Security die Verwendung des einfachen Wiederherstellungsmodells für die ePO-Datenbank. Falls Sie sich doch für das vollständige Wiederherstellungsmodell entscheiden, benötigen Sie einen zuverlässigen Sicherungsplan sowohl für die ePO-Datenbank als auch für das Transaktionsprotokoll. Eine ausführliche Abhandlung des Sicherungsplans für SQL Server-Datenbanken würde den Rahmen dieses Artikels sprengen. Ausführlichere Informationen dazu finden Sie in der SQL Server-Online-Dokumentation: https://msdn.microsoft.com/de-de/library/ms130214.aspx.

HINWEIS: Wenn Sie über mehrere Datenbanken mit unterschiedlichen Wiederherstellungsmodellen verfügen, können Sie für jedes Wiederherstellungsmodell einen eigenen Datenbankwartungsplan erstellen. Auf diese Weise können Sie einen Schritt zum Sichern Ihrer Transaktionsprotokolle nur für diejenigen Datenbanken einfügen, die nicht den einfachen Wiederherstellungsmodus verwenden.


Festlegen des Wiederherstellungsmodells "Simple" (Einfach) für die ePO-Datenbank
Um das Wiederherstellungsmodell auf "Simple" (Einfach) festzulegen, öffnen Sie SQL Server Management Studio, und führen Sie die folgenden Schritte durch: 

Verkleinern der Datenbank und warum dies NICHT empfehlenswert ist:
Das Verkleinern der ePO-Datenbank sollte unbedingt vermieden werden. Das Verkleinern einer SQL Server-Datenbank in einer Produktionsumgebung führt zu einer logischen Fragmentierung, d. h., die physische Reihenfolge der Seiten auf Blattebene eines Indexes stimmt nicht mehr mit der logischen Reihenfolge der Seiten überein. Dadurch muss der Lesekopf beim Lesen der Seiten ständig hin und hergeführt werden, was die Anzahl der E/A-Vorgänge erhöht und damit die Leistung vermindert.

Wenn Sie die Datendatei verkleinern, werden die Seiten am Ende der Datendatei an den Anfang der Datei verschoben, obwohl dieses Verfahren zur Fragmentierung führen kann.

Falls Sie nach dem Löschen von Ereignissen und dem Verkleinern der Datenbank bemerken, dass die ePO-Datenbank anwächst, bedeutet dies, dass der Platz für Ereignisse benötigt wird, die vom Agenten gesendet werden. Daher führt das Verkleinern der Datendatei nach dem Löschen der Ereignisse dazu, dass die Datei wieder anwächst und zudem eine Fragmentierung erfolgt. Falls Sie auf die Speicherplatznutzung achten müssen, empfiehlt sich das Herausfiltern unwichtiger Ereignisse mithilfe der ePO-Ereignisfilterungsfunktion.

HINWEIS: Nach dem Durchführen einer großen Anzahl von Löschvorgängen, z. B. nach dem Bereinigen alter Ereignisse, können Sie das Verkleinern der Datendatei in Erwägung ziehen, wenn Sie sicher sind, dass Sie den Speicherplatz nicht erneut für das Speichern von neuen Ereignissen benötigen. Anderenfalls wird empfohlen, die Indizes regelmäßig neu zu erstellen und nicht benötigte Ereignisse mithilfe der ePO-Ereignisfilterungsfunktion herauszufiltern, um die Erfassung unerwünschter Daten gleich zu unterbinden.

WICHTIG: Das Filtern von Ereignissen wirkt sich direkt auf die generierten Berichte aus, die auf diese Ereignisse zurückgreifen. Sie dürfen daher nur Ereignisse herausfiltern, die für die täglichen Berichte nicht benötigt werden. Bevor Sie ältere Ereignisse bereinigen, sollten Sie die ePO-Datenbank sichern. Sie könnten diese ePO-Datenbanksicherung dann jederzeit unter einem anderen Namen wiederherstellen, um Berichte für diesen Zeitraum generieren zu können.

Wenn die Datenbank ordnungsgemäß gewartet wird (z. B. Indizes neu erstellen und neu organisieren), sollte die Größe der ePO-Datenbank die Leistung von Abfragen nicht beeinträchtigen. Wenn Sie regelmäßig mithilfe des ePO-Server-Tasks "Ereignisse bereinigen" alte Ereignisse löschen (z. B. alle Ereignisse, die älter als drei Monate sind), sollte die Datenbankgröße einigermaßen stabil bleiben, sofern die Wachstumsrate der Datenbank proportional im Verhältnis zu den älteren Ereignissen steht, die gelöscht werden.

Sie benötigen einen angemessenen Datenbankwartungsplan, um sicherzustellen, dass die Leistung der ePO-Datenbank optimal ist. 

Erstellen Sie in SQL Server einen Wartungsplan für die ePO-Datenbank:

HINWEIS: Wenn die ePO-Datenbank sehr groß ist, sollte der Datenbankadministrator den Wartungs-Task überwachen und ihn außerhalb der Arbeitszeiten ausführen.

Wenn Sie mit einer großen Produktionsdatenbank arbeiten, empfiehlt Intel Security, für das Neuerstellen bzw. Neuorganisieren des Index anstelle der Wartungsplan-Tasks "Index Reorganize" und "Index Rebuild" ("Index neu organisieren" und "Index neu erstellen") ein entsprechendes benutzerdefiniertes Skript zu verwenden.

So können Sie flexibler auswählen, welche Objekte neu organisiert und/oder neu erstellt werden sollen, als bei einem vorgegebenen Task, bei dem alle Objekte ungeachtet des Fragmentierungsgrads neu erstellt werden.

Laut SQL Server-Online-Dokumentation:

Den Fragmentierungsgrad eines Index können Sie ermitteln, indem Sie den Eintrag für die dynamische Verwaltungssicht (Dynamic Management View, DMV) sys.dm_db_index_physical_stats abfragen. Die Online-Dokumentation zu SQL Server stellt ein Beispiel-SQL-Skript zur Verfügung, das ein Fragmentierungsverhältnis bietet, wie es oben aufgeführt ist. Weitere Informationen hierzu finden Sie unter sys.dm_db_index_physical_stats in der folgenden Online-Dokumentation zu SQL Server:

 

HINWEIS: Den Beispielcode finden Sie im Beispiel D der Online-Dokumentation.

 

Sie müssen nach der Ausführung des Befehls Index Reorganize (Index neu organisieren) die Statistiken aktualisieren, da im Gegensatz zu Index Rebuild (Index neu erstellen) bei der Ausführung von "Index Reorganize" (Index neu organisieren) die Statistiken nicht automatisch aktualisiert werden. Die Datei RebuildReorganizeIndexes-V4.zip enthält ein aktualisiertes SQL-Skript, das auf dem oben angegebenen Beispiel der Online-Dokumentation zu SQL Server basiert. Diese Datei befindet sich im Abschnitt Anhänge dieses Artikels. Dieses Skript fügt den Schritt zum Aktualisieren der Statistiken nach Ausführung des Vorgangs "Index neu erstellen" hinzu.

Sie können das Skript weiter anpassen, um die Option zum Online-Neuerstellen eines Indexes durchzuführen. Bei der Online-Indexneuerstellung können mehr Indexneuerstellungsvorgänge parallel durchgeführt werden, sie belastet die Ressourcen daher stärker. Diese Funktion ist jedoch nicht in allen Editionen von SQL Server verfügbar. In der Online-Dokumentation wird angegeben, welche Editionen die Funktion zur Online-Indexneuerstellung unterstützen.