← На главную

Разберем типичную, но весьма неочевидную ситуацию, с которой часто сталкиваются администраторы и программисты 1С. Пользователь жалуется, что при попытке поставить пометку на удаление на любой элемент справочника система буквально "зависает" на долгое время. При этом, если зайти в базу под другим пользователем с аналогичными (или даже административными) правами, все работает мгновенно. База данных клиент-серверная (MS SQL), конфигурация типовая (например, 1С:Комплексная автоматизация). Более того, если выгрузить базу в формат .dt и развернуть в файловом варианте, проблема исчезает.

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

Ошибочные гипотезы: почему дело не в статистике MS SQL

Первое, что часто приходит в голову при проблемах с производительностью в клиент-серверной архитектуре — это проблемы на стороне СУБД. В частности, "протухшая" статистика или фрагментированные индексы. Действительно, в некоторых случаях выполнение процедуры ОбновлениеВспомогательныхДанных или запуск полного перестроения индексов в SQL может помочь.

Однако в нашей ситуации есть ключевой симптом: проблема воспроизводится только у одного конкретного пользователя. Статистика и индексы СУБД строятся для таблиц в целом и не привязаны к конкретным учетным записям 1С (СУБД вообще ничего не знает о пользователях 1С, она оперирует только таблицами и запросами). Если бы проблема заключалась в индексах, пометка на удаление тормозила бы у всех. Таким образом, гипотезу с обслуживанием SQL можно смело отбросить.

Главная причина проблемы: пользовательские настройки динамических списков

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

Когда пользователь работает со справочником, он видит форму списка. Эту форму каждый пользователь может настроить под себя. Рассмотрим подробнее, что именно может вызвать катастрофическое падение производительности:

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

При установке пометки на удаление платформа обновляет статус элемента в базе данных, после чего автоматически происходит оповещение открытых форм и перерисовка динамического списка. Именно в этот момент СУБД вынуждена обрабатывать огромный неоптимальный запрос, сформированный на основе тяжелых пользовательских настроек. Это и выглядит как зависание интерфейса.

Влияние RLS (ограничения доступа на уровне записей)

Проанализируем ситуацию с правами. Даже если визуально роли проблемного пользователя кажутся такими же, как у администратора, на него могут действовать ограничения RLS. Как это связано с зависанием?

Механизм RLS неявно добавляет к каждому запросу динамического списка дополнительные условия для фильтрации записей, которые пользователю видеть не положено. В связке с тяжелым "Условным оформлением" и отборами, запрос разрастается до гигантских размеров. В MS SQL для такого специфического сочетания условий может строиться крайне неоптимальный план запроса (в то время как для пользователя без этих настроек или без RLS план строится быстро и выполняется оптимально).

Почему в файловой базе работает быстро?

Разберем интересный эффект, упомянутый в начале: после выгрузки в .dt и загрузки в файловую базу проблема исчезает. Этому есть несколько причин:

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

Решение проблемы: очистка кэша и настроек

Рассмотрим по шагам, как быстро и эффективно устранить подобную проблему, не прибегая к глобальным операциям на сервере.

1. Очистка кэша: У каждого пользователя в локальных профилях ОС хранятся файлы кэша. Повреждение кэша форм приводит к тому, что система пытается обратиться к некорректным метаданным. Рекомендуется полностью очистить папки кэша 1С в директориях AppData\Local\1C и AppData\Roaming\1C на компьютере проблемного пользователя.
2. Очистка персональных настроек пользователя: Это самый действенный метод. В режиме конфигуратора или в режиме предприятия (через функции технического специалиста) необходимо очистить пользовательские настройки проблемного справочника (или все настройки пользователя, если точный источник неизвестен). Как только форма списка вернется к стандартному (типовому) виду, перерисовка списка перестанет тормозить транзакцию записи.

Как избежать проблемы в будущем и правильно диагностировать ее

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

1. Точечная корректировка настроек списка

Вместо полного сброса зайдите в базу под проблемным пользователем, откройте тормозящий справочник, нажмите кнопку «Ещё» -> «Настроить список». Внимательно изучите вкладку «Условное оформление» и «Отборы». Отключение тяжелых цветовых выделений или фильтров по связанным таблицам обычно решает проблему навсегда, сохраняя остальные полезные настройки пользователя.

2. Использование Замера производительности

Снимите замер производительности именно в режиме пользователя. Для этого:

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

Вы увидите, что 99% времени тратится не на саму запись (Объект.Записать()), а на обработчики форм (например, СписокПриИзменении) или на получение данных динамического списка.

3. Анализ планов запросов СУБД

Если вы опытный администратор, запустите SQL Server Profiler (или Extended Events) и отловите запрос, который выполняется в момент зависания. Вы увидите реальный SQL-запрос, который платформа 1С генерирует для отрисовки динамического списка с учетом пользовательских настроек и RLS. Анализ этого запроса окончательно подтвердит влияние пользовательского оформления на производительность базы данных.