Работа с платформой 1С 7.7 в файловом режиме (DBF) рано или поздно приводит к столкновению с физическим ограничением формата: размер любого файла таблицы не может превышать 2 Гб. Чаще всего "раздуваются" таблицы итогов (файлы вида RG*.dbf). Когда этот предел достигнут, база перестает позволять записывать новые документы, а штатные средства выгрузки в .dt выдают ошибку. Рассмотрим подробно, как мы можем решить эту проблему, очистить базу от лишних данных и восстановить работоспособность системы.
Проанализируем механику работы системы. В 1С 7.7 таблицы итогов RG хранят остатки на начало каждого месяца. Если по какому-то набору измерений (например, "Номенклатура", "Склад", "Партия") завис остаток хотя бы в 0.00001 или произошел пересорт (на одном складе +1, на другом -1), система будет копировать эту запись в таблицу каждого последующего месяца до бесконечности. Это и есть "незакрытые регистры".
Разберем типичные ситуации:
Если база уже не позволяет выгрузить данные, мы можем прибегнуть к радикальному, но эффективному методу очистки. Рассмотрим алгоритм действий:
RG* и RH*. Это таблицы итогов и истории. Не беспокойтесь, данные о движениях хранятся в файлах RA*.Важный нюанс: Перед пересчетом итогов стоит убедиться, что в системе нет движений "в глубоком прошлом", которые не нужны для работы. Сдвиг ТА назад без перепроведения документов позволяет системе не рассчитывать итоги за будущие (относительно ТА) периоды, что уменьшит размер итоговых таблиц.
Проанализируем структуру конфигурации. Иногда размер файла можно уменьшить, просто изменив типы данных в метаданных. Посмотрим на пример:
Если в регистре "ОстаткиТоваров" ресурс Сумма имеет длину 20 знаков с точностью 2, а реальные обороты компании не превышают миллионов, мы можем безболезненно уменьшить длину до 12-14 знаков. Это сократит длину каждой записи в DBF-файле. Посчитаем: при миллионах записей экономия даже в 2-4 байта на строку может дать сотни мегабайт выигрыша.
Также стоит рассмотреть "схлопывание" аналитики. Если компания работает как "интеркомпани" (несколько юрлиц), но детальный учет по фирмам в регистрах остатков не критичен, можно программно заменить значение измерения Фирма на пустое значение. Рассмотрим пример кода для обработки движений:
Рег = СоздатьОбъект("Регистр.ОстаткиТоваров");
Рег.ВыбратьДвижения(ДатаНачала, ДатаКонца);
Пока Рег.ПолучитьДвижение() = 1 Цикл
Если ПустоеЗначение(Рег.Фирма) = 0 Тогда
// Заменяем конкретную фирму на пустую ссылку для схлопывания итогов
Рег.Фирма = ПолучитьПустоеЗначение("Справочник.Фирмы");
Рег.Записать();
КонецЕсли;
КонецЦикла;
После такого "схлопывания" количество уникальных записей в таблице RG резко сократится, так как остатки по разным фирмам объединятся в одну строку.
Если штатная выгрузка в .dt (или .zip для 7.7) выдает ошибку из-за размера, воспользуемся наработками сообщества:
bkend.dll, которые позволяют обходить ограничение 2 Гб, используя возможности файловой системы NTFS. Это позволит базе "проглотить" большой объем данных, чтобы вы могли провести свертку.ConfStat или аналоги, которые считывают сообщения напрямую из памяти процесса 1cv7.exe. Это позволит нам видеть реальный прогресс операции.Самый правильный с точки зрения методологии способ — это свертка. Выясним причину, по которой она не делалась ранее, и приступим:
RA и итогов RG, применяя универсальное сжатие базы для минимизации объемов.Для ускорения процесса можно использовать "Универсальный двигатель регистров". Это обработка, которая позволяет быстро перенести остатки из одной базы в другую или переформировать их внутри текущей без полного перепроведения всех цепочек документов. Также для миграции объектов пригодится выгрузка и загрузка справочников TRANREF.
При работе с базами, объем которых приближается к критическому, мы часто наблюдаем "белый экран" и отсутствие реакции программы. Проанализируем ситуацию: ОС Windows считает приложение зависшим, если оно долго не отвечает на системные сообщения. Чтобы минимизировать это:
1cv7.exe продолжает читать и писать данные в файлы RG*.Подведем итог: Основная стратегия борьбы с разрастанием итогов — это поиск "мусорных" остатков и их отсечение. Если база уже "встала", используем физическое удаление файлов RG* и последующий пересчет, предварительно обеспечив стабильную среду выполнения с помощью патчей или режима совместимости.