Почему 1С:Управление торговлей 10.3 зависает при записи контрагента при включенном RLS и как это исправить?

В конфигурациях на базе «обычных форм», таких как 1С:Управление торговлей 10.3, УПП 1.3 или КА 1.1, часто возникает ситуация, когда при включении механизма ограничения доступа на уровне записей (RLS) система начинает работать крайне медленно. В некоторых случаях это доходит до полного «зависания» интерфейса при попытке записать справочник Контрагенты или провести документ. Примечательно, что под пользователем с полными правами проблема не воспроизводится. Разберем детально, почему это происходит и какие шаги необходимо предпринять для решения проблемы.

Анализируем причину зависания: RLS и файловый режим

Проанализируем ситуацию: механизм RLS (Record Level Security) добавляет к каждому запросу платформы дополнительные условия фильтрации данных на уровне СУБД. Когда пользователь с ограниченными правами пытается записать объект, платформа должна проверить его права не только на сам объект, но и на все связанные данные, попадающие под ограничения (например, группы доступа контрагентов, организации и т.д.).

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

1. Сложность запросов: В УТ 10.3 шаблоны ограничений доступа часто содержат сложные вложенные запросы и соединения с регистрами сведений (например, НастройкаПравДоступаПользователей). Файловый движок 1С не всегда эффективно оптимизирует такие запросы.
2. Блокировки таблиц: В отличие от клиент-серверного варианта (SQL), файловая база данных при выполнении транзакции записи часто блокирует таблицы целиком или значительные их части. Длительная проверка RLS внутри транзакции удерживает блокировку слишком долго.
3. Последовательное выполнение: Файловая СУБД выполняет операции фактически в один поток. Пока один пользователь «ждет» завершения тяжелого запроса RLS, остальные сессии встают в очередь.

Разбор ошибок технологического журнала

Выясним причину через анализ технологического журнала (ТЖ). Часто в логах при подобных зависаниях встречаются следующие ошибки:

Exception=DatabaseException8, Descr="Не удалось заблокировать запись. Действие (изменение, удаление или блокировка записи) не выполнено 'ACTIVEUSERS'"
Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3, Descr="Файл не обнаружен ... DynamicalWorkCache"

Проанализируем эти сообщения подробнее. Ошибка блокировки ACTIVEUSERS в файловом режиме часто является «ложным следом». На самом деле система не может обновить таблицу активных пользователей, потому что база данных «мертво» занята обработкой тяжелого запроса RLS при записи контрагента. Таймаут наступает раньше, чем завершается проверка прав.

Ошибки DynamicalWorkCache указывают на проблемы с временными файлами платформы. Это может быть следствием аварийного завершения процесса, который «завис» на RLS, или нехватки прав пользователя Windows на запись в папку AppData. Также стоит проверить, не блокирует ли антивирус доступ к этим папкам в момент интенсивной работы 1С.

Шаг 1: Тестирование и исправление базы данных

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

1. Создадим резервную копию базы данных (обязательно!).
2. Запустим конфигуратор и перейдем в меню Администрирование — Тестирование и исправление.
3. Установим флаг Реиндексация таблиц информационной базы.
4. Выполним проверку. Это перестроит индексы, что может ускорить выполнение запросов RLS, если проблема была вызвана деградацией индексов.

Шаг 2: Оптимизация настроек прав доступа

Проанализируем структуру прав в самой конфигурации. В УТ 10.3 права на контрагентов часто зависят от их принадлежности к группам доступа. Если у одного контрагента указано слишком много групп или у пользователя включено множество противоречивых ограничений, запрос проверки прав становится «неподъемным» для файловой базы.

Рекомендуем проверить следующие моменты:

• Не перегружены ли регистры сведений, отвечающие за права доступа (например, НастройкаПравДоступаПользователей). Удалите неактуальные записи.
• Попробуйте упростить иерархию групп доступа контрагентов.
• Проверьте, не включены ли одновременно RLS по организациям, контрагентам и складам — сочетание нескольких видов ограничений кратно увеличивает нагрузку.

Шаг 3: Настройка инфраструктуры

Если отказаться от RLS нельзя, а база остается файловой, проанализируем аппаратную часть. Скорость работы RLS в файловом режиме напрямую коррелирует со скоростью дисковых операций I/O.

1. Использование SSD: Перенос базы на быстрый NVMe SSD накопитель может сократить время зависания в несколько раз.
2. Исключения антивируса: Добавим папки с базой данных и папки профиля пользователя (%AppData%\1C) в исключения антивируса. Это предотвратит блокировку временных файлов DynamicalWorkCache.
3. Очистка кэша: Регулярно очищайте кэш конфигурации на рабочих станциях пользователей. Для этого можно использовать скрипты или вручную удалять содержимое папок в %AppData%\1C\1Cv8\.

Шаг 4: Переход на клиент-серверный вариант (рекомендуемое решение)

Как показывает практика и обсуждения экспертов, файловая версия и RLS — это архитектурно несовместимые вещи для стабильной многопользовательской работы. Рассмотрим преимущества перехода на SQL:

• Row-level locking: SQL-сервер блокирует только конкретные строки, а не всю таблицу. Это позволяет другим пользователям работать, пока идет запись контрагента.
• Оптимизатор запросов: SQL-сервер (MS SQL, PostgreSQL) гораздо лучше справляется со сложными соединениями в запросах RLS.
• Стабильность: Ошибки типа ACTIVEUSERS или повреждение заголовка файла базы (1Cv8.1CD) в серверном варианте практически исключены.

Альтернативные варианты разделения прав

Если переход на SQL невозможен по бюджетным соображениям, разберем другие способы решения задачи разделения доступа по организациям:

1. Разделение баз: Создание отдельных информационных баз для каждой организации. Это полностью исключает проблему RLS и блокировок, но усложняет получение консолидированной отчетности (потребуется настройка обмена данными).
2. Административные меры: Отказ от программного RLS в пользу регламентного контроля. Пользователей обучают не заходить в «чужие» документы, а контроль осуществляется через отчеты по журналу регистрации.
3. Доработка конфигурации: Замена стандартного RLS на более «легкие» проверки в модулях объектов (в процедурах ПередЗаписью или ПриОткрытии). Это требует навыков программирования, но позволяет избежать тяжелых запросов на уровне СУБД.

Подведем итог: если ваша УТ 10.3 начала виснуть при записи после включения RLS, в первую очередь проанализируйте возможность перехода на клиент-сервер. Если это невозможно — займитесь оптимизацией индексов, дисковой подсистемы и упрощением структуры прав доступа.