Администрирование · 12 мин
Реструктуризация в 1С: что она делает и как пройти её без потерь
Что делает реструктуризация в 1С, когда она запускается, чем опасна и как подготовиться: резервная копия, тестирование, проверка результата и типичные ошибки.
Реструктуризация в 1С — это процедура, при которой платформа изменяет физическую структуру таблиц базы данных в соответствии с изменённой конфигурацией. Она запускается автоматически при обновлении конфигурации базы данных, если в метаданных появились отличия от текущей структуры: добавлены или удалены реквизиты, справочники, документы, регистры, изменены типы и длины полей. Проще говоря, платформа приводит реальные таблицы в соответствие с тем, что описал разработчик.
Для пользователя реструктуризация выглядит как окно со списком изменений и кнопкой «Принять». Пока процесс идёт, база недоступна для работы, а на больших объёмах данных процедура может занимать от нескольких минут до многих часов. Именно поэтому к реструктуризации нельзя относиться как к формальности: ошибка или прерывание посередине способны оставить базу в неработоспособном состоянии.
Понимание того, что именно делает платформа на этом этапе, помогает правильно подготовиться: снять резервную копию, выбрать время обновления, оценить длительность и проверить результат. Ниже разобраны механика процесса, условия безопасного запуска, типичные ошибки и способы проверки базы после завершения.
Что именно делает реструктуризация на уровне базы данных
Когда разработчик добавляет в конфигурацию новый реквизит документа, платформа должна создать соответствующую колонку в таблице базы данных. Когда реквизит удаляется — колонка удаляется вместе с данными. При изменении типа поля, например со строки на число или при увеличении длины строки, платформа создаёт новую структуру и переносит в неё существующие значения с преобразованием.
Для тяжёлых изменений типа платформа фактически создаёт новую таблицу, копирует в неё данные из старой с преобразованием значений, удаляет старую таблицу и переименовывает новую. Именно поэтому на больших таблицах — например, на регистрах накопления с миллионами записей — реструктуризация занимает много времени и требует свободного места на диске: на время процедуры данные существуют в двойном объёме.
Также реструктуризация создаёт таблицы для новых объектов метаданных: справочников, документов, регистров сведений и накопления, перечислений, планов обмена. Если объект удалён из конфигурации, его таблицы удаляются из базы вместе со всеми накопленными данными — восстановить их после принятия изменений без резервной копии невозможно.
Когда запускается реструктуризация и как это выглядит
Процедура стартует автоматически в момент обновления конфигурации базы данных: через конфигуратор («Конфигурация — Обновить конфигурацию базы данных»), при установке типового обновления через поддержку или при загрузке конфигурации из файла. Если изменений в структуре нет, реструктуризация не выполняется, и обновление проходит почти мгновенно.
Перед стартом платформа показывает окно «Реорганизация информации» со списком изменений: какие объекты будут добавлены, изменены или удалены. Это последняя точка, где можно отказаться без последствий. После нажатия «Принять» откат возможен только восстановлением из резервной копии.
Во время выполнения в конфигураторе отображается индикатор прогресса. В клиент-серверном варианте работа идёт на стороне СУБД, в файловом — непосредственно с файлом базы. В обоих случаях сеансы пользователей должны быть завершены: при монопольном обновлении платформа сама попросит завершить работу пользователей или отказаться от обновления.
Подготовка: что сделать до нажатия кнопки «Принять»
Главное условие безопасной реструктуризации — актуальная резервная копия, сделанная непосредственно перед обновлением. Для файловой базы это копия файла 1Cv8.1CD или выгрузка в dt, для клиент-серверной — штатный бэкап средствами СУБД. Копия должна быть проверена на восстановление: бэкап, который никогда не разворачивали, нельзя считать надёжным.
Второе условие — свободное место на диске. При перестроении крупных таблиц платформе требуется пространство, сопоставимое с размером этих таблиц, а в клиент-серверном варианте дополнительно растёт журнал транзакций СУБД. Перед обновлением большой базы стоит убедиться, что запас места есть и на диске с данными, и на диске с логами.
Третье условие — выбор времени. Реструктуризацию большой базы планируют на нерабочие часы: вечер, ночь или выходные. Пользователей предупреждают заранее, сеансы завершают принудительно через консоль кластера или установку блокировки сеансов. Регламентные задания на время обновления отключают, чтобы фоновые процессы не мешали и не обращались к изменяемым таблицам.
- 1Сделайте резервную копию базы и убедитесь, что она восстанавливается
- 2Завершите сеансы пользователей и отключите регламентные задания
- 3Проверьте свободное место на диске с данными и журналами СУБД
- 4Запустите обновление конфигурации базы данных и изучите список изменений
- 5Нажмите «Принять» и дождитесь завершения, не прерывая процесс
- 6Проверьте базу: вход, ключевые документы, отчёты, обмены данными
Динамическое обновление и его ограничения
Платформа умеет выполнять динамическое обновление — без завершения сеансов пользователей. Но этот режим доступен только для ограниченного набора изменений: например, добавления новых объектов, не затрагивающих существующие таблицы. Если изменения требуют перестроения существующих таблиц, платформа откажет в динамическом обновлении и потребует монопольный режим.
После динамического обновления пользователи продолжают работать со старой версией конфигурации в памяти до перезапуска сеанса. Это источник ошибок: код на клиенте и на сервере может различаться, а новые объекты недоступны до перезахода. Поэтому даже после успешного динамического обновления рекомендуется в ближайшее время перезапустить сеансы пользователей.
Для серьёзных релизов с изменением структуры данных динамическое обновление не подходит в принципе. Пытаться «протолкнуть» такое обновление без монопольного доступа — значит получить отказ платформы в лучшем случае и рассинхронизацию работы пользователей в худшем.
Сравнение вариантов обновления
Подходит для любых изменений структуры. Требует завершения всех сеансов и резервной копии, но гарантирует целостный результат.
Подходит только для точечных изменений без перестроения таблиц. Пользователи продолжают работу, но обязаны перезайти в базу.
Подходит для больших баз: реструктуризация отрабатывается на копии, оценивается время, затем процедура повторяется на рабочей базе в выбранное окно.
Сколько длится процесс и от чего зависит время
Длительность реструктуризации определяется объёмом данных в изменяемых таблицах, а не размером конфигурации. Добавление реквизита в редко используемый справочник проходит за секунды, а изменение таблицы регистра накопления с сотнями миллионов записей может занять часы. Точное время заранее предсказать нельзя — его оценивают только опытным путём на копии базы.
На скорость влияют производительность дисковой подсистемы, объём оперативной памяти, настройки СУБД и наличие индексов на перестраиваемых таблицах. В клиент-серверном варианте заметную долю времени занимает запись в журнал транзакций: при простых моделях восстановления это менее заметно, при полной модели лог растёт быстро.
Практический приём для больших баз — репетиция на копии. Копия разворачивается на тестовом сервере, обновление запускается с замером времени, и по результату планируется окно обновления рабочей базы. Заодно проверяется, нет ли ошибок в самой процедуре обновления конкретного релиза.
Типичные ошибки и как их избежать
Самая частая ошибка — обновление без свежей резервной копии в расчёте на то, что «обычно всё проходит нормально». Реструктуризация действительно в большинстве случаев завершается успешно, но единственный сбой — отключение электричества, переполнение диска, авария сервера — превращает экономию получаса в многодневное восстановление.
Вторая ошибка — нечтение списка изменений перед принятием. В окне реорганизации видно, какие объекты будут удалены. Если в списке неожиданно появились удаляемые справочники или регистры, это повод остановиться и разобраться: возможно, обновление накатывается не на ту конфигурацию или снятие с поддержки выполнено некорректно.
Третья группа ошибок связана с окружением: недостаток места на диске, активные регламентные задания, не завершённые сеансы, обновление через нестабильное сетевое подключение к файловой базе. Все они устраняются простой подготовкой по чек-листу, но регулярно становятся причиной прерванных обновлений.
Как проверить базу после реструктуризации
Минимальная проверка — вход в базу, открытие основных документов и журналов, формирование ключевых отчётов. Если реструктуризация затрагивала регистры, стоит сверить итоги до и после: например, остатки по складу или взаиморасчётам на одну и ту же дату. Совпадение итогов — хороший признак того, что данные перенесены корректно.
Дополнительно полезно запустить тестирование и исправление информационной базы в режиме проверки логической целостности — без ремонтных операций, только диагностику. Для клиент-серверных баз аналогичные проверки выполняются средствами СУБД. Ошибки обменов данными, если они настроены, проверяются отдельной отправкой и получением сообщений.
Если после обновления пользователи сообщают об ошибках вида «поле не найдено» или «объект не обнаружен», часто помогает очистка кэша метаданных на клиентских машинах и сервере. Это типовая ситуация после реструктуризации, и она не означает повреждения данных.
Как проверить результат
База открывается, документы и списки отображаются без ошибок
Ошибки при открытии, сообщения о не найденных полях или объектах
Остатки и обороты совпадают с контрольными значениями
Расхождения итогов на ту же дату
Обмены проходят, задания выполняются без ошибок в журнале
Ошибки в журнале регистрации, неотправленные сообщения
Нет ошибок, связанных с реструктуризацией
Записи об ошибках обновления или прерванных фоновых процессах
FAQ: частые вопросы о реструктуризации
Можно ли запускать реструктуризацию без резервной копии, если база небольшая?
Технически можно, и на маленьких базах процедура обычно проходит быстро. Но размер базы не защищает от внезапного отключения питания или сбоя диска. Копирование файловой базы занимает минуты, поэтому экономия на бэкапе не оправдана даже для маленьких баз.
Реструктуризация зависла — индикатор не двигается. Что делать?
Сначала проверьте, идёт ли реальная работа: активность диска, загрузку процессора, сессии на стороне СУБД. Перестроение большой таблицы может долго не менять показания индикатора. Если активности нет продолжительное время, зафиксируйте ситуацию и готовьтесь к восстановлению из копии — но не снимайте процесс, пока есть признаки работы.
Удаляются ли данные при реструктуризации?
Да, если объект или реквизит удалён из конфигурации, его таблица или колонка удаляется вместе с данными. Поэтому список изменений в окне реорганизации нужно читать: все удаляемые объекты там перечислены. После принятия изменений вернуть удалённые данные можно только из резервной копии.
Почему после обновления пользователи видят ошибки, хотя реструктуризация прошла успешно?
Чаще всего причина в кэше метаданных на клиентских компьютерах или в том, что сеансы запущены до обновления и работают со старой конфигурацией в памяти. Помогает перезапуск сеансов, а при необходимости — очистка кэша. Это штатная ситуация, а не признак повреждения базы.
Можно ли ускорить реструктуризацию большой базы?
Кардинально — только за счёт быстрого оборудования: SSD, достаточный объём памяти, грамотные настройки СУБД. Сократить окно простоя помогает репетиция на копии и предварительное удаление устаревших данных из изменяемых таблиц, если это допустимо по учётной политике. Саму процедуру платформы ускорить настройками нельзя.
Чем реструктуризация отличается от тестирования и исправления?
Реструктуризация приводит структуру таблиц в соответствие с конфигурацией и запускается при обновлении. Тестирование и исправление — отдельная сервисная процедура проверки логической и ссылочной целостности данных, которую администратор запускает вручную. Эти процедуры не заменяют друг друга.
Что важно запомнить
Реструктуризация перестраивает таблицы базы под изменённую конфигурацию и запускается при обновлении конфигурации базы данных. Безопасная схема всегда одинакова: резервная копия, завершение сеансов, свободное место на диске, внимательное чтение списка изменений, непрерываемое выполнение и проверка базы после завершения.