TGViewer
Антон Дорошкевич | маяк в мире 1С и СУБД Антон Дорошкевич | маяк в мире 1С и СУБД @explorer1c · 2.02K subscribers
Post #94 2.37K
Как собрать для анализа запроса все временные таблицы с их содержимым?

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

Насколько мне известно при работе с MS SQL так ничего и не поменялось.
А вот в PostgreSQL появилось расширение auto_dump.
«На пальцах» что делает расширение:
Следит за текстом запросов dump_on_query_string и когда находит нужный (например UPDATE _AccRg), то делает бэкап всех временных таблиц и их содержимым (можно и физических, но по моему мнению это достаточно опасно, ниже опишу почему), собирает предполагаемый и фактический планы запроса, сохраняет текст самого запроса, складывает это всё в каталог указанный в параметре output_directory
Так же можно настроить чтобы собирались запросы только длительнее чем auto_dump.timeout
Или запросы у которых по нашему мнению плохой план из-за большой разницы в предполагаемых и фактических значениях bad_plan_count_threshold и/или bad_plan_percent_threshold

Чем опасен параметр dump_persistent_tables, который позволяет сразу дампить физические таблицы?
Тем что физические таблицы могут быть огромного объёма и в итоге мы получим и тормоза и забитый диск.
Поэтому включать этот параметр нужно только полностью понимая что вы делаете.

Как потом работать с полученной информацией уже запросами к СУБД напрямую:
1. Создаём новую пустую базу из 1С. Это делается для того чтобы были созданы функции и типы данных, которые использует 1С.
2. Делаем dump физических таблиц, которые есть в запросе.
3. Восстанавливаем из дампа таблицы в базу созданную в п.1
4. Выполняем скрипт create_temporary.sql по созданию временных таблиц, который нам создал auto_dump
5. Выполняем скрипт insert_temporary.sql по наполнению временных таблиц, который нам создал auto_dump
6. Выполняем запрос query.sql, который нам создал auto_dump, на уровне СУБД и пытаемся его оптимизировать настройками СУБД, добавлением индексов (понимая как потом мы их сможем добавить на уровне 1С), улучшать план запроса манипулируя параметрами сбора статистики, менять сам запрос на уровне СУБД опять же понимая как мы потом это на 1С напишем и т.д.

В итоге мы получаем достаточно удобный инструмент, в котором есть вся необходимая для оптимизации запроса информация.
  • 👍 21
  • 🔥 8
  • ❤ 4
More from @explorer1c
  1. Sep 21, 2026Можно ли сделать поведение PostgreSQL в отношении потребления памяти процессами более жест…
  2. Sep 11, 2026Сегодня ровно год первому сообщению в канале! Огромное спасибо всем вам! Честно - было оче…
  3. Sep 9, 2026Теперь на багборде можно легко и быстро сравнить версии платформы по изменениям! Уверен чт…
  4. Sep 7, 2026Начнём...)
  5. Aug 26, 2026Небольшой анонс поездок и мероприятий с моим участием: 08-10/09 - Обучение по кластеру 1с…
  6. Aug 20, 2026Плановая дата обязательного перехода на Платформу 8.5 для конфигураций ERP/KA/УТ– не ранее…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →