← На главную

При настройке регулярного обмена данными между базами (например, УТ 10 — УТ 10) многие сталкиваются с серьезной проблемой: в момент загрузки или выгрузки пакетов данных пользователи рабочей базы (которых может быть 150 и более) не могут проводить или записывать документы. Возникает конфликт блокировок, система зависает, а интерфейс начинает «тормозить». Разберем по шагам, почему возникает эта проблема и какие существуют способы её комплексного решения.

1. Оптимизация порций данных и частоты обмена

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

1. Уменьшение объектов в транзакции: Настройте параметр КоличествоЭлементовВТранзакции. Если передавать объекты порциями (например, по 100 или 1000 элементов), транзакции становятся короче. Исключительные блокировки сбрасываются быстрее, давая пользователям «окно» для работы. Важно помнить: при этом теряется принцип «всё или ничего». Если часть пакета не загрузится из-за ошибки, в базе могут появиться документы без движений по регистрам.
2. Увеличение частоты обменов: Чем чаще запускается обмен (например, каждые 15-30 минут вместо одного раза в день), тем меньше объем передаваемых данных в каждом пакете, и тем быстрее проходит транзакция.
3. Ограничение сеанса: Можно программно ограничить выгрузку только определенным количеством зарегистрированных объектов, добавляя паузы (например, пустым циклом) между загрузкой больших пакетов.

2. Перенос обмена на монопольное время

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

3. Настройка кластера серверов 1С и распределение нагрузки

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

Однако кластеризация серверов 1С крайне полезна для решения проблемы «тормозов» интерфейса:

1. Разберем механизм Требования назначения функциональности (доступен в современных версиях платформы 1С). Вы можете добавить второй рабочий сервер в кластер и жестко указать, что все фоновые и регламентные задания (включая обмены) должны выполняться исключительно на нем.
2. Интерактивные сеансы пользователей (клиентские подключения) привязываются к основному серверу.
3. В результате тяжелый процесс обмена забирает процессорное время и оперативную память только у выделенного сервера, не мешая пользователям комфортно работать в интерфейсе.

Примечание по отказоустойчивости SQL: если вы планируете создавать отказоустойчивый кластер на уровне MS SQL Server, помните, что объединить серверы разных версий (например, 2005 и 2008) в единый Failover Cluster невозможно. Версии и редакции SQL на всех узлах должны быть строго идентичны.

4. Переход на управляемые блокировки (Главное решение)

Проанализируем архитектурную суть проблемы. Конфигурация «Управление торговлей 10» исторически создавалась под режим автоматических блокировок. В этом режиме всеми блокировками управляет сам MS SQL Server.

Когда при обмене происходит массовая запись множества объектов, SQL Server часто применяет механизм «эскалации блокировок». Чтобы не тратить ресурсы на удержание тысяч блокировок отдельных строк, он объединяет их и блокирует целиком страницы данных или всю таблицу. Именно поэтому пользователи вообще ничего не могут записать в параллельном режиме.

Посмотрим на самое эффективное, хотя и трудозатратное решение:

1. Перевод конфигурации в режим управляемых блокировок. В этом режиме за логику отвечает сервер 1С, который передает в СУБД максимально точечные команды. Блокируются только те записи (или диапазоны ключей регистров), которые действительно изменяются в данный момент.
2. Это потребует рефакторинга кода (добавления объекта БлокировкаДанных в критичных местах проведения), однако это единственный гарантированный способ обеспечить комфортную параллельную работу 150+ пользователей и фоновых процессов обмена.

Подведем итог: если у вас возникают блокировки при обмене, сначала попробуйте дробить транзакции и увеличить частоту обменов. Если позволяет железо, вынесите регламентные задания на отдельный рабочий сервер в кластере 1С. А для кардинального решения проблемы конкурентного доступа — планируйте перевод конфигурации на управляемые блокировки.