Работа с платформой 1С:Предприятие 7.7 в режиме DBF накладывает жесткое ограничение: размер любого файла таблицы не может превышать 2 гигабайта. Одним из самых уязвимых в этом плане является файл 1SBLOB.dbf. Когда этот файл достигает критической отметки, база данных перестает принимать новые записи, возникают ошибки индексов, а загрузка обновлений в распределенных информационных базах (РИБ) становится невозможной. Проанализируем причины раздувания этого файла и разберем по шагам, как привести базу в рабочее состояние.
Для начала разберемся, за какие данные отвечает этот файл. В архитектуре 1С 7.7 файл 1SBLOB.dbf (от англ. Binary Large Object) используется как хранилище для данных, размер которых заранее не определен или слишком велик для стандартных полей DBF. Рассмотрим основные объекты, которые «живут» в этом файле:
Проанализируем ситуацию: если ваша база работает в РИБ, файл может расти из-за логов обмена или огромных текстовых комментариев, которые синхронизируются между узлами.
Чтобы понять, какой именно объект раздул файл, нам необходимо найти все реквизиты с неограниченной длиной. Вручную перебирать дерево метаданных в конфигураторе долго и неэффективно, особенно в крупных конфигурациях. Воспользуемся программным методом перебора метаданных.
Рассмотрим пример кода на языке 1С 7.7, который можно запустить в обработке для вывода списка подозрительных реквизитов в окно сообщений:
// Перебор всех справочников
Для и=1 По Метаданные.Справочник() Цикл
ТекСпр = Метаданные.Справочник(и);
Для й=1 По ТекСпр.Реквизит() Цикл
ТекРекв = ТекСпр.Реквизит(й);
Если ТекРекв.Тип = "Строка" Тогда
Если ТекРекв.Длина = 0 Тогда
Сообщить("Справочник: " + ТекСпр.Идентификатор + " -> Реквизит: " + ТекРекв.Идентификатор);
КонецЕсли;
КонецЕсли;
КонецЦикла;
КонецЦикла;
// Перебор всех документов
Для и=1 По Метаданные.Документ() Цикл
ТекДок = Метаданные.Документ(и);
Для й=1 По ТекДок.Реквизит() Цикл
ТекРекв = ТекДок.Реквизит(й);
Если ТекРекв.Тип = "Строка" Тогда
Если ТекРекв.Длина = 0 Тогда
Сообщить("Документ: " + ТекДок.Идентификатор + " -> Реквизит: " + ТекРекв.Идентификатор);
КонецЕсли;
КонецЕсли;
КонецЦикла;
КонецЦикла;
Этот скрипт покажет нам все места, где данные потенциально записываются в 1SBLOB.dbf. После этого проанализируем заполненность этих реквизитов в режиме «Предприятие». Часто оказывается, что какой-то технический реквизит (например, ЛогОбмена или ОписаниеОшибки) хранит мегабайты ненужной информации.
Самый эффективный способ уменьшить BLOB — это отказаться от использования неограниченной длины там, где это не требуется. Если мы установим конкретную длину строки (например, 200 или 250 символов), данные будут перенесены из файла 1SBLOB.dbf в основные файлы таблиц справочников (SC*.dbf) или документов (DH*.dbf/DT*.dbf).
Важный момент: При изменении типа реквизита в конфигураторе с «неограниченной» на фиксированную длину (например, 100), все данные, которые были длиннее 100 символов, будут безвозвратно обрезаны. Перед выполнением этой операции обязательно сделайте резервную копию базы данных!
Нужно понимать особенность формата DBF: даже если вы очистите данные в программе или измените тип реквизита, физический размер файла 1SBLOB.dbf на диске не уменьшится. 1С просто пометит записи как удаленные, но место останется зарезервированным.
Чтобы физически сжать файл, выполним следующие действия:
В процессе упаковки система создаст новые файлы таблиц, перенеся в них только актуальные данные без пометок на удаление. Только после этой процедуры размер 1SBLOB.dbf реально уменьшится.
Если данные действительно важны и их нельзя обрезать, рассмотрим более продвинутые подходы:
Если файл раздут из-за картинок или PDF-файлов, лучшим решением будет вынести их из базы данных. Вместо хранения самого объекта в реквизите типа «Строка неограниченной длины» или «Картинка», мы будем хранить только текстовый путь к файлу на диске (например, C:\Baza\Images\item_001.jpg). Сами файлы будут лежать в отдельной папке. Это позволит держать базу данных легкой и быстрой.
Для технических данных (логи, история изменений) можно использовать архивацию. Перед записью в базу текст упаковывается сторонними компонентами (например, v7plus.dll или GZip), а при чтении — распаковывается. Это позволяет сократить объем занимаемого места в 5–10 раз.
В распределенных базах переполнение 1SBLOB.dbf на периферийной точке может заблокировать обмен. Если это произошло, помните:
Таким образом, системный подход к анализу метаданных и своевременная «упаковка» таблиц позволяют эффективно бороться с ограничениями платформы 7.7 и поддерживать работоспособность системы даже при больших объемах данных.