Что делать, если список входящих документов в 1С:Документооборот зависает у одного пользователя?

← На главную

В процессе эксплуатации систем на базе 1С:Документооборот 2.1 (особенно сильно кастомизированных конфигураций) администраторы и программисты часто сталкиваются с ситуацией, когда конкретный динамический список (например, «Входящие документы») перестает открываться у одного конкретного сотрудника. При этом у остальных пользователей система работает штатно, а стандартные методы вроде очистки локального кэша не приносят мгновенного результата. Рассмотрим подробно причины такого поведения и пошаговый алгоритм решения проблемы.

Анализ ситуации: почему «виснет» только один пользователь?

Если проблема локализована только у одного человека, и она сохраняется даже при входе с другой рабочей станции, мы можем сразу исключить проблемы с «железом» клиента или локальной установкой платформы. Основными подозреваемыми становятся:

Индивидуальные настройки пользователя: сохраненные отборы, сортировки, условное оформление или добавленные через «Изменить форму» колонки.
Ограничения прав доступа (RLS): в «1С:Документооборот» используется сложная система дескрипторов. Если у пользователя специфический набор прав или он входит во множество рабочих групп, запрос к базе данных становится критически тяжелым.
Эффект Parameter Sniffing на SQL-сервере: СУБД кэширует неоптимальный план запроса именно для параметров (прав доступа) этого пользователя.

Шаг 1. Очистка пользовательских настроек в информационной базе

Зачастую простой очистки локального кэша (папок в AppData) недостаточно, так как настройки форм хранятся непосредственно в базе данных. Проанализируем, как правильно выполнить полную очистку настроек проблемного пользователя:

Перейдем в раздел Администрирование — Настройки пользователей и прав — Настройки пользователей. Здесь необходимо выполнить два действия:

Выбрать пользователя и зайти в «Настройки внешнего вида». Удалить настройки для формы списка входящих документов.
Зайти в «Прочие настройки» и очистить настройки, связанные с динамическими списками.

Важно: Как показывает практика, после полной очистки настроек первый запуск списка может занять очень длительное время (вплоть до часа и более). Это происходит потому, что система пытается построить запрос без фильтров по всем 50 000+ записям, одновременно накладывая условия RLS. Если дождаться завершения, список откроется, и в него сразу нужно установить ограничивающий фильтр (например, по периоду «Текущий месяц»).

Шаг 2. Диагностика прав доступа и дескрипторов

В «1С:Документооборот» права рассчитываются через механизм дескрипторов. Разберем ситуацию, когда очередь обновления прав перегружена. Если в базе ведутся активные изменения (пересчет прав для тысяч документов), динамический список будет пытаться соединить таблицу документов с таблицей прав, которая в данный момент может быть заблокирована или находиться в процессе трансформации.

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

Шаг 3. Проверка динамического списка на уровне конфигурации

Если база кастомизирована, выясним, не переведен ли список в режим «Произвольный запрос». Рассмотрим важные свойства динамического списка, которые влияют на скорость открытия:

Основная таблица: Если в произвольном запросе не указана основная таблица (например, Справочник.ВходящиеДокументы), система не сможет применить эффективную постраничную выборку, и SQL-сервер попытается вычитать все записи сразу.
Динамическое считывание данных: Эта галочка должна быть включена для больших списков, чтобы данные подгружались порциями по мере прокрутки.

Шаг 4. Использование Технологического журнала (ТЖ) для поиска тяжелых запросов

Если «отладка» на рабочем сервере невозможна, единственным надежным способом понять причину зависания является сбор Технологического журнала. Настроим сбор события DBMSSQL, чтобы увидеть текст SQL-запроса, на котором «залипает» сеанс пользователя.

Пример настройки logcfg.xml для отлова длительных запросов (более 10 секунд):


<config xmlns="http://v8.1c.ru/7.4/config/log">
  <log location="C:\Logs\SlowQueries" history="24">
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <gt property="Duration" value="10000000"/>
    </event>
    <property name="AllProperties"/>
  </log>
</config>

Проанализировав полученный файл, мы сможем увидеть, какие именно соединения (JOIN) с таблицами прав (_AccessRights, _Accessor) вызывают задержку. Это позволит понять, не слишком ли много дескрипторов создано в системе и не пора ли запустить регламентное задание по их очистке. Для сбора логов и выявления проблемных запросов конкретного сеанса можно воспользоваться инструментом для сбора технологического журнала и замера производительности.

Шаг 5. Проблема Parameter Sniffing на SQL-сервере

Выясним причину, по которой на копии базы всё работает быстро, а на рабочей — виснет. При создании копии статистика SQL-сервера сбрасывается. На рабочем же сервере SQL может хранить «плохой» план выполнения для конкретного набора параметров запроса. Рассмотрим действия по устранению этой проблемы на уровне СУБД:

Обновление статистик: Выполните команду UPDATE STATISTICS для таблиц справочника документов и таблиц прав доступа.
Очистка процедурного кэша: Если обновление статистик не помогло, можно точечно очистить кэш планов для конкретной базы данных (команда DBCC FREEPROCCACHE), хотя на нагруженных системах это следует делать с осторожностью.

Итоговые рекомендации

Для решения проблемы зависания списка мы рекомендуем придерживаться следующей последовательности действий:

Полностью очистить настройки формы списка для данного пользователя через консоль «Настройки пользователей».
Дождаться открытия списка (даже если это занимает час). Система должна «прожевать» тяжелый запрос RLS и закэшировать результат на уровне СУБД.
Сразу после открытия установить жесткий фильтр по периоду (например, только за последние 30 дней). Это значительно снизит нагрузку на RLS при последующих открытиях.
Проверить работу регламентных заданий: Очистка устаревших дескрипторов доступа и Обновление прав доступа.
Если проблема повторяется, проанализировать текст запроса через Технологический журнал и проверить наличие индекса по полям, участвующим в отборах.

Помните, что в «1С:Документооборот» производительность списков напрямую зависит от чистоты системы прав. Регулярная очистка неиспользуемых дескрипторов — залог стабильной работы динамических списков при больших объемах данных. Для проведения всестороннего аудита быстродействия конфигурации можно использовать методику комплексной оптимизации 1С:Документооборот КОРП 2.1.