В работе с платформой 1С:Предприятие 7.7 программисты и системные администраторы часто сталкиваются с загадочным поведением: один и тот же отчет при нескольких запусках подряд может выдать разные результаты. В одном случае остатки на конец периода отображаются корректно, а в другом — вместо данных выводятся нули или пустые строки. При этом никаких сообщений об ошибках система не выдает. Давайте подробно разберем природу этого явления, которое в профессиональных кругах называют «тихой ошибкой 1 Гб», и выясним, как с этим бороться.
Рассмотрим типичную ситуацию. Отчет, использующий объект Запрос, выполняется достаточно долго (от 2 до 5 минут). В многопользовательском режиме работы часть запусков завершается успешно, а часть — с абсолютно неверными итогами. Проанализируем основные признаки, указывающие на наличие системной проблемы, а не ошибки в коде:
.dbf) приблизился к отметке 1 Гб или превысил её.Выясним причину такого поведения системы. Платформа 1С 7.7 при работе с файловой базой данных (DBF) использует механизмы операционной системы для блокировки записей. Драйвер базы данных резервирует старшие биты смещения в файле для установки блокировок. Когда размер файла .dbf достигает 1 Гб (точнее, 1 073 741 824 байта), адреса реальных данных начинают пересекаться с областью, отведенной под управление блокировками.
Проанализируем ситуацию: если во время того, как один пользователь читает данные (формирует отчет), другой пользователь вносит изменения в этот же файл (проводит документ), система пытается установить блокировку. Из-за пересечения адресных пространств механизм чтения ошибочно воспринимает область данных как заблокированную или вовсе считает, что достигнут конец файла (EOF). В результате Запрос просто прекращает перебор записей, не выдавая никакой системной ошибки, и возвращает те итоги, которые успел собрать до момента «сбоя».
Для начала нам необходимо определить, какой именно файл вызывает сбой. В 1С 7.7 наиболее подвержены росту таблицы регистров и журнал документов. Обратим внимание на следующие файлы в папке базы данных:
RG*.dbf — таблицы итогов регистров. Именно из них отчеты берут остатки.RA*.dbf — таблицы движений регистров. Используются для получения оборотов.1SJOURN.dbf — общий журнал документов. Если отчет анализирует документы напрямую, проблема может быть в нем.1SCREDI.dbf — таблица кредиторской задолженности или другие специфические таблицы (в зависимости от конфигурации).Если размер любого из этих файлов составляет 1 Гб или более (например, 1.2 Гб, как часто бывает в запущенных базах), риск получения «пустых» отчетов становится критическим.
Самый правильный и надежный способ — физически уменьшить размер таблиц. Рассмотрим, как это сделать структурно:
Свертка информационной базы. Это процесс удаления старых документов (например, за прошлые 2-3 года) и ввод входящих остатков на дату начала нового периода. После удаления документов необходимо обязательно выполнить «Упаковку» таблиц (через конфигуратор или удалив файлы индексов .cdx и запустив переиндексацию), чтобы физически освободить место на диске.
Управление итогами. Проанализируем периодичность хранения итогов. В некоторых случаях помогает перенос точки актуальности или пересчет итогов. Также стоит проверить, нет ли в конфигурации лишних индексов. Каждый установленный флаг «Сортировка» или «Отбор» в метаданных увеличивает размер индексного файла, а иногда и основной таблицы.
Если оперативно провести свертку базы невозможно, существует техническое решение, позволяющее «отодвинуть» границу ошибки. Рассмотрим применение специализированных библиотек, таких как kernel3x.dll.
Этот метод заключается в подмене стандартных вызовов функций операционной системы. Патч перехватывает обращения к файловой системе и переносит область блокировок в диапазон выше 2 Гб или 4 Гб. Это позволяет базе данных стабильно работать с файлами размером до 2 Гб (теоретический предел для многих драйверов DBF). Однако помните, что это вмешательство в работу платформы, и перед его внедрением необходимо сделать полную резервную копию базы данных.
Разберем радикальный, но наиболее эффективный метод. Платформа 1С 7.7 существует в версии «Для SQL». При использовании MS SQL Server проблемы с ограничением размера файлов исчезают, так как:
Переход потребует конвертации базы данных через стандартную процедуру «Выгрузить данные — Загрузить данные» в пустую SQL-структуру.
Если вы не можете сменить платформу, попробуйте изменить способ получения данных. Вместо стандартного объекта Запрос можно использовать внешнюю компоненту 1С++. Она позволяет выполнять прямые SQL-запросы к DBF-файлам.
Рассмотрим пример логики (без конкретного кода, так как он зависит от метаданных), почему это помогает:
Посмотрим на проблему с точки зрения системного администрирования. Современные протоколы SMB2 и SMB3 (начиная с Windows 7 и Server 2008) имеют агрессивные механизмы кэширования (Oplocks). Это часто усугубляет нестабильность DBF-баз.
Проанализируем шаги по стабилизации сети:
Мы выяснили, что если ваш отчет в 1С 7.7 внезапно выдает пустые результаты при достижении файлом базы размера в 1 Гб — это не случайный сбой, а документированное ограничение архитектуры DBF. Для решения проблемы в краткосрочной перспективе используйте kernel3x, а в долгосрочной — планируйте свертку базы или переход на MS SQL Server.