При переходе на новое оборудование или обновлении версий СУБД (например, на MS SQL Server 2019) в старых конфигурациях, таких как "Управление торговлей 10.3", часто возникают проблемы производительности и стабильности. Рассмотрим ситуацию, когда база данных периодически "зависает", пользователи получают ошибки конфликта блокировок (TimeOut или Deadlock), а клиентское приложение аварийно завершает работу с ошибкой в модуле entext.dll. Разберем причины и методы решения этих проблем.
В описанной ситуации мы наблюдаем комплексную проблему, состоящую из трех разных симптомов. Давайте разделим их, так как они требуют разных подходов к лечению.
Сообщение вида: Конфликт блокировок при выполнении транзакции... Превышено время ожидания запроса на блокировку. Это означает, что одна транзакция удерживает ресурс слишком долго, а вторая не дождалась своей очереди.
Сообщение вида: Транзакция (идентификатор процесса X) вызвала взаимоблокировку ресурсов... и стала жертвой взаимоблокировки (код ошибки 1205). Это ситуация, когда два процесса блокируют ресурсы, необходимые друг другу, и СУБД принудительно "убивает" один из них.
Имя сбойного модуля: entext.dll, код исключения: 0xc0000005. Это ошибка доступа к памяти на уровне платформы 1С.
Для конфигураций поколения УТ 10.3 и УПП 1.3 самой частой причиной блокировок при активной параллельной работе пользователей является механизм оперативного списания партий.
Суть проблемы: Когда в настройках учета включена опция "Списывать партии при проведении документов", система при каждом проведении документа реализации пытается рассчитать себестоимость, блокируя регистры партий. При большом потоке документов (400+ в день) образуется очередь, что неминуемо ведет к таймаутам.
Решение: Перевести расчет себестоимости в "офлайн" режим.
Для этого необходимо:
Настройка параметров учета -> Списание запасов.Это действие устраняет причину массовых ожиданий на регистрах накопления и значительно ускоряет оперативную работу пользователей (менеджеров и кассиров).
При использовании MS SQL Server 2019 (и более новых версий) со старыми конфигурациями может наблюдаться деградация производительности из-за неактуальной статистики. Оптимизатор запросов SQL строит неверные планы выполнения (например, полное сканирование таблицы вместо поиска по индексу), что приводит к избыточным блокировкам.
Если вы заметили, что база начинает "тормозить" спустя некоторое время после обслуживания, необходимо настроить регулярное обновление статистики.
Важный нюанс: Автоматического обновления статистики средствами SQL Server может быть недостаточно, так как оно использует выборку (семплирование). Для 1С рекомендуется полное обновление (FullScan).
Рассмотрим пример скрипта, который выполняет реорганизацию индексов и обновление статистики (адаптировано для SQL Server):
USE [ИмяВашейБазы]
GO
-- Включаем возможность блокировки страниц и строк (важно для дефрагментации)
EXEC sp_msforeachtable 'ALTER INDEX ALL ON ? SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON)'
-- Выполняем реорганизацию индексов (менее затратно, чем ребилд)
EXEC sp_msforeachtable 'ALTER INDEX ALL ON ? REORGANIZE WITH (LOB_COMPACTION = ON)'
-- Обновляем статистику с полным сканированием
EXEC sp_msforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
GO
Рекомендуется настроить план обслуживания (Maintenance Plan) в MS SQL Server Management Studio, который будет выполнять обновление статистики раз в сутки (ночью). Если нагрузка очень высокая и данные меняются быстро, можно выполнять обновление статистики для ключевых таблиц чаще.
Ошибка в библиотеке entext.dll (работа с текстом и строками) чаще всего не связана напрямую с кодом конфигурации, а вызвана внешними факторами или повреждением индексов.
Причина А: Конфликт с КриптоПро или Антивирусом
Программы криптозащиты (например, CryptoPro CSP) и антивирусы могут внедряться в процессы 1С (1cv8.exe, rphost.exe) для перехвата трафика или проверки подписей. Это часто вызывает конфликты адресации памяти.
Что делать:
Причина Б: Полнотекстовый поиск
Библиотека entext.dll отвечает за полнотекстовый поиск. Если индекс поиска поврежден, платформа может падать при попытке обращения к нему (например, при поиске в динамическом списке).
Что делать:
Для повышения стабильности работы "старых" конфигураций 1С на новых версиях SQL Server, проанализируем следующие настройки:
Режим совместимости (Compatibility Level):
Попробуйте изменить уровень совместимости базы данных. Иногда переключение на уровень SQL Server 2012 (110) или 2014 (120) возвращает "старое" поведение оптимизатора запросов, которое лучше подходит для кода УТ 10.3.
Параметры соединения:
Так как сервер 1С и SQL Server находятся на одной физической машине, убедитесь, что используется протокол Shared Memory. В настройках подключения к базе данных на сервере 1С в поле "Сервер баз данных" можно указать lpc:ИмяСервера (или lpc:., lpc:localhost), чтобы принудительно использовать этот протокол. Это исключает сетевой стек и повышает надежность передачи данных.
Если описанные выше меры не помогли полностью устранить ошибки TDEADLOCK, необходимо включить Технологический журнал (ТЖ) 1С. Настройте сбор событий TLOCK и TDEADLOCK.
В логах ТЖ вы увидите:
Это позволит точечно определить участки кода или запросы, требующие оптимизации (например, добавления индексов или изменения порядка захвата ресурсов).
Для решения проблемы нестабильной работы УТ 10.3 на современном оборудовании выполните следующие шаги в указанном порядке:
FULLSCAN).entext.dll.