Медленное и неэффективное перестроение индекса через план обслуживания
Всем привет!
Ребилд индексов при помощи стандартной задачи в плане обслуживания выполняется за два часа.
Ребилд индексов при помощи запроса exec sp_msforeachtable N'DBCC DBREINDEX (''?'')' с ИТС выполняется за 11 минут
Если после ребилда посмотреть состояние фрагментации индексов вот таким запросом:
То в первом случае получается фрагментация 50-60-80-90% на половине таблиц, а во втором - в районе 11% на тех же таблицах.
Что в таком случае делает стандартный ребилд и зачем он вообще нужен?
Ребилд индексов при помощи стандартной задачи в плане обслуживания выполняется за два часа.
Ребилд индексов при помощи запроса exec sp_msforeachtable N'DBCC DBREINDEX (''?'')' с ИТС выполняется за 11 минут
Если после ребилда посмотреть состояние фрагментации индексов вот таким запросом:
sel ect s.name schema_name, t.name TableName, i.name IndexName, d.avg_fragmentation_in_percent Fragmentation
fr om sys.dm_db_index_physical_stats( DB_ID(), null, null, null, null) d
inner join sys.tables t on d.object_id = t.object_id
inner join sys.schemas s on t.schema_id = s.schema_id
inner join sys.indexes i on d.object_id = i.object_id AND d.index_id = i.index_id
where d.index_id > 0 and d.page_count > 8
order by fragmentation desc
ПоказатьТо в первом случае получается фрагментация 50-60-80-90% на половине таблиц, а во втором - в районе 11% на тех же таблицах.
Что в таком случае делает стандартный ребилд и зачем он вообще нужен?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Подозреваю, что exec sp_msforeachtable N'DBCC DBREINDEX (''?'')' вы выполняете не над своей базой, а над master.
Тем более, что, если не путаю, DBREINDEX еще и сама статисику обновляет, 11 минут на "номральной" базе у вас просто не будет.
Ну и фрагментация в 50% после rebuild, воля ваша, но что-то вы странное делаете. Скорее всего опять не на той базе смотрите.
P.S.
exec sp_msforeachtable N'DBCC DBREINDEX (''?'')' - это не запрос с ИТС, а использование стандартного, но deprecated, способа.
Тем более, что, если не путаю, DBREINDEX еще и сама статисику обновляет, 11 минут на "номральной" базе у вас просто не будет.
Ну и фрагментация в 50% после rebuild, воля ваша, но что-то вы странное делаете. Скорее всего опять не на той базе смотрите.
P.S.
exec sp_msforeachtable N'DBCC DBREINDEX (''?'')' - это не запрос с ИТС, а использование стандартного, но deprecated, способа.
Выключил в задании на ребилд отбор по Fragmentation и Page Count. Восстановил базу из копии до проведения DBREINDEX и запустил ребилд с новыми настройками. В этот раз задание выполнилось за 16 минут вместо двух часов, а результат запроса по фрагментированности индексов стал выдавать тот же результат, что и после DBREINDEX - 11% фрагментации.
(5)
Ну дык стало же 16 минут, следовательно, что-то намудрено с job-ом,
попробуйте сделать руками (только замените на свою базу и таблицу), на индексе побольше, что-то типа:
И сравните. Если ОК, то вот это и делайте (с циклом по всем).
Обратите внимание на FILLFACTOR , что-то мне не нравится фрагментация после rebuild
Но почему так долго?
Ну дык стало же 16 минут, следовательно, что-то намудрено с job-ом,
попробуйте сделать руками (только замените на свою базу и таблицу), на индексе побольше, что-то типа:
USE my_base;
GO
ALT ER INDEX ALL ON dbo.Product
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON, MAXDOP=8);
GO
И сравните. Если ОК, то вот это и делайте (с циклом по всем).
Обратите внимание на FILLFACTOR , что-то мне не нравится фрагментация после rebuild
(8)
- Давайте увеличим площадь кухни на 50%, а то тесно.
- Вы что, это же увеличит площадь квартиры в 1.5 раза!
Вы открыли мне глаза, предлагаю считать, что FILLFACTOR придумали слабаки. :)
Что-то мне не нравится фрагментация, поэтому давайте раздуем базу на 20%, авось лучше будет
- Давайте увеличим площадь кухни на 50%, а то тесно.
- Вы что, это же увеличит площадь квартиры в 1.5 раза!
Вы открыли мне глаза, предлагаю считать, что FILLFACTOR придумали слабаки. :)
(10)
Я считаю, что переписываюсь с людьми, которым не надо объяснять, что ничего не надо делать бездумно.
И на каждый чих писать "но, конечно, это только в том случае, когда", "смотрите не упадите", "не сушите кошек в микроволновке", это несколько бессмысленно.
А также с теми, кто понимает, что говорить про увеличение на 20% размера базы при задании
FILLFACTOR в 20% не корректно, хотя бы потому, что 80% отнюдь не означает, что у вас всегда будет "пустым" 20% индексов.
Давайте оставим этот бесполезный разговор, если у вас есть, что сказать автору - с удовольствием почитаю.
А кем считать того, кто советует бездумно применить его на всю базу?
Я считаю, что переписываюсь с людьми, которым не надо объяснять, что ничего не надо делать бездумно.
И на каждый чих писать "но, конечно, это только в том случае, когда", "смотрите не упадите", "не сушите кошек в микроволновке", это несколько бессмысленно.
А также с теми, кто понимает, что говорить про увеличение на 20% размера базы при задании
FILLFACTOR в 20% не корректно, хотя бы потому, что 80% отнюдь не означает, что у вас всегда будет "пустым" 20% индексов.
Давайте оставим этот бесполезный разговор, если у вас есть, что сказать автору - с удовольствием почитаю.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот