При переносе информационных баз 1С:Предприятия между различными системами управления базами данных (СУБД) технические специалисты часто сталкиваются со специфическими ошибками совместимости. Одной из наиболее распространенных и неприятных проблем является сбой при импорте файла резервной копии .dt, выгруженного из СУБД PostgreSQL, в целевую базу под управлением Microsoft SQL Server.
В процессе загрузки система выдает критическую ошибку установки или изменения национальных настроек информационной базы со следующим системным сообщением:
«Microsoft SQL Server Native Client 11.0: The database could not be exclusively locked to perform the operation. HRESULT=80040E14, SQLSTATE=42000, native=5072, native=5030»
В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем внутренние механизмы взаимодействия платформы 1С и MS SQL Server, а также рассмотрим пошаговые практические методы решения проблемы.
Для того чтобы эффективно устранить неисправность, нам необходимо понять физический смысл происходящего. Файл выгрузки .dt содержит не только конфигурацию и табличные данные, но и метаданные о региональных настройках (локали) исходной информационной базы (например, кодировку, порядок сортировки символов, язык).
При миграции с PostgreSQL на MS SQL Server очень часто возникает ситуация, когда параметры сопоставления (Collation) в целевой базе MS SQL Server не совпадают с национальными установками, сохраненными в файле .dt. В этот момент платформа 1С:Предприятие пытается проявить «интеллектуальное» поведение: она инициирует автоматическое изменение параметров сопоставления целевой базы данных на стороне СУБД «на лету» во время загрузки.
Для изменения кодировки и локали базы данных платформа отправляет на SQL-сервер команду:
ALTER DATABASE [Имя_Базы] COLLATE [Имя_Нового_Сопоставления]
Согласно внутренней архитектуре Microsoft SQL Server, выполнение операции ALTER DATABASE с изменением параметров COLLATE требует строго монопольного доступа (exclusive lock) к базе данных. СУБД должна гарантировать, что ни один другой процесс в этот момент не читает и не изменяет данные. Если к базе данных установлено хотя бы одно активное соединение (даже «спящее» или фоновое), SQL Server мгновенно отклоняет транзакцию и возвращает ошибки с кодами 5030 или 5072.
Рассмотрим основные источники скрытых подключений, которые чаще всего мешают монопольному захвату базы:
rphost.Самый быстрый способ вернуть контроль над базой данных — принудительно разорвать все существующие транзакции и перевести базу данных в однопользовательский режим работы, выполнить импорт и вернуть многопользовательский режим.
Разберем этот процесс по шагам с использованием SQL-скрипта:
master, а не та база, которую мы собираемся восстанавливать. Это критически важно, иначе наш собственный запрос заблокирует целевую базу.[Имя_Вашей_Базы] на реальное имя базы в вашей СУБД:
USE [master];
GO
-- 1. Принудительно разрываем все соединения и переводим базу в SINGLE_USER
ALTER DATABASE [Имя_Вашей_Базы]
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
-- 2. Возвращаем базу в стандартный режим работы MULTI_USER
ALTER DATABASE [Имя_Вашей_Базы]
SET MULTI_USER;
GO
Проанализируем, как работает этот код. Инструкция SET SINGLE_USER WITH ROLLBACK IMMEDIATE мгновенно откатывает все незавершенные транзакции пользователей и закрывает их сессии без ожидания. База переходит в режим, когда к ней может подключиться только один клиент. Следующая команда SET MULTI_USER возвращает базу в обычный режим работы, но все старые «зависшие» соединения уже гарантированно уничтожены.
Важный совет: Сразу после выполнения этого скрипта (буквально в течение нескольких секунд), пока фоновые службы сервера 1С не успели заново инициировать соединения, переключитесь в Конфигуратор 1С и запустите процесс загрузки файла .dt.
Чтобы платформа 1С:Предприятие даже не пыталась менять кодировку базы данных «на лету» и не вызывала конфликтов блокировок в MS SQL Server, мы можем предварительно выровнять региональные параметры. Это самый надежный и системный подход к миграции СУБД.
Рассмотрим данный алгоритм подробно:
.dt (полученного из PostgreSQL) через меню Администрирование — Восстановить информационную базу.... В файловом варианте нет жестких блокировок СУБД, поэтому импорт пройдет без ошибок.Cyrillic_General_CI_AS, а в базе установлены специфические настройки), мы можем изменить их прямо здесь, в интерфейсе конфигуратора файловой базы..dt теперь содержит корректные региональные настройки, полностью совместимые с целевым SQL-сервером.Теперь при загрузке этого нового файла в базу на MS SQL Server платформа определит, что кодировки совпадают, и операция изменения сопоставления вызываться не будет. Соответственно, требование монопольного захвата базы SQL-сервером будет снято.
Часто в целевой базе данных накапливается различный «мусор» от предыдущих неудачных попыток импорта, а также к ней привязываются служебные сессии планировщика. В таком случае проще и быстрее полностью пересоздать базу данных с нуля.
Выполним следующие шаги:
Cyrillic_General_CI_AS..dt.Если блокировку вызывают внутренние процессы самого сервера приложений 1С:Предприятия (например, менеджер кластера rmngr или рабочие процессы rphost постоянно сканируют базу данных на предмет регламентных заданий), нам поможет временная остановка службы сервера.
Разберем этот сценарий управления службами:
services.msc и нажмем Enter).
USE [master];
GO
ALTER DATABASE [Имя_Вашей_Базы] COLLATE Cyrillic_General_CI_AS;
GO
.dt. Поскольку кодировки теперь идентичны, загрузка пройдет штатно без требования эксклюзивной блокировки.Используя предложенные методы, мы сможем обойти системное ограничение SQL Server и успешно завершить миграцию информационной базы 1С с СУБД PostgreSQL на MS SQL Server.