При активной коллективной разработке в среде 1С:Предприятие программисты часто сталкиваются с неприятной ситуацией: при попытке поместить измененные объекты в хранилище система выдает критическую ошибку: «Ошибка при попытке помещения объекта в хранилище конфигурации» по причине «Превышен максимально допустимый размер внутреннего файла '.../1cv8ddb.1CD'». В этой статье мы подробно проанализируем, почему возникает данное ограничение, как устроена файловая СУБД 1С изнутри, и разберем по шагам все возможные способы решения проблемы — от простых организационных мер до передовых технических решений.
Для того чтобы понять природу проблемы, разберем внутреннее устройство файла хранилища конфигурации 1cv8ddb.1CD. Этот файл представляет собой стандартную базу данных собственного файлового формата 1С. Любая таблица внутри этой базы данных (включая таблицы, хранящие версии конфигураций и бинарные данные объектов) физически делится на несколько составляющих частей:
В старых версиях платформы (или при определенных настройках совместимости) размер страницы данных по умолчанию составляет всего 4 Кб. Из-за особенностей 32-битной адресации страниц СУБД 1С, максимальный объем любого из этих четырех внутренних файлов одной таблицы физически ограничен величиной 4 Гб (точнее, около 4,26 Гб). Как только ваша конфигурация накапливает историю изменений, объем бинарных данных в таблице версий превышает этот лимит, и СУБД блокирует любые операции записи.
Многие разработчики сразу пытаются выполнить операцию сокращения истории хранилища. Однако в большинстве случаев эта попытка также аварийно завершается с аналогичной ошибкой превышения размера. Выясним причину этого поведения: дело в том, что СУБД 1С при удалении устаревших версий или их объединении создает временные таблицы и активно использует механизм транзакций. Так как лимит в 4 Гб уже исчерпан, у СУБД физически нет свободного пространства страниц для записи временных файлов транзакций. Процесс аварийно прерывается, оставляя базу в исходном состоянии.
Рассмотрим подробнее четыре основных способа решения этой проблемы, начиная с самых современных и эффективных.
Если вы работаете на современных релизах платформы, вам доступно наиболее технологичное решение, которое позволяет полностью сохранить всю многолетнюю историю разработки. Начиная с версии платформы 1С:Предприятие 8.3.8, разработчики добавили возможность управления размером страницы файловой СУБД с помощью утилиты CNVDBFL.EXE.
Увеличение размера страницы базы данных пропорционально увеличивает максимально допустимый размер внутренних таблиц:
Разберем по шагам процесс конвертации хранилища без потери данных:
1cv8ddb.1CD из каталога вашего хранилища в надежное место.CNVDBFL.EXE. Обычно она располагается в каталоге установленной платформы, например: C:\Program Files\1cv8\8.3.X.X\bin\.-p 64k) и путь к файлу хранилища:
"C:\Program Files\1cv8\8.3.18.1300\bin\cnvdbfl.exe" -c -f 8.3.8 -p 64k "D:\Storages\BMS\1cv8ddb.1CD"
После успешного завершения процесса лимит на размер внутренней таблицы вырастет в 16 раз, что позволит вашей команде беспрепятственно продолжить работу с текущим хранилищем еще долгие годы.
Если вы используете старые версии платформы (например, 8.2) и не имеете возможности обновиться, то единственным выходом будет создание нового «чистого» хранилища.
Проанализируем этот процесс:
Важный нюанс: при этом подходе вы полностью теряете интерактивную историю изменений в конфигураторе. Для сохранения преемственности старое хранилище рекомендуется оставить в режиме «только для чтения» (без возможности изменения объектов) исключительно для просмотра истории прошлых лет.
Начиная с версии платформы 8.3.3, разработчики 1С оптимизировали внутренние механизмы работы версионирования. Был изменен способ хранения объектов конфигурации — они стали записываться непосредственно в файловую систему, минуя СУБД 1CD.
Чтобы задействовать эту оптимизацию, необходимо выполнить следующие действия:
Обратите внимание, что данная настройка применится только для новых помещаемых объектов, поэтому ее рекомендуется включать либо на ранних этапах жизни хранилища, либо сразу после создания нового репозитория.
В современной практике крупной разработки классическое файловое хранилище 1С признано устаревающим инструментом. Если ваша команда постоянно сталкивается с лимитами производительности и объема, мы рекомендуем рассмотреть переход на современные инструменты:
При использовании этого стека конфигурация полностью выгружается в структурированный набор текстовых и XML-файлов. Весь процесс ведения истории, слияния веток разработки и фиксации коммитов переносится в репозиторий Git (например, на корпоративный сервер GitLab или GitHub). В репозиториях Git отсутствуют какие-либо искусственные ограничения СУБД 1С на объем таблиц в 4 Гб, а скорость работы с историей изменений возрастает в десятки раз.
Чтобы продлить жизненный цикл вашего файлового хранилища 1С и избежать внезапного достижения лимитов, придерживайтесь следующих правил командной разработки:
Процедура Префикс_ПриЗаписиДокумента(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
// Наш кастомный обработчик логики
Префикс_ВыполнитьРасчетПараметров(Источник);
КонецПроцедуры
Применение этих простых правил в сочетании со своевременной конвертацией базы данных утилитой CNVDBFL.EXE гарантирует стабильную и быструю работу вашей команды разработчиков без критических сбоев и потери ценной истории конфигурации.