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

Первая редакция этой страницы вышла 22 ноября 2019 года — и в ней было расхождение, из-за которого страницей неудобно пользоваться как шпаргалкой. В тексте мы писали, что реорганизацию индекса имеет смысл делать каждый день, а в таблице ниже у реорганизации и у перестроения стояла одна и та же периодичность: не реже одного раза в неделю. Два разных ответа на один вопрос в одном документе. Теперь расхождение снято, и снято не нашим решением: в методической поддержке 1С у дефрагментации индексов стоит «не реже одного раза в неделю, а при высокой изменчивости данных в базе еще чаще – до одного раза в день». Оба числа со страницы 2019 года оказались частями одной рекомендации — неделя как нижняя граница и день для баз с высокой изменчивостью данных. Условия про изменчивость в редакции 2019 года не было ни в тексте, ни в таблице, отсюда и спор двух чисел.

Порядок сборки плана в SQL Server Management Studio остался — за ним сюда и приходят. К нему добавилось то, чего на странице 2019 года не было. Регламент 1С с цитатами и ссылкой на первоисточник. Разбор DBCC FREEPROCCACHE: зачем чистить кэш сразу после обновления статистики и чем эта команда чревата на боевом сервере. Порог автообновления статистики и модели восстановления: при какой из них копия типа «Журнал транзакций» вообще имеет смысл. А фраза про отключение клиентов в редакции Standard на странице стояла и в 2019 году; теперь она привязана к редакции и версии: строка «Online index create and rebuild» из таблицы возможностей SQL Server 2025 и блокировка Sch-M из справочника alter-index-transact-sql. График в конце статьи остался, и у каждой строки теперь указано, чья это периодичность. И 1С, и Microsoft в своих текстах просят проверять частоту на собственной базе, так что календарь из таблицы — это старт работы, а не её ответ.

Обновлено 7 сентября 2026 года. Цитаты документации Microsoft сверены 6 сентября 2026 года по действующим страницам learn.microsoft.com (moniker ver17 — это SQL Server 2025). Цитаты 1С сняты 7 сентября 2026 года со страницы методической поддержки для разработчиков и администраторов «1С:Предприятия 8»; дата самой страницы — 18.11.2022, доступ к ней — по подписке 1С:ИТС.

Коротко

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

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

План обслуживания — это набор задач администрирования базы данных, который служба SQL Server Agent запускает по расписанию с заданным интервалом. Документация Microsoft описывает мастер планов так: «The Maintenance Plan Wizard creates a maintenance plan that SQL Server Agent can run regularly. You can perform various database administration tasks, including backups, database integrity checks, or database statistics updates, at specified intervals» (use-the-maintenance-plan-wizard, сверено 06.09.2026). В разделе Permissions страницы use-the-maintenance-plan-wizard указано право доступа: создавать планы обслуживания и видеть узел «Планы обслуживания» в обозревателе объектов может только участник серверной роли sysadmin.

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

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

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

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

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

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

   

   

   

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

   

   

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

   

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

   

5. «Обновление статистики», связь «Завершение». Периодичность у этой задачи своя, от разработчика платформы, а не производная от индексных операций: обновлять статистику методическая поддержка 1С рекомендует не реже раза в день и полным сканированием (страница «Регламентные операции на уровне СУБД для MS SQL Server» от 18.11.2022, доступ по подписке 1С:ИТС, сверено 07.09.2026).

   

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

   

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

   

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

   

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

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

   

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

   

   

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

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

Обе задачи есть в мастере планов обслуживания, но стоят они очень по-разному. Реорганизация дешевле по ресурсам, и документация Microsoft прямо называет её предпочтительным способом обслуживания: «Reorganizing an index is less resource intensive than rebuilding an index. For that reason it should be your preferred index maintenance method, unless there's a specific reason to use index rebuild. Reorganize is always an online operation» (раздел «Reorganize an index»). Для rowstore-индексов в таблицах и представлениях движок дефрагментирует только листовой уровень кластеризованных и некластеризованных индексов, физически переупорядочивая листовые страницы так, чтобы их порядок совпадал с логическим.

Перестроение удаляет индекс и создаёт его заново, а блокировки зависят от режима: «Rebuilding an index drops and re-creates the index. Depending on the type of index and the Database Engine version, a rebuild operation can be done offline or online. An offline index rebuild usually takes less time than an online rebuild, but it holds object-level locks for the duration of the rebuild operation, blocking queries from accessing the table or view» (раздел «Rebuild an index»).

Источник таблицы — разделы «Reorganize an index», «Rebuild an index» и «Statistics update during index build» страницы reorganize-and-rebuild-indexes (ms.date: 2026-03-11), сверено 06.09.2026.

Standard: перестроение отключит пользователей от базы

Фраза из редакции 2019 года про отключение клиентов подтверждается действующей документацией, поэтому она осталась, но теперь с привязкой к редакции и версии. В таблице возможностей SQL Server 2025 строка «Online index create and rebuild» выглядит так: Enterprise — Yes, Standard — No, Express — No (сверено 06.09.2026). Значит, в Microsoft SQL Server Standard задача перестроения идёт офлайн, а последствия офлайн-режима справочник alter-index-transact-sql описывает дословно: «Table locks are applied for the duration of the index operation. An offline index operation that creates, rebuilds, or drops a clustered, spatial, or XML index, or rebuilds or drops a nonclustered index, acquires a schema modification (Sch-M) lock on the table. This prevents all user access to the underlying table for the duration of the operation» (раздел ONLINE = { ON | OFF }).

Флажок «Keep index online while reindexing» включает как раз ONLINE — так эту опцию описывает страница «Define Rebuild Index Task» в действующей документации мастера планов обслуживания Microsoft для SQL Server 2025 (сверено 06.09.2026). Там же оговорка: «Note: Online index operations aren't available in every edition of SQL Server». То есть в редакции Standard флажок не поможет: перестроение всё равно закроет таблицу, и планировать эту задачу нужно на окно, когда в 1С никто не работает.

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

Правило «фрагментация 5–30 % — реорганизуем, свыше 30 % — перестраиваем» в документации Microsoft сегодня живёт в архивных версиях страницы reorganize-and-rebuild-indexes, по адресу previous-versions/sql/sql-server-2008…. В чужих скриптах обслуживания я встречаю его до сих пор. В действующей версии той же страницы, которая обновляется по сей день, старое правило заменено прямо противоположной по духу рекомендацией из раздела «What to consider before performing index maintenance»:

«Important: Index maintenance decisions should be made after considering multiple factors in the specific context of each workload, including the resource cost of maintenance. They shouldn't be based on fixed fragmentation or page density thresholds alone.»

Раздел «Index maintenance strategy» страницы reorganize-and-rebuild-indexes высказывается о расписании: «…don't assume that maintenance must be performed on a fixed schedule. A better strategy is to monitor fragmentation and page density, and run index maintenance as needed before performance degrades unacceptably». Вместо порога документация предлагает замер: «Measure the specific impact of reorganizing or rebuilding indexes on query performance in your workload. Query Store is a good way to measure the "before maintenance" and "after maintenance" performance…».

В разделе «A positive side effect of index rebuild» страницы reorganize-and-rebuild-indexes объясняется, почему перестроение так часто «помогает», хотя дело не в фрагментации:

«An index rebuild has an important benefit: it updates statistics on key columns of the index by scanning all rows in the index. This is the equivalent of executing UPDATE STATISTICS ... WITH FULLSCAN… Customers often incorrectly attribute this improvement to the index rebuild itself, taking it to be result of reduced fragmentation and increased page density. In reality, the same benefit can often be achieved at a much lower resource cost by updating statistics instead of rebuilding indexes.»

Раздел «Index maintenance strategy» страницы reorganize-and-rebuild-indexes предлагает попробовать замену одной операции другой: «If you observe that rebuilding indexes improves performance, try replacing it with updating statistics. This can result in a similar improvement». Моя позиция как автора: для базы 1С это первое, что стоит попробовать вместо ежедневного перестроения всех индексов, а проверить замену можно замером на своих запросах — до обслуживания и после.

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

DBCC DBREINDEX и DBCC INDEXDEFRAG стоят в примерах методической поддержки 1С на странице «Регламентные операции на уровне СУБД для MS SQL Server» (18.11.2022, доступ по подписке 1С:ИТС, сверено 07.09.2026): дефрагментация приведена как sp_msforeachtable N'DBCC INDEXDEFRAG (<имя базы данных>, ''?'')', реиндексация — как sp_msforeachtable N'DBCC DBREINDEX (''?'')'. Если вы обслуживаете базы 1С скриптами, которые кто-то принёс много лет назад, поищите в них эти две команды.

Документация Microsoft называет обе команды устаревшими, дословно и одинаково на страницах dbcc-dbreindex-transact-sql и dbcc-indexdefrag-transact-sql: «This feature will be removed in a future version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Use ALTER INDEX instead» (ms.date: 2022-12-05, updated_at: 2026-08-24, сверено 06.09.2026). Замена прямая: ALTER INDEX ... REBUILD и ALTER INDEX ... REORGANIZE. В плане обслуживания то же самое делают штатные задачи «Перестроение индекса» и «Реорганизация индекса» мастера SSMS. Переписывая старый скрипт, посмотрите заодно, какие опции доступны на вашей версии сервера: RESUMABLE (возобновляемое перестроение) появился в SQL Server 2017 (14.x), OPTIMIZE_FOR_SEQUENTIAL_KEY — в SQL Server 2019 (15.x). Обе версии указаны тегами «Applies to» в справочнике alter-index-transact-sql (сверено 06.09.2026).

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

Microsoft SQL Server поддерживает статистику в актуальном состоянии сам, если у базы включена опция AUTO_UPDATE_STATISTICS. Занимается этим оптимизатор запросов: по странице statistics документации Microsoft он определяет, когда статистика могла устареть, и обновляет её в момент, когда ею пользуется очередной запрос. Механика такая: оптимизатор считает число изменений строк с момента последнего обновления статистики и сравнивает его с порогом, а порог зависит от количества строк в таблице. Про выключение опции страница statistics (ms.date: 2026-06-12, сверено 06.09.2026) высказывается недвусмысленно: «Setting AUTO_UPDATE_STATISTICS to OFF can cause suboptimal query plans and degraded query performance. Set the AUTO_UPDATE STATISTICS option to ON».

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

• До 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 — и в старом фиксированном пороге, и в новом динамическом. Про новую формулу документация Microsoft на странице statistics пишет так: «With this change, statistics on large tables are updated more frequently». Там же — оговорка про уровень совместимости: «if a database has a compatibility level below 130, the SQL Server 2014 (12.x) thresholds apply». База, приехавшая на новый сервер из старой версии, может работать по старому порогу — уровень совместимости своей базы 1С стоит просто посмотреть. Для промежуточных версий есть отдельный механизм: «In SQL Server 2008 R2 (10.50.x) through SQL Server 2014 (12.x), or in SQL Server 2016 (13.x) and later versions with database compatibility level 120 and lower versions, enable trace flag 2371 so that SQL Server uses a decreasing, dynamic statistics update threshold».

Условия, при которых стоит обновить статистику вручную, страница statistics даёт списком в разделе «Detect out-of-date statistics»:

«Consider updating statistics for the following conditions: — Query execution times are slow. — Insert operations occur on ascending or descending key columns. — After maintenance operations.»

Условие «Insert operations occur on ascending or descending key columns» — это про вставку по возрастающему или убывающему ключу. По моему опыту, таблицы движений в базах 1С растут именно так.

Условие «After maintenance operations» документация Microsoft объясняет одноимённым разделом страницы statistics: после ALTER INDEX REBUILD, DBCC DBREINDEX, DBCC INDEXDEFRAG и ALTER INDEX REORGANIZE обновлять статистику отдельно не нужно. Дословно: «Operations such as rebuilding, defragmenting, or reorganizing an index don't change the distribution of data. Therefore, you don't need to update statistics after performing ALTER INDEX REBUILD, DBCC DBREINDEX, DBCC INDEXDEFRAG, or ALTER INDEX REORGANIZE operations». Логика простая: перестроение уже обновило статистику как побочный эффект пересоздания индекса, а реорганизация распределение данных вообще не меняет.

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

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

Справочник dbcc-freeproccache-transact-sql (updated_at: 2026-08-24, сверено 06.09.2026) предупреждает о последствиях прямым текстом:

«Use DBCC FREEPROCCACHE to clear the plan cache carefully. Clearing the procedure (plan) cache causes all plans to be evicted, and incoming query executions will compile a new plan, instead of reusing any previously cached plan.»

«This can cause a sudden, temporary decrease in query performance as the number of new compilations increases.»

То есть команда не «ускоряет сервер», а заставляет его перекомпилировать планы заново — и это, по формулировке документации Microsoft («can cause»), может вызвать внезапное временное падение скорости выполнения запросов, пока растёт число новых компиляций. Тут я говорю уже от себя, а не от документации: в ночном окне обслуживания это приемлемая плата за то, что сервер перестанет использовать устаревшие планы, а вот запускать dbcc freeproccache руками в рабочее время, «чтобы 1С побыстрее работала», — плохая идея.

Ещё четыре детали со страницы dbcc-freeproccache-transact-sql:

• На каждый очищенный 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С — страница «Регламентные операции на уровне СУБД для MS SQL Server» (18.11.2022, доступ по подписке 1С:ИТС, сверено 07.09.2026). Дословно: «Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план». Отсюда и вывод 1С — «рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа». О связке «обновление статистики → очистка процедурного кэша» документация Microsoft не высказывается. Так что порядок «сначала статистика, потом очистка кэша», стоящий в нашем плане с редакции 2019 года, опирается теперь на регламент разработчика платформы.

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

Тип копии в задаче резервного копирования выбирается не по вкусу, а по модели восстановления базы. Модель восстановления, по определению страницы recovery-models-sql-server (ms.date: 2026-02-19, сверено 06.09.2026), — это свойство базы данных, которое управляет тем, как логируются транзакции, требуется ли и допускается ли резервное копирование журнала транзакций и какие операции восстановления доступны. Моделей три, и про журнал транзакций каждая говорит своё:

• simple — «The simple recovery model doesn't support transaction log backups». Движок сам освобождает место в журнале; восстановиться можно только на момент окончания резервной копии. Копия типа «Журнал транзакций» при этой модели неприменима.
• full — «The full recovery model requires transaction log backups». Восстановление на произвольный момент времени доступно, но есть обратная сторона: «In this recovery model, the transaction log continues to grow until you perform a transaction log backup». Журнал, который никто не бэкапит, так и будет расти, пока не сделают резервную копию журнала, — потому при full-модели задача с типом «Журнал транзакций» и попадает в план обслуживания.
• bulk-logged — «The bulk-logged recovery model requires transaction log backups». Вариант full с минимальным логированием массовых операций; восстановление на произвольный момент не поддерживается, копии журнала могут быть большими.

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

Регламент 1С в выборе модели восстановления не помощник: на странице методической поддержки «Регламентные операции на уровне СУБД для MS SQL Server» (18.11.2022, доступ по подписке 1С:ИТС, сверено 07.09.2026) перечислены четыре операции уровня СУБД, и модели восстановления среди них нет. Тип копии для базы 1С выбирают по документации Microsoft и по той модели, которая стоит у самой базы.

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

У разработчика платформы есть собственная инструкция по обслуживанию СУБД — страница «Регламентные операции на уровне СУБД для MS SQL Server» в методической поддержке для разработчиков и администраторов «1С:Предприятия 8» (its.1c.ru). Дата самой страницы — 18.11.2022; читается она по подписке 1С:ИТС, после входа в личный кабинет. Цитаты ниже сняты со страницы 7 сентября 2026 года.

Перечень у 1С такой:

«Для MS SQL Server рекомендуется выполнять следующие регламентные операции: Обновление статистик Очистка процедурного КЭШа Дефрагментация индексов Реиндексация таблиц базы данных»

Резервного копирования в этих четырёх пунктах нет — задачу копирования мы держим в том же плане по своей практике, а в регламенте 1С её искать не нужно. Зато есть требование к форме исполнения: «Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan.» (так в источнике). Тот самый мастер планов обслуживания SSMS, с которого начинается пошаговая часть этой статьи.

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

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

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

Дефрагментация индексов — не реже одного раза в неделю. Дословно: «Рекомендуется выполнять дефрагментацию индексов не реже одного раза в неделю». В разделе про настройку задачи Reorganize Index Task цифра уточнена: «Рекомендуется выполнять задачу не реже одного раза в неделю, а при высокой изменчивости данных в базе еще чаще – до одного раза в день». Про цену операции на той же странице сказано отдельно: дефрагментация «не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server».

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

Календарь и сама 1С догмой не считает — на той же странице частоту просят подбирать под систему. Про статистику: «Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем». Про индексы: «Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации». Читаю я обе формулировки буквально: цифра из регламента — старт, дальше её проверяют на своей базе. Это моя оценка, но слова «экспериментальным путем» и «эффектом, получаемым от дефрагментации» стоят в тексте 1С.

Оговорка для платформы 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 или новее, алгоритм из оговорки 1С стоит прочитать внимательно: 1С требует обрамить дефрагментацию включением и обратным выключением страничных блокировок.

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

Отдельным требованием у 1С стоит контроль: «Необходимо осуществлять регулярный контроль выполнения регламентных процедур на уровне СУБД», и на той же странице — «Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур». Смотреть 1С предлагает в истории плана обслуживания: «Успешно выполненные задачи и задачи, выполненные с ошибками, будут помечены соответствующими иконками. Для задач, выполненных с ошибками, доступна подробная информация об ошибке». На странице ИТС пункт меню назван по-английски, «View History»; в русской SSMS на нашем стенде тот же пункт контекстного меню плана подписан «Просмотр журнала».

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

Таблица ниже — график, который стоял на этой странице с 2019 года, теперь с указанием, откуда взята каждая строка. В редакции 2019 года у графика был подзаголовок «Периодичность выполнения регламентных операций, рекомендуемая разработчиками „1С: Предприятие 8“», и дан он был без ссылки на конкретную статью ИТС. У четырёх строк первоисточник теперь есть: это страница методической поддержки 1С «Регламентные операции на уровне СУБД для MS SQL Server» (18.11.2022, сверено 07.09.2026). В строке перестроения индекса к странице ИТС добавлены ещё два источника, по которым написан столбец «Зачем»: таблица возможностей SQL Server 2025 и справочник alter-index-transact-sql (сверено 06.09.2026). Остальные четыре строки — наша практика, и они так и помечены; отправной точкой таблица от этого быть не перестала.

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

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

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

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

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

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

DBCC FREEPROCCACHE — для чего он нужен?

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

Чем реиндексация отличается от реорганизации индекса?

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

Как перестроить индексы всей базы?

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

Нужно ли обновлять статистику после перестроения индексов?

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

Какую периодичность регламентных операций рекомендует 1С?

По странице методической поддержки «Регламентные операции на уровне СУБД для MS SQL Server» (18.11.2022, доступ по подписке 1С:ИТС, сверено 07.09.2026): статистику 1С просит обновлять ежедневно или чаще и обязательно с включённой опцией Full Scan; процедурный КЭШ — очищать сразу после обновления статистики, с той же частотой; дефрагментацию индексов — выполнять как минимум раз в неделю, а на базах с высокой изменчивостью данных вплоть до ежедневной; реиндексацию таблиц — раз в неделю или чаще, в часы минимальной нагрузки на систему. Саму частоту 1С там же просит подбирать под свою нагрузку: для статистики — «экспериментальным путем», для дефрагментации — по получаемому эффекту.

Как часто запускать план обслуживания базы 1С?

Наша практика — один запуск в сутки как минимум, в окно с наименьшей нагрузкой на сервер; операции с другой периодичностью разносятся по вложенным планам со своими расписаниями. Периодичность отдельных операций задана в регламенте 1С (статистика — не реже раза в день, индексные операции — не реже раза в неделю), а действующая документация Microsoft SQL Server просит не считать фиксированное расписание обязательным и не принимать решения об обслуживании индексов по одним лишь порогам фрагментации и плотности страниц. Более удачной стратегией документация Microsoft в разделе «Index maintenance strategy» называет наблюдение за фрагментацией и плотностью страниц и запуск обслуживания индексов по мере необходимости, пока производительность не деградировала неприемлемо. Отдельным пунктом того же раздела стоит замер: эффект реорганизации и перестроения индексов на своих запросах документация Microsoft предлагает мерить через Query Store.

Почему план обслуживания перестал запускаться после перезагрузки сервера?

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

Александр Жогов, основатель и руководитель «+Альянс». Текст обновлён 7 сентября 2026 года; цитаты документации Microsoft SQL Server сверены 6 сентября 2026 года, цитаты методической поддержки 1С — 7 сентября 2026 года.