При администрировании баз данных 1С:Предприятие на платформе MS SQL Server одной из самых распространенных задач является настройка планов обслуживания (Maintenance Plans). Однако новички и даже опытные администраторы часто сталкиваются с ситуацией, когда корректно настроенный план выдает неочевидную ошибку при запуске. Особенно остро эта проблема встала с выходом обновлений платформы 1С (начиная с версии 8.3.22), где изменились механизмы работы с блокировками. В данной статье мы подробно разберем, почему возникают сбои и как их устранить.
Рассмотрим важную техническую особенность современных версий платформы 1С. Начиная с версии 8.3.22, разработчики 1С внесли изменения в логику работы с СУБД: теперь система жестко требует, чтобы на уровне индексов SQL Server были разрешены страничные блокировки. Если в процессе выполнения плана обслуживания (например, при реорганизации или перестроении индексов) этот параметр изменяется, 1С может начать выдавать критические ошибки или вовсе блокировать работу пользователей.
Выясним причину: параметр ALLOW_PAGE_LOCKS должен быть установлен в значение ON. Если ваш план обслуживания сбрасывает его в OFF, это гарантированно приведет к проблемам. Проанализируем ситуацию и подготовим скрипты для исправления этой настройки. Для массового изменения параметров всех таблиц в базе данных удобно использовать недокументированную, но эффективную процедуру sp_msforeachtable.
Разберем по шагам, как принудительно установить нужные параметры блокировок перед выполнением основных задач обслуживания:
EXEC sp_msforeachtable 'ALTER INDEX ALL ON ? SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON)'
GO
Иногда администраторы пытаются отключать страничные блокировки после завершения обслуживания, чтобы «оптимизировать» нагрузку, используя следующий код:
EXEC sp_msforeachtable 'ALTER INDEX ALL ON ? SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON)'
GO
Внимание: Для версий 1С 8.3.22 и выше выполнение второго скрипта (установка OFF) категорически не рекомендуется, так как это приведет к ошибкам структуры таблиц в сеансах пользователей. Убедитесь, что в ваших сценариях обслуживания параметр ALLOW_PAGE_LOCKS всегда остается в состоянии ON.
Одной из самых банальных, но часто встречающихся причин сбоя плана обслуживания является недостаток прав у учетной записи, под которой работает служба SQL Server Agent. Посмотрим на ситуацию глазами системы: план обслуживания — это набор заданий, которые выполняются не от имени текущего пользователя (вас), а от имени сервиса.
Проанализируем следующие моменты:
MDF, LDF), папки для хранения бэкапов и временные директории (TEMP).sa. Если владельцем является доменная учетная запись, которая не имеет прав sysadmin на сервере SQL, выполнение плана завершится ошибкой.sa. Если в этом случае всё проходит успешно, значит, проблема точно в правах доступа службы агента.Планы обслуживания в MS SQL Server технически представляют собой пакеты SQL Server Integration Services (SSIS). Если при установке SQL Server вы пропустили установку компонента «Integration Services» или «Client Tools Backward Compatibility», планы могут создаваться в графическом интерфейсе, но не запускаться фактически. Проверьте наличие этих компонентов в инсталляторе SQL Server.
Также разберем настройку системных опций SQL Server. Для работы заданий агента должна быть включена опция Agent XPs. Проверим и включим её с помощью следующих команд:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'Agent XPs', 1;
RECONFIGURE;
Без активации этой настройки SQL Server Agent не сможет корректно взаимодействовать с подсистемами выполнения планов, что приведет к мгновенному сбою при попытке запуска.
Стандартное сообщение «Ошибка при выполнении плана» в SSMS крайне малоинформативно. Чтобы выяснить истинную причину, нам необходимо обратиться к расширенным логам. Рассмотрим подробнее, как это сделать:
0x80131904) или текстовое описание, указывающее на конкретную таблицу или файл, вызвавший сбой.Проанализируем ситуацию, если лог пуст или обрывается. Это часто свидетельствует о нехватке места в базе tempdb или в логе транзакций обслуживаемой базы данных. Операции с индексами генерируют огромный объем записей в лог. Убедитесь, что на дисках достаточно свободного места и настройки авторасширения файлов позволяют им расти.
В современных версиях SQL Server Management Studio (особенно 18.x и 19.x) замечены баги, связанные с визуальным конструктором планов. Иногда при редактировании существующего плана его внутренняя XML-структура повреждается. Рассмотрим решение: если вы перепробовали настройки прав и блокировок, но ошибка сохраняется, попробуйте создать абсолютно новый план обслуживания с нуля, не копируя элементы из старого. В некоторых случаях более надежным решением будет отказ от графического конструктора в пользу создания обычного SQL Agent Job, в котором задачи будут описаны в виде T-SQL скриптов.
Подведем итог: стабильная работа плана обслуживания баз 1С требует комплексного подхода — от соблюдения требований платформы по страничным блокировкам ALLOW_PAGE_LOCKS до тонкой настройки прав службы SQL Agent и мониторинга свободного места на дисках. Следуя этим шагам, вы сможете локализовать и устранить большинство причин возникновения ошибок.