Почему уменьшился размер файловой базы 1С после выгрузки и загрузки DT и безопасно ли это?

При обслуживании файловых баз данных «1С:Предприятие 8» (особенно часто это происходит с конфигурацией «Бухгалтерия предприятия 3.0») администраторы и программисты регулярно сталкиваются с удивительным явлением. База данных, которая на диске занимала 20 Гб, после стандартной процедуры выгрузки в файл резервной копии .dt и последующей загрузки в новую чистую базу внезапно уменьшается до 5 Гб. При этом стандартное «Тестирование и исправление» (ТиИ) со сжатием таблиц до этого не давало практически никакого эффекта.

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

Физическое устройство файла базы данных 1CD: почему раздувается файловая база?

Чтобы понять, куда делись 15 Гб объема, нам необходимо заглянуть под капот файловой СУБД 1С. Файл 1Cv8.1CD имеет сложную внутреннюю структуру, состоящую из страниц фиксированного размера (обычно это 4 Кб или 8 Кб). Работа с этими страницами подчиняется строгим законам оптимизации быстродействия, из-за чего и возникает избыточный объем.

Рассмотрим подробнее три главные причины «раздувания» базы:

1. Механизм распределения свободных страниц (Page Allocator). Когда в программе удаляются какие-либо объекты (например, документы, помеченные на удаление, или временные файлы), физически из файла 1Cv8.1CD они не стираются. Операционная система не умеет динамически уменьшать размер занятого файла на диске без полной перезаписи. Платформа 1С просто помечает освободившиеся страницы данных как «свободные» для последующей записи. При создании новых документов СУБД старается использовать эти пустые страницы, но из-за сильной фрагментации это удается далеко не всегда. В результате файл постоянно растет вширь, накапливая пустые пространства.
2. Особенности транзакционной модели 1С. Транзакции в файловой базе работают по принципу теневого копирования. Практически все измененные или создаваемые объекты сохраняются как минимум в двух копиях в процессе записи. Фиксация транзакции — это перезапись секторов указателей на фактическое размещение актуальных данных. После фиксации старые версии страниц переходят в категорию свободных, увеличивая «пустоту» внутри файла.
3. Накопление мусора при обновлениях метаданных. Конфигурация «Бухгалтерия предприятия 3.0» обновляется очень часто. При каждом обновлении в структуре базы накапливаются устаревшие описания метаданных, старые версии конфигураций поставщика и кэш-таблицы. Платформа резервирует под них место, которое после завершения обновления часто остается невостребованным.
4. Фрагментация индексов таблиц. Индексы — это специальные упорядоченные структуры, ускоряющие поиск данных. При постоянной перезаписи и добавлении документов деревья индексов сильно фрагментируются. Они начинают занимать на диске в 2–3 раза больше места, чем требуется для хранения дефрагментированных данных.

Что происходит во время выгрузки и загрузки файла DT?

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

Когда мы загружаем .dt обратно в пустую базу данных:

• Файл 1Cv8.1CD создается на диске абсолютно заново с нулевого размера.
• Все таблицы записываются последовательно друг за другом, страница к странице. Это полностью исключает наличие пустого зарезервированного пространства.
• Индексы перестраиваются с нуля. Они создаются идеально дефрагментированными и компактными, что дает колоссальную экономию места.
• Удаляются все зависшие временные таблицы платформы и остатки старых конфигураций, которые не имели логических связей с текущими данными.

Что именно «потерялось» при переносе через DT?

Естественный страх любого бухгалтера или администратора при уменьшении базы в 4 раза — «мы потеряли документы!». Спешим вас успокоить: учетные данные (документы, справочники, проводки, регистры сведений и накопления) при этой процедуре пострадать не могут. Однако кое-что действительно удаляется навсегда.

Давайте разберем, что именно исчезло из новой базы:

1. Журнал регистрации пользователей. Это самый важный элемент, который не переносится через файл .dt. Журнал регистрации физически хранится вне файла базы данных 1Cv8.1CD — он находится в каталоге 1Cv8Log в папке с базой данных. Если вы загрузили .dt в абсолютно новый пустой каталог, ваш журнал регистрации в новой информационной базе окажется абсолютно чистым. Вы потеряете историю того, кто и когда изменял документы в прошлом.
2. Индексы полнотекстового поиска (ППП). Файлы индекса ППП также создаются платформой отдельно. При загрузке в новую базу они будут перегенерированы заново при первом же обращении к поиску или запуске регламентного задания, что временно создаст нагрузку на систему.
3. Поврежденные или «осиротевшие» записи. Если в исходной базе были серьезные логические или физические разрушения (например, битые ссылки или записи в таблицах регистрах без регистратора), механизм выгрузки в .dt мог их просто проигнорировать. С одной стороны, база очистилась от мусора. С другой стороны — эти скрытые ошибки теперь зафиксированы физически.

Вылезут ли косяки в новой базе при работе?

Работать в оптимизированной базе размером 5 Гб можно и нужно. В большинстве случаев пользователи заметят лишь существенный прирост производительности из-за отсутствия фрагментации индексов. Тем не менее, перед запуском пользователей в новую базу необходимо выполнить ряд проверок, чтобы исключить редкие, но неприятные проблемы.

Проанализируем потенциальные риски и способы их минимизации:

Риск 1. Появление «битых» ссылок. Если при выгрузке платформе пришлось отсечь поврежденные объекты, в новой базе вы можете столкнуться с элементами, содержащими надпись <Объект не найден>. Обязательно запустите встроенную проверку логической целостности.

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

Риск 3. База быстро вернется к прежнему объему. Помните, что сжатие — это временный эффект. Как только начнется активный документооборот, платформа снова зарезервирует свободные страницы под новые транзакции. База быстро подрастет на несколько гигабайт, и это абсолютно нормальный рабочий процесс файловой СУБД.

Пошаговый алгоритм безопасного сжатия файловой базы

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

Шаг 1. Подготовка и создание резервной копии

Перед началом любых работ обязательно завершите все сеансы пользователей. Сделайте физическую копию всей папки с базой данных (скопируйте файл 1Cv8.1CD средствами Windows). Это ваша главная страховка.

Шаг 2. Выгрузка в DT и создание новой информационной базы

Запустите Конфигуратор исходной базы, перейдите в меню Администрирование — Выгрузить информационную базу... и сохраните файл .dt. После этого создайте на диске новую пустую папку (например, C:\1C_Bases\BP_Optimized), добавьте ее в список баз и запустите ее Конфигуратор. Выберите пункт Администрирование — Загрузить информационную базу... и укажите сохраненный ранее файл .dt.

Шаг 3. Восстановление Журнала регистрации

Чтобы не потерять историю действий пользователей, перенесите журнал регистрации вручную. Для этого перейдите в каталог старой базы, найдите там папку 1Cv8Log и скопируйте ее целиком в каталог новой оптимизированной базы с заменой файлов. Структура каталога должна выглядеть следующим образом:

C:\1C_Bases\BP_Optimized\
    ├── 1Cv8.1CD (новый сжатый файл базы данных)
    └── 1Cv8Log\ (скопированная папка с историей действий)
        ├── 1Cv8.lgf
        └── 1Cv8.lgp

Шаг 4. Контрольная проверка и сверка данных

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

1. Установите флаги: Реиндексация таблиц информационного сопоставления, Проверка логической целостности, Проверка ссылочной целостности.
2. В разделе "При наличии ссылок на несуществующие объекты" выберите вариант Создавать объекты или Очищать ссылки (рекомендуется предварительно запустить в режиме "Только тестирование", чтобы оценить масштаб проблемы).
3. Нажмите кнопку Выполнить.

После успешного прохождения теста запустите обе базы (старую и новую) в пользовательском режиме предприятия и сформируйте Оборотно-сальдовую ведомость (ОСВ) за весь период работы до копейки. Сверьте показатели активов, обязательств и капитала. Если данные полностью идентичны — процедура оптимизации прошла успешно и новую базу можно отдавать в работу пользователям.

Альтернативный способ сжатия базы без использования выгрузки в DT

Выгрузка и загрузка через .dt таит в себе скрытую опасность: если база данных имеет физические повреждения таблиц на низком уровне, выгрузка может пройти успешно, а вот загрузить такой файл обратно платформа откажется из-за критической ошибки формата потока. В таком случае вы рискуете остаться с нерабочим архивом.

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

1. Запустите утилиту физического восстановления файлов баз данных 1С — chdbfl.exe (она находится в каталоге установленной платформы, например C:\Program Files\1cv8\8.3.XX.XXX\bin\). Укажите ваш файл 1Cv8.1CD, поставьте галочку "Исправлять обнаруженные ошибки" и выполните проверку. Это устранит физические повреждения страниц.
2. Запустите Конфигуратор вашей рабочей базы, откройте Администрирование — Тестирование и исправление..., выберите пункт Реструктуризация таблиц информационной базы и запустите процесс. Реструктуризация выполняет физическое перестроение таблиц во временные файлы с последующей заменой старых структур, что гарантированно сжимает файл базы данных до минимально возможного технологического размера, удаляя свободные страницы и дефрагментируя индексы прямо «на месте».