web-dev-qa-db-ja.com

dm_db_index_physical_statsに参加するのが非常に遅い

以下の小さなクエリをMS Dynamics AX 2012データベースで実行していますが、5分以上実行されたため、キャンセルする必要があり、PAGEIOLATCH_SH待機タイプ。データベースデータファイルは560GBで、SQL Server 2012 SP1上にあります。

SELECT TOP 1 A.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(),NULL,NULL,NULL,NULL) A 
INNER JOIN sys.objects B
ON A.object_id = B.object_id
INNER JOIN sys.indexes C 
ON B.object_id = C.object_id AND A.index_id = C.index_id
INNER JOIN sys.partitions D 
ON B.object_id = D.object_id AND A.index_id = D.index_id

サーバーのリソースモニターでディスクアクティビティを確認したところ、クエリの実行中に読み取り（B /秒）が最初の23,000から13,000,000を超え、クエリがキャンセルされた後、ダウンに戻りました。

これを引き起こしている可能性のあるアイデアはありますか？

sql-serversql-server-2012performancefragmentationmicrosoft-dynamics
4
HTM

データベース全体をRAMに移動して分析する必要があるため、ディスクアクティビティが高くなります。より少ないNULLでsys.dm_db_index_physical_statsを呼び出すと、クエリを実行できます。データベースのサブセクション。これにより、実行速度が大幅に向上します。

悲しいことに、あなたのTOP 1は、それらのすべてのNULLを使用してメイン関数を呼び出しているので、すべての計算を停止していません。

4
Rob Farley

...それは私がキャンセルしなければならなかった5分以上実行され、それはPAGEIOLATCH_SH待機タイプを示しています

PAGEIOLATCH_SH待機は、SQL Serverがメモリ内にないデータまたはインデックスページが永続ストレージからフェッチされるのを待機しているときに発生します。

sys.dm_db_index_physical_stats動的管理関数LIMITEDモード（デフォルト）で実行するには、b-treeインデックスの非リーフレベルのページとIAM/PFSを読み取る必要がありますまだキャッシュにないヒープのページ。 560GBのデータベースの場合、これによりかなりのI/Oが発生する可能性があります。

これは実際には長いクエリで、ページ数と断片化レベルでフィルターされたTOP N断片化インデックスを取得するために使用します。

あなたはおそらくここで車輪を再発明しています。人気のある無料のインデックスメンテナンスソリューションは次のとおりです。

これらは必ずしも断片化評価を速くするわけではありませんが、世界中で広く使用されている高度に構成可能な事前構築されたソリューションを提供します。特にMinion Reindexでは、メンテナンスウィンドウの外で断片化情報を収集できます。

4
Paul White 9