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

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

Способ узнать размер таблиц зависит от того, как развёрнута база: в файловом варианте (один файл 1Cv8.1CD) или в клиент-серверном, на MS SQL Server, PostgreSQL или другой СУБД. В клиент-серверном варианте данные доступны штатными средствами СУБД, а в файловом придётся использовать специальные утилиты.

Важно понимать, что таблица в СУБД и объект метаданных 1С — не одно и то же. Один документ может храниться в нескольких таблицах (шапка, табличные части, движения), а имена таблиц в базе данных выглядят как _Document123 или _AccumRg456. Поэтому задача обычно состоит из двух шагов: найти самые большие таблицы и сопоставить их имена с объектами конфигурации.

Как 1С хранит данные: что нужно понимать перед анализом

Платформа 1С:Предприятие не хранит объекты «как есть». Каждый объект конфигурации преобразуется в одну или несколько таблиц СУБД с техническими именами. Справочник «Номенклатура» может называться _Reference31, его табличная часть — _Reference31_VT1523, а регистр накопления «Продажи» — _AccumRg245. Числовой суффикс формируется при создании объекта и не несёт смысловой нагрузки.

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

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

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

Самый быстрый способ — отчёт в SQL Server Management Studio. Кликните правой кнопкой по базе данных, выберите «Отчёты» → «Стандартные отчёты» → «Использование диска таблицей» (Disk Usage by Table). Отчёт покажет все таблицы с количеством строк, зарезервированным и фактически занятым местом, включая индексы.

Для регулярного анализа удобнее запрос. Классический вариант через системные представления:

SELECT
t.NAME AS TableName,
SUM(p.rows) AS RowCounts,
SUM(a.total_pages) * 8 / 1024 AS TotalSpaceMB
FROM sys.tables t
INNER JOIN sys.indexes i ON t.object_id = i.object_id
INNER JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id
GROUP BY t.NAME
ORDER BY TotalSpaceMB DESC

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

Для точечной проверки одной таблицы используйте команду EXEC sp_spaceused '_AccumRg245' — она покажет количество строк, зарезервированное место, объём данных и индексов отдельно. Если индексы занимают больше места, чем сами данные, это повод проверить состав индексирования, но менять индексы таблиц 1С вручную нельзя — платформа управляет ими сама.

EXEC sp_spaceused '_AccumRg245';

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

В PostgreSQL для оценки размера используются функции pg_total_relation_size (таблица со всеми индексами и TOAST-данными), pg_relation_size (только данные) и pg_indexes_size (только индексы). Запрос для топ-20 таблиц по суммарному размеру:

SELECT
relname AS table_name,
pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size,
pg_total_relation_size(c.oid) AS size_bytes
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY size_bytes DESC
LIMIT 20;

Функция pg_size_pretty выводит размер в читаемом виде (MB, GB), что удобно для быстрого просмотра. Для автоматической обработки лучше брать значение в байтах и сортировать по нему.

В PostgreSQL есть специфика, важная для 1С: при интенсивном обновлении и удалении записей таблицы «раздуваются» из-за мёртвых версий строк. Если pg_total_relation_size показывает аномально большой объём при небольшом числе актуальных записей, проверьте, работает ли autovacuum, и при необходимости выполните VACUUM FULL для конкретной таблицы — но только вне рабочего времени, так как операция блокирует таблицу.

Как оценить размер данных в файловой базе 1Cv8.1CD

Файловая база — это один файл с контейнерной структурой, и штатных средств посмотреть размер отдельных таблиц внутри него в платформе нет. Самый простой показатель — общий размер файла 1Cv8.1CD в каталоге базы, но он не отвечает на вопрос, какие таблицы самые большие.

Для детального анализа используют сторонние утилиты чтения формата 1CD (например, инструменты семейства Tool_1CD и аналогичные разработки, доступные в открытом доступе). Они открывают файл базы и показывают список внутренних таблиц с количеством записей и занимаемым объёмом. Работать с такими утилитами нужно только с копией файла — открытие живой базы на чтение обычно безопасно, но любые эксперименты с модификацией файла 1CD приводят к потере данных.

Косвенный способ без сторонних инструментов — выгрузить базу в dt и посмотреть размер выгрузки, а затем в конфигураторе проанализировать объёмы данных через запросы: посчитать количество записей в крупных регистрах, документах, журнале регистрации. Это не даст точных мегабайтов по таблицам, но покажет, где сосредоточены данные.

1. 1
   Сделайте резервную копию файла 1Cv8.1CD
2. 2
   Откройте копию файла утилитой чтения формата 1CD
3. 3
   Отсортируйте таблицы по размеру и зафиксируйте топ-10
4. 4
   Сопоставьте имена таблиц с метаданными через ПолучитьСтруктуруХраненияБазыДанных()
5. 5
   Примите решение о чистке: свёртка, удаление устаревших данных, отключение версионирования

Как сопоставить таблицы СУБД с объектами конфигурации

Получив список тяжёлых таблиц вида _AccumRg или _InfoRg, нужно понять, что это за объекты. Для этого в 1С есть штатный механизм: выполните в консоли кода или через внешнюю обработку функцию ПолучитьСтруктуруХраненияБазыДанных(). Она возвращает таблицу значений с колонками: имя таблицы хранения, имя таблицы в терминах метаданных, назначение, а также состав полей и индексов.

Удобнее использовать готовые внешние обработки «Структура хранения базы данных», которые выводят это соответствие в наглядном виде с поиском. Введите имя таблицы из отчёта СУБД — и увидите, что _AccumRg245, например, это регистр накопления «ТоварыНаСкладах».

Обратите внимание на суффиксы в именах таблиц. _AccumRg — основная таблица регистра накопления, _AccumRgTotals — таблица итогов, _AccumRgOpt — дополнительные таблицы оптимизации. Если итоговые таблицы непропорционально велики, проверьте период рассчитанных итогов: хранение итогов за много лет назад редко оправдано, и его можно сократить через «Управление итогами» в конфигураторе.

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

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

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

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

Частые ошибки при анализе и сокращении размера базы

Первая ошибка — попытка уменьшить базу шринком файлов СУБД сразу после удаления данных. Shrink в MS SQL фрагментирует индексы и деградирует производительность; его выполняют только после массовой чистки и с последующей реорганизацией индексов. В повседневном режиме свободное место внутри файлов — это нормально, СУБД переиспользует его.

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

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

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