Каждый администратор баз данных и разработчик 1С рано или поздно сталкивается со страшным сном: в стабильно работающей системе внезапно начинаются массовые взаимоблокировки (дедлоки). Пользователи жалуются, что база «зависает», документы не проводятся, кассы на точках не могут пробить чеки, а обычный подбор номенклатуры в документ вызывает ошибку блокировки. Ситуация становится критической, когда документы записываются частично (например, из 128 строк записываются только 56, а остальные пропадают), а штатная выгрузка базы в формат .dt начинает завершаться с ошибками.
В этой статье мы подробно разберем, почему возникают такие проблемы, как на это влияют обновления законодательства (такие как переход на НДС 20% и ФФД 1.05), почему обычная выгрузка и загрузка базы через .dt временно решает проблему и как настроить MS SQL Server и конфигурацию 1С раз и навсегда, чтобы забыть о дедлоках.
Автор темы отметил, что после выполнения выгрузки информационной базы в файл .dt и последующей загрузки ее в новую базу данных на SQL-сервере скорость работы выросла в 10 раз, а дедлоки мгновенно прекратились. Давайте проанализируем, что именно происходит на физическом уровне в СУБД во время этой операции:
.dt, она не просто вставляет строки в существующие таблицы. Она полностью удаляет старую структуру базы данных на SQL-сервере и создает таблицы и индексы с нуля. В этот момент фрагментация абсолютно всех индексов становится равной 0%. Чтение данных начинает происходить максимально быстро, без лишних сканирований диска.Важное предупреждение: Фирма «1С» настоятельно рекомендует не использовать формат .dt как средство резервного копирования для баз на SQL. Если в вашей базе есть физические повреждения (например, поврежденные страницы на диске), выгрузка в .dt может пройти успешно, но загрузить базу обратно вы уже не сможете! Единственным надежным способом бэкапа для SQL-баз является создание файлов резервных копий средствами самой СУБД (файлы .bak).
Давайте разберем по шагам механизм, связывающий плохую производительность дисков или фрагментацию индексов с возникновением взаимоблокировок:
Когда индекс сильно фрагментирован или статистика устарела, SQL-сервер не может быстро найти конкретную строку (например, остаток товара «Номенклатура А» на складе «Основной»). Вместо точечного поиска (Index Seek) СУБД вынуждена выполнять полное сканирование таблицы или индекса (Clustered Index Scan). Это приводит к двум катастрофическим последствиям:
TABLOCK). В этот момент все остальные пользователи, пытающиеся записать данные в эту таблицу, полностью блокируются.S-lock) на диапазон данных. Касса №2 делает то же самое. Затем обе кассы пытаются списать товар, что требует монопольной блокировки (X-lock). Возникает ситуация, когда Касса №1 ждет освобождения данных Кассой №2, а Касса №2 ждет Кассу №1. СУБД фиксирует дедлок и аварийно завершает одну из транзакций, делая её «жертвой» (Deadlock Victim). Пользователь при этом видит ошибку транзакции, а документ проводится лишь частично.Почему дедлоки часто начинаются «ни с того ни с сего» после обновления конфигурации (например, УТ 10.3 под новые кассовые требования)? Выясним причину этой взаимосвязи:
При переходе на формат фискальных данных ФФД 1.05 система обязана передавать на кассовый аппарат детальные признаки расчета, ставку НДС и систему налогообложения для каждой строки чека. Разработчики часто реализуют это путем динамического обращения к справочнику номенклатуры и регистрам сведений в момент пробития чека.
Самая большая ошибка здесь — выполнение физической печати чека на ККТ внутри транзакции СУБД. Физический принтер чеков печатает медленно, обменивается данными с ОФД через интернет, и этот процесс может занимать от 2 до 10 секунд. Если все это время транзакция в 1С остается открытой, наложенные СУБД блокировки на таблицы товаров, остатков и касс продолжают удерживаться. Другие кассы выстраиваются в очередь ожидания и в итоге «отваливаются» по таймауту или вызывают взаимоблокировки.
Решение: Физическая фискализация (печать чека на кассе) должна быть полностью отделена от транзакции проведения документа в базе данных. Сначала документ должен быстро провестись в базе (это занимает миллисекунды), транзакция должна закрыться, и только после этого команда на печать чека должна отправляться на кассовый аппарат.
Для того чтобы решить проблему дедлоков раз и навсегда, выполним комплексную настройку нашей СУБД и базы данных 1С.
Параметр MAXDOP (Max Degree of Parallelism) определяет максимальное количество ядер процессора, которое СУБД может задействовать для выполнения одного запроса. По умолчанию этот параметр равен 0 (использовать все доступные ядра). Для баз данных 1С это крайне опасно, так как тяжелые запросы начинают параллелиться, вызывают взаимные блокировки потоков одного запроса (intra-query deadlocks) и перегружают процессор.
Установим значение MAXDOP в 1. Это принудительно заставит СУБД выполнять каждый отдельный запрос в один поток, что полностью ликвидирует внутризапросные дедлоки.
Для этого в среде SQL Server Management Studio (SSMS) выполним следующий скрипт:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
Если у вас очень мощный сервер и многоядерные процессоры, можно установить значение от 2 до 4, но при этом обязательно нужно поднять порог стоимости параллелизма (cost threshold for parallelism) со стандартных 5 до 50 или 80 секунд, чтобы мелкие запросы касс гарантированно выполнялись в один поток.
По умолчанию в базах 1С с автоматическим режимом блокировок читающие транзакции блокируют пишущие, а пишущие — читающие. Чтобы решить эту проблему на уровне СУБД, включим режим версионирования строк Read Committed Snapshot Isolation (RCSI). При этом читающие запросы будут получать согласованные версии строк из базы данных tempdb без наложения разделяемых блокировок (S-locks). Чтение больше никогда не будет блокировать запись!
Выполним по шагам скрипт для включения RCSI (обратите внимание, что базу потребуется перевести в монопольный режим, поэтому выполнять это нужно во время отсутствия пользователей):
-- Переводим базу в монопольный режим и сбрасываем активные соединения
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
-- Включаем режим версионирования строк
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
-- Возвращаем базу в многопользовательский режим
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
Важное требование: Так как версии строк будут сохраняться во временной базе данных tempdb, нагрузка на дисковую систему, где лежит tempdb, существенно возрастет. Настоятельно рекомендуется перенести файлы базы tempdb на максимально быстрый физический диск (желательно NVMe SSD).
Если в базе данных возникли логические или физические сбои, их необходимо локализовать и устранить. Запустим проверку целостности базы данных без остановки работы пользователей (хотя это может вызвать временное снижение производительности):
DBCC CHECKDB ('Имя_Вашей_Базы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если проверка выявила ошибки, базу необходимо перевести в монопольный режим и восстановить с помощью команды REPAIR_ALLOW_DATA_LOSS или восстановить из последнего чистого SQL-бэкапа.
Также сбросим старый кэш планов запросов, в котором могли зависнуть неоптимальные планы:
DBCC FREEPROCCACHE;
Чтобы проблема с фрагментацией индексов и устаревшей статистикой не повторилась через несколько недель, настроим автоматические задачи обслуживания в SQL Server Agent:
FULLSCAN. Свежая статистика — это гарантия того, что SQL Server всегда будет выбирать оптимальные и быстрые планы запросов.Если ваша конфигурация (например, УТ 10.3) работает полностью в режиме автоматических блокировок, это накладывает серьезные ограничения на параллельную работу. Самым надежным архитектурным решением проблемы блокировок является перевод конфигурации (или ее наиболее критичных документов и регистров — «Чек ККМ», «Расходный ордер», регистры остатков товаров) на управляемый режим блокировок.
В управляемом режиме разработчик с помощью специального объекта БлокировкаДанных сам явно указывает платформе, какие конкретно записи и по каким разрезам (например, только по конкретному складу и списку товаров из документа) нужно заблокировать на время транзакции проведения. Это полностью исключает избыточные блокировки соседних данных и делает работу сотен пользователей легкой и бесконфликтной.