План обслуживания баз 1С в Microsoft SQL Server: порядок задач в SSMS и почему расписание перестало быть главным

Здесь собран план обслуживания для базы «1С:Предприятие 8» на Microsoft SQL Server: проверка целостности, индексы, статистика, очистка процедурного кэша, резервная копия и уборка за собой. Десять шагов в SQL Server Management Studio и пятнадцать снимков экрана с нашего стенда. На снимках видно несовпадение, которое стоит поискать и у себя: резервные копии ложатся в одну папку, а задача очистки смотрит в другую. При таком расхождении старые копии никто не удаляет, и диск заполняется. Откройте обе задачи своего плана и сравните поле «Папка».

После шагов разобрано, что каждая задача делает с сервером. Перестроение индексов в редакции Standard закрывает таблицы для пользователей, DBCC FREEPROCCACHE заставляет сервер заново компилировать каждый запрос, а копия журнала транзакций имеет смысл не при любой модели восстановления. В конце — график запусков. Это старт, а не ответ: частоту каждой операции проверяют на своей базе, поэтому расписание и перестало быть главным.

Коротко

• Наш порядок задач в плане обслуживания базы «1С:Предприятие 8»: проверка целостности → индексы → обновление статистики → очистка процедурного кэша → резервное копирование, а от него двумя ветками — очистка после обслуживания и очистка журнала.
• В регламенте 1С для MS SQL Server четыре операции: обновление статистик, очистка процедурного КЭШа, дефрагментация индексов и реиндексация таблиц базы данных. Их выполнение должно быть автоматизировано; рекомендованный инструмент — штатный Maintenance Plan.
• В графике в конце страницы четыре строки взяты из регламента 1С, ещё четыре — наша практика.
• Числового порога фрагментации для выбора между REORGANIZE и REBUILD у Microsoft сейчас нет: решайте по замеру на своих запросах, для него подходит Query Store. В SQL Server 2025 в редакции Standard онлайн-перестроение по-прежнему недоступно, а офлайновый REBUILD закрывает таблицу блокировкой Sch-M на всё время операции.
• DBCC FREEPROCCACHE удаляет из кэша все планы запросов. Сервер заново компилирует план под каждый входящий запрос, и возможна внезапная временная просадка скорости запросов — поэтому команде место в окне обслуживания.

Что такое план обслуживания и из каких операций он состоит

План обслуживания — это набор задач администрирования базы данных, который служба SQL Server Agent запускает по расписанию с заданным интервалом. Среди таких задач — резервные копии, проверки целостности базы и обновление статистики. Создавать планы обслуживания и управлять ими может только участник серверной роли sysadmin; остальным узел «Планы обслуживания» в обозревателе объектов не показывается.

Для клиент-серверной «1С:Предприятие 8» на Microsoft SQL Server мы держим в плане пять регламентных операций (это перечень, не порядок сборки):

• регулярное резервное копирование баз данных;
• обновление статистики;
• очистка процедурного кэша;
• реорганизация индекса;
• перестроение индекса.

К ним добавляются проверка целостности базы перед всем остальным и две уборочные задачи в конце — «Очистка после обслуживания» и «Очистка журнала».

Как собрать план обслуживания в SSMS

Порядок ниже — тот, по которому мы собираем план для баз 1С. SQL Server Management Studio устанавливается отдельно от самого Microsoft SQL Server; дальше всё делается в обозревателе объектов. Снимки экрана сделаны на нашем тестовом стенде: в корне дерева стоит RDS2TEST (SQL Server 14.0.1000.169 - A…), то есть Microsoft SQL Server 2017 RTM; обслуживаемая база называется testbase.

1. «Управление» → «Планы обслуживания» → правая кнопка мыши → «Создать план обслуживания…». Автоматически создаётся вложенный план, а расписание для него задаётся в окне «Создание расписания задания»: там выбираются частота и время запуска.

   
   Узел «Планы обслуживания» в обозревателе объектов: контекстное меню, первым пунктом — «Создать план обслуживания…».

   
   Окно «Создание расписания задания» для MaintenancePlan.ВложенныйПлан_1: повторяющееся задание, еженедельно, воскресенье, однократный запуск в 0:00:00, дата начала 20.05.2019 без даты окончания. На стенде расписание еженедельное; свою частоту вы задаёте здесь же.

   
   Вложенный план создан: «Расписание: Не запланировано», «Запуск от имени: Учетная запись службы „агент SQL Server“». Слева подсвечена вкладка «Панель элементов».

2. Первой задачей ставится «Проверка целостности базы данных». Базы выбираются в свойствах задачи: все, кроме системных, или конкретные. Почему проверка идёт первой и что делать, если она нашла ошибки, — тема соседней статьи о проверке базы 1С на целостность в MS SQL.

   
   Состав задач в «Панели элементов»: выполнение задания агента SQL, выполнение инструкции T-SQL, обновление статистики, очистка журнала, очистка после обслуживания, перестроение индекса, проверка целостности базы данных, резервное копирование, реорганизация индекса, сжатие базы данных, уведомление оператора. Готовой задачи для очистки процедурного кэша среди них нет.

   
   Выбор баз в задаче проверки целостности: переключатель «Следующие базы данных», отмечена testbase, ниже флажок «Пропускать базы данных, находящиеся в режиме „вне сети“».

3. Дальше — «Перестроение индекса» или «Реорганизация индекса», исходя из нагрузки и времени выполнения регламентного задания. Обе задачи в мастере штатные: «Реорганизация индекса» соответствует ALTER INDEX ... REORGANIZE, «Перестроение индекса» — ALTER INDEX ... REBUILD PARTITION. Отдельный скрипт, чтобы перестроить индексы всей базы, писать не нужно. На стенде со снимков выбрана реорганизация.

   
   Две задачи на полотне: проверка целостности базы testbase («Включить индексы», «Только физическое») и реорганизация индекса по таблицам и представлениям. От первой ко второй тянут связь.

4. Связи между задачами задаются «Редактором управления очерёдностью»: тип связи выбирается полем «Значение», и вариантов три. «Успешное выполнение» — следующая задача выполняется только при успехе предыдущей; «Ошибка» — только при ошибке предыдущей; «Завершение» — независимо от результата. В конструкторе связи различаются подписью на стрелке: «Завершение» подписано словом, а «Успешное выполнение» рисуется без подписи, потому что это значение по умолчанию. Практический смысл связи «Успешное выполнение» после проверки целостности такой: если проверка выявила повреждение базы данных, то последующие задачи обслуживания выполнены не будут.

   
   «Редактор управления очерёдностью»: вычислительная операция «Ограничение», значение «Успешное выполнение», для нескольких ограничений выбрано логическое AND.

5. «Обновление статистики», связь «Завершение». Частота у этой задачи своя: стартовое значение в графике — не реже раза в день, полным сканированием.

   
   Связь «Реорганизация индекса» → «Обновление статистики» подписана словом «Завершение», а стрелка от проверки целостности идёт без подписи: это и есть значение по умолчанию «Успешное выполнение». В карточке статистики — «Вся собранная статистика», «Тип просмотра: Полный просмотр».

6. Очистка процедурного кэша. Готовой задачи в «Панели элементов» нет, поэтому добавляется задача «Выполнение инструкции T-SQL» с текстом dbcc freeproccache.

   
   Задача «Выполнение инструкции T-SQL»: в поле инструкции набрано DBCC FREEPROCCACHE, время ожидания выполнения — 0.

7. Резервное копирование. На вкладке «Общее» выбирается тип копии: полная, разностная или журнал транзакций. На вкладке «Целевой объект» — разбиение на файлы, отдельный каталог на каждую базу и путь. На вкладке «Параметры» мы включаем «Сжимать резервные копии» и «Проверку целостности резервной копии»; там же задаются срок действия набора и шифрование.

   
   Вкладка «Целевой объект» задачи резервного копирования: отдельный файл на каждую базу, вложенный каталог на каждую базу, папка B:\BackUP\1cbases, расширение bak.

8. «Очистка после обслуживания» — путь к резервным копиям, расширение файлов (*.bak) и срок, после которого старые файлы удаляются.

   
   Задача «Очистка после обслуживания»: удаляются файлы резервных копий с расширением bak старше одной недели из каталога C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQ…, вложенные папки первого уровня включены.

   Сравните путь в задаче очистки с путём в задаче резервного копирования на снимках выше: копии пишутся в B:\BackUP\1cbases, а очистка удаляет *.bak из каталога по умолчанию. Пути не совпадают, а значит, в таком плане очистка не удалит ни одного файла резервной копии и диск под копии будет заполняться. Сверять пути нужно глазами: строка «Папка» в задаче очистки должна совпадать со строкой «Папка» в задаче резервного копирования.

9. «Очистка журнала» — удаление данных журнала о самих регламентных заданиях Microsoft SQL Server.

   
   Задача «Очистка журнала»: отмечены журнал резервного копирования и восстановления, журнал заданий агента SQL Server и журнал плана обслуживания, удаляются записи старше одной недели.

10. Проверить, что план вообще отрабатывает: «Обозреватель объектов» → «Управление» → «Планы обслуживания» → правая кнопка → «Просмотр журнала».

    
    Собранный план целиком: проверка целостности базы данных → реорганизация индекса → обновление статистики → выполнение инструкции T-SQL → резервное копирование, от которого идут две ветки — очистка после обслуживания и очистка журнала.

    
    Контекстное меню созданного плана: «Просмотр журнала» стоит между «Мастером планов обслуживания» и «Изменить».

И последнее. По моему опыту, забывают именно об этом: за выполнение планов обслуживания отвечает служба «Агент SQL Server». В её свойствах в оснастке «Службы» тип запуска должен стоять «Автоматически», иначе после перезагрузки сервера план молча перестанет запускаться.

Свойства службы «Агент SQL Server (MSSQLSERVER)»: имя службы SQLSERVERAGENT, тип запуска «Автоматически», состояние «Выполняется».

Реорганизация или перестроение индекса: что выбрать

Задачи «Реорганизация индекса» и «Перестроение индекса» обе есть в мастере планов обслуживания, но стоят они очень по-разному. Реорганизация индекса дешевле по ресурсам и всегда идёт онлайн: длительных блокировок уровня объекта она не держит, запросы и обновления таблицы могут идти дальше. Берите её по умолчанию, а перестроение — когда для него есть конкретная причина. В rowstore-индексах таблиц и представлений реорганизация дефрагментирует только листовой уровень кластеризованных и некластеризованных индексов: физически переставляет листовые страницы так, чтобы их порядок совпал с логическим.

Перестроение удаляет индекс и создаёт его заново. Пройти оно может офлайн или онлайн — это зависит от типа индекса и версии Database Engine. Офлайн обычно быстрее, но на всё время операции держит блокировки уровня объекта и не пускает запросы к таблице или представлению.

Standard: перестроение закроет таблицу для пользователей

Онлайн-перестроение индексов в редакции Standard по-прежнему недоступно: в SQL Server 2025 онлайн-создание и перестроение индексов есть в Enterprise, а в Standard и Express — нет. Значит, в Microsoft SQL Server Standard задача перестроения идёт офлайн. Офлайн-операция, которая перестраивает кластеризованный или некластеризованный индекс, берёт на таблицу блокировку изменения схемы Sch-M. Пока операция идёт, доступ к таблице закрыт всем пользователям.

У задачи перестроения есть флажок «Keep index online while reindexing» — так он назван в английском интерфейсе мастера. Флажок включает опцию ONLINE, а онлайн-операции с индексами доступны не в каждой редакции SQL Server. В редакции Standard он не поможет: перестроение всё равно закроет таблицу. Ставьте эту задачу на окно, когда в 1С никто не работает.

Почему в этой статье нет процентов фрагментации

Правило «фрагментация 5–30 % — реорганизуем, свыше 30 % — перестраиваем» я до сих пор встречаю в чужих скриптах обслуживания. У Microsoft оно осталось в архивных версиях руководства по индексам. В действующей версии подход другой: решения об обслуживании индексов не должны опираться на одни лишь фиксированные пороги фрагментации и плотности страниц. Смотреть нужно на несколько факторов в контексте своей нагрузки, и ресурсная цена самого обслуживания — один из них.

Фиксированное расписание для обслуживания индексов не обязательно. Лучше следить за фрагментацией и плотностью страниц и запускать обслуживание индексов по мере необходимости, пока производительность не деградировала неприемлемо. Что дают реорганизация и перестроение именно вашим запросам, нужно замерить. Query Store — хороший способ сравнить производительность до обслуживания и после.

У перестроения индекса есть побочная польза: оно обновляет статистику по ключевым столбцам индекса, сканируя все его строки, — это эквивалент UPDATE STATISTICS ... WITH FULLSCAN. Улучшение после перестроения легко приписать ему самому: меньше фрагментация, выше плотность страниц. На деле ту же пользу часто можно получить намного дешевле по ресурсам — обновить статистику и не перестраивать индексы.

Для базы 1С я бы начал с этого, а не с ежедневного перестроения всех индексов. Если перестроение ускоряет работу, попробуйте заменить его обновлением статистики: улучшение может оказаться похожим. Проверить замену можно замером на своих запросах — до обслуживания и после.

DBCC DBREINDEX и DBCC INDEXDEFRAG из старых скриптов

Если вы обслуживаете базы 1С скриптами, которые кто-то принёс много лет назад, поищите в них DBCC INDEXDEFRAG и DBCC DBREINDEX. В примерах 1С для MS SQL Server стоят обе: дефрагментация записана там как sp_msforeachtable N'DBCC INDEXDEFRAG (<имя базы данных>, ''?'')', реиндексация — как sp_msforeachtable N'DBCC DBREINDEX (''?'')'.

DBCC DBREINDEX и DBCC INDEXDEFRAG устарели: в одной из будущих версий SQL Server их уберут. В новых разработках ими пользоваться не надо, а перевод действующих скриптов на ALTER INDEX стоит запланировать. Замена прямая: ALTER INDEX ... REBUILD и ALTER INDEX ... REORGANIZE. В плане обслуживания то же самое делают штатные задачи «Перестроение индекса» и «Реорганизация индекса» мастера SSMS. Переписывая старый скрипт, посмотрите заодно, какие опции доступны на вашей версии сервера: RESUMABLE (возобновляемое перестроение) появился в SQL Server 2017 (14.x), OPTIMIZE_FOR_SEQUENTIAL_KEY — в SQL Server 2019 (15.x). Учтите и редакцию: в SQL Server 2025 возобновляемое онлайн-создание и перестроение индексов в Standard и Express недоступно.

Обновление статистики: порог автообновления и когда его не хватает

Microsoft SQL Server поддерживает статистику в актуальном состоянии сам, если у базы включена опция AUTO_UPDATE_STATISTICS. Занимается этим оптимизатор запросов. Он считает число изменений строк с момента последнего обновления статистики и сравнивает его с порогом, а порог зависит от количества строк в таблице. Если статистика могла устареть, оптимизатор обновляет её в тот момент, когда ею пользуется очередной запрос. Выключать опцию не надо: при OFF планы запросов могут стать неоптимальными, а производительность — упасть.

Порогов при этом два, и какой из них работает — зависит от версии сервера и от уровня совместимости базы.

• До SQL Server 2014 (12.x) включительно — фиксированный порог. Для постоянной таблицы с числом строк n > 500 это 500 + (0,20 × n). Пример: в таблице 20 000 строк → 500 + 0,2 × 20 000 = 4 500, статистика обновляется каждые 4 500 изменений.
• Начиная с SQL Server 2016 (13.x) при уровне совместимости базы 130 — динамический убывающий порог: MIN(500 + (0,20 × n), SQRT(1 000 × n)). Пример: в таблице 2 000 000 строк порог — минимум из 400 500 и 44 721, то есть статистика обновляется каждые 44 721 изменение.

Таблицы 1С почти всегда постоянные и почти всегда крупнее 500 строк, то есть попадают под формулу для n > 500 — и в старом фиксированном пороге, и в новом динамическом. С новой формулой статистика больших таблиц обновляется чаще. Но если уровень совместимости базы ниже 130, действуют пороги SQL Server 2014. База, приехавшая на новый сервер из старой версии, может работать по старому порогу — уровень совместимости своей базы 1С стоит просто посмотреть. Для таких случаев есть флаг трассировки 2371. Он включает убывающий динамический порог в SQL Server с 2008 R2 (10.50.x) по 2014 (12.x), а в SQL Server 2016 (13.x) и новее — у баз с уровнем совместимости 120 и ниже.

Автообновления хватает не всегда. Подумать о ручном обновлении статистики стоит в трёх случаях: запросы выполняются медленно; вставка идёт по возрастающему или убывающему ключу; прошли операции обслуживания. Второй случай — про базы 1С: по моему опыту, таблицы движений растут именно так.

У случая «после обслуживания» есть оговорка. После ALTER INDEX REBUILD, DBCC DBREINDEX, DBCC INDEXDEFRAG и ALTER INDEX REORGANIZE обновлять статистику отдельно не нужно: перестроение, дефрагментация и реорганизация индекса не меняют распределение данных. При перестроении статистика обновляется сама — это побочный эффект пересоздания индекса. После реорганизации оптимизатор её не обновляет.

DBCC FREEPROCCACHE: для чего нужен и чем чреват

DBCC FREEPROCCACHE — команда, которая удаляет либо все элементы кэша планов запросов, либо один конкретный план по его хендлу, либо все записи кэша, связанные с указанным пулом ресурсов. В план обслуживания базы 1С она ставится задачей «Выполнение инструкции T-SQL»: готовой задачи очистки кэша в «Панели элементов» конструктора нет.

Чистить кэш планов нужно осторожно. Очистка вытесняет все планы, и под каждый входящий запрос сервер компилирует новый: взять готовый уже неоткуда. Число компиляций растёт, и скорость выполнения запросов может внезапно и временно упасть.

DBCC FREEPROCCACHE не «ускоряет сервер», а заставляет его перекомпилировать планы заново. Дальше моя оценка. В ночном окне обслуживания это приемлемая плата за то, что сервер перестанет использовать устаревшие планы. А вот запускать dbcc freeproccache руками в рабочее время, «чтобы 1С побыстрее работала», — плохая идея.

Ещё четыре детали о DBCC FREEPROCCACHE:

• На каждый очищенный cachestore в кэше планов SQL Server пишет в журнал ошибок сообщение «SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to 'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE' operations», и логируется оно раз в пять минут, пока кэш продолжают чистить. Если такие записи в журнале ошибок есть, а задачи очистки в плане обслуживания нет, значит, одну из двух названных в сообщении команд кто-то выполняет помимо плана.
• Процедурный кэш неявно очищает изменение целого ряда серверных настроек: access check cache bucket count, access check cache quota, clr enabled, cost threshold for parallelism, cross db ownership chaining, index create memory, max degree of parallelism, max server memory, max text repl size, max worker threads, min memory per query, min server memory, query governor cost limit, query wait, remote query timeout, user options.
• Начиная с SQL Server 2016 (13.x) есть команда, очищающая кэш планов только текущей базы, а не всего экземпляра: ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE. По моему опыту, на сервере, где рядом с базой 1С живут другие базы, это аккуратнее.
• Право на выполнение: ALTER SERVER STATE на сервере.

Почему очистка кэша стоит в плане сразу после обновления статистики, объясняет 1С. Если статистику обновили, а процедурный кэш не очистили, SQL Server может выбрать из кэша старый, неоптимальный план запроса вместо того, чтобы построить новый, более оптимальный. Отсюда и рекомендация: после обновления статистик очищать кэш всегда. На неё опирается порядок «сначала статистика, потом очистка кэша», который стоит в нашем плане с 2019 года.

Резервное копирование: модель восстановления решает, какие копии осмысленны

Тип копии в задаче резервного копирования выбирается не по вкусу, а по модели восстановления базы. Модель восстановления — это свойство базы данных. Оно управляет тем, как логируются транзакции, требуется ли и допускается ли резервное копирование журнала транзакций и какие операции восстановления доступны. Моделей три.

• simple — резервные копии журнала транзакций не поддерживаются. Движок сам освобождает место в журнале; восстановиться можно только на момент окончания резервной копии. Копия типа «Журнал транзакций» при этой модели неприменима.
• full — резервные копии журнала транзакций обязательны. Зато доступно восстановление на произвольный момент времени. Обратная сторона: журнал транзакций растёт до тех пор, пока не сделают его резервную копию. Потому при full-модели задача с типом «Журнал транзакций» и попадает в план обслуживания.
• bulk-logged — копии журнала тоже обязательны. Это вариант full с минимальным логированием большинства массовых операций; восстановление на произвольный момент не поддерживается, копии журнала могут быть большими.

По умолчанию редакции Enterprise и Standard используют модель full, а Express — simple. Проверить модель конкретной базы 1С стоит до того, как включать в план копию журнала транзакций: при simple вы просто не получите то, за чем эту задачу добавляли.

Что о регламентных операциях рекомендует сама 1С

У 1С есть собственный регламент обслуживания СУБД — «Регламентные операции на уровне СУБД для MS SQL Server». Он написан для клиент-серверной «1С:Предприятия 8» и открывается по подписке 1С:ИТС, после входа в личный кабинет. В нём четыре регламентные операции: обновление статистик и следом очистка процедурного КЭШа, дефрагментация индексов, реиндексация таблиц. Резервного копирования среди них нет — задачу копирования мы держим в том же плане по своей практике.

Регламентные процедуры должны выполняться автоматически, и рекомендованный для этого инструмент — встроенный в MS SQL Server Maintenance Plan. Это тот же план обслуживания, что собран в пошаговой части статьи.

Периодичность в регламенте 1С

Обновление статистик — не реже одного раза в день, с включённой опцией Full Scan. Команда для этого — exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'. Одинаково обслуживать все таблицы не обязательно. В реально работающей системе разным таблицам нужна разная частота обновления статистик, и по планам запросов видно, каким таблицам оно нужно чаще. Тогда вместо одной регламентной процедуры можно настроить две или больше: для часто обновляемых таблиц и для всех остальных.

Частота очистки процедурного КЭШа привязана к статистике: DBCC FREEPROCCACHE выполняют непосредственно после её обновления и так же часто. В плане обслуживания это задача Execute T-SQL Statement Task, присоединённая стрелкой к задаче Update Statistics Task внутри одного субплана. На снимках нашего стенда связка та же: «Обновление статистики», а следом «Выполнение инструкции T-SQL».

Дефрагментация индексов — не реже одного раза в неделю, а при высокой изменчивости данных в базе ещё чаще, до одного раза в день. Таблицы дефрагментация не блокирует и работе других пользователей не мешает, но создаёт дополнительную нагрузку на SQL Server.

Реиндексация таблиц — во время минимальной нагрузки на систему, не реже одного раза в неделю. Время выбрано не случайно: реиндексация блокирует таблицы на всё время своей работы, и это может существенно сказаться на работе пользователей. И деталь, которая экономит ночное окно: после реиндексации делать дефрагментацию индексов не нужно.

Раз в день и раз в неделю — стартовые значения, а не догма. Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путём. Частоту дефрагментации подбирают по нагрузке на систему и по эффекту, который дефрагментация даёт. Дальше каждую цифру проверяют на своей базе.

Оговорка для платформы 8.3.22 и новее

Оговорка привязана к версии самой платформы «1С:Предприятие» и касается дефрагментации индексов:

«Важно! Начиная с версии платформы 8.3.22 необходимо выполнять дефрагментацию индексов по следующему алгоритму:
До дефрагментации индекса необходимо включить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);
Выполнить дефрагментацию.
Обратно выключить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON);»

Если в плане стоит задача «Реорганизация индекса», а платформа у вас 8.3.22 или новее, прочитайте этот алгоритм внимательно: дефрагментацию нужно обрамить включением и обратным выключением страничных блокировок.

Контроль выполнения

Выполнение регламентных процедур на уровне СУБД нужно регулярно контролировать: вовремя ли они прошли и правильно ли. Смотрят это в истории плана обслуживания: успешные задачи и задачи с ошибками помечены своими значками, а по задаче с ошибкой доступна подробная информация. В английском интерфейсе пункт меню называется «View History»; в русской SSMS на нашем стенде тот же пункт контекстного меню плана подписан «Просмотр журнала».

График регламентных операций: отправная точка

График регламентных операций для базы 1С в Microsoft SQL Server — отправная точка, а не готовый ответ. Периодичность четырёх операций в нём взята у 1С, остальные четыре строки — наша практика; чья строка, сказано в последнем столбце.

Сам план мы запускаем не реже одного раза в сутки, в часы минимальной загруженности сервера. Если нужны более частые резервные копии или, наоборот, редкое полное перестроение индексов раз в неделю — это делается отдельными вложенными планами с собственными расписаниями; двигать ради этого всё окно обслуживания не нужно.

Регламентные операции — работа постоянная: расписание, которое собрали один раз, через год живёт уже с другой базой. Если вести эту работу некому, она входит в нашу услугу «Сопровождение 1С»: в «+Альянсе» мы берём на себя обновления, консультации пользователей, резервные копии и разбор ошибок.

Что осталось за скобками

Регламент 1С отвечает на вопрос «что и как часто». Как это собрать в вашей версии SSMS, он не покажет: примеры настройки в нём даны для MS SQL Server 2005, и порядок галочек оттуда — иллюстрация, а не инструкция. Состав операций и стартовую периодичность берите из него, а инструмент выбирайте по своей версии сервера: штатные задачи «Реорганизация индекса» и «Перестроение индекса» мастера той SSMS, что стоит у вас, либо команды ALTER INDEX вместо устаревших DBCC DBREINDEX и DBCC INDEXDEFRAG. Пошаговую часть этой статьи мы собирали на своём стенде с SQL Server 2017. Пересказ здесь выборочный: если подписка 1С:ИТС у вас есть, прочитайте первоисточник целиком.

Статья написана только про Microsoft SQL Server — про PostgreSQL здесь нет ничего. И она про типовую инсталляцию, где план обслуживания успевает отработать за ночное окно; для баз, которым окна уже не хватает, разговор начинается не с мастера SSMS, а с замеров.

Частые вопросы

DBCC FREEPROCCACHE — для чего он нужен?
Команда удаляет из кэша планов все планы запросов (или один конкретный, или все планы пула ресурсов), чтобы сервер перестал использовать устаревшие. Цена — перекомпиляция: готовых планов в кэше больше нет, сервер строит новый под каждый запрос, и на это время запросы могут внезапно замедлиться. Поэтому место этой команды — в плане обслуживания в часы минимальной нагрузки, а не в рабочем дне.

Чем реиндексация отличается от реорганизации индекса?
Реорганизация (ALTER INDEX ... REORGANIZE) дефрагментирует листовой уровень индекса и всегда выполняется online. Перестроение (ALTER INDEX ... REBUILD) удаляет и создаёт индекс заново. Онлайн-режима для него в редакции Standard нет, в SQL Server 2025 тоже, поэтому перестроение идёт офлайн и на время операции закрывает доступ к таблице всем пользователям. Начинайте с реорганизации; перестраивайте, когда на это есть конкретная причина.

Как перестроить индексы всей базы?
Через штатную задачу «Перестроение индекса» в плане обслуживания: она выполняет ALTER INDEX ... REBUILD PARTITION по расписанию для выбранных в задаче баз. Отдельный скрипт для этого не нужен. А вот DBCC DBREINDEX и DBCC INDEXDEFRAG из старых скриптов устарели — вместо них пишут ALTER INDEX.

Нужно ли обновлять статистику после перестроения индексов?
Нет: перестроение само обновляет статистику, сканируя все строки индекса, а реорганизация распределение данных не меняет вовсе, так что отдельное обновление «для порядка» в обоих случаях избыточно. Поводов подумать об обновлении статистики три: медленное выполнение запросов, вставка по возрастающему или убывающему ключу и обслуживание базы. Из третьего повода ALTER INDEX REBUILD, DBCC DBREINDEX, DBCC INDEXDEFRAG и ALTER INDEX REORGANIZE исключены.

Какую периодичность регламентных операций рекомендует 1С?
Рекомендации 1С для MS SQL Server такие: статистику — обновлять ежедневно или чаще и обязательно с включённой опцией Full Scan; процедурный КЭШ — очищать сразу после обновления статистики, с той же частотой; дефрагментацию индексов — выполнять как минимум раз в неделю, а на базах с высокой изменчивостью данных вплоть до ежедневной; реиндексацию таблиц — раз в неделю или чаще, в часы минимальной нагрузки на систему. Это стартовые значения. Частоту подбирают под свою нагрузку: для статистики экспериментально, для дефрагментации по получаемому эффекту.

Как часто запускать план обслуживания базы 1С?
Наша практика — один запуск в сутки как минимум, в окно с наименьшей нагрузкой на сервер; операции с другой периодичностью разносятся по вложенным планам со своими расписаниями. Стартовая периодичность отдельных операций взята из рекомендаций 1С: статистика — не реже раза в день, индексные операции — не реже раза в неделю. Для индексов жёсткое расписание при этом не обязательно. Удачнее смотреть на фрагментацию и плотность страниц и обслуживать индексы тогда, когда это нужно, не дожидаясь неприемлемого падения производительности. Эффект проверяйте замером через Query Store.

Почему план обслуживания перестал запускаться после перезагрузки сервера?
Первое, что стоит проверить, — службу «Агент SQL Server»: планы обслуживания выполняет именно она, и тип запуска у неё в оснастке «Службы» должен быть «Автоматически». Второе — журнал: «Управление» → «Планы обслуживания» → правая кнопка → «Просмотр журнала». Третье — права: узел «Планы обслуживания» и управление ими доступны только участникам роли sysadmin.

Александр Жогов, основатель и руководитель «+Альянс».