1C_MAINTENANCE_TIMEOUT 1С:Предприятие и СУБД

Гайд 1С: Оптимизация планов обслуживания баз данных при ночном окне резервного копирования

Обновлено: 26.08.2026 · Официальная документация ↗

В процессе ночного регламентного обслуживания продуктивных баз данных 1С возникают сбои:

Планы обслуживания не успевают завершиться к началу рабочего дня, вызывая колоссальные очереди блокировок и тайм-ауты пользователей.
Блокировка таблиц во время выполнения ALTER INDEX ... REBUILD или DBCC CHECKDB.
Резкий рост размера файла журнала транзакций (LDF / WAL-архивов) во время ночных процедур с последующим исчерпанием диска.
Падение производительности запросов утром из-за неактуальной статистики, обновленной с недостаточным sample rate.

1. Разделение дефрагментации и реорганизации индексов

Используйте скрипты адаптивного обслуживания (например, решение Олы Халленгрена — Ola Hallengren) вместо стандартных планов обслуживания SSMS:

Фрагментация 10–30%: выполнять только REORGANIZE (онлайн-операция, не блокирует параллельные запросы).
Фрагментация > 30%: выполнять REBUILD WITH (ONLINE = ON, MAXDOP = 4). Для Enterprise-редакций SQL Server режим ONLINE=ON предотвращает длительные эксклюзивные блокировки таблиц.
Таблицы менее 1000 страниц: исключать из обслуживания (фрагментация не влияет на производительность сканирования таких объемов).

2. Оптимизация обновления статистик (UPDATE STATISTICS)

Не обновляйте статистики во время перестроения индексов, если индекс уже был перестроен (Rebuild автоматически строит статистику со 100% выборкой). Для остальных таблиц запускайте выборочный пересчет:

-- Выборочное обновление статистики только по измененным данным
EXEC sp_updatestats;
-- Либо с фиксированным сэмплированием для тяжелых таблиц 1С:
UPDATE STATISTICS _InfoRg12345 WITH SAMPLE 30 PERCENT, PERSIST_SAMPLE_PERCENT = ON;

3. Оптимизация целостности (CHECKDB) и бэкапов

Выносите тяжелую проверку DBCC CHECKDB на резервный сервер (Secondary Replica в Always On) или выполняйте проверку на восстановленной из ночного бэкапа копии.
Включите компрессию резервных копий (BACKUP DATABASE ... WITH COMPRESSION, CHECKSUM), что сокращает время создания бэкапа в 3–5 раз и экономит I/O.
Используйте несколько файлов бэкапа (Striped Backup), распределяя запись на параллельные дисковые потоки: TO DISK = 'B1.bak', DISK = 'B2.bak', DISK = 'B3.bak', DISK = 'B4.bak'.

💡 Практика специалистов: Для баз данных 1С на PostgreSQL обязательно настраивайте автовакуум (autovacuum_vacuum_scale_factor = 0.05, autovacuum_analyze_scale_factor = 0.02) и запускайте регламентный VACUUM FULL / REINDEX только в изолированных сервисных окнах.

Частые вопросы (FAQ)

Почему нельзя запускать Shrink (сжатие) базы данных по расписанию?

Shrink вызывает катастрофическую 99% фрагментацию индексов, раздувает журнал транзакций и создает бесполезную нагрузку на дисковую подсистему. Сжатие допустимо выполнять только разово после удаления гигантских массивов данных.

Нужно ли отключать регламентные задания 1С на время ночного обслуживания СУБД?

Да, тяжелые фоновые задания (расчет себестоимости, полнотекстовый поиск, закрытие месяца) должны быть разнесены по времени с планами обслуживания СУБД, чтобы исключить взаимные дедлоки.

Как параметр MAXDOP влияет на ночную переиндексацию?

MAXDOP ограничивает число процессорных ядер на одну операцию индексации. Ограничение MAXDOP=4 или 8 предотвращает утилизацию 100% CPU одним процессом перестроения, оставляя ресурсы ОС и сопутствующим службам.

В чем разница между обновлением статистики с FULLSCAN и с SAMPLE?

FULLSCAN сканирует 100% строк таблицы, создавая максимально точную гистограмму распределения, но требует много времени. SAMPLE считывает выборку (например, 20-30%), что ускоряет процесс в разы при сохранении приемлемой точности для оптимизатора.