Многие разработчики и администраторы систем на базе 1С:Комплексная автоматизация 2.4 или 1С:ERP сталкиваются с классической ситуацией: отчет, который у администратора формируется мгновенно, у обычного менеджера или кладовщика выполняется крайне долго. Проанализируем, почему так происходит, и разберем по шагам, как оптимизировать систему, чтобы отчеты работали быстро для всех категорий пользователей.
Разберем основной механизм возникновения проблемы. Когда отчет запускает пользователь с полными правами, система генерирует прямой SQL-запрос к таблицам базы данных без дополнительных фильтров. Однако, когда тот же отчет запускает пользователь с ограниченными правами, включается механизм RLS (Record Level Security) — ограничение доступа на уровне записей.
Проанализируем ситуацию: платформа 1С динамически модифицирует запрос, добавляя в него дополнительные условия ГДЕ и соединения JOIN с таблицами прав доступа (например, по организациям, складам или партнерам). В результате простой запрос превращается в сложную конструкцию, выполнение которой создает колоссальную нагрузку на СУБД. Выясним, как это исправить.
Прежде чем приступать к оптимизации, нам необходимо точно локализовать проблему. Рассмотрим, как это сделать с помощью встроенных инструментов платформы:
Посмотрим на самые длительные операции. Если основное время тратится на выполнение метода СкомпоноватьРезультат(), значит, проблема именно в сложности SQL-запроса, порожденного RLS. Сравним этот замер с аналогичным под администратором: разница в тексте запроса и времени его выполнения на уровне СУБД подтвердит теорию влияния ограничений доступа.
В современных конфигурациях на базе БСП (Библиотеки Стандартных Подсистем) предусмотрено два варианта работы ограничений доступа. Проверим текущие настройки:
Перейдем в раздел Администрирование — Настройка пользователей и прав — Группы доступа. Нам нужно найти флаг Ограничивать доступ на уровне записей. Рядом должен быть выбран вариант Производительный. Этот режим использует заранее подготовленные вспомогательные таблицы прав, что значительно ускоряет работу СУБД по сравнению со стандартным режимом, где права вычисляются «на лету» при каждом обращении.
Если смена режима не дала мгновенного результата, проанализируем ситуацию дальше — возможно, таблицы прав еще не успели обновиться.
Разберем критическую ошибку в разработке отчетов. Если в схеме компоновки данных (СКД) в тексте запроса не указано ключевое слово РАЗРЕШЕННЫЕ, система сначала пытается получить все данные из базы, а затем отсекает их на уровне платформы 1С. Это создает огромный объем передаваемых данных.
Рассмотрим пример правильного оформления запроса в отчете:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
ПродажиОбороты.Организация КАК Организация,
ПродажиОбороты.СуммаВыручкиОборот КАК Выручка
ИЗ
РегистрНакопления.ВыручкаИСебестоимостьПродаж.Обороты(&НачалоПериода, &КонецПериода, , ) КАК ПродажиОбороты
При использовании слова РАЗРЕШЕННЫЕ фильтрация происходит на уровне СУБД (SQL Server или PostgreSQL), что в десятки раз быстрее.
Выясним технический нюанс на уровне структуры таблиц. RLS добавляет в каждый запрос пользователя условия ГДЕ по таким полям, как Организация, Склад, Подразделение. Если эти поля в базе данных не проиндексированы, SQL-сервер выполняет полное сканирование таблиц (Table Scan) вместо быстрого поиска по индексу.
Рекомендация: убедитесь, что для всех измерений и реквизитов, по которым настроены ограничения в профилях доступа, в Конфигураторе установлено свойство Индексировать (или Индексировать с доп. упорядочиванием).
Часто тормоза вызваны тем, что пользователь включен в слишком большое количество групп доступа. Посмотрим на это глазами SQL-сервера: каждое новое условие доступа — это дополнительное объединение таблиц. Если у пользователя 10 групп доступа с пересекающимися правами, запрос превращается в «простыню» из условий OR и UNION.
Проанализируем возможность создания упрощенных профилей доступа. В КА 2.4 эффективнее создать одну специализированную группу доступа, чем добавлять пользователю множество типовых. Также стоит отключить неиспользуемые виды доступа (например, если вы не используете ограничение по группам партнеров, его лучше полностью отключить в настройках, чтобы система не тратила ресурсы на проверку пустых условий).
Механизмы RLS постоянно совершенствуются. В версии платформы 8.3.16 (упомянутой в обсуждении) работа с временными таблицами прав была менее эффективной. Начиная с версий 8.3.18 и выше, платформа гораздо лучше кэширует права и оптимизирует «интерактивный» RLS.
Также проверим, запущены ли в базе регламентные задания:
Заполнение данных для ограничения доступаОбновление прав доступаЕсли таблицы с правами не актуализированы, система вынуждена пересчитывать их в реальном времени при каждом формировании отчета, что и вызывает задержки.
Чтобы окончательно подтвердить причину, выполним следующий эксперимент. Запустим Консоль запросов под «медленным» пользователем и выполним текст запроса из отчета. Если запрос со словом РАЗРЕШЕННЫЕ работает медленно, значит проблема в сложности самих условий RLS. Если быстро — проблема может быть в постобработке данных в компоновке (например, в обращении через точку к полям, на которые у пользователя нет прав).
Таким образом, решив проблему комплексным подходом — от настройки режима работы RLS до индексации полей и оптимизации состава групп доступа — мы добьемся того, что отчеты будут «летать» даже у пользователей с самыми сложными ограничениями прав.