По мотивам хотелки
#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
