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

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

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

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

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

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

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

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

В окне «Тестирование и исправление информационной базы» реструктуризация — первый пункт списка проверок. Если флажок установлен, платформа сравнивает структуру метаданных со структурой таблиц и приводит их в соответствие. Если расхождений нет, этап завершается быстро и незаметно.

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

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

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

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

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

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

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

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

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

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

Реструктуризация при обновлении конфигурации

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

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

Сколько длится реструктуризация и что делать, если она зависла

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

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

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

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

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

Завершение процедуры без сообщений об ошибках — необходимое, но недостаточное условие. Минимальная проверка: база открывается в режиме предприятия, ключевые отчёты (ОСВ, карточки счетов, остатки) формируются и сходятся с контрольными значениями, снятыми до процедуры.

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

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

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

Открытие базы в режиме предприятия

Норма

База открывается, пользователи входят без ошибок

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

Ошибки открытия, сообщения о нарушении целостности

Контрольные отчёты (ОСВ, остатки)

Норма

Итоги совпадают со значениями до процедуры

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

Расхождения сумм, пустые отчёты

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

Норма

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

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

Поля пустые или отсутствуют в формах

Журнал регистрации и журнал СУБД

Норма

Нет ошибок за период процедуры

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

Ошибки нехватки места, обрывы операций

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

Реструктуризация при ТиИ удаляет данные?

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

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

Реиндексация перестраивает только индексы таблиц, не меняя их структуру и данные. Реструктуризация изменяет сами таблицы: состав колонок, типы полей, индексы. Реиндексация безопаснее и входит в ТиИ отдельным пунктом.

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

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

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

Не запускайте базу в рабочем режиме. Если есть резервная копия — восстановите её и повторите процедуру после устранения причины (место на диске, стабильность соединения). Для файловой базы без копии попробуйте chdbfl.exe и ТиИ, но результат не гарантирован.

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

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

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

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