web-dev-qa-db-ja.com

定期的にDBまたは少なくともログファイルを圧縮する必要がありますか？

私の質問は、縮小コマンドの一方または両方を定期的に実行している場合、

DBCC SHRINKDATABASE

OR

DBCC SHRINKFILE

=============================

バックグラウンド

SQL Server：データベースは200 GB、ログは150 GBです。

このコマンドを実行する

SELECT name ,size/128.0 - 
CAST(FILEPROPERTY(name, 'SpaceUsed') AS int) / 128.0 
AS AvailableSpaceInMB FROM sys.database_files;`

この出力を生成します。

MyDB：159.812500 MBの空き容量

MyDB_Log：149476.390625 MB空き

空き容量があるようです。

バックアップスケジュールは次のとおりです。

  1. トランザクションログ1時間に1回
  2. 週2回の完全バックアップ
  3. 週に5回の差分バックアップ
sql-servermaintenancedbcc
5
Tom DeMille

データファイル（ログファイルははい、データファイルはいいえ）を縮小すべきでない理由について Paul Randalの記事 を読むことを強くお勧めします。

記事を引用したり、要約したりするつもりはありません。少なくともあなたが気づくべきだと私が思う何か。

5
AdaTheDev

ファイルを縮小することの唯一の利点は、ディスク領域を再利用することですが、ここに注意点があります-データベースがその領域を埋めるために拡大する場合、実際に縮小すると、長い間不利益になる可能性があります用語。これは、縮小後、SQL Serverが大きくなるにつれてディスク領域を再利用する必要があり（それほど時間はかかりませんが）、物理ディスクの断片化につながる可能性があるためです（問題の詳細）。

ファイルが通常よりもはるかに大きくなり、ハードドライブのスペースを元に戻したい場合は、縮小します。縮小が通常のメンテナンスの一部であるかどうか疑問に思っているだけなら、そうすべきではありません。

4
SqlRyan

rwmnauが言う のように、SHRINKは通常のメンテナンスではないため、定期的に行うべきではありません。 ただし、1時間ごとにログをバックアップしていて、150 GBの空き容量がある場合-私はあなたがそうであると推測したくなるでしょうそのログを埋めることはありません。

私はおそらくそれを適切なサイズにSHRINKし、バランスが見つかるまで自動成長させます。通常の使用では自動拡張したくありませんが、個人的にはログファイルが99％空にならないようにしています。

適切な開始点を推定するには、1時間（バックアップログスケジュール）での最大変更数を推定するか、数回の代表的なサイクルのログバックアップの前に使用サイズを確認します。

1
Mark Brackett