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 » 29 ноя 2014, 20:22

Gma писал(а):Имеджери работает

Не факт, что так будет и дальше.
Gma писал(а):а Ях так и не хочет

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

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

Сообщение Gma » 29 ноя 2014, 20:24

И ещё. сейчас заметил, что куда-то делись несколько уровней карты. Вот список существующих:
env\
z10\
z11\
z12\
z13\
z16\
z17\
Gma
Советчик
 
Сообщения: 427
Зарегистрирован: 10 апр 2011, 23:10
Благодарил (а): 35 раз.
Поблагодарили: 71 раз.

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

Сообщение Gma » 29 ноя 2014, 20:29

zed писал(а):Указанный файл удаляли?
да, всё сделал по рецепту.
Приведите содержимое папки env
__db.register
DB_CONFIG
__db.001
__db.002
__db.003
__db.004
__db.005
__db.006
log.0000000001
выложите её на обменник.
http://progressor.ru/gm/book/env.zip
Gma
Советчик
 
Сообщения: 427
Зарегистрирован: 10 апр 2011, 23:10
Благодарил (а): 35 раз.
Поблагодарили: 71 раз.

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

Сообщение zed » 29 ноя 2014, 20:32

Gma писал(а):куда-то делись несколько уровней карты

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

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

Сообщение zed » 29 ноя 2014, 20:50

Проблема в отсутствии sdb файлов в кэше. В логе есть ссылки на файлы z5/z6/z14 а у вас этих папок нету, вот оно и обламывается.

Плюс ко всему, файл лога создан 16.09.2013 и в нём не более 2 Мб данных. Поскольку порядковый номер у файла log.0000000001 то очевидно, других файлов небыло и в кэш ничего больше не писалось. К тому же, последняя запись в логе датирована также 2013 годом:
Код: Выделить всё
Mon Sep 16 22:25:18 2013

Что-то вы у себя намудрили и я вам тут не помогу, потому как восстанавливать тут попросту нечего. Или лог не от этого кэша или одно из двух.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение zed » 29 июл 2016, 21:20

Обновил утилиту sdb_util:
- вроде исправил баги;
- добавил настройки логирования в файл (None - не сохранять, Normal - по мере заполнения лога в памяти или в конце проверки, Extreme - при выводе каждой строчки в лог на экран, она сперва сохраняется в файл);
- добавил опцию, чтобы лог не перезаписывался, а дописывался;
- добавил опцию ограничения на размер лога в памяти (который в чёрное окошко пишется);
- добавил ключ командной строки --autostart для автозапуска проверки при старте программы;
- добавил кэширование результатов проверки, чтобы не перепроверять файлы, не изменившиеся с прошлой проверки (требует sqlite3.dll);
- сделал отдельную утилиту sdb_info.exe для просмотра статистики (см скриншот).

Архив пока что с приставкой *_test, жду отзывы по результатам тестирования: https://bitbucket.org/zedxxx/sdb_util/d ... 3_test.zip

Image 1.png

Спонсор этого масштабного обновления - пользователь sergbrother, большое ему спасибо.

За это сообщение автора zed поблагодарили: 2
Merh (29 июл 2016, 22:50) • Papazol (30 июл 2016, 00:30)
Рейтинг: 10.53%
 
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение T_Im » 18 окт 2016, 02:10

Столкнулся с битым кешем. Восстановить с ходу не удалось, пришлось разбираться с логикой работы утилит. Это конспект опыта, соображений и найденных в работе утилит баго-фич.

Простой кейс: файл 616.316.sdb.bad ~200М, тип ошибки: "обнулился" конец базы - последние ~10% файла сплошные нули (файл по просьбе могу выложить, но такую ситуацию можно смоделировать и на меньшем файле).

Достаточно большая часть тайлов из этой базы читаются в SAS планете, и даже частично экспортируются, но периодически происходит "завис" на битых тайлах. Выделив большую область смог экспортировать ~77М тайлов, т.е. выделяя маленькие участки и экспортируя их в тайловый кеш, следуя логике повреждения, можно восстановить предположительно до 90% тайлов).

Итоги восстановления с помощью sdb_util_1.3
Выбирается вариант восстановления .bad файлов (Restore broken files from *.bad [cmd: db_dump && db_load]) поочередно тестировал все 3 возможных варианта восстановления.

а) по дефолту (без дополнительных ключей в настройках).
Процесс происходит без ошибок. Казалось бы можно радоваться, но... размер файла 616.316.sdb = 11,486 М! (<6% от исходного) :o
Это, похоже, читает и восстанавливает базу только до первой ошибки.
Более того, файл *.sdb.bad после восстановления НАСОВСЕМ УДАЛЯЕТСЯ (особо цинично при этом читается рекомендация из шапки выкладывать .bad файлы после рекавери "если что то не работает" :lol: ).
Нельзя же так по дефолту совершать деструктивные действия, даже в SAS планете из таких бэдов можно вытянуть в разы больше тайлов!
Еще отмечу (это касается и следующего пункта рекавери), что создавать дамп - неправильно, т.к. db_dump и db_load прекрасно работают с потоками.
В итоге этот пункт стоит реализовывать следующим образом (в итоге не будем зря гонять диск, дополнительно записывая и потом считывая огромный дамп):
db_dump.exe 616.316.sdb.bad | db_load 616.316.sdb


б) salvage data (-r) спотыкается на этапе дампа:
Ошибка db_dump.exe: пямять не может быть read
Да, уже говорилось, что в версии утилит 5.1 "db_dump -r" нерабочий. Чтобы это обойти, достаточно взять db_dump.exe и libdb53.dll из версии 5.3 (можно 6.1, но не 6.3). Поскольку остальные утилиты и SAS жестко завязаны на libdb51.dll, такой финт никаких конфликтов не создаст.
Но это не помогает: видно, что создается файл 616.316.sdb.dump, но дальше происходит затык и дамп просто удаляеся! Почему не срабатывает db_load? Запись в логах:
Код: Выделить всё
db_dump.exe: 616.316.sdb.bad: DB_VERIFY_BAD: Database verification failed
<< ExitCode = 1
наталкивает на мысль, что получив ExitCode = 1 sdb_info просто прерывает восстановление, в то время как согласно документации
"If you are dumping a database known to be corrupt, you can safely ignore a DB_VERIFY_BAD error return."
Еще полученный дамп не имеет в заголовке "правильной" строчки db_pagesize=1024, однако его можно грузить без редактирования заголовка задав pagesize вручную. Итого правильно было бы так:
Код: Выделить всё
db_dump.exe -r 616.316.sdb.bad | db_load -c db_pagesize=1024 616.316.sdb
В некоторых случаях так удается создать более менее рабочую базу (на которую все равно ругается SAS), но в этот раз получился файл ~180МБ, с которым SAS не смогла работать (сыпятся ошибки и все зависает):
Код: Выделить всё
BerkeleyDB: путь\616.316.sdb: multiple databases specified but not supported by file [root path: "путь к папке с кешем"]


в) Aggressively salvage data (-R)
та же ошибка ошибочного завершения создания дампа по "ложному" коду ошибки. Но даже ее игнорирование помогло бы:
Код: Выделить всё
db_load -f 616.316.sdb.dump 616.316.sdb
db_load.exe: line 1: unexpected format
ибо при дампе с ключем -R в заголовке дампа будут лишние две строчки, из-за которых db_load не сможет воссоздать из дампа базу. Т.о. без дополнительных утилит этот пункт в принципе невозможно сделать работоспособным.
Получающаяся база, если поменять заголовок и загрузить дамп db_load, ведет себя аналогично предыдущему пункту.

Вывод: sdb_util идеально подходит для устранения мелких ошибок, но если после проверки образовались .bad файлы, нельзя использовать штатное рекавери *.bad файлов: опции, способные максимально полностью восстановить данные, не функциональны, а единственная работающая дефолтная опция чревата большой потерей данных!

Поскольку ниже найден оптимальный метод восстановления базы, рекомендуется включить его и использовать по умолчанию в sdb_util (а также добавить опцию "удалять *.bad файлы после восстановления"). Пока же рекомендуется использовать описанную ниже методику восстановления .bad файлов.
Последний раз редактировалось T_Im 19 окт 2016, 20:23, всего редактировалось 3 раз(а).
T_Im
Постигающий Дао
 
Сообщения: 112
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 15 раз.
Поблагодарили: 14 раз.

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

Сообщение T_Im » 18 окт 2016, 17:39

Продолжаю конспект.

Как выглядит дамп?
сначала идет заголовок
скрытый текст: показать
при дампе базы без доп. ключей и с ключем -R
Код: Выделить всё
VERSION=3
format=bytevalue
database=
type=btree
db_pagesize=1024
HEADER=END
при дампе с ключем -r
Код: Выделить всё

00000002
VERSION=3
format=bytevalue
type=btree
HEADER=END

Затем идут пары строчек ключ-значение.
Сравнивая дампы нормальной и битой баз сразу же становятся видны отличия и понятны причины возникновения проблем (см. вложения):

а) битые тайлы и тайлы без ключей
появляются при дампе -r/-R (в последнем варианте их существенно больше). После загрузки дампа, по всей видимости, они беспрепятственно уходят в базу, вызывая недовольство SAS. Восстановленная база не будет до конца работоспособна, только экспорт bdb-bdb, возможно, это может фиксить.

б) несколько баз внутри одного дампа (дополнительные база/базы возникают как с ключем -r, так и с ключем -R). Это причина ошибки SAS о "multiple databases" (см. выше). Если такое произошло - все тайлы из второй и последующих баз невозможно восстановить штатными средствами. В моем случае те восстановленные 11М и есть первая база (режим восстановления без ключей).
Если грузить db_load полученные с ключами -r/-R большие дампы, то эти несколько баз включаются в состав одной базы sbd, однако SAS частично может работать опять таки только с первой из них: при экспорте bdb2bdb через "управлением кэша" из полученного большого восстановленного файла sdb экспортируется только те 11М первой базы.

Теперь становится понятно как с этим бороться: из дампа надо взять все пары строк ключ-тайл, в которых лежат валидные тайлы.
Для фильтрации была написана элементарная утилитка на перле, которая фильтрует пары ключ-тайл, по следующим условиям:
- длина строки ключа = 18 (включая символ переноса строки)
- у тайла на 86-м месте стоит hex-код начала jpg-а ffd8ff
- конец строки тайла совпадает с hex-кодом конца jpg-а ffd9 (не уверен в строгости условия)
Полученный фильтрованный дамп уже можно превратить в полностью работоспособную базу db_load и вернуть в кэш.

Итог восстановления: файл 616.316.sdb
из дампа, полученного с ключем -r ~176040К
из дампа, полученного с ключем -R 177112К
:ugeek:
Вложения
!recov_!дамп.PNG
основные особенности структуры дампа
!recov_вторая база.PNG
вторая база внутри дампа
!recov_битые в конце.PNG
тайлы без ключей в конце базы
Последний раз редактировалось T_Im 19 окт 2016, 20:21, всего редактировалось 1 раз.
T_Im
Постигающий Дао
 
Сообщения: 112
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 15 раз.
Поблагодарили: 14 раз.

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

Сообщение T_Im » 18 окт 2016, 21:53

Заметки по результатам восстановления.

База из "-r дампа" содержит 10178 тайлов, из "-R дампа" на 64 тайла больше. Общие файлы между ними одинаковы (распаковал в файловый формат и проанализировал)

Возможные проблемы.

1) Проблема единственности.
Насколько я понимаю, db_load последовательно закидывает все встреченные пары ключ-тайл в восстанавливаемую .sdb. Т.о. если у одного ключа при чтении дампа будет встречено несколько значений, в .sdb уйдет последнее встреченное.
- может ли теоретически такое быть с дампами?
(В распакованных "-r" и "-R" кешах файлы с одинаковыми путями имеют одинаковые md5. Наличие разных тайлов с одним ключем в имеющихся дампах пока не проверял)
- может ли один и тот же тайл попасть в разные ключи? (проверил, в моих кэшах дубликаты тайлов не найдены)

2) проблема битости.
- может ли у jpg-а в дампе быть валидным начало и конец, но побиться середина? (badpeggy в распакованных кэшах их не нашла)
NB: с ключем -r в дампе нет ни одной записи тайла, где есть валидное jpg начало, но нет валидного jpg конца. Но с ключем -R в дампе уже появляются ~30 jpg "огрызков".
Последний раз редактировалось T_Im 19 окт 2016, 03:18, всего редактировалось 1 раз.
T_Im
Постигающий Дао
 
Сообщения: 112
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 15 раз.
Поблагодарили: 14 раз.

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

Сообщение T_Im » 19 окт 2016, 03:17

По итогам выкладываю утилиту для очистки дампа от мусора, которая должна дополнить комплект имеющихся db_* утилит для наших нужд.

Использование
Код: Выделить всё
db_cleaner -fi файлдампа -fo файлочищенногодампа
если один или оба -fi/-fo не указаны, то чтение/запись будут происходить со STDIN/STDOUT соответственно (по аналогии db_dump/db_load).
Утилита отфильтровывает из дампа валидные jpg и png тайлы (проверяется соответствие сигнатур начала/конца файла).

Примеры использования:
очистка дампа 616.317.sdb.dump в дамп 616.317.sdb.cdump:
db_cleaner -fi 616.317.sdb.dump -fo 616.317.sdb.cdump

очистка дампа 616.317.sdb.dump с одновременной загрузкой результата в рабочую базу:
db_cleaner -fi 616.317.sdb.dump | db_load 616.317.sdb

Это должно стать основным вариантом рекавери: создаем из *.bad сразу рабочую *.sdb (тайлы плавно перетекают из битой базы в рабочую через память без промежуточных файлов на диске) :thumbup: :
db_dump -R 616.317.sdb.bad | db_cleaner | db_load 616.317.sdb

Пока в sdb_util не входит такой вариант рекавери, сделал кнопочку для атоматизации процесса восстановления в Total Commander
скрытый текст: показать
положить файл db_ClearRebuild.bat (и db_cleaner.exe !) из архива в папку sdb_util, скопировать следующий код (поправить в 2-х местах путь к папке sdb_util на свой)
Код: Выделить всё
TOTALCMD#BAR#DATA
d:\sdb_util_13\db_ClearRebuild.bat
"%P%O.%E" "%P%O"
shell32.dll,65
Построить базу *.sbd на основе файла *.bad под курсором
d:\sdb_util_13\

-1
Теперь, если поместить курсор на .bad файл и нажать кнопку, будет создан восстановленный файл .sdb
PS. Поправил предыдущие сообщения с учетом всей новой информации.
Вложения
db_ClearRebuild.zip
для работы кнопки в TC
(172 байт) Скачиваний: 108
db_cleaner_source.7z
исходник .pl
(1.13 KiB) Скачиваний: 116
db_cleaner.7z
!Утилита по очистке дампа (exe)
(426.34 KiB) Скачиваний: 124
T_Im
Постигающий Дао
 
Сообщения: 112
Зарегистрирован: 04 янв 2009, 21:52
Благодарил (а): 15 раз.
Поблагодарили: 14 раз.

Пред.След.

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

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

Сейчас этот форум просматривают: Google [Bot] и гости: 7