Восстановление убитого кэша Беркли (BerkeleyDB)

программа для загрузки и просмотра спутниковых снимков Земли, Луны, Марса предоставленных сервисами Google Maps и Космоснимки. Возможность работы с GPS приёмником.

Модераторы: Tolik, zed

Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение zed » 02 авг 2012, 23:30

По мотивам хотелки #1341 написал утилиту-помощника в нелёгком деле восстановления кэша. Хотя, строго говоря, я ещё не сталкивался с тем, чтобы мой кэш умер и не мог быть прочитан/восстановлен самим САСом при запуске (а "падает" САС у меня часто, т.к. запускаю я его преимущественно прямо в дебагере и имею привычку не всегда корректно завершать работу, а выходить по аналогу Ctrl+Alt+Del). Но, как говорится: "сани готовь летом" (c), так что, пусчай будет - авось когда и пригодится.

Итак, для восстановления баз Беркли поставщик оной БД (Оракл) предлагает нам в комплекте кучу различных консольных утилит. Утилиты там на все случаи жизни, какие только можно себе представить и всё бы хорошо, но для неподготовленного человека, встреча с консолью может быть весьма неприятна. Да и для гуру, выполнение однотипных рутинных операций через голую консоль, может отнимать лишнее время. Поэтому, представляю вам оболочку над некоторыми консольными утилитами (а именно: db_recover, db_verify, db_load и db_dump) с вшитыми настройками и минимальной конфигурацией. Настройки вполне достаточны для восстановления кэша Беркли в САСе (по крайней мере, пока кто-то не сообщит, что у него никак не выходит этот самый кэш восстановить). Если каких-то ключей/режимов вдруг не хватит - пишите, по возможности, добавим.

Забираем: sdb_util_1.0.2.5.7z + исходники для интересующихся

Инструкция к действию:
скрытый текст: показать
- закрываем САС
- распаковываем архив в папку с установленным САСом и соглашаемся с предложением заменить файлы
- запускаем sdb_util.exe
- выбираем папку с испорченным кэшем: path\to\cache_db\sat или даже целиком все карты: path\to\cache_db
- запускаем восстановление: Run
- по окончании процесса запускаем САС (предпочтительно - дебажную версию) и проверяем кэш на работоспособность
- если кэш по прежнему не работает, закрываем САС, возвращаемся в утилиту, жмём Config и выбираем "Rename broken files to *.bad" или "Restore broken files" (можно ещё включить Catastrophic recovery) и жмём Apply
- запускаем восстановление заново и по окончании, ещё раз проверяем в САС
- если и сейчас ничего не работает - пишите сюда и приложите логи (всё что писалось в чёрном окошке на всех этапах) и пару небольших битых файлов (*.bad). Лог так же мог создать и САС в папке с кэшем: \cache_db\sdb.log

Описание режимов работы:
скрытый текст: показать
Auto-Restore: Recover & Reset LSN & Verify
Последовательно вызывает функции: Recover to last good state [cmd: db_recover -v], Reset LSN [cmd: db_load -r lsn] и Verify (find broken files) [cmd: db_verify] с предустановленными настройками (с вкладки Config).

Recover to last good state [cmd: db_recover -v] (утилита db_recover)
Используя файлы лога из папки env кэша, восстанавливает кэш до валидного состояния: записывает все завершённые и откатывает все незавершённые транзакции. Особой необходимости в этой утилите нет, т.к. в САСе env создаётся с флагом DB_RECOVER, но в настройках (по кнопке Config) можно указать, чтобы использовался режим "катастрофы", тогда эта утилита выполняет некие дополнительные действия.

Reset LSN [cmd: db_load -r lsn] (утилита db_load)
Удаляет привязку файлов кэша (*.sdb) от файлов лога из папки env. Опционально, по окончанию процесса может удалять уже не нужную папку env вместе со всеми старыми логами.

Verify (find broken files) [cmd: db_verify] (утилита db_verify)
Проверяет файлы кэша (*.sdb) на ошибки. При обнаружении ошибок, в зависимости от настроек, может:
1. Не предпринимать никаких действий (Only report)
2. Удалить файл кэша, содержащий ошибку (Delete broken files). Использовать эту опции рекомендуется только в крайнем случае, т.к. а) ошибка может быть не критическая (САС может прекрасно работать с данным файлом кэша) и б) есть теоретическая возможность восстановить неповреждённые данные (см. ниже)
3. Переименовать файл в *.bad (Rename broken files to *.bad), который затем можно дополнительно анализировать/восстанавливать имеющимися утилитами.
4. Не отходя от кассы, попытаться восстановить повреждённый файл (Restore broken files). Следует учитывать, что эта операция достаточно медленная. Все действия, предпринимаемые программой будут аналогичны восстановлению данных из *.bad файлов (см. ниже).

Restore data from *.bad [cmd: db_dump && db_load] (утилиты db_dump и db_load)
1. Создаёт дамп данных из повреждённых файлов (пытается прочитать неповреждённые данные). При создании дампа используется утилита db_dump. Файл дампа имеет несколько бОльший размер, чем исходный файл *.sdb (примерно в 1,5-2 раза).
2. Из свежего дампа формирует новый файл кэша, с гарантией отсутствия ошибок (использует утилиту db_load). В качестве дополнительного бонуса, происходит оптимизация структуры файла кэша, в результате чего, он может быть меньшего размера (даже, если удалось восстановить абсолютно все данные). При этом, однако, нет возможности оценить количество восстановленных данных (в процентном или абсолютном выражении) по отношению к исходным данным.
3. По окончании процесса подчищает за собой хвосты: удаляет восстановленный *.bad файл и его файл дампа (*.dump).

Утилиту можно натравливать и на здоровый кэш, она его не испортит. Работу утилиты можно прерывать в любой момент времени, кэш при этом всегда будет оставаться работоспособным.

Пара скриншотов:

sdb.gif
Главное окно

sdb_config.gif
Окошко с настройками
Хитрости GoogleEarth - то, чего вы не знаете о гугле

За это сообщение автора zed поблагодарили: 5
guf (15 авг 2012, 13:42) • igel72 (11 апр 2013, 10:17) • Papazol (03 авг 2012, 09:56) • Parasite (03 авг 2012, 16:19) • Tolik (03 авг 2012, 12:44)
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение zed » 08 апр 2013, 16:17

Хитрости GoogleEarth - то, чего вы не знаете о гугле

За это сообщение автора zed поблагодарил:
T_Im (09 апр 2013, 22:44)
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение T_Im » 09 апр 2013, 22:35

Можно ли как нибудь пофиксить ошибки в уже восстановленной базе?

Прошелся по кешу последней версией sdb_util в режиме Verify (find broken files) [cmd: db_verify] (в режиме переименования в *.bad). Полученный 155.80.sdb.bad sdb_util в режиме Restore (с любыми опциями) не восстанавливается. По приведенному выше алгоритму утилитами из BerkeleyDB.v5.3.xx.7z дамп создается, но с ошибкой
db_dump: 155.80.sdb.bad: BDB0090 DB_VERIFY_BAD: Database verification failed
db_load создает из дампа базу, которая верифицируется без ошибок, но при просмотре в SAS часть тайлов отсутствуют с "Error [BerkeleyDB]: Bad magic value (UNKN)". Причем, экспортировать в SAS этот участок кеша нельзя - останавливается с такой же ошибкой (если через управление кеша - то вылетает с AV).

Статистика восстановленной базы (db_stat -d):
скрытый текст: показать
Tue Apr 09 21:36:06 2013 Local time
53162 Btree magic number
9 Btree version number
Little-endian Byte order
multiple-databases Flags
2 Minimum keys per-page
1024 Underlying database page size
239 Overflow key/data size
1 Number of levels in the tree
1 Number of unique keys in the tree
1 Number of data items in the tree
0 Number of tree internal pages
0 Number of bytes free in tree internal pages (0% ff)
1 Number of tree leaf pages
982 Number of bytes free in tree leaf pages (4% ff)
0 Number of tree duplicate pages
0 Number of bytes free in tree duplicate pages (0% ff)
0 Number of tree overflow pages
0 Number of bytes free in tree overflow pages (0% ff)
0 Number of empty pages
0 Number of pages on the free list

Восстановленный файл (86МБ) http://yadi.sk/d/9x4Mkb0N3vspX
-----
Еще аналогичная ситуация (14МБ) http://yadi.sk/d/ptyV3PSh3vzkk (примерно на координатах N57,570129° E34,919047°)
Обнаружил у себя в кешах еще много подобных "невотанавливаемых" баз. Если db_load выдает ошибку верификации при попытки записи дампа - почти стопроцентно такая база будет содержать после восстановления такие битые тайлы.
T_Im
Соображающий
 
Сообщения: 72
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 11 раз.
Поблагодарили: 8 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение T_Im » 10 апр 2013, 00:15

zed писал(а):...максимально-агрессивное восстановление (ключ -R). Менее агрессивный метод (-r) в этой версии библиотеки почему-то не работает. Попробуйте на более новой версии из аттача.

Еще подумал: а работают ли опция Salvage Data в текущей sdb_util? Не нужно ли заменить libdb51.dll на libdb53.dll и консольные утилиты на находящиеся в BerkeleyDB.v5.3.xx.7z?
Вложения
1.GIF
T_Im
Соображающий
 
Сообщения: 72
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 11 раз.
Поблагодарили: 8 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение zed » 10 апр 2013, 00:22

T_Im писал(а):Можно ли как нибудь пофиксить ошибки в уже восстановленной базе?

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

Такие файлы уже малоинтересны. Нужны оригинальные битые, чтобы можно было посмотреть, что там в них за ошибки.

И интересно, как вёл себя САС с битыми тайлами? Были какие-то ошибки?

T_Im писал(а):Если db_load выдает ошибку верификации при попытки записи дампа

Дамп пишет db_dump и по-идее, это он может ругаться, если файл сильно повреждён. А db_load должен отрабатывать без ошибок.

Не нужно ли заменить libdb51.dll на libdb53.dll и консольные утилиты на находящиеся в BerkeleyDB.v5.3.xx.7z?

Можно заменить. Только не в директории САСа. Утилита sdb_util просто вызывает ту или иную консольную утилиту, поэтому ей без разницы, какая там версия. А вот САС работает с libdb51.
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение T_Im » 10 апр 2013, 02:38

Вот пример оригинальной битой базы
http://yadi.sk/d/vcnS_41E3w7Dw (14M)
В SAS при просмотре таких баз как правило виснет картинка.

Еще сталкивался с тем, что обновив одну из летних версий SAS на одну из последних ночнушек, при переключении между картами что то портилось в папках env (при этом также висло изображение, помогал Reset LSN, в самих базах при этом вроде бы ничего не менялось) - даже не знаю, баг это был или фича.
T_Im
Соображающий
 
Сообщения: 72
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 11 раз.
Поблагодарили: 8 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение zed » 10 апр 2013, 09:03

T_Im писал(а):Вот пример оригинальной битой базы

Восстанавливается без ошибок (ни db_dump, ни db_load не ругается).
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение zed » 10 апр 2013, 09:23

T_Im писал(а):BerkeleyDB.v5.3.xx.7z дамп создается, но с ошибкой
db_dump: 155.80.sdb.bad: BDB0090 DB_VERIFY_BAD: Database verification failed

Так и должно быть, при использовании ключа -r:
Salvage data from a possibly corrupt file. When used on a uncorrupted database, this option should return equivalent data to a normal dump, but most likely in a different order.

Note that this option causes the utility to verify the integrity of the database before performing the database dump. If this verification fails, the utility will exit with error return DB_VERIFY_BAD even though the database is successfully dumped. If you are dumping a database known to be corrupt, you can safely ignore a DB_VERIFY_BAD error return.
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение T_Im » 10 апр 2013, 12:14

zed писал(а):
T_Im писал(а):Вот пример оригинальной битой базы

Восстанавливается без ошибок (ни db_dump, ни db_load не ругается).

Это самый маленький найденный пример, где в восстановленной базе, например, тайлы
76.38.sdb\x19560\y9942.jpg
76.38.sdb\x19561\y9942.jpg
76.38.sdb\x19560\y9943.jpg
76.38.sdb\x19562\y9943.jpg
выдают "Error [BerkeleyDB]: Bad magic value (UNKN)"
Если нужны примеры не восстановленных .bad, где db_dump ругается и после восстановления тоже есть тайлы с "Bad magic value", могу выложить (но сомневаюсь, что там что то принципиально иное).

Хочется понять, что можно сделать с базами, содержащими "Bad magic value", поскольку, по сути, кеши с такими базами неработоспособны несмотря на то, что верифицируются после восстановления без ошибок.
Можно ли их как нибудь выявить консольными утилитами? Можно ли восстановить содержимое тайлов с "Bad magic value"? Если нет - то как пересоздать bd с пропуском битых тайлов?
T_Im
Соображающий
 
Сообщения: 72
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 11 раз.
Поблагодарили: 8 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение zed » 10 апр 2013, 14:20

T_Im писал(а):Хочется понять, что можно сделать с базами, содержащими "Bad magic value"

Да собственно, ничего с ними делать не надо, подправлю САСа, чтобы он игнорил такие ошибки, а не кидал эксепшены и всё будет путём.
T_Im писал(а):Можно ли их как нибудь выявить консольными утилитами? Можно ли восстановить содержимое тайлов с "Bad magic value"? Если нет - то как пересоздать bd с пропуском битых тайлов?

Нет и нет. Пересоздать без битых - использовать db_dump без ключиков r/R.

Но это всё цветочки. Меня больше всего волнует, почему они бьются. Анализ некоторых логов и битых файлов показывает, что записи о завершенных транзакциях в них может присутствовать, но db_recover ни в какую не восстанавливает эти записи в БД. Или восстанавливает, но лишь отчасти и в малой степени. Почему так происходит - большой вопрос.
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Re: Восстановление убитого кэша Беркли (BerkeleyDB)

Сообщение zed » 10 апр 2013, 16:17

zed писал(а): Анализ некоторых логов и битых файлов показывает, что записи о завершенных транзакциях в них может присутствовать, но db_recover ни в какую не восстанавливает эти записи в БД. Или восстанавливает, но лишь отчасти и в малой степени. Почему так происходит - большой вопрос.

Но самое интересное, что что если просто запустить САС с этими битыми файлами, он их полностью восстанавливает по логам и они успешно проходят верификацию! Т.е. все эти заморочки с db_recover/verify/dump/load не только не приносят пользы, а наоборот - вредят. Ну, по крайней мере, пока САС работает и не пишет ошибок.

Поэтому мой совет: пока САС работает, не нужно гонять кэш всякими проверками. Даже если САС упал и verify что-то там пишет, после следующего запуска САС может самостоятельно всё починить по имеющимся логам.
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 1519
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 37 раз.
Поблагодарили: 177 раз.

Пред.След.

Вернуться в SAS.Планета

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 16

cron