Реструктуризация 1С: что это значит и как работает

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

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

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

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

На физическом уровне 1С хранит данные в таблицах СУБД (или в файле 1Cv8.1CD для файлового режима). Когда вы добавляете реквизит в справочник, платформе нужно добавить колонку в соответствующую таблицу. Когда меняется тип реквизита или длина строки — преобразовать уже записанные значения. Когда удаляется объект — решить, что делать с накопленными данными.

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

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

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

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

Типичные триггеры:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Не пытайтесь сразу снова запустить обновление конфигурации БД — сначала оцените состояние.
2. Проверьте базу утилитой тестирования и исправления (для файловых баз — chdbfl.exe из каталога платформы как первый шаг).
3. Если база открывается и работает — сделайте копию и повторите обновление.
4. Если база не открывается или ведёт себя некорректно — восстановите её из резервной копии и повторите процедуру, устранив причину сбоя (место на диске, питание, память).

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

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

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

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

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

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

Конфигурация БД

Норма

В конфигураторе нет предупреждения о различии конфигураций, обновление завершено без ошибок

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

Повторно появляется окно реорганизации или сообщение о несовпадении конфигураций

Открытие базы

Норма

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

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

Ошибки при открытии, падение при обращении к изменённым объектам

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

Норма

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

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

Есть обработчики с ошибками или в очереди спустя длительное время

Данные

Норма

Контрольные отчёты (ОСВ, остатки) совпадают с показателями до обновления

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

Расхождения в итогах, пропавшие записи

Когда реструктуризации можно избежать

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

Разумные подходы:

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

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

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

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

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

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

Чем реструктуризация в файловой базе отличается от клиент-серверной?

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

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

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

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

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

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

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