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

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

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

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

Что именно делает реструктуризация

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

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

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

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

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

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

Типичные изменения, вызывающие реструктуризацию:

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

Как проходит процесс на практике

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

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

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

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

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

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

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

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

Основные риски и как их снизить

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

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

Практические меры защиты:

• всегда делайте выгрузку в dt или копию базы перед обновлением и проверяйте, что копия открывается;
• используйте ИБП на сервере и рабочем месте администратора;
• не выполняйте реструктуризацию файловой базы через сетевой диск — скопируйте базу локально;
• сначала прогоните обновление на тестовой копии, особенно при пропуске нескольких релизов;
• никогда не завершайте процесс 1cv8.exe принудительно, пока идёт реструктуризация.

Реструктуризация в фоновом режиме и динамическое обновление

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

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

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

Сравнение вариантов обновления

Монопольное обновление

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

Фоновое обновление

Основная работа идёт без остановки работы пользователей, финальная фаза — короткая. Подходит для больших клиент-серверных баз, но сложнее в контроле.

Динамическое обновление

Без перезапуска сеансов, но только если структура данных не менялась. При наличии реструктуризации неприменимо.

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

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

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

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

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

Для глубокой проверки используйте «Тестирование и исправление» в конфигураторе в режиме проверки логической и ссылочной целостности — сначала без исправления, чтобы оценить состояние. В клиент-серверном варианте полезно просмотреть журнал ошибок СУБД.

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

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

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

Норма

База открывается без ошибок, пользователи входят штатно

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

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

Проведение документов и отчёты

Норма

Документы проводятся, отчёты формируются с корректными данными

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

Ошибки при проведении, пустые или искажённые отчёты

Новые и изменённые реквизиты

Норма

Поля отображаются, значения сохраняются

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

Поля отсутствуют или данные не записываются

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

Реструктуризация удаляет данные из базы?

Только в двух случаях: когда удаляется реквизит или объект (данные в соответствующих колонках удаляются вместе с ними) и когда сокращается длина строкового поля (длинные значения обрезаются). Добавление реквизитов и создание новых объектов существующие данные не затрагивает.

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

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

Почему реструктуризация идёт так долго?

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

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

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

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

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

База не открывается после прерванной реструктуризации. Что делать?

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