При администрировании распределенных информационных баз (УРБД) на платформе 1С:Предприятие 7.7 технические специалисты часто сталкиваются с необходимостью быстрого создания новой периферийной базы (ПБ). Стандартный механизм создания базы через Конфигуратор («Первоначальная выгрузка») на крупных базах данных может занимать десятки часов и выгружать огромный массив избыточной информации.
Для экономии времени администраторы часто используют альтернативный путь — ручное клонирование уже существующей, стабильно работающей периферийной базы с последующим изменением ее идентификатора. Однако при первой же попытке загрузить в такую базу файл обмена из Центральной базы (ЦБ) часто возникает критическая ошибка:
CBD Загрузка из файла D:\TEMP\ОБМЕН\KRK0.zip
CBD Ошибка адреса ИБ
В этой статье мы подробно разберем, почему возникает данная ошибка при ручном клонировании баз, проанализируем структуру системных DBF-таблиц УРБД и рассмотрим пошаговый алгоритм решения этой проблемы.
Основная причина этой ошибки кроется в архитектуре механизма УРБД 1С 7.7. Обмен данными жестко привязан к внутренним уникальным идентификаторам баз (GUID/UUID), которые генерируются платформой автоматически при создании узлов в Конфигураторе. Когда мы просто копируем файлы рабочей периферийной базы и меняем текстовый трехсимвольный идентификатор в настройках (например, с OLD на KRK), внутренние системные идентификаторы в таблицах базы-донора остаются прежними.
Для успешной идентификации баз в процессе обмена платформа 1С 7.7 использует два критически важных GUID:
DBSETUUID в таблице 1SSYSTEM). Этот GUID должен быть абсолютно идентичным во всех базах распределенной сети — как в Центральной базе, так и во всех периферийных. Он определяет принадлежность баз к единому распределенному пространству.DBUUID в таблице 1SDBSET). При создании нового узла периферийной базы в Центральной базе Конфигуратор генерирует для него случайный GUID. При загрузке файла обмена система сравнивает GUID получателя, записанный в заголовке файла обмена (сгенерированный ЦБ), с фактическим GUID принимающей базы, хранящимся в ее локальной таблице 1SDBSET. Если они не совпадают, система выдает ошибку адресации.Проанализируем ситуацию: в клонированной базе в таблице 1SDBSET для записи со статусом текущей базы («Me») остается старый GUID базы-донора. Центральная база выгружает пакет обмена с новым GUID, сгенерированным для новой базы. При импорте происходит конфликт идентификаторов, приводящий к отказу в загрузке.
---
Чтобы успешно запустить клонированную периферийную базу без выполнения долгой штатной выгрузки, нам понадобится любой DBF-редактор, поддерживающий работу с кодировками DOS/Windows (например, DBF Commander, Database Desktop или плагины для Total Commander).
Рассмотрим по шагам весь процесс синхронизации идентификаторов.
Прежде всего, нам необходимо зарегистрировать новую периферийную базу в Центральной базе данных стандартным способом:
KRK) и наименование.KRK уникальный GUID.Теперь нам нужно извлечь созданный платформой идентификатор для новой базы:
1SDBSET.DBF.DBSIGN указан код нашей новой периферийной базы (KRK).DBUUID. Это текстовая строка из 36 символов (например, {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}). Нам нужно скопировать ее полностью и сохранить в текстовый файл.Перейдем к каталогу нашей новой (клонированной) периферийной базы. Первым делом отредактируем общие системные реквизиты:
1SSYSTEM.DBF в каталоге новой ПБ.DBSIGN (трехсимвольный идентификатор базы) запишем код нашей новой базы — KRK.DBSETUUID. Оно должно полностью совпадать со значением поля DBSETUUID в аналогичной таблице Центральной базы. Если они отличаются, скопируем значение из ЦБ и запишем в ПБ. Это свяжет базу с общим информационным пространством.Это самый важный этап, на котором мы устраним непосредственную причину ошибки адресации. Откроем файл 1SDBSET.DBF в каталоге клонированной ПБ. В этой таблице должны остаться строго две записи. Все лишние строки, доставшиеся от старой базы-донора, необходимо удалить. Настроим эти две строки следующим образом:
Запись 1. Настройка текущей базы (статус «M» — Me):
DBSIGN: запишем код новой базы — KRK.DBSTATUS: должно быть установлено значение M.DBUUID: вставим сюда тот самый 36-символьный идентификатор, который мы скопировали из Центральной базы на Шаге 2.Запись 2. Настройка центральной базы (статус «P» — Parent):
DBSIGN: запишем код Центральной базы — например, CBD.DBSTATUS: должно быть установлено значение P.DBUUID: запишем GUID Центральной базы (его можно подсмотреть в файле 1SSYSTEM.DBF Центральной базы или в строке со статусом M в 1SDBSET.DBF Центральной базы).Также обратим внимание на поля имен файлов обмена в этих записях:
DBFNCP — имя файла для передачи данных от родительской базы к дочерней (Parent to Child). Для записи со статусом P здесь должно быть указано имя файла обмена, например, KRK.DBFNPC — имя файла для передачи данных от дочерней базы к родительской (Child to Parent). Убедимся, что имена соответствуют настройкам обмена.Для наглядности проанализируем пример правильного заполнения таблицы 1SDBSET.DBF для новой периферийной базы KRK:
DBSIGN | DBSTATUS | DBUUID | DBFNCP | DBFNPC
-------------------------------------------------------------------------
KRK | M | {F3D2C1B0-A987-4EFE-8DCD-1234567890AB}| |
CBD | P | {A1B2C3D4-E5F6-7A8B-9C0D-1E2F3A4B5C6D}| KRK | CBD
---
Поскольку наша новая периферийная база была получена путем клонирования другой рабочей базы, она унаследовала старые файлы регистрации изменений и таблицы истории загруженных пакетов. Если не очистить эти данные, при первом же обмене мы получим коллизии номеров сообщений («Получено сообщение с номером меньше ожидаемого» или «Файл обмена уже загружался»).
Перед первым запуском базы после редактирования таблиц физически удалим из каталога новой ПБ следующие файлы:
1SDWNLDS.DBF и его индексный файл 1SDWNLDS.CDX (таблица истории загруженных пакетов).1SUPDTS.DBF и его индексный файл 1SUPDTS.CDX (таблица зарегистрированных изменений для обмена).При первом запуске базы в режиме «Предприятие» платформа автоматически создаст эти файлы заново, но они будут абсолютно чистыми, что позволит начать нумерацию пакетов обмена с нуля (с номера 0).
---
После проведения всех манипуляций с файлами выполним запуск базы:
KRK монопольно в режиме «1С:Предприятие»..CDX) для измененных таблиц, система автоматически выдаст уведомление о необходимости переиндексации. Согласимся и дождемся завершения процесса.KRK.Проанализировав результат, мы увидим, что загрузка пройдет без ошибок адресации, так как теперь GUID принимающей базы полностью совпадает с идентификатором получателя, указанным в заголовке файла обмена.
Метод ручного редактирования системных файлов позволяет развернуть новую периферийную базу за считанные минуты вместо многочасового ожидания первоначальной выгрузки. Главное — строго следить за соответствием GUID в таблицах 1SSYSTEM и 1SDBSET. Перед началом любых работ с DBF-файлами всегда создавайте резервную копию базы данных, чтобы иметь возможность быстро откатить изменения в случае ошибки.