Почему резко падает производительность RLS на MS SQL Server после обновления и как это исправить?

После обновления типовых конфигураций (таких как Управление торговлей 11, Комплексная автоматизация 2 или 1С:ERP 2) на определенные релизы пользователи могут столкнуться с резким замедлением работы системы. Типичный симптом — открытие списков документов или изменение порядка сортировки (например, переключение сортировки с даты на номер) начинает выполняться десятки секунд вместо привычных одной-двух. При этом регламентные процедуры СУБД (дефрагментация индексов, очистка процедурного кэша, обновление статистики) не дают видимого эффекта. Разберем детально, почему это происходит и как восстановить быстродействие базы данных.

Причины падения производительности: конфликт оптимизаторов MS SQL и PostgreSQL

Проанализируем техническую первопричину проблемы. Изначально в конфигурациях была зарегистрирована ошибка для СУБД PostgreSQL: при выполнении конструкции EXISTS в общей части запросов RLS оптимизатор PostgreSQL не задействовал индексы, что приводило к катастрофическому падению скорости работы в 50–200 раз. Разработчики типовых решений внесли изменения в стандартные шаблоны ограничения доступа к данным, адаптировав их под особенности PostgreSQL.

Однако изменение порядка таблиц во внутреннем соединении (INNER JOIN) внутри шаблонов прав негативно повлияло на оптимизатор запросов MS SQL Server. Хотя операция внутреннего соединения математически коммутативна, оптимизатор MS SQL Server строит план выполнения на основе внутренних эвристик и расчета стоимости. В сложных RLS-запросах со вложенными подзапросами оптимизатор преждевременно прерывал перебор вариантов и выбирал неоптимальный алгоритм соединения — вместо точечного поиска по индексу (Index Seek) запускалось сканирование кластерных индексов или ресурсоемкие циклические просмотры (Nested Loops).

Особенно ярко это проявляется в динамических списках. Динамический список запрашивает данные порциями. Когда пользователь меняет сортировку (например, по номеру), СУБД при некорректном плане перестает применять раннюю отсечку строк, полностью сканирует физическую таблицу и вычисляет тяжелое RLS-выражение для каждой записи еще до того, как вернуть первую страницу пользователю.

Данная проблема была официально зафиксирована фирмой «1С» под номером 00-00118228.

Способ 1. Ручная корректировка стандартных шаблонов ограничения доступа

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

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

Справочник.ИдентификаторыОбъектовМетаданных КАК СвойстваТекущейТаблицы
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ТаблицыГруппДоступа КАК ТаблицыГруппДоступа

Заменим этот фрагмент на исходный порядок таблиц, при котором оптимизатор MS SQL Server строит корректный план выполнения:

РегистрСведений.ТаблицыГруппДоступа КАК ТаблицыГруппДоступа
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ИдентификаторыОбъектовМетаданных КАК СвойстваТекущейТаблицы

После внесения изменений во все шаблоны ролей необходимо обновить конфигурацию базы данных. Это сразу возвращает прежнюю скорость обработки динамических списков на MS SQL Server.

Способ 2. Заимствование ролей из стабильного релиза или обновление

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

1. Заимствование прав из предыдущего релиза: выгрузим проблемные роли из стабильной сборки (например, из релиза УТ 11.3.3.196 до внедрения изменений под PostgreSQL) и объединим их с рабочей базой данных с заменой шаблонов ограничений.
2. Установка официального исправительного релиза: фирма «1С» признала неудачным данное изменение и полностью отменила его. В последующих релизах конфигураций (начиная с УТ 11.3.4.19, БСП 2.3.5.81) шаблоны были возвращены к проверенному варианту, стабильно работающему на MS SQL.

Дополнительные методы стабилизации производительности RLS на уровне MS SQL Server

Если корректировка шаблонов по каким-либо причинам откладывается, рассмотрим серверные настройки, помогающие оптимизатору MS SQL справляться со сложными RLS-конструкциями:

1. Включение устаревшей оценки кардинальности (Legacy Cardinality Estimator): начиная с MS SQL Server 2014, новый механизм оценки кардинальности часто дает неточные прогнозы для многотабличных соединений с системными справочниками 1С. Включение старого механизма возвращает стабильные планы запросов. Выполним команду для рабочей базы данных: ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = ON; Альтернативно можно использовать флаг трассировки 9481 на уровне инстанса СУБД.
2. Сбор статистики с полным сканированием: автоматический сбор статистики по умолчанию использует выборку (Sampled), что приводит к искажению селективности для служебных таблиц. Для таблиц Справочник.ИдентификаторыОбъектовМетаданных и РегистрСведений.ТаблицыГруппДоступа настроим регламентное обновление статистики с параметром FULLSCAN.
3. Оптимизация профилей безопасности: проверим, чтобы пользователям не назначались пересекающиеся роли с разными ограничениями RLS на одни и те же таблицы. Платформа 1С объединяет такие условия через логическое ИЛИ (OR), что практически полностью блокирует использование индексов на стороне СУБД.
4. Переход на производительный режим RLS: в современных версиях платформы 1С:Предприятие 8.3 и подсистемы БСП рекомендуется использовать механизм ограничения доступа с предварительным расчетом прав (производительный режим). В этом режиме права рассчитываются при записи объектов в специальные таблицы ключей доступа, а при чтении списков проверка сводится к тривиальному соединению без вычисления тяжелых шаблонов на лету.