При работе с базами данных 1С программисты и системные администраторы часто сталкиваются с необходимостью развернуть копию клиент-серверной базы в файловом варианте. Однако в процессе загрузки файла .dt может возникнуть критическая ошибка: «Превышен максимальный размер». Ситуация осложняется тем, что база может успешно выгружаться из MS SQL Server, но наотрез отказываться загружаться в .1CD, даже если общий объем .dt кажется небольшим.
В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем внутренние механизмы хранения данных в 1С и найдем способы решения этой проблемы.
Прежде всего, проанализируем ситуацию: ошибка возникает не просто из-за размера самого файла базы данных, а из-за ограничений внутреннего формата 1Cv8.1CD. В файловом варианте вся база хранится в одном файле, который внутри разделен на таблицы. Каждая таблица состоит из нескольких составляющих: данных, индексов и так называемых BLOB-данных (Binary Large Objects), которые в 1С представлены полями типа ХранилищеЗначения.
Рассмотрим основные причины возникновения лимита:
.1CD. Это создает жесткий порог в 4 ГБ для любой отдельной таблицы или ее составляющих..dt эти данные могут занимать в разы больше места, чем в сжатом виде.CREATE INDEX) объем индексного файла превышает допустимый порог.Разберем первый технический способ обхода ограничений — использование утилиты cnvdbfl.exe. Эта утилита позволяет изменить размер страницы данных в файле 1Cv8.1CD. По умолчанию размер страницы составляет 4 КБ, что ограничивает максимальный объем всей базы примерно 4 ГБ (в старых версиях) или создает проблемы при росте таблиц.
Проанализируем алгоритм действий:
C:\Program Files\1cv8\8.3.X.X\bin) утилиту cnvdbfl.exe.1Cv8.1CD и установим параметр «Размер страницы» в значение 64 КБ (65536)..dt в эту подготовленную базу.Важное замечание: Увеличение размера страницы до 64 КБ теоретически расширяет общий лимит базы до терабайтных значений, но, к сожалению, оно не всегда снимает ограничение в 4 ГБ на конкретные внутренние структуры данных (например, на файлы неограниченной длины внутри таблицы). Если ошибка сохраняется при загрузке конкретной таблицы (например, РС «Версии объектов»), значит, мы уперлись именно в лимит BLOB-данных.
Если манипуляции с размером страницы не помогли, нам необходимо уменьшить физический объем данных в самой проблемной таблице перед выгрузкой. Рассмотрим, как это сделать правильно, если у вас есть доступ к серверной базе (SQL).
Проанализируем ситуацию с регистром «Версии объектов». Простое удаление записей через интерфейс 1С («Очистка ненужных версий») часто лишь помечает записи на удаление в базе данных, но не освобождает физическое место немедленно. Выясним, как добиться результата:
Администрирование — Тестирование и исправление. Установим галочку только на пункте «Реструктуризация таблиц информационной базы».Рассмотрим пример кода для программной очистки записей регистра сведений перед выгрузкой:
// Пример очистки регистра ВерсииОбъектов программным способом
НаборЗаписей = РегистрыСведений.ВерсииОбъектов.СоздатьНаборЗаписей();
// Устанавливаем отбор по дате, если нужно удалить только старые
// Или не устанавливаем отбор для полной очистки
НаборЗаписей.Записать();
После выполнения этого кода в SQL-варианте база «похудеет», и вероятность успешной загрузки в .1CD значительно возрастет.
Чтобы точно понять, в какой момент происходит сбой, проанализируем настройки Технологического журнала (ТЖ). Это поможет выяснить, какая именно таблица вызывает ошибку «Превышен максимальный размер».
Создадим файл logcfg.xml в каталоге conf вашей платформы со следующим содержимым:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\Logs\1C_Load_Error" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="DBV8DBEng"/>
</event>
<property name="All"/>
</log>
</config>
После настройки ТЖ запустим процесс загрузки .dt. В логах мы увидим события, предшествующие ошибке. Если последним удачным событием была десериализация таблицы InformationRegister.ВерсииОбъектов, значит, проблема именно в ней. Обратите внимание на отсутствие строки CREATE INDEX — если ее нет, значит, ошибка происходит именно при наполнении таблицы данными (десериализации потока BLOB), а не при индексировании.
Разберем, почему даже сокращение срока хранения версий (например, с 3 месяцев до 1 месяца) может не помочь. В файловом варианте 1С данные хранилищ значений упаковываются в блоки. При частом обновлении объектов и их версионировании возникает сильная фрагментация этих блоков.
Выясним причину: при выгрузке в .dt 1С собирает данные «как есть». Если в SQL-базе данные хранились неоптимально, при попытке восстановить их в файловую базу 1CD механизм десериализации может попытаться создать внутренний файл данных, размер которого превысит 4 ГБ еще до завершения процесса.
Рекомендация: Перед выгрузкой из SQL попробуйте выполнить команду SHRINK DATABASE средствами SQL Server Management Studio. Это переупорядочит страницы данных на физическом уровне, что может положительно сказаться на структуре последующей выгрузки .dt.
Проанализировав проблему, мы можем сделать следующие выводы:
cnvdbfl.exe полезна для общего роста базы, но бессильна против лимита в 4 ГБ на одну таблицу или BLOB-поле..1CD.Рассмотрим финальный чек-лист при возникновении ошибки:
C: (папка %TEMP%), так как распаковка .dt требует много временного пространства.ВерсииОбъектов в исходной базе.Тестирование и исправление (Реструктуризацию) в серверной базе перед выгрузкой..1CD с размером страницы 64 КБ через cnvdbfl.exe.Соблюдение этих шагов позволит успешно перенести данные и избежать блокирующих ошибок при развертывании файловых копий информационных баз.