Фрагментация индексов

[Lankey]

D365
Обновлена база в PrePROD копией базы из PROD

Два индекса на таблице DirPartyRelationship

• по RecID (unique, no-clustered)
• по Partition (non-unique, no-clustered)

имеют фрагментацию 98%

Как я понимаю, MS поддерживает здоровье индексов в D365, поэтому не очень ясно, почему такая высокая фрагментация?

PS: Такая же история,например, с DirPartyTable. На стороне SQL в ней 34 индекса. Среди них 8 имеют фрагментацию больше 90%
В CustTable три основных индекса RecID, AccountIdx InvoiceAccountIdx имеют 98%

[Lankey]

А у вас как? Тоже такая сильная фрагментация на этих индексах?

[fed]

Посмотрел. У меня фрагментация кластерных индексов по recId порядка 50%, фрагментация обычных индексов - порядка 70% (для этих двух таблиц конечно)
Вообще логику отбора индексов для перестроения/реорганизации можно в хранимой процедуре SYS.DM_DB_INDEX_USAGE_STATS Если я там правильно код понял, то индексы с более 500 записей и менее 100 страниц переиндексируются только если за некий период к ним было более 100000 обращений, а индекс с более 100 страниц переиндексируются только если к ним было более 10000 обращений. Как период определяется - я не знаю. Как я подозреваю, можно статистику доступа к индексам какой-то командой сбросить, но какой именно командой и насколько часто она этими скриптами автоиндексации выполняется - я не знаю.

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

[ТРЕНЕР]

Цитата:

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

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

Статья на Хабре: https://habr.com/ru/articles/724702/

Цитата:

Цитата:

Миф: у нас SSD, поэтому дефрагментация нам не нужна. Еще как нужна! Часто в высоко нагруженных системах не делают дефрагментацию, потому что это сложно. В итоге процент фрагментации выходит на уровень почти 100%, и таблицы занимают в два раза больше страниц, чем нужно. В два раза больше места - это в два раза хуже Buffer Cache Hits Ratio. Это в два раза больше размер full backups. Это в два раза дольше full table scans. Это выше CPU (потому что страницы перемещаются с помощью процессора, а не сами по себе)

[Lankey]

Цитата:

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

Посмотрел. У меня фрагментация кластерных индексов по recId порядка 50%, фрагментация обычных индексов - порядка 70% (для этих двух таблиц конечно)

Спасибо большое, что посмотрели! Очень признательна . Есть хоть какие-то теперь ориентиры , чтобы понимать, нормально ли то, что у нас происходит.