Как прервать реструктуризацию базы 1С без потери данных

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

Короткий ответ: прерывание возможно, но оно почти всегда оставляет базу в промежуточном состоянии. Файловая база после аварийной остановки часто не открывается и требует восстановления из резервной копии или тестирования и исправления. Клиент-серверная база на MS SQL или PostgreSQL обычно откатывает изменения транзакциями, но и там возможны «битые» таблицы и расхождение конфигурации базы данных с реальной структурой.

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

Как понять, что реструктуризация зависла, а не работает

Прежде чем что-либо прерывать, проверьте признаки реальной активности процесса. В файловом режиме откройте диспетчер задач и посмотрите на процесс 1cv8.exe: если он потребляет процессор или активно работает с диском, реструктуризация идёт. Дополнительно проверьте размер файла 1Cv8.1CD и файлов в папке временных файлов — если размеры меняются, процесс жив.

В клиент-серверном режиме активность видна на стороне СУБД. В MS SQL Server через Activity Monitor или запрос к sys.dm_exec_requests видно выполняющиеся запросы от имени сервера 1С. В PostgreSQL — через представление pg_stat_activity. Если запросы выполняются и меняется их состояние, прерывать процесс рано.

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

Подготовка: что обязательно сделать до прерывания

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

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

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

Как прервать реструктуризацию в файловом режиме

В файловом режиме реструктуризацию выполняет сам процесс конфигуратора. Способ прерывания один — завершить процесс. Откройте диспетчер задач, найдите процесс 1cv8.exe, соответствующий конфигуратору (если открыто несколько окон 1С, сверьтесь по командной строке в столбце «Командная строка»), и снимите задачу.

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

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

1. 1
   Убедитесь по диспетчеру задач, что процесс не активен длительное время
2. 2
   Проверьте наличие резервной копии базы
3. 3
   Снимите задачу 1cv8.exe через диспетчер задач
4. 4
   Удалите файл 1Cv8.1CL из каталога базы
5. 5
   Проверьте файл chdbfl.exe в режиме диагностики
6. 6
   Восстановите базу из копии либо выполните тестирование и исправление

Как прервать реструктуризацию в клиент-серверном режиме

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

В MS SQL Server найдите сессию по базе данных и выполните команду KILL с номером SPID. В PostgreSQL используйте pg_cancel_backend (мягкая отмена) или pg_terminate_backend (жёсткое завершение) для соответствующего pid. Учтите, что откат длительной транзакции сам по себе может занять значительное время — это нормально, не перезагружайте сервер СУБД в этот момент.

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

SELECT pid, state, query_start, query FROM pg_stat_activity WHERE datname = 'my_base' AND state <> 'idle'; SELECT pg_terminate_backend(12345);

Что делать с базой после прерывания

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

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

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

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

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

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

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

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