← На главную

При администрировании и разработке в системе 1С:Предприятие разработчики регулярно сталкиваются с необходимостью переноса доработок между базами. Для этого используются два штатных механизма Конфигуратора: «Загрузить конфигурацию из файла...» и «Сравнить, объединить с конфигурацией из файла...». На первый взгляд может показаться, что если перенести один и тот же файл .cf, результат для структуры базы данных будет одинаковым. Однако это заблуждение, способное привести к потере данных, разрушению связей в РИБ или ошибкам в таблицах индексов. Разберем детально, как работают эти механизмы под капотом платформы 1С.

1. Разница механизмов сопоставления объектов метаданных

Проанализируем ключевое архитектурное отличие, которое определяет поведение базы при обновлении:

1. «Загрузить конфигурацию из файла» — операция полной замены основной конфигурации. В этом режиме сопоставление объектов метаданных происходит строго по их внутренним идентификаторам (UUID). Если в файле поставщика реквизит был переименован (но его внутренний идентификатор остался прежним), платформа понимает, что это тот же самый объект. При обновлении конфигурации базы данных колонка в таблице СУБД просто сменит имя, а данные внутри неё сохранятся.
2. «Сравнить, объединить с конфигурацией из файла» — интерактивный режим сопоставления. По умолчанию алгоритм сравнения сопоставляет объекты метаданных по их именам (идентификаторам в дереве метаданных), а не по внутренним UUID. Если в источнике имя реквизита изменилось, механизм посчитает, что старый реквизит удален, а новый создан. Если согласиться с таким объединением, старая колонка в СУБД со всеми данными будет удалена, а новая колонка создана пустой. Кроме того, всем новым объектам, добавленным через сравнение/объединение, присваиваются новые внутренние идентификаторы в контексте текущей информационной базы.

Рассмотрим практическое следствие: если развивать две одинаковые базы параллельно и обновлять их только через сравнение и объединение, их метаданные со временем разойдутся по внутренним UUID. В дальнейшем объединить такие базы в распределенную информационную базу (РИБ) будет крайне сложно, так как РИБ требует абсолютной идентичности структуры и внутренних идентификаторов метаданных.

2. Как изменения применяются к конфигурации базы данных

Важно понимать двухэтапность процесса внесения изменений. Все действия («Загрузить» или «Сравнить/объединить») изменяют только основную конфигурацию (ту, которую мы редактируем в дереве метаданных). Реальное изменение таблиц СУБД происходит только в момент выполнения команды «Обновить конфигурацию базы данных» (клавиша F7).

На этапе обновления конфигурации БД платформа 1С ВСЕГДА сопоставляет основную конфигурацию и конфигурацию базы данных по внутренним UUID. Если вы случайно удалили реквизит из основной конфигурации и тут же создали новый с точно таким же именем, типом и длиной — для платформы это совершенно другой объект. При обновлении БД колонка старого реквизита физически удалится из таблицы, а для нового реквизита создастся новая пустая колонка. Чтобы избежать случайной потери данных, всегда можно воспользоваться командой «Конфигурация — Вернуться к конфигурации БД», которая заново перечитывает состояние метаданных из базы данных.

3. Влияние на индексирование таблиц базы данных

Выясним причину, почему после загрузки конфигурации могут возникать ошибки чтения данных, требующие реиндексации таблиц базы данных. Напрямую сама кнопка загрузки индексы не ломает, однако процедура накатывания изменений провоцирует глубокую реструктуризацию:

1. Неявная реструктуризация таблиц и индексов. В отличие от точечного объединения, операция «Загрузить конфигурацию» перезаписывает абсолютно все свойства объектов. Если в загружаемом файле хотя бы у одного реквизита документа изменились свойства Индексировать, Индексировать с доп. упорядочиванием, изменился состав измерений регистров или признак Ведущее, платформа принудительно запускает перестроение индексов для всей таблицы. В файловых базах .1CD таблица при реструктуризации пересоздается целиком вместе с индексными страницами B-Tree.
2. Сбои в момент реструктуризации. Если в момент обновления базы данных происходят сбои питания, блокировки антивирусного ПО, скачки дисковой подсистемы или таймауты СУБД, физический индекс таблицы может остаться в несогласованном или поврежденном состоянии. Документ или список перестает открываться с ошибками чтения записей, пока не будет выполнена полная реиндексация.
3. Индексы полнотекстового поиска (ППП). Если конфигурация была загружена с измененными настройками полнотекстового поиска для объекта, стандартные динамические списки форм могут выдавать необъяснимые ошибки при открытии. Это связано с тем, что индекс полнотекстового поиска не соответствует обновленной структуре данных и требует принудительного обновления.

4. Как безопасно контролировать изменения и устранять сбои

Разберем по шагам правила безопасной работы и способы восстановления индексов, если после обновления возникли ошибки:

1. Контроль перед обновлением БД. Если вы использовали команду «Загрузить конфигурацию», перед нажатием F7 обязательно запустите процедуру «Конфигурация — Сравнить конфигурации». В качестве первой выберите основную конфигурацию, в качестве второй — конфигурацию базы данных. Обязательно снимите флаг «Устанавливать соответствие по именам объектов». В таком режиме сравнение пройдет быстро по UUID и покажет реальный список реструктурируемых таблиц и полей.
2. Восстановление индексов через Конфигуратор. При появлении плавающих ошибок чтения объектов после обновления запустите процедуру «Администрирование — Тестирование и исправление...». Установите единственный флаг «Реиндексация таблиц информационной базы». Платформа принудительно пересоздаст все системные индексы таблиц в соответствии с актуальными метаданными.
3. Восстановление файловых баз. Если база работает в файловом режиме (файл 1Cv8.1CD), перед открытием Конфигуратора рекомендуется выполнить диагностику утилитой chdbfl.exe, расположенной в каталоге bin установленной платформы 1С. Она устраняет повреждения ссылочной целостности страниц и дерева индексов.
4. Обслуживание на уровне СУБД. В клиент-серверном варианте (MS SQL Server, PostgreSQL) сбои устраняются регламентными операциями перестроения индексов (REBUILD INDEX) и обязательным обновлением статистики распределения данных (UPDATE STATISTICS / ANALYZE) для таблиц документов и их табличных частей.