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

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

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

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

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

Конфигурация 1С описывает логическую модель данных: справочники, документы, регистры, их реквизиты и измерения. Реальные данные хранятся в таблицах СУБД (в файловом варианте — в файле 1Cv8.1CD, в клиент-серверном — в таблицах MS SQL Server, PostgreSQL, Oracle или IBM Db2). Когда логическая модель меняется, физические таблицы должны быть приведены в соответствие с ней.

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

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

Когда запускается реструктуризация

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

Изменения, которые вызывают реструктуризацию:

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

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

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

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

Порядок действий для типового обновления:

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

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

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

Монопольный доступ и блокировки

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

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

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

Зависание и ошибки реструктуризации: что делать

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

Если реструктуризация завершилась ошибкой, типичные причины следующие:

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

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

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

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

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

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

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

Выгрузка в dt

Штатный способ через конфигуратор. Подходит для баз умеренного размера; минус — долгая выгрузка и загрузка на больших объёмах.

Копия файла 1Cv8.1CD

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

Бэкап средствами СУБД

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

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

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

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

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

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

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

Норма

Вход выполняется без ошибок, версия конфигурации обновлена

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

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

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

Норма

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

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

Пустые или искажённые значения, ошибки при открытии

Остатки по регистрам

Норма

Совпадают с контрольными значениями до обновления

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

Расхождения в остатках и оборотах

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

Норма

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

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

Ошибки проведения, блокировки, падение сеанса

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

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

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

Реструктуризация удаляет или изменяет данные пользователей?

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

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

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

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

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

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

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

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

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

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

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