Почему при пересчете бухгалтерских итогов в 1С 7.7 SQL возникает ошибка монопольного доступа?

← На главную

При работе с базами данных 1С:Предприятие 7.7 на современных версиях MS SQL Server (2005, 2008, 2008 R2, 2012 и выше) администраторы часто сталкиваются с аварийным завершением длительных процедур обслуживания. Наиболее распространенный сценарий — полный пересчет бухгалтерских итогов как в режиме предприятия, так и через меню «Тестирование и исправление ИБ» в Конфигураторе.

Через некоторое время после запуска регламентной процедуры 1С аварийно закрывается с ошибкой: «База данных "имя_базы" уже открыта, и одновременно к ней может обращаться только один пользователь».

Разберем детально механизм возникновения этой коллизии, выясним причины сбоя и рассмотрим пошаговые способы исправления ситуации.

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

Проанализируем логику взаимодействия платформы 1С 7.7 с сервером баз данных MS SQL Server при выполнении монопольных операций:

Проверка монопольности со стороны 1С: Перед началом и во время выполнения тяжелых пакетных операций (пересчет итогов, перестроение индексов) платформа проверяет наличие параллельных подключений к базе данных.
Проблема учетной записи sa (System Administrator): Если база подключена под системным администратором СУБД (sa), процесс 1С видит абсолютно все служебные и фоновые процессы экземпляра SQL Server.
Фоновые процессы СУБД: В процессе активной записи и изменения сотен тысяч записей в таблицы итогов (_1SBKTTL, _1SBKTTLC) SQL Server запускает внутренние потоки (сброс «грязных» страниц из буферного пула данных, фоновый процесс CHECKPOINT, обновление статистики). Платформа 1С 7.7 ошибочно воспринимает эти системные потоки как подключение второго реального пользователя и принудительно прерывает операцию.

Решение 1. Создание выделенного SQL-пользователя с ограниченными правами

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

Разберем по шагам настройку учетной записи в SQL Server Management Studio (SSMS):

Создаем новый логин SQL Server (например, usr1c_buh) с проверкой подлинности SQL Server Authentication.
В свойствах созданного пользователя (раздел «Сопоставление пользователей» / User Mapping) сопоставляем его с рабочей базой данных 1С и назначаем только роль db_owner на эту конкретную базу. Не назначайте роль sysadmin на уровне сервера.
Предоставляем пользователю право на просмотр состояния сервера. Это необходимо для корректной работы модифицированных библиотек доступа к современным версиям SQL Server:
```
USE [master];
GRANT VIEW SERVER STATE TO [usr1c_buh];
```
Указываем созданную учетную запись в параметрах подключения к базе данных в 1С (меню «Администрирование» → «Параметры базы данных SQL»).

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

Решение 2. Корректировка параметров базы данных на стороне SQL Server

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

Отключение автоматического закрытия и сжатия: Опции AUTO_CLOSE и AUTO_SHRINK инициируют служебные блокировки базы данных, несовместимые с монопольным режимом 1С 7.7.
Отключение асинхронного обновления статистики: Фоновое обновление статистики (AUTO_UPDATE_STATISTICS_ASYNC) создает параллельное подключение во время выполнения тяжелых запросов.

Выполним следующий T-SQL скрипт для оптимизации свойств информационной базы:


ALTER DATABASE [ИмяБазы1С] SET AUTO_CLOSE OFF WITH NO_WAIT;
ALTER DATABASE [ИмяБазы1С] SET AUTO_SHRINK OFF WITH NO_WAIT;
ALTER DATABASE [ИмяБазы1С] SET AUTO_UPDATE_STATISTICS_ASYNC OFF WITH NO_WAIT;

Решение 3. Управление моделью восстановления и журналом транзакций

При полном пересчете бухгалтерских итогов объем генерируемых транзакций может многократно превышать обычную нагрузку. В модели восстановления Full это приводит к разрастанию журнала транзакций (файла .ldf) и частым задержкам на контрольные точки.

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

ALTER DATABASE [ИмяБазы1С] SET RECOVERY SIMPLE;

После завершения пересчета итогов при необходимости можно вернуть модель FULL и обязательно сделать полную резервную копию базы данных.

Дополнительные рекомендации при подготовке к пересчету

Проанализируем сопутствующие факторы, которые помогают избежать сбоев при обслуживании базы:

Закрытие сторонних утилит: Перед началом пересчета закройте все окна SQL Server Management Studio (SSMS) и сторонние средства мониторинга, так как фоновый опрос состояния таблиц создает кратковременные сессии.
Временная остановка агента SQL: Если настроены регламентные задания резервного копирования или проверки целостности, временно отключите службу SQL Server Agent на период пересчета итогов.
Отключение пула соединений: В системной оснастке «Администратор источников данных ODBC» на вкладке «Пул соединений» (Connection Pooling) убедитесь, что пул соединений для используемого драйвера отключен, чтобы разорванные сессии не оставались активными в памяти.