Ситуация, когда стабильно работавшая годами система начинает давать сбои после изменения бизнес-процессов (например, подключения онлайн-касс), является классической для конфигураций на базе 1С:Управление торговлей 10.3. Основная сложность заключается в том, что эта конфигурация использует автоматический режим блокировок, который крайне чувствителен к длительности транзакций и настройкам SQL-сервера. Разберем пошагово, как выявить причину «зависаний» и настроить сервер для стабильной работы.
Первым делом нам необходимо понять, почему проблема обострилась именно после подключения кассовых аппаратов. В старых конфигурациях, таких как УТ 10.3, процесс проведения документа и печати чека часто объединен в одну транзакцию. Рассмотрим типичную последовательность действий:
Commit).Если в этот момент касса «тупит», возникли проблемы с интернетом или драйвер долго обрабатывает запрос, транзакция в SQL остается открытой. Другие 15 пользователей, пытающиеся провести документы, обращаются к тем же таблицам и встают в очередь. Выясним, как это диагностировать.
Для определения виновника блокировок воспользуемся инструментами платформы и СУБД. Проанализируем ситуацию через Консоль кластера серверов 1С. Нам важны следующие параметры в списке соединений:
Параллельно в SQL Server Management Studio (SSMS) выполним стандартный запрос для поиска блокирующих процессов:
SELECT
blocking_session_id AS BlockingSessionID,
session_id AS VictimSessionID,
wait_time,
wait_type,
last_wait_type
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;
Это позволит нам точно определить, на уровне какой таблицы SQL происходит конфликт. Часто в УТ 10.3 это касается общего модуля ПолныеПрава, где выполняются системные записи в регистры сведений или проверку прав. Рассмотрим код, который может вызывать подобные задержки:
// Пример критического участка в модуле ПолныеПрава
Процедура ЗаписатьОбъектВИнформационнуюБазу(Объект) Экспорт
Объект.Записать(); // Здесь SQL накладывает исключительную блокировку
КонецПроцедуры
Если железо (SSD, достаточный объем ОЗУ) в порядке, а ошибки продолжаются, необходимо проверить специфические настройки SQL-сервера, которые критичны для работы с 1С.
1. Настройка параллелизма (MAXDOP). По умолчанию SQL Server пытается распараллелить выполнение одного тяжелого запроса на все ядра процессора. Для 1С это часто приводит к взаимным блокировкам (deadlocks). Установим значение Max Degree of Parallelism в 1. Это заставит каждый запрос выполняться в рамках одного ядра, что значительно снижает вероятность блокировок в автоматическом режиме.
2. Регулятор стоимости запроса (Cost Threshold for Parallelism). Если вы не хотите полностью отключать параллелизм, поднимите порог стоимости с 5 до 50. Это предотвратит дробление мелких запросов на потоки.
3. Включение режима Snapshot Isolation. Рассмотрим применение механизма READ_COMMITTED_SNAPSHOT (RCSI). Это одна из самых эффективных настроек для борьбы с блокировками «чтение-запись». Она позволяет пользователям читать данные из TempDB (версионное хранилище), не дожидаясь окончания транзакций записи. Выполним скрипт (предварительно выгнав всех пользователей):
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
Важно: при включении RCSI значительно возрастает нагрузка на базу TempDB. Убедитесь, что она расположена на самом быстром SSD в системе.
Проанализируем состояние индексов и статистики. Если статистика SQL устарела, оптимизатор может выбрать неверный план выполнения запроса (например, Index Scan вместо Index Seek), что увеличивает время блокировки таблиц. Разберем необходимый минимум обслуживания:
UPDATE STATISTICS. В 1С 8.2/8.3 это критично для корректной работы планировщика SQL.ALTER INDEX REBUILD в ночное время для устранения фрагментации.DBCC FREEPROCCACHE, чтобы SQL перестроил планы выполнения.Часто причиной блокировок становятся регламентные задания 1С, которые запускаются автоматически. В УТ 10.3 это могут быть:
Воспользуемся обработкой «Консоль заданий», чтобы посмотреть, какие процессы выполнялись в момент возникновения ошибки у кассиров. Если фоновое задание «пересекается» по таблицам с чеками ККМ, его следует перенести на нерабочее время.
Как системный администратор, проверьте состояние сетевых подключений. В режиме «толстого клиента» (обычные формы УТ 10.3) разрыв сетевого соединения на доли секунды может привести к тому, что сессия в SQL зависнет в статусе Sleeping, удерживая при этом все блокировки. Проанализируем настройки электропитания сетевых карт на рабочих станциях (запретим отключение для экономии энергии) и стабильность работы коммутаторов.
Подведем итог: проблема в данном случае носит комплексный характер. Это не «ошибка в 1С» или «ошибка в SQL», а результат взаимодействия старого прикладного кода (УТ 10.3) с новой нагрузкой в условиях современных версий СУБД. Сочетание настройки MAXDOP = 1, включение RCSI и разнесение по времени фоновых заданий обычно решает проблему в 90% случаев.