Администрирование · 11 мин
Реструктуризация базы 1С: что это и как выполнить правильно
Что такое реструктуризация базы 1С, когда она нужна и как выполнить её без потери данных. Пошаговая инструкция, резервное копирование, типичные ошибки и FAQ.
Реструктуризация в 1С — это процесс приведения физической структуры информационной базы в соответствие с изменённой конфигурацией. Когда вы добавляете новый реквизит в справочник, меняете тип поля, создаёте регистр или удаляете объект, платформа должна перестроить таблицы базы данных. Именно это перестроение и называется реструктуризацией.
Операция запускается автоматически при обновлении конфигурации базы данных, если изменения затрагивают структуру хранения. Платформа формирует список изменений, показывает его администратору и после подтверждения выполняет преобразование таблиц. На небольших базах это занимает секунды, на крупных — часы.
Главный риск реструктуризации — потеря или повреждение данных при сбое. Прерванная на середине реструктуризация может оставить базу в нерабочем состоянии, поэтому резервная копия перед запуском — не рекомендация, а обязательное условие. Ниже разберём весь процесс по шагам.
Когда требуется реструктуризация базы 1С
Не каждое изменение конфигурации вызывает реструктуризацию. Платформа перестраивает таблицы только тогда, когда меняется физическая модель хранения данных. Понимание этого помогает заранее оценить длительность и риски обновления.
Реструктуризация запускается при добавлении или удалении реквизитов объектов, изменении типа или длины поля, создании новых справочников, документов, регистров, изменении состава измерений и ресурсов регистров, добавлении табличных частей, изменении признаков учёта субконто. Также она нужна при типовом обновлении конфигурации от поставщика, если релиз содержит структурные изменения.
Не вызывают реструктуризацию изменения в модулях, формах, макетах, ролях без изменения состава объектов, а также правка синонимов и подсказок. Такие обновления проходят быстро и безопасно, их часто называют «динамическими» — в клиент-серверном режиме платформа может применить их без перезапуска сеансов.
Подготовка: резервная копия и свободная база
Первый шаг — полная резервная копия базы. Для файлового режима достаточно скопировать файл 1Cv8.1CD при закрытых сеансах или использовать выгрузку в dt через конфигуратор (Файл → Сохранить копию). Для клиент-серверного варианта делайте копию средствами СУБД: для MS SQL — полный backup базы, для PostgreSQL — pg_dump. Выгрузка в dt не заменяет копию средствами СУБД на больших базах: загрузка dt может занять много часов.
Второй шаг — завершить все сеансы пользователей. В клиент-серверном режиме откройте консоль кластера, проверьте список сеансов и установите блокировку соединений с информационной базой. Завершите фоновые задания и регламентные операции: выполняющееся фоновое задание может держать соединение и помешать монопольному доступу.
Третий шаг — оцените объём изменений. Если обновление типовое, изучите описание релиза: поставщик указывает, есть ли реструктуризация и насколько она объёмная. Для крупных баз имеет смысл сначала выполнить обновление на тестовой копии и замерить время — это даст реалистичную оценку окна простоя.
Пошаговое выполнение реструктуризации
После подготовки сама процедура занимает несколько действий в конфигураторе. Важно не прерывать процесс и дождаться полного завершения, даже если окно прогресса кажется зависшим — на больших таблицах индикатор может долго не меняться, пока идёт перестроение данных.
Откройте конфигуратор под учётной записью с правами администратора. Если нужно, загрузите новую конфигурацию из файла cf (Конфигурация → Загрузить конфигурацию из файла) или выполните типовое обновление через поддержку. Затем вызовите команду Конфигурация → Обновить конфигурацию базы данных.
Платформа покажет окно «Реструктуризация информационной базы» со списком изменений: какие объекты будут добавлены, изменены или удалены. Внимательно просмотрите список — особенно строки с удалением объектов и реквизитов: данные удаляемых полей будут потеряны безвозвратно. После проверки нажмите «Принять» и дождитесь завершения.
- 1Сделайте резервную копию базы (файл 1Cv8.1CD, backup СУБД или выгрузка dt) и проверьте, что копия открывается
- 2Завершите все сеансы пользователей и фоновые задания, установите блокировку соединений
- 3Откройте конфигуратор и загрузите новую конфигурацию или выполните типовое обновление
- 4Запустите команду Конфигурация → Обновить конфигурацию базы данных
- 5Изучите список изменений реструктуризации, особенно удаляемые объекты, и нажмите «Принять»
- 6Дождитесь завершения процесса, не прерывая его
- 7Запустите обработчики обновления данных в режиме предприятия, если они предусмотрены релизом
- 8Проверьте работоспособность базы и снимите блокировку соединений
Особенности для файлового и клиент-серверного режимов
В файловом режиме реструктуризация выполняется напрямую над файлом 1Cv8.1CD. Платформа создаёт временные файлы рядом с базой, поэтому на диске должно быть свободное место, сопоставимое с размером базы. Файловый режим чувствителен к сбоям: перебои с питанием или сетью (если база лежит на сетевом диске) во время реструктуризации нередко приводят к повреждению файла.
В клиент-серверном режиме перестроение выполняет СУБД, что надёжнее и обычно быстрее на больших объёмах. Однако здесь важно учитывать рост журнала транзакций: массовое перестроение таблиц может сильно увеличить лог MS SQL, поэтому на время обновления иногда переводят модель восстановления в простую. Также убедитесь, что у учётной записи сервера 1С есть необходимые права на изменение структуры базы.
Для динамического обновления в клиент-серверном режиме есть ограничение: оно возможно только пока изменения не затрагивают структуру данных. Если в очереди накопилось несколько обновлений и одно из них реструктуризирует таблицы, потребуется полноценное обновление с завершением сеансов.
Сравнение режимов
Простая копия файла перед обновлением, но высокая чувствительность к сбоям и медленная работа на больших объёмах. Подходит для небольших баз
Перестроение средствами СУБД, быстрее и надёжнее, но требует контроля журнала транзакций, прав доступа и блокировки сеансов через консоль кластера
Проверка результата после реструктуризации
Завершение окна реструктуризации без сообщений об ошибках — первый, но не единственный признак успеха. После обновления запустите базу в режиме предприятия и дайте отработать обработчикам обновления данных: типовые релизы часто заполняют новые реквизиты и переносят данные в новые структуры именно на этом этапе. До завершения обработчиков часть функций может быть недоступна.
Далее выполните тестирование и исправление информационной базы (Конфигурация → Администрирование → Тестирование и исправление) хотя бы в режиме проверки логической и ссылочной целостности без исправления. Это выявит скрытые проблемы. Дополнительно откройте ключевые отчёты и журналы документов, сверьте итоги с данными до обновления.
Как проверить результат
Процесс завершился без сообщений об ошибках
Ошибки преобразования данных или аварийное завершение
Все обработчики выполнены, статус «обновление завершено»
Обработчики зависли или завершились с ошибками
Обороты и остатки совпадают с данными до обновления
Расхождения в итогах, пропавшие документы
Проверка целостности не выявила ошибок
Ошибки ссылочной или логической целостности
Типичные ошибки и как их избежать
Большинство проблем при реструктуризации связано не с самой платформой, а с нарушением подготовительных процедур. Характерные сценарии: обновление без копии, запуск при активных пользователях, нехватка места на диске и нетерпеливое прерывание «зависшего» процесса.
Отдельная группа ошибок — работа с нетиповыми конфигурациями. Если конфигурация доработана, при типовом обновлении реструктуризация может конфликтовать с доработками: например, типовой релиз изменяет реквизит, который используется в ваших доработках. В таких случаях обновление выполняется вручную через сравнение и объединение конфигураций, а реструктуризация требует дополнительной проверки на тестовой копии.
Что делать, если реструктуризация завершилась сбоем
Если процесс аварийно завершился, не пытайтесь запускать базу в рабочем режиме и не повторяйте реструктуризацию поверх повреждённой базы. Правильная последовательность: восстановить базу из резервной копии, выяснить и устранить причину сбоя (место на диске, права, активные сеансы, ошибки СУБД), затем повторить обновление.
Если копии нет — ситуация сложнее. Для файлового режима попробуйте утилиту chdbfl.exe из каталога установки платформы: она проверяет и исправляет физическую целостность файла базы. Для клиент-серверного режима используйте средства восстановления СУБД. Однако гарантии восстановления нет, поэтому этот путь — крайняя мера, а не рабочая практика.
Как выбрать действие
Что важно запомнить
Реструктуризация — это перестройка таблиц базы при изменении структуры конфигурации. Обязательные условия безопасного выполнения: проверенная резервная копия, отсутствие активных сеансов, достаточно свободного места и непрерываемый процесс. После завершения проверьте обработчики обновления, итоги и целостность базы.
Частые вопросы о реструктуризации 1С
Можно ли отменить реструктуризацию после её выполнения?
Штатной отмены нет. Единственный способ вернуться к прежнему состоянию — восстановить базу из резервной копии, сделанной до обновления. Поэтому копия должна создаваться непосредственно перед запуском процесса, а не «вчерашняя».
Почему реструктуризация длится несколько часов?
Длительность зависит от объёма затрагиваемых таблиц: при изменении реквизита документа с миллионами записей платформа перестраивает всю таблицу. Ускорить может переход на клиент-серверный режим и выполнение обновления в нерабочее время без конкурирующей нагрузки.
Что произойдёт с данными удаляемого реквизита?
Они будут удалены вместе с полем таблицы без возможности восстановления. Если данные нужны, заранее перенесите их в другой реквизит или сохраните во внешний файл, либо откажитесь от удаления поля в списке изменений.
Можно ли обновлять конфигурацию, пока пользователи работают?
Только если изменения не затрагивают структуру данных — тогда возможно динамическое обновление в клиент-серверном режиме. Если требуется реструктуризация, все сеансы необходимо завершить, иначе обновление не запустится или завершится ошибкой.
Нужно ли запускать тестирование и исправление после каждой реструктуризации?
Обязательным это не является, если процесс завершился без ошибок, однако проверка целостности на больших или ранее повреждавшихся базах — разумная мера. Запускайте проверку без включённых режимов исправления, чтобы сначала оценить состояние.
Чем выгрузка в dt отличается от копии средствами СУБД?
Выгрузка dt — логическая копия на уровне платформы, она универсальна, но на больших базах создаётся и восстанавливается долго. Backup средствами СУБД выполняется значительно быстрее и надёжнее для крупных баз, однако привязан к конкретной СУБД и её версии.