При работе с крупными информационными базами в клиент-серверном режиме пользователи и администраторы могут сталкиваться со сбойной ситуацией, когда при формировании объемных отчетов платформа выводит сообщение: «Ошибка SDBL: Соединение с базой данных не удерживается. Отпустить контекст соединения невозможно». Проблема часто носит плавающий характер: при первом запуске отчета сеанс аварийно завершается, однако после перезапуска клиентского приложения этот же отчет может успешно сформироваться.
Рассмотрим подробно причины возникновения этой ошибки, разберем механизм ее проявления на уровне слоя взаимодействия 1С с СУБД (SDBL) и изучим пошаговые методики ее устранения.
Проанализируем архитектуру взаимодействия сервера приложений 1С и сервера СУБД (например, Microsoft SQL Server). Ошибка слоя SDBL свидетельствует о том, что рабочий процесс сервера 1С (rphost) потерял контекст выполнения SQL-запроса или активное сетевое соединение с СУБД прервалось раньше, чем платформа успела корректно завершить транзакцию и освободить ресурсы.
Выделим основные факторы, вызывающие данный сбой:
ОБЪЕДИНИТЬ ВСЕ с прямым обращением к ресурсоемким виртуальным таблицам (остатки и обороты) без промежуточной выгрузки во временные таблицы. Это создает колоссальную нагрузку на транслятор SDBL и приводит к сбоям при формировании плана запроса.ИЛИ: предикаты с ИЛИ в условиях запроса мешают СУБД эффективно использовать индексы, что увеличивает время выполнения запроса и расходование оперативной памяти.TempDB. Задержки при авторасширении файлов TempDB или нехватка места приводят к отмене сессии со стороны MSSQL.Посмотрим на практический пример оптимизации. Наиболее частая причина падения соединения SDBL — попытка выполнить один сложный запрос, объединяющий виртуальные таблицы остатков и оборотов через ОБЪЕДИНИТЬ ВСЕ.
Если в отчете используется прямой выбор из нескольких виртуальных таблиц:
ВЫБРАТЬ
Остатки.Номенклатура КАК Номенклатура,
Остатки.КоличествоОстаток КАК Количество
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, ) КАК Остатки
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
Обороты.Номенклатура КАК Номенклатура,
Обороты.КоличествоОборот КАК Количество
ИЗ
РегистрНакопления.ТоварыНаСкладах.Обороты(&НачалоПериода, &КонецПериода, , ) КАК Обороты
Такой подход нагружает слой SDBL и может приводить к потере контекста. Перепишем запрос с использованием временных таблиц. Разберем по шагам новый подход:
ВТ_Остатки.ВТ_Обороты.
ВЫБРАТЬ
Остатки.Номенклатура КАК Номенклатура,
Остатки.КоличествоОстаток КАК Количество
ПОМЕСТИТЬ ВТ_Остатки
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, ) КАК Остатки
;
ВЫБРАТЬ
Обороты.Номенклатура КАК Номенклатура,
Обороты.КоличествоОборот КАК Количество
ПОМЕСТИТЬ ВТ_Обороты
ИЗ
РегистрНакопления.ТоварыНаСкладах.Обороты(&НачалоПериода, &КонецПериода, , ) КАК Обороты
;
ВЫБРАТЬ
ВТ_Остатки.Номенклатура КАК Номенклатура,
ВТ_Остатки.Количество КАК Количество
ИЗ
ВТ_Остатки КАК ВТ_Остатки
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ВТ_Обороты.Номенклатура КАК Номенклатура,
ВТ_Обороты.Количество КАК Количество
ИЗ
ВТ_Обороты КАК ВТ_Обороты
Использование временных таблиц снижает нагрузку на транслятор SQL-запросов 1С и гарантирует стабильное удержание контекста соединения.
Разберем настройки конфигурации. Для предотвращения неоптимальных наложений блокировок убедимся в правильности настроек свойства базы данных:
Режим управления блокировкой данных. Для современных систем рекомендуется значение Управляемый или Авто-Управляемый.Если сервер приложений 1С и сервер СУБД MSSQL находятся на разных физических серверах, необходимо разгрузить сетевой трафик и исключить разрывы сокетов:
TCP Chimney Offload, Receive Side Scaling (RSS), Large Send Offload (LSO)). Они могут сбрасывать долгие TCP-сессии при отсутствии активности на физическом уровне.Проанализируем состояние базы данных TempDB на SQL-сервере. Во время выполнения тяжелых запросов из отчетов 1С временные таблицы создаются именно там.
TempDB расположена на высокоскоростном диске (SSD/NVMe).TempDB с достаточным запасом, чтобы исключить задержки выполнения запросов из-за операции автоматического приращения файлов (Autogrow).В случаях, когда сбой SDBL вызван накоплением ошибок метаданных, выполним комплексное обслуживание информационной базы:
rphost..dt и последующую загрузку в новую базу данных — это полностью пересоздаст структуры кеша SDBL.Применение комплексного подхода — от переработки запросов с использованием временных таблиц до корректной настройки сетевых адаптеров и подсистемы TempDB — позволяет полностью устранить ошибку неудержания соединения СУБД и обеспечить стабильную работу любых объемных отчетов.