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

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

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

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

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

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

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

• добавление или удаление реквизита у справочника, документа, регистра;
• изменение типа или длины реквизита (например, строка 50 символов заменена на 100);
• создание нового объекта метаданных — документа, регистра сведений, плана счетов;
• добавление измерения в регистр сведений или регистр накопления;
• изменение состава индексов, включение признака «Индексировать» у реквизита;
• изменение длины кода или номера объекта, изменение иерархичности справочника.

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

Как проходит процесс: этапы и режимы

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

Существует два режима реструктуризации, выбор которых критичен для больших баз:

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

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

Подготовка: резервная копия и монопольный доступ

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

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

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

Для серверных баз под управлением MS SQL или PostgreSQL предпочтителен бэкап средствами СУБД: он создаётся быстрее выгрузки в dt и восстанавливается надёжнее. Выгрузка в dt на больших базах может занимать часы и сама по себе является нагрузочной операцией.

Реструктуризация в файловом и клиент-серверном режиме

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

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

Сравнение вариантов размещения базы

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

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

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

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

Обновление на копии с последующей подменой

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

Зависание, ошибки и типичные проблемы

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

Типичные ошибки и их причины:

• «Ошибка разделённого доступа» — в базе остались активные сеансы или фоновые задания. Завершите сеансы через консоль кластера или список активных пользователей.
• Нехватка места на диске — платформа дублирует таблицы во время переноса. Освободите место или перенесите временные файлы.
• Ошибка преобразования данных — например, при сужении длины строки, если в данных есть значения длиннее нового предела. Платформа укажет проблемный объект; данные придётся исправить и повторить обновление.
• Конфликт блокировок на SQL-сервере — параллельные процессы удерживают таблицы. Убедитесь, что никакие внешние системы и отчёты напрямую не читают базу.

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

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

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

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

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

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

Норма

База открывается без сообщений о несоответствии версии конфигурации

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

Ошибка «Конфигурация базы данных не соответствует сохранённой конфигурации» — реструктуризация не завершена корректно

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

Норма

Реквизиты на месте, записи открываются, документы проводятся

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

Пустые поля, ошибки при открытии или проведении

Отчёты по изменённым регистрам

Норма

Отчёты формируются, итоги сходятся с данными до обновления

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

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

Регламентные задания

Норма

Задания включены и выполняются по расписанию

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

Задания заблокированы или завершаются с ошибкой

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

Обязательна ли резервная копия, если изменения небольшие?

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

Реструктуризация идёт уже несколько часов — это нормально?

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

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

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

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

Не пытайтесь повторно запускать обновление или «дообновить» базу — структура таблиц находится в несогласованном состоянии. Восстановите базу из резервной копии и повторите обновление сначала, устранив причину сбоя (например, подключив источник бесперебойного питания).

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

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

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

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