К статье
Практический материал

Администрирование · 10 мин

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

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

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

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

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

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

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

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

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

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

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

Также процедура запускается в следующих ситуациях:

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

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

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

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

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

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

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

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

При обновлении конфигурации

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

Через «Тестирование и исправление»

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

Пакетный запуск конфигуратора

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

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

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

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

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

Прогон обновления на копии базы — самый надёжный способ оценить время реструктуризации. Засеките длительность на копии и заложите запас 30–50% для рабочей базы: на ней обычно больше фоновая нагрузка и фрагментация.
ПЗ
Практическое замечание

Ошибки, зависания и способы восстановления

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

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

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

Типичные ошибки
01
Запуск без резервной копии — при сбое данные восстановить нечем
02
Принудительное завершение процесса, который «завис», — на больших таблицах долгое отсутствие прогресса нормально, а прерывание убивает базу
03
Обновление в рабочее время — пользователи не могут войти, а процесс растягивается из-за конкуренции за ресурсы
04
Игнорирование свободного места на диске — реструктуризация падает на середине из-за нехватки пространства для временных таблиц

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

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

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

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

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

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

База открывается без сообщений об ошибках структуры

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

Ошибки о несоответствии конфигурации или недоступности таблиц

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

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

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

Пропавшие записи, ошибки при обращении к объектам

Журнал регистрации
Норма

Нет массовых ошибок после обновления

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

Повторяющиеся ошибки доступа к данным или фоновых заданий

Итог

Что важно запомнить

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

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

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

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

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

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

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

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

Что такое динамическое обновление и стоит ли его использовать?

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

Обязательно ли делать выгрузку .dt, если есть бэкап средствами СУБД?

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