Skip to content

MS_DataFileShrinkAndGrow

Jump to bottom
nishi_74322014 edited this page Aug 18, 2026 · 1 revision

データ ファイルの圧縮と拡張

概要

  • 拡張

    • 必要に応じて、DB の「データ ファイル」、「トランザクション ログ ファイル」を拡張する。
    • 自動拡張と手動拡張がある。

  • 圧縮

    • 必要に応じて、DB の「データ ファイル」、「トランザクション ログ ファイル」を圧縮し
      無駄なディスク消費を減らす。
    • 自動圧縮と手動圧縮がある。

補足（用語の注意）: ここでの「圧縮」は
**shrink（ファイルの縮小）**であり、
SQL Server データ圧縮の
**compression（行・ページの圧縮）**とは全く別の機能である。
日本語ではどちらも「圧縮」と訳されるため混同しやすい。

拡張

手動拡張か、緊急回避としての自動拡張が推奨。

手動拡張

  • 自動拡張を OFF に設定し、手動拡張にする。
  • 手動拡張では拡張のタイミングを完全に制御することができる。
  • ただし、手動拡張は、管理上のオーバーヘッドが増加する。

自動拡張

  • 自動拡張を ON に設定する。
  • ファイル サイズの自動拡張が頻繁に起こるような設定は避ける。

設定方法

「Management Studio」や、ALTER DATABASE ステートメントの
ファイル プロパティで設定する。

補足（自動拡張は「保険」として ON にする）: 本文は
「自動拡張を OFF にして手動拡張」を推奨しているが、
自動拡張を完全に OFF にするのは危険である。
領域が尽きた時点で DB が読み取り専用状態になり、
業務が停止するためである
（SQL Server 大量データ処理時の性能問題の
「結論」も同じことを述べている）。

現在の定石は以下。

項目 指針
自動拡張 ON のままにする（緊急回避の保険）
拡張量 パーセントではなく固定 MB で指定（例: 512MB〜1GB）
最大サイズ 無制限にせず上限を設定し、ディスクを食い潰さないようにする
実運用 監視して事前に手動拡張し、自動拡張が発動しないようにする

パーセント指定が危険なのは、DB が大きくなるほど 1 回の拡張量が増え、
拡張中の待ち時間が伸びていくためである
（SQL Server での設定取得方法の
is_percent_growth の補足も参照）。

補足（瞬時ファイル初期化）: データ ファイルの拡張は、既定では
拡張分をゼロ埋めするため時間がかかる。
SQL Server のサービス アカウントに
「ボリュームの保守タスクを実行」権限を付与すると
**瞬時ファイル初期化（Instant File Initialization）**が有効になり、
ゼロ埋めが省略されて拡張が一瞬で終わる。

ただし、トランザクション ログ ファイルには適用されない
（ログは必ずゼロ埋めされる）。
ログを小刻みに自動拡張させると
VLF（仮想ログ ファイル）が大量に生成され、
復旧時間やログ バックアップの性能が悪化するため、
ログこそ事前に必要サイズを確保しておくべきである
（SQL Server の障害復旧）。

圧縮

  • 自動圧縮は極力使用せず、DB の監視を行い手動で拡張する。
  • この圧縮処理は、ログの切り捨て処理を含まないので、必要であれば、
    圧縮する前に「トランザクション ログ ファイル」のログの切り捨て処理をする。

手動圧縮

  • 手動圧縮では圧縮のタイミングを完全に制御することができる。

  • ただし、手動圧縮は、管理上のオーバーヘッドが増加する。

  • 手動圧縮をする場合、

    • 「Management Studio」や、
    • DBCC SHRINKDATABASE ステートメント
    • DBCC SHRINKFILE ステートメント

自動圧縮

  • ファイル サイズの自動圧縮を設定する場合、autoshrink オプションを設定する。

  • このデータベース オプションの設定には、

    • 「Management Studio」や、
    • ALTER DATABASE ステートメント
    • sp_dboption システム ストアド プロシージャ

    を使用する。

  • デフォルトの設定では、ファイル サイズの自動圧縮は OFF になっている。

    • ファイル サイズの自動圧縮を ON にすると、
      「データ ファイル」、「トランザクション ファイル」の未使用領域が、
      25% を超えた場合に、自動的にファイルが圧縮される。

移行メモ（最新化）: sp_dboption は SQL Server 2005 で非推奨となり
2012 で削除されている。現在は ALTER DATABASE ... SET を使用する。

ALTER DATABASE [MyDB] SET AUTO_SHRINK OFF;

補足（AUTO_SHRINK は絶対に有効にしない）: 本文は
「極力使用せず」と表現しているが、現在の共通認識は
**「有効にしてはならない」**である。理由は以下。

  1. 激しい断片化を招く
    ページを末尾から先頭へ移動するため、
    インデックスの論理的な順序が崩壊する
    （SQL Server のインデックスの断片化の節を参照）。
  2. 縮小 → 拡張のループになる
    縮小した領域はすぐまた必要になり、拡張が走る。
    その拡張のたびに待ちが発生し、VLF も増える。
  3. 実行タイミングを制御できない
    業務のピーク時に走ると致命的。

手動の DBCC SHRINKFILE も同じ副作用を持つため、
定常のメンテナンス プランには入れない
（SQL Server の管理の補足も参照）。

実施してよいのは、

  • 大量削除やアーカイブ後など、恒久的に空き領域が生じたときの単発作業
  • 誤って肥大化したログを一度だけ縮小するとき

に限られる。
実施後は必ずインデックスを再構築すること
（インデックスの再構築・デフラグ）。

補足（ログが縮まないとき）: DBCC SHRINKFILE でログを縮小しても
サイズが変わらない場合、ログを切り捨てられない理由がある。
sys.databases の log_reuse_wait_desc で確認できる。

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;
値 意味と対処
LOG_BACKUP 完全復旧モデルでログ バックアップが未取得。取得すれば切り捨てられる
ACTIVE_TRANSACTION 長時間実行中のトランザクションがある
REPLICATION 未配信のレプリケーション対象トランザクションがある（SQL Server のレプリケーション）
AVAILABILITY_REPLICA 可用性グループのセカンダリへの同期が遅れている
CHECKPOINT チェックポイント待ち

なお、復旧モデルを単純に切り替えてログを切り捨てるという対処は、
ログの鎖（log chain）を切ってしまい
ポイントインタイム復旧ができなくなる。
実施する場合は直後に完全バックアップを取り直すこと
（SQL Server の障害復旧）。

参考

Tags: 移行, データアクセス, SQL Server

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally