Как восстановить доступ пользователей и оптимизировать пересчет дескрипторов доступа в 1С:Документооборот 3.0?

← На главную

Типичная аварийная ситуация после развертывания базы «1С:Документооборот 3.0» из резервной копии характеризуется следующими симптомами: сотрудники с полными административными правами заходят в базу и работают без видимых задержек, тогда как обычные пользователи вообще не могут войти в программу либо их клиентские приложения зависают на этапе открытия начальной страницы. Одновременно на сервере приложений «1С:Предприятия» наблюдается лавинообразное появление фоновых заданий, утилизация процессора и дисковой подсистемы возрастает до 100%, а в регистрах прав скапливаются сотни тысяч необработанных записей. Попытка дождаться штатного окончания пересчета прав часто затягивается на несколько суток без ощутимого прогресса.

Почему возникает коллапс прав доступа при восстановлении базы

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

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

Сброс актуальности прав при восстановлении копии происходит по ряду фундаментальных причин:

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

Шаг 1. Экстренная стабилизация сервера и остановка фоновых процессов

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

Для отключения фоновой активности выполните действия в консоли кластера серверов «1С:Предприятия»:

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

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

В консоли кластера переведите рабочий процесс (rphost), в котором зависли фоновые сеансы, в состояние «Не используется». Платформа перестанет направлять в него новые клиентские подключения.
Через диспетчер задач операционной системы или команду завершения процессов остановите конкретный зависший экземпляр rphost.exe по его системному идентификатору (PID).
В критической ситуации, когда кластер серверов перестает отвечать, выполните холодную очистку кэша сеансов: остановите службу сервера 1C:Enterprise Server Agent, перейдите в системный каталог хранения данных кластера (путь по умолчанию: srvinfo/reg_1541/) и очистите папки с префиксом snccntx_*. После этого запустите службу заново. Данное действие сбрасывает зависшие контексты сеансов без повреждения данных СУБД.

Шаг 2. Анализ масштаба очереди и состояния дескрипторов

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

Настройки → Права доступа → Управление расчетом прав

В открывшейся панели оцените ключевые метрики системы:

Суточный график движения очереди: позволяет понять соотношение скорости добавления новых элементов и скорости их обработки. Если график стабильно держится на пиковых значениях без нисходящего тренда, штатный фоновый процесс не справляется с объемом.
Команда «Открыть очередь»: открывает системный регистр сведений «Очередь обновления прав доступа». Обратите внимание на количество записей и типы объектов. Если в очереди зафиксировано более 200 000 объектов, последовательная обработка в один поток стандартными порциями парализует работу предприятия на несколько дней.
Отчет «Дескрипторы доступа»: открывается из раздела администрирования прав. Отчет отображает статистику по действующим, пустым и помеченным на удаление дескрипторам. Наличие десятков тысяч неиспользуемых или дублирующихся дескрипторов указывает на необходимость их предварительной очистки перед расчетом.

Шаг 3. Ускорение обработки очереди дескрипторов

Штатный расчет сотен тысяч прав с параметрами по умолчанию работает медленно из-за малого размера транзакций и постоянных накладных расходов на открытие контекстов. Для форсирования пересчета применяется комплекс мер.

Корректировка порционности и групповой обработки:

В настройках прав доступа задействован механизм отложенного обновления. При его работе система группирует однотипные дескрипторы. По умолчанию размер порции составляет 100 объектов за одну транзакцию. При объеме очереди в 200 000–300 000 элементов накладные расходы на фиксацию сотен тысяч отдельных транзакций перегружают журнал транзакций СУБД.

Размер порции можно скорректировать программно или через тонкую настройку констант БСП, увеличив размер пачки до 500–1000 объектов (в зависимости от доступной оперативной памяти сервера). Это ускоряет пакетную вставку рассчитанных ключей доступа в регистры.

Точечный ручной запуск для ключевых сотрудников:

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

В форме «Управление расчетом прав» нажмите кнопку «Открыть очередь».
Установите отбор по типам объектов, критически важным для старта дня: «Входящие документы», «Исходящие документы», «Задачи исполнителя» за текущий месяц.
Выделите строки текущего периода и выполните команду Обработать → Выбранные. Система выполнит пересчет прав выделенных объектов в приоритетном синхронном потоке текущего административного сеанса.
Для конкретного проблемного руководителя или подразделения перейдите в карточку пользователя, откройте список связанных с ним документов и на форме проверки прав объекта нажмите кнопку Обновить. Это мгновенно рассчитает дескриптор целевого документа.

Параллелизация и расписание фонового задания:

Перейдите по пути: Настройки → Поддержка и обслуживание → Регламентные и фоновые задания → Обновление прав доступа (долгое). Откройте настройку расписания.

Для ускорения процесса в условиях технологического окна настройте расписание с минимальным интервалом перезапуска (каждые 10–15 секунд при паузе в 1 секунду) и проверьте количество разрешенных потоков в настройках кластера серверов 1С. Разрешите параллельное выполнение нескольких фоновых заданий, если дисковая подсистема СУБД построена на быстрых NVMe-накопителях и не имеет очередей на запись.

Шаг 4. Обязательное регламентное обслуживание СУБД

Расчет дескрипторов доступа генерирует многомерные матрицы соединений в запросах к СУБД. Платформа активно использует временные таблицы, соединения регистров сведений прав и таблиц состава групп пользователей. Если после восстановления базы из копии оптимизатор СУБД опирается на устаревшую статистику распределения ключей, время выполнения элементарного запроса расчета возрастает с 5 миллисекунд до десятков секунд.

Перед запуском массового пересчета прав выполните на стороне СУБД следующие операции:

Обновление статистик: Для Microsoft SQL Server выполните процедуру sp_updatestats или команду полного обновления статистики с признаком FULLSCAN для таблиц с префиксами _InfoRg (регистры сведений прав) и _Reference (справочники дескрипторов). Для PostgreSQL выполните команду ANALYZE для всей базы данных.
Перестроение индексов: При массовой перезаписи регистров дескрипторов фрагментация индексов быстро достигает критических значений. Выполните реорганизацию или перестроение индексов по таблицам прав доступа.
Контроль журнала транзакций: Убедитесь, что файл журнала транзакций (LDF в MS SQL или WAL-сегменты в PostgreSQL) имеет достаточный запас свободного пространства на диске и не ограничен низким шагом автороста.

Оптимизация структуры дескрипторов и матриц ограничений

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

Использование рабочих групп объектов: Если в конфигурации к каждому документу привязывается уникальный список сотрудников в рабочей группе, система вынуждена создавать индивидуальный дескриптор доступа практически под каждый документ. Перевод прав на типовые профили, подразделения или назначение локальных администраторов (путь: Настройка программы → Настройка прав доступа → Локальные администраторы) сокращает общее число формируемых дескрипторов в десятки раз.
Очистка неиспользуемых записей: По данным отчета «Дескрипторы доступа» выявите неиспользуемые дескрипторы и дескрипторы, привязанные к помеченным на удаление объектам. Запустите регламентную процедуру удаления неиспользуемых дескрипторов для минимизации размера расчетных таблиц.
Анализ содержимого дескриптора: Открыв карточку конкретного дескриптора, перейдите на закладку Данные. Здесь содержатся параметры, на основе которых формируется ключ доступа. Если для схожих документов генерируются разные дескрипторы из-за второстепенных реквизитов (например, опционального грифа доступа или второстепенного вопроса деятельности), пересмотрите политики заполнения реквизитов для укрупнения дескрипторов.