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

← На главную

При работе с базами данных 1С:Предприятие на платформе MS SQL Server критически важно своевременно выполнять регламентные операции: создание резервных копий (бэкапов), дефрагментацию и реиндексацию таблиц, а также обновление статистики. Традиционно для автоматизации этих процессов системные администраторы используют встроенный инструмент СУБД — Агент SQL Server (SQL Server Agent).

Однако на практике часто возникает проблема, когда служба Агента упорно отказывается запускаться, выдавая неинформативные ошибки или сообщения вида: «SQLServerAgent could not be started (reason: Ошибка при создании нового сеанса)» или «SQLServerAgent must be able to connect to SQLServer as SysAdmin». В этой статье мы подробно разберем, почему возникает данная проблема, как настроить права учетных записей и как организовать обслуживание баз данных, если запуск Агента невозможен по техническим или лицензионным причинам.

Шаг 1. Диагностика редакции СУБД (Проблема SQL Server Express)

Самая распространенная причина, по которой Агент SQL Server не запускается — это использование бесплатной редакции SQL Server Express Edition. Начиная с ранних версий СУБД и заканчивая современными релизами, компания Microsoft программно блокирует работу службы Агента в бесплатной версии. Служба физически присутствует в списке установленных компонентов Windows, но при попытке запуска она сразу же останавливается.

Давайте выясним, какая именно редакция SQL Server установлена на вашем сервере. Для этого запустим среду SQL Server Management Studio (SSMS), откроем новое окно запроса и выполним следующий T-SQL код:


SELECT @@VERSION AS 'Полная информация о версии';
SELECT SERVERPROPERTY('Edition') AS 'Редакция СУБД';
SELECT SERVERPROPERTY('EngineEdition') AS 'Тип движка (3 = Personal/Standard, 4 = Express)';

Проанализируем полученный результат. Если в поле «Редакция СУБД» вы видите слово Express, то запустить Агент SQL Server стандартным способом не удастся. Это ограничение лицензии, и обойти его технически невозможно.

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

Ограничение на размер базы данных: файл данных (MDF) не может превышать 10 ГБ (для версий 2008 R2 и старше). При этом лог транзакций (LDF) под это ограничение не попадает, поэтому общий размер папки с базой на диске может быть больше 10 ГБ.
Ограничение на оперативную память: СУБД может использовать не более 1 ГБ (в версиях до 2014) или чуть более 1.4 ГБ (в версиях 2016+) оперативной памяти под буферный пул (кэш данных). Тем не менее общий процесс sqlservr.exe может потреблять больше памяти под нужды ОС, CLR и планов запросов.

Если вы столкнулись с ограничениями Express-версии, у вас есть два пути: осуществить переход на платную редакцию (например, Standard или Enterprise) или настроить регламентные задачи альтернативными методами.

Шаг 2. Альтернативная настройка обслуживания в SQL Server Express

Если перейти на полноценную версию SQL Server в данный момент невозможно, мы можем настроить резервное копирование и оптимизацию индексов 1С в обход службы Агента. Для этого мы свяжем стандартный Планировщик задач Windows (Task Scheduler) и консольную утилиту SQLCMD.

Давайте разберем по шагам, как настроить автоматический бэкап базы данных:

Создадим на сервере папку для хранения служебных скриптов, например, C:\SQL_Scripts\.
В этой папке создадим текстовый файл с именем backup_1c.sql. Откроем его и запишем T-SQL сценарий для создания резервной копии базы данных:
```
USE [master];
GO
BACKUP DATABASE [Имя_Вашей_Базы_1С]
TO DISK = N'D:\SQL_Backups\Base1C_Full.bak'
WITH FORMAT, INIT, 
NAME = N'Full Backup of 1C Database', 
SKIP, NOREWIND, NOUNLOAD, STATS = 10;
GO
```
Рядом создадим командный исполняемый файл run_backup.bat, который будет запускать наш SQL-скрипт через консоль:
```
@echo off
sqlcmd -S SERVERNAME\SQLEXPRESS -E -i "C:\SQL_Scripts\backup_1c.sql" >> "C:\SQL_Scripts\backup_log.txt" 2>&1
```
Примечание: параметр -S указывает имя вашего SQL-сервера и инстанса, -E задает авторизацию под текущей учетной записью Windows (Trusted Connection), а -i указывает путь к файлу с T-SQL кодом.
Откроем Планировщик задач Windows (команда taskschd.msc в строке выполнения).
Создадим простую задачу, укажем расписание выполнения (например, каждую ночь в 02:00) и выберем действие «Запуск программы», указав путь к нашему файлу run_backup.bat.
Важно: в свойствах задачи планировщика обязательно установите флаг «Выполнять с наивысшими правами» и укажите учетную запись администратора, имеющего права на запись в каталог бэкапов и права sysadmin на SQL-сервере.

Для более продвинутого обслуживания баз данных (включая проверку целостности и дефрагментацию индексов) мы рекомендуем использовать бесплатный пакет скриптов Олы Халленгрена (Ola Hallengren). Вы можете развернуть его процедуры в системной базе данных master, а затем аналогичным образом запускать их через планировщик Windows и утилиту SQLCMD:


sqlcmd -S SERVERNAME\SQLEXPRESS -E -Q "EXECUTE dbo.DatabaseBackup @Databases = 'USER_DATABASES', @Directory = 'D:\SQL_Backups', @BackupType = 'FULL'"

Шаг 3. Решение проблем с правами учетной записи (для редакций Standard / Enterprise)

Если вы точно удостоверились, что на сервере развернута редакция Standard или Enterprise, но Агент SQL Server по-прежнему выдает ошибку при запуске, проблема кроется в правах учетных записей операционной системы или СУБД. Давайте проанализируем основные требования к правам.

1. Наличие роли Sysadmin в СУБД

Учетная запись, от имени которой стартует служба Windows SQLServerAgent, должна обладать максимальными привилегиями внутри самого SQL Server. Если вы запускаете службу под локальной учетной записью (например, Local Service, Network Service) или под специально созданным доменным пользователем, этот пользователь должен быть добавлен в logins сервера с ролью sysadmin.

Давайте проверим и добавим пользователя через интерфейс SSMS:

Подключитесь к серверу под учетной записью администратора (например, под встроенной учеткой sa).
Разверните ветку Безопасность (Security) -> Имена входа (Logins).
Если учетной записи службы Агента нет в списке, нажмите правой кнопкой мыши по «Имена входа» и выберите «Создать имя входа» (New Login).
В появившемся окне укажите имя пользователя (например, доменного пользователя или виртуальную службу NT SERVICE\SQLSERVERAGENT).
Перейдите на вкладку Роли сервера (Server Roles) и обязательно отметьте галочкой роль sysadmin. Сохраните изменения.

2. Права в операционной системе Windows (Локальная политика безопасности)

Система безопасности Windows не позволит запустить службу, если учетная запись не имеет специального системного разрешения. Разберем, как его предоставить:

Нажмите сочетание клавиш Win + R, введите secpol.msc и нажмите Enter для открытия Локальной политики безопасности.
Перейдите по пути: Локальные политики (Local Policies) -> Назначение прав пользователя (User Rights Assignment).
Найдите политику Вход в качестве службы (Log on as a service) и дважды кликните по ней.
Нажмите кнопку «Добавить пользователя или группу» и введите имя вашей учетной записи, под которой настраивается запуск Агента.
Примените изменения и перезагрузите сервер или перезапустите службы СУБД для обновления политик.

Шаг 4. Проверка разрядности СУБД и WoW64

Иногда при анализе свойств службы Агента на вкладке «Дополнительно» администраторы замечают параметр «Выполнение в 64-разрядной системе» (Running in 64-bit system) со значением «Нет». Давайте выясним, на что это влияет.

Если данное значение установлено в «Нет», это означает, что на вашей 64-битной операционной системе Windows Server установлена устаревшая 32-разрядная (x86) версия SQL Server. В этом случае СУБД работает через эмуляционную прослойку WoW64 (Windows on Windows 64-bit).

Агент SQL Server жестко привязан к разрядности ядра СУБД. Вы не сможете запустить 64-битный Агент, если само ядро СУБД работает в 32-битом режиме. Для баз данных 1С это критический фактор, так как 32-битный SQL Server не может адресовать более 4 ГБ оперативной памяти, что приводит к сильному замедлению работы пользователей и частым ошибкам нехватки памяти («Out of memory»). В данной ситуации мы настоятельно рекомендуем выполнить миграцию СУБД на полноценный 64-разрядный дистрибутив.

Шаг 5. Повреждение системной базы данных msdb

Если все права настроены корректно, редакция СУБД соответствует требованиям, но служба Агента падает в процессе инициализации с ошибкой создания нового сеанса, проблема может заключаться в повреждении служебной базы данных msdb.

Агент SQL Server хранит в базе msdb всю системную информацию: структуру заданий (jobs), расписания, историю запусков и сессий. Если в процессе работы сервера произошел сбой по питанию, файлы базы msdb могли быть повреждены.

Чтобы локализовать проблему, проанализируйте логи СУБД. Если вы увидите сообщения о повреждении страниц или невозможности прочитать таблицы в msdb, выполните следующие действия:

Попробуйте запустить проверку целостности базы данных, выполнив запрос: DBCC CHECKDB ('msdb') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если проверка выявила неустранимые ошибки, вам потребуется восстановить базу данных msdb из резервной копии (которая создается автоматически при корректной настройке планов обслуживания).
Если резервной копии нет, базу msdb можно пересоздать заново с помощью системных скриптов переустановки шаблонов баз данных, поставляемых вместе с дистрибутивом MS SQL Server.

Таким образом, последовательно анализируя редакцию СУБД, разрядность системы, права локальных учетных записей и целостность системных файлов базы msdb, мы сможем гарантированно решить проблему запуска Агента или настроить стабильный процесс резервного копирования баз 1С альтернативными методами.