Восстановление убитого кэша Беркли (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)

Сообщение Parasite » 28 сен 2012, 12:30

Tolik писал(а):Там в меню есть пункт "restore data from bad". Если интересно, можно попробовать восстановить и посмотреть, что получится.

Ну разве что в виде эксперимента - попробую вечерком. Там 18Мб всего в 2х файлах, оно при проверке общего кэша влетит быстрее чем я буду плясать с восстановлением этих двух...Уже влетело, наверное. :)
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Аватара пользователя
Parasite
Администратор
 
Сообщения: 4532
ICQ: 15819243
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 57 раз.
Поблагодарили: 214 раз.

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

Сообщение zed » 30 сен 2012, 18:49

Parasite писал(а):
Tolik писал(а):Так ведь есть признак работы: если долго думает над одним файлом, то в строке статуса крутится пропеллер.

У меня ничего не крутится.
Clipboard02.jpg

Крутится начинает, если обрабатывается файл размером более 50Мб.
Parasite писал(а):Так, вроде помогло. За ночь нашло 2 файла, переименовало их в .bad
Кеш САСом подцепился без ерроров.

zed, теперь куда с этими .bad? Я конечно в сасе дал проверку на прокачку кэша заново, что в кэше не найдет - докачает...но эти два файла для вивисекции нужны, или просто стереть?

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

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

Сообщение Parasite » 30 сен 2012, 22:21

zed писал(а):Крутится начинает, если обрабатывается файл размером более 100Мб.

В моем случае была хренова туча файлов по ~10Мб. И непонятно - работало оно, или зависло...
Может разрешить крутилку на файлы любого размера?
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Аватара пользователя
Parasite
Администратор
 
Сообщения: 4532
ICQ: 15819243
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 57 раз.
Поблагодарили: 214 раз.

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

Сообщение zed » 30 сен 2012, 22:29

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

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

Сообщение Parasite » 01 окт 2012, 05:35

zed писал(а):строчки в логе должны были бежать

"Бежать"? Оптимист, однако.
Изменялось раз в пару\тройку минут (посему на ночь и оставлял, собссно). На этом промежутке - сиди и думай, еще работает оно или уже нет.

Впрочем, некритично. Главное, что таки починило.
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Аватара пользователя
Parasite
Администратор
 
Сообщения: 4532
ICQ: 15819243
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 57 раз.
Поблагодарили: 214 раз.

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

Сообщение Tolik » 01 окт 2012, 08:35

Может пропеллер из-за вайна не крутился... Хотя это просто текст \|/-
Tolik
Гуру
 
Сообщения: 1624
Зарегистрирован: 28 янв 2011, 10:38
Благодарил (а): 68 раз.
Поблагодарили: 242 раз.

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

Сообщение Parasite » 01 окт 2012, 09:33

Tolik писал(а):Может пропеллер из-за вайна не крутился...

Проверялось на 2003Serv, кое работало в виртуалке. Скорее всего именно из-за серверной оси - там пользовательские приложения запускаются намного строже, с кучами огораживающих политик. Посему и падает намного меньше - последний блюскрин я в этом видел аж в прошлом году, даже соскучился уже... :)
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Аватара пользователя
Parasite
Администратор
 
Сообщения: 4532
ICQ: 15819243
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 57 раз.
Поблагодарили: 214 раз.

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

Сообщение T_Im » 10 окт 2012, 11:35

Есть кеш, утилита sdb_util версией из шапки проходит его в режиме verify без ошибок, но кеш глючит (не идет построение карты заполнения). Если экспортировать его, SAS вылетает с ошибкой - см. вложение
что можно сделать (кроме удалить битый файл)?
(битая часть базы http://zalil.ru/33836858 37МБ)
Вложения
err.GIF
T_Im
Соображающий
 
Сообщения: 72
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 11 раз.
Поблагодарили: 8 раз.

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

Сообщение zed » 10 окт 2012, 11:39

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

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

Сообщение T_Im » 17 окт 2012, 01:01

Как быть с таким невосстановимым кешем?

скрытый текст: показать
db_verify ...\z19\155\81\621.324.sdb

db_verify: Page 2801: offpage item 21 has bad pgno 272202
db_verify: Page 2801: offpage item 33 has bad pgno 272215
db_verify: Page 2801: offpage item 37 has bad pgno 272227
db_verify: Page 2801: item order check unsafe: skipping
db_verify: Page 8302: invalid prev_pgno 272987
db_verify: Page 15570: invalid prev_pgno 274029
db_verify: Page 40814: offpage item 39 has bad pgno 272117
db_verify: Page 40814: offpage item 41 has bad pgno 273036
db_verify: Page 40814: offpage item 43 has bad pgno 272124
db_verify: Page 40814: offpage item 45 has bad pgno 273044
db_verify: Page 40814: offpage item 55 has bad pgno 272131
db_verify: Page 40814: offpage item 57 has bad pgno 273051
db_verify: Page 40814: offpage item 59 has bad pgno 272138
db_verify: Page 40814: offpage item 61 has bad pgno 273058
db_verify: Page 40814: item order check unsafe: skipping
db_verify: Page 127055: offpage item 11 has bad pgno 272304
db_verify: Page 127055: offpage item 15 has bad pgno 272317
db_verify: Page 127055: offpage item 17 has bad pgno 273073
db_verify: Page 127055: item order check unsafe: skipping
db_verify: Page 128366: invalid prev_pgno 272483
db_verify: Page 133767: invalid prev_pgno 272841
db_verify: Page 262994: invalid prev_pgno 274488
db_verify: Page 263887: invalid next_pgno 274132
db_verify: Page 263887: offpage item 7 has bad pgno 272647
db_verify: Page 263887: offpage item 9 has bad pgno 274062
db_verify: Page 263887: offpage item 11 has bad pgno 273388
db_verify: Page 263887: offpage item 13 has bad pgno 274069
db_verify: Page 263887: offpage item 15 has bad pgno 273401
db_verify: Page 263887: offpage item 17 has bad pgno 274082
db_verify: Page 263887: offpage item 35 has bad pgno 272660
db_verify: Page 263887: item order check unsafe: skipping
db_verify: Page 266608: invalid next_pgno 272553
db_verify: Page 266608: offpage item 25 has bad pgno 272545
db_verify: Page 266608: offpage item 27 has bad pgno 273298
db_verify: Page 266608: offpage item 29 has bad pgno 272554
db_verify: Page 266608: offpage item 31 has bad pgno 273308
db_verify: Page 266608: offpage item 41 has bad pgno 272559
db_verify: Page 266608: offpage item 43 has bad pgno 273313
db_verify: Page 266608: offpage item 45 has bad pgno 272565
db_verify: Page 266608: offpage item 47 has bad pgno 273319
db_verify: Page 266608: offpage item 49 has bad pgno 273960
db_verify: Page 266608: offpage item 51 has bad pgno 274612
db_verify: Page 266608: offpage item 53 has bad pgno 273971
db_verify: Page 266608: offpage item 55 has bad pgno 274623
db_verify: Page 266608: offpage item 57 has bad pgno 273978
db_verify: Page 266608: offpage item 59 has bad pgno 274632
db_verify: Page 266608: offpage item 61 has bad pgno 273984
db_verify: Page 266608: offpage item 63 has bad pgno 274638
db_verify: Page 266608: item order check unsafe: skipping
db_verify: Page 266683: offpage item 43 has bad pgno 272764
db_verify: Page 266683: offpage item 47 has bad pgno 272777
db_verify: Page 266683: item order check unsafe: skipping
db_verify: Page 266809: invalid prev_pgno 272894
db_verify: Page 267104: invalid next_pgno 273064
db_verify: Page 267104: offpage item 25 has bad pgno 272145
db_verify: Page 267104: offpage item 27 has bad pgno 273065
db_verify: Page 267104: offpage item 29 has bad pgno 272152
db_verify: Page 267104: item order check unsafe: skipping
db_verify: Page 267849: invalid next_pgno 272987
db_verify: Page 268218: offpage item 37 has bad pgno 272240
db_verify: Page 268218: offpage item 41 has bad pgno 272252
db_verify: Page 268218: offpage item 53 has bad pgno 272265
db_verify: Page 268218: offpage item 57 has bad pgno 272278
db_verify: Page 268218: item order check unsafe: skipping
db_verify: Page 269529: invalid next_pgno 272483
db_verify: Page 269529: offpage item 25 has bad pgno 272471
db_verify: Page 269529: offpage item 27 has bad pgno 273223
db_verify: Page 269529: offpage item 29 has bad pgno 272484
db_verify: Page 269529: offpage item 31 has bad pgno 273235
db_verify: Page 269529: offpage item 41 has bad pgno 272493
db_verify: Page 269529: offpage item 43 has bad pgno 273246
db_verify: Page 269529: offpage item 45 has bad pgno 272504
db_verify: Page 269529: offpage item 47 has bad pgno 273258
db_verify: Page 269529: offpage item 49 has bad pgno 273890
db_verify: Page 269529: offpage item 51 has bad pgno 274538
db_verify: Page 269529: offpage item 53 has bad pgno 273902
db_verify: Page 269529: offpage item 55 has bad pgno 274551
db_verify: Page 269529: offpage item 57 has bad pgno 273913
db_verify: Page 269529: offpage item 59 has bad pgno 274563
db_verify: Page 269529: offpage item 61 has bad pgno 273923
db_verify: Page 269529: offpage item 63 has bad pgno 274574
db_verify: Page 269529: item order check unsafe: skipping
db_verify: Page 269625: invalid prev_pgno 272553
db_verify: Page 269625: invalid next_pgno 274029
db_verify: Page 269625: offpage item 33 has bad pgno 272609
db_verify: Page 269625: offpage item 35 has bad pgno 273356
db_verify: Page 269625: item order check unsafe: skipping
db_verify: Page 269672: invalid prev_pgno 272646
db_verify: Page 269777: invalid next_pgno 272841
db_verify: Page 269777: offpage item 11 has bad pgno 272790
db_verify: Page 269777: offpage item 15 has bad pgno 272803
db_verify: Page 269777: offpage item 17 has bad pgno 273517
db_verify: Page 269777: offpage item 19 has bad pgno 274197
db_verify: Page 269777: offpage item 21 has bad pgno 273530
db_verify: Page 269777: offpage item 23 has bad pgno 274210
db_verify: Page 269777: offpage item 25 has bad pgno 273543
db_verify: Page 269777: offpage item 27 has bad pgno 274223
db_verify: Page 269777: offpage item 29 has bad pgno 273556
db_verify: Page 269777: offpage item 31 has bad pgno 274236
db_verify: Page 269777: offpage item 43 has bad pgno 272816
db_verify: Page 269777: offpage item 47 has bad pgno 272829
db_verify: Page 269777: item order check unsafe: skipping
db_verify: Page 270460: invalid next_pgno 273131
db_verify: Page 270460: offpage item 27 has bad pgno 272375
db_verify: Page 270460: offpage item 29 has bad pgno 273132
db_verify: Page 270460: offpage item 31 has bad pgno 272387
db_verify: Page 270460: offpage item 33 has bad pgno 273143
db_verify: Page 270460: item order check unsafe: skipping
db_verify: Page 270850: invalid next_pgno 272894
db_verify: Page 270850: offpage item 19 has bad pgno 272868
db_verify: Page 270850: offpage item 23 has bad pgno 272881
db_verify: Page 270850: offpage item 35 has bad pgno 272895
db_verify: Page 270850: offpage item 39 has bad pgno 272908
db_verify: Page 270850: offpage item 41 has bad pgno 273620
db_verify: Page 270850: offpage item 43 has bad pgno 274300
db_verify: Page 270850: offpage item 45 has bad pgno 273632
db_verify: Page 270850: offpage item 47 has bad pgno 274313
db_verify: Page 270850: offpage item 49 has bad pgno 273645
db_verify: Page 270850: offpage item 51 has bad pgno 274326
db_verify: Page 270850: offpage item 53 has bad pgno 273658
db_verify: Page 270850: offpage item 55 has bad pgno 274338
db_verify: Page 270850: item order check unsafe: skipping
db_verify: Page 271075: offpage item 25 has bad pgno 272075
db_verify: Page 271075: offpage item 29 has bad pgno 272088
db_verify: Page 271075: offpage item 41 has bad pgno 272099
db_verify: Page 271075: offpage item 43 has bad pgno 273012
db_verify: Page 271075: offpage item 45 has bad pgno 272109
db_verify: Page 271075: offpage item 47 has bad pgno 273024
db_verify: Page 271075: item order check unsafe: skipping
db_verify: Page 271322: offpage item 39 has bad pgno 272291
db_verify: Page 271322: item order check unsafe: skipping
db_verify: Page 271405: offpage item 17 has bad pgno 272329
db_verify: Page 271405: offpage item 19 has bad pgno 273085
db_verify: Page 271405: offpage item 21 has bad pgno 272341
db_verify: Page 271405: offpage item 23 has bad pgno 273097
db_verify: Page 271405: offpage item 33 has bad pgno 272352
db_verify: Page 271405: offpage item 35 has bad pgno 273108
db_verify: Page 271405: offpage item 37 has bad pgno 272364
db_verify: Page 271405: offpage item 39 has bad pgno 273120
db_verify: Page 271405: offpage item 41 has bad pgno 273749
db_verify: Page 271405: offpage item 45 has bad pgno 273759
db_verify: Page 271405: offpage item 57 has bad pgno 273771
db_verify: Page 271405: offpage item 59 has bad pgno 274416
db_verify: Page 271405: offpage item 61 has bad pgno 273783
db_verify: Page 271405: offpage item 63 has bad pgno 274428
db_verify: Page 271405: item order check unsafe: skipping
db_verify: ...\z19\155\81\621.324.sdb: DB_VERIFY_BAD: Database verification failed
Verification of ...\z19\155\81\621.324.sdb failed.
ExitCode = 1

db_dump -f ...\z19\155\81\621.324.sdb.dump ...\z19\155\81\621.324.sdb.bad
ExitCode = 1


Кеш убился при падении в синий экран винды XP (шла закачка, упало не от нее), никакие режимы восстановления не дают результат (причем при режиме "Salvage data" db_dump вылетает с ошибкой "Инструкция .... обратилась к памяти... Пямять не может быть "read"").
Файл 621.324.sdb 270М, если надо - могу выложить.
T_Im
Соображающий
 
Сообщения: 72
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 11 раз.
Поблагодарили: 8 раз.

Пред.След.

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

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

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

cron