При работе с файловыми базами 1С формата .1CD пользователи и администраторы часто сталкиваются с аппаратным ограничением движка базы данных. Ошибка «Превышен максимально допустимый размер внутреннего файла» сигнализирует о том, что одна из внутренних таблиц (данные конкретного объекта или его индексы) достигла критического порога в 4 ГБ (или 6-12 ГБ при увеличенном размере страницы). В распределенных информационных базах (РИБ) ситуация осложняется тем, что база «на замке», а «Предприятие» не запускается, что блокирует стандартные методы очистки через обработки.
В данной статье мы подробно разберем, почему возникает эта проблема, как диагностировать «виновную» таблицу и какими методами можно вернуть работоспособность узлу РИБ, сохранив при этом его связь с центральной базой.
Прежде всего, проанализируем техническую сторону вопроса. Файловая база 1С состоит из множества внутренних таблиц. Ограничение накладывается не на общий размер файла 1Cv8.1CD, а на каждый отдельный внутренний файл. Чаще всего «раздуваются» регистры сведений, хранящие техническую информацию: ЗамерыВремени (подсистема оценки производительности APDX), ВерсииОбъектов (история изменений) или ПрисоединенныеФайлы.
Для диагностики в условиях, когда режим «Предприятие» недоступен, выполним следующие шаги:
.dt. Если выгрузка проходит успешно, значит, физическая целостность базы не нарушена.cnvdbfl.exe (находится в папке bin платформы) для проверки размера страницы. Если страница 4К, лимит составляет 4 ГБ. Увеличение страницы до 64К может временно помочь, подняв лимит до 6 ГБ, но это лишь отсрочит проблему.Tool_1CD, или развернуть копию базы на SQL-сервере (если есть такая возможность).Рассмотрим метод, который позволяет инициировать реструктуризацию таблицы в обход режима «Предприятие». Это эффективный способ, если база находится на поддержке (РИБ).
ЗамерыВремени).Если база не открывается из-за переполнения таблиц при инициализации интерфейса, мы можем попробовать выполнить код очистки до того, как система выдаст ошибку. Для этого создадим внешнюю обработку CleanUp.epf с кодом:
Процедура ПриОткрытии()
Набор = РегистрыСведений.ЗамерыВремени.СоздатьНаборЗаписей();
// Мы не устанавливаем отборы, чтобы при записи набор стал пустым
Набор.Записать();
Сообщить("Регистр успешно очищен!");
ЗавершитьРаботуСистемы(Ложь);
КонецПроцедуры
Запустим 1С из командной строки с параметром /Execute:
1cv8.exe ENTERPRISE /F "ПутьКБазе" /N "Имя" /P "Пароль" /Execute "C:\CleanUp.epf"
В некоторых случаях (если переполнение не касается таблиц, нужных для старта сеанса) этот метод позволяет «проскочить» в базу и обнулить данные.
Это самый надежный метод («путь отца русской демократии», как упоминалось в обсуждении), который гарантированно решает проблему лимитов. Разберем его по шагам:
.dt..dt в клиент-серверную базу. В SQL-варианте ограничений на 4 ГБ для таблицы не существует..dt.Важно: При таком подходе идентификаторы объектов и настройки РИБ сохраняются, так как структура Config не менялась критически.
Если манипуляции с конфигурацией не помогают из-за ограничений РИБ, можно временно «отвязать» узел, сделать его автономным, почистить и привязать обратно. Проанализируем этот алгоритм:
1cv8.exe CONFIG /F "Путь" /ResetMasterNode. Это снимет признак подчиненного узла.ЗамерыВремени нам нужно вернуть статус узла. Для этого в режиме «Предприятие» воспользуемся кодом:
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);
Однако помните, что после таких манипуляций может потребоваться перерегистрация изменений, чтобы данные снова синхронизировались корректно.
Выясним причину, почему регистр ЗамерыВремени раздулся до 7 ГБ. Обычно это связано с активным механизмом замера производительности в типовых конфигурациях (БСП).
Проанализируем следующие рекомендации:
ЗамерыВремени не мигрировали в подчиненные узлы. Для этого в плане обмена нужно исключить данный регистр из состава отправляемых данных.Использование данных методов позволит вам эффективно справляться с ограничениями файлового формата 1С, сохраняя целостность распределенной системы.