Wie viele Sicherungsgeräte werden empfohlen, um die Sicherungsleistung zu verbessern?

Um die Leistung unserer SQL Server-Sicherungen zu verbessern, sichern wir in mehreren Sicherungsdateien.

In den meisten Blog-Posts zu diesem Thema wird angegeben, dass mehrere Sicherungsdateien verwendet werden sollen. Gibt es jedoch einen Punkt, an dem Sie zu viele Dateien haben können, sodass Sie aufgrund der großen Anzahl wartender Threads eine schlechtere Leistung erzielen, anstatt die Leistung zu verbessern?
Gibt es eine allgemeine Empfehlung, die beispielsweise auf der Anzahl der Kerne im Server basiert? Um genauer zu sein, zeigt einer unserer Server BACKUPIOund BACKUPBUFFERals Top-2-Täter warten Statistiken.

Wir sichern eine große Datenbank (mehrere TBs) mit 10 Sicherungsdateien, aber ich habe festgestellt, dass der Server nur 4 Kerne und 32 GB RAM hat. Ich habe die Anzahl der Sicherungsdateien geändert, um stattdessen 4 Sicherungsdateien zu verwenden. Ich werde sehen, wie es nächste Woche im nächsten Sicherungszyklus läuft, aber in der Zwischenzeit habe ich versucht, Empfehlungen zu finden, wie viele Sicherungsdateien abhängig von den Serverspezifikationen verwendet werden sollen.

sql-server backup

— Victor Barajas
quelle

Antworten:

Lassen Sie uns zuerst Ihre Fragen beantworten ...

Gibt es einen Punkt, an dem Sie zu viele Dateien haben können, sodass Sie aufgrund der großen Anzahl wartender Threads nicht die Leistung verbessern, sondern die schlechteste Leistung erzielen?

Die Anzahl der Sicherungsthreads hängt von der Anzahl der für die Datenbankdateien verwendeten logischen Datenträger und der Anzahl der Sicherungsgeräte ab. SQL Server unterstützt maximal 64 Sicherungsgeräte für einen einzelnen Sicherungsvorgang.

Wenn Sie also Ihre Backups streifen, erhöhen Sie den Durchsatz. Das ist ein guter Schachzug.

Gibt es eine allgemeine Empfehlung, die beispielsweise auf der Anzahl der Kerne im Server basiert?

Ein Beispiel für ausgeglichene Dateien und Datenträger für eine gute Sicherungsleistung finden Sie im Whitepaper zur Sicherungsoptimierung (Achtung: Es handelt sich um ein Word-Dokument) .

Dinge, die man beachten muss :

Aktivieren Sie die sofortige Initialisierung von Dateien.
Verwenden Sie die Sicherungskomprimierung (SQL Server 2008 R2 und höher verfügt über eine Sicherungskomprimierung in der Standard Edition). Durch die Komprimierung wird die CPU-Auslastung erhöht. Stellen Sie daher sicher, dass Sie keine CPU-Sättigung haben.
Ändern / Anpassen Ihrer Sicherungsstrategie. Anstatt täglich eine vollständige Sicherung einer Multi-Terabyte-Datenbank durchzuführen, sollten Sie auch eine differenzielle Sicherung zusammen mit Protokollsicherungen durchführen.
Spielen Sie in einer Testumgebung mit BUFFERCOUNT(Gesamtzahl der E / A-Puffer) und MAXTRANSFERSIZE(größte Übertragungseinheit in Bytes zwischen SQL Server und Sicherungsmedien) Sicherungsparametern zusammen mit den Ablaufverfolgungsflags 3605 und 3213.
Siehe meine Antwort SQL Backup Optimieren großer Datenbanken

Freundliche Beratung

Ich habe festgestellt, dass der Server nur 4 Kerne und 32 GB RAM hat.

Da Sie eine große Datenbank (mehrere TBs) verwenden, klingen 4 Kerne und 32 GB RAM sehr niedrig. Erhöhen Sie Ihre Hardware.

Verweisen :

— Kin Shah
quelle

Die Daten dieser Tabelle sind veraltet. 2 CPU-Kerne pro Datendatei sind auf heutigen Systemen sicherlich nicht ausgeglichen. Im Allgemeinen kann diese Aussage auch nicht wahr sein, da sie von der Festplatten- und CPU-Geschwindigkeit abhängt. Die Zahlen in der Tabelle fühlen sich so falsch an, dass ich denke, dass es irreführend ist.

— usr

Hängt auch von der Backup-Komprimierung ab. Ohne sie kann ein einzelner Kern wahrscheinlich 2 GB / s sichern. Diese Zahlen variieren daher um eine Größenordnung.

— usr

@usr Die Tabellendaten sind nur eine allgemeine Empfehlung gemäß dem Whitepaper (unter Bezugnahme auf SQL Server 2008). Sie sind nicht einfach falsch und sollten als guter Ausgangspunkt verwendet werden. Die Tabelle besagt, dass ein guter Ausgangspunkt sein sollte, z. B. für ein 2-Kern-System, es sollten 2 Datendateien und 2 Sicherungsdateien vorhanden sein ... was ist daran falsch? Backup kann schneller gemacht werden kitzeln mit buffercountund maxtransfersizeund Striping sie.

— Kin Shah

Als allgemeine Empfehlung sind diese Zahlen schrecklich, weil die wahren Zahlen um eine Größenordnung abweichen können. Was daran falsch ist, beziehe ich mich auf meine Antwort, die erklärt, warum solche allgemeinen Zahlen nicht existieren können .

— usr

Ich denke, es ist ein viel produktiverer Ansatz, die zugrunde liegenden Regeln zu verstehen und zu verstehen, warum bestimmte Zahlen gut sind. Auf diese Weise können Sie häufig anhand der Umschlagberechnungen vorhersagen, wie die richtigen Einstellungen aussehen werden. Alternativ können Sie auch einige Zahlen ausprobieren und messen. Das Kopieren von Zahlen aus einem anderen völlig anderen System ohne Verständnis der Grundlagen ist jedoch ziemlich unzuverlässig.

— usr

Um die Leistung unserer SQL Server-Sicherungen zu verbessern, sichern wir in mehreren Sicherungsdateien

Nicht generell nein. Das ist eine spezielle Technik, die helfen kann .

große Menge von Threads warten

Warum würde dies zu einem Durchsatzverlust führen? Threads sind normalerweise eine umfangreiche Ressource. In bestimmten Konfigurationen treten Probleme auf, bei denen Sie Hunderte und Tausende von Threads durchbrennen.

basierend auf der Anzahl der Kerne im Server

Das wäre sinnvoll, wenn der Sicherungsvorgang CPU-gebunden wäre. Das könnte der Fall sein. Solange es E / A-gebunden ist, kann es nicht helfen, die Anzahl der Kerne mit einer Einstellung zu bestimmen.

Einer unserer Server zeigt BACKUPIO und BACKUPBUFFER als Wartestatistiken der Top-2-Täter an

Dies deutet auf einen E / A-gebundenen Sicherungsprozess hin. Nach meiner Erfahrung ist das weitaus häufiger als die CPU-Begrenzung.

eine große DB (mehrere TBs)

Die Größe der Sicherung spielt bei Durchsatzüberlegungen keine Rolle. Der Durchsatz ist die Leistung pro Zeiteinheit.

Das bloße Vorhandensein wartender Threads wirkt sich normalerweise nicht auf andere Threads und Vorgänge auf dem Server aus. Wartende Threads machen nichts.

Daher habe ich die Anzahl der Sicherungsdateien geändert, um stattdessen 4 Sicherungsdateien zu verwenden

Das war unbegründet, da das Backup IO-gebunden ist. Das Zielen auf die Anzahl der Kerne ist kein gutes Ziel.

Wenn Sie 128 CPU-Kerne hinzufügen, wird Ihre Sicherung nicht eine Sekunde schneller.

Möglicherweise haben Sie die Leistung erhöht, aber nur aus Versehen.

Wie viele Sicherungsdateien verwendet werden sollen, hängt von vielen Faktoren ab. Eine einfache Möglichkeit, eine gute Zahl zu finden, besteht darin, einfach verschiedene Werte zu testen, einschließlich 1 (der wahrscheinlichste Wert für gängige Systeme).

— usr
quelle