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

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

1. Vollständige tägliche Sicherung (täglich) - großartig, aber vergessen Sie nicht, nach einer vordefinierten Zeit nach Speicherplatz zu suchen und alte Dateien zu entfernen.
2. Sichern Sie ausgewählte Tabellen (stündlich) - Sie verstehen nicht, warum Sie dies benötigen, sondern sollten differenzielle Sicherungen durchführen. Wie sichern Sie nur bestimmte Tabellen: SSIS, Skripte, bcp? Planen Sie Diff-Sicherungen nicht zu oft ein, da Sie die Rolle der Protokollsicherungen stehlen.
3. Transaktionsprotokollsicherungen (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 in Bezug auf Ressourcen ziemlich egoistisch und scannen vollständige Datenbankdaten, sodass sie außerhalb der Geschäftszeiten geplant werden müssen.
5. Index neu organisieren (täglich) - nicht erzwingen, sondern nur bei Bedarf. Überprüfen Sie die Index-DMVs auf Fragmentierung und organisieren Sie sie nur nach Bedarf neu. Ich würde alle Index- und Statistikoperationen auf eine einzige wöchentliche Aufgabe verschieben.
6. Statistiken aktualisieren (täglich) - Siehe meine Antwort zu einer vorherigen 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 Paul Randals Artikel zum Verkleinern von Dateien.
8. Index neu erstellen (wöchentlich) - siehe 5.

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

10. Sie sollten auch eine Aufgabe hinzufügen, um Ihre Backups zu überprüfen - es gibt eine Version des RESTORE-Befehls (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. Daher müssen Sie die Systemdatenbanken in diesem Wartungsverfahren hinzufügen. 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 Ihrer Aufgabe!

Eine späte Antwort könnte aber für andere Leser von Nutzen sein.

Beachten Sie bitte, dass Sie viele Wartungs- oder Berichtsaufgaben erstellen können, die mit unsichtbaren Risiken verbunden sind.

Was würde passieren, wenn ein Laufwerk während der täglich durchgeführten differenziellen Sicherungen voll wird? Und was ist, wenn ein Indexwiederherstellungsjob ungewöhnlich lange ausgeführt wird? Wie wäre es, wenn ein Datenladevorgang zu umfangreichen Ressourcenkonflikten führt und den normalen Betrieb in die Knie zwingt? All dies sind geplante Ereignisse, können jedoch die Prozesse, die wir zu schützen versuchen, erheblich stören.

Überlegen 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. Beispiel: Sie können einfache Überprüfungen in Ihre Wartungsjobs 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 Ihren Aufgaben umgehen kann, und bei unzureichenden Ressourcen mit einem bedeutenden Fehler abbrechen.

1. Sieht gut aus

2. Hier können Sie möglicherweise von differenziellen Sicherungen profitieren. Schau sie dir sicher an

3. Sieht gut aus

4. Sieht gut aus

5. Wie bereits erwähnt, sind Datenbankverkleinerungen schlecht, da sie eine physische Fragmentierung Ihrer Daten und Protokolldateien verursachen und somit mehr zufällige IO-Lesevorgänge) verursachen.

5, 6 und 8: Siehe unten.

Diese gehen wirklich Hand in Hand, da Indizes auf aktuellen Statistiken beruhen und die Reihenfolge dieser Operationen ziemlich wichtig ist. Die Basismethode, die ich verwende und die zugegebenermaßen nicht für alle funktioniert, besteht darin, dass ich zwei Runden der Indexpflege durchführe. Zuerst mache ich die Clustered-Indizes und dann die Nonclustered-Indizes. Die Methode, die ich für beide verwende, ist die folgende. Wenn ein Index groß genug und fragmentiert genug ist (sys.dm_db_index_physical_stats), werde ich den Index neu erstellen (einschließlich einer Statistikaktualisierung mit vollständigem Scan). Wenn ein Index für eine Neuerstellung entweder zu klein oder für eine Neuerstellung nicht ausreichend fragmentiert ist (weniger als 100 Seiten und zwischen 5% und 15% Fragmentierung), führe ich zuerst eine Indexreorganisation durch. Ich werde dann ein Statistik-Update mit vollständigem Scan durchführen. Wenn der Index für keine dieser Indexpflegeteile ausreichend fragmentiert ist, werde ich die Statistik weiterhin mit einem vollständigen Scan aktualisieren.

Dies betrifft nun die Indexstatistik, vernachlässigt jedoch, die Spaltenstatistik zu ändern. Wöchentlich werde ich die Spaltenstatistik aktualisieren.

Ich hoffe das hat irgendwie geholfen!

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

Dann möchten Sie auf jeden Fall ein leistungsstarkes Tool von Drittanbietern (wie DPM) erhalten, das Backups (und die Wiederherstellung von Katastrophenereignissen blitzschnell und mit minimalem Aufwand) viel schneller und viel besser handhaben kann als jedes Skript, das Sie aus dem Internet abrufen können.

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

Vergessen Sie nicht, dass Sie wahrscheinlich bereits unter einer Menge Stress und Druck stehen, wenn Sie nach einem schwerwiegenden Fehler so weit sind, ein Backup wiederherzustellen. Sie müssen nicht zusätzlich die RESTORE DATABASE-Anweisung mit 12 Transaktionsprotokolldateien ausgraben und fehlerfrei schreiben ... und beten, dass Sie nicht scheitern ...

An meinem Arbeitsplatz kann ich mit DPM innerhalb von 5 Minuten innerhalb von 5 Minuten eine 350-GB-Datenbank wiederherstellen. Mit einer GUI-Oberfläche. Es lohnt sich, in meinem Buch.

Schauen Sie sich im Übrigen unbedingt das Indexskript von Ola Hallengren an und passen Sie die Parameter an Ihre Bedürfnisse an. Persönlich habe ich es mit einer geplanten Aufgabe gekoppelt, bei der es jede Nacht eine Stunde lang ohne erneuten Scan ausgeführt wird, sodass jedes Mal die schlechtesten Indizes verarbeitet werden und jeden Samstag oder wenn alle Indizes in der Liste einen vollständigen erneuten Scan der Fragmentierung erzwingen wurden defragmentiert.

Zuletzt füge ich meine Stimme der Gruppe "Verkleinern Sie Ihre Dateien niemals automatisch" hinzu. File Shrink ist nur ein Tool, das sporadisch verwendet werden kann, wenn ein unregelmäßiges Ereignis auftritt, das Ihre Protokolle oder DB-Dateien (Endlosschleife oder ähnliches) überwuchert. Es soll kein Wartungswerkzeug sein. Wenn Sie Speicherplatzdruck haben, verzögert das Verkleinern ohnehin nur das Unvermeidliche.