Festlegen von BUFFERCOUNT, BLOCKSIZE und MAXTRANSFERSIZE für den Befehl BACKUP

Ich suche praktische Anleitung für die Werte für die Einstellung BUFFERCOUNT, BLOCKSIZEund MAXTRANSFERSIZEdes BACKUPBefehls. Ich habe ein bisschen recherchiert (siehe unten), ein bisschen getestet und mir ist klar, dass jede wirklich wertvolle Antwort mit "Nun, es kommt darauf an ..." beginnt. Meine Bedenken hinsichtlich der Tests, die ich durchgeführt habe, und der Tests, die in den von mir gefundenen Ressourcen gezeigt wurden (siehe unten), bestehen darin, dass die Tests in einem Vakuum durchgeführt werden, höchstwahrscheinlich auf einem System ohne andere Last.

Ich bin gespannt auf die richtigen Anleitungen / Best Practices in Bezug auf diese drei Optionen, die auf langjährigen Erfahrungen beruhen: viele Datenpunkte über Wochen oder Monate. Und ich suche keine spezifischen Werte, da dies hauptsächlich eine Funktion der verfügbaren Hardware ist, aber ich würde gerne wissen:

• Wie verschiedene Hardware- / Lastfaktoren Einfluss darauf haben, was zu tun ist.
• Gibt es Umstände, unter denen keiner dieser Werte überschrieben werden sollte?
• Gibt es Fallstricke für das Überschreiben von diesen, die nicht sofort offensichtlich sind? Verbrauchen Sie zu viel Speicher und / oder Festplatten-E / A? Komplizierte Wiederherstellungsvorgänge?
• Wenn auf einem Server mehrere Instanzen von SQL Server ausgeführt werden (eine Standardinstanz und zwei benannte Instanzen) und die Sicherungen aller drei Instanzen gleichzeitig ausgeführt werden, wirkt sich dies darauf aus, wie ich diese Werte einstelle, ohne sicherzustellen, dass das Kollektiv ( BUFFERCOUNT* MAXTRANSFERSIZE) überschreitet nicht den verfügbaren Arbeitsspeicher? Mögliche E / A-Konflikte?
• Wie würde sich das gleichzeitige Ausführen der Sicherungen für mehrere Datenbanken in jeder Instanz auf die Einstellung dieser Werte auswirken, wenn Sie die drei Instanzen auf einem Server haben und die Sicherungen erneut für alle drei gleichzeitig ausführen? Das heißt, wenn jede der drei Instanzen über 100 Datenbanken verfügt, werden 2 oder 3 Sicherungen pro Instanz gleichzeitig ausgeführt, sodass zwischen 6 und 9 Sicherungen gleichzeitig ausgeführt werden. (In dieser Situation habe ich viele kleine bis mittlere Datenbanken und nicht wenige große.)

Was ich bisher gesammelt habe:

• BLOCKSIZE:

  • Die unterstützten Größen sind 512, 1024, 2048, 4096, 8192, 16384, 32768 und 65536 (64 KB) Bytes. ^[1]
  • Der Standardwert ist 65536 für Bandgeräte und 512 ansonsten ^[1].
  • Wenn Sie ein Backup erstellen, das Sie von einer CD-ROM kopieren und wiederherstellen möchten, geben Sie BLOCKSIZE = 2048 ^{[1] an.}
  • Wenn Sie auf einzelne Datenträger schreiben, ist der Standardwert von 512 in Ordnung. Wenn Sie RAID-Arrays oder SAN verwenden, müssen Sie testen, ob die Standardeinstellung oder 65536 besser ist. ^{[13 (Seite 18)]}

  • Bei manueller Einstellung muss der Wert> = die zum Erstellen der Datendatei (en) verwendete Blockgröße sein. Andernfalls wird der folgende Fehler angezeigt:

    Meldung 3272, Ebene 16,
    Status 0, Zeile 3 Das Gerät "C: \ Programme \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak" hat eine Hardwaresektorgröße von 4096, der Parameter block size gibt dies jedoch an Ein inkompatibler Überschreibungswert von 512. Die Anweisung mit einer kompatiblen Blockgröße erneut ausgeben.

• BUFFERCOUNT:

  • Standard ^{[2], [8]} :

    SQL Server 2005 und
    höhere Versionen: (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mystery_multiplier]: Es gibt einige Inkonsistenzen in Bezug auf diesen Wert. Ich habe es in 3 Formen ausgedrückt gesehen:

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    Tests, die zeigen, dass der Multiplikator unter 3SQL Server 2005 SP2 durchgeführt wurde ^[9] .

    Meine Tests unter SQL Server 2008 R2 und 2012 sowie ein Benutzerkommentar zu SQL Server 2014 ^[8] zeigen, dass dies ein Multiplikator ist 4. Das heißt, wenn der gemeldete Wert für GetSuggestedIoDepth(direkt darunter) angegeben wird, entweder:

    • GetSuggestedIoDepthist jetzt 4oder
    • Der Multiplikator ist jetzt GetSuggestedIoDepth + 1
  • GetSuggestedIoDepthRetoure 3für DISK-Geräte ^[9]
  • Kein fest eingestellter Maximalwert, aber angesichts des erforderlichen Speichers = ( BUFFERCOUNT* MAXTRANSFERSIZE) scheint ein praktischer Maximalwert zu sein: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • Die möglichen Werte sind Vielfache von 65536 Bytes (64 KB) und reichen bis zu 4194304 Bytes (4 MB). ^[1]
  • Standardwerte: Wenn sich das Gerät im Lesemodus (Wiederherstellen) befindet oder es sich um eine Desktop- oder Express-Edition handelt, verwenden Sie 64 KB, andernfalls 1 MB. ^[9]
• Allgemeines / Sonstiges:
  • Die maximale Größe, die verwendet werden kann, ist die ( Buffer Pools To Physical Memory / 16 ). Wie vom GlobalMemoryStatusEx (ullTotalPhys) API-Aufruf zurückgegeben. ^[9]
  • Das Trace-Flag 3213gibt die Konfigurationsparameter für die Sicherung / Wiederherstellung aus, während die Sicherungs- / Wiederherstellungsvorgänge ausgeführt werden, und gibt einen Speicherauszug3605 in die ERRORLOG- Datei aus:DBCC TRACEON (3213, 3605, -1);
  • Sie können DISK = N'NUL:'(DOS / Windows-Äquivalent zu /dev/nullUNIX) zum einfacheren Testen einiger Metriken verwenden (erhalten jedoch kein gutes Gefühl für die Gesamtprozesszeit, da die Schreib-E / A übersprungen wird).

Ressourcen

1. MSDN-Seite für den T-SQL- Befehl BACKUP
2. KB904804: Beim Sichern der Datenbank in SQL Server 2000 tritt eine geringe Leistung auf
3. Optionen zur Verbesserung der SQL Server-Sicherungsleistung
4. Sichern und Wiederherstellen
5. Optimieren der Sicherung und Wiederherstellung von SQL Server
6. Optimieren der Sicherungsleistung
7. So erhöhen Sie die Geschwindigkeit der vollständigen SQL-Datenbanksicherung mithilfe von Komprimierung und Solid State Disks
8. Eine falsche BufferCount-Datenübertragungsoption kann zu einem OOM-Zustand führen
9. Funktionsweise: Wie wählt SQL Server Backup and Restore Übertragungsgrößen aus?
10. Funktionsweise: SQL Server-Sicherungspufferaustausch (ein VDI-Fokus)
11. SQL Backup optimiert große Datenbanken
12. SQL Server-Speicher für Sicherungspuffer
13. Eine Fallstudie: Schnelle und zuverlässige Sicherung und Wiederherstellung einer VLDB über das Netzwerk (DOCX-Datei)
14. Wie viele Sicherungsgeräte werden empfohlen, um die Sicherungsleistung zu verbessern?

Ich habe getestet mit:

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

AKTUALISIEREN

Es scheint, dass ich manchmal vergesse, einige der Informationen hinzuzufügen, die ich immer von anderen erbitte, wenn ich eine Frage beantworte ;-). Ich habe oben einige Informationen zu meiner aktuellen Situation gegeben, kann aber weitere Details angeben:

Ich arbeite für einen Kunden, der eine SaaS-Anwendung rund um die Uhr zur Verfügung stellt. Es besteht also die Möglichkeit, dass Benutzer zu jedem Zeitpunkt eingeschaltet sind. Realistisch gesehen sind die Benutzer jedoch alle in den USA ansässig und arbeiten in der Regel "Standard" -Stunden: 7.00 Uhr pazifischer Zeit (dh 10.00 Uhr östlicher Zeit) bis 19.00 Uhr pazifischer Zeit (dh 22 Uhr Ost), aber 7 Tage die Woche, nicht nur Montag - Freitag, obwohl die Wochenendauslastung etwas geringer ist.

Sie sind so eingerichtet, dass jeder Mandant einen eigenen DB hat. Da es sich um eine Nischenbranche handelt, gibt es nicht Zehntausende (oder mehr) potenzielle Kunden. Die Anzahl der Client-DBs variiert pro Instanz, wobei die größte Instanz 206 Clients enthält. Die größte DB ist ca. 8 GB, aber nur etwa 30 DBs sind mehr als 1 GB. Daher versuche ich nicht speziell, die Leistung einer VLDB zu maximieren.

Als ich mit diesem Client anfing, waren die Sicherungen immer einmal täglich VOLL und keine LOG-Sicherungen. Sie hatten auch MAXTRANSFERSIZE auf 4 MB und BUFFERCOUNT auf 50 festgelegt. Ich ersetzte dieses Setup durch eine leicht angepasste Version des Datenbanksicherungsskripts von Ola Hallengren . Der leicht angepasste Teil ist, dass es von einem Multithreading-Tool ausgeführt wird (das ich geschrieben habe und das hoffentlich bald verkaufen wird), das DBs dynamisch erkennt, wenn es mit jeder Instanz verbunden wird, und das Drosseln pro Instanz ermöglicht (daher führe ich derzeit das aus) drei Instanzen gleichzeitig, aber die DBs für jede Instanz nacheinander, da ich mir nicht sicher war, welche Auswirkungen es hat, sie gleichzeitig auszuführen).

Das Setup besteht nun aus einer vollständigen Sicherung an einem Tag pro Woche und DIFF-Sicherungen an den anderen Tagen. LOG-Backups werden alle 10 Minuten erstellt. Ich verwende die Standardwerte für die drei Optionen, nach denen ich hier frage. Da ich wusste, wie sie eingestellt waren, wollte ich sicherstellen, dass ich eine Optimierung nicht rückgängig machte (nur weil das alte System einige schwerwiegende Mängel aufwies, heißt das noch lange nicht, dass alles funktioniertwar falsch). Derzeit dauert es für die 206 Datenbanken ungefähr 62 Minuten für vollständige Sicherungen (einmal pro Woche) und zwischen 7 und 20 Minuten für DIFF-Sicherungen an den verbleibenden Tagen (7 am ersten Tag nach dem vollständigen und 20 am letzten Tag vor dem vollständigen Backup) das nächste FULL). Und das läuft sie nacheinander (Einzelthread). Insgesamt dauert der LOG-Sicherungsvorgang (alle DBs auf allen 3 Instanzen) jedes Mal zwischen 50 und 90 Sekunden (erneut alle 10 Minuten).

Mir ist klar, dass ich mehrere Dateien pro DB ausführen kann, aber a) ich bin mir nicht sicher, um wie viel besser das Multithreading und die kleine bis mittlere Größe der DBs ist, und b) ich möchte den Wiederherstellungsprozess nicht verkomplizieren ( Es gibt verschiedene Gründe, warum der Umgang mit einer einzelnen Datei bevorzugt wird.

Mir ist auch klar, dass ich die Komprimierung aktivieren kann (meine Testabfrage hat sie absichtlich deaktiviert), und ich hatte dies dem Team empfohlen, aber ich wurde darauf aufmerksam gemacht, dass die eingebaute Komprimierung ein bisschen blöd ist. Ein Teil des alten Prozesses bestand darin, jede Datei in eine RAR zu komprimieren, und ich führte meine eigenen Tests durch und stellte fest, dass die RAR-Version mindestens 50% kleiner ist als die nativ komprimierte Version. Ich habe versucht, die native Komprimierung zuerst zu verwenden, um die Dinge zu beschleunigen und dann die Dateien mit RAR zu versehen, aber diese Dateien waren zwar kleiner als die nativ komprimierten, aber immer noch ein bisschen größer als die nur mit RAR komprimierte Version und rechtfertigten einen gewissen Unterschied keine native Komprimierung verwenden. Der Prozess zum Komprimieren der Sicherungen ist asynchron und wird alle X Minuten ausgeführt. Wenn es ein .bakoder findet.trnDatei, komprimiert es es. Auf diese Weise wird der Sicherungsvorgang nicht durch die Zeit verlangsamt, die zum Komprimieren der einzelnen Dateien erforderlich ist.

Sie haben eine Schiffsladung von Artikeln in Ihrer Frage angesprochen. Danke, dass du so gründlich bist!

Nur ein paar Dinge, die mir auffallen:

• Wie verschiedene Hardware- / Lastfaktoren Einfluss darauf haben, was zu tun ist.

Führen Sie eine 24x7-Instanz aus? Was ist die Last rund um die Uhr? Ich stelle fest, dass die Sicherungskomprimierung deaktiviert ist. Ist das beabsichtigt für den Test, oder ist es aus irgendeinem Grund wünschenswert, ihn auszuschalten, wenn Sie diesen Test in Betrieb nehmen? Wenn Sie über eine Menge Hardware-Headroom (CPU / RAM) verfügen und die Sicherung in kürzester Zeit durchführen möchten, sollten Sie diese Parameter an die jeweilige Hardware anpassen, die Sie für dieses Ziel verwenden. Wenn Sie sicherstellen möchten, dass OLTP-Workloads rund um die Uhr bedient werden und das Backup dies nicht beeinträchtigen soll, müssen Sie diese Parameter wahrscheinlich umgekehrt anpassen. Sie haben Ihre Entwurfsziele nicht identifiziert, da Sie nach allgemeiner Anleitung fragen, da Sie so weise angeben, dass es darauf ankommt.

• Gibt es Umstände, unter denen keiner dieser Werte überschrieben werden sollte?

Sie möchten die Standardeinstellungen beibehalten, wenn Sie sich später Gedanken über die Unterstützung machen, nachdem Sie die Instanz nicht mehr gewartet haben, und wenn Sie sich nicht sicher sind, ob Sie sie ersetzen können. Wahrscheinlich möchten Sie die Standardeinstellungen beibehalten, es sei denn, Sie müssen sie speziell anpassen. Lass schlafende Hunde lügen, wie sie sagen.

• Gibt es Fallstricke für das Überschreiben von diesen, die nicht sofort offensichtlich sind? Verbrauchen Sie zu viel Speicher und / oder Festplatten-E / A? Komplizierte Wiederherstellungsvorgänge?

Wie in den Dokumenten, auf die Sie verweisen, eindeutig angegeben ist, kann eine zu starke Erhöhung dieser Parameter die Betriebszeit negativ beeinflussen. Wie bei allen produktionsbasierten Dingen müssen Sie dies vor der Bereitstellung gründlich testen und die Einstellungen in Ruhe lassen, sofern dies nicht unbedingt erforderlich ist.

• Wenn auf einem Server mehrere Instanzen von SQL Server ausgeführt werden (eine Standardinstanz und zwei benannte Instanzen) und wenn ich die Sicherungen aller drei Instanzen gleichzeitig ausführe, wirkt sich dies darauf aus, wie ich diese Werte einstelle, ohne sicherzustellen, dass das Kollektiv (BUFFERCOUNT) aktiviert ist * MAXTRANSFERSIZE) überschreitet nicht den verfügbaren Arbeitsspeicher? Mögliche E / A-Konflikte?

Sie sollten sicherstellen, dass Sie für unvorhergesehene Umstände genügend RAM zur Verfügung haben. Ich wäre sicherlich besorgt darüber, mehr als 60% oder 70% des verfügbaren Arbeitsspeichers für Sicherungsvorgänge zu verwenden, es sei denn, ich hätte mit hundertprozentiger Sicherheit gewusst, dass während des Sicherungsfensters nie etwas anderes passieren würde.

Ich habe unter SQLServerScience.com einen Blog-Beitrag mit einem Code geschrieben, der zeigt, wie ich Leistungstests für Sicherungen durchführe

^{Dies ist möglicherweise nicht die beste Antwort, die ich je geschrieben habe, aber wie The Great One ™ einmal sagte: "Sie verpassen 100% der Aufnahmen, die Sie nicht machen."}