web-dev-qa-db-ja.com

縮小後にパフォーマンスが低下する

古いデータを削除して不要なテーブルを切り捨てることで、データベース（SQL Server 2012 SE）をクリーンアップしていました。データを削除して切り捨てた後、パフォーマンスが向上し、16 GBのデータベースから67％の空き容量がありました。次に、次のコマンドを実行して、データベースを10％の空き領域で圧縮します。

DBCC SHRINKDATABASE (databasename, 10);
GO

データベースが7GBに減少した後、パフォーマンスの問題が発生した場合は、添付のスクリーンショットを参照してください。ちなみに、インデックスも再構築していますが、運はありません。 New Relicアプリ監視ツールからアプリケーションパフォーマンスインデックス（Apdex）の警告を取得します。

enter image description here

DMVクエリの結果を見てください。少なくとも20のクエリは1000ミリ秒以上かかります。 1000msの制限を超えるクエリは2つしかありませんでした。

enter image description here

sql-serversql-server-2012performanceshrinkperformance-tuning
3
Shahdat

編集：これをまもなく削除するか、質問への回答に基づいて更新します。実現したOPは、彼がDID=インデックスを既に再構築していると述べました。

SQL Serverデータベースを縮小すると、アルゴリズムの動作方法により、データが大幅に断片化されます。通常はプリサイズするので、縮小する必要はありませんが、拡大についてあまり心配する必要はありません。 IFIを使用してライブDBを拡張する方が、縮小して再インデックスするよりも常に簡単です。

Paul Randalがこれについて深く掘り下げています here 。このスクリプトを使用して前後に断片化を再作成し、断片化をチェックする必要があります here ：

SELECT dbschemas.[name] as 'Schema', 
dbtables.[name] as 'Table', 
dbindexes.[name] as 'Index',
indexstats.alloc_unit_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID()
ORDER BY indexstats.avg_fragmentation_in_percent desc
2
Ali Razeghi

データベースを縮小すると、データファイルが断片化されます。私がこれまで管理してきたデータベースは、常に成長しています。それで、私がデータベースファイルを縮小したとしましょう。オペレーティングシステム（OS）が解放されたディスクセクターを使用している他のものではありません。これで、データベースを拡張する必要がある場合、オペレーティングシステムはデータベースファイルに連続するディスクセクターを提供できなくなり、可能な範囲でそれを提供します。

概要：データベースファイルを圧縮しないでください。スペースを解放してください。ただし、縮小しないでください。

0
Duane Lawrence