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

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

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

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

Когда платформа запускает реструктуризацию

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

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

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

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

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

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

В файловом варианте базы реструктуризация выполняется монопольно: все пользователи должны выйти, фоновые задания останавливаются. В клиент-серверном варианте (MS SQL, PostgreSQL и другие) процесс также требует монопольного доступа к информационной базе, поэтому обновление с реструктуризацией всегда планируют на время, когда пользователи не работают.

Ход процесса отображается индикатором с названием текущей таблицы. Если индикатор «замер» на одной таблице — чаще всего это не зависание, а именно длительное копирование большого объёма данных. Ориентироваться можно по размеру файла базы (в файловом варианте) или по активности сервера СУБД.

Подготовка базы перед реструктуризацией

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

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

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

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

Типичные ошибки и как их избежать

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

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

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

Файловая и клиент-серверная база: в чём разница

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

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

Сравнение вариантов

Файловая база

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

Клиент-серверная база

Реструктуризация обычно быстрее за счёт ресурсов СУБД, но требует администратора, грамотного резервного копирования средствами СУБД и контроля журналов транзакций

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

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

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

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

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

Запуск базы в режиме предприятия

Норма

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

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

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

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

Норма

Записи на месте, новые реквизиты доступны, отчёты сходятся с контрольными значениями

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

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

Журнал и сообщения платформы

Норма

Обновление завершено без ошибок в служебных сообщениях

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

Сообщения об ошибках СУБД, незавершённые транзакции

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

Частые вопросы о реструктуризации таблиц

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

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

Почему реструктуризация запускается, хотя я ничего не менял в конфигурации?

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

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

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

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

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

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

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

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

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