Как исправить ошибку «Сеанс завершен администратором» при выгрузке 1С в .dt (SQL Native Error 596)?

← На главную

В процессе эксплуатации 1С:Предприятие 8.3 на СУБД Microsoft SQL Server пользователи часто сталкиваются с критической ошибкой при попытке выгрузки информационной базы в файл .dt или при обновлении конфигурации. Ошибка сопровождается сообщением: «Соединение с сервером баз данных разорвано администратором. Microsoft SQL Server Native Client 11.0: Не удалось продолжить выполнение, поскольку сеанс находится в состоянии завершения. HRESULT=80004005, SQLSrvr: SQLSTATE=HY000, native=596». Рассмотрим подробно, что это означает и как восстановить работоспособность базы.

Разбор причины ошибки Native 596

Ошибка с кодом native=596 указывает на то, что сеанс работы с SQL Server был принудительно переведен в состояние «Kill State». Несмотря на текст ошибки «завершен администратором», чаще всего это делает не человек, а сам SQL Server. Разберем основные причины такого поведения:

Критический сбой процесса: При выполнении тяжелой операции (чтение больших таблиц при выгрузке) происходит исключение на уровне ядра SQL Server.
Физическое повреждение данных: Если на диске появились битые сектора в области хранения системных таблиц или индексов, SQL Server обрывает соединение при попытке доступа к ним.
Недостаток ресурсов: Нехватка оперативной памяти или места в TempDB может привести к аварийному завершению потока.
Ошибки в системных каталогах: Повреждение метаданных самой СУБД, которые описывают структуру таблиц 1С.

Проанализируем ситуацию: если база открывается в режиме «Предприятие», но «падает» именно при попытке выгрузки или тестирования, значит, проблема кроется в конкретной области данных, к которой обращается конфигуратор для сборки образа базы. Если база ещё открывается, сопоставьте время сбоя выгрузки с фактическими запусками в истории регламентных заданий. Это поможет обнаружить совпавшую по времени активность, но не докажет её причиной ошибки и не включит блокировку заданий.

Шаг 1: Первичная диагностика инфраструктуры

Прежде чем приступать к исправлению самой базы данных, исключим внешние факторы. Рассмотрим стандартный набор действий:

Перезапуск службы: Выполним перезапуск службы 1C:Enterprise 8.3 Server Agent и службы SQL Server (MSSQLSERVER).
Очистка кластера: Попробуем удалить базу из списка информационных баз в консоли администрирования 1С (без удаления самой БД в SQL) и прописать её заново. Это исключит ошибки кэша сеансов в кластере.
Проверка фоновых заданий: Убедимся, что в момент выгрузки не запускаются регламентные задания. Проанализируем настройки блокировки в консоли администрирования 1С и установим «Блокировка регламентных заданий включена».

Шаг 2: Глубокая проверка целостности через SQL

Если базовые действия не помогли, значит, проблема в самой структуре БД. Разберем, как проверить базу средствами SQL Server Management Studio (SSMS). Нам необходимо запустить проверку логической и физической целостности. Для первичной диагностики СУБД также пригодится инструмент для анализа SQL-сервера глазами 1С-специалиста.

Выполним следующий скрипт в окне запросов SSMS:

DBCC CHECKDB ('Имя_Вашей_Базы') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Если в результате проверки вы увидите сообщения об ошибках в объектах типа sys.sysidxstats или sys.sysallocunits, это означает повреждение системных таблиц. Например, ошибка «This system table index cannot be recreated» говорит о серьезном сбое в метаданных SQL Server.

Шаг 3: Исправление системных таблиц и индексов

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

Проанализируем последовательность команд:


-- Переводим базу в однопользовательский режим
ALTER DATABASE [Имя_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- Запускаем исправление
DBCC CHECKDB ('Имя_Базы', REPAIR_ALLOW_DATA_LOSS);
GO

-- Проверяем соответствие системных каталогов
DBCC CHECKCATALOG ('Имя_Базы');
GO

-- Возвращаем базу в обычный режим
ALTER DATABASE [Имя_Базы] SET MULTI_USER;
GO

Функция CHECKCATALOG особенно важна, так как она проверяет согласованность между системными таблицами (например, наличие записи в таблице столбцов для каждой таблицы в базе). Если после этих действий CHECKDB рапортует об отсутствии ошибок, попробуем снова запустить выгрузку .dt.

Шаг 4: Локализация «битых» данных 1С

Выясним причину, если SQL-проверка не находит ошибок, но выгрузка все равно обрывается. Вероятно, проблема в данных 1С, которые логически корректны для SQL, но вызывают сбой парсера 1С. Разберем, как найти проблемную таблицу:

Запустим SQL Server Profiler.
Настроим трассировку событий RPC:Completed и SQL:BatchCompleted.
Запустим процесс выгрузки в 1С.
Посмотрим на последний успешный запрос перед разрывом соединения. Последняя таблица, из которой 1С пыталась прочитать данные, скорее всего, содержит «битую» запись (например, некорректное значение в поле типа Value Storage или бесконечный цикл ссылок).

Шаг 5: Очистка служебных таблиц конфигурации

В некоторых случаях выгрузка прерывается из-за мусора в таблицах, хранящих временные данные конфигурации. Рассмотрим безопасную очистку этих таблиц через SQL:


TRUNCATE TABLE _ConfigSave;
TRUNCATE TABLE _ConfigSaveInfo;

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

Шаг 6: Крайние меры — перенос данных через XML

Если исправить физическую структуру базы не удается, а CHECKDB продолжает выдавать ошибки в системных индексах, единственным надежным способом спасения данных остается их выгрузка на уровне объектов. Рассмотрим этот алгоритм:

Создадим новую пустую базу 1С с аналогичной конфигурацией.
Используем стандартную обработку «Выгрузка и загрузка данных XML» (её можно найти на ИТС).
Попробуем выгрузить данные по частям: сначала справочники, затем константы, затем документы за последние периоды.
Если на определенном типе объектов выгрузка «упадет» с той же ошибкой 596, мы точно будем знать, какая таблица повреждена.

Важный совет: Проверьте состояние дисковой подсистемы сервера. Ошибка native=596 в сочетании с HRESULT=80004005 часто является первым признаком деградации RAID-массива или скорого выхода из строя SSD/HDD, на котором расположены файлы базы данных или TempDB.