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

[zed]

Новая версия: sdb_util_1.0.2.5.7z

Содержит исправления багов:
- #1: Ошибка с переименованием .BAD файла
- #2: Баг при отмене Reset LSN

[T_Im]

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

Прошелся по кешу последней версией 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]

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

Еще подумал: а работают ли опция Salvage Data в текущей sdb_util? Не нужно ли заменить libdb51.dll на libdb53.dll и консольные утилиты на находящиеся в BerkeleyDB.v5.3.xx.7z?

[zed]

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

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

Восстановленный файл

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

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

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

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

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

Можно заменить. Только не в директории САСа. Утилита sdb_util просто вызывает ту или иную консольную утилиту, поэтому ей без разницы, какая там версия. А вот САС работает с libdb51.

[T_Im]

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

Еще сталкивался с тем, что обновив одну из летних версий SAS на одну из последних ночнушек, при переключении между картами что то портилось в папках env (при этом также висло изображение, помогал Reset LSN, в самих базах при этом вроде бы ничего не менялось) - даже не знаю, баг это был или фича.

[zed]

Вот пример оригинальной битой базы

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

[zed]

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.

[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 с пропуском битых тайлов?

[zed]

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

Да собственно, ничего с ними делать не надо, подправлю САСа, чтобы он игнорил такие ошибки, а не кидал эксепшены и всё будет путём.

Можно ли их как нибудь выявить консольными утилитами? Можно ли восстановить содержимое тайлов с "Bad magic value"? Если нет - то как пересоздать bd с пропуском битых тайлов?

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

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

[zed]

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

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

Поэтому мой совет: пока САС работает, не нужно гонять кэш всякими проверками. Даже если САС упал и verify что-то там пишет, после следующего запуска САС может самостоятельно всё починить по имеющимся логам.