Почему база 1С на SQL Server самопроизвольно переходит в однопользовательский режим (SINGLE_USER)

В процессе эксплуатации связки 1С:Предприятие и SQL Server администраторы иногда сталкиваются с критической ситуацией: база данных внезапно становится недоступной для пользователей, а система выдает ошибку о том, что база находится в однопользовательском режиме (SINGLE_USER). В этой статье мы подробно разберем, почему это происходит, как диагностировать причину с помощью системных логов и как правильно настроить регламентные задания, чтобы избежать подобных инцидентов.

Понимание режима SINGLE_USER и его влияния на 1С

Режим SINGLE_USER предназначен для выполнения технических операций, таких как восстановление базы, исправление логических ошибок через DBCC CHECKDB или изменение структуры. Когда база переходит в этот режим, SQL Server разрешает только одно активное соединение. Поскольку сервер приложений 1С обычно поддерживает пул соединений, попытка входа любого второго пользователя (или даже фонового задания самого сервера 1С) приводит к блокировке доступа.

Рассмотрим ситуацию, когда база "отваливается" 1–2 раза в неделю, и для возврата её в рабочий режим приходится вручную выполнять команду ALTER DATABASE ... SET MULTI_USER. Проанализируем основные причины такого поведения.

Шаг 1: Анализ системных логов SQL Server

Первым делом нам необходимо выяснить, кто или что инициирует смену режима. Для этого мы обратимся к SQL Server Error Log. Выясним причину, изучив записи в журнале в момент возникновения проблемы. Нам нужно искать специфическую команду:

Setting database option SINGLE_USER to ON for database 'Имя_Базы'

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

08/21/2018 23:02:52,spid54,Неизвестно,Setting database option SINGLE_USER to ON for database 'sklad'.
08/21/2018 23:02:51,SQLISPackage120,Сведения,Event Name: OnInformation
Message: База данных sklad передается с сервера INFO-1CSQL2014 серверу INFO-1CSQL2014 как sklad_new

Проанализируем эти записи. Обратите внимание на идентификатор spid54 и службу SQLISPackage120. Это указывает на работу SQL Server Integration Services (SSIS). Записи о передаче базы под новым именем sklad_new однозначно говорят о том, что запущен Мастер копирования баз данных (Copy Database Wizard).

Шаг 2: Мастер копирования баз данных (CDW) как главный подозреваемый

Многие администраторы используют этот мастер для создания тестовых баз или "бэкапов" путем копирования. Однако метод работы этого инструмента крайне агрессивен:

1. Программа инициирует отсоединение (Detach) базы.
2. Для этого она принудительно переводит базу в SINGLE_USER с флагом ROLLBACK IMMEDIATE, чтобы разорвать все текущие сеансы пользователей 1С.
3. После копирования файлов мастер должен вернуть базу в строй (Attach) и установить MULTI_USER.

Если в процессе копирования происходит сбой (недостаточно места на диске, ошибка сети или тайм-аут из-за высокой нагрузки на CPU), скрипт аварийно завершается, оставляя базу в режиме SINGLE_USER. Именно поэтому проблема может возникать хаотично — когда нагрузка на сервер позволяет операции завершиться, всё проходит гладко, а в пиковые моменты происходит сбой.

Шаг 3: Проблема низкой производительности процессора

Рассмотрим аппаратную составляющую. Частота процессора 1.7 ГГц является критически низкой для современных конфигураций 1С (например, Управление торговлей 11). Когда загрузка процессора постоянно держится около 100%, планировщик задач SQL Server Agent может не успевать обрабатывать сигналы завершения процессов.

Проанализируем влияние нагрузки на стабильность:

• Тайм-ауты регламентных заданий: При 100% нагрузке задачи обслуживания базы данных могут выполняться значительно дольше положенного времени.
• Конфликты блокировок: Если 1С выполняет тяжелое фоновое задание, а в это время SQL пытается перевести базу в монопольный режим для обслуживания, возникает "клинч", который может закончиться некорректным состоянием БД.

Шаг 4: Как исправить ситуацию и настроить сервер правильно

Чтобы навсегда избавиться от самопроизвольного ухода базы в SINGLE_USER, выполним следующие действия:

1. Удаление некорректных планов обслуживания. Перейдем в SQL Server Management Studio (SSMS), откроем раздел Management (Управление) -> Maintenance Plans (Планы обслуживания). Проверим наличие задач, созданных мастером копирования. Все задачи, которые используют метод Transfer или создают копии баз через "отсоединение", следует удалить.

2. Настройка классического бэкапа. Вместо копирования базы целиком, настроим стандартное резервное копирование. Рассмотрим пример правильного T-SQL скрипта для ежедневного полного бэкапа, который не требует перевода базы в однопользовательский режим:

DECLARE @path VARCHAR(256);
DECLARE @fileName VARCHAR(256);
SET @path = 'G:\Backup\sklad\';
SET @fileName = @path + 'sklad_full_' + FORMAT(GETDATE(), 'yyyy_MM_dd_HHmmss') + '.bak';

BACKUP DATABASE [sklad] 
TO DISK = @fileName 
WITH NOFORMAT, NOINIT,  
NAME = 'Full Backup of sklad', 
SKIP, NOREWIND, NOUNLOAD, STATS = 10;

3. Проверка целостности без исправления ошибок. Часто базу переводит в SINGLE_USER задача Check Database Integrity, если в ней установлена галочка "Attempt to repair any minor problems". Выясним состояние базы вручную, выполнив команду:

DBCC CHECKDB ('sklad') WITH NO_INFOMSGS;

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

4. Оптимизация электропитания. На серверах с низкой частотой процессора (1.7 ГГц) крайне важно убедиться, что Windows не снижает её ещё сильнее ради экономии энергии. Перейдем в Панель управления -> Электропитание и установим схему Высокая производительность (High Performance). Также проверим настройки BIOS (C-States, SpeedStep), чтобы процессор всегда работал на максимальной частоте.

Дополнительные рекомендации по SQL Server 2014

Поскольку мы рассматриваем SQL Server 2014, важно помнить о необходимости установки обновлений. Версия Service Pack 1 (SP1) имела ряд недоработок в работе SQL Agent. Рекомендуем обновиться до Service Pack 3 (SP3), что значительно повысит стабильность выполнения планов обслуживания и решит проблемы с утечками памяти при выполнении сложных SSIS-пакетов.

Также стоит обратить внимание на настройки кластера 1С. Если на сервере работает несколько баз и много пользователей, распределите нагрузку, создав несколько рабочих процессов (rphost). Это позволит более эффективно утилизировать даже слабый процессор и уменьшит вероятность того, что одно зависшее соединение заблокирует выполнение регламентной задачи SQL по переводу базы обратно в MULTI_USER.

В завершение, если вы обнаружили базу в режиме SINGLE_USER и не можете зайти в неё даже через консоль, используйте следующий скрипт для принудительного возврата в многопользовательский режим:

USE [master];
GO
ALTER DATABASE [sklad] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE [sklad] SET MULTI_USER;
GO

Этот код сначала форсированно обрывает все "зависшие" одиночные соединения, а затем открывает доступ для всех. Это гораздо эффективнее и быстрее, чем перезагрузка всей службы SQL Server или сервера целиком.