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

Первая редакция этой страницы вышла 22 ноября 2019 года — и в ней было расхождение, из-за которого страницей неудобно пользоваться как шпаргалкой. В тексте мы писали, что реорганизацию индекса имеет смысл делать каждый день, а в таблице ниже у реорганизации и у перестроения стояла одна и та же периодичность: не реже одного раза в неделю. Два разных ответа на один вопрос в одном документе. Фразу про ежедневную реорганизацию мы убрали и заменять её другой цифрой не стали: действующая документация Microsoft SQL Server просит не привязывать обслуживание индексов ни к фиксированному проценту фрагментации, ни к фиксированному расписанию. График в конце статьи остался, но теперь он честно назван отправной точкой, которую подгоняют под свою базу.

Порядок сборки плана в SQL Server Management Studio остался — за ним сюда и приходят. К нему добавилось то, чего на странице не было вовсе: что делает DBCC FREEPROCCACHE и чем эта команда чревата на боевом сервере, чем отличается перестроение индекса от реорганизации в редакции Standard, как работает порог автообновления статистики и при какой модели восстановления копия типа «Журнал транзакций» вообще имеет смысл.

Обновлено 7 сентября 2026 года. Все цитаты документации Microsoft сверены 6 сентября 2026 года по действующим страницам learn.microsoft.com (moniker ver17 — это SQL Server 2025); у каждой цитаты ниже указан раздел, из которого она взята.

Коротко

• Порядок задач, по которому мы собираем план обслуживания базы «1С:Предприятие 8»: проверка целостности → индексы → обновление статистики → очистка процедурного кэша → резервное копирование → очистка после обслуживания → очистка журнала.
• Действующая документация Microsoft SQL Server не даёт числового порога фрагментации для выбора между REORGANIZE и REBUILD и предлагает измерять эффект обслуживания, например через Query Store (сверено 06.09.2026).
• В действующей таблице возможностей SQL Server 2025 у редакции Standard онлайн-перестроение индекса отмечено как недоступное: REBUILD без ONLINE = ON берёт на таблицу блокировку Sch-M и закрывает пользователям доступ к ней на всё время операции (сверено 06.09.2026).
• DBCC FREEPROCCACHE удаляет из кэша все планы запросов, после чего каждый входящий запрос компилируется заново; документация Microsoft предупреждает о внезапном временном падении скорости выполнения запросов.
• Копия типа «Журнал транзакций» осмысленна при моделях восстановления full и bulk-logged; модель simple бэкап журнала транзакций не поддерживает вовсе.

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

План обслуживания — это набор задач администрирования базы данных, который служба 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), то есть Microsoft SQL Server 2017 RTM, обслуживаемая база называется testbase.

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

   

   

   

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

   

   

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

   

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

   

5. После индексных задач — «Обновление статистик», связь «Завершение».

   

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

   

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

   

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

   

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

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

   

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

    

    

И последнее. По моему опыту, забывают именно об этом: за выполнение планов обслуживания отвечает служба «Агент 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» на странице мастера «Define Rebuild Index Task» включает как раз ONLINE. Документация мастера тут же оговаривает: «Online index operations aren't available in every edition of SQL Server». То есть в редакции Standard флажок вам не поможет: перестроение всё равно закроет таблицу, и ставить его нужно в окно, когда в 1С никто не работает.

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

Если вы когда-то запомнили правило «фрагментация 5–30 % — реорганизуем, свыше 30 % — перестраиваем», то в документации Microsoft найти его сегодня можно только в архивных версиях страницы (раздел previous-versions/sql/sql-server-2008…); в чужих скриптах обслуживания я встречаю его до сих пор. В действующей версии страницы reorganize-and-rebuild-indexes, которая обновляется по сей день, на этом месте стоит прямо противоположная по духу врезка:

«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.»

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

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

Если вы обслуживаете базы 1С скриптами, которые кто-то принёс много лет назад, там почти наверняка встретятся DBCC DBREINDEX и DBCC INDEXDEFRAG. Документация 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). Замена прямая: ALTER INDEX ... REBUILD и ALTER INDEX ... REORGANIZE. Переписывая старый скрипт, посмотрите заодно, какие опции доступны на вашей версии сервера: 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 (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 строк, так что на новой формуле статистика по крупным регистрам обновляется заметно чаще. Но документация делает важную оговорку: «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».

Условия, при которых стоит обновить статистику вручную, документация тоже даёт списком: «Query execution times are slow. Insert operations occur on ascending or descending key columns. After maintenance operations». Второй пункт — это про вставку по возрастающему ключу, то есть ровно про то, как растут таблицы движений в 1С.

Отдельно стоит прочитать пояснение к третьему пункту, потому что оно противоречит привычной практике «после индексов всегда обновляем статистику»: «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».

Дальше — то, чего на этой странице не было с 2019 года. Справочник 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.»

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

Полезные детали со страницы dbcc-freeproccache-transact-sql, о которых обычно не знают:

• Каждая очистка кэша пишется в журнал ошибок 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 на сервере.

Почему очистка кэша стоит в плане именно после обновления статистики, документация 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». Журнал, который никто не бэкапит, будет расти, пока не кончится диск.
• bulk-logged — «The bulk-logged recovery model requires transaction log backups». Вариант full с минимальным логированием массовых операций; восстановление на произвольный момент не поддерживается, копии журнала могут быть большими.

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

Что о выборе модели восстановления для баз «1С:Предприятие 8» говорит сам разработчик платформы, мы здесь не приводим: дословной формулировки его методической поддержки у нас нет.

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

Таблица ниже — график, который стоял на этой странице с 2019 года. Ни нормой разработчика платформы, ни требованием Microsoft она не является. В редакции 2019 года у таблицы стояла подпись «периодичность, рекомендуемая разработчиками „1С:Предприятие 8“»; подтверждённого первоисточника под эту подпись у нас нет, поэтому подпись снята. Пользоваться таблицей как отправной точкой можно, но помните, что действующая документация Microsoft SQL Server советует смотреть на замер, а не на календарь.

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

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

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

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

Ещё две границы этого текста. Он только про 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 — нет: перестроение обновляет статистику по ключевым столбцам сканированием всех строк, а реорганизация распределение данных не меняет вовсе, так что отдельное обновление «для порядка» в обоих случаях избыточно. Отдельная задача обновления статистики нужна по другим причинам: медленные запросы, вставка по возрастающему ключу, массовые изменения данных.

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

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

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

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

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