ТА в 1С: что это и зачем нужен технологический анализ

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

Технологический анализ собирает текст запроса, план его выполнения на стороне СУБД и статистику: длительность, количество обращений, объём прочитанных данных. На основе этих сведений администратор или разработчик видит, какой именно запрос создаёт нагрузку и почему — например, из-за отсутствия индекса, соединения с виртуальной таблицей без отборов или сканирования всей таблицы.

Инструмент доступен в сервисе 1С:ЦУП (центр управления производительностью) и в виде обработок технологического анализа для типовых конфигураций. Ниже разберём, что именно показывает ТА, в каких случаях его запускать и как интерпретировать результаты без риска для рабочей базы.

Что конкретно показывает технологический анализ

Результат работы ТА — это набор записей по каждому «тяжёлому» запросу. Для каждого запроса фиксируется его текст на языке запросов 1С и в терминах СУБД, план выполнения (какие индексы используются, есть ли полное сканирование таблиц), количество выполнений за период наблюдения и суммарная длительность.

Дополнительно анализ показывает контекст: из какого объекта метаданных или процедуры был вызван запрос. Это важно, потому что один и тот же запрос может быть безобидным при разовом вызове и критичным, если выполняется тысячи раз в цикле.

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

В каких ситуациях стоит запускать ТА

Основной повод — жалобы на производительность: медленное проведение документов, долгое открытие форм, отчёты, которые строятся неприемлемо долго. ТА позволяет заменить догадки фактами и увидеть, какой именно запрос отвечает за большую часть времени ожидания.

Второй сценарий — профилактика перед ростом нагрузки: увеличение числа пользователей, переход на новую версию конфигурации, перенос базы на другой сервер. Анализ до и после изменений показывает, какие запросы стали работать хуже.

Как запустить технологический анализ

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

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

1. 1
   Воспроизведите проблему: зафиксируйте, какая операция тормозит и в какое время
2. 2
   Запустите сбор технологического анализа на период типичной нагрузки
3. 3
   Дождитесь накопления статистики по запросам
4. 4
   Отсортируйте запросы по суммарной длительности и числу выполнений
5. 5
   Откройте план выполнения для самых тяжёлых запросов
6. 6
   Проверьте наличие индексов и отборы по виртуальным таблицам
7. 7
   Внесите исправление на копии базы и сравните результат повторным замером

Как читать результаты и находить причину

Начинайте с сортировки по суммарному времени: запрос, который выполняется 0,1 секунды, но вызывается 10 000 раз, важнее запроса длительностью 2 секунды, вызванного один раз. Затем откройте план выполнения и ищите типовые признаки проблем: полное сканирование таблицы (Table Scan), соединения без условий, обращения к виртуальным таблицам без отборов по измерениям и периоду.

Частые причины, которые выявляет ТА: отсутствие индекса по полям отбора, использование функций над полями в условиях (это отключает индекс), запросы в цикле вместо одного пакетного запроса, избыточное получение всех полей вместо нужных. Каждая из этих проблем имеет понятное исправление на уровне кода или структуры метаданных.

Типичные ошибки при работе с ТА

Ограничения и альтернативы

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

Если база файловая, возможности оптимизации ограничены: многие рекомендации ТА (тонкая настройка планов, статистика СУБД) применимы только в клиент-серверном варианте. В таком случае основной путь — исправление запросов в коде и сокращение объёма обрабатываемых данных.

FAQ

Контрольные точки

Как проверить результат оптимизации

Время выполнения операции

Норма

Заметно сократилось при повторном замере

Тревожный признак

Не изменилось или выросло

План запроса

Норма

Используется поиск по индексу

Тревожный признак

Осталось полное сканирование таблицы

Число обращений к СУБД

Норма

Уменьшилось после устранения запросов в цикле

Тревожный признак

Прежнее количество вызовов

Скорость записи данных

Норма

Не ухудшилась после добавления индекса

Тревожный признак

Проведение документов замедлилось

ТА в 1С — это то же самое, что технологический журнал?

Нет. Технологический журнал — это низкоуровневый лог событий платформы (вызовы, ошибки, длительные операции). Технологический анализ — надстройка, которая разбирает именно запросы к СУБД: их текст, план выполнения и статистику. Данные для ТА часто собираются с использованием технологического журнала, но это разные инструменты.

Нужны ли специальные права для запуска технологического анализа?

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

Можно ли запускать ТА на рабочей базе без остановки пользователей?

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

Что делать, если ТА показал проблемный запрос в типовой конфигурации?

Сначала проверьте, установлены ли актуальные обновления — часть проблем производительности вендор исправляет в релизах. Если запрос изменять нельзя без снятия конфигурации с поддержки, рассмотрите варианты: настройка индексов на уровне СУБД, оптимизация отборов в настройках отчёта или обращение к разработчику конфигурации с результатами анализа.

Поможет ли ТА, если 1С тормозит из-за блокировок?

Частично: ТА покажет запросы, которые участвуют в конфликтах, но причины взаимоблокировок и избыточных управляемых блокировок анализируются по технологическому журналу и событиям TLOCK и TDEADLOCK. Обычно оба инструмента применяют вместе.