Кем должна выполняться дефрагментация?

[Lankey]

(Выношу в отдельную тему тот же вопрос, что задала в ветке "дефрагментация индексов")

Скажите , пожалуйста, на cloud tier 2-3-4-5 кем должна выполняться дефрагментация?

На UAT пользователи жалуются на локи на таблице из ISV модели: когда один процесс update делает , а пользователь (др процесс) открывает форму с данными на просмотр, то его страница виснет.
На стороне SQL лок эскалируется на всю таблицу, хоть апдейт по идее полько subset записей обновляет по полю из одного из индексов. Я вижу, что на таблице дефрагментация индексов от 50 до 99 процентов (кластерный 94). Подозреваю, что с такой фрагментацией SQL проще всю таблицу залочить, отсюда проблема.(тут я буду благодарна за другие гипотзы )
В любом случае, с фрагментацией надо, наверное, что-то делать:

Нашла
https://www.inetdynamics.com.sg/3-ti...s-performance/ , но хотела бы уточнить, вы этим пользуетесь или как-то иначе дефрагментируете?
Спасибо

[fed]

Цитата:

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

(Выношу в отдельную тему тот же вопрос, что задала в ветке "дефрагментация индексов")

Скажите , пожалуйста, на cloud tier 2-3-4-5 кем должна выполняться дефрагментация?

На UAT пользователи жалуются на локи на таблице из ISV модели: когда один процесс update делает , а пользователь (др процесс) открывает форму с данными на просмотр, то его страница виснет.
На стороне SQL лок эскалируется на всю таблицу, хоть апдейт по идее полько subset записей обновляет по полю из одного из индексов. Я вижу, что на таблице дефрагментация индексов от 50 до 99 процентов (кластерный 94). Подозреваю, что с такой фрагментацией SQL проще всю таблицу залочить, отсюда проблема.(тут я буду благодарна за другие гипотзы )
В любом случае, с фрагментацией надо, наверное, что-то делать:

Нашла
https://www.inetdynamics.com.sg/3-ti...s-performance/ , но хотела бы уточнить, вы этим пользуетесь или как-то иначе дефрагментируете?
Спасибо

Теоретически всем этим занимается DAMS (не помню как оно расшифровывается, но это какая-то микрософтовская тулза, которая периодически стартует и перестраивает фрагментированые индексы, собирает статистику и даже строит новые индексы если в Query Store есть какие-то тяжелые запросы, которым индексов не хватает).
Во первых проблема в том, что оно игнорирует таблицы с объемом меньше N мегабайт (раньше было 100 Mb, может с тех пор что-то поменялось).
Во вторых - я экспериментировал с перестройкой индексов и даже если индекс только что перестроен, иногда сиквелу кажется что запрос будет много строк обновлять (либо статистика старая, либо сам запрос заковыристый и предположения микрософта о коррелации между несколькими статистиками неправильные). В этом случае оно все равно эскалирует блокировку до уровня страниц или вообще всей таблицы.
Я в какой-то момент написал SysSetup скрипт, который после каждой синхронизации запускается и нужных таблиц и индексов через Alter table/alter Index отключает возможность эскалации блокировок и блокировок индекса на уровне страниц. Сейчас мы туда время от времени добавляем новые таблицы (индексы оно само добавляет просто запросив данные из sys.indexes для очередной таблтцы).