Как проверить запросы 1С: SQL, блокировки и производительность

Работа с высоконагруженной базой данных в экосистеме 1С:Предприятие часто сопряжена с необходимостью глубокого анализа производительности. Когда пользователи жалуются на «тормоза» или зависание отчетов, администратору или разработчику необходимо понять, что именно происходит «под капотом». Проверка запросов 1С — это не просто просмотр текста кода, а комплексный процесс, включающий анализ времени выполнения, планов запросов и состояния блокировок.

Система 1С использует собственный язык запросов, который транслируется платформой в нативный SQL для конкретной СУБД (MSSQL, PostgreSQL или Oracle). Ошибки на любом этапе этой цепочки могут привести к критическому снижению скорости работы всего предприятия. Поэтому умение оперативно выявить узкое место является ключевым навыком для сопровождения системы.

В этой статье мы рассмотрим инструменты, которые позволяют заглянуть внутрь процессов выполнения кода. Вы научитесь отличать проблемы клиентской части от проблем сервера, а также поймете, как читать технологический журнал для поиска «тяжелых» операций.

Анализ запросов через Консоль запросов

Самый доступный и часто используемый инструмент для первичной проверки — это встроенная консоль запросов. Она позволяет выполнить любой запрос вручную, увидеть структуру результатов и, что самое важное, оценить время выполнения. Для запуска утилиты обычно используется внешняя обработка или режим предприятия с правами администратора.

При работе с консолью важно обращать внимание не только на итоговый результат, но и на время компиляции и выполнения. Медленный запрос может быть следствием неверно построенного условия или отсутствия необходимых индексов в базе данных. Если вы видите, что простой выбор данных занимает секунды, это первый сигнал к действию.

Используйте кнопку «Выполнить» многократно для проверки стабильности времени отклика. Иногда первый запуск медленный из-за кэширования планов, а последующие — быстрые. Однако, если время скачет или постоянно высокое, требуется детальный разбор текста запроса и связей между таблицами.

⚠️ Внимание: Выполнение тяжелых запросов в консоль в рабочее время может создать дополнительную нагрузку на сервер и усугубить ситуацию с блокировками. Проводите тесты на копии базы или в технологическое окно.

💡

Используйте функцию «Показать план выполнения» в консоли запросов, если ваша версия платформы и тип СУБД поддерживают эту опцию. Это поможет увидеть, какие индексы использует сервер.

Для сложных случаев можно экспортировать текст запроса в текстовый редактор для форматирования и анализа. Часто ошибка кроется в лишних соединениях или неправильном порядке таблиц в операторе ИЗ.

Использование Технологического журнала (ТЖ)

Технологический журнал — это мощнейший инструмент диагностики, который фиксирует события на уровне процессов сервера 1С. Он позволяет отследить жизненный цикл каждого запроса: от момента получения клиентом до возврата результата. Настройка ТЖ требует редактирования файла logcfg.xml в каталоге сервера.

Чтобы поймать проблемный запрос, необходимо включить логирование событий, связанных с выполнением SQL. Обычно администраторы активируют события DBMSSQL (для MS SQL) или соответствующие события для PostgreSQL. В логах будет видно время начала, время окончания и текст самого запроса, преобразованного платформой.

🔍 SQL — событие фиксации текста SQL-запроса, отправляемого в СУБД.
⏱️ DBCall — событие, показывающее длительность вызова метода работы с данными.
🔒 Lock — событие, фиксирующее установку и снятие блокировок на объекты данных.

Анализ логов ТЖ требует внимательности, так как объем записей может быть огромным. Рекомендуется использовать фильтры по длительности выполнения (например, искать запросы, выполняющиеся дольше 1000 мс). Это позволит отсечь «шум» и сфокусироваться на реальных проблемах производительности.

⚠️ Внимание: Включение подробного логирования всех запросов на продуктивном сервере может привести к переполнению дискового пространства и падению производительности самого сервера 1С из-за записи логов.

Как настроить фильтр по длительности в logcfg.xml?

В секции event необходимо добавить свойство duration, указав минимальное время в миллисекундах. Например: будет логировать только операции дольше 1 секунды.

После сбора данных логи удобно анализировать с помощью сторонних утилит, таких как 1C:LogAnalyzer или специализированных скриптов. Они агрегируют данные и выводят топ самых ресурсоемких запросов.

Выявление и анализ блокировок

Одной из самых частых причин зависания интерфейса пользователя являются блокировки. В 1С они возникают, когда одна транзакция изменяет данные, а другая пытается прочитать или изменить те же самые записи. Платформа 1С управляет блокировками на уровне менеджера блокировок, но в конечном итоге они реализуются средствами СУБД.

Проверить наличие активных блокировок можно через стандартные средства платформы или запросы к системным таблицам СУБД. В режиме предприятия администратор может увидеть список сеансов и удерживаемые ими блокировки. Важно различать управляемые и неуправляемые блокировки.

Тип блокировки	Уровень влияния	Частая причина
Монопольная	Высокий	Проведение документа с длительной транзакцией
Разделяемая	Средний	Чтение данных в цикле без оптимизации
Блокировка регистра	Критический	Некорректная работа с итогами регистров накопления

Для поиска виновника блокировки часто используют запрос к таблице блокировок в самой СУБД. В MS SQL Server это системное представление sys.dm_tran_locks. Сопоставив ID процесса в базе данных с ID сеанса в 1С, можно точно определить, какой пользователь или фоновое задание держит базу.

☑️ Диагностика блокировки

Определить зависший сеанс в списке пользователейНайти удерживаемые блокировки в ТЖПроверить активные транзакции в СУБДАнализировать код зависшего сеанса

Выполнено: 0 / 4

Устранение блокировок часто требует изменения логики проведения документов или разнесения тяжелых операций на ночное время. Иногда помогает оптимизация индексов, что снижает время удержания блокировок СУБД.

Профайлер и мониторинг SQL Server

Если 1С работает под управлением MS SQL Server, то незаменимым инструментом становится SQL Server Profiler или его современный аналог — Extended Events. Эти инструменты позволяют видеть запросы на уровне движка базы данных, минуя прослойку платформы 1С.

С помощью профайлера можно отфильтровать запросы по имени базы данных 1С и увидеть реальный текст SQL, который генерирует платформа. Это особенно полезно, когда встроенные средства 1С не дают полной картины. Вы можете увидеть параметры, передаваемые в запрос, и план выполнения, выбранный оптимизатором SQL Server.

Обращайте внимание на события RPC:Completed и SQL:BatchCompleted. Они показывают завершенные пакеты команд. Фильтрация по длительности (Duration) поможет быстро найти «тяжеловесов». Также полезно отслеживать события блокировок (Lock:Deadlock), чтобы выявлять взаимоблокировки (deadlocks), которые приводят к аварийному завершению транзакций.

⚠️ Внимание: Интерфейсы и возможности инструментов мониторинга СУБД могут меняться с выходом новых версий SQL Server. Всегда сверяйтесь с официальной документацией Microsoft для вашей версии СУБД.

💡

Использование SQL Profiler дает наиболее точную картину нагрузки на базу данных, но требует высоких привилегий доступа к серверу СУБД и навыков чтения планов выполнения.

Анализ планов выполнения в профайлере позволяет увидеть, делает ли сервер сканирование всей таблицы (Table Scan) вместо поиска по индексу (Index Seek). Это явный признак проблем с индексами или статистикой.

Оптимизация и перестроение индексов

Частой причиной медленных запросов является фрагментация индексов или устаревшая статистика распределения данных. Даже идеально написанный запрос в 1С будет работать медленно, если СУБД выбирает неоптимальный план из-за неактуальных данных о распределении ключей.

Регулярное обслуживание базы данных должно включать перестроение (Rebuild) или реорганизацию (Reorganize) индексов. Для баз 1С это критически важная процедура, так как характер записи данных (постоянное добавление документов) быстро приводит к фрагментации. Использовать можно стандартные планы обслуживания SQL Server или скрипты Ola Hallengren.

Также стоит проверить наличие отсутствующих индексов. СУБД может подсказывать, какие индексы ускорили бы выполнение конкретных запросов. Однако добавлять их нужно с осторожностью, учитывая, что каждый новый индекс замедляет вставку и обновление данных.

🚀 Fragmentation — степень раздробленности страниц индекса, влияющая на скорость чтения.
📊 Statistics — гистограммы распределения данных, используемые оптимизатором запросов.
🛠️ Maintenance Plan — автоматизированный план обслуживания базы данных.

Проверку индексов можно выполнить с помощью системных динамических представлений, таких как sys.dm_db_index_physical_stats. Значение фрагментации выше 30% обычно требует перестроения индекса.

Частые ошибки при написании запросов

Помимо проблем на стороне инфраструктуры, причинами низкой производительности часто становятся ошибки в самом коде запросов 1С. Разработчики могут неосознанно создавать конструкции, которые вынуждают платформу выполнять неэффективные операции.

Одной из распространенных ошибок является использование функций в условиях соединения или отбора, что запрещает использование индексов. Например, использование ГОД(Дата) в условии ГДЕ превращает быстрый поиск по индексу даты в полное сканирование таблицы.

НЕПРАВИЛЬНО:
ГДЕ ГОД(Документ.Дата) = 2023

ПРАВИЛЬНО:
ГДЕ Документ.Дата BETWEEN '2023.01.01' И '2023.12.31 23:59:59'

Также стоит избегать вложенных запросов там, где можно использовать временные таблицы. Временные таблицы позволяют разбить сложную логику на этапы и материализовать промежуточные результаты, что часто ускоряет работу.

Почему запрос с функцией в условии работает медленно?

Когда функция применяется к полю в условии, СУБД не может использовать индекс для этого поля, так как значение индекса не совпадает с результатом функции. Серверу приходится перебирать каждую запись, вычислять функцию и сравнивать результат, что приводит к полному сканированию таблицы (Table Scan).

Как найти запрос, который выполняется прямо сейчас?

В 1С можно использовать обработку «Монитор производительности» или запросы к системным таблицам сеансов. В SQL Server используйте представление sys.dm_exec_requests, отфильтровав его по ID базы данных 1С и отсортировав по времени ожидания или выполнения.

Что такое deadlock и как его избежать?

Взаимоблокировка (deadlock) возникает, когда два процесса ждут ресурсы, удерживаемые друг другом. Чтобы избежать этого, старайтесь обращаться к таблицам в одном и том же порядке во всех транзакциях и минимизируйте время удержания блокировок, выполняя длительные вычисления вне транзакций.

Можно ли ускорить запрос без изменения кода?

Да, часто ускорение достигается за счет обновления статистики, перестроения индексов, увеличения оперативной памяти сервера SQL или настройки параметров максимизации параллелизма (MAXDOP). Также помогает разделение файлов данных и логов на разные физические диски.

Диагностика и проверка запросов в 1С: Предприятие