Что такое коллизия в 1С и как её устранить

Термин «коллизия» в 1С встречается в двух принципиально разных ситуациях, и путать их нельзя. Первая — ошибка «Коллизия блокировок при выполнении транзакции», которая возникает при одновременной работе пользователей с одними и теми же данными в клиент-серверной базе. Вторая — коллизия при обмене данными между узлами распределённой информационной базы (РИБ) или при синхронизации с другими системами, когда один и тот же объект изменён в двух местах до обмена.

Оба явления связаны с конкурентным доступом к данным, но механизмы их возникновения и способы устранения различаются. Коллизия блокировок — это вопрос производительности и архитектуры кода, коллизия обмена — вопрос целостности и приоритетов данных. Ниже разобраны оба случая: как распознать ситуацию, что проверить и какие действия безопасно выполнить самостоятельно.

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

Виды коллизий в 1С и как их отличить

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

Коллизия блокировок проявляется сообщением вида «Коллизия блокировок при выполнении транзакции: превышено максимальное время ожидания предоставления блокировки» или указанием на взаимоблокировку (deadlock). Возникает в момент записи документа, проведения, закрытия смены, расчёта зарплаты — то есть при любой операции, изменяющей данные, в многопользовательском режиме.

Коллизия обмена данными видна в мониторе обмена или в журнале регистрации: система сообщает, что объект был изменён и в текущем узле, и в узле-корреспонденте с момента последнего обмена. Типичный признак — после синхронизации изменения из одной базы «затёрли» изменения из другой.

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

Коллизия блокировок: почему возникает ошибка в транзакции

Когда пользователь проводит документ, 1С накладывает блокировки на затрагиваемые данные: остатки регистров, записи справочников, последовательности. Если параллельно другой процесс уже заблокировал часть этих ресурсов и сам ждёт освобождения ресурсов первого процесса, возникает взаимная блокировка. СУБД (MS SQL Server, PostgreSQL и др.) принудительно завершает одну из транзакций — пользователь видит ошибку коллизии.

Типичные причины регулярных коллизий блокировок:

• длинные транзакции — например, проведение большого документа с сотнями строк, внутри которого выполняются запросы к тем же регистрам;
• проведение документов «внавал» пакетной обработкой одновременно с интерактивной работой пользователей;
• отсутствие индексов по полям, используемым в запросах внутри транзакции — блокировка захватывает лишние диапазоны;
• запись в одни и те же «горячие» объекты: общие константы, один счёт, один склад, один узел плана обмена;
• регламентные задания (расчёт итогов, обновление агрегатов, обмен), запущенные в часы активной работы.

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

Что делать пользователю при ошибке «Коллизия блокировок»

Если вы обычный пользователь и увидели сообщение о коллизии блокировок, порядок действий простой и безопасный:

1. Не закрывайте программу аварийно. Данные, которые вы вводили в форме документа, как правило, не потеряны — не записалась только транзакция.
2. Подождите 15–30 секунд и повторите операцию: запишите или проведите документ ещё раз.
3. Если ошибка повторяется несколько раз подряд, уточните у коллег, не выполняют ли они массовую обработку, перепроведение или обмен данными в этот момент.
4. Сообщите администратору или специалисту по 1С точное время ошибки, текст сообщения и операцию, которую выполняли — эти данные нужны для анализа журнала регистрации.

Самостоятельно «лечить» базу тестированием и исправлением или очисткой таблиц не нужно — при конкурентных блокировках это не помогает, а при неправильном применении может повредить данные.

Как администратору снизить число коллизий блокировок

Работа администратора начинается с диагностики. Основные источники информации — журнал регистрации (фильтр по ошибкам с текстом «Коллизия блокировок») и технологический журнал сервера 1С с настроенным сбором событий блокировок (DBLOCK, TLOCK, TDEADLOCK). Для MS SQL Server дополнительно анализируются данные о взаимоблокировках на стороне СУБД.

Практические меры, которые обычно дают эффект:

• перевести базу в управляемый режим блокировок, если конфигурация это поддерживает — он сужает область блокировок по сравнению с автоматическим режимом;
• включить у регистров накопления и бухгалтерии разделение итогов, чтобы проведение документов не блокировало итоговые записи;
• развести по времени тяжёлые операции: регламентные задания, обмены и пакетное перепроведение перенести на нерабочие часы;
• ограничить одновременный запуск нескольких экземпляров одного регламентного задания;
• проверить индексацию таблиц, участвующих в проблемных транзакциях, и обновить статистику на стороне СУБД;
• при росте числа пользователей в файловой базе рассмотреть переход на клиент-серверный вариант.

Если коллизии локализованы в конкретном документе или обработке, потребуется доработка кода: сокращение транзакций, вынос запросов за пределы транзакции, упорядочивание обращений к ресурсам (все процессы блокируют объекты в одном и том же порядке — это устраняет взаимоблокировки).

1. 1
   Найдите в журнале регистрации ошибки коллизии и зафиксируйте время, пользователя и операцию
2. 2
   Определите конкурирующий процесс: регламентное задание, обмен, пакетная обработка
3. 3
   Проверьте режим управления блокировками и разделение итогов у регистров
4. 4
   Разнесите конфликтующие процессы по времени
5. 5
   Проверьте индексы и статистику на стороне СУБД
6. 6
   Повторите операцию в рабочем режиме и убедитесь, что ошибка не воспроизводится

Коллизия при обмене данными: что это и почему возникает

В распределённой информационной базе или при синхронизации (например, УТ ↔ БП) коллизия возникает, когда один и тот же объект — документ, элемент справочника — изменён в обоих узлах в период между сеансами обмена. При загрузке сообщения система обнаруживает: в текущем узле объект тоже менялся с момента последней выгрузки, значит, простое применение изменений приведёт к потере одной из версий.

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

Признаки коллизии обмена: в мониторе обмена есть предупреждения, часть объектов помечена как незагруженные, данные в узлах расходятся, хотя обмен завершается «успешно».

Как разрешить коллизию обмена

Разрешение выполняется в мониторе обмена данными (в типовых конфигурациях — раздел «Синхронизация данных», ссылка на предупреждения или «Проблемы обмена»). Для каждого конфликтного объекта доступны варианты:

• принять версию из сообщения обмена — данные из другого узла заменят текущие;
• оставить текущую версию — пришедшие изменения будут отклонены;
• открыть обе версии и сравнить их перед принятием решения.

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

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

Маршрут решения

Как выбрать действие

Ошибка «Коллизия блокировок» у одного пользователя, разовоПовторите операцию через 15–30 секунд, никаких дополнительных действий не требуется

Коллизия блокировок повторяется у разных пользователей в одной операцииАнализируйте журнал регистрации, режим блокировок, индексы и расписание регламентных заданий

Предупреждения о коллизиях в мониторе обменаОткройте список конфликтов, сравните версии объектов и примите решение по каждому

Данные в узлах РИБ расходятся, а коллизий не видноПроверьте состав узлов, регистрацию изменений и выполните полную выгрузку начального образа при необходимости

Типичные ошибки при работе с коллизиями

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

Контрольные точки

Как проверить результат

Повторное выполнение операции после разовой коллизии блокировок

Норма

Документ проводится без ошибок

Тревожный признак

Ошибка воспроизводится стабильно

Монитор обмена после разрешения коллизий

Норма

Нет предупреждений, все объекты загружены

Тревожный признак

Остаются неразрешённые конфликты или ошибки загрузки

Сверка данных в узлах обмена

Норма

Ключевые документы и остатки совпадают

Тревожный признак

Расхождения в остатках или документах

Журнал регистрации за неделю после мероприятий

Норма

Число коллизий снизилось до единичных случаев

Тревожный признак

Количество ошибок не изменилось

Частые вопросы о коллизиях в 1С

Коллизия блокировок — это признак повреждения базы?

Нет. Это штатная реакция СУБД на конкурентный доступ к данным: одна из транзакций завершается, чтобы избежать взаимной блокировки. Поводом для проверки целостности базы коллизия не является.

Теряются ли данные при коллизии блокировок?

Данные, уже записанные в базу другими транзакциями, не теряются. Не сохраняется только та транзакция, которая была отменена — введённые в форму значения обычно можно записать повторно.

Можно ли полностью исключить коллизии блокировок?

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

Что будет, если не разрешать коллизии в обмене данными?

Конфликтные объекты останутся в разных версиях в разных узлах, данные баз будут расходиться. Со временем это приводит к расхождению остатков, двойным документам и ошибкам в отчётности.

Какая версия данных приоритетна при коллизии в РИБ?

По умолчанию в типовой РИБ изменения главного узла принимаются автоматически, а изменения из подчинённого узла, конфликтующие с локальными, откладываются для ручного разрешения. Конкретное поведение зависит от настроек плана обмена.

Помогает ли переход на управляемые блокировки?

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