|
![]() |
#1 |
Moderator
|
Посмотрел. У меня фрагментация кластерных индексов по recId порядка 50%, фрагментация обычных индексов - порядка 70% (для этих двух таблиц конечно)
Вообще логику отбора индексов для перестроения/реорганизации можно в хранимой процедуре SYS.DM_DB_INDEX_USAGE_STATS Если я там правильно код понял, то индексы с более 500 записей и менее 100 страниц переиндексируются только если за некий период к ним было более 100000 обращений, а индекс с более 100 страниц переиндексируются только если к ним было более 10000 обращений. Как период определяется - я не знаю. Как я подозреваю, можно статистику доступа к индексам какой-то командой сбросить, но какой именно командой и насколько часто она этими скриптами автоиндексации выполняется - я не знаю. Еще у меня было ощущение, что во времена SSD переиндексация не так актуальна, как во времена настоящих жестких дисков, поскольку время последовательного и произвольного чтения/записи для SSD достаточно близки. Последний раз редактировалось fed; 29.01.2024 в 15:24. |
|
|
За это сообщение автора поблагодарили: Lankey (1). |
![]() |
#2 |
Участник
|
Цитата:
Цитата: Цитата:
Миф: у нас SSD, поэтому дефрагментация нам не нужна. Еще как нужна! Часто в высоко нагруженных системах не делают дефрагментацию, потому что это сложно. В итоге процент фрагментации выходит на уровень почти 100%, и таблицы занимают в два раза больше страниц, чем нужно. В два раза больше места - это в два раза хуже Buffer Cache Hits Ratio. Это в два раза больше размер full backups. Это в два раза дольше full table scans. Это выше CPU (потому что страницы перемещаются с помощью процессора, а не сами по себе)
|
|
![]() |
#3 |
Участник
|
Спасибо большое, что посмотрели! Очень признательна . Есть хоть какие-то теперь ориентиры , чтобы понимать, нормально ли то, что у нас происходит.
Последний раз редактировалось Lankey; 29.01.2024 в 22:16. |
|