Как устранить тормоза при использовании RLS в 1С:Комплексная автоматизация 2.4

← На главную

Механизм ограничения доступа на уровне записей (RLS) — это мощный инструмент обеспечения безопасности данных, однако в конфигурациях на базе ERP и Комплексная автоматизация 2.4 он часто становится «бутылочным горлышком», замедляющим работу системы до критических значений. Особенно остро это ощущается при открытии журналов документов, подборе товаров или формировании отчетов пользователями с неполными правами. Разберем подробно, почему это происходит и как настроить систему для максимально быстрой работы.

Анализируем причины замедления системы

Для начала проанализируем ситуацию: почему пользователи с полными правами не замечают проблем, а менеджеры сталкиваются с «фризами» интерфейса? При включенном RLS платформа 1С модифицирует каждый запрос к базе данных. К стандартному тексту запроса SELECT... FROM... динамически добавляется сложная секция WHERE, содержащая условия проверки прав. Если у пользователя настроен доступ по контрагентам, организациям или складам, итоговый SQL-запрос может увеличиться в несколько раз, становясь крайне тяжелым для оптимизатора MS SQL Server.

Ситуация усугубляется, когда пользователь входит в большое количество групп доступа. Каждая группа добавляет свои условия через оператор OR (ИЛИ), что вынуждает сервер базы данных выполнять полное сканирование таблиц вместо использования индексов. Рассмотрим, как мы можем исправить эту ситуацию поэтапно.

Включение производительного режима управления доступом

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

В стандартном режиме проверка прав происходит «на лету» для каждой записи. В производительном режиме система использует заранее рассчитанные таблицы ключей доступа (например, _AccessKeys). Это позволяет платформе выполнять простые соединения (JOIN) с таблицами прав, что значительно быстрее, чем вычисление сложных логических условий в каждом запросе.

Перейдем в раздел НСИ и администрирование — Настройка пользователей и прав.
Найдем пункт Ограничивать доступ на уровне записей.
Убедимся, что выбран вариант Производительный. Если сейчас установлен «Стандартный», переключение может занять значительное время, так как системе потребуется выполнить первоначальный расчет ключей доступа для всех объектов.
Проверим состояние фоновых заданий. После включения режима будет запущено регламентное задание Заполнение данных для ограничения доступа. Пока оно не завершится, пользователи могут не видеть часть данных или продолжать испытывать тормоза.

Оптимизация профилей и групп доступа

Рассмотрим ситуацию из сообщения (3): менеджерам нужны ограничения по контрагентам, а бухгалтерам — нет. Часто администраторы по ошибке включают RLS для всех, просто разрешая «все записи» в группе доступа. Однако даже если доступ разрешен ко всем записям, 1С все равно добавит в запрос соединение с таблицами прав, что создаст лишнюю нагрузку.

Проанализируем стратегию разделения прав:

Для пользователей, которым не нужен RLS: Создайте отдельный профиль групп доступа, в котором для видов доступа (например, «Контрагенты») будет стоять настройка «Доступ не ограничен». В последних версиях платформы 8.3 можно также использовать флаг «Не ограничивать доступ» непосредственно в профиле, что полностью исключает проверку RLS для этой роли.
Минимизация количества групп: Постарайтесь объединять пользователей в одну крупную группу доступа вместо десяти мелких. Чем меньше записей в таблицах прав приходится анализировать SQL-серверу для конкретного UserID, тем быстрее будет отклик.

Настройка SQL-сервера под нужды RLS

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

Параметр MAXDOP (Maximum Degree of Parallelism): Для баз 1С с активным использованием RLS рекомендуется устанавливать значение 1. Это предотвращает ситуацию, когда SQL Server пытается распараллелить сложный запрос на множество ядер, тратя на управление потоками больше времени, чем на само выполнение запроса.

Обновление статистики: Убедитесь, что настроено регулярное обновление статистики для таблиц, связанных с доступом. Если статистика устареет, оптимизатор выберет неверный план выполнения, и даже производительный режим не спасет от тормозов. Рекомендуется выполнять UPDATE STATISTICS для таблиц с префиксами _AccessKeys и _AccessValues ежедневно.

Использование расширений для «ручного» ограничения

Если типовой RLS все равно работает медленно, проанализируем вариант из сообщения (4) — написание собственного ограничения через расширение. Это радикальный, но действенный метод.

Идея заключается в том, чтобы отключить системный RLS и добавить программную фильтрацию в динамические списки. Например, в обработчике ПриСозданииНаСервере для формы списка документов мы можем принудительно установить отбор:


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

Такой подход работает молниеносно, так как использует стандартные индексы по полям Контрагент или Организация без привлечения механизмов RLS. Однако помните, что это потребует значительных затрат на поддержку, так как фильтры придется добавлять во все формы и отчеты вручную.

Регламентные операции и очистка данных

Иногда причиной тормозов является «раздувание» таблиц ключей доступа. Проанализируем состояние системы через типовой отчет Анализ состояния доступа (в разделе администрирования). Если вы видите миллионы записей в ключах доступа объектов, выполните следующие действия:

Запустите обработку Обновление доступа на уровне записей.
Выберите режим Пересчитать все права доступа (рекомендуется делать в нерабочее время).
Выполните сжатие (Shrink) базы данных и переиндексацию таблиц прав, чтобы убрать фрагментацию.

Подведем итог: для устранения тормозов в 1С:КА 2.4 в первую очередь перейдите на производительный режим, проверьте настройки MAXDOP на SQL-сервере и убедитесь, что пользователям, не нуждающимся в ограничениях, назначены профили с отключенным RLS. Это обеспечит комфортную работу системы без необходимости покупки сверхмощного оборудования.