Как исправить ошибку «База данных заблокирована» при обмене РИБ в 1С:Розница

← На главную

При работе с распределенными информационными базами (РИБ) в конфигурации 1С:Розница пользователи и администраторы часто сталкиваются с непредвиденными сбоями в процессе синхронизации данных. Одним из самых критических и труднодиагностируемых сбоев является ошибка совместного доступа, возникающая при чтении пакета обмена в периферийном узле.

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

Симптомы и анализ проблемы

Типичный сценарий возникновения ошибки выглядит следующим образом: в процессе автоматической или ручной синхронизации в подчиненном узле система внезапно прерывает операцию и выводит в журнал регистрации или на экран пользователя следующее сообщение:

«Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(197)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): База данных заблокирована»

При этом администратор базы данных фиксирует следующие сопутствующие условия:

База данных функционирует в файловом режиме работы.
В момент выполнения обмена в системе нет активных фоновых заданий или других пользователей (монопольный режим обеспечен).
Используется платформа семейства 1С:Предприятие 8.3 (в частности, релизы ветки 8.3.13, например, 8.3.13.1865, или ранние сборки 8.3.14).
В главном узле (ГУ) установлено и активно расширение конфигурации, которое вносит изменения в структуру метаданных (например, добавляет новые реквизиты, табличные части или новые объекты учета).

Рассмотрим подробнее механизм возникновения этого сбоя. Начиная с версии платформы 8.3.12, разработчики 1С реализовали автоматическую передачу расширений конфигурации через механизмы РИБ. Если ваше расширение не просто меняет программный код в модулях, а добавляет собственные реквизиты (например, поле «Количество посетителей» в документ ОтчетОРозничныхПродажах), платформа обязана модифицировать физические таблицы базы данных в подчиненном узле в момент чтения файла обмена.

В этот момент срабатывает зарегистрированный баг платформы (ошибка под номером 30167210). При вызове стандартного метода ПрочитатьИзменения() система пытается одновременно монопольно заблокировать таблицы СУБД для реструктуризации и прочитать пакет данных. Происходит взаимная блокировка (deadlock) потока выполнения платформы самим с собой. В результате процесс аварийно завершается с сообщением о заблокированной базе данных.

Метод 1. Кардинальное решение — обновление платформы 1С

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

Для устранения проблемы выполним следующие шаги:

Скачаем актуальный дистрибутив технологической платформы 1С:Предприятие (рекомендуется использовать стабильные сборки веток 8.3.15, 8.3.20 или выше).
Завершим работу всех пользователей во всех узлах распределенной базы данных.
Установим новую версию платформы на сервере или компьютерах, где выполняются сеансы главного узла.
Произведем аналогичную установку платформы на рабочих станциях во всех подчиненных магазинах и торговых точках.
Запустим базы данных под новым релизом платформы и инициируем повторный сеанс обмена данными.

Метод 2. Интерактивный запуск обмена через «Выполнить сценарий»

Если оперативно обновить платформу на удаленных точках не представляется возможным (например, из-за слабого интернет-канала или отсутствия прав администратора у кассиров), мы можем применить обходной технологический прием. Стандартный запуск синхронизации по кнопке «Синхронизировать» инициализирует регламентное фоновое задание, которое работает в режиме разделения сеансов и часто провоцирует блокировку таблиц расширения.

Чтобы обойти это ограничение, выполним обмен в интерактивном режиме монопольного выполнения:

Попросим абсолютно всех пользователей выйти из периферийной базы данных. Проверим отсутствие зависших сеансов через консоль администрирования (для клиент-серверного варианта) или через просмотр активных пользователей в режиме Предприятия.
Перейдем в раздел Администрирование — Синхронизация данных.
Откроем список настроенных синхронизаций, выберем текущий сценарий обмена с главным узлом.
Вместо использования стандартной команды автоматического обмена нажмем кнопку «Выполнить сценарий» (или запустим обмен вручную непосредственно из формы настроек узла).

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

Метод 3. Временное отключение узла РИБ для обновления расширения

В наиболее тяжелых случаях база данных подчиненного узла зацикливается и намертво блокирует любые попытки прочитать изменения из входящего файла обмена. При этом удаление расширения в главном узле крайне нежелательно, так как это приведет к безвозвратной потере накопленных данных в созданных реквизитах на стороне всех торговых точек. В такой ситуации мы можем применить метод временной «отвязки» периферийного узла от РИБ.

Разберем по шагам алгоритм безопасного отключения и подключения узла:

Запустим командную строку (cmd) на компьютере с проблемной периферийной базой данных.
Выполним команду отключения признака подчиненности главному узлу (база перейдет в автономный режим, что позволит нам редактировать метаданные конфигурации):
```
"C:\Program Files\1cv8\8.3.13.1865\bin\1cv8.exe" CONFIG /F "C:\1C_Bases\Retail_Store1" /ResetMasterNode
```
Примечание: обязательно укажите ваш корректный путь к исполняемому файлу платформы и к каталогу с базой данных.
Запустим периферийную базу в режиме Конфигуратора. База теперь открыта для редактирования.
Перейдем в меню Конфигурация — Расширения конфигурации. Удалим проблемное расширение (предварительно можно выгрузить его в файл .cfe для резервного копирования). При удалении расширения физические таблицы реквизитов очистятся, однако это позволит нам «протолкнуть» зависший обмен и восстановить работоспособность кассы.

Запустим базу в режиме 1С:Предприятие. Нам необходимо вернуть признак главного узла обратно. Для этого воспользуемся встроенным языком 1С. Создадим внешнюю обработку или выполним код в консоли кода:


// Код для восстановления связи с главным узлом РИБ
УзелГлавный = ПланыОбмена.ГлавныйУзел();
Если Не ЗначениеЗаполнено(УзелГлавный) Тогда
    // Находим узел главного офиса по его уникальному коду в плане обмена
    СсылкаНаУзел = ПланыОбмена.ПолнотекстовыйПоиск.НайтиПоКоду("ГБ");
    Если ЗначениеЗаполнено(СсылкаНаУзел) Тогда
        ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаУзел);
        Сообщить("Связь с главным узлом РИБ успешно восстановлена!");
    Иначе
        Сообщить("Не удалось найти узел с указанным кодом!");
    КонецЕсли;
КонецЕсли;

Запустим стандартный сеанс синхронизации данных. Накопленные пакеты обмена прочитаются без ошибок блокировки.

Метод 4. Очистка кэша метаданных и устранение ошибок Params/DBNames

Даже после успешного завершения обмена и применения расширений, платформа 1С может сохранять в локальном кэше компьютера устаревшие схемы метаданных. Это приводит к возникновению вторичных ошибок совместного доступа или сообщениям вида Нарушение прав доступа, файл не обнаружен Params\DBNames.

Для гарантированного устранения последствий сбоя выполним полную очистку кэша конфигурации на рабочем месте:

Полностью закроем все запущенные программы семейства 1С:Предприятие.
Откроем проводник Windows и перейдем по следующим путям:
- %USERPROFILE%\AppData\Local\1C\1cv8
- %USERPROFILE%\AppData\Roaming\1C\1cv8
Удалим все папки с буквенно-цифровыми наименованиями (например, 2a4b8c9d-e3f4...), которые представляют собой кэш метаданных ранее запускавшихся информационных баз.
Снова запустим 1С:Предприятие и выполним контрольный обмен РИБ для проверки стабильности системы.

Важная рекомендация по архитектуре метаданных

Анализируя опыт практикующих разработчиков и системных архитекторов 1С, мы можем сформулировать ключевое правило для проектирования распределенных систем:

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

Механизм распределенных баз данных 1С крайне чувствителен к идентичности структур таблиц SQL и файлов 1Cv8.1CD на всех узлах сети. Расширения создавались преимущественно как инструмент быстрой кастомизации интерфейса и доработки алгоритмов бизнес-логики (программного кода) под нужды конкретных пользователей без снятия основной конфигурации с поддержки.

Если перед вами стоит задача добавить новые поля данных (например, информацию о посетителях в чек или отчет о продажах), безопаснее и надежнее выполнить следующие действия:

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

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