Что делает реструктуризация таблиц информационной базы 1С

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

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

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

Что физически происходит с таблицами при реструктуризации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Риски и типичные ошибки

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

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

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

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

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

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

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

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

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

Открытие изменённых объектов

Норма

Документы и справочники открываются, реквизиты заполнены корректно

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

Ошибки при открытии, пустые или обрезанные значения полей

Регистры и отчёты

Норма

Обороты и остатки сходятся с данными до обновления

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

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

Тестирование и исправление (проверка целостности)

Норма

Проверки завершаются без ошибок

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

Сообщения о битых ссылках или нарушении логической целостности

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

Норма

Задания выполняются по расписанию, обмены проходят

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

Задания падают с ошибками, обмены не стартуют

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

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

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

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

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

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

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

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

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

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

Не запускайте повторные обновления и не пытайтесь «чинить» базу всеми режимами ТиИ подряд. Оцените сообщение об ошибке, проверьте базу утилитой chdbfl (для файлового варианта) или средствами СУБД, а при отсутствии результата восстановите резервную копию и повторите операцию, устранив первопричину сбоя.