Обновление 1С:Предприятия оборвалось на середине: насколько это опасно и как вернуть базу в строй
Содержание
Если прервать обновление 1С, база чаще всего остаётся в одном из двух состояний: либо на старой версии без изменений, либо с новой конфигурацией, у которой не дописаны данные. Последствия зависят от этапа, на котором случился обрыв. Прерванное объединение в Конфигураторе безобидно. Обрыв реструктуризации или обработчиков обновления лечится повторным запуском. Реальная порча данных возможна в основном у файловой базы при отключении питания или принудительном снятии процесса во время записи.
Распространённое заблуждение — «раз обновление зависло, надо срочно снять задачу, иначе база сломается». На деле опаснее именно снятие процесса. Обновление крупной базы может идти часами без движения индикатора, и это нормально. Сначала убедитесь, что процесс действительно стоит, а уже потом решайте, что делать с прерванным обновлением 1С Предприятие.
Из каких этапов состоит обновление конфигурации
Обновление типовой конфигурации 1С 8.3 — это не одна операция, а цепочка. На каждом звене меняется своё, поэтому и последствия обрыва разные.
- Загрузка и объединение. Конфигуратор читает файл
.cfuили.cfи сравнивает его с основной конфигурацией. Если конфигурация на поддержке без изменений, объединение проходит почти мгновенно. Если доработана — открывается окно сравнения. - Сохранение основной конфигурации. Результат объединения записывается в основную конфигурацию. Данные пользователей на этом шаге не трогаются.
- Обновление конфигурации
базы данных (реструктуризация). Команда
Конфигурация → Обновить конфигурацию базы данных(клавиша F7). Платформа приводит таблицы к новой структуре: добавляет поля, создаёт таблицы, переносит данные. Это самый тяжёлый этап, для него нужен монопольный доступ. - Обработчики обновления. При первом запуске в режиме 1С:Предприятие типовая конфигурация выполняет обработчики новой версии: заполняет новые реквизиты, пересчитывает регистры, переносит настройки. Часть обработчиков отложенная — она идёт в фоне уже после того, как пользователи начали работать.
Если обновление запускали из пользовательского режима через помощник обновления программы, внутри происходит то же самое. Помощник закрывает сеансы, ставит блокировку, вызывает Конфигуратор в пакетном режиме и после завершения снимает блокировку.
| Этап | Что меняется | Последствия обрыва |
|---|---|---|
| Объединение | Только основная конфигурация в памяти Конфигуратора | Нет, изменения просто не сохранятся |
| Сохранение основной конфигурации | Основная конфигурация | База работает на старой версии, основная конфигурация может отличаться от конфигурации БД |
| Реструктуризация | Структура таблиц и данные | Обновление нужно повторить; у файловой базы при аварии возможна порча файла |
| Обработчики обновления | Данные (заполнение, пересчёт) | Программа при входе снова запустит обновление |
| Отложенные обработчики | Данные в фоне | Обработка продолжится при следующем запуске фонового задания |
Последствия прерванного обновления 1С: что увидят пользователи
Симптомы после обрыва вполне узнаваемые. По ним можно сразу понять, где именно остановился процесс.
- 🔒 Никто не может войти. Блокировка работы пользователей, которую поставили перед обновлением, осталась. Сеанс получает сообщение о запрете входа, иногда с текстом, который ввёл администратор.
- ⚠️ При запуске появляется вопрос
Конфигурация базы данных не соответствует сохраненной конфигурации. Продолжить?Значит, основная конфигурация сохранена, а реструктуризация не завершилась или не запускалась. - 🔄 Каждый вход открывает окно обновления версии программы. Обработчики не доработали, программа пытается выполнить их снова.
- 🐢 Отчёты показывают странные цифры, новые поля пустые. Не завершились отложенные обработчики.
- ❌ База не открывается вовсе, платформа сообщает об ошибке формата или повреждении. Это случай файловой базы, файл
1Cv8.1CDкоторой был повреждён при аварии.
В клиент-серверном варианте последний сценарий редкость. Изменения структуры выполняются средствами СУБД в транзакциях, и при обрыве незавершённая транзакция откатывается. База, как правило, остаётся в старой структуре, и обновление можно запустить ещё раз.
У файловой базы такой защиты нет в той же мере. Если во время записи выдернули питание или сняли процесс 1cv8.exe, часть страниц файла может остаться недописанной. Отсюда ошибки чтения и необходимость тестирования.
Как отличить зависание от долгой работы
Прежде чем что-то прерывать, проверьте нагрузку. Откройте диспетчер задач Windows на машине, где идёт обновление.
- Для файловой базы смотрите процесс
1cv8.exe: растёт ли счётчик операций с диском, меняется ли загрузка процессора. - Для клиент-серверной — процессы
rphost.exeна сервере 1С и процесс СУБД (для MS SQL этоsqlservr.exe). - Если диск и процессор заняты, процесс работает. Реструктуризация больших регистров накопления у базы на сотни гигабайт может занимать несколько часов.
Перед крупным обновлением засеките, сколько заняло прошлое. Это лучший ориентир: если прошло вдвое больше времени, а нагрузки нет, — тогда уже разбирайтесь.
Как восстановить базу после прерванного обновления
Порядок действий зависит от того, на каком этапе оборвался процесс. Выберите свой случай:
Снять оставшуюся блокировку пользователей
Блокировка, установленная в программе, хранится в базе и сама не исчезнет. Снять её можно двумя способами.
- Войдите под администратором с ключом разрешения. Помощник обновления типовых конфигураций ставит блокировку с кодом
ПакетноеОбновлениеКонфигурацииИБ, поэтому строка запуска выглядит так:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F"D:\Base\Buh" /N"Администратор" /UCПакетноеОбновлениеКонфигурацииИБ
- В программе откройте
Администрирование → Обслуживаниеи найдите ссылку «Блокировка работы пользователей». Снимите флажок блокировки и сохраните.
Для клиент-серверной базы проверьте ещё и консоль кластера. В свойствах информационной базы может остаться включённая «Блокировка начала сеансов» — снимите флажок там.
Перед повторным запуском обновления убедитесь, что в базе нет чужих сеансов. В консоли кластера посмотрите список сеансов; завершать их можно, только предупредив людей: несохранённые документы пропадут.
Повторить обновление конфигурации базы данных
Это основной сценарий восстановления работоспособности базы.
- Запустите Конфигуратор под администратором.
- Откройте конфигурацию:
Конфигурация → Открыть конфигурацию. - Выполните
Конфигурация → Обновить конфигурацию базы данных(F7). - Прочитайте список изменений структуры и примите его.
- Дождитесь сообщения о завершении, не закрывая окно.
- Запустите 1С:Предприятие под администратором и дайте выполниться обработчикам.
Если на шаге 3 платформа сообщает, что не может установить монопольный режим, значит, в базе остались сеансы или фоновые задания. Для клиент-серверной базы на время обновления можно включить в консоли кластера блокировку регламентных заданий.
Откатиться к старой версии
Иногда проще вернуться назад и обновиться в спокойное время. Вариантов три.
| Способ | Когда подходит | Риски |
|---|---|---|
| Вернуться к конфигурации БД | Основная конфигурация сохранена, а F7 ещё не выполнялся | Нет, данные не трогаются |
Загрузка .dt (Администрирование → Загрузить информационную базу в Конфигураторе) | Есть выгрузка перед обновлением | Полностью заменяет базу: всё, что ввели после выгрузки, пропадёт |
Копия файла 1Cv8.1CD или бэкап СУБД | Файловая база или SQL с регулярным резервным копированием | Те же: теряются данные после момента копии |
Загрузка .dt и восстановление бэкапа стирают текущее содержимое базы. Если после обрыва кто-то успел поработать, сначала сделайте копию текущего состояния — даже повреждённую.
Тестирование и исправление информационной базы
Инструмент проверяет физическую и логическую целостность данных. Он нужен, когда повторное обновление падает с ошибками или база ведёт себя странно после аварии. Работает в монопольном режиме — всех пользователей нужно выгнать заранее.
Запуск: Конфигуратор → Администрирование → Тестирование и исправление. В окне отметьте проверки:
- Реиндексация таблиц информационной базы — перестраивает индексы, часто снимает ошибки после аварии.
- Проверка логической целостности — ищет нарушения внутренней структуры.
- Проверка ссылочной целостности — находит «битые» ссылки на несуществующие объекты.
- Пересчёт итогов — заново считает итоги регистров.
- Сжатие таблиц — уменьшает файл, для восстановления необязательно.
- Реструктуризация таблиц информационной базы — пересоздаёт таблицы, самая долгая операция.
Режим сначала выберите «Тестирование» без исправления: так вы увидите масштаб проблем, ничего не меняя. Затем «Тестирование и исправление» с вариантами реакции на битые ссылки.
Вариант «Удалять ссылки» и «Удалять объекты» необратим. Для бухгалтерской базы безопаснее «Создавать объекты»: программа заведёт пустые элементы на месте потерянных, и их потом можно найти и заполнить.
Перед тестированием сделайте копию базы. Исправление меняет данные, и результат не всегда тот, что ожидался.
Утилита chdbfl.exe для файловой базы
Если файловая база не открывается даже в Конфигураторе, используйте отдельную утилиту chdbfl.exe. Она лежит в каталоге bin установленной платформы, например C:\Program Files\1cv8\8.3.24.1548\bin\chdbfl.exe (номер — ваш).
- Закройте все сеансы базы.
- Скопируйте файл
1Cv8.1CDв другое место. - Запустите
chdbfl.exe, укажите путь к файлу. - Сначала запустите проверку без флажка «Исправлять обнаруженные ошибки».
- Если ошибки есть — повторите с флажком.
После утилиты всё равно прогоните тестирование и исправление из Конфигуратора: chdbfl.exe чинит физическую структуру файла, но не логику данных.
Проверка на стороне СУБД
Для клиент-серверной базы на MS SQL Server администратор может проверить целостность самой базы СУБД командой:
DBCC CHECKDB ('buh_base') WITH NO_INFOMSGS;
Команда только проверяет и выводит ошибки. Варианты с исправлением (REPAIR_ALLOW_DATA_LOSS) могут удалить данные — применять их стоит лишь при отсутствии резервной копии и после консультации с администратором БД.
Обработчики обновления и отложенная обработка данных
Если обрыв случился при первом запуске, данные могут остаться наполовину заполненными. Программа это помнит.
- При следующем входе администратора запускается окно обновления версии и дорабатывает то, что не успело выполниться.
- Если обработчик падает с ошибкой, текст ошибки есть в журнале регистрации:
Администрирование → Обслуживание → Журнал регистрации, отбор по событию, связанному с обновлением информационной базы. - Ход отложенных обработчиков видно в разделе
Администрирование → Обслуживание, в группе, посвящённой обновлению версии программы, — ссылка на результаты обновления и дополнительную обработку данных.
Пока отложенная обработка не завершена, некоторые отчёты могут показывать неполные данные. Закрывать период и сдавать отчётность до окончания обработки не стоит.
Если обработчик стабильно падает на одном объекте, обычно виноват конкретный «битый» документ или элемент справочника. Текст ошибки в журнале регистрации называет его — исправьте объект вручную и запустите обновление снова.
Как подготовиться к обновлению, чтобы обрыв не стал проблемой
Обрыв не страшен, если есть, куда откатиться. Подготовка занимает полчаса и превращает аварию в мелкую неприятность.
Несколько приёмов, о которых часто забывают:
- 💾 Место на диске. Реструктуризация создаёт новые таблицы рядом со старыми. Если место кончится посреди процесса, обновление оборвётся само.
- 🖥️ Обновление по удалённому рабочему столу. Если сеанс RDP разорвётся, процессы в нём продолжат работу, пока сеанс не будет завершён. Настройте на сервере, чтобы отключённые сеансы не завершались слишком быстро, или запускайте обновление прямо на сервере.
- 🔁 Цепочка релизов. Пропущенные релизы ставятся последовательно. Каждая ступень — отдельное обновление с реструктуризацией и обработчиками. Не прерывайте цепочку посередине на ночь: доведите её до конца или остановитесь на завершённом релизе с отработавшими обработчиками.
- 🧪 Тестовая копия. Для доработанной конфигурации сначала обновите копию. Заодно узнаете, сколько займёт процесс на рабочей базе.