При работе с высоконагруженными базами данных 1С, такими как Управление торговлей 11.4, администраторы часто сталкиваются с ситуацией, когда проведение документов начинает «зависать» на несколько минут. Эти задержки носят хаотичный характер и не всегда зависят от объема документа. Проанализируем типичную ситуацию, когда при анализе плана выполнения запроса в MS SQL Server 2016 система выдает сообщение об отсутствующем индексе (Missing Index). Выясним, действительно ли нужно создавать предложенные индексы и какие регламентные операции помогут вернуть быстродействие системы.
Разберем ситуацию, когда SQL-оптимизатор подсказывает создать индекс по полю Active (Активность). Рассмотрим, стоит ли слепо следовать этому совету. В архитектуре 1С поле Active присутствует практически во всех регистрах, но оно имеет крайне низкую селективность — оно принимает только значения «Истина» или «Ложь». Создание отдельного индекса по такому полю зачастую оказывается не только бесполезным, но и вредным. Проанализируем почему: при каждом проведении документа (записи в регистр) SQL Server будет вынужден обновлять этот индекс, что только увеличит время транзакции.
Если система указывает на Missing Index в плане запроса, это чаще всего симптом, а не причина. Это сигнализирует о том, что оптимизатор не смог эффективно использовать существующие индексы. Выясним причину: это происходит либо из-за неактуальной статистики, либо из-за особенностей работы механизма Cardinality Estimator в SQL Server 2016.
Первым делом рассмотрим необходимость регулярного обслуживания базы данных. Если «зависания» происходят хаотично, велика вероятность, что SQL Server строит неоптимальные планы запросов. Разберем по шагам, что необходимо выполнить:
Посмотрим на пример команды для обновления статистики с полным сканированием, что наиболее эффективно для 1С:
-- Обновление статистики для всей базы данных
EXEC sp_updatestats;
-- Или для конкретной таблицы (замените ИмяТаблицы на реальное имя из SQL)
UPDATE STATISTICS [ИмяТаблицы] WITH FULLSCAN;
Проанализируем специфические настройки MS SQL 2016, которые напрямую влияют на «зависания» в 1С. Версия 2016 года использует новый алгоритм оценки количества строк (Cardinality Estimator), который часто конфликтует с логикой построения запросов платформы 1С.
Рассмотрим применение флага трассировки 9481 или изменение уровня совместимости базы данных. Если мы переключим Compatibility Level в значение 110 (соответствует SQL 2012), SQL Server начнет использовать старый, более предсказуемый для 1С оптимизатор. Это часто решает проблему мгновенно без изменения кода конфигурации.
Также важно проверить параметр MAXDOP (Maximum Degree of Parallelism). В контексте 1С рекомендуется устанавливать MAXDOP = 1 для небольших серверов или значение, не превышающее количество ядер в одном NUMA-узле (обычно 2 или 4) для мощных систем. Это предотвратит ситуацию, когда один тяжелый запрос на проведение документа захватывает все ресурсы процессора, вызывая микро-стопы у других пользователей.
Выясним причину длительных «зависаний» по несколько минут. Скорее всего, это не просто медленная работа диска, а эскалация блокировок (Lock Escalation). Когда документ делает много движений (более 5000 строк блокировок), SQL Server может решить заблокировать всю таблицу регистра целиком. В этот момент все остальные пользователи, пытающиеся провести документы, будут ждать завершения первой транзакции.
Проанализируем состояние параметра LOCK_ESCALATION. Для высоконагруженных таблиц регистров в 1С иногда имеет смысл перевести этот параметр в DISABLE, чтобы разрешить серверу удерживать множество мелких блокировок вместо одной глобальной на всю таблицу.
Посмотрим на ситуацию, которую называют Parameter Sniffing. SQL Server кэширует план выполнения запроса, ориентируясь на параметры первого запущенного документа. Если первым был проведен очень маленький документ, план будет оптимизирован под него. Когда следом пойдет огромный документ, этот план окажется фатально медленным.
Для борьбы с этим в SQL Server 2016 существует инструмент Query Store (Хранилище запросов). Рассмотрим его использование:
Query Store в свойствах базы данных.Не забудем про системную базу tempdb. Платформа 1С активно использует временные таблицы при проведении документов. Убедимся, что tempdb разделена на несколько файлов одинакового размера (по количеству ядер процессора, но обычно не более 8). Это снизит конкуренцию за ресурсы при создании временных объектов.
Также проанализируем параметр Fill Factor (коэффициент заполнения страниц). Для регистров накопления, в которые постоянно идет запись, установим Fill Factor на уровне 80–90%. Это создаст свободное место на страницах данных и предотвратит их частое разбиение (Page Splits), что значительно ускорит процесс записи при проведении документов.
Таким образом, мы выяснили, что сообщение об «отсутствующем индексе» — это лишь повод для глубокой проверки настроек сервера и выполнения регламентных процедур. Комплексный подход к обслуживанию и тонкая настройка SQL Server позволят устранить хаотичные зависания в 1С:УТ 11.4.