В процессе работы с конфигурацией 1С:Зарплата и Управление Персоналом 3.1 пользователи часто сталкиваются с неприятной ситуацией: при попытке провести документ Табель или открыть форму перерасчетов система выдает критическую ошибку. Текст ошибки обычно выглядит так: {ОбщийМодуль.ПерерасчетЗарплаты.Модуль(2807)}: Ошибка при вызове метода контекста (Записать) НаборЗаписей.Записать; по причине: Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки. В этой статье мы подробно разберем, почему возникает данная проблема и какими методами ее можно победить.
Давайте проанализируем, что происходит «под капотом» программы. Ошибка возникает в общем модуле ПерерасчетЗарплаты в момент попытки записи в регистр сведений. В ЗУП 3.1 реализован сложный механизм автоматической регистрации необходимости перерасчетов. Как только в системе изменяются кадровые данные, графики или документы-основания, программа фиксирует это в специальных таблицах — очередях перерасчетов.
Основная проблема заключается в том, что при проведении табеля система пытается проверить, не нужно ли зарегистрировать или, наоборот, удалить записи о перерасчетах для сотрудников. Если база данных работает в режиме автоматических блокировок или если таблица регистра перерасчетов чрезмерно разрослась, транзакция по записи набора записей блокирует значительную часть таблицы. Если в этот же момент другой пользователь проводит начисление зарплаты или формирует другой табель, возникает конфликт, и система «зависает» до истечения времени ожидания.
Как показывает практика, наиболее эффективным методом решения является радикальная очистка регистра перерасчетов. Рассмотрим, как это сделать, если штатные средства 1С не справляются из-за блокировок.
Проанализируем ситуацию: если записей в регистре сотни тысяч, попытка стандартной очистки через интерфейс 1С сама по себе может вызвать конфликт блокировок. В этом случае мы можем прибегнуть к инструментам СУБД (например, MS SQL Server). Пошагово разберем этот процесс:
НастройкаПерерасчетов или аналогичным регистрам очереди. Для этого можно воспользоваться консолью запросов или специальными обработками по поиску метаданных.После очистки таблицы «завалы» исчезнут, и проведение документов снова станет мгновенным. Стоит учитывать, что после такой очистки программа «забудет», кому именно требовался перерасчет за прошлые периоды, поэтому данные за текущий месяц стоит перепроверить вручную.
Разберем, как минимизировать вероятность конфликтов на уровне системных настроек. Если ваша база работает на SQL-сервере, важно проверить режим управления блокировками.
Перевод в режим управляемых блокировок. Проанализируем настройки базы в SQL Server Management Studio. Рекомендуется включить параметр Is Read Committed Snapshot On. Это позволит транзакциям выполняться на уровне изоляции ReadCommitted с использованием версионности строк, что значительно снижает количество блокировок типа SERIALIZABLE.
Также обратим внимание на параметр Max Degree of Parallelism (MAXDOP). В высоконагруженных системах 1С рекомендуется устанавливать MAXDOP = 1. Это предотвращает ситуацию, когда SQL Server распараллеливает простую операцию записи в таблицу перерасчетов на множество потоков, которые в итоге начинают блокировать друг друга на уровне страниц данных (LATCH-блокировки).
В самой программе ЗУП 3.1 есть настройки, напрямую влияющие на поведение механизмов перерасчета. Рассмотрим их подробнее:
Выполнять доначисление и перерасчет зарплаты отдельным документом. Если этот флаг включен, система при каждом проведении табеля инициирует поиск всех незакрытых перерасчетов. Попробуйте временно отключить эту опцию, провести «проблемные» документы и включить ее обратно.Выполнять расчет зарплаты без оптимизации. В новых релизах (начиная с 3.1.11) 1С старается отключать этот режим автоматически, так как он создает избыточную нагрузку на таблицы.Часто корни проблем с блокировками растут из «замусоренных» индексов и устаревшей статистики. Проанализируем ситуацию: если статистика распределения данных в таблице перерасчетов устарела, оптимизатор SQL может выбрать неэффективный план запроса (например, сканирование всей таблицы вместо поиска по индексу), что приведет к длительной блокировке всей таблицы.
Рекомендуемые регламентные операции:
Если конфликты возникают из-за кратковременных столкновений пользователей, можно немного «растянуть» время ожидания, чтобы система успевала дождаться освобождения ресурса. Для этого выполним следующие действия в режиме Конфигуратора:
Время ожидания блокировки данных. По умолчанию там может стоять 20 секунд.Проанализируем версию используемой платформы. В версии 8.3.15.1513 был зафиксирован баг, связанный с некорректным поведением менеджера блокировок для MS SQL Server. Если вы используете эту или близкие к ней версии, крайне рекомендуется обновиться до актуальных релизов (например, ветки 8.3.18 или выше). Зачастую переход на новую платформу магическим образом исправляет «фантомные» блокировки, которые не поддаются логическому объяснению.
Мы выяснили, что ошибка в строке 2807 модуля ПерерасчетЗарплаты почти всегда связана с переполнением или блокировкой таблиц регистрации перерасчетов. Для долгосрочного решения проблемы придерживайтесь следующего алгоритма:
Соблюдение этих простых правил позволит вашим транзакциям проходить гладко, а расчетчикам — работать без нервных срывов из-за «вылетающих» ошибок блокировок.