SQL Server-Wartungsplan - Best Practices für Aufgaben und Planung

Ich habe die Aufgabe, einen Wartungsplan für unsere SQL Server 2005-Datenbanken zu erstellen. Ich weiß, dass ich für Sicherungen alle 15 Minuten eine tägliche vollständige Datenbanksicherung und Transaktionsprotokollsicherungen durchführen möchte. Mein Problem besteht darin, herauszufinden, welche anderen Aufgaben ich ausführen möchte und wie oft ich sie ausführen sollte.

Soweit habe ich das vor Augen. Korrigieren Sie mich, wenn meine Überlegungen fehlerhaft oder besser sind.

1. Backup - Alle Tabellen, Full Backup (täglich)
2. Sicherung - Ausgewählte Tabellen, vollständige Sicherung (stündlich)
3. Backup - Transaktionsprotokolle (alle 15 Minuten)
4. Datenbankintegrität prüfen (täglich)
5. Index neu organisieren (täglich)
6. Statistiken aktualisieren (täglich)
7. Datenbank verkleinern (wöchentlich)
8. Index neu erstellen (wöchentlich)
9. Wartungsbereinigung (täglich)

Ich erinnerte mich, dass ich vor einiger Zeit gelesen hatte (als ich einen ähnlichen Plan für einen anderen Job aufstellte), dass einige dieser Aufgaben nicht täglich ausgeführt werden müssen oder nicht täglich ausgeführt werden sollten. Welche, das entgeht mir. Ich könnte ein wenig Anleitung zur Erstellung eines besseren Wartungsplans gebrauchen, der den Datenverlust bei einer Katastrophe verringert, das System jedoch nicht belastet, wenn es zu Spitzenzeiten ausgeführt wird (und auch die Leistung erhöht).

Josh,

Dies ist eine sehr häufige Aufgabe für alle Datenbankadministratoren, und die richtige Antwort ist NICHT für jeden und jeden Server gleich. Wie viele andere Dinge hängt es davon ab, was Sie brauchen.

Auf keinen Fall möchten Sie "Shrink Database" wie bereits vorgeschlagen ausführen. Das Schlechte an der Leistung und der unten stehende Hinweis zeigen Ihnen, warum. Dies führt zu Festplatten- und Indexfragmentierung und kann zu Leistungsproblemen führen. Sie sind besser dran, wenn Sie eine große Größe für die Daten- und Protokolldateien vorab zuweisen, damit das automatische Wachstum NICHT einsetzt.

Ich habe deine Nummer 2 nicht verstanden. ausgewählte Tabellen vollständige Sicherung. Können Sie das näher erläutern?

Bei der Indexreorganisation, der Aktualisierung von Statistiken und der Indexwiederherstellung müssen Sie sorgfältig vorgehen, da Sie sonst mehr Ressourcen verbrauchen und auch Leistungsprobleme haben.

Wenn Sie Indizes neu erstellen, werden die Statistiken der Indizes mit Fullscan aktualisiert. Wenn Sie danach jedoch Statistiken aktualisieren, werden diese erneut mit einem Standardmuster aktualisiert (das von mehreren Faktoren abhängt, normalerweise 5% der Tabelle, wenn die Tabellengröße> 8 ist MB), was zu Leistungsproblemen führen kann. Abhängig von Ihrer Edition können Sie möglicherweise Online-Indexerstellungen durchführen. Die richtige Methode für diese Aktivität besteht darin, den Fragmentierungsgrad zu überprüfen und abhängig davon entweder eine Indexerstellung oder eine Indexreorganisation durchzuführen und Statistiken zu aktualisieren. Außerdem möchten Sie möglicherweise ermitteln, welche Tabellen Statistiken häufiger aktualisieren müssen, und versuchen, Statistiken häufiger zu aktualisieren.

Wartungspläne sind in Ordnung, aber es ist schwierig, das Beste aus ihnen herauszuholen, wenn Sie sich nicht bei SSIS anmelden und die MPs optimieren können. Deshalb bevorzuge ich es, sie NICHT zu verwenden und Ola Hallengrens kostenlose Skripte zu verwenden , die robuster sind als MPs. Außerdem würde ich empfehlen, den Artikel von Paul Randal zu diesem Thema nachzuschlagen.

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Dies ist KEINE umfassende Antwort auf Ihre Frage, sondern ein guter Ausgangspunkt. HTH und lassen Sie uns wissen, wenn Sie weitere Fragen / Kommentare haben.

Ich werde meine Erfahrungen teilen, auch wenn Sie bereits eine Antwort akzeptiert haben. Vielleicht wird es hilfreich sein :-).

1. Tägliches Backup (täglich) - großartig, aber vergessen Sie nicht, nach einer festgelegten Zeit nach Speicherplatz zu suchen und alte Dateien zu entfernen.
2. Ausgewählte Tabellen (stündlich) sichern - Sie wissen nicht, warum Sie dies benötigen, sondern entscheiden sich für differenzielle Sicherungen. Wie sichern Sie nur bestimmte Tabellen: SSIS, Skripte, BCP? Planen Sie diff-Sicherungen nicht zu oft, da Sie die Rolle der Protokollsicherungen stehlen.
3. Transaktionsprotokoll-Backups (alle 15 Minuten) - großartig, sind Sie sicher, dass Sie für alle Datenbanken benötigen? Verwenden alle Datenbanken das vollständige Wiederherstellungsmodell oder nicht?
4. Überprüfen Sie die Datenbankintegrität - ja, aber Sie müssen sicherstellen, dass Sie Ihre Umgebung nicht töten. Die DBCC-Prüfanweisungen sind ziemlich egoistisch in Bezug auf Ressourcen und scannen vollständige DBS. Sie müssen daher außerhalb der Geschäftszeiten geplant werden.
5. Index neu organisieren (täglich) - nicht erzwingen, nur bei Bedarf. Überprüfen Sie die Index-DMVs auf Fragmentierung und reorganisieren Sie sie nur nach Bedarf. Ich würde alle Index- und Statistikoperationen auf eine einzelne wöchentliche Aufgabe verschieben.
6. Statistik aktualisieren (täglich) - Bitte sehen Sie meine Antwort auf eine vorherige Frage. Anstatt nur die Aktualisierung aller Statistiken zu erzwingen, sollten Sie jeden Tag überprüfen, wann die Statistiken zuletzt aktualisiert wurden, und sie nur in einigen Fällen aktualisieren.
7. Datenbank verkleinern (wöchentlich) - Oh, nein. Bitte lesen Sie den Artikel von Paul Randal über das Verkleinern von Dateien.
8. Neuerstellungsindex (wöchentlich) - siehe 5.

9. Unterhaltsreinigung (täglich) - ok damit.

10. Sie sollten auch eine Aufgabe hinzufügen, um Ihre Sicherungen zu überprüfen - es gibt eine Version des Befehls RESTORE (verifyOnly .. wenn ich mich richtig erinnere) - sagen wir wöchentlich, obwohl ich es täglich bevorzuge.

Sie erwähnen, dass Sie im Falle eines Datenverlusts abgeschirmt werden möchten. Ich würde daher sagen, dass Sie bei diesem Wartungsvorgang die Systemdatenbanken hinzufügen müssen. Achten Sie auch darauf, die Dateien auf einem anderen Computer als dem Server selbst zu sichern. Bewahren Sie irgendwo eine Datei mit den erforderlichen Schritten auf, falls Sie die Master-Datenbank msdb..etc neu erstellen müssen. Viel Glück bei deiner Aufgabe!

Verspätete Antwort könnte aber für andere Leser von Nutzen sein.

Beachten Sie, dass Sie zahlreiche Wartungs- oder Berichterstellungsaufgaben erstellen können, die mit unsichtbaren Risiken verbunden sind.

Was würde passieren, wenn ein Laufwerk während täglich durchgeführter differenzieller Sicherungen voll wird? Und was ist, wenn ein Job zur Indexwiederherstellung ungewöhnlich lange dauert? Wie wäre es, wenn ein Datenladeprozess zu umfangreichen Ressourcenkonflikten führt und den normalen Betrieb in die Knie zwingt? All dies sind geplante Ereignisse, die jedoch die Prozesse, die wir zu sichern versuchen, erheblich stören können.

Bedenken Sie immer, wie verschiedene Jobs interagieren, und planen Sie sie so, dass sich sensible oder ressourcenintensive Aufgaben nicht überschneiden.

Ich empfehle, diesen Artikel zuerst zu lesen: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Es wird beschrieben, wie wichtige Wartungsaufgaben in SQL Server ausgeführt werden - ohne Risiko. Zum Beispiel können Sie in Ihre Wartungsaufträge einfache Überprüfungen einbauen, die die verfügbaren Ressourcen sowie die Anforderungen eines Vorgangs vor der Ausführung überprüfen. Auf diese Weise können Sie sicherstellen, dass Ihre Umgebung mit dem, was Sie gerade tun, umgehen kann, und bei unzureichenden Ressourcen mit einem aussagekräftigen Fehler abbrechen.

1. Sieht gut aus

2. Hier können Sie von differenziellen Sicherungen profitieren. Sieh sie dir genau an

3. Sieht gut aus

4. Sieht gut aus

5. Wie bereits erwähnt, sind Datenbank-Shrinks schlecht, da sie eine physische Fragmentierung Ihrer Daten- und Protokolldateien verursachen und somit mehr zufällige E / A-Lesevorgänge verursachen.

5, 6 und 8: Siehe folgende.

Diese gehen wirklich Hand in Hand, da Indizes auf aktuellen Statistiken basieren und die Reihenfolge dieser Vorgänge ziemlich wichtig ist. Die von mir verwendete Basismethode, die zugegebenermaßen nicht für alle funktioniert, besteht darin, dass ich zwei Runden der Indexpflege durchführe. Zuerst mache ich die gruppierten Indizes und dann die nicht gruppierten Indizes. Die Methode, die ich für beide anwende, ist die folgende. Wenn ein Index groß genug und fragmentiert genug ist (sys.dm_db_index_physical_stats), erstelle ich den Index neu (einschließlich einer Statistikaktualisierung mit vollständiger Überprüfung). Wenn ein Index für eine Neuerstellung zu klein oder für eine Neuerstellung nicht ausreichend fragmentiert ist (weniger als 100 Seiten und eine Fragmentierung zwischen 5% und 15%), führe ich zunächst eine Indexreorganisation durch. Ich werde dann ein Statistik-Update mit vollem Scan durchführen.

Dies betrifft zwar die Indexstatistik, vernachlässigt jedoch die Spaltenstatistik. Wöchentlich aktualisiere ich die Spaltenstatistik.

Ich hoffe das hat irgendwie geholfen!

Ich habe auf Ihren Kommentar "Datenverlust könnte rechtliche Konsequenzen haben" hingewiesen.

Dann möchten Sie auf jeden Fall ein leistungsstarkes Drittanbieter-Tool (wie DPM) haben, das Backups (und die blitzschnelle Wiederherstellung nach Katastrophenereignissen mit minimalem Aufwand) schneller und besser als jedes Skript, das Sie aus dem Internet ziehen können, ausführen kann.

Backups zu haben ist eine Sache. Zu wissen, wie man sie im Notfall benutzt, ist eine andere.

Vergessen Sie nicht, dass Sie, wenn Sie im Begriff sind, nach einem schwerwiegenden Ausfall ein Backup wiederherzustellen, wahrscheinlich bereits eine Menge Stress und Druck haben. Sie müssen nicht zusätzlich die Last aufbringen, die RESTORE DATABASE-Anweisung mit 12 Transaktionsprotokolldateien fehlerfrei auszulesen und aufzuschreiben.

An meinem Arbeitsplatz kann ich mit DPM eine 350-Gb-Datenbank innerhalb von 5 Minuten für die letzte Woche an einem beliebigen Punkt wiederherstellen. Mit einer GUI-Oberfläche. Es lohnt sich, in meinem Buch.

Schauen Sie sich im Übrigen unbedingt das Index-Skript von Ola Hallengren an und passen Sie die Parameter an Ihre Bedürfnisse an. Persönlich habe ich es mit einer geplanten Aufgabe verknüpft, die es jede Nacht eine Stunde lang ohne erneute Überprüfung laufen lässt, damit es jedes Mal die schlechtesten Indizes verarbeitet und jeden Samstag oder wenn alle Indizes in der Liste vorhanden sind, eine vollständige erneute Überprüfung der Fragmentierung erzwingt wurden defragmentiert.

Zuletzt füge ich meine Stimme der Gruppe "Verkleinere deine Dateien nie automatisch" hinzu. File Shrink ist nur ein Tool, das Sie sporadisch verwenden können, wenn ein unregelmäßiges Ereignis auftritt, das Ihre Protokolle oder DB-Dateien (Endlosschleife oder ähnliches) überschwemmt. Es soll kein Wartungswerkzeug sein. Wenn Sie Speicherplatzdruck haben, verzögert das Schrumpfen nur das Unvermeidliche.