【SQL Server】バックアップの圧縮オプションを検証

SQL
スポンサーリンク

メンテナンスしているシステムのDB(SQLServer2012)が肥大化(200GB近い)してきたのでDBの圧縮オプションを入れたバックアップができないか検証して見ることにしました。

主なメリットとして以下があります。

  • バックアップ時間が短縮される。
  • データベースのバックアップ容量が少なく済む
  • データベースの移行時の時間短縮(移行データのコピー時間も少なくなる)

反対にデメリットとして

  • バックアップと圧縮を同時に行うのでCPUの負荷が高くなる。
  • 圧縮は取得後に行われるため、一時的に必要なDBがいまいちわからない。

今回は、ざっくりした時間などを計測して本番運用として使ってよいオプションなのかを検証してみました。圧縮オプションでバックアップを取得することを検討されている方は参考にしていただければと思います。

圧縮オプションの手順

DBバックアップの圧縮設定

[バックアップオプション]→[バックアップの圧縮設定]で[バックアップを圧縮する]とバックアップをしながら圧縮される。

DBバックアップ

コマンド場合は、COMPRESSIONオプションを付与すればOK

BACKUP DATABASE [データベース名] TO  DISK = N'バックアップ取得先フルパス' COMPRESSION

検証結果

データベースの圧縮率はどれくらい?100GB越えも検証

データの内容にもよると思いますが、圧縮せずにバックアップすると約11.3GBだったDBが
圧縮してバックアップしてバックアップすると約1.3GBに圧縮されました。約30GBで試しても、約3.4GB程度に圧縮されました。ざっくり1/8程度に圧縮されるみたいです。

また、バックアップの速度も半分程度になりました。

2021年3月追記 150GBのデータベースを圧縮オプションでバックアップしてみました。
結果、約15GBに圧縮されました。容量的にも1/10程度になっています。またバックアップ時間も
10分程度で完了したのでバックアップもかなり高速です

CPUの負荷は?

ざっくりした内容で申し訳ないのですが、バックアップを取得中にタスクマネジャーを監視していましたが20%以上行くこともなく、システムも特に問題なく利用できていました。本番環境にも反映していますがCPUの負荷が特別高くなり、レスポンスが落ちるようなことはありませんでした。

24時間稼働しているシステムなどで行う場合は極力ユーザーが少ない時間帯に実行したほうが良いと思います。

使ってみた感想

別サーバーなどへの移行などの際は、バックアップ時間の短縮、圧縮によってデータ移行容量も大幅に縮小されます。

データ移行時間も大幅に縮小され使わない手はないと思います。サーバに別システムなどが存在した場合はDB圧縮時にCPU負荷がかかるので注意が必要ですが非常に便利な機能だと思います。

まとめ

  • バックアップの圧縮設定で、時間短縮、バックアップ容量削減ができる。
  • バックアップの圧縮設定を入れた場合は、通常のバックアップより負荷がかかる。

コメント

タイトルとURLをコピーしました