Как узнать размер таблиц в базе 1С на SQL

База 1С на SQL Server или PostgreSQL со временем разрастается: накапливаются документы, движения по регистрам, версии объектов и записи журнала регистрации. Когда свободное место на диске заканчивается или запросы начинают тормозить, первый шаг — выяснить, какие именно таблицы занимают больше всего места. Без этой информации любая чистка превращается в работу вслепую.

Таблицы в базе 1С имеют технические имена вида _Document123, _AccumRg456, _InfoRg789, поэтому по названию не всегда понятно, какому объекту конфигурации они соответствуют. Ниже разобраны готовые запросы для MS SQL Server и PostgreSQL, способы сопоставить технические имена с объектами метаданных и безопасные методы уменьшения самых тяжёлых таблиц.

Зачем контролировать размер таблиц и что именно занимает место

Рост базы почти никогда не бывает равномерным. Обычно 80–90% объёма занимают несколько таблиц: регистры накопления и сведений с большим количеством движений, журнал регистрации, таблицы версирования объектов, вложения и хранилища двоичных данных. Пока вы не знаете конкретных «тяжёлых» таблиц, невозможно решить, что чистить: сворачивать итоги, удалять старые версии объектов или сокращать журнал регистрации.

Важно понимать, что размер таблицы складывается из самих данных, индексов и, в случае MS SQL, нераспределённого (зарезервированного, но не использованного) пространства. Таблица с большим объёмом индексов может требовать не удаления данных, а перестроения индексов. Поэтому полезно смотреть размер данных и индексов раздельно — оба запроса ниже это позволяют.

Как узнать размер таблиц в MS SQL Server

Для базы 1С на MS SQL Server самый практичный способ — запрос к системным представлениям sys.tables и sys.dm_db_partition_stats. Он выполняется в SQL Server Management Studio (SSMS) в контексте нужной базы и не требует никаких изменений в самой базе — это операция только чтения.

SELECT t.name AS TableName, SUM(p.rows) AS RowCount, CAST(SUM(a.total_pages) <em> 8 / 1024.0 AS DECIMAL(18,2)) AS TotalMB, CAST(SUM(a.used_pages) </em> 8 / 1024.0 AS DECIMAL(18,2)) AS UsedMB FROM sys.tables t JOIN sys.indexes i ON t.object_id = i.object_id JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id JOIN sys.allocation_units a ON p.partition_id = a.container_id GROUP BY t.name ORDER BY TotalMB DESC

Запрос возвращает имя таблицы, количество строк, общий зарезервированный объём и фактически использованный объём в мегабайтах, отсортированные от большего к меньшему. Строки вида _Document234, _AccumRg567 — это и есть таблицы объектов 1С. Если разница между TotalMB и UsedMB велика, таблица содержит много неиспользуемого зарезервированного пространства — его можно вернуть перестроением индексов или shrink при осознанной необходимости.

Альтернатива: отчёт SSMS без запросов

Если запросы писать не хочется, в SSMS есть встроенный отчёт: правый клик по базе → Reports → Standard Reports → Disk Usage by Table. Отчёт показывает те же таблицы с количеством строк и занятым местом. Ограничение — отчёт медленно строится на очень больших базах и не всегда удобен для копирования результатов.

Как узнать размер таблиц в PostgreSQL

Для базы 1С на PostgreSQL используются функции pg_total_relation_size() (таблица вместе с индексами и TOAST-данными) и pg_relation_size() (только данные). Запрос выполняется в pgAdmin или psql.

SELECT relname AS TableName, pg_size_pretty(pg_total_relation_size(c.oid)) AS TotalSize, pg_size_pretty(pg_relation_size(c.oid)) AS DataSize, c.reltuples::bigint AS ApproxRows FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind = 'r' AND n.nspname = 'public' ORDER BY pg_total_relation_size(c.oid) DESC LIMIT 30

Запрос выводит 30 самых больших таблиц схемы public с размером в читаемом виде и приблизительным числом строк. Учтите, что reltuples — оценочное значение из статистики, а не точный счёт; для точного числа строк по конкретной таблице нужен SELECT count(*), который на больших таблицах выполняется долго.

Как сопоставить технические имена таблиц с объектами 1С

Получив список тяжёлых таблиц, нужно понять, каким объектам конфигурации они соответствуют. Для этого в 1С есть встроенная функция ПолучитьСтруктуруХраненияБазыДанных(). Она возвращает таблицу значений с колонками «ИмяТаблицыХранения» (техническое имя вроде _AccumRg4231) и «ИмяТаблицы» (имя объекта метаданных, например «РегистрНакопления.Продажи»).

Практический способ — открыть в конфигураторе или в режиме предприятия (при наличии внешней обработки) консоль кода и выгрузить структуру хранения, затем найти в ней нужное техническое имя. Многие готовые обработки «Структура хранения базы данных» делают это наглядно: показывают дерево объектов метаданных с их физическими таблицами и индексами.

1. 1
   Выполните запрос размера таблиц в SSMS или pgAdmin и сохраните топ-20 таблиц
2. 2
   В 1С получите структуру хранения через ПолучитьСтруктуруХраненияБазыДанных() или обработку
3. 3
   Сопоставьте технические имена с объектами метаданных
4. 4
   Определите природу каждой тяжёлой таблицы: данные, итоги, журнал, версии, вложения
5. 5
   Выберите безопасный способ уменьшения: штатная свёртка, настройка журнала регистрации, очистка версий
6. 6
   После чистки повторите запрос и оцените фактическое изменение размера

Что делать с самыми большими таблицами

Действия зависят от типа таблицы. Для регистров накопления с многолетней историей штатный вариант — свёртка базы или установка периода расчёта итогов, чтобы итоги не хранились за ненужные периоды. Для журнала регистрации — сокращение через «Настройка журнала регистрации» с выгрузкой старого периода в файл, либо уменьшение уровня протоколирования. Для версий объектов — ограничение срока хранения версий в настройках версионирования.

Категорически не рекомендуется удалять строки из таблиц 1С напрямую SQL-запросами DELETE. Структура базы 1С включает служебные таблицы, итоги и ссылки между объектами; ручное удаление нарушает целостность и может привести к ошибкам при обновлении конфигурации или к потере данных. Все чистки выполняйте штатными средствами платформы и конфигурации.

Типичные ошибки при анализе размера базы

Отдельная частая ситуация: администратор видит огромный файл .ldf и начинает искать большие таблицы, хотя проблема в журнале транзакций при модели полного восстановления без регулярных бэкапов лога. Проверьте размер файлов базы на диске до анализа таблиц — это сэкономит время.

Контроль результата и регулярный мониторинг

После чистки повторите запрос размера таблиц и сравните с исходными значениями. Помните про особенности СУБД: в MS SQL освободившееся внутри файла место видно по UsedMB, а возврат места операционной системе требует shrink; в PostgreSQL размер таблицы уменьшится только после VACUUM FULL или pg_repack. Для регулярного контроля полезно сохранять результаты запроса раз в месяц — так видна динамика роста и можно спрогнозировать, когда понадобится расширение диска или очередная чистка.

Частые вопросы