Работа с платформой 1С:Предприятие часто требует от администратора или разработчика глубокого понимания того, что происходит «под капотом» системы. Когда производительность падает или возникает сложная ошибка, первым делом специалисты обращают внимание на то, какие именно инструкции отправляются в СУБД. Понимание механизма трансляции запросов языка 1С в нативный SQL является ключевым навыком для оптимизации работы информационной базы.
Существует несколько способов мониторинга и анализа выполняемых команд, каждый из которых имеет свои особенности и сферу применения. От встроенных средств отладки до внешних утилит администрирования — выбор инструмента зависит от того, на каком этапе разработки или сопровождения вы находитесь. В этой статье мы детально разберем основные методы и инструменты, позволяющие увидеть реальный код, уходящий в сервер баз данных.
Использование консоли запросов для анализа кода
Наиболее доступным и часто используемым инструментом для разработчиков является встроенная консоль запросов. Она позволяет не только писать и тестировать новые запросы, но и анализировать уже существующие. Если у вас есть текст запроса на языке 1С, вы можете вставить его в консоль и сразу увидеть результат выполнения, а также получить представление о том, как он будет обработан.
Однако стоит понимать, что консоль запросов показывает именно текст запроса на языке платформы, а не готовый SQL-код. Для перехода к визуальному представлению структуры данных используется кнопка «Показать таблицу значений». Это удобно для быстрой проверки логики выборки без необходимости запускать весь конфигурационный код.
Для более глубокого анализа внутри консоли можно использовать режим отладки. Он позволяет пошагово проходить по операторам запроса и видеть промежуточные результаты. Это особенно полезно при работе со сложными соединениями таблиц или временными наборами данных.
Используйте комбинацию клавиш Ctrl+Enter в консоли запросов для быстрого выполнения текущего текста без необходимости нажимать кнопку «Выполнить» на панели инструментов.
Важно отметить, что консоль не показывает параметры, передаваемые в запрос, в явном виде до момента выполнения. Это может затруднить диагностику проблем, связанных с конкретными значениями переменных в момент/runtime.
Просмотр SQL через журнал регистрации 1С
Для получения информации о реально выполненных командах в работающей базе наиболее надежным штатным средством является журнал регистрации. Этот механизм фиксирует événements системы, включая взаимодействие с СУБД. Чтобы увидеть SQL-запросы, необходимо предварительно настроить фильтры журнала.
В режиме предприятия или конфигуратора перейдите в меню Администрирование → Журнал регистрации. По умолчанию журнал может быть пуст или содержать только общие сообщения. Вам необходимо добавить событие SQL в список отслеживаемых событий. Без этой настройки система не будет сохранять текст запросов в лог.
- 📁 Откройте форму настроек журнала регистрации через главное меню.
- ⚙️ Перейдите на вкладку «Настройки» и найдите группу событий, связанных с СУБД.
- ✅ Установите флажок напротив события
Выполнение запроса к СУБД. - 💾 Сохраните настройки и убедитесь, что уровень детализации установлен на «Детальный».
После включения логирования все проходящие через сервер 1С команды будут записываться. В колонке «Представление данных» или в дополнительном поле (в зависимости от версии платформы) отобразится текст SQL-запроса. Обратите внимание, что включение подробного логирования SQL может существенно увеличить размер файла журнала и снизить общую производительность системы в часы пик.
⚠️ Внимание: Никогда не оставляйте детальное логирование SQL-запросов включенным на продуктивной базе в режиме 24/7. Это может привести к быстрому заполнению дискового пространства и замедлению работы сервера 1С из-за накладных расходов на запись в лог.
Анализ с помощью технологического журнала (ТЖ)
Когда стандартного журнала регистрации недостаточно для диагностики сложных проблем производительности, на сцену выходит технологический журнал (ТЖ). Это мощный инструмент низкоуровневого логирования, который требует редактирования конфигурационных файлов на сервере. ТЖ позволяет фиксировать не только текст запроса, но и время его выполнения, блокировки и другие метрики.
Для настройки ТЖ необходимо отредактировать файл ragent.cfg или создать файл настроек в каталоге параметров сервера. В секции логирования нужно активировать событие DBMSSQL (для MS SQL) или соответствующее событие для PostgreSQL. Синтаксис настройки может различаться в зависимости от версии платформы 1С:Предприятие 8.3.
Пример структуры записи в технологическом журнале включает время начала, длительность (в микросекундах) и сам текст команды. Анализ таких логов требует использования специальных утилит или скриптов, так как объем данных может быть огромным. Часто администраторы пишут парсеры на Python или PowerShell для выгрузки «тяжелых» запросов в отдельный отчет.
<log>
<logitem>
<event>DBMSSQL</event>
<level>3</level>
</logitem>
</log>
Использование технологического журнала оправдано при поиске причин периодических «тормозов» системы, которые не воспроизводятся в момент ручной проверки. Он дает полную картину нагрузки на СУБД со стороны приложения 1С.
Мониторинг через средства СУБД (SQL Profiler)
Самый достоверный способ увидеть, что именно исполняется в базе данных — использовать-native инструменты самой СУБД. Для Microsoft SQL Server таким инструментом является SQL Server Profiler или его современная замена Extended Events. Для PostgreSQL можно использовать логирование в файле postgresql.log с параметром log_min_duration_statement.
Подключение профайлера позволяет видеть запросы в том виде, в котором их получает сервер баз данных, включая все сгенерированные параметры. Это критически важно для понимания работы параметризированных запросов, которые часто скрывают реальные значения за плейсхолдерами вроде @P1, @P2.
| Инструмент | Сложность настройки | Влияние на производительность | Уровень детализации |
|---|---|---|---|
| Журнал регистрации 1С | Низкая | Среднее | Текст запроса |
| Технологический журнал | Высокая | Высокое | Текст + время + блокировки |
| SQL Profiler | Средняя | Низкое/Среднее | Полный план выполнения |
| Консоль запросов | Низкая | Отсутствует | Только язык 1С |
При использовании SQL Profiler рекомендуется применять фильтры по имени базы данных или имени приложения (обычно это 1Cv8 или 1Cv8C), чтобы отсечь системный шум и другие приложения, работающие с тем же сервером SQL.
Почему запросы в профайлере выглядят страшно?
Текст SQL, сгенерированный платформой 1С, часто содержит множество вложенных подзапросов, временных таблиц и специфических функций (например, _AddOrder или _LikeParam). Это нормальное поведение транслятора, пытающегося оптимизировать выполнение запроса с учетом индексов и статистики.
Использование расширений и внешних обработок
Для упрощения процесса анализа разработчики сообщества 1С создали множество полезных инструментов. Одним из популярных решений является обработка «Анализ производительности» или различные расширения для конфигуратора. Эти инструменты позволяют в реальном времени выводить список выполняемых запросов в удобном интерфейсе.
Некоторые обработки умеют автоматически определять место в коде конфигурации, откуда был вызван тот или иной запрос. Это значительно ускоряет поиск проблемного участка кода в больших типовых конфигурациях, таких как ERP или УТ 11. Вам не придется вручную сопоставлять текст SQL с модулем объекта.
- 🚀 Обработки могут работать в фоновом режиме без остановки работы пользователей.
- 📊 Возможность экспорта списка медленных запросов в Excel для последующего анализа.
- 🔍 Подсветка синтаксиса и форматирование SQL-кода для лучшей читаемости.
Важно скачивать такие инструменты только из проверенных источников, например, с порта Infostart, чтобы избежать внесения вредоносного кода в вашу информационную базу. Перед запуском на продуктивной среде обязательно протестируйте обработку в копии базы.
Оптимизация найденных запросов
После того как вы успешно перехватили и проанализировали SQL-запрос, следующим шагом становится его оптимизация. Часто проблема кроется не в самом тексте запроса, а в отсутствии необходимых индексов в базе данных или некорректной статистике.
Если запрос содержит полнотекстовый поиск или операции LIKE с подстановочными знаками в начале строки, это может приводить к полному сканированию таблицы (Table Scan). В таких случаях рекомендуется пересмотреть логику выборки или использовать полнотекстовые индексы, поддерживаемые СУБД.
⚠️ Внимание: Не пытайтесь оптимизировать запросы путем прямой правки сгенерированного SQL-кода. Изменения должны вноситься на уровне языка запросов 1С или схемы базы данных, иначе они будут потеряны при следующем обновлении конфигурации или перезапуске сервера.
Также стоит обратить внимание на использование временных таблиц. В некоторых случаях разбивка одного огромного запроса на несколько этапов с сохранением промежуточных результатов во временные таблицы дает выигрыш в производительности за счет уменьшения сложности плана выполнения.
☑️ Чек-лист оптимизации запроса
Частые ошибки при анализе SQL
Новички часто допускают ошибку, пытаясь читать сгенерированный SQL-код как ручной. Структура запросов 1С специфична: платформа использует множество служебных таблиц и представлений. Пытаться переписать такой запрос вручную «напрямую» в SQL-менеджере без понимания внутренней логики 1С — путь к ошибкам и нарушению целостности данных.
Еще одна распространенная проблема — игнорирование параметров. Запрос может выглядеть быстрым в профайлере при одних значениях параметров и крайне медленным при других. Это явление называется «параметрическая чувствительность» плана выполнения. Всегда проверяйте запрос с разными входными данными.
Не забывайте, что интерфейс 1С и серверная часть могут работать в разных процессах. Запрос, видимый в клиентском логе, может отличаться от того, что ушло в сеть из-за оптимизаций, выполняемых сервером 1С перед отправкой в СУБД.
Наиболее полную картину взаимодействия с базой данных дает комбинация Технологического журнала 1С и SQL Profiler, однако для повседневных задач достаточно грамотно настроенного журнала регистрации.
Можно ли увидеть SQL-запрос прямо в коде конфигуратора?
Нет, в тексте модуля конфигуратора вы видите только запрос на языке 1С. Трансляция в SQL происходит динамически во время выполнения программы сервером 1С. Чтобы увидеть результат трансляции, необходимо использовать инструменты трассировки (Журнал регистрации, ТЖ или профайлер СУБД).
Почему в журнале регистрации запросы записываются не полностью?
Это может происходить из-за ограничений на длину записываемого поля в настройках журнала или из-за того, что само событие не было включено в фильтрацию. Также некоторые служебные запросы платформы могут не логироваться в стандартном режиме.
Влияет ли просмотр SQL-запросов на скорость работы базы?
Сам факт просмотра через внешние средства (Profiler) влияет минимально. Однако включение подробного логирования внутри 1С (Журнал регистрации, ТЖ) создает дополнительную нагрузку на дисковую подсистему и процессор, что может замедлить работу пользователей.
Как понять, какой именно объект 1С вызвал медленный запрос?
В технологическом журнале или расширенных событиях SQL можно настроить вывод контекста выполнения, включая имя пользователя и иногда метки потока. Для точной привязки к объекту конфигурации удобнее использовать специализированные обработки анализа производительности.