1. zed Avatar zed
  2. Untitled project
  3. sdb_util
  4. Issues

Добавить способ восстановления с очисткой базы от мусора дополнительной утилитой

Issue #8 resolved
DCT created an issue

db_dump создает в дампе много мусора (дополнительные варианты баз, дополнительные варианты значений ключей, значения ключей без самих ключей ...), поэтому пересозданная потом db_load база часто оказывается нефункциональной. С целью убрать весь этот мусор из дампа, чтобы получить базу только с валидными тайлами, была написана консольная утилита. При чистке ею дампа, значения ключей проверяются на сигнатуры jpg и png, так что в очищенный дамп идут только небитые пары ключ-значение. Предлагается заменить в sdb_util неработающую опцию агрессивного восстановления -R и заменить его пунктом: "агрессивное восстановление -R с фильтром валидных jpg/png" команда при этом будет следующая: db_dump -R FN.bad | db_cleaner | db_load FN и если все будет гладко, то сделать это дефолтным вариантом восстановления .bad

Comments (25)

  1. zed repo owner

    значения ключей проверяются на сигнатуры jpg и png

    Но будут же проблемы с остальными форматами (kml/kmz/gif/bmp). Если уж делать такую утилиту, то проверку значений надо выполнять по их контрольным суммам. Тогда с форматами проблем не будет, да и значения версионных ключей вообще, кроме как по контрольной сумме, не отличишь от невалидных.

  2. DCT reporter

    Тоже думал об этом. Но если считать контрольные суммы, то сильно увеличится затраченное время (еще поленился разбираться где там в значении ключа позиция CRC и каким аллгоритмом оно вычисляется, т.к. для этого нужно глубоко вникать в код САС). В тоже время >90% кешей - это jpg/png, и как я видел, битые тайлы - это огрызки без конца, что сильно облегчает их выявление по сигнатурам. .kml и .gif можно легко добавить не меняя аглоритм, а вот с bmp и kmz будут уже проблемы, т.к. они, вроде бы, не имеют фиксированного hex-окончания файла.

    да и значения версионных ключей вообще, кроме как по контрольной сумме, не отличишь от невалидных.

    Поясните? Они разве в дампе не отдельными парами ключ-значение идут, где версия = последние 4 бита ключа?

  3. DCT reporter

    Может, сделать так: по дефолту jpg/png/kml/gif проверяю по hex-сигнатурам, но если вижу hex-начало bmp/kmz - то проверяю его полностью по CRC.

    И добавлю дополнительный ключ, при наличии которого (задается через GUI sdb_util) будет происходить полная проверка по CRC для всех типов тайлов.

  4. zed repo owner

    Но если считать контрольные суммы, то сильно увеличится затраченное время

    Время увеличится, но я бы не стал делать на этом акцент. Всё же, задача максимально точно восстановить данные, а не сделать это как можно быстрее. Ну займёт оно лишнюю минуту, и чёрт с ним.

    Они разве в дампе не отдельными парами ключ-значение идут, где версия = последние 4 бита ключа?

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

    В общем-то, я могу попробовать переписать вашу утилиту на Delphi, поскольку в SAS уже есть код парсинга и валидации данных, то вся сложность будет исключительно в логике чтения данных из дампа.

  5. zed repo owner

    Можете дать мне сорцы утилиты и какой-нибудь битый файл кэша для тренировок?

  6. DCT reporter

    исходник с подробным описанием алгоритма Битый кэш легко сделать самому, скопировав первые мегабайт 10 от любой базы. Можно, например, взять то, на чем я отлаживал работу версионного кеша http://rgho.st/68GnvcTX5 (80М)

    Для метаинформации, последние 2 байта ключа установлены в 0xFFFF

    Да, все забываю, что байт - это не один а два hex символа ) В моей утилитке все ключи, имеющие в конце ffff, печатаются без проверки (под это условие попадает также служебный тайл неверсионного кеша, ключ которого состоит из одних f).

  7. zed repo owner

    Ок, алгоритм очистки достаточно прост, поэтому сделаю вариант на Delphi с доп. проверками чексумм. Поскольку утилита внешняя, вы всегда сможете подменить её на свой вариант.

  8. DCT reporter

    Время увеличится, но я бы не стал делать на этом акцент.

    Я уже работал с содержимым тайлов (через pack H* содержимого тайла из дампа). Даже если не считать CRC, время обработки, увы, на перле возрастает в разы.

    Но, действительно, каждый может выбрать нужный вариант, и проверка на Делфи може будет быстрее, чем на Перле.

  10. DCT reporter

    Протестировал на нескольких базах (переименовал нормальные в .bad и запустил восстановление с включенной новой опцией). Дампы восстановленных и исходных баз совпадают.

  13. Former user Account Deleted

    Добрый день. Настала необходимость вновь воспользоваться утилитами восстановления БД, и вот, проблема. Тестовый билд, ссылка на который чуть выше, работает не так, как ожидалось. Вот что пишет в окне:

    [+] 2017-03-03 16:51:34.159 [Auto (Recover + Verify)]: I:\SASPlanet\cache\Google_sat_version\z14\

    VerifyCache.Read: I:\SASPlanet\cache\Google_sat_version\z14\4\1\18.7.sdbv << Exists: True; Changed: False; Verified: 2017-03-03 16:35:54.220 [0,3829 ms] VerifyCache.UpdateFull: ID = 2 << Updated: True; Status: Busy (4); Result: 0x00BADBAD (12245933) [2,2915 ms] "db_verify.exe" 18.7.sdbv [I:\SASPlanet\cache\Google_sat_version\z14\4\1] << Error: Не удается найти указанный файл VerifyCache.Update: ID = 2 << Updated: True; Status: Aborted (3); Result: 0xFFFFFFFF (4294967295) [0,9226 ms] Total processed: 1 (492,0 kB) [-] 2017-03-03 16:51:34.175 [Auto (Recover + Verify)]: I:\SASPlanet\cache\Google_sat_version\z14\

    То же самое происходит при попытке воспользоваться любой другой утилитой из набора. Что посоветуете?

    PS Честно сказать, в последнее время поведение базы Беркли меня немного напрягает. Я уже стал бояться обращаться к ней, особенно скачивать что-нибудь с одновременным построением карты заполнения. Шаг влево-вправо - и вылет, порча базы. Такое впечатление, что есть узкое место, через которое не успевают проскочить все необходимые данные. Это может быть внешний HDD?

  16. Former user Account Deleted

    Новый тестовый билд даёт аналогичный результат. Попробую вставить лог:

    [+] 2017-03-04 13:10:44.345 [Verify]: I:\SASPlanet\cache\Google_sat_version\z14\

    VerifyCache.Read: I:\SASPlanet\cache\Google_sat_version\z14\4\1\18.7.sdbv

    << Exists: True; Changed: False; Verified: 2017-03-03 16:51:34.175 [0,6388 ms]

    VerifyCache.UpdateFull: ID = 2

    << Updated: True; Status: Busy (4); Result: 0x00BADBAD (12245933) [3,1301 ms]

    "db_verify.exe" 18.7.sdbv [I:\SASPlanet\cache\Google_sat_version\z14\4\1]

    << Error: Не удается найти указанный файл

    VerifyCache.Update: ID = 2

    << Updated: True; Status: Aborted (3); Result: 0xFFFFFFFF (4294967295) [1,1329 ms]

    Total processed: 1 (492,0 kB)

    [-] 2017-03-04 13:10:44.595 [Verify]: I:\SASPlanet\cache\Google_sat_version\z14\

  17. zed repo owner

    Файл не заблокирован на запись? Может у него выставлен атрибут "Только для чтения"?

    Если скопировать его в другую папку и запустить проверку она тоже обломится?

    Другие файлы проверку проходят или такая проблема со всеми?

    Ошибку выдаёт утилита db_verify.exe. Попробуйте скопировать её (и все dll) в папку с файлом и выполнить команду в консоли: db_verify.exe 18.7.sdbv

  18. zed repo owner

    А может вы вообще не положили в папку с тестовой версией файлы от стабильной версии? В тестовом архиве ведь лежат только те файлы, которые изменились по сравнению со стабильной версией. Но все остальные файлы (типа db_verify.exe) ей тоже нужны.

  19. Former user Account Deleted

    А ведь да! Тут что было? Я скачал билд, поместил его в папку с утилитами. При попытке запуска начало ругаться на отсутствие библиотеки, не помню точно, но вроде sqlite. Я подумал, что, наверное, надо запускать из папки с самой программой, перекинул туда файлы из архивов (те, что скачал). А остальные файлы остались в той самой папке с утилитами! Вот и косяк. Однако, неудобно, когда все файлы свалены в одну кучу. Но придётся. Спасибо!

  20. zed repo owner

    Мне за три месяца так никто и не отписался, что тестовая утилита работает нормально, вот я до сих пор и не сделал нормальный архив со всеми необходимыми файлами. И да, эту утилиту и все её принадлежности лучше хранить в отдельной папке. Более того, в следующем релизе SAS я не планирую включать её в архив. К тому же, все существующие db_XXX.exe, которые сейчас есть даже в ночнушке, так же будут оттуда удалены.

  21. Former user Account Deleted

    Да, так уж вышло... Сейчас я всё-таки восстановил битые файлы на z14, упоминавшиеся в логе моём. Не без проблем. Потому что при восстановлении базы из дампа у меня опять произошёл краш, и это уже точно мой внешний HDD. Похоже, ему не хватает питания в некоторые моменты времени, и он отсоединяется от системы. Мне пришлось его передёрнуть, затем скопировать битые файлы на другой диск и восстанавливать их там, а потом уже восстановленные файлы копировать обратно. Ну да ладно, но сразу после этого при скачивании уже z15 опять вылет. Я запитал один из USB этого диска от внешнего источника, стал пытаться восстановить новые битые файлы (их оказалось два). Но тут меня постигла неудача, дампы не создаются. Похоже, я эти файлы потерял безвозвратно...

  22. zed repo owner

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

  26. Log in to comment
Assignee
Type
proposal
Priority
major
Status
resolved
Votes
0
Watchers
2
Jira Software: the preferred issue tracker for Bitbucket. Join the team!