При работе с крупными базами данных на платформе 1С:Предприятие 7.7 системные администраторы и программисты часто сталкиваются с «критической отметкой» — размером файла 1SENTRY.dbf (журнал проводок), приближающимся к 2 Гб. Это жесткое ограничение архитектуры DBF-движка 1С 7.7, связанное с использованием 32-битных смещений. Как только файл достигает этого порога, любая попытка записи новой проводки приводит к фатальной ошибке, остановке работы бухгалтерии и даже невозможности штатно выполнить свертку базы, так как временные таблицы также упираются в этот лимит.
В данной статье мы подробно разберем, как выйти из этой ситуации, рассмотрим методы «реанимации» базы через изменение структуры таблиц и проанализируем процесс миграции на SQL-версию программы.
Прежде чем приступать к активным действиям, проанализируем природу ошибки. Ограничение в 2 Гб ($2^{31}-1$ байт) обусловлено тем, что драйвер DBF в 1С 7.7 использует знаковые целые числа для адресации внутри файла. Когда файл становится больше, указатель принимает отрицательное значение, и программа теряет доступ к данным. Проблема усугубляется тем, что индексные файлы (.cdx) также имеют этот лимит, и зачастую база «падает» раньше, когда индекс 1SACCEL.cdx дорастает до критического объема.
Рассмотрим основные способы решения проблемы, от временных мер до кардинальной смены архитектуры хранения данных.
Если база «встала», а работать нужно немедленно, можно выиграть время, уменьшив физический размер файла за счет сокращения избыточных текстовых полей. Рассмотрим этот процесс по шагам. Внимание: все действия выполняются строго на копии базы!
1CV7.DD (лежит в корне каталога базы) любым текстовым редактором. Найдем описание таблицы 1SENTRY. Нас интересуют длинные текстовые поля, которые часто содержат много пустых пробелов.SP547 (Содержание проводки) и SP27565 (Первичный документ). По умолчанию их длина может достигать 50, 100 или даже 133 символов. На практике бухгалтеры редко заполняют их целиком.1CV7.DD. Например, сократим SP547 с 50 до 30 символов, а SP27565 со 133 до 50 символов. Это позволит 1С в будущем «считать», что поля стали короче.Используем специализированный редактор DBF-файлов. Откроем в нем 1SENTRY.dbf и вручную изменим длину соответствующих полей в соответствии с теми значениями, которые мы прописали в 1CV7.DD. После сохранения изменений файл физически уменьшится в размере, так как «отрежутся» лишние хвостовые пробелы в каждой из миллионов строк.
После внесения правок обязательно удалим все индексные файлы с расширением .cdx в каталоге базы. Запустим 1С в монопольном режиме и дождемся завершения процесса восстановления индексов.
Этот метод позволяет освободить от 300 до 600 Мб дискового пространства в файле, что даст организации запас времени (от нескольких недель до месяцев) для планового перехода на SQL или проведения свертки.
Это единственный надежный способ навсегда забыть об ограничениях в 2 Гб. Разберем, как перевести «тяжелую» файловую базу на SQL, даже если она уже не выгружается штатно.
Проанализируем последовательность действий для миграции:
Для 1С 7.7 оптимальным выбором был MS SQL 2000, однако на современных ОС приходится использовать MS SQL 2008, 2012 или 2014. Создадим пустую базу данных в SQL Management Studio (режим совместимости лучше оставить 2000 или 2008). Убедимся, что используется SQL Server Authentication.
Для корректной работы 1С 7.7 с современными версиями SQL необходимо выполнить следующие «хитрости»:
1cv7.exe). Это позволит игнорировать ошибки сортировки (Collation), которые часто возникают из-за различий в региональных настройках Windows и SQL Server.Если штатная выгрузка в .dat файл не проходит из-за ошибок в огромном DBF, можно попробовать «схитрить»:
Если компания хочет остаться на DBF-версии (например, из-за скорости работы небольшого количества пользователей), необходимо провести свертку (обрезание старых периодов). Однако, как мы выяснили, на файле в 1.99 Гб штатная свертка часто падает.
Рассмотрим алгоритм «Свертки через SQL»:
Wrap.ert (свертка базы). Удаляем документы и проводки до 31.12.2018 (как в нашем примере)..dat.1SENTRY.dbf будет иметь значительно меньший размер (например, 300-500 Мб), сохранив при этом актуальные данные и остатки.Проанализируем несколько технических нюансов, которые помогут избежать ошибок в будущем:
Индексы и итоги: При работе с большими таблицами 1SENTRY очень важно следить за актуальностью итогов. Если база часто аварийно завершается, итоги могут «разъехаться». Рекомендуется регулярно выполнять процедуру «Пересчет бухгалтерских итогов».
Настройка сервера: Если вы используете современный многоядерный сервер для 1С 7.7, попробуйте ограничить количество ядер для процесса 1cv7.exe до одного или двух. Старый движок 1С не умеет эффективно распределять потоки, и на 32-ядерных системах могут возникать необъяснимые блокировки при чтении тяжелых DBF.
Использование ADS (Advantage Database Server): Существует альтернативный путь — установка сервера ADS. Это промежуточное решение, которое позволяет 1С 7.7 работать с DBF-файлами размером более 2 Гб без перехода на полноценный SQL. Это требует замены библиотеки dbeng32.dll на модифицированную, но позволяет существенно продлить жизнь файловой версии.
Мы рассмотрели три основных пути решения проблемы. Первый путь (правка DD и DBF) — это «первая помощь», позволяющая быстро вернуть базу в строй. Второй путь (SQL) — это стратегическое решение для растущего бизнеса. Третий путь (свертка через SQL) — лучший способ очистить базу от «груза истории», сохранив ее мобильность в файловом варианте.
Выясним, какой метод подходит вам: если количество записей в 1SENTRY превысило 5 миллионов (как в обсуждаемой теме), переход на SQL становится не просто желательным, а обязательным условием стабильной работы предприятия.