Как интерпретировать результаты команды sp_spaceused в отношении индексов - PullRequest
1 голос
/ 01 апреля 2011

Если мне нужно просмотреть индексы более чем 2000 таблиц, с чего начать, учитывая информацию из команды sp_spaceused?

Я изучаю индексы для таблиц, но не совсем уверен, что делать срезультаты для IndexSize, когда я выполняю хранимую процедуру sp_spaceused в SQL.

Во-первых, могу ли я использовать соотношение между IndexSize и DataSize, чтобы сделать вызов на выбор, или нет, индексы являются оптимальными?Например, если мой DataSize для таблицы равен 31 261 768 КБ, а IndexSize равен 41 682 120 КБ, я делю indexSize / DataSize * 100 и получаю соотношение 133. Правильно ли я поступаю?Если это правильно, является ли отношение IndexSize более 100% плохим?

Каким будет тогда хорошее соотношение?

Спасибо,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Мне нужно добавить немного больше информации.

Приложение - Microsoft Dynamics Ax 4.0.Хотя разработчики могут добавлять новые индексы, системные индексы не могут быть удалены.

В настоящее время мы находимся в ситуации, когда имеется множество пользовательских индексов, которые не добавляют никакого значения (индексы в пустых полях, индексы в количествеполя и т. д.).Я исследую их как часть процесса очистки кода.

Но поскольку для работы с тысячами таблиц мне нужна отправная точка.Моя первая задача - определить пользовательские индексы, которые не добавляют ценности, и для этого я подумал об использовании процедуры sp_spaceused.

Ответы [ 3 ]

1 голос
/ 04 апреля 2011

Performance Analyzer для Microsoft Dynamics можно использовать для анализа дорогих и длительных запросов, отсутствующих кластеризованных индексов, неправильных и отсутствующих индексов, скрытых сканирований кластеризованных индексов и т. Д. В БД AX.

Способ устранения количества ненужных индексов состоит в поиске индексов, которые являются подмножеством левого ключа другого индекса в той же таблице.Если ключ набора не является уникальным, его полезность относится к ключу набора.Чтобы получить список таких индексов, вы можете выполнить следующий запрос:

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

Ниже будут показаны 10 самых дорогих запросов, упорядоченных по средним логическим чтениям с точки зрения DMV SQL Server:

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

Вам также необходимо взглянуть на другие параметры, такие как счетчик выполнения (сколько раз было выполнено запросов).

Если вы хотите получить обзор запросов AXпри работе более 1000 мс можно выполнить следующий запрос:

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

Надеюсь, это поможет.

1 голос
/ 01 апреля 2011

Проверка соотношения размера индекса и размера данных - это ужасный показатель, который можно использовать для этого.

Единственное, что должно влиять на создание или изменение индекса, - это производительность.Это будет зависеть в значительной степени от активности в таблице (много SELECT с, много INSERTS/UPDATEs, какая-то комбинация?) И состава стола.

К сожалению, нет ничего легкогоответь на это.Индексирование - это один из самых сложных аспектов проектирования БД.

Я рекомендую вам почитать об этом.

Посетите блог Кимберли Трипп здесь.
Онадолгое время работал в MS, и ее муж (Пол Рэндалл) написал процедуры DBCC в SQL Server 2005.

Гейл Шоу также имеет несколько хороших статей в своем блоге.

0 голосов
/ 01 апреля 2011

Я не уверен, чего вы пытаетесь достичь.Вы бы оптимизировали запрос, а не индекс.Но слишком много индексов могут снизить производительность записи.Я рекомендую вам взглянуть на DMV (динамические представления управления), представленные в 2005 году.

Например, select * from sys.dm_index_usage_stats поможет определить индексы, которые не используются.

Существует список DMV, связанных с индексами на BOL.

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

...