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

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

Типичная ситуация: вы добавили в документ новый реквизит и нажали «Обновить конфигурацию базы данных» (F7). Платформа сравнивает конфигурацию базы данных с изменённой конфигурацией, строит список изменений и пересоздаёт таблицы SQL-сервера или файловой базы под новую структуру. Именно этот этап и называется реструктуризацией.

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

Когда 1С запускает реструктуризацию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибки при реструктуризации и как на них реагировать

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

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

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

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

Ошибка «недостаточно места на диске»Освободите место с запасом, восстановите копию при повреждении и запустите заново

Обновление идёт несколько часов без признаков прогрессаПроверьте активность на стороне СУБД или рост временных файлов — не прерывайте, пока идёт запись на диск

Ошибка преобразования данных конкретной таблицыПроверьте данные тестированием и исправлением, исправьте проблемные записи и повторите

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

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

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

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

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

Вход в базу в пользовательском режиме

Норма

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

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

Ошибки при входе, сообщения о несоответствии версии

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

Норма

Поля видны в формах и заполняются

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

Реквизита нет или данные старого поля пусты

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

Норма

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

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

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

Журнал регистрации и консоль СУБД

Норма

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

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

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

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

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

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

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

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

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

Почему после переименования реквизита данные пропали?

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

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

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

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

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

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

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