|
04.02.2014, 14:17 | #1 |
Британский учённый
|
Стандартные неиспользуемые индексы
Может я сейчас глупость спрошу... На некоторых таблицах индексы занимают в 3-5 раз больше места, чем данные. Многие индексы со слоя sys нигде не используются. Например на таблице LedgerTrans из семи индексов четыре в коде аксапты не обнаружены.
Собственно вопрос, нужно ли держать эти индексы в системе или удалить их дабы сберечь место и ускорить работу с таблицей? Если удалять, какие могут возникнуть проблемы? AX 2009 SP1 RU5
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
04.02.2014, 14:31 | #2 |
Участник
|
не удалять, а выключить.
еще к некоторым индексам не добавляют конфигурационный ключ. поэтому при выключении некоторых ключей поля действительно исчезают, а индексы - нет. в результате на SQL получается два-три полностью идентичных индекса. выключать однозначно. выключение безопасно с точки зрения целостности кода. |
|
|
За это сообщение автора поблагодарили: Logger (1). |
04.02.2014, 14:48 | #3 |
Британский учённый
|
Цитата:
Сообщение от mazzy
не удалять, а выключить.
еще к некоторым индексам не добавляют конфигурационный ключ. поэтому при выключении некоторых ключей поля действительно исчезают, а индексы - нет. в результате на SQL получается два-три полностью идентичных индекса. выключать однозначно. выключение безопасно с точки зрения целостности кода. 1) Включить ключ SysDeletedObjects 2) Выставить ключ на нужных индексах 3) В нужный момент снова отключить ключ и при синхронизации ненужные индексы удалятся. Спасибо
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
04.02.2014, 14:31 | #4 |
Участник
|
То что индекс в коде не упомянут нигде - не значит что он не используется.
В БД должно быть средство посмотреть статистику используемых индексов. На него и нужно полагаться. |
|
04.02.2014, 14:51 | #5 |
Британский учённый
|
Я правильно понимаю, что если индекс не находится обновленными перекрестными ссылками, то он самой Аксаптой не используется и что в этом случае может идти речь только об использовании базы сторонними приложениями? Речь о версии 2009.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
04.02.2014, 15:02 | #6 |
Участник
|
Да при чем здесь сторонние приложения.
Индекс может использоваться самой базой данных Ей же наплевать на Аксапту и на приложение. Она получает запрос выбирает план исполнения и использует для него оптимальный с точки зрения оптимизатора индекс. Индекс может ни разу в коде приложения не упоминаться, но активно использоваться самой базой данных. |
|
04.02.2014, 15:30 | #7 |
Британский учённый
|
Цитата:
Сообщение от Logger
Да при чем здесь сторонние приложения.
Индекс может использоваться самой базой данных Ей же наплевать на Аксапту и на приложение. Она получает запрос выбирает план исполнения и использует для него оптимальный с точки зрения оптимизатора индекс. Индекс может ни разу в коде приложения не упоминаться, но активно использоваться самой базой данных.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
04.02.2014, 15:07 | #8 |
Axapta
|
В большинстве случаев в коде индекс упомянут и не должен быть, а значит и перекрестными ссылками он не найдется. 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 |
|
|
За это сообщение автора поблагодарили: mazzy (5), sukhanchik (4), Logger (10), lev (5), Link (4), gl00mie (5), alex55 (1). |
04.02.2014, 15:31 | #9 |
Британский учённый
|
Цитата:
Сообщение от 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
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
|
За это сообщение автора поблагодарили: leva (1). |
04.02.2014, 17:16 | #10 |
Участник
|
Готовый запрос
Этот запрос возвращает список индексов, которые никогда не использовались в планах исполнения запросов,
и показывает число изменений на страницах каждого такого индекса. Вы можете найти не только индексы, которые лежат в базе данных мёртвым грузом, но и те индексы, которые за счёт большого числа изменений приносят только вред (в виде затрат на изменения значений ключей индекса). X++: 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 Последний раз редактировалось AlexeyS; 04.02.2014 в 17:21. |
|
|
За это сообщение автора поблагодарили: mazzy (5), Logger (3), Link (4), Kabardian (6). |
04.02.2014, 18:18 | #11 |
Британский учённый
|
Цитата:
Сообщение от AlexeyS
Этот запрос возвращает список индексов, которые никогда не использовались в планах исполнения запросов,
и показывает число изменений на страницах каждого такого индекса. Вы можете найти не только индексы, которые лежат в базе данных мёртвым грузом, но и те индексы, которые за счёт большого числа изменений приносят только вред (в виде затрат на изменения значений ключей индекса). Очень полезное замечание, у нас как раз очень огромные индексы, собственно больше половины всей базы занимают индексы. Недавно перезапускали Сиквел, так что теперь придется ждать пока статистика накопится.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
06.02.2014, 14:18 | #12 |
Британский учённый
|
Еще один вопрос назрел по теме. Перешел я к анализу, но сомневаюсь можно ли полагаться на статистику, если очень много индексов имеют сильную фрагментацию. Подозреваю, что можно, но все же хочется уточнить. Базой никто не занимался, поэтому больше тысячи индексов имеют фрагментацию от 30 до 99%.
Еще может кому будет полезно, в сиквеле (2008) уже есть встроенный отчеты по статистике индексов, то о чем выше писал уважаемый oip. Запустил, сохранил в эксель и можно анализировать. Очень удобно, особенно в сильно запущенных случаях. Так же в отчете (Service Dashboard) можно посмотреть дату перезапуска службы.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
04.02.2014, 17:38 | #13 |
Участник
|
2AlexeyS: если обновление статистики и/или реиндексация происходит периодически, то информация будет не корректна
|
|
04.02.2014, 18:00 | #14 |
Axapta
|
И надо не забывать о том, что данные в этих вьюшках могут очищаться:
Цитата:
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.
|
|
Теги |
sql server, администратор бд, анализ, индекс, производительность |
|
|