SASGIS

Веб-картография и навигация

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

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

Модератор: Tolik

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

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

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

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

Забираем: sdb_util_1.0.2.8.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). Лог так же мог создать и САС, в папке с exe: sdb.log

Описание режимов работы:
скрытый текст: показать
Restore cache after crash: Recover & Verify
Последовательно вызывает функции: Recover environment [cmd: db_recover -v] и Verify cache (find broken files) [cmd: db_verify] с предустановленными настройками (с вкладки Config).

Recover environment [cmd: db_recover -v] (утилита db_recover)
Используя файлы лога из папки env кэша, восстанавливает кэш до валидного состояния: записывает все завершённые и откатывает все незавершённые транзакции. Так же, при этой операции опционально создаётся файл DB_CONFIG с выбранными установками.

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

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

Несколько слов про пресеты Durability:
скрытый текст: показать
1. Low - при записи в кэш, максимально используются буферы в памяти и запись на диск производится только если буферы переполняются или САС вызывает sync метод (каждые 5 мин или через 1024 операций записи в кэш). С такими настройками сейчас работает САС по-умолчанию (конфигурация зашита в коде), а вот новые версии САСа, планируется по-умолчанию заставить работать с пресетом Normal.
Пресет Low соответствует SQLite-овскому PRAGMA synchronous=OFF, со всеми вытекающими последствиями. Определяющим флагом, активирующим пресет, является флаг DB_TXN_NOSYNC:
If set, Berkeley DB will not write or synchronously flush the log on transaction commit. This means that transactions exhibit the ACI (atomicity, consistency, and isolation) properties, but not D (durability); that is, database integrity will be maintained, but if the application or system fails, it is possible some number of the most recently committed transactions may be undone during recovery. The number of transactions at risk is governed by how many log updates can fit into the log buffer, how often the operating system flushes dirty buffers to disk, and how often the log is checkpointed.

Или, говоря по-русски, тут не гарантируется полное восстановление кэша при падении САСа или винды.

2. Normal - файл лога пишется синхронно (после каждого коммита из буфера в памяти, производится запись в лог), но не даётся гарантий, что винда сбросит буфер и данные действительно запишутся в файл. Определяющий флаг - DB_TXN_WRITE_NOSYNC:
If set, Berkeley DB will write, but will not synchronously flush, the log on transaction commit. This means that transactions exhibit the ACI (atomicity, consistency, and isolation) properties, but not D (durability); that is, database integrity will be maintained, but if the system fails, it is possible some number of the most recently committed transactions may be undone during recovery. The number of transactions at risk is governed by how often the system flushes dirty buffers to disk and how often the log is checkpointed.

Или, говоря по-русски, тут не гарантируется полное восстановление кэша только при падении винды. Если же упадёт только САС, то по логам возможно всё восстановить. В SQLite это называется PRAGMA synchronous=NORMAL.

3. High - гарантированная запись в лог, т.е. после каждой транзакции, мало того, что данные записываются в файл лога, так ещё и вызывается системная функция (FlushFileBuffers), которая указывает Windows принудительно записать свой буфер на диск. Активирует данный пресет одновременное отключение флагов DB_TXN_NOSYNC и DB_TXN_WRITE_NOSYNC. В SQLite это называется PRAGMA synchronous=FULL.

4. Extremaly High - в дополнение к High, по возможности отключаются все буферы (в том числе и виндозный) при записи в лог и в кэш - экспериментальный пресет и насколько он лучше или хуже чем High, должны показать тесты (если кто возьмётся за них).

Чтобы активировать тот или иной пресет, нужно выполнить операцию Recover (db_recover), во время которой в папку env будет записан файлик DB_CONFIG с нужной конфигурацией. И при следующем запуске САС автоматически подхватит эти настройки.

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

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

config.gif

За это сообщение автора zed поблагодарили: 9
cycler (15 июн 2013, 21:43) • guf (15 авг 2012, 13:42) • igel72 (11 апр 2013, 10:17) • Papazol (03 авг 2012, 09:56) • Parasite (03 авг 2012, 16:19) • saldek (21 янв 2020, 10:17) • Tolik (03 авг 2012, 12:44) • vvstepa (05 апр 2017, 20:21) • xromeo (14 апр 2013, 11:43)
Рейтинг: 47.37%
 
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение zed » 20 авг 2012, 18:48

Появилась у меня в кэше ошибка:
Код: Выделить всё
c:\>db_verify k:\SAS.Planet\bin\cache_db\yasat\z18\75\42\301.171.sdb
db_verify: Page 101677: overflow item incomplete
db_verify: k:\SAS.Planet\bin\cache_db\yasat\z18\75\42\301.171.sdb: DB_VERIFY_BAD: Database verification failed
Verification of k:\SAS.Planet\bin\cache_db\yasat\z18\75\42\301.171.sdb failed.

Хотя, файл кэша открывается и вроде бы работает нормально. Не уверен точно, но может там пара тройка тайлов и пропала, но не суть. А вопрос в том, как починить кэш, чтобы verify не находил ошибок. Оказывается, в моём случае, всё оказалось довольно просто:
1. нужно создать дамп повреждённого файла:
Код: Выделить всё
db_dump -r -f 301.171.sdb.dump 301.171.sdb

2. удалить/забэкапить повреждённый файл и воссоздать его из дампа:
Код: Выделить всё
db_load -f 301.171.sdb.dump 301.171.sdb

После этого, verify ошибок уже не находит :)

За это сообщение автора zed поблагодарил:
Tolik (20 авг 2012, 20:48)
Рейтинг: 5.26%
 
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение Tolik » 20 авг 2012, 18:57

Ну а всё-таки можно как-то выяснить, сколько тайлов было-стало?
Tolik
Гуру
 
Сообщения: 2603
Зарегистрирован: 28 янв 2011, 10:38
Благодарил (а): 277 раз.
Поблагодарили: 515 раз.

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

Сообщение zed » 20 авг 2012, 19:07

Сколько было до момента повреждения? Никак.
А у текущего варианта можно попробовать утилитой db_stat.
Но вообще смысл этого действия? Ну узнали и что?
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение Tolik » 20 авг 2012, 20:48

Смысл - узнать, кэш абсолютно не пострадал или надо искать потерянные тайлы. Ну понятно, что лучше восстановить файл хотя бы частично, чем стереть совсем. Спасибо за способ восстановления! Может, как-то интегрировать его в sdb_util..
Tolik
Гуру
 
Сообщения: 2603
Зарегистрирован: 28 янв 2011, 10:38
Благодарил (а): 277 раз.
Поблагодарили: 515 раз.

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

Сообщение zed » 21 авг 2012, 09:27

Tolik писал(а):Может, как-то интегрировать его в sdb_util

Да, интегрирую :)
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение zed » 25 авг 2012, 20:54

Обновил утилитку (линк в первом посте) и добавил возможность исправлять ошибки в *.bad файлах (в файлах, на которые ругается db_verify).

Так же подправил первый пост и добавил туда описание режимов работы sdb_util.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение zed » 26 авг 2012, 16:24

Обновил до версии 1.0.2.2: добавил возможность в настройках выбирать тип дампа. Плюс, пара небольших исправлений.

P.S. У меня почему-то при использовании -r ключа у утилиты db_dump эта самая утилита на некоторых файлах кэша падает с ошибкой. А если запускать без ключа - всё ОК, создаётся нормальный дамп и из него все нормально восстанавливается. Поэтому я и вынес этот момент в настройки.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение Tolik » 26 сен 2012, 15:29

Восстанавливал БД утилитой из последнего релиза (забыл, что есть более новая).
Починил нормально, но заметил, что
1. при выборе опции "rename to *.bad" плохие файлы не переименовываются, а удаляются (не исправлено и в sdb_util_1.0.2.2)
2. Кстати, этот режим лучше сделать по умолчанию. Сейчас по умолчанию "report only", что неудобно: сначала долго ждёшь, потом оказывается, что ничего не исправлено, а в длинном-длинном логе найти ошибку трудно.
3. Отсюда ещё одно пожелание: сделать как-то список ошибок по результатам сканирования. Или хотя бы изменить лог: не выводить строки ExitCode = 0, Verification succeeded и т.п., обозначать ошибки другим цветом/шрифтом и т.п. Не знаю, что сделать проще.
4. И ещё одно, попроще: запоминать директорию.
5. И лог сохранять на диск.
Tolik
Гуру
 
Сообщения: 2603
Зарегистрирован: 28 янв 2011, 10:38
Благодарил (а): 277 раз.
Поблагодарили: 515 раз.

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

Сообщение zed » 26 сен 2012, 15:51

Tolik писал(а):4. И ещё одно, попроще: запоминать директорию.

Так вроде запоминается.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

След.

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

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

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