1

私が継承したSQLServer2005データベースのいくつかのキーは、非常に高い断片化率を持っています。次のSQLを使用する場合：

select  OBJECT_NAME(object_id), avg_fragmentation_in_percent, record_count, *
from    sys.dm_db_index_physical_stats (DB_ID(N'FragmentedDB'), NULL, NULL, NULL, 'Detailed') s

断片化率が50〜99のテーブルがいくつかあります。これらのテーブルはすべて100,000行を超え、一部は2,000,000行以上です。これがアプリケーションのパフォーマンスに重大な問題を引き起こしていると思われるため、次のSQLを使用してこれらのインデックスの一部を再構築しようとしました。

ALTER INDEX ALL ON [dbo].[FragmentedTable] 
REBUILD WITH ( FILLFACTOR = 90, ONLINE = ON )

ただし、インデックスを再構築して断片化％を再度確認した後、それらはすべて変更されていません。足りないものはありますか？私はこのトピックについていくつかの検索を行いましたが、これまでのところ空になっています。

ありがとう！

4

4 に答える 4

1

dm_db_index_physical_stats で「詳細」を使用しています。これにより、非リーフ レベルとインデックスのリーフ レベルが表示されます。

フラグメンテーションは、リーフ レベル (leaf_level = 0)、非リーフ レベル (leaf_level > 0)、またはその両方ですか?

フラグメンテーションが非リーフ レベルである場合、これはあまり問題にならないか、まったく問題ありません。

それでも断片化をすべて取り除きたい場合は、PAD_INDEX を追加してみてください。

于 2009-11-17T19:17:16.153 に答える
0

いくつかのことが頭に浮かびます。最初は、テーブル内のインデックスをバックアップするために複数のファイルを使用している場合、次は、インデックスの再構築中に見られる並列処理です。次に、これがパフォーマンスの問題を引き起こしているとあなたは信じていると言いますが、これが事実であることを確認しましたか？つまり、いくつかの例外を除いて、断片化は通常、スキャンとシークの大きな問題です。断片化の完全な詳細なレビュー、対処方法、集中する場所、およびさまざまな修復方法で見られる違いについては、この一連のブログ投稿を参照してください。

于 2009-11-17T16:30:55.217 に答える
0

考え..

  • 分割されていますか？REBUILD PARTITION = partition_number
  • 必要LOB_COMPACTION = ONですか？
  • クラスタ化インデックスはありますか?
于 2009-11-17T16:38:06.617 に答える
0

断片化を解消する方法は 2 つあります。この 2 つの方法は、特性がまったく異なるため必要です。

SQL Server 2005 以降の 3 つの方法の違いについて説明します。

ALTER INDEX … REORGANIZE (新しい DBCC INDEXDEFRAG)

ALTER INDEX … REBUILD (新しい DBCC DBREINDEX)

ALTER INDEX … 再構築

詳細情報
http://sqlnetcode.blogspot.com/2011/11/sql-server-methods-for-removing.html

于 2011-11-17T16:46:12.023 に答える