web-dev-qa-db-ja.com

SHRINKFILEのベストプラクティスと経験

プリアンブル：一般に、それは大したことではありませんが、スペースが本当に必要なまれなケースであると私は信じています。たとえばExpress Editionは10GBに制限されています。データ型変換（BLOB列）により、かなりの量のスペースを解放できることを発見したと想像してください。しかし、その後もDBファイルは私たちが知っているのと同じサイズであり、10 GBの制限も魔法のように変更されませんでした。そのため、何らかの収縮が必要です。それは一例でした。

私のテスト環境で私は実行しました：

_DBCC SHRINKFILE (DBFile, NOTRUNCATE)
DBCC SHRINKFILE (DBFile, TRUNCATEONLY)
_

それでうまくいきました（私はそれが空きスペースを最小化することを知っています、現実の世界では私は空きスペースを残します）。完了するまでに何時間もかかりました。シングルスレッドプロセスであることはわかっていますが、 奇妙な動作DBCC Shrinkfile 、「一連の非常に小さなシステムトランザクションとして機能するため、ロールバックするものはありません。」 -Paul Randal http://www.sqlservercentral.com/Forums/Topic241295-5-1.aspx 。インデックスの断片化が大幅に失敗することもわかっています http://www.mssqltips.com/sqlservertip/2055/issues-with-running-dbcc-shrinkfile-on-your-sql-server-data- files / と確認できます。 http://www.karaszi.com/SQLServer/info_dont_shrink.asp で説明されていますが、ログファイルの増加は経験しませんでした

_INDEX REBUILD_とREORGANIZEをいくつか発行したところ、数秒で終了しました。

私の質問：

  1. 数秒以内に縮小した後、インデックスの断片化を修正できる場合、縮小についての重要な点は何ですか？わかりません。ここDBAのstackexchangeで、「縮小」トピック（ https://dba.stackexchange.com/tags/shrink/info ）は、「SQL Serverデータベースに対して行うことができる最悪のことをかなりします。 short：スペースを確保するためにパフォーマンスを犠牲にします。」プラスはそれについての別の人気のある記事を指します。ただし、インデックスの断片化は修正できます。
  2. ログファイルが増加しなかったのはなぜですか？
  3. スペース解放操作の後で最初にインデックスを再構築するとどうなりますか。最初のDBCC SHRINKFILE (DBFile, NOTRUNCATE)を置き換えることができるので、DBCC SHRINKFILE (DBFile, TRUNCATEONLY)だけで十分ですか？ふたりは論理レベルが違うと感じているのですが、聞いてみます。

結論：私は定期的にまたは何も縮小しないことを約束します。しかし、これは上限に達し、縮小が必要な状況です。

2番目の質問への回答：開発者のテスト環境をいじっていたため、トランザクションログファイルの増加はありませんでした。トランザクションログファイルは、実稼働環境で拡張されます（完全復旧モデルを想定）。テスト環境でもそれを模倣する必要があります。 trログファイルの増加は、実際にはデータベースファイル内で解放できる領域よりも大きくなります。最後に、データベースファイルだけでなくトランザクションログも圧縮する必要があります（どのように、いつ行うかは復旧モデルによって異なります）。私が見た本番環境では、インデックスの断片化が非常に台無しになり、それがさらに改善されました。私のスクリプトは、断片化レベルが30％を超えるすべてのインデックスのインデックスを再作成します。

増大に対処するには、一生に一度の変換を行っている間に、完全復旧から単純復旧に切り替えなければならない場合があります。しかし、それはバックアップチェーンを壊します。

私の3番目の質問への回答：圧縮はインデックスの断片化を台無しにするので、DBファイルの圧縮後にreindex/index rebuildを実行します。

これらすべてがクエリ統計にどのように影響するかは実験していません。

再インデックス用のスクリプト： TechNet sys.dm_db_index_physical_stats（Transact-SQL） の例Dを参照してください。他の貴重なコンテンツにつながるインクリメンタルシュリンクに関する記事： http://www.mssqltips.com/sqlservertip/3178/incrementally-shrinking-a-large-sql-server-data-file-using- powershell

sql-serversql-server-2005best-practicesshrink
6
Csaba Toth

あなたがしたい場合は：

  1. sQL Serverに関する豊富な経験を持つ非常に賢い人々からの警告はすべて無視してください。
  2. thisの場合はログの増加が発生しなかったため、thisの場合は断片化の修正が迅速であり、それ以上の増加が発生しなかったため、それは常に場合;そして、
  3. この拡大/縮小/拡大/縮小のサイクルがクエリ時間に影響することを確認しないでください。

どうぞ。まれなシナリオでのみこれを行うと言うので、ここであなたが探している答えはわかりません。あなたはそれについて読んだすべてを無視してサイコロを振ることができる大きな親指を上げたいですか？

少なくとも1つのことを提案します。10GBのデータがある場合、Expressで10 GBの制限に達する可能性があります。これを回避するには、データファイルのデータを削除します（またはデータを複数のデータベースに分散します）。データファイル内の大量のスペースを解放すると、そのスペースwillが再利用されます（テーブルをドロップした場合、これは自動的に行われます。行を削除した場合、または列構造を変更した場合、再構築する必要があります-これも少なくとも一時的にいくつかのスペースを取ります）。したがって、ファイル内の5 GBのデータを解放しても、ファイルが9 GBであっても、2 GBを追加しても11 GBになろうとするわけではありません。ファイルが見つからなくなるまで、ファイル内のスペースを再利用します。ファイルを4GBに圧縮してから、新しいデータに対応できるようにファイルを拡張するのは、はるかにコストのかかる操作になります。これは、汚れを拭くために使用しようとしている、すでに清潔なタオルを洗うようなものです...

14
Aaron Bertrand