Как устранить взаимоблокировки в 1С:УПП при работе на SQL Server?

← На главную

Взаимоблокировки (deadlocks) в конфигурации "Управление производственным предприятием" (УПП) — это классическая проблема, с которой сталкиваются многие компании при росте количества одновременно работающих пользователей. Ситуация осложняется тем, что УПП традиционно работает в режиме совместимости с платформой 8.2.13, что накладывает определенные ограничения на механизмы управления блокировками. Разберем подробно, почему возникают эти ошибки и как их можно устранить, не прибегая к немедленному переходу на ERP.

Анализируем причины возникновения блокировок в режиме совместимости 8.2

Прежде всего, проанализируем техническую подоплеку. В режиме совместимости 8.2.13 по умолчанию используются автоматические блокировки. Это означает, что управлением очередностью доступа к данным занимается непосредственно СУБД (Microsoft SQL Server). При проведении документа система устанавливает блокировки на уровне таблиц или страниц данных в зависимости от того, какие регистры затрагиваются. Рассмотрим основные факторы, провоцирующие конфликты:

Shared Locks (Разделяемые блокировки): Когда один пользователь читает данные для формирования движений (например, остатки на складах), он блокирует эти данные от изменения другими пользователями.
Exclusive Locks (Исключительные блокировки): Когда документ записывает движения в регистр, он блокирует данные от чтения другими процессами.
Эскалация блокировок: Если транзакция затрагивает большое количество строк (более 5000), SQL Server может заменить блокировки отдельных строк на блокировку всей таблицы Lock Escalation, что моментально парализует работу всех остальных пользователей.

Решение 1: Настройка регламентного обслуживания SQL Server

Как показывает практика и опыт участников обсуждения, зачастую проблема решается не изменением кода, а корректным администрированием базы данных. Если статистика устарела, оптимизатор SQL Server может выбрать неэффективный план запроса, который будет удерживать блокировки дольше необходимого. Реализуем следующий план обслуживания:

Обновление статистики: Проанализируем частоту изменения данных. Для активно работающей базы УПП рекомендуется обновлять статистику ежедневно, а для самых нагруженных таблиц — несколько раз в день.
Дефрагментация и перестроение индексов: Сильно фрагментированные индексы замедляют операции чтения и записи, увеличивая время транзакции. Настроим еженедельное перестроение (Rebuild) для индексов с фрагментацией более 30% и реорганизацию (Reorganize) для остальных.
Очистка процедурного кэша: Иногда после массовых обновлений полезно сбросить закэшированные планы запросов, чтобы SQL Server построил их заново на основе актуальной статистики.

Решение 2: Включение режима Snapshot Isolation (RCSI)

Одним из наиболее эффективных методов борьбы с блокировками "чтение против записи" является перевод базы данных в режим Read Committed Snapshot Isolation. Это позволяет читающим транзакциям получать версию данных из tempdb, не ожидая завершения пишущих транзакций.

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


ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;

Важно: При включении этого режима нагрузка на базу tempdb возрастает, поэтому убедитесь, что она расположена на быстрых SSD-дисках и разделена на несколько файлов данных (по количеству ядер процессора).

Решение 3: Оптимизация параметров SQL Server и кластера 1С

Посмотрим на настройки самого сервера. Для систем 1С критически важным является параметр Max Degree of Parallelism (MAXDOP). Рассмотрим рекомендации:

Установим MAXDOP в значение 1. Это предотвратит ситуацию, когда один тяжелый запрос захватывает все ресурсы процессора и порождает ожидания типа CXPACKET.
Параметр Cost Threshold for Parallelism рекомендуется поднять до 50.

В настройках кластера 1С проанализируем параметр "Количество соединений на процесс". В условиях УПП и большого количества блокировок эффективно работает стратегия разделения нагрузки. Если у вас 40-50 пользователей, попробуйте ограничить количество соединений на один рабочий процесс rphost (например, до 20). Это позволит создать несколько процессов, что повысит общую отказоустойчивость системы при зависании отдельных транзакций.

Решение 4: Изменение режима совместимости и переход на управляемые блокировки

Если административные меры не помогают, придется рассмотреть архитектурные изменения. Рассмотрим два пути:

Повышение режима совместимости: Перевод конфигурации на режим совместимости 8.3.15 и выше позволяет использовать новые возможности платформы и более эффективно работать с памятью. Однако это требует тщательного тестирования, так как могут "вылезти" ошибки в старом коде (например, использование зарезервированных имен в структурах или специфические функции ЕГАИС).
Переход на управляемые блокировки: Это самый надежный, но и самый трудоемкий путь. В свойствах конфигурации устанавливается режим Управляемый, после чего программист должен вручную прописать блокировки в коде перед выполнением запросов к базе данных. Разберем пример установки блокировки в коде:


ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ОстаткиТоваров");
ЭлементБлокировки.УстановитьЗначение("Склад", СкладОбъект);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();

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

Методика диагностики: как найти виновника?

Чтобы понять, какой именно документ или отчет вызывает проблему, воспользуемся инструментами диагностики. Проанализируем ситуацию с помощью Технологического журнала (ТЖ). Настроим сбор событий TLOCK и TDEADLOCK. Это поможет нам увидеть строки кода 1С, на которых происходит ожидание.

Параллельно используем SQL Server Profiler или Extended Events. Нас интересуют события Deadlock graph и Lock:Timeout. Граф взаимоблокировки наглядно покажет два процесса, которые пытаются захватить ресурсы друг друга, и укажет на конкретные таблицы и индексы.

Резюме: Для быстрого решения проблемы в УПП начните с регламентных операций в SQL (статистика и индексы) и включения RCSI. Если это не поможет, проанализируйте настройки MAXDOP и распределение процессов в кластере. Полный отказ от блокировок возможен только при переходе на управляемый режим, что является серьезным инвестиционным проектом по переработке кода конфигурации.