Переход с редакции «Бухгалтерия предприятия» (БП) 2.0 на 3.0 — это не просто рядовое обновление конфигурации, а фундаментальная смена поколения ИТ-системы. Программа переходит на принципиально новую архитектуру управляемого приложения, начинает активно использовать механизмы Библиотеки Стандартных Подсистем (БСП) и новые возможности платформы 1С:Предприятие 8.3. Часто пользователи сталкиваются с пугающим эффектом: физический размер файла базы данных (1Cv8.1CD) на диске после обновления вырастает в 3–5 раз (например, с 650 МБ до 3.3 ГБ).
В этой статье мы подробно разберем, почему происходит такой лавинообразный рост объема данных, детально изучим внутренние процессы СУБД 1С при реструктуризации и рассмотрим пошаговые методы оптимизации, которые помогут безопасно вернуть базу к адекватному физическому размеру.
Глубинные причины роста объема базы данных при переходе на БП 3.0
Для понимания природы роста базы данных нам необходимо заглянуть «под капот» платформы 1С. Выделяют несколько основных факторов, влияющих на размер базы после апгрейда:
Масштаб самой конфигурации БП 3.0. Новая редакция содержит в разы больше объектов метаданных (справочников, документов, регистров, общих модулей, макетов), чем устаревшая БП 2.0. Механизмы управляемых форм, интеграция с государственными информационными системами, интеграция с банками и сервисами значительно увеличили «вес» метаданных. Сама пустая конфигурация БП 3.0 в структуре СУБД занимает около 700–800 МБ, в то время как конфигурация БП 2.0 укладывалась в рамки 200–300 МБ.
Снятие режима совместимости с версией 8.2. При обновлении на БП 3.0 платформа перестраивает физическую структуру таблиц СУБД под стандарты версии 8.3. Изменяются типы данных, индексы, оптимизируются поля под новые требования работы СУБД. Процесс реструктуризации требует создания временных таблиц, что приводит к фрагментации файлов на диске.
Работа механизмов отложенного обновления БСП. После первого запуска обновленной конфигурации в режиме «1С:Предприятие» в фоновом режиме запускаются обработчики обновления. Происходит масштабный перенос информации из старых структур данных в новые. Например, полностью перестраивается хранение контактной информации (адресов, телефонов) с переходом на форматы ФИАС/ГАР, трансформируется учет банковских счетов, переносятся данные по зарплате и кадрам. На время этого процесса данные фактически дублируются: они одновременно присутствуют и в старых регистрах (для совместимости), и в новых структурах БСП.
Разрастание индекса полнотекстового поиска (ППД). В процессе перезаписи миллионов строк данных при миграции платформа активно регистрирует изменения для индексации поиска. В каталоге базы данных файлы полнотекстового поиска (особенно служебный файл tableChanges.dat в папке 1Cv8FTxt) могут раздуваться до огромных размеров из-за некорректного высвобождения памяти платформой во время массовых транзакций.
Накопление системного мусора в Журнале регистрации. В процессе обновления выполняются тысячи регламентных и фоновых заданий, миллионы транзакций записи. Все эти события логируются платформой в Журнал регистрации. Если журнал настроен в стандартном режиме (формат .lgd или старый .elf), его размер может вырасти на гигабайты за время проведения обновления.
Использование автоматических патчей (исправлений). БП 3.0 по умолчанию настроена на автоматическую загрузку исправлений (патчей) от разработчиков 1С. Каждое такое исправление представляет собой небольшое расширение конфигурации, которое физически записывается внутрь базы данных, постепенно увеличивая её объем.
Особенности работы файловой СУБД 1С (.1CD) при реструктуризации
Для файловых баз данных критически важно понимать логику распределения дискового пространства внутренним движком 1С. Файл базы данных 1Cv8.1CD состоит из страниц фиксированного размера. При удалении данных или при переносе информации из старых таблиц в новые в ходе реструктуризации страницы, занимаемые старыми данными, помечаются СУБД как «свободные» для последующей записи.
Важно: Платформа 1С никогда автоматически не отдает освободившееся дисковое пространство операционной системе обратно. Физический размер файла 1Cv8.1CD на диске не уменьшится сам по себе, даже если вы удалите из базы 90% документов. Для реального сжатия файла требуется запуск специализированных процедур дефрагментации и оптимизации таблиц.
В случае клиент-серверных баз (например, на MS SQL Server, PostgreSQL) аналогичное поведение демонстрируют файлы баз данных и логи транзакций (.ldf в MS SQL). При массовых транзакциях обновления файл лога транзакций разрастается до гигантских размеров и требует принудительного сжатия (Shrink).
Пошаговая инструкция по оптимизации и уменьшению базы данных
Выяснив причины роста базы, разберем по шагам, как правильно и безопасно уменьшить её объем.
Шаг 1. Ожидание завершения всех процедур отложенного обновления
Пытаться сжимать и оптимизировать базу данных сразу после первого успешного входа в БП 3.0 — грубая ошибка. Сначала необходимо завершить все фоновые процессы переноса данных. Проанализируем состояние обновления по следующему алгоритму:
Перейдем в раздел Администрирование, далее выберем пункт Обслуживание.
В открывшемся окне развернем группу Обновление программы и перейдем по ссылке Результаты обновления и дополнительные процедуры.
Убедимся, что все отложенные обработчики данных выполнены на 100%. Если в списке есть активные фоновые задания, дождемся их полного завершения (это может занять несколько часов в зависимости от объема исходных данных).
Шаг 2. Очистка и перестроение индекса полнотекстового поиска
После завершения обновления индекс полнотекстового поиска часто содержит устаревшие ссылки и избыточные данные. Выполним его очистку:
Перейдем в раздел Администрирование — Общие настройки.
Развернем подраздел Поиск данных.
Нажмем на ссылку Настроить рядом с пунктом «Полнотекстовый поиск».
В открывшейся форме нажмем кнопку Очистить индекс. Это действие физически удалит файлы индекса из папки базы данных.
Для восстановления возможности быстрого поиска документов нажмем кнопку Обновить индекс. Будет создан новый, оптимизированный и актуальный поисковый индекс без накопленного при обновлении мусора.
Шаг 3. Запуск утилиты Тестирование и исправление (ТИИ) со сжатием таблиц
Основным инструментом физического сжатия базы данных является штатный механизм тестирования. Выполним следующие действия:
Создадим резервную копию базы данных! Это обязательное условие перед любыми техническими операциями. Для файловой базы скопируем файл 1Cv8.1CD в отдельный каталог.
Запустим информационную базу в режиме Конфигуратор.
В главном меню выберем пункт Администрирование — Тестирование и исправление...
В открывшемся окне настроек установим флажки напротив следующих проверок:
Реиндексация таблиц информационной базы (перестроит и оптимизирует индексы таблиц СУБД);
Сжатие таблиц информационной базы (физически освободит неиспользуемое пространство на диске, удалив пустые страницы в файле базы);
Реструктуризация таблиц информационной базы (пересоздаст таблицы базы данных на физическом уровне, исключив накопленные ошибки совместимости).
В поле «При наличии ссылок на несуществующие объекты» выберем значение Очищать объекты.
Нажмем кнопку Выполнить и дождемся окончания процесса. Для базы размером в несколько гигабайт это может занять длительное время. По завершении утилита выдаст отчет, а размер файла на диске существенно уменьшится (как правило, в 1.5–2.5 раза).
Шаг 4. Использование утилиты chdbfl.exe (для файловых баз)
Если после ТИИ размер базы по-прежнему кажется избыточным, или в процессе ТИИ возникли ошибки, воспользуемся специализированной внешней утилитой проверки физической целостности файла БД:
Полностью закроем все сеансы работы с базой данных (включая Конфигуратор).
Перейдем в каталог установки платформы 1С. Обычно он находится по пути вида: C:\Program Files\1cv8\[Номер_Версии_Платформы]\bin\.
Найдем и запустим файл chdbfl.exe.
В поле «Имя файла информационной базы» укажем путь к нашему файлу 1Cv8.1CD.
Установим флажок Исправлять обнаруженные ошибки.
Нажмем кнопку Выполнить. Утилита проверит структуру файла на физическом уровне, исправит поврежденные заголовки страниц базы и оптимизирует внутреннее размещение данных.
Шаг 5. Оптимизация клиент-серверных баз на MS SQL Server
Если база данных развернута в клиент-серверном варианте, стандартных инструментов 1С будет недостаточно, так как СУБД резервирует пространство под файлы данных (.mdf) и файлы логов транзакций (.ldf). Проанализируем алгоритм сжатия средствами СУБД:
Откроем среду Microsoft SQL Server Management Studio (SSMS) и подключимся к нашему серверу баз данных.
В дереве объектов выберем нашу базу данных, кликнем по ней правой кнопкой мыши и перейдем в меню Задачи (Tasks) — Сжать (Shrink) — База данных (Database).
Для принудительного освобождения лога транзакций выполним следующий T-SQL скрипт в окне создания нового запроса:
-- Переключение модели восстановления базы данных в Simple (Простая)
ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY SIMPLE;
GO
-- Сжатие лога транзакций до минимально возможного размера (например, до 10 МБ)
DBCC SHRINKFILE (Имя_Файла_Лога_log, 10);
GO
-- Возврат модели восстановления базы данных в Full (если использовалась полная модель)
ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY FULL;
GO
Обратите внимание: Вместо Имя_Вашей_Базы укажите имя базы в SQL Server, а вместо Имя_Файла_Лога_log — логическое имя файла лога транзакций (его можно посмотреть в свойствах базы данных на вкладке "Файлы").
Шаг 6. Радикальный и самый чистый метод: Перенос данных через XML
Бывают ситуации, когда даже после ТИИ и сжатия база данных остается неоправданно большой. Это связано с тем, что в системных таблицах базы за годы ведения учета скопилось огромное количество неиспользуемых служебных данных, старых версий объектов и внутренних логов, которые невозможно удалить стандартными методами.
В таких случаях применим радикальный метод «пересоздания» базы:
Создадим абсолютно новую, чистую базу данных на базе типового шаблона Бухгалтерия предприятия 3.0 той же самой версии (релиза), до которой мы только что обновились.
В обновленной старой базе данных воспользуемся внешней обработкой ВыгрузкаЗагрузкаДанныхXML.epf (ее можно найти на ИТС или в каталоге шаблонов конфигурации).
Выгрузим все справочники, документы, константы и регистры сведений (за исключением служебных регистров, содержащих историю обновлений или кэш полнотекстового поиска).
Запустим чистую базу данных БП 3.0 и с помощью этой же обработки загрузим полученный XML-файл.
Этот метод позволяет перенести исключительно полезную бизнес-информацию. В результате мы получим абсолютно чистую от технологического мусора базу данных, физический размер которой будет минимально возможным для накопленного объема документов.
Подведем итоги
Мы выяснили, что пятикратный рост базы данных при переходе с БП 2.0 на БП 3.0 — это естественный процесс, обусловленный изменением структуры хранения данных платформы 1С:Предприятие 8.3, разрастанием конфигурации и выполнением фоновых процедур обновления.
Для возвращения базы в оптимальный размер достаточно выполнить последовательную цепочку действий: дождаться завершения отложенных обновлений БСП, очистить индекс полнотекстового поиска и провести процедуру тестирования и исправления со сжатием таблиц. Эти простые регламентные шаги позволят сохранить высокую скорость работы программы и значительно сэкономят дисковое пространство на сервере или локальном компьютере.