← На главную

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

Удаление записей из таблицы 1CUPDTS в многопользовательском режиме

Таблица 1CUPDTS (в SQL-версии) или файл 1CUPDTS.DBF отвечают за хранение ссылок на объекты, которые были изменены и подлежат выгрузке в другие узлы распределенной базы. Рассмотрим ситуацию, когда необходимо программно удалить лишние записи из этой таблицы, используя прямой запрос через ODBCRecordset или аналогичные инструменты.

Анализ рисков и блокировок:

Многие разработчики опасаются конфликтов при выполнении команды DELETE, когда в базе активно работают пользователи. Проанализируем механику работы платформы: штатные средства 1С при проведении документов или записи элементов справочников также обращаются к этой таблице для регистрации изменений. Однако, как показывает практика эксплуатации SQL-версий, выполнение точечных запросов на удаление по условию (например, по идентификатору записи) не вызывает критических конфликтов.

Рассмотрим причины, почему это безопасно:

1. Транзакционность SQL: Современные СУБД эффективно управляют блокировками на уровне строк. Пока выполняется DELETE одной записи, другие процессы могут спокойно вставлять новые строки (INSERT).
2. Аналогия со штатными механизмами: При обычной отмене проведения документа 1С сама инициирует удаление записей из соответствующих таблиц движений и регистрацию изменений. Прямой запрос через ODBC действует аналогичным образом.
3. Автоматическое обслуживание индексов: В SQL-версии индексы перестраиваются сервером автоматически, что минимизирует риск повреждения структуры таблицы при параллельном доступе.

Важная рекомендация: Несмотря на относительную безопасность, при массовом удалении (десятки тысяч строк) рекомендуется выполнять операцию пакетами по 500-1000 записей в цикле с небольшими паузами. Это предотвратит чрезмерное разрастание лога транзакций и исключит вероятность эскалации блокировок до уровня всей таблицы.

Быстрое создание периферийной базы: Клонирование вместо выгрузки

Создание новой периферийной базы через штатный механизм «Выгрузить данные» в Конфигураторе может занимать колоссальное количество времени. Если объем базы составляет десятки гигабайт, процесс может длиться днями или вовсе прерываться ошибками. Опытные специалисты используют метод клонирования. Разберем этот алгоритм по шагам.

Вместо того чтобы ждать формирования огромного .dat файла, мы берем полную копию Центральной Базы (ЦБ) и «превращаем» её в периферийную путем правки системных таблиц.

Шаг 1: Подготовка в Центральной Базе

Сначала в Конфигураторе Центральной Базы создаем новый узел УРБД (если он еще не создан). Нам необходимо зафиксировать трехсимвольный код этой базы (например, P01). После этого база готова к взаимодействию, но нам нужно настроить саму копию.

Шаг 2: Изменение статуса базы в таблице _1SDBSET

В системе 1С 7.7 за настройки распределенной базы отвечает таблица _1SDBSET. Нам нужно изменить в ней значения полей, чтобы копия базы осознала себя как «периферийная».

Проанализируем необходимые изменения:

• Найдем строку, соответствующую Центральной Базе (обычно DBSIGN = '000' или 'ЦБ').
• Установим для неё DBSTATUS = 'P' (статус родительской базы для периферийки).
• Найдем строку, соответствующую созданной периферийной базе (наш код P01).
• Установим для неё DBSTATUS = 'M' (Main — текущая база) и DBFMODE в соответствующее значение (обычно разрешающее изменения конфигурации).

Шаг 3: Настройка идентификатора в таблице _1SSYSTEM

Таблица _1SSYSTEM содержит глобальный идентификатор текущей информационной базы. Выясним, что нужно изменить:

Поле DBSIGN в этой таблице должно строго соответствовать коду периферийной базы, который мы задали в ЦБ. Если в копии там стоит код центра (например, '000'), меняем его на 'P01'. Это ключевой момент, по которому 1С понимает, кто она в иерархии обменов.

Шаг 4: Очистка регистрации изменений

Поскольку мы клонировали базу из Центральной, в таблице 1CUPDTS (или 1CUPDTS.DBF) остались записи о регистрации изменений для всех остальных узлов. Если их не очистить, периферийная база при первом же обмене попытается отправить в центр данные, которые там и так есть.

Необходимо выполнить запрос:

DELETE FROM 1CUPDTS;

Это обеспечит «чистый старт» для новой базы.

Особенности работы с большими базами в формате DBF

Если ваша база работает в формате DBF и её объем приближается к 10-20 Гб, вы находитесь в зоне риска. Разберем основные проблемы:

1. Лимит 2 Гб: В 1С 7.7 размер любого отдельного файла таблицы (.dbf) не может превышать 2 Гб. Чаще всего этот порог первым преодолевает файл итогов или движений регистров.
2. Индексация: Пересчет итогов и переиндексация на больших объемах в DBF крайне медленны. Использование прямых запросов или клонирования позволяет избежать лишних запусков монопольного режима.
3. Редактирование таблиц: Для выполнения описанного выше алгоритма в DBF-версии вам понадобятся внешние утилиты для редактирования таблиц (например, DBF Viewer или специализированные обработки 1С).

Заключение: Использование прямого доступа к таблицам базы данных (SQL или DBF) — это мощный инструмент в руках администратора 1С 7.7. Удаление записей из 1CUPDTS в многопользовательском режиме вполне допустимо, а ручное клонирование баз УРБД является стандартом де-факто для крупных внедрений, позволяя избежать временных затрат на штатные выгрузки.