第7回 最近のMigration事情 - SQLServer の圧縮 -

弊社が作業させて頂くことの多いSQL Server 2008 をお使いの日本のお客様環境では、SQL Serverの圧縮によってR/3本番機のデータベースサイズは概ね1/4以下になります。

インポート処理に関して言えば、圧縮することもありBULK INSERT処理は遅くなりました。

というのも非圧縮の場合、ダイレクトにトランザクションログへ書き込みますが、圧縮の場合はいったんTEMPDBで圧縮してからトランザクションログへ書き込む、という処理になるため経験的に30%程度は遅くなる感じです。

1TB越のDBをSQL Server2005へインポートしたときに9時間(DBサイズ950GB)でしたが、SQL Server2008ページ圧縮の時は16時間(DBサイズは260GB)かかりました。Create Indexに関しては最初のフルスキャンが短縮される分短くなるのと、恐らくですがメモリ使用量が減っている気がしますので、メモリの利用効率が良い分I/Oが減っていることも時間短縮につながっているかもしれません。

SQL Server2008の圧縮で助かるのは、トランザクションログの使用量も圧縮される分減っているようなのです。以前はCreate Indexが始まると、BULK INSERT分のトランザクションログが解放されないため、トランザクションログの使用量を溢れないよう監視しながら、随時データを投入していましたが、非圧縮のときよりもそれがしやすくなりました。

NotesにもあるようにCPU負荷があがることと、Migration時のインポートが遅いことを挙げると、「本番でのパフォーマンスが落ちないか？」ということをお客さんから聞かれます。私の答えは「お客様が気にするほど、心配する必要はありません。」と答えます。

私がそう答える理由は3つあります。

一つ目は、最近のプロセッサ性能は飛躍的に向上しており、新システムのハードウェア能力向上でそれが吸収されてしまうというものです。

二つ目は、I/Oが軽減されるのとキャッシュ効率が良くなる分I/Oを含めたシステム全体の利用効率があがると考えられます。CPUを使いきらないバッチよりもCPUが張り付くぐらいの方がバッチ処理は早く終わるわけで、むしろ良いことだと思います。

三つ目は、データの書き込み処理が実際の業務処理全体に占める割合が小さいために、そこが多少遅くなったとしても対して影響がないからです。

次回はネットワークに関して書いてみたいと思います。

ではまた。

hama