Как остановить быстрый рост файловой базы 1С (1CD) и оптимизировать размер таблиц?

← На главную

Рано или поздно многие администраторы и разработчики систем на базе «1С:Предприятие» сталкиваются с проблемой лавинообразного роста файловой базы данных. Ситуация, когда при сравнительно небольшом объеме вводимых документов (например, около 1000 документов в месяц) файл базы данных 1Cv8.1CD увеличивается на сотни мегабайт ежемесячно, не является редкостью. При этом архивный файл выгрузки (.dt) может весить всего 100 Мб, в то время как сама файловая база раздувается до 3,5 Гб и более.

В этой статье мы подробно разберем, почему возникает такая колоссальная разница между размером базы и размером ее архива, какие архитектурные ошибки приводят к «распуханию» таблиц и какими инструментами можно локализовать и устранить эту проблему.

Выясняем причины: почему 1CD растет быстрее, чем выгрузка DT?

Для начала проанализируем физику процесса хранения данных. Файл выгрузки информационной базы (.dt) — это сжатый архив, содержащий только «чистые» данные (записи справочников, документов, движений регистров) в специальном XML-подобном формате. При формировании .dt-файла платформа полностью игнорирует индексы таблиц, так как они могут быть легко перестроены при последующей загрузке базы.

Файл же файловой базы данных 1Cv8.1CD содержит в себе:

Фактические данные таблиц.
Индексы таблиц, которые необходимы для быстрого поиска данных и могут занимать до 50-70% от общего объема базы при неоптимальном проектировании.
Таблицы итогов регистров накопления и бухгалтерии, хранящие рассчитанные остатки и обороты в разрезе периодов.
Пространство, зарезервированное СУБД под новые записи (так называемый «мусорный» или свободный объем, остающийся после удаления объектов до проведения сжатия таблиц).

Если разница между размером 1CD и dt составляет десятки раз (например, 3.5 Гб против 100 Мб), это явный маркер того, что база раздута за счет индексов, итогов или пустого зарезервированного пространства.

Физика процесса: как «незакрытые» остатки лавинообразно раздувают базу

Одной из наиболее частых архитектурных ошибок в самописных или доработанных конфигурациях является некорректная работа с регистрами накопления остатков. Рассмотрим подробнее, как устроено хранение остатков в платформе 1С.

Регистр накопления остатков физически состоит из двух ключевых таблиц базы данных:

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

Когда мы проводим документ расхода, платформа должна полностью закрыть в ноль соответствующий приход по всем измерениям регистра (например: Номенклатура, Склад, Характеристика). Если из-за программной ошибки или неверной логики проведения на остатках зависает копейка или микроскопическая дробная часть (например, пришло 10 шт, а списалось 9.99999 шт вследствие ошибок округления), эта запись остатка считается активной.

Каждый раз при наступлении нового месяца платформа копирует все ненулевые остатки из предыдущего периода в новый. Если в базе скопились тысячи таких «висящих» копеечных остатков, таблица итогов начинает лавинообразно увеличиваться при каждом переходе на новый месяц. Даже если новые документы в базу не вводятся, размер файла 1Cv8.1CD продолжит стабильно расти за счет ежемесячного дублирования незакрытых записей в таблице итогов. Это явление часто называют «пухнущими итогами».

Пошаговый анализ размера таблиц файловой базы

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

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


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

// Анализируем справочники
Для Каждого Справочник Из Метаданные.Справочники Цикл
    Размер = ПолучитьРазмерДанныхБазыДанных(Справочник);
    Если Размер > 0 Тогда
        НоваяСтрока = ТаблицаРезультатов.Добавить();
        НоваяСтрока.ИмяОбъекта = Справочник.ПолноеИмя();
        НоваяСтрока.РазмерБ = Размер;
        НоваяСтрока.РазмерМБ = Окр(Размер / (1024 * 1024), 2);
    КонецЕсли;
КонецЦикла;

// Анализируем регистры накопления
Для Каждого Регистр Из Метаданные.РегистрыНакопления Цикл
    Размер = ПолучитьРазмерДанныхБазыДанных(Регистр);
    Если Размер > 0 Тогда
        НоваяСтрока = ТаблицаРезультатов.Добавить();
        НоваяСтрока.ИмяОбъекта = Регистр.ПолноеИмя();
        НоваяСтрока.РазмерБ = Размер;
        НоваяСтрока.РазмерМБ = Окр(Размер / (1024 * 1024), 2);
    КонецЕсли;
КонецЦикла;

ТаблицаРезультатов.Сортировать("РазмерБ Убыв");
// Выводим результат в консоль или таблицу формы...

Функция ПолучитьРазмерДанныхБазыДанных() возвращает размер данных, занимаемый конкретным объектом метаданных. Метод ПолучитьСтруктуруХраненияБазыДанных() позволяет сопоставить имена объектов метаданных с их физическими именами таблиц в файле 1CD (например, определить, к какому регистру относится таблица _InfoReg1234 или _AccumRegTotals5678).

Для тех, кто использует более ранние версии платформы или предпочитает готовые интерактивные инструменты, рекомендуется использовать внешние утилиты диагностики, такие как «Базопузомер» (специальный анализатор физической структуры файла 1CD) или отчеты, построенные на чтении заголовков таблиц файловой базы.

Оптимизация индексов: убираем лишнее

Индексы создаются для ускорения поиска и выборки данных, но за это приходится платить дисковым пространством. В самописных конфигурациях часто допускают ошибку, устанавливая свойство «Индексировать» (или «Индексировать с доп. упорядочиванием») для всех измерений и реквизитов подряд.

Проанализируем следующие правила создания индексов:

Не индексируйте строковые поля неограниченной длины и длинные текстовые реквизиты. Индексы по таким полям занимают колоссальный объем памяти и работают крайне неэффективно.
Для регистров накопления платформа автоматически создает многокомпонентные индексы по измерениям. Дополнительное ручное индексирование каждого отдельного измерения часто избыточно и ведет лишь к необоснованному росту физического файла базы.
Проверьте свойства реквизитов справочников и документов. Если по какому-то реквизиту никогда не строится отбор в запросах и он не используется в качестве критерия отбора, снимите флаг индексации.

Преодоление лимитов файловой базы и работа с утилитой CNVDBFL.EXE

В процессе эксплуатации файловой базы важно помнить о технологических ограничениях формата 1CD. Исторически максимальный размер одной таблицы в файловой базе ограничивался 4 Гб (при стандартном размере страницы данных 4 Кб). При превышении этого лимита база аварийно завершает работу, а выгрузка или загрузка данных становится невозможной.

Начиная с версии платформы 8.3.8, фирма 1С добавила возможность создания баз с увеличенным размером страницы данных (8, 16, 32 и 64 Кб). При использовании размера страницы 64 Кб максимальный размер одной таблицы увеличивается до 16 Гб (в современных релизах платформы).

Для того чтобы преобразовать формат существующей базы и увеличить лимиты таблиц, выполним следующие шаги:

Обязательно создайте резервную копию файла 1Cv8.1CD путем его копирования в безопасное место.
Закройте все сеансы работы с базой данных, включая конфигуратор и фоновые задания.
Запустите командную строку Windows (cmd) и перейдите в каталог установленной платформы 1С (папка bin текущего релиза).
Выполните команду конвертации базы данных с помощью утилиты CNVDBFL.EXE, указав максимальный размер страницы 64 Кб (параметр -p 64k):

CNVDBFL.EXE -c -f 8.3.8 -p 64k "C:\PathToYourBase\1Cv8.1CD"

После выполнения этой операции база будет переведена на новый формат. Стоит учитывать, что сам файл 1CD после этого может незначительно увеличиться в размере, поскольку данные теперь будут выравниваться по границам более крупных страниц (64 Кб), однако это полностью нивелирует угрозу упереться в лимит 4 Гб для ключевых таблиц на долгое время.

Комплекс мер по наведению порядка в базе

Чтобы окончательно решить проблему быстрого роста и стабилизировать размер базы данных, выполним комплекс мероприятий:

Исправление архитектурной ошибки регистров: Необходимо скорректировать алгоритмы проведения документов так, чтобы остатки по регистрам накопления всегда закрывались в ноль. Если в базе уже накоплено множество «висящих» копеек, следует написать разовую обработку очистки движений или корректировки записей регистров, которая принудительно обнулит неактуальные остатки прошлых периодов.
Сжатие таблиц базы данных: При удалении объектов или очистке регистров физическое место в файле 1CD не высвобождается автоматически. Чтобы уменьшить размер файла, запустите Конфигуратор, перейдите в меню «Администрирование» — «Тестирование и исправление», установите флаг «Сжатие таблиц информационной базы» и запустите процесс.
Регулярная свертка базы данных: Если база эксплуатируется много лет, рассмотрите возможность проведения свертки. Процесс свертки удаляет документы прошлых периодов, заменяя их документами ввода остатков на определенную дату, что позволяет существенно уменьшить количество записей в таблицах движений и итогов.

Систематическое проведение аудита структуры хранения данных, оптимизация индексов и контроль за закрытием регистров позволят вам держать размер файловой базы 1С под полным контролем, обеспечивая высокое быстродействие системы и надежность хранения информации.