Стандартные неиспользуемые индексы

[Link]

Может я сейчас глупость спрошу... На некоторых таблицах индексы занимают в 3-5 раз больше места, чем данные. Многие индексы со слоя sys нигде не используются. Например на таблице LedgerTrans из семи индексов четыре в коде аксапты не обнаружены.

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

AX 2009 SP1 RU5

[mazzy]

Цитата:

Сообщение от Link

удалить

не удалять, а выключить.

еще к некоторым индексам не добавляют конфигурационный ключ.
поэтому при выключении некоторых ключей поля действительно исчезают, а индексы - нет. в результате на SQL получается два-три полностью идентичных индекса.

выключать однозначно.
выключение безопасно с точки зрения целостности кода.

[Logger]

То что индекс в коде не упомянут нигде - не значит что он не используется.
В БД должно быть средство посмотреть статистику используемых индексов. На него и нужно полагаться.

[Link]

Цитата:

Сообщение от mazzy

не удалять, а выключить.

еще к некоторым индексам не добавляют конфигурационный ключ.
поэтому при выключении некоторых ключей поля действительно исчезают, а индексы - нет. в результате на SQL получается два-три полностью идентичных индекса.

выключать однозначно.
выключение безопасно с точки зрения целостности кода.

За редким исключением конфигурационные ключи на этих индексах нигде не стоят. Т.е. правильный подход:
1) Включить ключ SysDeletedObjects
2) Выставить ключ на нужных индексах
3) В нужный момент снова отключить ключ и при синхронизации ненужные индексы удалятся.

Спасибо

[Link]

Цитата:

Сообщение от Logger

То что индекс в коде не упомянут нигде - не значит что он не используется.
В БД должно быть средство посмотреть статистику используемых индексов. На него и нужно полагаться.

Я правильно понимаю, что если индекс не находится обновленными перекрестными ссылками, то он самой Аксаптой не используется и что в этом случае может идти речь только об использовании базы сторонними приложениями? Речь о версии 2009.

[Logger]

Да при чем здесь сторонние приложения.
Индекс может использоваться самой базой данных

Ей же наплевать на Аксапту и на приложение. Она получает запрос выбирает план исполнения и использует для него оптимальный с точки зрения оптимизатора индекс.
Индекс может ни разу в коде приложения не упоминаться, но активно использоваться самой базой данных.

[oip]

В большинстве случаев в коде индекс упомянут и не должен быть, а значит и перекрестными ссылками он не найдется. SQL Server сам решает, какой из индексов надо использовать.

Статистику использования индексов можно посмотреть во вьюшке sys.dm_db_index_usage_stats. Отсюда можно определить и выключить реально неиспользуемые индексы.
http://technet.microsoft.com/en-us/l.../ms188755.aspx

Еще есть полезная вьюшка sys.dm_db_index_operational_stats.
http://msdn.microsoft.com/en-us/library/ms174281.aspx

О различиях между ними тут: http://blogs.msdn.com/b/craigfr/arch...nal-stats.aspx

[Link]

Цитата:

Сообщение от Logger

Да при чем здесь сторонние приложения.
Индекс может использоваться самой базой данных

Ей же наплевать на Аксапту и на приложение. Она получает запрос выбирает план исполнения и использует для него оптимальный с точки зрения оптимизатора индекс.
Индекс может ни разу в коде приложения не упоминаться, но активно использоваться самой базой данных.

Спасибо, именно это я и хотел понять. У клиента накручено много всего, из аксаптовской БД тянут много инфы. А в самой аксапте очень много создали индексов. К тому же за чем то создали несколько индексов в самой базе, что выдает ошибки синхронизации.

[Link]

Цитата:

Сообщение от oip

В большинстве случаев в коде индекс упомянут и не должен быть, а значит и перекрестными ссылками он не найдется. SQL Server сам решает, какой из индексов надо использовать.

Статистику использования индексов можно посмотреть во вьюшке sys.dm_db_index_usage_stats. Отсюда можно определить и выключить реально неиспользуемые индексы.
http://technet.microsoft.com/en-us/l.../ms188755.aspx

Еще есть полезная вьюшка sys.dm_db_index_operational_stats.
http://msdn.microsoft.com/en-us/library/ms174281.aspx

О различиях между ними тут: http://blogs.msdn.com/b/craigfr/arch...nal-stats.aspx

Спасибо за конструктив, понял куда копать!

[AlexeyS]

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

SELECT   OBJECT_NAME(i.object_id) AS [Table Name],
         i.name AS [Not Used Index Name],
         s.last_user_update AS [Last Update Time],
         s.user_updates AS [Updates]
FROM     sys.dm_db_index_usage_stats AS s
JOIN     sys.indexes AS i
ON       i.object_id = s.object_id
AND      i.index_id = s.index_id
JOIN     sys.objects AS o
ON       o.object_id = s.object_id
WHERE    s.database_id = DB_ID()
AND      (    user_scans   = 0
          AND user_seeks   = 0
          AND user_lookups = 0
          AND last_user_scan   IS NULL
          AND last_user_seek   IS NULL
          AND last_user_lookup IS NULL 
         )
AND      OBJECTPROPERTY(i.[object_id],         'IsSystemTable'   ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsAutoStatistics') = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsHypothetical'  ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsStatistics'    ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsFulltextKey'   ) = 0
AND      (i.index_id between 2 AND 250 OR (i.index_id=1 AND OBJECTPROPERTY(i.[object_id],'IsView')=1))
AND      o.type <> 'IT'
--ORDER BY OBJECT_NAME(i.object_id) 
order by [Updates] desc

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

[ice]

2AlexeyS: если обновление статистики и/или реиндексация происходит периодически, то информация будет не корректна

[oip]

И надо не забывать о том, что данные в этих вьюшках могут очищаться:

Цитата:

The counters are initialized to empty whenever the SQL Server (MSSQLSERVER) service is started. In addition, whenever a database is detached or is shut down (for example, because AUTO_CLOSE is set to ON), all rows associated with the database are removed.

[Link]

Цитата:

Сообщение от AlexeyS

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

Спасибо, нашел похожий запрос здесь.

Цитата:

Сообщение от AlexeyS

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

Очень полезное замечание, у нас как раз очень огромные индексы, собственно больше половины всей базы занимают индексы. Недавно перезапускали Сиквел, так что теперь придется ждать пока статистика накопится.

[Link]

Еще один вопрос назрел по теме. Перешел я к анализу, но сомневаюсь можно ли полагаться на статистику, если очень много индексов имеют сильную фрагментацию. Подозреваю, что можно, но все же хочется уточнить. Базой никто не занимался, поэтому больше тысячи индексов имеют фрагментацию от 30 до 99%.

Еще может кому будет полезно, в сиквеле (2008) уже есть встроенный отчеты по статистике индексов, то о чем выше писал уважаемый oip. Запустил, сохранил в эксель и можно анализировать. Очень удобно, особенно в сильно запущенных случаях. Так же в отчете (Service Dashboard) можно посмотреть дату перезапуска службы.

[Link]

Вот что пишут:

 When an Index Logical Scan Fragmentation exceeds 50%, SQL will ignore the Statistics recommendations and perform a Table Scan instead.

Получается, что нельзя полагаться на статистику по индексу, если фрагментация больше 50%?