Переход на 64-битную платформу 1С:Предприятие часто сопровождается не только приростом производительности, но и возникновением специфических проблем, таких как ошибка Microsoft SQL Server Native Client 11.0: Превышено время ожидания запроса на блокировку (HRESULT=80040E31, native=1222). Это происходит из-за изменения модели потребления ресурсов и скорости выполнения транзакций. Проанализируем ситуацию и разберем по шагам, как локализовать и устранить эти конфликты. Для автоматического отслеживания подобных сбоев есть мониторинг ошибок в журнале регистрации 1С с уведомлением в Telegram.
Если блокировки начали парализовать работу пользователей, первым делом стоит применить «терапевтические» меры, которые дадут системе запас времени — для этого подойдёт утилита администрирования 1С и мониторинга активных сеансов. Рассмотрим, как изменить стандартный таймаут ожидания блокировки.
По умолчанию в 1С установлено время ожидания 20 секунд. В условиях тяжелых регламентных заданий или обменов (например, с сайтом или «1С:Бухгалтерией») этого может быть недостаточно. Выполним следующие действия:
Важно понимать: это не решает причину проблемы, а лишь отодвигает момент возникновения ошибки. Если транзакция удерживает таблицы слишком долго, пользователи все равно будут ждать, но реже видеть окно с ошибкой. Также проанализируем текущие сеансы в консоли администрирования. Иногда достаточно завершить «зависший» сеанс, который держит блокировку, чтобы работа возобновилась — для этого подойдет обработка управления сеансами и соединениями 1С в реальном времени.
Чтобы выяснить, какой именно кусок кода или запрос вызывает конфликт, необходимо настроить Технологический журнал (ТЖ) — в этом поможет инструмент анализа производительности 1С по технологическому журналу. Это единственный надежный способ увидеть контекст ошибки на стороне 1С. Создадим файл logcfg.xml в папке с настройками сервера 1С (обычно это C:\Program Files\1cv8\conf).
Разберем пример конфигурации файла для отлова блокировок:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\Logs\Locks" history="24">
<event>
<eq property="Name" value="TLOCK"/>
</event>
<event>
<eq property="Name" value="TTIMEOUT"/>
</event>
<event>
<eq property="Name" value="TDEADLOCK"/>
</event>
<property name="all"/>
</log>
</config>
После настройки ТЖ проанализируем события TTIMEOUT и TLOCK. В логах мы увидим свойство Context, которое укажет на конкретную строку кода в общем модуле или модуле объекта (например, при записи документа РегистрацияЦен или выполнении обработки ЗаменаДублей), где произошло ожидание.
Одной из главных причин конфликтов блокировок на уровне СУБД является то, что читающие транзакции блокируются пишущими. В современных конфигурациях, таких как УТ 11.3, рекомендуется использовать режим Read Committed Snapshot Isolation (RCSI). Выясним, как это работает: при включении этого режима SQL Server хранит версии строк в TempDB, позволяя пользователям читать данные без ожидания завершения записи.
Для включения этого режима выполним следующий скрипт в SQL Server Management Studio (предварительно переведя базу в однопользовательский режим или убедившись, что соединений нет):
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
Это кардинально снижает вероятность ошибки 1222, особенно при активных обменах данными.
При переходе на x64 сервер начинает агрессивнее использовать многопоточность. Если параметр Max Degree of Parallelism (MAXDOP) установлен в «0», SQL Server может выделять все ядра на один сложный запрос, вызывая микро-блокировки других процессов. Проанализируем настройки сервера:
High Performance. На x64 системах динамическое изменение частоты процессора (сбалансированный режим) приводит к существенным задержкам при открытии транзакций.Ошибка Native Client 11.0 может возникать из-за устаревания самого компонента доступа к данным. Рассмотрим замену драйвера. Microsoft прекратила развитие Native Client, поэтому стоит рассмотреть установку и использование Microsoft ODBC Driver for SQL Server версии 17 или 18. Это повышает стабильность соединения между рабочими процессами 1С и СУБД.
Также не забудем про регламентное обслуживание. Если статистика SQL Server устарела, оптимизатор может выбрать неверный план запроса, который наложит избыточные блокировки на таблицы (например, сканирование всей таблицы вместо поиска по индексу) — провести диагностику поможет обработка анализа структуры и объема таблиц и индексов базы данных. Настроим ежедневное выполнение следующих операций:
Update Statistics (Обновление статистики).Index Defragmentation (Дефрагментация индексов).Поскольку автор упоминает, что блокировки возникают при обмене с сайтом и замене дублей, проанализируем алгоритмы этих процессов. Часто проблема кроется в слишком больших порциях данных, обрабатываемых в одной транзакции. Разберем рекомендации:
Заблокировать() для объектов, которые только читаются.Соблюдение этих шагов — от настройки Технологического журнала до оптимизации SQL-параметров — позволит не только избавиться от ошибки конфликта блокировок, но и значительно повысить общую отзывчивость системы после перехода на 64-битную архитектуру.