1

2000を超えるテーブルのインデックスを確認する必要がある場合、sp_spaceusedコマンドからの情報をどこから取得すればよいですか?

テーブルのインデックスを調査していますが、SQLでsp_spaceusedストアドプロシージャを実行したときに、IndexSizeの結果をどうするかがよくわかりません。

まず、IndexSizeとDataSizeの比率を使用して、インデックスが最適かどうかを呼び出すことができますか?たとえば、テーブルのDataSizeが31 261 768KBで、IndexSizeが41 682 120KBの場合、indexSize / DataSize * 100を除算して、133の比率を取得します。私が行っていることは正しいですか?正しければ、IndexSizeの比率が100%を超えていませんか?

では、良い比率はどうなるでしょうか?

ありがとう、

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~追加する必要がありますもう少し情報。

アプリケーションはMicrosoftDynamicsAx4.0です。開発者は新しいインデックスを追加できますが、システムインデックスを削除することはできません。

現在、値を追加しないカスタムインデックス(空白フィールドのインデックス、金額フィールドのインデックスなど)が割り当てられている状況にあります。コードクリーンアッププロセスの一環として、これらを調査しています。

しかし、何千ものテーブルを処理する必要があるため、開始点が必要です。私の最初の関心事は、価値を付加しないカスタムインデックスを特定することです。このために、sp_spaceusedプロシージャを使用することを考えました。

4

3 に答える 3

1

インデックスサイズとデータサイズの比率を確認することは、これに使用するためのひどいメトリックです。

インデックスの作成または変更を推進する必要があるのは、パフォーマンスだけです。SELECTこれは、テーブル内のアクティビティ(多くの、多くのINSERTS/UPDATEs、いくつかの組み合わせ?)とテーブルの構成に大きく依存します。

残念ながら、これに対する簡単な答えはありません。インデックス作成は、DB設計の最も複雑な側面の1つです。

これについて読んでおくことをお勧めします。

キンバリー・トリップのブログをここでチェックしてください。
彼女はMSでかなり長い間働いており、夫(Paul Randall)はSQLServer2005でDBCCプロシージャを作成しました。

ゲイルショーも彼女のブログにいくつかの良い記事を持っています。

于 2011-04-01T12:32:07.780 に答える
1

Microsoft Dynamicsのパフォーマンスアナライザーを使用すると、AX DBで、高価で長時間実行されるクエリ、クラスター化インデックスの欠落、インデックスの不正確および欠落、非表示のクラスター化インデックススキャンなどを分析できます。

不要なインデックスの量を排除する方法は、同じテーブル上の別のインデックスの左キーサブセットであるインデックスを検索することです。サブセットキーが一意でない限り、その有用性はスーパーセットキーに含まれます。このようなインデックスのリストを取得するには、次のクエリを実行できます。

SELECT *
FROM INDEX_STATS_CURR_VW O
WHERE INDEX_DESCRIPTION NOT LIKE '%UNIQUE%'
AND EXISTS
(
    SELECT * FROM INDEX_STATS_VW I
    WHERE I.RUN_NAME = O.RUN_NAME
    AND I.TABLE_NAME = O.TABLE_NAME
    AND I.INDEX_KEYS <> O.INDEX_KEYS
    AND I.INDEX_KEYS LIKE O.INDEX_KEYS + ',%'
    AND O.USER_SEEKS = 0
)
ORDER BY TABLE_NAME, INDEX_KEYS

完全な監視期間中に使用されなかったすべてのインデックスの概要を取得するには、次のクエリを実行できます。

SELECT TABLE_NAME,
    INDEX_NAME,
    INDEX_DESCRIPTION,
    INDEX_KEYS,
    INCLUDED_COLUMNS,
    SUM(USER_SEEKS) AS USER_SEEKS,
    SUM(USER_SCANS) AS USER_SCANS,
    SUM(USER_LOOKUPS) AS USER_LOOKUPS,
    SUM(USER_UPDATES) AS USER_UPDATES
FROM INDEX_STATS_VW
WHERE INDEX_DESCRIPTION NOT LIKE '%UNIQUE%'
GROUP BY TABLE_NAME, INDEX_NAME, INDEX_DESCRIPTION, INDEX_KEYS, INCLUDED_COLUMNS
HAVING SUM(USER_SEEKS) = 0
AND SUM(USER_SCANS) = 0
AND SUM(USER_LOOKUPS) = 0
ORDER BY 9 DESC

インデックスシークを使用してデータをフィルタリングするクエリを特定することもできます。

SELECT TOP 100 * FROM HIDDEN_SCANS_CURR_VW
ORDER BY TOTAL_ELAPSED_TIME DESC

以下は、SQLServerDMVの観点からの平均的な論理読み取り順に並べられた最もコストのかかる10個のクエリを表示します。

SELECT TOP 10
    SQL_TEXT,
    QUERY_PLAN,
    TOTAL_ELAPSED_TIME,
    AVG_ELAPSED_TIME,
    MAX_ELAPSED_TIME,
    AVG_LOGICAL_READS,
    EXECUTION_COUNT
FROM QUERY_STATS_CURR_VW
ORDER BY AVG_LOGICAL_READS DESC

また、実行回数(クエリが実行された回数)などの他のパラメーターも確認する必要があります。

1000ミリ秒より長く実行されるAXクエリの概要が必要な場合は、次のクエリを実行できます。

SELECT CONVERT(nvarchar,CREATED_DATETIME,101) AS CREATED_DATE,
    DATEPART (hh, CREATED_DATETIME) AS HOUR_OF_DAY,
    COUNT (CREATED_DATETIME) AS EXECUTION_COUNT,
    SUM (SQL_DURATION) AS TOTAL_DURATION,
    AVG (SQL_DURATION) AS AVERAGE_DURATION
FROM AX_SQLTRACE_VW
WHERE SQL_DURATION > 1000 and CREATED_DATETIME > '04/01/2011'
GROUP BY CONVERT(nvarchar, CREATED_DATETIME, 101), DATEPART (hh, CREATED_DATETIME)
ORDER BY CREATED_DATE, HOUR_OF_DAY

お役に立てば幸いです。

于 2011-04-04T14:12:52.527 に答える
0

あなたが何を達成しようとしているのかわかりません。インデックスではなく、クエリを最適化します。ただし、インデックスが多すぎると、書き込みパフォーマンスが低下する可能性があります。2005年に提供されたDMV(動的管理ビュー)を確認することをお勧めします。

たとえば、select * from sys.dm_index_usage_stats使用されていないインデックスを特定するのに役立ちます。

BOLのインデックスに関連するDMVのリストがあります。

http://msdn.microsoft.com/en-us/library/ms187974%28v=SQL.90%29.aspx

于 2011-04-01T12:44:47.843 に答える