Ситуация, когда менеджер открывает Заказ клиента, созданный день или два назад, и при попытке подобрать товары программа «зависает наглухо», является довольно распространенной в крупных базах 1С:Комплексная автоматизация 2 и 1С:ERP. Особенно примечателен тот факт, что если передвинуть дату заказа на текущую, проблема исчезает. Это явный маркер того, что причина кроется в механизмах работы платформы с виртуальными таблицами и правами доступа на определенную «точку времени».
В этой статье мы подробно разберем, почему так происходит, проанализируем влияние RLS (ограничение прав на уровне записей), расширений и специфики расчета остатков, а также составим план диагностики и решения проблемы.
Разберем фундаментальное различие в том, как 1С получает данные об остатках. Когда документ датирован сегодняшним числом (текущим моментом), система обращается к таблицам итогов регистров накопления. Эти данные уже рассчитаны и хранятся в базе в готовом виде, поэтому запрос выполняется мгновенно.
Однако, когда мы открываем подбор из документа «вчерашней» даты, 1С должна показать остатки именно на тот момент. Для этого системе приходится выполнять следующие действия:
Проанализируем ситуацию: если к этому расчету добавляется RLS, нагрузка на SQL-сервер возрастает в геометрической прогрессии, так как условия прав накладываются на каждую запись, участвующую в «открутке» итогов.
Как было отмечено в обсуждении, в базе включен RLS. Ограничение прав на уровне записей существенно усложняет SQL-запросы, которые генерирует платформа. Когда форма подбора пытается отобразить остатки на прошлую дату, 1С формирует запрос к виртуальной таблице ОстаткиИОбороты или Остатки с параметром Период.
Если используется «старый» (непроизводительный) режим RLS, то условия прав вставляются прямо в подзапросы. При работе с динамическими списками, которыми является форма подбора, это может приводить к созданию неоптимальных планов запросов в SQL-сервере. В итоге сервер тратит колоссальное время на расчет прав для каждой строки номенклатуры, что пользователь видит как «глухое зависание» интерфейса.
В рассматриваемой ситуации используется расширение, которое добавляет «таблицу остатков и цен» в подбор товаров. Это критический момент. Зачастую разработчики расширений добавляют в динамический список формы подбора дополнительные соединения (JOIN) с другими таблицами или вложенные запросы для вычисления цен.
Рассмотрим пример кода, который часто встречается в таких расширениях и может вызывать тормоза:
// Пример неудачного запроса в динамическом списке
ВЫБРАТЬ
Номенклатура.Ссылка,
ЕСТЬNULL(Цены.Цена, 0) КАК Цена,
ЕСТЬNULL(Остатки.ВНаличииОстаток, 0) КАК Остаток
ИЗ
Справочник.Номенклатура КАК Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ) КАК Цены
ПО Номенклатура.Ссылка = Цены.Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, ) КАК Остаток
ПО Номенклатура.Ссылка = Остатки.Номенклатура
Если &Период в данном запросе не совпадает с текущим временем, SQL-серверу приходится выполнять тяжелую работу по расчету среза последних и остатков на историческую дату для каждой позиции в списке, что и вызывает фриз.
Стоит обратить внимание на совет из обсуждения: проверить документы, проведенные будущей датой. Если в системе есть документ УстановкаЦенНоменклатуры или складской документ, датированный, к примеру, 2030 годом, механизм расчета итогов в 1С может начать работать некорректно. Система будет пытаться рассчитать остатки, учитывая этот «будущий» период, что приводит к непредсказуемым задержкам при расчете итогов на любую дату, отличную от «сейчас».
Шаг 1: Замер производительности
Первым делом необходимо выполнить Замер производительности. Для этого:
ОткрытьФорму или получение данных динамического списка.Шаг 2: Проверка режима RLS
Проверьте настройки программы (НСИ и администрирование -> Настройки пользователей и прав). Если активен режим «Стандартный», рассмотрите возможность перехода на «Производительный» режим RLS. Он использует заранее рассчитанные таблицы прав доступа, что значительно ускоряет работу динамических списков в документах и подборах.
Шаг 3: Оптимизация расширения
Если замер показал, что тормозит запрос в расширении, попробуйте временно отключить расширение и проверить работу подбора без него. Если «зависание» пропало, значит, код расширения требует оптимизации. Выясним причину: возможно, стоит отказаться от расчета остатков «на лету» в списке и выводить их только при активации строки или по отдельной кнопке.
Шаг 4: Анализ индекса полнотекстового поиска
Иногда подбор виснет из-за попытки системы обновить индекс полнотекстового поиска при открытии формы. Попробуйте выполнить следующие действия в разделе «Обслуживание»:
Шаг 5: Очистка серверного кэша
Поскольку проблема специфична для клиент-серверного варианта и большого числа пользователей, «залипшие» планы запросов в кэше сервера 1С или SQL-сервера могут усугублять ситуацию. Рекомендуется выполнить перезапуск службы 1C:Enterprise Server Administration и очистку процедурного кэша SQL-сервера.
Проблема «зависания» подбора на старых датах — это комплексная проблема производительности. Основной удар наносит сочетание исторического расчета виртуальных таблиц и фильтров RLS. Чтобы пользователи работали комфортно, необходимо минимизировать сложность запросов в расширениях формы подбора и убедиться, что система использует наиболее производительные режимы работы с правами доступа.