Проблема возникновения ошибки «Конфликт блокировок при выполнении транзакции» является одной из самых распространенных при выполнении регламентных операций в тяжелых конфигурациях, таких как 1С:Комплексная автоматизация 2.4 или 1С:ERP. Ситуация часто осложняется тем, что закрытие месяца запускается в разгар рабочего дня, когда пользователи активно вводят первичные документы. Рассмотрим подробно причины возникновения этой ошибки, проанализируем технические нюансы работы регистров и разберем по шагам способы оптимизации системы для стабильной работы.
Разберем природу блокировки. В системе 1С при записи документа или выполнении расчета запускается транзакция. Чтобы данные оставались согласованными, система «бронирует» определенные таблицы или записи в базе данных, запрещая другим процессам их изменять. Если процедура Закрытие месяца (например, расчет себестоимости) и обычный пользователь одновременно пытаются получить доступ к одному и тому же ресурсу (регистру), возникает очередь. Если ожидание превышает установленный лимит (обычно 20 секунд), система выдает ошибку.
В случае с конфигурацией КА 2.4 наиболее «конфликтным» объектом является регистр накопления ДетализацияПартийТоваровДляНДСиУСН. Проанализируем ситуацию, описанную в сообщениях форума: ошибка записи движений по этому регистру возникает даже при проведении старых документов. Это происходит потому, что расчет партионного учета — крайне ресурсоемкая операция, которая накладывает исключительные блокировки на таблицы итогов.
Как справедливо отмечено в обсуждении, закрывать месяц во время активной работы пользователей — это практика, ведущая к деградации производительности. Рассмотрим основные рекомендации по организации процесса:
ДатаЗапретаРедактирования для всех пользователей, включая администраторов, чтобы исключить случайное перепроведение документов, вызывающее цепочку пересчетов партий.В современных конфигурациях 1С многие расчеты происходят «незаметно» для пользователя. Выясним причину, по которой система может блокироваться сама собой. В КА 2.4 существует механизм фонового расчета партий.
Посмотрим на настройки в разделе НСИ и администрирование — Финансовый результат и контроллинг. Если включены опции «Рассчитывать предварительную себестоимость» или «Рассчитывать партии фоновым заданием», система будет постоянно пытаться актуализировать регистр ДетализацияПартийТоваровДляНДСиУСН. В рабочее время это создает постоянный фон для блокировок. Рекомендуем отключать эти опции в периоды пиковой нагрузки и запускать их вручную или по расписанию в часы затишья.
Проанализируем техническую сторону взаимодействия 1С с MS SQL Server. По умолчанию SQL-сервер использует блокировки при чтении данных, что часто приводит к конфликтам с пишущими транзакциями. Для решения этой проблемы разработано решение — режим Read Committed Snapshot Isolation (RCSI).
Разберем по шагам, что дает включение этого режима:
TempDB.Для включения этого режима на стороне SQL-сервера (при отсутствии активных соединений с базой) используется следующий код:
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
Важно: Перед выполнением данной операции обязательно проконсультируйтесь с системным администратором и сделайте резервную копию базы данных.
В КА 2.4 расчет себестоимости может выполняться в несколько потоков. Казалось бы, это должно ускорять процесс, но при большом количестве конфликтов эффект может быть обратным. Если несколько потоков одновременно пытаются записать данные в одни и те же таблицы регистров партий, они начинают блокировать друг друга.
Рассмотрим возможность изменения настроек многопоточности:
Закрытие месяца.Выясним причину, по которой «с пятницы стало постоянно» возникать ошибка. Если нагрузка не менялась, но блокировки участились, вероятно, дело в деградации статистики SQL-сервера. Оптимизатор запросов начинает выбирать неверные планы выполнения (например, полное сканирование таблицы Table Scan вместо поиска по индексу Index Seek).
Проанализируем необходимые регламентные операции на SQL-сервере:
ЗаданияКРасчетуСебестоимости и ЗаданияКРаспределениюРасчетов. Если в них накопились записи за прошлые годы (как в примере из 2017 года), система будет пытаться пересчитать огромный массив данных. Рекомендуем проверить эти регистры и удалить из них «мусорные» записи за закрытые и неактуальные периоды.Подводя итог, можно сказать, что конфликт блокировок в КА 2.4 — это комплексная проблема. Для ее решения мы рекомендуем:
Во-первых, навести порядок в регламенте: закрывать периоды монопольно или ночью, обязательно устанавливать дату запрета редактирования.
Во-вторых, проверить технические настройки: включить RCSI на SQL-сервере и убедиться, что регламентные задания по обслуживанию индексов выполняются ежедневно.
В-третьих, проанализировать очередь заданий к расчету. Если система пытается «тянуть» расчет с 2017 года, никакие аппаратные мощности не помогут избежать блокировок — нужно устранить первопричину в данных или очистить очередь пересчета.
Соблюдение этих правил позволит сделать процесс закрытия месяца предсказуемым и стабильным, минимизировав простой пользователей и стресс для бухгалтерии.