gifts2017

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

Опубликовал Yauhen Makei (mrDSide) в раздел Администрирование - Тестирование и исправление

С статье описан реальный опыт восстановления файловой информационной базы после сбоя при обновлении

Опыт восстановления файловой базы данных 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 (http://infostart.ru/public/19633/) от Валерия Агеева (http://infostart.ru/profile/13819/) . А так как файл был поврежден решился на использование альфа-версии данной утилиты с возможностью не только чтения таблиц, но и редактирования. Плюсом явилось то, что кроме самой утилиты на странице загрузки были ссылки на материалы автора по опыту обследования и восстановления информационных баз. Также весьма полезной оказалась информация о предназначении таблиц (http://1c-dn.com/library/data_structure_in_1c_enterprise_8/). Так же очень полезно прочесть перед дальнейшим чтением: http://infostart.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 ошибок о потере данных не было). Тест прошел полностью, получил сообщение что тестирование завершено.

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Николай Зайков (Mortiferus) 04.10.13 08:36
Спасибо за ссылки - все в одном месте. Не дай-то Бог, но вдруг когда и пригодится.
2. Алексей Роза (DoctorRoza) 04.10.13 08:41
Имею печальный, но поучительный, на всю рабочую карьеру, опыт неделания бэкапа. Не дай Бог ни Кому! Но за статьи спасибо! :)
3. andrewks 04.10.13 09:25
Запустил платформу в режиме конфигуратора, сразу открылась конфигурация. Далее сделал «Тестирование и исправление» в режиме «Только тестирование». Тестирование прерывалось почти сразу с ошибкой «Таблица _DocumentJournalXXXXX не обнаружена» (название одной из таблиц индексов). Из чего делаем вывод, что утилита chdbfl.exe просто удалила таблицы индексов, которые были рассогласованы.


позволю поставить под сомнение. утилита chdbfl.exe с галкой "исправлять" полностью перестраивает индексы на основании данных таблиц. значит, где-то что-то было сделано не так
4. yaugen (mrDSide) 04.10.13 10:00
Никто не мешает Вам самостоятельно провести эксперимент. А если Вы читали внимательно, то выше я описывал какие таблицы были "задублированы". Пишу, что утилита удалила таблицы, т.к. до проверки самостоятельно удалил только таблицы индексов, которые дублировались, а после проверки этой утилитой их не оказалось в ИБ вовсе (далее по тексту описываю, как взял их из последнего бэкапа). После этого ТиИ сделал всю работу в режиме "Конфигуратор".
5. andrewks 04.10.13 10:05
(4) yaugen, я провёл достаточно экспериментов, чтобы говорить то, что я сказал.

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

но то, что утилита chdbfl.exe с галкой "исправлять" полностью перестраивает индексы - это факт. в таком режиме даже алгоритм её работы совсем другой - она создаёт новый файл с БД, куда переносит все данные таблиц, которые ей удалось прочитать (при этом имеющиеся индексы не учитываются, в отличие от режима без галки), и полностью строит заново индексы
6. Yauhen Makei (mrDSide) 04.10.13 10:25
(5) andrewks, тоже очень может быть, но тогда не совсем понятно почему остались ссылки на эти таблицы (т.е. ТиИ в первый раз остановилось именно с этой ошибкой)
7. Адамчук Татьяна (т1951) 07.10.13 15:15
Спасибо! Был опыт давно в семёрке...
8. Татьяна Разинкина (105raz) 09.10.13 05:32
Да уж...Но на всякий случай возьму на заметку, тем более что у многих обновление происходит по интернету автоматически, а куда при этом программа пишет архив, никто и не знает
9. sanek sanek_gk (sanek_gk) 10.10.13 13:40
Самый лучший и быстрый способ восстановления файловой базы после неудачного обновления конфигурации - Делать бэкап перед обновлением конфигурации. Остальное считаю мазахизмом. Именно по этой причине 1сники всегда в типовой автоматической обновлялке пишут - "Обязательно сделайте бэкап перед обновлением", потому что нет никаких гарантий что вообще битые данные или структуры восстановить удастся.
10. Mariya Cherkasskaya (mcher) 20.11.13 07:16
Добрый день! Спасибо за рекомендации. Надеюсь не пригодится, но на заметку возьму. Плюсуем!
11. Ivan A. (ioff83) 06.02.14 19:02
Есть файл выгрузки ИБ не типовой конфигурации dt (45 Mb) с ошибкой при загрузке:

"Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Ошибка при выполнении операции над данными:
Устанавливаемое значение не помещается в поле таблицы '_SYSTEMSETTINGS._SETTINGSKEY'
по причине:
Устанавливаемое значение не помещается в поле таблицы '_SYSTEMSETTINGS._SETTINGSKEY'
"

Есть cf-шник.

Нужно по-максимуму восстановить базу. Реально (естественно не бесплатно)?
12. andrewks 06.02.14 20:40
(11) ioff83, скиньте ссылку мне в личку, посмотрю, что можно сделать
13. Yauhen Makei (mrDSide) 10.02.14 15:03
(11) ioff83, попробуйте все таблицы данных из этого дт перенести в чистую базу (дт без данных той же конфигурации). Сопоставить таблицы данных с конфигурацией можно с помощью утилиты Tool_1CD.exe
14. Елена Пименова (Bukaska) 10.02.14 17:13
Только плюсую))) Таких статей да побольше)))
15. ColaKola (ColaKola) 27.04.15 19:52
(11) ioff83, и для тех кто столкнется, лечится загрузкой в клиент-сервере режиме и очисткой настроек пользователей.
16. Екатерина Манишевская (djkate1) 15.05.15 15:54
Спасибо за вашу статью. Мне очень помогла. Удалила битые таблицы и импортировала со старой копии. Сделала тестирование.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа