web-dev-qa-db-ja.com

SQL Server、「未使用領域を解放する前にファイルを再編成する」は良いですか、悪いですか？

満足のいく答えが見つかりませんでした。 「縮小」はインデックスの最適化を引き起こし、パフォーマンスを低下させる可能性があることを十分に理解しています。

しかし、このオプションはデフラグを減らすためのものではないのですか？

それで、このオプションを有効にするために、それは良いですか悪いですか？私の混乱を増やさないでください。私は明確で単純な答えを私に与えてください：それはより良い、またはより悪いです。

よろしければ、よろしくお願いいたします。

enter image description here

sql-serverperformancetuning
3
DiegoSoto

それは縮小に相当します。それを証明するには、ボックスをチェックし、上部にある[スクリプト]ボタンをクリックして、生成される縮小コマンドを確認します。

一般的に言えば、これも優れた学習ツールです。UIの機能を学びたいときはいつでも、そのスクリプトボタンを試してください。

8
Brent Ozar

既存の回答とは逆に、これにより、以下の生成された2つのスクリプト（少なくとも私のバージョンのEnterprise Manager-SQL Server 2017）に見られるように、サイズを指定できるようにする以外に、SQLが変更されます。

-- Checkbox Unchecked
DBCC SHRINKFILE (N'My_DB' , 0, TRUNCATEONLY)

-- Reorganise Checkbox Checked
DBCC SHRINKFILE (N'My_DB' , 48491)

チェックされていないオプションの場合、TRUNCATEONLYが適用され、SQLサーバーがデータの再編成を実行できなくなります。これは、すぐにパフォーマンスに影響を与えずに一部のスペースをすばやく解放したい場合に最適ですが、データベースが断片化するため、進行中のパフォーマンスに影響を与える可能性があります。

TRUNCATEONLYファイルの終わりにあるすべての空き領域をオペレーティングシステムに解放しますが、ファイル内のページ移動は実行しません。データファイルは、最後に割り当てられたエクステントにのみ縮小されます。 target_sizeは、TRUNCATEONLYと共に指定された場合は無視されます。

参照： https://docs.Microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-2017

TLDR;（コメントに基づいて書き換え）：

  • どちらの方法でもパフォーマンス上の利点はありませんが、再編成すると、データベースの最後に割り当てられた空き領域を解放するだけでなく、追加の領域を解放できるようになります（特定の状況でのみこれが有益です）。
  • 再編成するとインデックスがフラグメント化されるため、後で再構築します
  • 再編成すると、データベースが物理的にデータページを移動する間、パフォーマンスに短期的な影響が生じる可能性があります。
0
Radderz