web-dev-qa-db-ja.com

SQL Serverは（圧縮された）バックアップの初期サイズをどのように計算しますか？

バックアップが作成されると、SQL Serverは最初のバックアップファイルのサイズを推測（？）します。後で、ログを追加するときに、サイズが再調整される場合があります。最終サイズに達するまで、場合によっては複数回再調整されます。差が大きいほど、バックアップに時間がかかります。 （後でサイズがそれほど調整されない別のバックアップと比較）。例：Database1（サイズ500GB、70 GBのログを使用）は圧縮してバックアップされます。 .bakファイルは85 GBのサイズで作成され、しばらくするとCPU使用率が上昇し、.bakファイルが136 GBに再調整されたことがわかります。これは、バックアップの最終的なサイズが178 GBになるまで、再び発生します。達した。

これらの再計算が行われると、平均バックアップ速度（MB /秒）が同じマシン上の他のバックアップと比較して低下します。ログの追加と消去のみが原因ですか？それとも、データベースで使用されるデータ型が異なるためですか？それらが異なる圧縮率、または何かで圧縮されていることを意味しますか？

このトピックにたどり着いたのは、バックアップに約30分かかることがわかっていたのですが、データベースのサイズが300％に達していなくても1.5時間かかりました。わずか30％の成長です。

待機統計を使用すると、BackupIOの他に、ある時点でCPU（SOS_SCHEDULER_YIELD）も待機していることがわかりました。

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)

もちろん、私はバックアップを実行するユーザーに対して、ファイルの即時初期化を有効にしています。

sql-serverperformancebackupcompressionwindows-server
7
RayofCommand

SQL Serverは（圧縮された）バックアップの初期サイズをどのように計算しますか？

BOLから ：

圧縮バックアップの場合、最終バックアップファイルのサイズはデータの圧縮率によって異なり、バックアップ操作が完了するまでは不明です。したがって、既定では、圧縮を使用してデータベースをバックアップする場合、データベースエンジンはpre-allocation algorithmバックアップファイル。このアルゴリズムは、データベースのサイズの事前定義された割合をバックアップファイルに事前に割り当てます。 バックアップ操作中にさらに領域が必要な場合、データベースエンジンはファイルを拡張します。最終サイズが割り当てられたスペースよりも小さい場合、バックアップ操作の最後に、データベースエンジンはファイルをバックアップの実際の最終サイズに縮小します。

最終サイズに到達するために必要な場合にのみバックアップファイルを拡張できるようにするには、トレースフラグ3042を使用します。トレースフラグ3042により、バックアップ操作はデフォルトをバイパスしますバックアップ圧縮の事前割り当てアルゴリズム。

従う必要があります- SharePoint 2013でのバックアップと復元のベストプラクティス 。

また、私にとってあなたのVM 2 CPUを持っていることは、70GBデータベースを実行するための仕様ではないようです（データベースが1つだけであるか複数のデータベースであるかはわかりません）。

5
Kin Shah