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

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

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

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

Что именно происходит при реструктуризации

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

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

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

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

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

Окно реструктуризации появляется при изменениях, влияющих на хранение данных:

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

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

Подготовка: что сделать до запуска

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

Второе условие — монопольный доступ. Все пользователи должны выйти из базы, фоновые задания и соединения — завершены. В клиент-серверном режиме проверьте консоль кластера: зависшие сеансы блокируют обновление даже при закрытых окнах 1С у пользователей.

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

1. 1
   Создайте резервную копию и убедитесь, что она читается
2. 2
   Завершите все сеансы пользователей и фоновые задания
3. 3
   Откройте конфигуратор, выполните «Обновить конфигурацию базы данных» (F7)
4. 4
   Изучите список реструктуризации: найдите удаления и изменения типов
5. 5
   Запустите процесс и дождитесь завершения, не прерывая его
6. 6
   Проверьте работу базы: откройте ключевые документы, отчеты, справочники

Разбор списка реструктуризации: на что смотреть

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

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

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

Особенности для файловых и клиент-серверных баз

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

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

Если база участвует в обменах (РИБ, синхронизации), обновляйте узлы в правильной последовательности и не запускайте обмен, пока реструктуризация не завершена на всех узлах, где она требуется.

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

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

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

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

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

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

Список реструктуризации после обновления

Норма

Повторный запуск F7 не показывает изменений

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

Изменения остались — обновление не применилось

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

Норма

Очередь выполнена без ошибок

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

Есть зависшие или завершившиеся ошибкой обработчики

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

Норма

Значения реквизитов на месте, отчеты сходятся

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

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

Журнал регистрации

Норма

Нет ошибок за период обновления

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

Ошибки обновления или фоновых заданий

Что делать, если реструктуризация зависла или упала

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

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

Если база после сбоя не открывается или ведет себя некорректно — не пытайтесь «лечить» ее повторными обновлениями. Разверните резервную копию в отдельном каталоге, разберитесь с причиной сбоя на копии и только потом повторяйте процедуру на рабочей базе.

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

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

В списке только добавление новых объектов и реквизитовМожно обновлять штатно, риск минимален

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

Есть удаление объектов с даннымиУбедитесь, что данные перенесены обработчиками или не нужны

База большая и обновление тяжелоеПланируйте на нерабочее время и репетируйте на копии

Реструктуризация упала с ошибкойНе перезапускайте вслепую — найдите причину в логах

Частые вопросы

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

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

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

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

Нужна ли реструктуризация при обновлении платформы 1С?

Как правило, нет. Обновление платформы меняет исполняемые файлы, а не структуру метаданных. Реструктуризация требуется при изменении конфигурации. Исключения редки и описываются в документации к конкретному релизу платформы.

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

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

Что будет, если при изменении типа реквизита часть значений не подходит?

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

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

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