Когда происходит реструктуризация 1С и как пройти её без потерь

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

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

Понимание того, в какие моменты срабатывает этот механизм и что именно он делает с данными, помогает правильно планировать обновления, оценивать время простоя и не паниковать, когда процесс занимает больше времени, чем ожидалось. Ниже разобраны все типовые ситуации запуска реструктуризации, её этапы, риски и способы проверить результат.

Что такое реструктуризация и зачем она нужна

Конфигурация 1С описывает структуру данных логически: какие есть справочники, документы, регистры, какие у них реквизиты и какого они типа. Физически эти данные хранятся в таблицах СУБД (в клиент-серверном варианте — MS SQL Server, PostgreSQL и др.) или в файле 1Cv8.1CD в файловом варианте. Пока логическое описание и физическая структура совпадают, база работает штатно.

Как только разработчик или поставщик обновления меняет метаданные — например, добавляет в документ «Реализация товаров» новый реквизит — возникает рассинхронизация. Таблица в базе не содержит нужной колонки, и платформа не может работать с новой версией конфигурации, пока не приведёт физическую структуру в соответствие. Это приведение и есть реструктуризация.

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

В каких ситуациях запускается реструктуризация

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

Реструктуризация потребуется в следующих случаях:

• добавление или удаление реквизитов, табличных частей, измерений, ресурсов и реквизитов регистров;
• изменение типа данных реквизита (например, строка стала ссылкой на справочник) или длины строки, точности числа;
• добавление или удаление объектов метаданных целиком — новых справочников, документов, регистров;
• изменение состава индексов, признаков ведения учета по измерениям, режимов итогов регистров;
• изменение длины кода или наименования справочника, номера документа;
• изменение состава планов обмена (добавление объектов в состав подписки).

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

Что происходит во время реструктуризации: этапы процесса

После подтверждения обновления конфигурации базы данных платформа последовательно обрабатывает изменённые объекты. Для каждого объекта выполняется типовой набор операций: создаётся новая таблица с целевой структурой, данные переносятся из старой таблицы в новую, старая таблица удаляется, новая переименовывается, перестраиваются индексы. В клиент-серверном варианте всё это выполняется средствами СУБД.

Порядок обработки объектов платформа выбирает сама с учётом зависимостей. На окне прогресса видно, какой объект обрабатывается в данный момент. Именно поэтому реструктуризация большого регистра накопления с сотнями миллионов записей может занять часы, а вся остальная база — минуты.

1. 1
   Администратор запускает обновление конфигурации базы данных в монопольном режиме
2. 2
   Платформа анализирует различия метаданных и показывает список изменений структуры
3. 3
   Администратор подтверждает изменения, принимая предупреждения о возможной потере данных
4. 4
   Платформа последовательно перестраивает таблицы: создаёт новые, переносит данные, удаляет старые
5. 5
   Пересоздаются индексы и служебные структуры
6. 6
   По завершении выполняются обработчики обновления данных (если предусмотрены релизом)
7. 7
   База открывается для пользователей, администратор проверяет результат

Отдельный этап, который часто путают с реструктуризацией, — обработчики обновления данных. Это программный код поставщика конфигурации, который заполняет новые реквизиты, переносит данные между объектами, пересчитывает служебные регистры. Он выполняется уже после реструктуризации и тоже может занимать значительное время. В типовых конфигурациях часть обработчиков откладывается и выполняется в фоне после запуска базы.

Сколько длится реструктуризация и от чего зависит время

Длительность реструктуризации определяется прежде всего объёмом данных в затрагиваемых таблицах и характером изменений. Добавление реквизита в маленький справочник займёт секунды, а изменение структуры регистра накопления с годами накопленных движений — часы. Точное время предсказать нельзя, его можно только оценить на копии базы.

На скорость влияют несколько факторов:

• объём таблиц, подлежащих перестройке, и количество индексов на них;
• тип изменений: добавление колонки обычно быстрее, чем изменение типа с полным перекопированием данных;
• производительность сервера СУБД: дисковая подсистема, объём оперативной памяти, настройки;
• размер и скорость роста журнала транзакций в клиент-серверном варианте;
• для файловых баз — скорость диска и отсутствие антивирусной проверки каталога базы в реальном времени.

Перед плановым обновлением рабочей базы выполните тестовое обновление на её копии и засеките время реструктуризации. Это единственный надёжный способ спланировать окно простоя: оценка «на глаз» на больших базах ошибается в разы.

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

Риски и как подготовиться к реструктуризации

Главный риск реструктуризации — прерывание процесса: отключение электричества, перезагрузка сервера, нехватка места на диске, обрыв соединения с СУБД. В файловом варианте прерванная реструктуризация часто делает базу неоткрываемой, и восстановление возможно только из резервной копии или через тестирование и исправление без гарантий. В клиент-серверном варианте СУБД обычно откатывает незавершённую транзакцию, но и здесь сбои случаются.

Второй риск — потеря данных по предупреждениям, которые администратор принял не читая. Если обновление удаляет реквизит, в котором хранились нужные сведения, после реструктуризации данные исчезнут безвозвратно. Поэтому список изменений структуры нужно изучать, а не подтверждать механически.

Подготовительные меры, которые стоит выполнить всегда:

• сделать резервную копию и убедиться, что она восстанавливается;
• проверить свободное место на диске — при перестройке больших таблиц может потребоваться объём, сопоставимый с размером самих таблиц, плюс место под журнал транзакций;
• завершить сеансы пользователей и отключить регламентные задания;
• провести тестовое обновление на копии и зафиксировать время;
• обеспечить бесперебойное питание сервера на время процедуры.

Как проверить, что реструктуризация прошла успешно

После завершения процесса конфигуратор не всегда сообщает обо всех проблемах явно. Минимальная проверка — открыть базу в режиме предприятия, убедиться, что отрабатывают обработчики обновления (в типовых конфигурациях виден прогресс обновления версии), и открыть ключевые документы и отчёты.

Контрольные точки

Как проверить результат

Запуск базы в режиме предприятия

Норма

База открывается, версия конфигурации соответствует новому релизу

Тревожный признак

Ошибки при запуске, сообщения о несоответствии версии конфигурации и базы данных

Отложенные обработчики обновления

Норма

Все обработчики выполнены, очередь пуста

Тревожный признак

Обработчики зависли с ошибками, прогресс не движется

Данные в изменённых объектах

Норма

Записи на месте, новые реквизиты заполнены или доступны

Тревожный признак

Пропали данные, документы не открываются с ошибкой

Журнал регистрации и логи СУБД

Норма

Нет ошибок за период реструктуризации

Тревожный признак

Ошибки нехватки места, обрывов, взаимоблокировок

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

Типичные ошибки администраторов

Отдельная группа ошибок связана с файловыми базами, размещёнными на сетевых дисках. Реструктуризация такой базы по сети идёт медленно и критична к обрывам связи. Правильный подход — скопировать базу на локальный диск, выполнить обновление локально и вернуть на место.

Частые вопросы о реструктуризации 1С

Можно ли обновить конфигурацию без реструктуризации?

Да, если изменения не затрагивают структуру хранения: правки модулей, форм, макетов, ролей применяются без перестройки таблиц. Но если платформа определила изменения структуры, избежать реструктуризации нельзя — это обязательный этап обновления конфигурации базы данных.

Что делать, если реструктуризация идёт уже несколько часов?

Сначала убедитесь, что процесс реально работает: в клиент-серверном варианте проверьте активные запросы на сервере СУБД, в файловом — рост временных файлов и загрузку диска. Если активность есть — ждите. Снимать задачу допустимо только при полном отсутствии активности и наличии резервной копии.

Почему платформа предупреждает о возможной потере данных?

Предупреждение появляется при удалении реквизитов, сужении типов или уменьшении длины строк: существующие значения могут не поместиться в новую структуру и будут утеряны. Перед подтверждением выгрузите затрагиваемые данные или убедитесь, что они не нужны.

Можно ли выполнять реструктуризацию при работающих пользователях?

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

Чем реструктуризация отличается от тестирования и исправления?

Реструктуризация приводит структуру таблиц в соответствие с конфигурацией и выполняется при обновлении. Тестирование и исправление — диагностическая утилита для поиска и устранения ошибок в данных и структуре уже работающей базы. Это разные механизмы, и заменять один другим нельзя.

Нужна ли реструктуризация после загрузки файла .dt?

Нет. При загрузке выгрузки информационной базы структура данных восстанавливается целиком из файла вместе с конфигурацией базы данных. Реструктуризация требуется только при расхождении метаданных конфигурации и физической структуры существующей базы, а при загрузке .dt база создаётся заново.