Wie berechnet SQL Server die Anfangsgröße einer (komprimierten) Sicherung?

Wenn eine Sicherung erstellt wird, errät SQL Server (?) Die Größe der ersten Sicherungsdatei. Später, möglicherweise beim Anhängen des Protokolls, wird die Größe angepasst, manchmal mehrmals, bis die endgültige Größe erreicht ist. Je größer der Unterschied, desto länger dauert die Sicherung. (Im Vergleich zu einem anderen Backup, dessen Größe später nicht mehr so ​​angepasst wird). Beispiel: Datenbank1 (Größe 500 GB, verwendetes 70 GB-Protokoll) wird durch Komprimierung gesichert. Die .bak-Datei wird mit einer Größe von 85 GB erstellt. Nach einiger Zeit steigt die CPU-Auslastung und ich kann sehen, dass die .bak-Datei auf 136 GB angepasst wird. Dies geschieht erneut, bis die endgültige Größe von 178 GB für die Sicherung erreicht ist erreicht.

Wenn diese Neuberechnungen durchgeführt werden, verringert sich die durchschnittliche Sicherungsgeschwindigkeit in MB / s im Vergleich zu anderen Sicherungen auf demselben Computer. Kommt das nur vom Anhängen und Löschen des Protokolls? Oder liegt es auch an den unterschiedlichen Datentypen, die in der Datenbank verwendet werden? Bedeutet das, dass sie mit unterschiedlichen Komprimierungsraten komprimiert werden oder so?

Ich kam zum Thema, weil ich wusste, dass meine Backups ungefähr 30 Minuten dauern, aber jetzt dauerte es 1,5 Stunden, obwohl die Datenbank nicht auf 300% ihrer Größe angewachsen war. Es wuchs nur 30%.

Anhand von Wartestatistiken konnte ich sehen, dass ich neben BackupIO irgendwann auch auf die CPU (SOS_SCHEDULER_YIELD) wartete.

Machine Details:
VMWare 6.0 
32 GB of Memory (Max memory 28GB given to SQL Server)
2 logical CPU
Max Degree of Parallelism (1, it's a Sharepoint 2013)   
SQL Server 2014
Windows Server 2012 R2
running on an SSD Raid (5)

Natürlich habe ich die sofortige Dateiinitialisierung für den Benutzer aktiviert, der die Sicherung ausführt.

Wie berechnet SQL Server die Anfangsgröße einer (komprimierten) Sicherung?

Von BOL :

Bei komprimierten Sicherungen hängt die Größe der endgültigen Sicherungsdatei davon ab, wie komprimierbar die Daten sind. Dies ist vor Abschluss des Sicherungsvorgangs nicht bekannt. Daher verwendet das Datenbankmodul beim Sichern einer Datenbank mithilfe der Komprimierung standardmäßig a pre-allocation algorithmfür die Sicherungsdatei. Dieser Algorithmus weist der Sicherungsdatei einen vordefinierten Prozentsatz der Datenbankgröße zu. Wenn während des Sicherungsvorgangs mehr Speicherplatz benötigt wird, vergrößert das Datenbankmodul die Datei. Wenn die endgültige Größe kleiner als der zugewiesene Speicherplatz ist, verkleinert das Datenbankmodul die Datei am Ende des Sicherungsvorgangs auf die tatsächliche endgültige Größe der Sicherung.

Verwenden Sie das Ablaufverfolgungsflag 3042, damit die Sicherungsdatei nur nach Bedarf wächst, um ihre endgültige Größe zu erreichen. Das Ablaufverfolgungsflag 3042 bewirkt, dass der Sicherungsvorgang den Standardalgorithmus für die Sicherungskomprimierung vor der Zuweisung umgeht.

Sie sollten Folgendes befolgen: - Best Practices in SharePoint 2013 sichern und wiederherstellen .

Außerdem scheint mir Ihre VM mit 2 CPUs für die Ausführung einer 70-GB-Datenbank nicht ausreichend zu sein (nicht sicher, ob es nur eine Datenbank oder mehrere Datenbanken gibt).