Как узнать размер таблиц базы данных в 1С:Предприятие 8? Разбор утилит Базопузомер, Статистика ИБ и встроенных методов

← На главную

Рано или поздно любой разработчик или системный администратор 1С сталкивается с проблемой стремительного роста объема информационной базы. Когда дисковое пространство начинает таять на глазах, возникает логичный вопрос: какие именно объекты метаданных (справочники, документы, регистры накопления или сведений) занимают больше всего места? Напрямую заглянуть в СУБД (будь то MS SQL Server или PostgreSQL) не всегда просто, ведь физические таблицы там называются абстрактно, например, _InfoReg123 или _Document456. Для такого обследования также подходит просмотр объектов и размеров базы: обработка покажет крупные объекты и таблицы, а точные размеры с индексами потребуют отдельного SQL-запроса. Совместимость с 8.3 не подтверждена.

В этой статье мы подробно рассмотрим, как решить задачу сопоставления физических таблиц СУБД с объектами метаданных 1С и анализа их объема. Мы разберем три отличных инструмента: легендарную утилиту «Базопузомер v8», мощный отчет «Статистика ИБ 8.1 SQL» от Дмитрия Глуха, а также встроенный программный метод платформы 1С:Предприятие ПолучитьРазмерДанныхБазыДанных(). Мы проанализируем их возможности, плюсы, минусы и особенности применения на практике.

Решение 1: Универсальный отчет «Базопузомер v8»

Корни этого инструмента уходят еще во времена платформы 1С:Предприятие 7.7, где утилита bazopuzo.ert была незаменимым помощником для быстрого получения статистики по размеру таблиц DBF или SQL. Для современных версий 1С 8.2 и 8.3 существует обновленная версия отчета «Базопузомер v8».

Рассмотрим ключевые особенности и возможности этой обработки:

Кроссплатформенность и интерфейс: Отчет адаптирован для работы в любых конфигурациях на управляемых и обычных формах, включая современный интерфейс «Такси». Это делает его универсальным солдатом, который можно запустить практически на любой базе данных.
Режим сопоставления таблиц СУБД: Главная ценность отчета заключается в возможности связать непонятные физические имена таблиц в SQL (например, _AccumRegTotals125) с понятными именами объектов метаданных в конфигураторе (например, РегистрНакопления.Продажи.Итоги).
Расчет физического объема: В клиент-серверном варианте работы утилита способна рассчитывать реальный физический объем таблиц, делая соответствующие запросы к СУБД, что позволяет быстро локализовать «виновников» раздувания базы данных. Если в ходе анализа выяснится, что значительную часть места занимают сведения по неиспользуемой компании, для безопасного очищения базы можно выполнить выборочное удаление организации из 1С.

«Базопузомер v8» идеально подходит для быстрого экспресс-анализа структуры базы данных без необходимости написания сложных SQL-запросов или глубокого погружения в администрирование СУБД. В качестве альтернативы можно использовать обработку для анализа дискового пространства MS SQL и PostgreSQL по метаданным.

Решение 2: Отчет «Статистика ИБ 8.1 SQL» от Дмитрия Глуха (IronDemon)

Если вам требуется более глубокий, детальный и профессиональный анализ производительности и структуры хранения данных, то лучшим выбором станет отчет «Статистика ИБ», созданный известным разработчиком Дмитрием Глухом (в сообществе более известным под ником IronDemon).

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

Анализ размера индексов: Большинство простых утилит (включая встроенные методы 1С) умеют показывать только размер «полезных» данных в таблице. Однако в реальных базах данных индексы могут занимать до 50-70% от общего объема таблицы! Отчет Дмитрия Глуха собирает данные напрямую из системных таблиц MS SQL Server и выводит детальную информацию: отдельно размер данных, отдельно размер индексов и общее количество записей.
Временная статистика и плотность учета: Отчет умеет анализировать плотность ведения учета. Он показывает распределение записей по периодам (месяцам, годам), выводит среднее и максимальное количество движений документов в день. Это помогает понять, в какие периоды база росла быстрее всего.
Анализ табличных частей: Утилита рассчитывает среднее количество строк в табличных частях документов. Это бесценно для архитекторов систем, так как позволяет выявить «перегруженные» документы, которые могут вызывать проблемы с блокировками и производительностью при проведении.

Важное ограничение: Инструмент работает путем прямого подключения к MS SQL Server. Для его работы требуются права администратора СУБД (или права на чтение системных таблиц конфигурации). В современных корпоративных облаках или при использовании СУБД PostgreSQL запуск этого отчета может потребовать серьезных усилий по настройке прав доступа и адаптации SQL-запросов.

Решение 3: Системный метод ПолучитьРазмерДанныхБазыДанных()

Начиная с версии платформы 8.3.15.1489, фирма «1С» предоставила разработчикам встроенный инструмент для решения этой задачи без использования сторонних компонент и прямых запросов к СУБД — метод глобального контекста ПолучитьРазмерДанныхБазыДанных().

Давайте проанализируем, как работает этот метод, а также рассмотрим его сильные и слабые стороны.

Как это устроено внутри: При вызове метода платформа выполняет к СУБД специальный запрос, который подсчитывает длину хранящихся данных. Например, для MS SQL Server платформа суммирует результаты функции DATALENGTH() по всем полям и строкам целевой таблицы.

Преимущества метода:

Полная кроссплатформенность: Метод одинаково успешно работает на MS SQL, PostgreSQL, IBM DB2 и Oracle. Разработчику больше не нужно писать условные ветвления в коде под разные СУБД.
Работа в файловом режиме: Это революционная возможность. Раньше узнать размер конкретной таблицы в файловой базе (внутри файла 1Cv8.1CD) без использования сторонних низкоуровневых утилит (таких как Tool1CD) было невозможно. Теперь платформа делает это штатно.
Безопасность: Не требуются учетные данные администратора СУБД. Вызов происходит из контекста выполнения 1С под правами администратора информационной базы.
Поддержка расширений: Метод корректно учитывает и возвращает размер данных для таблиц, добавленных через расширения конфигурации.

Критические недостатки и ограничения:

Не учитываются накладные расходы СУБД: Метод возвращает исключительно размер полезных данных. Он не учитывает индексы, служебные таблицы СУБД, таблицы итогов, историю данных и прочие накладные расходы. Из-за этого реальный физический размер файла базы данных на диске может отличаться от данных метода в несколько раз.
Крайне низкая производительность: Поскольку СУБД вынуждена рассчитывать размер каждого поля во всех строках, происходит полное сканирование таблиц (Table Scan). На базах объемом от 100 Гб и выше вызов метода может "повесить" систему на десятки минут, создав огромную нагрузку на дисковую подсистему и очистив кэш СУБД. Крайне не рекомендуется запускать этот метод на рабочих базах в период активной работы пользователей!
Проблемы с разделителями: В разделенных базах (например, в сервисе 1cFresh) метод может завершиться ошибкой, если не передать параметры разделения данных.

Практический пример использования ПолучитьРазмерДанныхБазыДанных()

Проанализируем пример кода, с помощью которого мы можем обойти метаданные конфигурации, получить размер таблиц для каждого объекта и вывести результаты для анализа. Этот код можно оформить в виде внешней обработки.


// Создадим таблицу значений для сбора статистики
ТаблицаРезультатов = Новый ТаблицаЗначений;
ТаблицаРезультатов.Колонки.Добавить("ИмяОбъекта", Новый ОписаниеТипов("Строка"));
ТаблицаРезультатов.Колонки.Добавить("РазмерБайт", Новый ОписаниеТипов("Число"));
ТаблицаРезультатов.Колонки.Добавить("РазмерМб", Новый ОписаниеТипов("Число"));

// Нам нужно обойти основные тяжелые объекты: Справочники и Документы
// Рассмотрим сбор данных по справочникам
Для Каждого Метаобъект Из Метаданные.Справочники Цикл
    
    ПолноеИмя = Метаобъект.ПолноеИмя();
    
    Попытка
        // Вызываем системный метод получения размера
        Размер = ПолучитьРазмерДанныхБазыДанных(ПолноеИмя);
        
        НоваяСтрока = ТаблицаРезультатов.Добавить();
        НоваяСтрока.ИмяОбъекта = ПолноеИмя;
        НоваяСтрока.РазмерБайт = Размер;
        НоваяСтрока.РазмерМб = Окр(Размер / (1024 * 1024), 2);
    Исключение
        // Метод может вызвать исключение, если к объекту нет доступа или таблица пуста
        ЗаписьЖурналаРегистрации("АнализРазмераБазы", 
            УровеньЖурналаРегистрации.Предупреждение, 
            Метаобъект, , 
            "Не удалось получить размер для: " + ПолноеИмя + ". Ошибка: " + ОписаниеОшибки());
    КонецПопытки;
    
КонецЦикла;

// Сортируем таблицу по убыванию размера, чтобы сразу видеть самые тяжелые объекты
ТаблицаРезультатов.Сортировать("РазмерБайт Убыв");

// Выведем результаты в окно сообщений для анализа
Для Каждого СтрокаРезультата Из ТаблицаРезультатов Цикл
    Если СтрокаРезультата.РазмерБайт > 0 Тогда
        Сообщить(СтрШаблон("Объект: %1 | Размер: %2 Мб (%3 байт)", 
            СтрокаРезультата.ИмяОбъекта, 
            СтрокаРезультата.РазмерМб, 
            СтрокаРезультата.РазмерБайт));
    КонецЕсли;
КонецЦикла;

Резюме и рекомендации

Выбор конкретного инструмента зависит от ваших текущих задач и условий окружения:

Если вам нужно быстро и без лишних сложностей сопоставить физические таблицы с объектами метаданных и при этом база работает на управляемых формах — используйте универсальный отчет «Базопузомер v8».
Если вы расследуете серьезные проблемы с производительностью, администрируете MS SQL Server и вам жизненно важно видеть размеры индексов и распределение данных по периодам — воспользуйтесь отчетом «Статистика ИБ 8.1 SQL» от Дмитрия Глуха.
Если перед вами стоит задача программного мониторинга размеров таблиц (например, для автоматической отправки уведомлений в Telegram при резком росте справочника файлов) или вы работаете в файловой базе данных — пишите собственный алгоритм на основе встроенного метода ПолучитьРазмерДанныхБазыДанных(), не забывая запускать его только в периоды минимальной активности пользователей (например, ночью).