Как ускорить загрузку номенклатуры и решить проблему зависания реструктуризации в УРБД 1С 7.7

При работе с распределенными информационными базами (УРБД) в 1С 7.7 администраторы часто сталкиваются с ситуацией, когда масштабные изменения в структуре справочника «Номенклатура» (например, добавление реквизита и заполнение его для 50 000+ элементов) приводят к фактической остановке работы периферийных точек. Стандартная загрузка через файл обмена может длиться десятки часов или зависать на этапе реструктуризации файлов DBF. Рассмотрим подробно, как выйти из этой ситуации и запустить работу системы в кратчайшие сроки.

Причина возникновения проблемы

Проанализируем ситуацию: в центральной базе (SQL) проведена реструктуризация, добавлен новый ссылочный реквизит, и данные обновлены для всего справочника. При выгрузке в периферийную базу (DBF) система пытается одновременно обновить структуру таблиц и записать огромный массив данных. Основные «тормоза» возникают из-за:

1. Объема индексного файла (CDX): В 1С 7.7 для DBF существует ограничение на размер ключа индекса (около 117–120 байт). Если новые реквизиты включены в индексы (сортировка/отбор), файл .cdx растет лавинообразно, замедляя запись.
2. Построчной реструктуризации: Система создает временную таблицу, копирует туда данные, что при больших объемах (55 000 элементов и более) на медленных дисках занимает часы.
3. Регистрации изменений: Огромная таблица _1supdts в центре заставляет систему постоянно обращаться к диску при формировании и приеме пакетов.

Способ 1. Метод «ручного» обновления периферийных точек

Если стандартный обмен завис, наиболее эффективным решением будет подготовка «эталонной» периферийной базы и копирование её файлов на остальные точки. Разберем по шагам этот алгоритм:

1. Подготовка эталона: Добейтесь успешной загрузки данных хотя бы на одной периферийной базе (например, на мощном сервере локально).
2. Копирование структуры: Возьмите из этой базы обновленные файлы метаданных 1cv7.md и 1cv7.dd.
3. Копирование данных: Найдите файл, отвечающий за справочник «Номенклатура». Обычно это SC*.dbf (например, SC84.dbf) и соответствующий ему индексный файл SC*.cdx.
4. Важный нюанс: Если в справочнике есть реквизиты типа «Строка неограниченной длины», необходимо также скопировать файл 1SBlob.dbf, где хранятся эти значения.
5. Распространение: На всех остальных точках (при закрытой 1С) замените указанные файлы. Это позволит избежать долгой процедуры реструктуризации на каждой точке по отдельности.

Внимание: После ручной подмены файлов необходимо «обмануть» систему обмена, чтобы она не пыталась загрузить эти же данные повторно через стандартный механизм.

Способ 2. Очистка регистрации изменений в центральной базе

Чтобы исключить повторную передачу огромного справочника после того, как вы обновили точки вручную, нужно очистить таблицу регистрации изменений _1supdts в центральной SQL-базе. Рассмотрим, как это сделать с помощью SQL-запроса через Query Analyzer или аналогичные инструменты.

Выясним внутренний идентификатор типа справочника «Номенклатура» (его можно посмотреть в файле 1cv7.dd). Допустим, это идентификатор типа в 36-ричном виде. В SQL таблице _1supdts поле TYPEID может быть представлено в виде целого числа (int). Выполним следующие действия:

-- Рекомендуется сначала сохранить данные в резервную таблицу
SELECT * INTO Nomenclature_Backup_2023 
FROM _1supdts 
WHERE typeid = [ID_вашего_справочника];

-- Удаление регистрации изменений для справочника Номенклатура
DELETE FROM _1supdts 
WHERE typeid = [ID_вашего_справочника];

-- Также полезно очистить регистрацию изменений самой конфигурации (MD), 
-- если вы обновили её на точках вручную
DELETE FROM _1supdts WHERE typeid = 0 AND objid = 0;

Проанализируем ситуацию после выполнения запроса: теперь при следующем обмене центральная база «считает», что номенклатура на точках уже актуальна, и файл обмена будет иметь минимальный размер.

Способ 3. Исправление проблем с иерархией («битые ссылки»)

Часто после форсированной загрузки пользователи жалуются, что в справочнике видна только одна папка или элементы отображаются некорректно. Это происходит из-за нарушения связей ParentID (родительских групп). Рассмотрим, как это исправить:

• Перезапись в центре: В центральной базе программно пройдите по всем группам справочника «Номенклатура» и выполните метод Записать(). Это создаст новые записи в таблице регистрации изменений именно для групп.
• Повторный обмен: Выгрузите эти изменения на точки. Поскольку групп значительно меньше, чем элементов, обмен пройдет быстро, а иерархия на периферии восстановится.

Технические советы по оптимизации реструктуризации

Если вы все же решили проводить реструктуризацию штатно, воспользуйтесь следующими рекомендациями для ускорения процесса:

1. Отключение Журнала регистрации: Перед загрузкой больших пакетов данных на точках временно отключите регистрацию событий в ЖР.
2. Оптимизация индексов: Проверьте свойства реквизитов справочника. Если у реквизита стоит галочка Сортировка или Отбор по реквизиту, но по факту поиск по нему не используется — снимите эти признаки. Это значительно уменьшит размер .cdx файла и ускорит загрузку.
3. Прямое манипулирование в SQL: Профессиональный метод для SQL-баз — переименование старой таблицы, создание новой пустой структуры через Конфигуратор за 2 секунды, и последующая вставка данных через INSERT INTO ... SELECT. Это в десятки раз быстрее штатной реструктуризации 1С.

Таким образом, комбинируя метод ручной подмены файлов на DBF-точках и адресную очистку таблицы _1supdts в SQL-центре, можно восстановить работоспособность распределенной системы 1С 7.7 всего за пару часов, вместо многодневного ожидания завершения штатных процессов.