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

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

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

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

Как устроена реструктуризация изнутри

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

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

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

В каких ситуациях запускается реструктуризация

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

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

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

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

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

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

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

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

Как выполнить реструктуризацию пошагово

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

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

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

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

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

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

Почему реструктуризация зависает и что делать

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

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

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

Как сократить время и снизить риски

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

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

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

Способы обновления

Штатное обновление в конфигураторе

Подходит для большинства баз; требует монопольного доступа и окна обслуживания на время реструктуризации

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

Только для изменений без реструктуризации; пользователи не отключаются, но есть риск ошибок в активных сеансах

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

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

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

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

Полезно выполнить тестирование и исправление базы (в режиме проверки без исправлений) или штатные проверки целостности СУБД. Ошибки, обнаруженные сразу, устраняются проще, чем через неделю работы пользователей поверх повреждённых данных.

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

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

Список изменений в окне реорганизации

Норма

Только ожидаемые добавления и изменения полей

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

Неожиданное удаление таблиц, полей, данных

Завершение процесса

Норма

Сообщение об успешном обновлении конфигурации БД

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

Ошибка СУБД, нехватка места, аварийное закрытие

Контрольные итоги после обновления

Норма

Обороты и остатки совпадают с дообновленческими

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

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

Работа типовых операций

Норма

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

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

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

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

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

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

Почему платформа предлагает удалить данные при обновлении?

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

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

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

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

Логика платформы одинакова, различается исполнение. В файловой базе пересоздание таблиц выполняется внутри одного файла 1Cv8.1CD, который может заметно вырасти. В клиент-серверном варианте работу выполняет СУБД, и критичными становятся настройки журнала транзакций, блокировки и производительность сервера. Резервное копирование тоже делается разными средствами.

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

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

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

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