При работе с распределенными информационными базами (УРБД) в 1С 7.7, особенно когда количество периферийных узлов велико, процесс создания каждой новой периферийной базы (ПБ) может быть крайне трудоемким. Основная проблема заключается в длительной начальной загрузке данных и последующем пересчете итогов, что занимает часы, а порой и дни. Мы рассмотрим два основных подхода к решению этой задачи: первый — это клонирование уже существующей или свежесозданной периферийной базы с ручной корректировкой служебных файлов УРБД, а второй — оптимизация процесса создания новых ПБ через модификацию стандартной обработки свертки информационной базы.
Прежде чем приступать к каким-либо манипуляциям, настоятельно рекомендуем выполнить полное резервное копирование всех участвующих информационных баз. Работа со служебными файлами УРБД требует предельной внимательности и понимания процессов, чтобы избежать потери данных или нарушения обмена.
Этот метод подразумевает создание копии существующей базы (Центральной или уже настроенной периферийной) и последующую ручную настройку ее как новой периферийной базы в системе УРБД. Этот подход позволяет избежать длительного процесса начальной выгрузки и загрузки данных, особенно если у вас уже есть свернутая центральная база, которая может послужить основой.
Разберем по шагам, как это сделать:
Начнем с создания полной копии вашей свернутой Центральной Базы (ЦБ) или уже существующей периферийной базы, которую мы будем клонировать. Предполагается, что эта база уже содержит актуальные и, при необходимости, свернутые данные, и мы хотим использовать ее как шаблон для новых ПБ. Допустим, мы скопировали ее в новый каталог, который будет нашей новой периферийкой.
1sdbset.dbf.
Файл 1sdbset.dbf содержит информацию о всех узлах распределенной базы и их статусах. Его необходимо отредактировать так, чтобы новая база правильно идентифицировала себя и центральный узел. Для этого:
Откройте файл 1sdbset.dbf (можно использовать любой редактор DBF-файлов).
Найдите запись, соответствующую текущей базе, и установите для нее статус 'M' (Master-узел) или 'P' (периферийный узел), согласно вашей конфигурации УРБД. В рамках данного обсуждения предлагается установить 'M' для текущей периферийной базы. Это сигнализирует системе, что данный узел является активным участником обмена.
Примерно это будет выглядеть так (мы изменили статус для новой базы):
ИД_УЗЛА_НОВОЙ_ПБ | ИМЯ_НОВОЙ_ПБ | M
ИД_ЦЕНТРАЛЬНОЙ_БАЗЫ | ИМЯ_ЦЕНТРАЛЬНОЙ_БАЗЫ | P
Обратите внимание: символы 'M' и 'P' должны быть английскими.
Найдите запись, соответствующую вашей Центральной Базе, и установите для нее статус 'P'.
Удалите все остальные записи из этого файла, которые относятся к другим периферийным базам. Новая ПБ не должна знать о существовании других ПБ напрямую; все обмены идут через ЦБ.
1ssystem.dbf.
В этом файле хранится уникальный идентификатор базы данных – dbsign. Каждая база в УРБД должна иметь свой уникальный dbsign для корректного обмена. Мы должны изменить его для нашей новой периферийной базы.
Откройте файл 1ssystem.dbf.
Найдите поле dbsign и измените его значение на новый, уникальный код. Мы можем использовать произвольный уникальный код (например, основанный на GUID или простой последовательности чисел), который не пересекается с кодами других баз в вашей системе УРБД. Это критически важно для предотвращения конфликтов при обмене данными.
Пример:
// Оригинальный dbsign
DBSIGN = "SOME_OLD_CODE"
// Новый уникальный dbsign для новой ПБ
DBSIGN = "NEW_UNIQUE_CODE_FOR_PB00X"
1supdts.dbf.
Файл 1supdts.dbf регистрирует все изменения, произошедшие в текущей базе, которые еще не были отправлены другим узлам. Поскольку мы создаем новую базу, ее история обмена должна начинаться с чистого листа. В противном случае, она попытается отправить данные, которые уже существуют в ЦБ, что приведет к ошибкам или дублированию.
Полностью очистите этот файл. Мы можем сделать это, удалив все записи в нем с помощью команд DBF-редактора (например, ZAP или DELETE ALL с последующим PACK).
Если вы можете открыть базу в монопольном режиме и есть доступ к программной обработке:
Сообщить("Очистка 1supdts.dbf...");
// Получаем доступ к таблице напрямую (пример для FoxPro-совместимых баз)
БазаДанных.ВыполнитьSQL("DELETE FROM 1supdts.dbf");
БазаДанных.ВыполнитьSQL("PACK 1supdts.dbf"); // Очистка физического места
Сообщить("1supdts.dbf очищен.");
В некоторых случаях достаточно удалить сам файл 1supdts.dbf и 1supdts.cdx (индексный файл). При следующем монопольном запуске 1С с установленными параметрами УРБД система создаст его заново.
1sdwnlds.dbf.
Аналогично 1supdts.dbf, файл 1sdwnlds.dbf содержит информацию о том, какие изменения были получены от других узлов. Для новой периферийной базы эта история также неактуальна и должна быть очищена.
Полностью очистите этот файл так же, как и 1supdts.dbf (удалите все записи или сам файл с индексным файлом 1sdwnlds.cdx).
Многие конфигурации 1С 7.7 используют префиксы для уникальной идентификации документов и элементов справочников, созданных в разных узлах УРБД (например, "ПБ1-" для первой периферийки, "ПБ2-" для второй). Мы должны убедиться, что новая ПБ будет использовать свой уникальный префикс. Мы можем настроить это в параметрах конфигурации (например, в константах или через обработку), чтобы избежать конфликтов при нумерации объектов.
Это очень важный шаг, и его забывчивость может привести к серьезным проблемам с дублированием данных или ошибками нумерации.
После всех этих изменений необходимо выполнить полный обмен данными между Центральной Базой и нашей новой Периферийной Базой. Сначала мы выгружаем изменения из ЦБ и загружаем их в ПБ, затем выгружаем изменения из ПБ (которые, по сути, будут пустыми, но система зафиксирует регистрацию новой ПБ) и загружаем их в ЦБ. Этот процесс позволит ЦБ узнать о новой ПБ как о полноправном участнике обмена, а новая ПБ получит все актуальные данные с ЦБ с чистого листа.
Дополнительные соображения: Этот метод предполагает, что правила миграции объектов между базами одинаковы для всех периферийных узлов. Если у вас есть объекты, которые мигрируют по особым правилам (например, "место создания и центр" для некоторых документов, а для других только "место создания"), вам может потребоваться дополнительный контроль или очистка этих специфичных данных в новой ПБ, если она создается на основе другой, уже существующей периферийки с другими правилами.
Если у вас уже есть проверенная обработка для свертки информационной базы, мы можем использовать ее потенциал для более эффективного создания "чистых" периферийных баз. Этот подход особенно актуален, если мы хотим, чтобы все периферийные базы начинали свою работу с одинаково свернутых, актуальных данных.
Разберем процесс:
Убедимся, что наша Центральная База свернута корректно и неоднократно проверена. Это будет нашим идеальным "шаблоном" для всех новых периферийных баз. Если Центральная База не свернута, то имеет смысл сначала свернуть ее. Также важно провести полную синхронизацию всех текущих баз (ЦБ-ПБ-ЦБ) перед этим процессом, чтобы все данные были актуальны.
В нашу существующую обработку свертки ИБ мы внесем важное изменение. Перед каждым изменением данных (например, при создании документов ввода остатков, корректировке справочников и т.д.) мы будем вызывать метод .РегистрацияИзменений(0);. Этот метод указывает системе УРБД, что текущие изменения не нужно регистрировать для обмена, поскольку они являются частью внутренней операции свертки. Это позволяет выполнять массовые изменения без создания огромного количества записей в таблицах обмена.
Пример (псевдокод):
// В обработке свертки, перед записью объекта, который НЕ должен попасть в обмен:
ДокВводаОстатков = СоздатьОбъект("Документ.ВводОстатков");
// ... заполнение документа ...
ДокВводаОстатков.РегистрацияИзменений(0); // Отключаем регистрацию для обмена
ДокВводаОстатков.Записать();
СпрЭлемент = СоздатьОбъект("Справочник.Товары");
// ... изменение реквизитов элемента ...
СпрЭлемент.РегистрацияИзменений(0); // Отключаем регистрацию для обмена
СпрЭлемент.Записать();
Этот подход гарантирует, что свертка пройдет без генерации лишних данных для обмена, а ЦБ и ПБ будут "согласны" по своим свернутым данным без необходимости сложного обмена по свертке.
Мы выполняем модифицированную обработку свертки во всех базах – Центральной и всех Периферийных – параллельно, автономно и в монопольном режиме. Если периферийные базы находятся на медленных серверах, мы можем временно перенести их на более производительный сервер, провести свертку и затем вернуть обратно. Это значительно экономит время и минимизирует количество обменов, которые пришлось бы проводить для синхронизации свернутых данных.
В результате мы получаем свернутые и корректные данные во всех базах, не прибегая к монструозным процессам выгрузки/загрузки или сложным операциям по очистке системных файлов УРБД в каждой новой ПБ. Этот метод также предотвращает потерю немигрирующих данных в периферийках, так как свертка происходит "на месте".
Преимущества подхода:
Скорость: Параллельная свертка значительно сокращает общее время, необходимое для подготовки всех баз.
Надежность: Свертка происходит внутри каждой базы, что минимизирует риски, связанные с миграцией данных или некорректной настройкой обмена.
Актуальность: Все базы начинают работать с одинаково свернутыми и актуальными данными.
Минимизация обменов: Благодаря использованию .РегистрацияИзменений(0);, объем данных, подлежащих обмену после свертки, значительно сокращается или становится нулевым.
Независимо от выбранного метода создания и клонирования баз, всегда полезно уделять внимание оптимизации регистров. "Распухшие" регистры могут существенно замедлять работу системы, особенно в условиях УРБД.
Регистры, такие как "Заявки" и "Резервы", имеют свойство быстро накапливать данные. Если заявки или резервы теряют актуальность, их необходимо регулярно закрывать. Незакрытые, "мертвые" записи продолжают участвовать в расчетах и формировании итогов, увеличивая нагрузку на базу данных.
Даже после закрытия, старые итоги могут оставаться в регистрах, но дальнейшие операции и пересчеты будут выполняться быстрее за счет уменьшения количества актуальных записей.
В некоторых случаях, если исторические данные определенных регистров (например, "Заявки" или других регистров накопления RA*.* или расчетов RG*.*) не являются критически важными для длительного хранения и их можно переформировать с нуля, мы можем рассмотреть радикальный шаг – полное удаление соответствующих файлов DBF и CDX для этих регистров. Например, удалить RAxxxx.DBF и RAxxxx.CDX для регистра "Заявки".
После удаления файлов, при монопольном запуске базы и выполнении пересчета итогов, 1С создаст регистры заново, но уже с минимальным набором актуальных данных. Этот шаг требует очень тщательного анализа, чтобы не потерять важную информацию.
Регистр партий в 1С 7.7 тесно связан с приходными документами. Если при свертке базы мы изменяем ссылки на приходные документы (например, заменяя их на единый документ ввода остатков), это может вызвать сложности в УРБД. При обмене, если периферийные базы продолжают ссылаться на старые приходные документы, а Центральная База уже имеет новые ссылки от свертки, возникнет конфликт.
Мы должны быть готовы к адаптации правил миграции для документов, формирующих движения по партиям, или к дополнительной обработке данных, чтобы ссылки на приходные документы были согласованы во всех узлах после свертки и первичного обмена.
В заключение, выбор метода клонирования и создания новых периферийных баз зависит от вашей конкретной ситуации, размера базы, сложности конфигурации и доступности ресурсов. Метод прямого редактирования файлов УРБД является быстрым, если у вас есть свернутая ЦБ, а метод модификации свертки обеспечивает более контролируемый и надежный процесс для большого количества узлов. В любом случае, мы должны помнить о необходимости тщательного тестирования и резервного копирования перед внедрением любых изменений в рабочие базы.