Как уменьшить размер базы данных 1С 7.7 за счет оптимизации числовых реквизитов в табличных частях документов

← На главную

При длительной эксплуатации систем на базе 1С:Предприятие 7.7 с использованием формата хранения данных DBF системные администраторы и программисты часто сталкиваются с критической проблемой — разрастанием файлов табличных частей документов (файлы DTXXXXX.dbf). В версии 7.7 существует жесткое ограничение на размер одного DBF-файла, который не должен превышать 2 Гб. При приближении к этому порогу база начинает работать нестабильно, а при его достижении запись новых данных становится невозможной.

Одним из эффективных способов «сжатия» базы без удаления архивных данных является пересмотр структуры метаданных, в частности — сокращение длины числовых реквизитов. Разберем подробно, как реализовать этот процесс, на что обратить внимание и как избежать потери данных.

Анализ текущего состояния и поиск «тяжелых» полей

Прежде чем вносить изменения в конфигурацию, проанализируем, какие именно реквизиты занимают лишнее место. В 1С 7.7 числовые данные хранятся в формате Numeric. Каждый такой реквизит занимает в DBF-файле количество байт, равное его длине в конфигураторе, плюс один байт под десятичную точку или знак минуса.

Рассмотрим ситуацию: если в табличной части документа (файл DT) добавлено 10 дополнительных числовых реквизитов с длиной 14 и точностью 2, каждый из них занимает 14 байт в каждой строке. Если в базе накоплено 10 миллионов строк, то один такой реквизит занимает 140 Мб. Сократив его длину до 9 знаков, мы сэкономим 50 Мб на одном поле. В масштабах всей таблицы это может высвободить сотни мегабайт.

Проанализируем максимальные значения, которые реально хранятся в базе. Для этого напишем простую обработку, которая переберет документы и найдет максимальное значение для каждого подозрительного реквизита. Пример кода для поиска максимума:


МаксЗнач = 0;
Док = СоздатьОбъект("Документ.Реализация");
Док.ВыбратьДокументы(ДатаНач, ДатаКон);
Пока Док.ПолучитьДокумент() = 1 Цикл
    Док.ВыбратьСтроки();
    Пока Док.ПолучитьСтроку() = 1 Цикл
        Если Док.НужныйРеквизит > МаксЗнач Тогда
            МаксЗнач = Док.НужныйРеквизит;
        КонецЕсли;
    КонецЦикла;
КонецЦикла;
Сообщить("Максимальное значение реквизита: " + МаксЗнач);

Определение оптимальной длины с учетом «Итогов по колонке»

При сокращении разрядности важно учитывать не только текущие значения в строках, но и итоговые суммы по документу. Если для реквизита в конфигураторе включена опция «Итог по колонке», это значение сохраняется в файле шапок документов (DHXXXXX.dbf).

Выясним причину возможной ошибки: если мы ограничим длину реквизита в табличной части значением 9.2 (максимум 999 999.99), а в документе может быть 100 строк, то итоговая сумма может составить почти 100 миллионов. Это значит, что в шапке документа реквизит, хранящий итог, должен иметь длину не менее 11–12 знаков. Рассмотрим этот момент внимательно:

Проверьте максимальное количество строк в одном документе.
Умножьте максимальное найденное значение реквизита на максимальное количество строк.
Добавьте «запас» на инфляцию или рост объемов (обычно это +1 или +2 к текущей максимальной разрядности).
Убедитесь, что реквизиты в шапке (сумма документа) согласованы с новыми ограничениями табличной части.

Риски и технические нюансы при изменении структуры

Проанализируем ситуацию с отрицательными числами. Если бизнес-логика предполагает сторно или возвраты, в числовом поле обязательно должен быть предусмотрен один знак под символ «-». Например, в поле длиной 9.2 число -100000.00 уже не поместится, так как оно требует 10 позиций (минус, 6 цифр до точки, точка, 2 цифры после). В таких случаях возникнет ошибка Numeric overflow.

Также стоит учитывать влияние на индексы. Уменьшение длины числового поля, по которому включена сортировка или отбор, напрямую уменьшает размер индексного файла .CDX. Это не только экономит место на диске, но и значительно ускоряет операции проведения документов и построения отчетов, так как объем данных, считываемых с диска, сокращается.

Работа с файлом 1SBLOB и строками неограниченной длины

Если в процессе анализа выяснилось, что файл 1SBLOB.dbf также имеет огромный размер, обратим внимание на использование строк неограниченной длины. Часто программисты используют их для хранения сериализованных Таблиц Значений или длинных примечаний.

Разберем способы оптимизации 1SBLOB:

Проверьте, нельзя ли заменить неограниченные строки на строки фиксированной длины (например, 100-200 символов), если данные в них реально не превышают этот предел.
Рассмотрите возможность выноса этих данных в подчиненный справочник. Это перераспределит нагрузку из одного общего файла 1SBLOB в отдельную таблицу справочника, что повысит надежность базы.

Пошаговый алгоритм выполнения изменений

Выполним следующие шаги для безопасного сокращения размера базы:

Создание резервной копии. Это обязательный этап перед любым изменением структуры MD-файла.
Тестирование и исправление (ТиС). Перед внесением изменений запустите процедуру «Упаковка таблиц». В 1С 7.7 при удалении строк или документов записи не стираются физически, а лишь помечаются на удаление. Упаковка позволит физически удалить эти записи и получить реальную картину размера файлов.
Изменение метаданных. В конфигураторе последовательно уменьшаем длину выбранных реквизитов. Не делайте это «впритык» к максимальному значению, всегда оставляйте 1-2 знака запаса.
Сохранение конфигурации. При сохранении 1С начнет процесс реструктуризации. На больших базах (более 1 Гб) этот процесс может занять длительное время. Убедитесь, что на диске достаточно свободного места (минимум в два раза больше текущего размера базы), так как создаются временные файлы.
Переиндексация. После завершения реструктуризации рекомендуется еще раз запустить полное индексирование.

Дополнительные методы сокращения «пухлых» баз

Если манипуляции с числовыми полями не дали желаемого эффекта (например, файл проводок 1SENTRY остается огромным), проанализируем ведение учета. В конфигурациях типа ПУБ или Комплексная часто можно отключить избыточную аналитику на счетах (например, на 41 счете), если эти данные дублируются в регистрах. Это позволит существенно сократить объем файла проводок.

Посмотрим на пример: если учет по партиям и складам ведется в регистрах, дублирование этой аналитики в бухгалтерских проводках лишь увеличивает размер 1SENTRY. Оставив на счете только суммовой учет, вы можете уменьшить размер файла проводок в несколько раз.

В заключение отметим, что если размер базы стабильно держится на уровне 1.5–1.8 Гб и продолжает расти, единственным радикальным и правильным решением будет переход на SQL-версию 1С 7.7. Это полностью снимет проблему ограничения размера файлов и обеспечит более высокую отказоустойчивость системы.