Реструктуризация 1С: что это и как пройти её без потери данных

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

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

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

Что происходит с базой во время реструктуризации

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

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

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

Какие изменения конфигурации вызывают реструктуризацию

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

• добавление или удаление реквизитов, измерений, ресурсов у справочников, документов, регистров;
• изменение типа или длины существующего реквизита (например, строка с 50 символов на 150);
• изменение длины кода или наименования справочника, номера документа;
• добавление табличной части или изменение её состава;
• изменение периодичности регистра сведений или режима итогов регистра накопления;
• изменение признаков учёта: длины серии, номера, признака «Субконто» у счёта;
• удаление объектов метаданных, содержащих данные.

Особого внимания заслуживает сужающее изменение: уменьшение длины строки, смена типа на несовместимый, удаление реквизита. Платформа предупредит, что данные могут быть потеряны, и потребует подтверждения. Если в поле «Комментарий» длиной 1000 символов у части контрагентов реально записаны длинные тексты, сокращение поля до 100 символов обрежет эти данные безвозвратно.

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

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

1. 1
   Сделайте резервную копию: выгрузку в dt через конфигуратор или копию средствами СУБД для клиент-серверной базы
2. 2
   Завершите работу всех пользователей и отключите регламентные задания
3. 3
   Убедитесь, что на диске достаточно свободного места — ориентировочно объём, сопоставимый с размером базы
4. 4
   Откройте базу в конфигураторе в монопольном режиме
5. 5
   Выполните «Обновить конфигурацию базы данных» и внимательно изучите окно изменений
6. 6
   Подтвердите реструктуризацию и дождитесь полного завершения, не прерывая процесс
7. 7
   Проверьте работоспособность базы и ключевые отчёты до запуска пользователей

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

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

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

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

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

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

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

Частые ошибки и что делать при сбое

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

Если реструктуризация всё же прервалась, не пытайтесь сразу открыть базу в режиме предприятия или повторно запустить обновление. Правильная последовательность: восстановите базу из резервной копии, устраните причину сбоя (место на диске, стабильность питания, повреждения файла) и только потом повторите обновление.

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

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

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

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

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

Открытие базы в режиме предприятия

Норма

База открывается без сообщений об ошибках структуры

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

Ошибки формата потока, несоответствия метаданных, падение клиента

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

Норма

Значения реквизитов на месте, списки открываются, поиск работает

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

Пустые поля, обрезанные строки, пропавшие записи

Отчёты по регистрам

Норма

Итоги сходятся с данными до обновления (по сохранённым отчётам)

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

Расхождения в остатках и оборотах

Тестирование и исправление

Норма

Проверка логической и ссылочной целостности завершается без ошибок

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

Битые ссылки, ошибки индексов

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

Когда реструктуризацию лучше поручить специалисту

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

Маршрут решения

Как выбрать действие

Типовая конфигурация, файловая база, обновление на один релиз, есть копияМожно обновить самостоятельно по стандартной инструкции

Конфигурация доработана или снята с полной поддержкиСначала сравнение и объединение с анализом изменений — лучше привлечь разработчика

Клиент-серверная база большого объёма с круглосуточной работойПланируйте обновление с администратором СУБД и репетицией на копии

Пропущено несколько релизов обновленийСверьтесь с порядком обновления от поставщика и выполняйте переход последовательно

Реструктуризация уже завершилась с ошибкойНе экспериментируйте с рабочей базой — восстановите копию и разбирайте причину

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

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

Можно ли отменить реструктуризацию после её завершения?

Нет, штатной отмены не существует. Откат возможен только одним способом — восстановлением базы из резервной копии, сделанной до обновления. Именно поэтому копия обязательна, даже если изменение кажется незначительным.

Почему реструктуризация зависла на одном объекте и что делать?

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

Теряются ли данные при реструктуризации?

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

Нужна ли реструктуризация при каждом обновлении типовой конфигурации?

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

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

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

Можно ли работать пользователям, пока идёт реструктуризация?

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