it-swarm.com.de

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

Ich suche nach praktisch Anleitungen zum Festlegen der Werte für BUFFERCOUNT, BLOCKSIZE und MAXTRANSFERSIZE des BACKUP Befehl. Ich habe ein bisschen recherchiert (siehe unten), ich habe ein bisschen getestet und mir ist völlig bewusst, dass jede wirklich wertvolle Antwort mit "Nun, es kommt darauf an ..." beginnt. Meine Bedenken hinsichtlich der von mir durchgeführten Tests und der in einer der gefundenen Ressourcen gezeigten Tests (siehe unten) sind, 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 für diese drei Optionen, die auf langjähriger Erfahrung beruhen: viele Datenpunkte über Wochen oder Monate. Und ich suche nicht nach bestimmten Werten, da dies hauptsächlich eine Funktion der verfügbaren Hardware ist, aber ich würde gerne wissen:

  • Wie verschiedene Hardware-/Lastfaktoren beeinflussen, was zu tun ist.
  • Gibt es Umstände, unter denen keiner dieser Werte überschrieben werden sollte?
  • Gibt es Fallstricke, um diese zu überschreiben, die nicht sofort offensichtlich sind? Zu viel Speicher und/oder Festplatten-E/A verbrauchen? Wiederherstellungsvorgänge erschweren?
  • 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 festlege, ohne sicherzustellen, dass das Kollektiv (BUFFERCOUNT * MAXTRANSFERSIZE) überschreitet nicht den verfügbaren RAM? Möglicher E/A-Konflikt?
  • Wie würde sich in demselben Szenario, in dem die drei Instanzen auf einem Server vorhanden sind und die Sicherungen erneut auf allen drei gleichzeitig ausgeführt werden, auf die Einstellung dieser Werte auswirken, wenn auch die Sicherungen für mehrere Datenbanken gleichzeitig in jeder Instanz ausgeführt werden? Das heißt, wenn jede der drei Instanzen jeweils 100 Datenbanken hat, 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 eher viele kleine bis mittlere Datenbanken als einige 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) Byte. [1]
    • Der Standardwert ist 65536 für Bandgeräte und ansonsten 512 [1]
    • Wenn Sie ein Backup erstellen, das Sie auf eine CD-ROM kopieren und von dieser wiederherstellen möchten, geben Sie BLOCKSIZE = 2048 an [1]
    • Wenn Sie auf einzelne Festplatten schreiben, ist der Standardwert von 512 in Ordnung. Wenn Sie RAID-Arrays oder SAN verwenden, müssen Sie testen, ob der Standardwert oder 65536 besser ist. [13 (Seite 18)]
    • Bei manueller Einstellung muss der Wert> = die Blockgröße sein, die zum Erstellen der Datendatei (en) verwendet wird. Andernfalls wird die folgende Fehlermeldung angezeigt:

      Nachricht 3272, Ebene 16, Status 0, Zeile 3
      Das Gerät 'C:\Programme\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\BackupTest.bak' hat eine Hardware-Sektorgröße von 4096, der Parameter Blockgröße gibt jedoch einen inkompatiblen Überschreibungswert von 512 an Geben Sie die Anweisung mit einer kompatiblen Blockgröße erneut aus.

  • BUFFERCOUNT:

    • Standard [2], [8]::

      SQL Server 2005 und spätere Versionen:
      (NumberofBackupDevices * [secret_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

    • [secret_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 3 Ist, wurden unter SQL Server 2005 SP2 durchgeführt [9].

      Meine Tests unter SQL Server 2008 R2 und 2012 sowie ein Benutzerkommentar zu SQL Server 2014 [8]Zeigen Sie den Multiplikator als 4. Bedeutet angesichts des angegebenen Werts für GetSuggestedIoDepth (direkt darunter) entweder:

      • GetSuggestedIoDepth ist jetzt 4 oder
      • der Multiplikator ist jetzt GetSuggestedIoDepth + 1
    • GetSuggestedIoDepth gibt 3 für DISK-Geräte zurück [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) bis zu 4194304 Bytes (4 MB). [1]
    • Standardwerte: Wenn sich das Gerät im Lesemodus befindet (Wiederherstellung) oder es sich um eine Desktop- oder Express Edition handelt, verwenden Sie 64 KB, andernfalls 1 MB. [9]
  • Allgemein/Verschiedenes:
    • Die maximale Größe, die verwendet werden kann, ist die ( Pufferpools To Physical Memory/16 ). Wie vom API-Aufruf GlobalMemoryStatusEx (ullTotalPhys) zurückgegeben. [9]
    • Das Trace-Flag 3213 Gibt Sicherungs-/Wiederherstellungskonfigurationsparameter aus, während Sicherungs-/Wiederherstellungsvorgänge ausgeführt werden, und 3605 Gibt die Ausgabe an das Fehlerprotokoll [~ # ~] [~ # ~] Datei: DBCC TRACEON (3213, 3605, -1);
    • Sie können DISK = N'NUL:' (DOS/Windows-Äquivalent von /dev/null Unter UNIX) verwenden, um das Testen einiger Metriken zu vereinfachen (Sie erhalten jedoch keinen guten Überblick über die Gesamtprozesszeit, da das Schreiben I übersprungen wird /Ö)

Ressourcen

  1. MSDN-Seite für den Befehl T-SQL [~ # ~] backup [~ # ~]
  2. KB904804: Beim Sichern der Datenbank in SQL Server 2000 tritt eine langsame 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 Sicherung der SQL-Datenbank mithilfe von Komprimierung und Solid State Disks
  8. Eine falsche BufferCount-Datenübertragungsoption kann zu einer OOM-Bedingung führen
  9. Funktionsweise: Wie wählt SQL Server Backup and Restore Übertragungsgrößen aus
  10. Funktionsweise: SQL Server Backup Buffer Exchange (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);

[~ # ~] Update [~ # ~]

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

Ich arbeite für einen Client, der eine 24/7/365.25 SaaS - Anwendung bereitstellt. Es besteht also die Möglichkeit, dass Benutzer zu jedem Zeitpunkt aktiv sind. Realistisch gesehen sind die Benutzer (vorerst) alle in den USA ansässig und arbeiten meistens "Standard" -Stunden: 7.00 Uhr pazifischer Zeit (dh 10.00 Uhr östlicher Zeit) bis 7.00 Uhr PM Pazifik (dh 10 PM Ost), aber 7 Tage die Woche, nicht nur Montag - Freitag, obwohl die Wochenendlast etwas geringer ist.

Sie sind so eingerichtet, dass jeder Client seine eigene Datenbank hat. Es ist eine Nischenbranche, daher gibt es nicht Zehntausende (oder mehr) potenzieller 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 über 1 GB. Daher versuche ich nicht speziell, die Leistung einer VLDB zu maximieren.

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

Das Setup besteht nun darin, an einem Tag pro Woche eine vollständige Sicherung und an den anderen Tagen DIFF-Sicherungen durchzuführen. LOG-Backups werden alle 10 Minuten erstellt. Ich verwende die Standardwerte für die 3 Optionen, nach denen ich hier frage. Da ich jedoch wusste, wie sie eingestellt wurden, wollte ich sicherstellen, dass ich eine Optimierung nicht rückgängig machte (nur weil das alte System einige schwerwiegende Fehler aufwies, heißt das nicht, dass alles falsch war ). Derzeit dauert es für die 206 Datenbanken etwa 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 der vollständigen und 20 am letzten Tag zuvor) das nächste VOLL). Und das führt sie nacheinander aus (einzelner Thread). Insgesamt dauert der LOG-Sicherungsprozess (alle DBs auf allen 3 Instanzen) jedes Mal zwischen 50 und 90 Sekunden (wiederum alle 10 Minuten).

Mir ist klar, dass ich mehrere Dateien pro Datenbank ausführen kann, aber a) ich bin nicht sicher, wie viel besser das Multithreading und die kleine bis mittlere Größe der DBs sein wird, und b) ich möchte den Wiederherstellungsprozess nicht komplizieren ( 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 integrierte Komprimierung irgendwie blöd ist. Ein Teil des alten Prozesses bestand darin, jede Datei in eine RAR zu komprimieren. Ich habe meine eigenen Tests durchgeführt und festgestellt, dass die RAR-Version zumindest 50% kleiner ist als die nativ komprimierte Version. Ich habe versucht, zuerst die native Komprimierung zu verwenden, um die Dateien zu beschleunigen und dann zu rarchen, aber diese Dateien waren zwar kleiner als die lediglich nativ komprimierten, aber immer noch etwas größer als die nur RAR-komprimierte Version und um einen ausreichenden Unterschied zu rechtfertigen keine native Komprimierung verwenden. Der Prozess zum Komprimieren der Sicherungen ist asynchron und wird alle X Minuten ausgeführt. Wenn eine .bak - oder .trn - Datei gefunden wird, wird sie komprimiert. Auf diese Weise wird der Sicherungsprozess nicht durch die Zeit verlangsamt, die zum Komprimieren jeder Datei erforderlich ist.

34
Solomon Rutzky

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

Nur ein paar Dinge, die mir sofort auffallen:

  • Wie verschiedene Hardware-/Lastfaktoren beeinflussen, 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 ihn in Produktion nehmen? Wenn Sie über eine Menge Hardware-Headroom (CPU/RAM) verfügen und die Sicherung in kürzester Zeit von größter Bedeutung ist, sollten Sie diese Parameter für die jeweilige Hardware optimieren, um dieses Ziel zu erreichen. Wenn Sie sicherstellen möchten, dass OLTP Workloads rund um die Uhr gewartet werden und die Sicherung keine Auswirkungen darauf hat, müssen Sie diese Parameter wahrscheinlich umgekehrt anpassen. Sie haben dies nicht getan Sie haben Ihre Entwurfsziele identifiziert, da Sie jedoch um allgemeine Anleitung bitten, da Sie so klug sagen, dass es darauf ankommt.

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

Sie möchten die Standardeinstellungen beibehalten, wenn Sie Bedenken hinsichtlich der späteren Unterstützbarkeit haben, nachdem Sie die Instanz nicht mehr gewartet haben, und sich über die Fähigkeiten Ihres Ersatzes nicht sicher sind. Sie möchten wahrscheinlich die Standardeinstellungen beibehalten, es sei denn, Sie müssen sie speziell anpassen. Lass schlafende Hunde liegen, wie sie sagen.

  • Gibt es Fallstricke, um diese zu überschreiben, die nicht sofort offensichtlich sind? Zu viel Speicher und/oder Festplatten-E/A verbrauchen? Wiederherstellungsvorgänge erschweren?

Wie in den Dokumenten, auf die Sie verweisen, eindeutig angegeben ist, kann eine zu starke Erhöhung dieser Parameter sicherlich negative Auswirkungen auf die Verfügbarkeit haben. 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 festlege, ohne sicherzustellen, dass das Kollektiv (BUFFERCOUNT) vorhanden ist * MAXTRANSFERSIZE) überschreitet nicht den verfügbaren RAM? Möglicher E/A-Konflikt?

Sie sollten sicherstellen, dass Sie genügend RAM für unvorhergesehene Umstände) lassen. Ich würde mir sicherlich Sorgen machen, mehr als 60% oder 70% des verfügbaren RAMs zu verwenden für Sicherungsvorgänge , es sei denn, ich wusste mit 100% iger Sicherheit, dass während des Sicherungsfensters nie etwas anderes passieren würde.

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


dies ist vielleicht 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."

12
Max Vernon