Как перенести базу 1С из SQL в файловый вариант и обойти ошибку «Превышен максимально допустимый внутренний размер файла»

← На главную

Перенос информационной базы из клиент-серверного варианта (SQL) в файловый (1CD) — задача, с которой часто сталкиваются разработчики при необходимости создать локальную копию для разработки или при оптимизации расходов на лицензии. Однако этот процесс часто прерывается критической ошибкой: «Ошибка DBMS: Превышен максимально допустимый внутренний размер файла». В этой статье мы подробно разберем, почему возникает эта проблема, как найти «виновную» таблицу и какие технические приемы позволят успешно завершить миграцию.

Понимаем причину: лимиты файлового формата 1CD

Для начала проанализируем, как устроена файловая база 1С. Файл 1Cv8.1CD является своего рода контейнером, внутри которого хранятся таблицы базы данных. В стандартном режиме (при размере страницы данных 4 Кб) размер одной внутренней таблицы не может превышать 4 Гб. Этот лимит включает в себя не только сами данные, но и индексы к этой таблице.

Начиная с версии платформы 8.3.8, появилась возможность увеличить этот лимит до 6 Гб, выбрав размер страницы 8 Кб. А в более современных версиях (начиная с 8.3.14) при создании базы можно задать размер страницы 16, 32 или 64 Кб, что теоретически позволяет таблицам расти до терабайтных размеров. Ошибка возникает тогда, когда в вашей SQL-базе есть хотя бы одна таблица, объем которой превышает установленный порог для целевого файлового файла.

Шаг 1. Идентификация тяжелых таблиц в SQL

Прежде чем предпринимать действия по переносу, нам нужно выяснить, какая именно таблица мешает выгрузке. Если у нас есть доступ к SQL Server Management Studio (SSMS), мы можем выполнить специальный запрос, который покажет размер всех таблиц в базе данных. Рассмотрим и проанализируем этот скрипт:


USE [Имя_Вашей_Базы]
GO
SELECT 
    tab.name AS TableName,
    part.rows AS [RowsCount],
    CAST(SUM(allocat.total_pages) * 8 / 1024.00 AS numeric(20,2)) AS TotalMB, 
    CAST(SUM(allocat.used_pages) * 8 / 1024.00 AS numeric(20,2)) AS UsedMB, 
    CAST((SUM(allocat.total_pages) - SUM(allocat.used_pages)) * 8 / 1024.00 AS numeric(20,2)) AS UnusedMB
FROM 
    sys.tables tab
INNER JOIN      
    sys.indexes idx ON tab.object_id = idx.object_id
INNER JOIN 
    sys.partitions part ON idx.object_id = part.object_id AND idx.index_id = part.index_id
INNER JOIN 
    sys.allocation_units allocat ON part.partition_id = allocat.container_id
GROUP BY 
    tab.name, part.rows
ORDER BY 
    TotalMB DESC
GO

Этот запрос выведет список таблиц, отсортированный по убыванию их размера в мегабайтах. Обратите внимание на колонку TotalMB. Если значение превышает 4000 (или 6000 для расширенного режима), эта таблица — главная причина ошибки.

Шаг 2. Сопоставление имен SQL и объектов 1С

SQL-таблицы имеют технические имена, такие как _InfoReg12345 или _Document300. Чтобы понять, какой объект метаданных в конфигураторе соответствует этой таблице, мы воспользуемся встроенным методом 1С ПолучитьСтруктуруХраненияБазыДанных(). Выполните следующий код в любой внешней обработке на стороне SQL-базы:


Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТаблицы Из Структура Цикл
    Если СтрокаТаблицы.ИмяТаблицыХранения = "_InfoReg12345" Тогда // Подставьте имя из SQL-запроса
        Сообщить("Проблемный объект: " + СтрокаТаблицы.ИмяТаблицы);
    КонецЕсли;
КонецЦикла;

Так мы выясним, что именно раздуло базу: история версий объектов, огромный регистр сведений с логами или присоединенные файлы (картинки, видео, PDF).

Шаг 3. Методы решения проблемы

Рассмотрим основные стратегии, которые помогут нам «втиснуть» базу в файловые рамки:

Очистка ненужных данных. Часто лимит превышают регистры сведений, хранящие историю версионирования или протоколы обмена. Если эти данные не критичны, их следует очистить перед выгрузкой в .dt.
Удаление файлов из базы. Если в базе хранятся тяжелые медиафайлы в справочниках (например, «Присоединенные файлы»), рассмотрите возможность их удаления или переноса во внешнее хранилище (на диск).
Оптимизация индексов. Иногда размер данных таблицы составляет 2 Гб, а размер индексов к ней — еще 3 Гб. В сумме это дает 5 Гб, что вызывает ошибку. Мы можем проанализировать состав индексов в Конфигураторе и отключить индексирование у тех реквизитов, где оно не является жизненно важным.
Свертка базы данных. Рассмотрим вариант проведения свертки на определенную дату. Это позволит физически удалить старые документы и записи регистров, значительно сократив объем таблиц.

Шаг 4. Увеличение размера страницы при создании файловой базы

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

Для этого воспользуемся утилитой CNVDBFL.EXE, которая находится в папке bin установленной платформы 1С. Проанализируем порядок действий:

Создайте пустую файловую базу.
Запустите CNVDBFL.EXE.
Выберите файл вашей пустой базы 1Cv8.1CD.
Установите флаг «Изменить размер страницы» и выберите значение 65536 (64 Кб).
Выполните преобразование.

После этого попробуйте загрузить ваш .dt файл в эту подготовленную базу. С размером страницы 64 Кб лимит на размер таблицы перестает быть проблемой для большинства информационных баз.

Шаг 5. Подготовка SQL-базы перед выгрузкой

Выясним, какие действия на стороне SQL сервера помогут сделать выгрузку более стабильной. Перед тем как нажать кнопку «Выгрузить информационную базу в файл...», выполните следующие операции:

Тестирование и исправление: запустите его в Конфигураторе с установленным флагом Сжатие таблиц информационной базы.
Обслуживание SQL: выполните операцию Shrink (сжатие) базы данных и Rebuild индексов. Это поможет избавиться от фрагментации и «пустых» страниц внутри файлов данных, что иногда критично для корректного формирования .dt.
Пересчет итогов: если проблема в таблицах итогов регистров, полный пересчет итогов в Конфигураторе может значительно уменьшить их физический размер.

Резюме

Мы проанализировали ситуацию, когда стандартный перенос базы блокируется СУБД. Помните: файловый вариант — это всегда компромисс. Если ваша база требует использования страниц размером 64 Кб для работы, рассмотрите возможность остаться на клиент-серверном варианте, используя бесплатную версию PostgreSQL. Это избавит вас от рисков повреждения файлового контейнера при внезапном отключении питания и обеспечит гораздо более высокую производительность при тех же объемах данных.