Каталог решений - Опыт восстановления файловой базы данных 1с 8.2 после неудачного обновления конфигурации

Опыт восстановления файловой базы данных 1с 8.2 после неудачного обновления конфигурации.

Главной причиной возникновения проблемы стало зависшее приложение при обновлении конфигурации информационной базы (это следует из текста ошибки в журнале событий системы – «Зависшее приложение 1cv8.exe, версия 8.2.18.96, зависший модуль hungapp, версия 0.0.0.0, адрес 0x00000000.»), запущенное на Microsoft Windows XP SP3 при работе с файловым вариантом базы данных, расположенной на другой (весьма нагруженном) машине (далее «Сервер») находящейся в том же домене, но фактически расположенной в другом месте (связь с которой обеспечивается через оптоволоконную линию одного из интернет-провайдеров). В качестве сервера используется Microsoft Windows Server 2003R2 Enterprise x64 Edition SP2 на процессоре Intel Xeon с 24 Гб ОЗУ. При этом на стороне сервера в этом промежутке времени никаких записей об ошибках или предупреждений не в системном журнале, не в журнале приложений нету.

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

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

Рисунок 1

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

Первым шагом попытался восстановить работоспособность штатными средствами (утилита chdbfl.exe от «1С», расположенной в каталоге платформы), но данная утилита выдавала ошибку «неожиданного прерывания выполнения» с длинным текстом из которой следовало, что в структуре таблиц найдена таблица с повторяющимся именем. Как позже выяснилось – их было несколько.  Данные таблицы были индексами к данным, структура которых должна была быть изменена (или уже была изменена). Трудно судить об этом.

После изучения различного рода материалов по данной тематике в сети, решил использовать утилиту Tool_1CD.exe (//sale.itcity.ru/public/19633/) от Валерия Агеева (//sale.itcity.ru/profile/13819/) . А так как файл был поврежден решился на использование альфа-версии данной утилиты с возможностью не только чтения таблиц, но и редактирования. Плюсом явилось то, что кроме самой утилиты на странице загрузки были ссылки на материалы автора по опыту обследования и восстановления информационных баз. Также весьма полезной оказалась информация о предназначении таблиц (http://1c-dn.com/library/data_structure_in_1c_enterprise_8/). Так же очень полезно прочесть перед дальнейшим чтением: //sale.itcity.ru/public/19734/, http://main.1c-ei.ru/Home/help/objectdb/dbschema (описана структура таблиц), http://www.gilev.ru/restoreib/ (здесь очень важно то, какие таблицы проверяет платформа перед запуском по словам самой «1С»).

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

После открытия файла базы приступил к изучению состава таблиц. Отсутствовала таблица «DBSHEMA», но присутствовала «DBSHEMAOG» которая (судя по изученным мной материалам) должна заменить первую после обновления конфигурации. Также в присутствовали записи в таблице «CONFIGSAVE», отвечающей за хранение текущей конфигурации. Записи из данной таблицы должны заменить записи в таблице «CONFIG» при обновлении конфигурации. По наличию записей в данной таблице стало ясно, что изменения внесены не полностью. Также обнаружил таблицу «IBVERSION», предназначение которой на официальной странице не объясняется, но служит (скорее всего) для определения возможности работы конкретной версии клиента с информационной базой (md5 или еще как, судя по значению единственной записи в этой таблице с полями «IBVERSION» со значением -0 и «PLATFORMVERSIONREQ» со значением 80214). Главное, что в этой таблице нет BLOB-данных.

Так же при тестировании формата потока данной утилитой выяснилось, что многие записи из таблицы «CONFIG» не соответствуют заявленному размеру. Это были записи со значениями поля «FILENAME», уже присутствующими в таблице и постфиксом «.new» (например «ffbed849-c70b-423a-80bc-aef8c9f22a75» и «ffbed849-c70b-423a-80bc-aef8c9f22a75.new»), что тоже косвенно указывало на некорректное обновление.

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

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

Таблицу «DBSHEMAOG» я удалил, а из последнего идентичного варианта конфигурации взял таблицы: «DBSHEMA», «CONFIG», «CONFIGSAVE» (проще было взять пустую, чем удалять записи из текущей), «FILES», «IBVERSION», «PARAMS». Далее удалил по одной из таблиц с повторяющимися именами, о которых писал выше.

После этого запустил утилиту chdbfl.exe, которая написала что некоторые индексы рассогласованы с таблицами данных. Потом включил исправление и запустил еще раз. Ответом было, что ошибки исправлены.

Запустил платформу в режиме конфигуратора, сразу открылась конфигурация. Далее сделал «Тестирование и исправление» в режиме «Только тестирование». Тестирование прерывалось почти сразу с ошибкой «Таблица _DocumentJournalXXXXX не обнаружена» (название одной из таблиц индексов). Из чего делаем вывод, что утилита chdbfl.exe просто удалила таблицы индексов, которые были рассогласованы.

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

Запустил платформу в режиме конфигуратора, запустил «Тестирование и исправление» в режиме «Только тестирование». Тестирование прошло до конца, было только много информационных сообщений о том, что нет данных в таблица индексов по разным элементам справочников и документам (индексы старые). Запустил тестирование еще раз только уже в режиме «Тестирование и исправление» со всеми включенными флагами (переключатели для несуществующих объектов оставил в положении «Не изменять», т.к. при проверке chdbfl.exe ошибок о потере данных не было). Тест прошел полностью, получил сообщение что тестирование завершено.

Запустил базу в режиме предприятия. Все последние документы

Удачи всем, кто оказался в той же ситуации!