← На главную

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

Основные риски и технические ограничения формата DBF в 1С 7.7

Для начала разберем природу ограничений файлового формата DBF и СУБД CodeBase, на которой работает 1С 7.7. Многие системные администраторы ошибочно полагают, что использование различных патчей операционной системы решает все проблемы с размером базы. Это не так.

Существует несколько жестких лимитов, о которых нужно знать:

1. Физический лимит размера файла (2 ГБ): СУБД CodeBase принципиально не умеет адресовать файлы (как DBF, так и CDX) размером более 2 ГБ (точнее, 2 147 483 647 байт). При превышении этого порога запись в файл прекращается, а система аварийно завершает работу с ошибками СУБД (например, CodeBase Error -120, -70 или -110).
2. Лимит индекса CDX: Очень часто критическая ошибка возникает еще до того, как сам файл данных .DBF вырастет до 2 ГБ. Индексный файл .CDX из-за большого количества измерений и реквизитов регистра растет гораздо быстрее. Превышение лимита в 2 ГБ индексным файлом приводит к точно такому же фатальному падению системы.
3. Ограничение на количество записей: Движок 1С 7.7 имеет ограничение по адресации строк в индексах. При приближении к 16,7–20 миллионам записей в одной таблице база может начать сбоить и рушиться даже при физическом размере файла менее 2 ГБ.
4. Бесполезность патчей Kernel3x (решений 5 и 6): Популярные библиотеки-заплатки, размещаемые в каталоге BIN платформы, предназначены только для обхода проблем с блокировками файлов в многопользовательском режиме («ошибка сетевого гигабайта»). На физическое ограничение размера файла в 2 ГБ они никак не влияют.
5. Лимит встроенного архиватора ZIP: Стандартный механизм выгрузки данных через Конфигуратор не может упаковать файл 1Cv77.dat, если его размер (или размер итогового архива) превышает 2 ГБ. Выгрузка будет прерываться с ошибкой, либо сформирует «битый» архив.

Давайте подробно рассмотрим четыре основных способа решения проблемы переполнения регистра.

Способ 1. Оптимизация структуры регистров и удаление лишних данных

Если свертка базы по каким-то причинам нежелательна, а переходить на SQL прямо сейчас нет возможности, мы можем существенно уменьшить физический размер таблиц за счет оптимизации метаданных.

Проанализируем структуру регистра партий в Конфигураторе. В типовых конфигурациях «Торговля и Склад» этот регистр часто перегружен избыточными измерениями и излишней разрядностью ресурсов:

1. Сокращение разрядности числовых полей: По умолчанию для количества и сумм в 1С 7.7 часто задается длина 15 знаков с точностью 3 или 2 знака после запятой. Если в вашей специфике бизнеса нет миллиардных оборотов или штучного товара с точностью до граммов, длину числовых полей (особенно ресурсов количества) можно смело уменьшить. Например, вместо формата 15.3 использовать 10.3 или 12.2. Это сэкономит байты в каждой строчке таблицы движений.
2. Удаление неиспользуемых измерений:
   • Если учет ведется строго по одной организации, можно безболезненно удалить измерение Фирма.
   • Если у вас один склад или логика списания не привязана к конкретному складу, можно избавиться от измерения Склад.
   • В розничной торговле при партионном учете часто оказывается неиспользуемым измерение ЦенаПрод (Цена продажи) — его удаление даст колоссальную экономию места.

Важно: При изменении структуры метаданных в распределенной информационной базе (УРБД) стандартная реструктуризация в Центральной Базе (ЦБ) породит огромный файл обмена для периферийных баз (ПБ), который может просто не загрузиться. Чтобы этого избежать, используем следующий алгоритм обхода:

1. Проводим полную синхронизацию со всеми периферийными базами и останавливаем обмен.
2. Создаем пустую базу-копию, вносим изменения структуры регистра в ее Конфигураторе и сохраняем метаданные. Получаем новые файлы 1Cv7.md и 1Cv7.dd.
3. Заменяем файлы метаданных (.md и .dd) в рабочей базе «на горячую».
4. Физическую структуру самих файлов таблиц RA*.dbf и RG*.dbf приводим к новому формату с помощью любого стороннего DBF-редактора, поддерживающего групповые операции (либо программно), изменив длину соответствующих колонок.
5. Очищаем таблицу регистрации изменений 1Supdts.dbf перед возобновлением обменов, чтобы исключить передачу гигантского пакета реструктуризации. На периферийных базах операцию изменения структуры DBF и замены MD проводим аналогично вручную.

Способ 2. Правильная свертка базы данных (обработка WRAP.ert)

Свертка базы — самый надежный способ радикально уменьшить размер таблиц движений (RA*). Однако при ее выполнении на больших базах администраторы часто совершают критическую ошибку, из-за которой база аварийно падает прямо во время процесса свертки.

Дело в том, что при удалении или пометке на удаление документов за прошлые периоды платформа начинает лавинообразно пересчитывать итоги по регистрам за каждый месяц. Из-за этого файлы итогов RG*.dbf начинают стремительно раздуваться и переполняют лимит в 2 ГБ еще до окончания работы обработки.

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

1. Сдвиг периода расчета итогов: Перед запуском удаления старых документов необходимо обязательно зайти в Конфигуратор (или режим предприятия) и установить период расчета бухгалтерских и оперативных итогов на самый ранний период (например, на начало ведения учета в базе — 01.01.2012). Это отключит автоматический пересчет итогов «на лету» при удалении каждого документа.
2. Запускаем обработку свертки (WRAP.ert), которая формирует документы ввода остатков на дату свертки (например, 01.01.2018) и удаляет старые документы движения. Процесс пройдет значительно быстрее и без риска переполнения файлов RG*.
3. После успешного удаления документов и фиксации остатков устанавливаем актуальную дату расчета итогов (01.01.2018) и запускаем полный пересчет итогов в режиме монопольного доступа.
4. Выполняем обязательную упаковку таблиц базы данных (через «Администрирование -> Тестирование и исправление ИБ» с флагом «Упаковка таблиц») для удаления физических пустых записей из файлов DBF.

Дополнительно для уменьшения объема таблицы итогов RG*.dbf рекомендуется использовать специализированные внешние обработки (например, популярное решение «Шишки для мартышки»), которые находят и вычищают из таблиц итогов «нулевые остатки» — записи, по которым когда-то было движение, но текущий итог равен нулю. В штатном режиме 1С 7.7 продолжает тащить эти пустые строки из периода в период, раздувая базу.

Способ 3. Переход на клиент-серверный режим (MS SQL Server)

Если бизнес-требования обязывают хранить всю историю за 5 и более лет без свертки, единственным долгосрочным решением является перенос базы на MS SQL Server.

Существует миф, что в SQL-версии 1С 7.7 таблицы движений также ограничены лимитом в 2 ГБ. Это технически неверно. В SQL-режиме хранением данных полностью управляет СУБД MS SQL, и размеры таблиц могут составлять сотни гигабайт. Лимит в 2 ГБ может коснуться только временных таблиц в системной базе tempdb при некорректно написанных прямых запросах, либо при полном исчерпании места на жестком диске сервера.

Разберем особенности миграции крупной DBF-базы на SQL:

1. Выгрузка базы большого размера: Стандартный процесс «Выгрузить данные» в файловом режиме завершится ошибкой из-за превышения лимита ZIP в 2 ГБ. Для обхода этой проблемы необходимо использовать специальную внешнюю библиотеку unload_dat_fix.dll (или сторонние решения, такие как утилита configspy). Они позволяют выгружать данные напрямую в несжатый файл romix.dat без ограничений по размеру.
2. Выбор СУБД: Если нет бюджета на покупку полноценной лицензии MS SQL Server, можно использовать бесплатную версию MS SQL Server Express. Начиная с версии 2008 R2 Express, лимит на размер одной базы данных увеличен до 10 ГБ. Для базы 1С 7.7 этого лимита обычно хватает очень надолго, так как SQL-базы сжимаются эффективнее файловых.
3. Запуск 1С 7.7 на Windows Server 2008 R2 x64 и SQL Server 2008: Для стабильной работы штатной 32-разрядной версии 1С 7.7 на современных 64-битных ОС потребуется применить известные в сообществе патчи для обхода проверки версии SQL (так называемый «секретный релиз» или подмена библиотеки BkEnd.dll), а также использовать модифицированный дистрибутив инсталлятора, совместимый с x64-системами.

Способ 4. Использование Advantage Database Server (ADS)

Если переход на полноценный SQL-сервер затруднен из-за отсутствия квалифицированного администратора базы данных или сложностей настройки, промежуточным решением может стать использование Advantage Database Server (ADS).

Этот программный продукт заменяет стандартный движок баз данных 1С (путем подмены библиотеки dbeng32.dll в каталоге программы) и переводит файловую базу в клиент-серверный режим работы с файлами формата FoxPro. Основное преимущество ADS в контексте нашей проблемы — расширение физического лимита размера DBF-файлов с 2 ГБ до 4 ГБ. Это позволит выиграть еще несколько лет стабильной работы информационной базы для подготовки к плановому переходу на современную платформу «1С:Предприятие 8».