Сбои в работе распределенных информационных баз (УРБД) на платформе 1С 7.7, особенно при использовании формата DBF, — явление нередкое. Ситуация осложняется, когда база данных «рушится» непосредственно в момент загрузки обмена: итоги «ползут», документы исчезают из журналов, а остатки начинают показывать некорректные значения за прошлые периоды. Рассмотрим подробно, как реанимировать периферийную базу (ПБ), исправить регистры и обеспечить актуальность данных без потери текущей работы магазина.
Если в базе данных наблюдается «чехарда» с остатками (например, они неверны с 2016 года), это явный признак рассинхронизации таблиц движений (RA) и таблиц итогов (RG). В 1С 7.7 остатки хранятся в файлах RG*, и если при обрыве обмена запись в них прошла некорректно, стандартное «Тестирование и исправление» (ТиИ) без пересчета итогов не поможет. Разберем алгоритм «жесткого» восстановления итогов:
.cdx (индексы). Затем найдем и удалим (или переместим в архивную папку) все файлы, начинающиеся на RG (например, RG123.dbf). В этих файлах хранятся только рассчитанные итоги, которые мы восстановим из документов (таблиц движений RA*).Важный нюанс: Пересчет итогов на больших базах может длиться очень долго (вплоть до 10-15 часов). Проанализируем ситуацию: если файл регистра движений партий (например, DH* или RA*) весит более 1 ГБ, процесс будет медленным. Для ускорения можно использовать RAM-диск — виртуальный диск в оперативной памяти, куда копируется база на время пересчета. Это может ускорить операцию в несколько раз.
Если пересчет итогов не помог или данные в периферийной базе физически повреждены (битые записи DBF), проанализируем возможность «перекрытия» базы данными из Центральной Базы (ЦБ). Это позволит не создавать периферийку с нуля, а принудительно обновить информацию в существующей.
Рассмотрим шаги по «форсированной» выгрузке данных из центра в периферию:
Для массовой регистрации объектов в ЦБ можно воспользоваться коротким скриптом в обработке:
Процедура ЗарегистрироватьВсеДляУРБД(КодПериферийки)
Док = СоздатьОбъект("Документ");
Док.ВыбратьДокументы(ДатаНачала, ДатаКонца);
Пока Док.ПолучитьДокумент() = 1 Цикл
// Метод Записать() без параметров регистрирует изменения для обмена
Док.Записать();
КонецЦикла;
Спр = СоздатьОбъект("Справочник.Номенклатура");
Спр.ВыбратьЭлементы();
Пока Спр.ПолучитьЭлемент() = 1 Цикл
Спр.Записать();
КонецЦикла;
КонецПроцедуры
После такой подготовки выгрузим данные. При загрузке в ПБ система по внутренним идентификаторам (ID) найдет записи и обновит их. Это более мягкий способ, чем создание нового образа.
Если ПБ повреждена настолько, что не открывается или выдает критические ошибки при ТиИ, а ждать 10 часов создания нового образа через Конфигуратор нет возможности, применим метод «клонирования» Центральной Базы. Выясним причину, почему это быстрее: стандартная выгрузка образа делает много лишних проверок, в то время как прямое копирование файлов происходит на максимальной скорости диска.
Проанализируем шаги метода:
1SSYSTEM.DBF. Нам понадобится любой DBF-редактор. Найдем поле DBSIGN и заменим в нем код центральной базы на трехсимвольный код нашей «рухнувшей» периферийки.1SUPDTS.DBF и 1SDWNLDS.DBF.После этих манипуляций база «поверит», что она является той самой периферийной базой. Останется только подложить в нее файл 1SBLOB.DBF (если есть специфические настройки) и запустить работу.
Выясним причину, почему база могла рухнуть. В 1С 7.7 на DBF существует жесткое ограничение: размер любого файла (.dbf или .cdx) не должен превышать 2 ГБ. Если файл RA* или его индекс .cdx приближается к этой отметке, стабильность обмена стремится к нулю.
Если вы видите, что регистры весят 1.4 ГБ — 1.8 ГБ, это «красная зона». В этом случае пересчет итогов может завершаться аварийно. Единственным долгосрочным решением здесь будет:
Если магазин продолжал работать или в центре создавались документы для этого магазина, пока ПБ была «мертва», важно их не потерять при пересоздании базы. Рассмотрим стратегию:
Таким образом, мы восстановим работоспособность магазина и сохраним целостность данных в распределенной системе.