Долгая пауза перед Реиндексацией или Перестроением индексов

Форум Администрирование Настройка СУБД (DB)

MS SQL

1. rbw 28.12.21 12:47 Сейчас в теме

Добрый день всем.
Есть план обслуживания Backup на MS SQL 2019 (SQL Server Management Studio 15.0.18390.0)
В нём 3 шага, никак между собой не связанных - у каждого свое расписание.
Один из этих шагов - это бэкап с реиндексацией баз (см.прикрепл.файл).
Проблема в том, что первые 3 подшага делаются поочередно, а потом возникает простой, который может составлять несколько часов (сейчас около 7 часов перед Reindex/Rebuild). Соответственно, реиндексация и обновление статистики происходят уже в рабочее время, что, понятное дело, нехорошо.
В логе это выглядит так:

Maintenance Plan: Backup
Duration: 12:07:04
Status: Succeeded.
Details:

Task start: 2022-01-25T00:00:02.
Task end: 2022-01-25T00:17:25.
Success

Task start: 2022-01-25T00:17:25.
Task end: 2022-01-25T00:17:26.
Success

Task start: 2022-01-25T00:17:26.
Task end: 2022-01-25T00:49:21.
Success

////////тут пауза в 7 часов примерно
Task start: 2022-01-25T07:30:04.
Task end: 2022-01-25T09:06:06.
Success

Task start: 2022-01-25T09:06:11.
Task end: 2022-01-25T12:07:03.
Success

Task start: 2022-01-25T12:07:03.
Task end: 2022-01-25T12:07:06.
Success

В журнале SQL Agent в это время не нашёл никаких событий.
Хотелось бы понять что м.б. причиной таких простоев и как лечить.

Прикрепленные файлы:

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. TormDV 28.12.21 13:23 Сейчас в теме

Добрый день. Копал эту тему. Это баг MS SQL перед реиндексацией и обновлением статистики много времени проходит. Например, вот ссылка, если пропустит:
https://support.microsoft.com/en-us/topic/kb4527229-fix-update-statistics-takes-very-long-time-to-generate-maintenance-plan-for-large-databases-in-sql-server-923c3dd9-dab2-908e-1a0b-333ba5c8c46b
Решение - поставить накопительное обновление MS SQL.

3. rbw 28.12.21 14:00 Сейчас в теме

(2) большое спасибо за быстрый и полезный ответ.
Попробую поставить 14-ый кумулятивный пакет и отпишусь по результату

4. rbw 18.01.22 15:36 Сейчас в теме

(2) наконец-то накатили Upd14
но, увы, это не помогло
пауза в 8 часов перед операцией Реиндексации (
НО зато положительный момент: после реиндексации не было паузы перед шагом Обновление статистики (раньше тоже была), так что наполовину помогло обновление

попробую сегодня переделать структуру: выделить его в отдельный план, а подзадания шага сделать отдельными шагами этого плана

5. rbw 26.01.22 12:34 Сейчас в теме

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

6. rbw 27.01.22 15:55 Сейчас в теме

в общем, судя по всему, никакой паузы нет там. Я посмотрел командой sp_who2: в это время поочередно к базам применяется команда SELECT.
Как я понял, это идёт подготовка к реиндексации - выбираются нужные индексы. А уже потом непосредственно и начинается процесс реиндексации, который и попадает в лог.
Возможно, это неправильный вывод, но пока так решил.
Как сократить это время я пока не понимаю.

7. kspecmash 07.09.22 15:35 Сейчас в теме

(6) Коллега, добрый день.
Столкнулся с абсолютно аналогичной проблемой. Подскажите пожалуйста решили ли вы ее у себя?

8. TormDV 07.09.22 15:58 Сейчас в теме

(7) Добрый день. У себя взяли на использование скрипт из комментариев этой статьи
https://infostart.ru/public/256292/
9 комментарий со ссылкой, если точнее.

9. rbw 08.09.22 11:38 Сейчас в теме

(7) добрый день
к сожалению, не решил
убрал просто лишние базы (они раз в неделю полному ребилду подвергаются), оставил только самые нужные для ежедневного реиндекса

10. ramonaman 01.08.23 14:53 Сейчас в теме

Была аналогичная проблема после перехода с SQL 2012 на 2019.
1. Убрать выборку по перестроению индекса "фрагментация" и "число страниц". Так как с большими базами SQL эту выборку готовить может 5-7 часов. (см крин, нужно убрать чекбосы)
2. Так же добавило скорости выключение чекбокса "физическое" в задании "проверка целостности".

Итого полное обслуживание проходит почти как на 2012, около 7 часов, до этого было 14 часов. Базы 700Гб и меньше, около 20шт.
Ещё всплыли приколы с оптимизацией, но это уже другая история.

Прикрепленные файлы:

Оставьте свое сообщение

E-mail: