При работе в распределенных информационных базах (РИБ) в файловом варианте пользователи часто сталкиваются с критической ошибкой: Не удалось заблокировать таблицу. Эта ошибка возникает в момент, когда регламентное задание по обмену данными пытается захватить таблицы регистрации изменений (например, _NODE21 или _DocumentChngR1681) в то самое время, когда кассир или товаровед пытается провести документ или пробить чек в РМК. Разберем детально, почему это происходит и как минимизировать данную проблему.
Файловая версия 1С:Предприятие работает на уровне блокировки всего файла базы данных. Когда происходит обмен данными в рамках РИБ, система переводит таблицы регистрации изменений в монопольный режим записи. Если в этот момент пользователь пытается записать документ (что также является транзакционным действием), возникает конфликт блокировок. В файловой базе это приводит к тому, что транзакция пользователя прерывается с ошибкой, а чек, будучи физически пробитым на фискальном регистраторе, остается в 1С непроведенным. Это расхождение требует ручного исправления.
Один из самых эффективных методов снижения частоты возникновения конфликтов — ограничение количества записей, передаваемых в одной транзакции при обмене. По умолчанию 1С может пытаться обработать весь пакет изменений за один раз, что удерживает блокировку таблиц на длительное время. Уменьшение размера транзакции до 1, 10 или 50 элементов позволяет системе «порционно» сбрасывать блокировку, давая возможность другим процессам (пробитию чеков) «протиснуться» между этими интервалами.
Для настройки количества элементов в транзакции можно воспользоваться программным методом в модуле менеджера обмена или через константы конфигурации. Рассмотрим пример реализации:
Попытка
УстановитьПривилегированныйРежим(Истина);
// Устанавливаем размер транзакции загрузки данных
Константы.КоличествоЭлементовВТранзакцииЗагрузкиДанных.Установить(10);
УстановитьПривилегированныйРежим(Ложь);
Исключение
// Обработка исключения
КонецПопытки;
Важно отметить, что уменьшение этого параметра увеличит общее время выполнения обмена, так как системе потребуется больше времени на открытие и закрытие транзакций, но это критически снизит время удержания монопольной блокировки на таблицах.
Не всегда оправдана установка частого обмена (каждые 15 минут) в файловых базах. Рассмотрим следующие шаги по оптимизации:
Плана обмена ускорит процесс синхронизации.Если вы создаете новые узлы, всегда используйте метод создания РИБ от пустого узла. Это предотвращает передачу накопленной истории изменений всей базы, которая может содержать терабайты записей в регистрах. Чем меньше объем начального образа, тем быстрее будут проходить последующие обмены, так как таблица регистрации изменений будет содержать только актуальные данные.
Поскольку полностью исключить вероятность блокировок в файловом режиме сложно, рекомендуем разработать вспомогательный функционал для администратора. Создайте регламентное задание или обработку, которая:
00:00:00 или без статуса Пробит.1С с информацией, хранящейся в ОФД или в памяти самого фискального регистратора.Пробит в базе данных, если факт продажи подтвержден на стороне кассового оборудования.Если ваша база 1С:Розница достигла размера в несколько сотен гигабайт, а количество узлов РИБ исчисляется десятками — файловый вариант себя изжил. Система MS SQL Server или PostgreSQL позволяет реализовать уровень изоляции транзакций, при котором блокировки на уровне записей работают значительно эффективнее. В SQL-варианте чтение и запись могут сосуществовать гораздо комфортнее, чем в файловом файле 1CD. Переход на серверную версию — это единственный способ гарантированно забыть о проблеме блокировок таблиц _NODE при интенсивной работе.
Таким образом, для борьбы с ошибкой Не удалось заблокировать таблицу в файловой базе: уменьшайте размер транзакций, пересмотрите частоту обмена, оптимизируйте состав передаваемых данных и обязательно внедрите инструмент автоматической сверки статусов чеков.