При попытке перенести крупную базу данных (в нашем случае — УПП 1.3 весом 240 Гб) из клиент-серверного варианта на MS SQL в локальный файловый вариант через выгрузку в .dt, администраторы часто сталкиваются с критической ошибкой: «Превышен максимально допустимый размер внутреннего файла». Проблема заключается в том, что формат файловой базы данных 1С (файл 1Cv8.1CD) имеет жесткие внутренние ограничения на размер одной таблицы. В этой статье мы подробно разберем, почему это происходит и какими способами можно решить задачу, сохранив работоспособность системы для аудита или разработки.
Рассмотрим внутреннюю структуру файловой базы 1С. Традиционно размер одной таблицы (внутреннего файла внутри .1CD) не может превышать 4 Гб. Это ограничение связано со стандартным размером страницы данных в 4 Кб. Даже если общий объем базы составляет 240 Гб, ошибка возникнет именно в тот момент, когда одна конкретная таблица (например, регистр бухгалтерии или хранилище дополнительных сведений со сканами документов) превысит этот порог при загрузке из .dt.
Проанализируем ситуацию: в типовой конфигурации УПП 1.3 «раздувание» таблиц чаще всего происходит в следующих объектах:
Начиная с версии платформы 8.3.15, разработчики 1С добавили возможность увеличивать размер страницы данных файловой базы с 4 Кб до 64 Кб. Это позволяет теоретически увеличить лимит одной таблицы до десятков гигабайт. Разберем по шагам, как это сделать.
Для изменения формата базы нам понадобится утилита cnv8db.exe, которая находится в папке bin установленной платформы. Рассмотрим пример команды для конвертации:
cd "C:\Program Files\1cv8\8.3.15.XXXX\bin"
cnv8db.exe -p 64k "C:\Bases\MyBase\1Cv8.1CD"
Важный нюанс: Чтобы загрузить .dt сразу в базу с увеличенным размером страницы, необходимо сначала создать пустую файловую базу, выполнить её конвертацию через cnv8db.exe с параметром --pagesize 64k, и только после этого запускать загрузку данных через Конфигуратор.
Если расширение страницы не помогает или база всё равно работает нестабильно, проанализируем структуру хранения базы данных на SQL-сервере. Нам нужно найти «виновника» — самую тяжелую таблицу.
Воспользуемся консолью запросов или специализированными обработками (например, «Структура хранения БД»), чтобы выявить таблицы с максимальным объемом. Выясним, можно ли сократить их объем:
ВерсииОбъектов или ВербальныеДанные, часто можно очистить без потери актуальных учетных данных..dt выполните операцию «Сжатие таблиц» в Конфигураторе на сервере, чтобы убрать «дырки» в индексах и таблицах.Для базы объемом 240 Гб файловый режим — это всегда риск потери производительности и стабильности. Если аудиторам необходимо работать с базой локально на ноутбуке, рассмотрим вариант установки полноценной СУБД.
Использование MS SQL Developer Edition: Это полнофункциональная версия SQL-сервера, которая бесплатна для целей разработки и тестирования. Она не имеет ограничений в 10 Гб (как версия Express) и позволит развернуть базу 240 Гб без каких-либо манипуляций с таблицами.
Использование PostgreSQL: Это полностью бесплатная СУБД с открытым исходным кодом. Она отлично работает с 1С и не имеет лицензионных ограничений по объему данных. Установив PostgreSQL локально на ноутбук аудитора, вы сможете восстановить базу из бэкапа и обеспечить высокую скорость работы.
Проанализируем требования аудиторов. Зачастую требование «база на ноутбуке» связано со страхом подмены данных. Однако для УПП 1.3 на обычных формах работа через файловый режим с таким объемом будет крайне медленной.
Рассмотрим более профессиональный подход:
Это позволит аудиторам работать с полноценной серверной скоростью, используя ваши лицензии и мощности, при этом база физически не покинет периметр компании, что важно для безопасности персональных данных.
Если необходимо во что бы то ни стало использовать файловый режим, используйте платформу не ниже 8.3.15 и утилиту cnv8db.exe для установки pagesize 64k. Однако для баз объемом свыше 100-200 Гб наиболее надежным решением остается локальная установка PostgreSQL или организация удаленного доступа к серверной копии.