Восстановление убитого кэша Беркли (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
Окошко с настройками
Хитрости GoogleEarth - то, чего вы не знаете о гугле

За это сообщение автора 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
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение zed » 11 апр 2013, 09:09

Разобрался, почему db_recover не работал - там нужна ещё небольшая конфигурация env (при помощи DB_CONFIG), чтобы recover мог найти файлы с БД.
В ближайшее время исправлю sdb_utils, чтобы всё работало как положено.
Хитрости GoogleEarth - то, чего вы не знаете о гугле

За это сообщение автора zed поблагодарили: 2
Parasite (11 апр 2013, 17:27) • xromeo (14 апр 2013, 11:43)
Рейтинг: 10.53%
 
Аватара пользователя
zed
Гуру
 
Сообщения: 2888
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение zed » 15 апр 2013, 19:49

Новая версия: sdb_util_1.0.2.6.7z

Содержит исправление бага #3: db_recover не находит файлов БД, плюс небольшие улучшения:
- появилась возможность автоматически конфигурировать свойство долговечности (Durability) кэша, через пресеты настроек DB_CONFIG
- немного переименованы пресеты операций (те, что в главном окне) и из пресета Auto-Restore убрана операция Reset LSN

Несколько слов про пресеты 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 с нужной конфигурацией. И при следующем запуске САС автоматически подхватит эти настройки.

P. S. Да, по поводу того, что там в пресетах есть приписки fast и slow, следует расценивать как относительные значения. Дело в том, что в конфиг помимо прочего, вносятся дополнительные параметры, которые устанавливают несколько больший размер внутренних буферов для env, что положительно сказывается на быстродействии кэша. Так что может оказаться, что пресет High, который помечен как slow, будет быстрее, чем существующий вариант в САСе, где используются маленькие буферы со значением по-молчанию. Кроме того, увеличивая значение set_cachesize (и зависимый mutex_set_max) теоретически можно добиться ещё большего прироста в скорости.
Хитрости GoogleEarth - то, чего вы не знаете о гугле

За это сообщение автора zed поблагодарили: 2
Smith2007 (22 апр 2013, 13:27) • T_Im (15 апр 2013, 23:44)
Рейтинг: 10.53%
 
Аватара пользователя
zed
Гуру
 
Сообщения: 2888
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение zed » 29 июн 2013, 20:33

Новая версия: sdb_util_1.0.2.7.7z

- добавлена поддержка версионного Беркли
- переработан вызов консольных утилит, с оглядкой на пути с русскими символами
- исправлен глюк, когда не весь текст сообщения от утилит выводился в окно лога
Хитрости GoogleEarth - то, чего вы не знаете о гугле

За это сообщение автора zed поблагодарил:
Parasite (04 июл 2013, 08:56)
Рейтинг: 5.26%
 
Аватара пользователя
zed
Гуру
 
Сообщения: 2888
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение Tolik » 05 июл 2013, 14:50

Что за хрень у меня бегает по карте?

Изображение

Недавно обновил ночнушку (130701.7325), до этого 3 месяца не обновлял (130408.7232).
На разных картах.
Tolik
Гуру
 
Сообщения: 2544
Зарегистрирован: 28 янв 2011, 10:38
Благодарил (а): 240 раз.
Поблагодарили: 494 раз.

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

Сообщение zed » 05 июл 2013, 21:20

Tolik писал(а):Что за хрень у меня бегает по карте?

http://sasgis.org/mantis/view.php?id=1995
http://sasgis.org/mantis/view.php?id=2002
Хитрости GoogleEarth - то, чего вы не знаете о гугле
Аватара пользователя
zed
Гуру
 
Сообщения: 2888
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение cycler » 07 авг 2013, 18:13

Вот и слетел мой намученный кеш!!!!!!!! Ой батюшки мои то....(((
Началось с совершенно безобидной операции - скопирнул в /cache 4гига тайлового кеша, собирался добавить его в имеющийся 200гиговый кеш беркли. Но там уже была папка такого же зума и чтобы проверить, где они пересекаются, я запросил у САС текущее покрытие z16-м зумом. САС думала-думала, но так ничего и не выдала, как будто z16 зума и в помине не было. Тогда я стал приближать карту к 16 зуму, так САС быстрее выдаёт покрытие, но в момент приближения прога зависла, висела 5мин, вырубил через диспетчер. После запуска от кеша пяти карт остался только кеш одного генштаба....((((
При просмотре карты прямо на её месте серый фон и такое сообщение (которое то пропадает то снова появляется) - "Access violation at address 0052cbfc in module 'sasplanet.exe'. Read of address 00000000"
Скажите, мне кердык, да???
(версия 130525.7259 ночная, винда 7 стартовая)

Вот содержимое *.elf
скрытый текст: показать
EurekaLog 6.1.03

Application:
-------------------------------------------------------
1.1 Start Date : Wed, 7 Aug 2013 18:00:07 +0400
1.2 Name/Description: SASPlanet.Debug.exe
1.3 Version Number : 13.5.25.7259
1.4 Parameters :
1.5 Compilation Date: Sat, 25 May 2013 04:02:44 +0400
1.6 Up Time : 42 seconds

Exception:
------------------------------------------------------------
2.1 Date : Wed, 7 Aug 2013 18:00:50 +0400
2.2 Address :
2.3 Module Name : SASPlanet.Debug.exe
2.4 Module Version: 13.5.25.7259
2.5 Type : EMemoryLeak
2.6 Message : Memory Leak: Total size=172 - Count=2.
2.7 ID : 6CA8
2.8 Count : 1
2.9 Status : New
2.10 Note :

Computer:
----------------------------------------------------------------------------------------
5.3 Free Memory : 562 Mb
5.5 Free Disk : 224.6 Gb
5.7 Processor : Intel(R) Atom(TM) CPU N2600 @ 1.60GHz
5.8 Display Mode: 1024 x 600, 32 bit
5.9 Display DPI : 96
5.10 Video Card : Intel(R) Graphics Media Accelerator 3600 Series (driver 8.14.8.1075)

Operating System:
-----------------------------------
6.1 Type : Microsoft Windows 7
6.2 Build # : 7601
6.3 Update :
6.4 Language: Russian
6.5 Charset : 0


Call Stack Information:
-------------------------------------------------------------------------------------------------------------------------------------------------------------
|Address |Module |Unit |Class |Procedure/Method |Line |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
|+Memory Leak: Type=TInternalPerformanceCounter; Total size=84; Count=1 |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
|005698BA|SASPlanet.Debug.exe|u_InternalPerformanceCounter.pas |TInternalPerformanceCounterFactory |Build |196[1] |
|0056AB28|SASPlanet.Debug.exe|u_InternalPerformanceCounterListForDebugOneClass.pas|TInternalPerformanceCounterListForDebugOneClass|Create |51[3] |
|0056B2B7|SASPlanet.Debug.exe|u_InternalPerformanceCounterListForDebug.pas |TInternalPerformanceCounterListForDebug |GetCounterByClass|80[4] |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
| |
|+Memory Leak: Type=TBerkeleyDB; Total size=88; Count=1 |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
|00583822|SASPlanet.Debug.exe|u_BerkeleyDBFactory.pas |TBerkeleyDBFactory |CreateDatabase |83[1] |
|00574869|SASPlanet.Debug.exe|u_BerkeleyDBPool.pas |TBerkeleyDBPool |Acquire |216[48]|
-------------------------------------------------------------------------------------------------------------------------------------------------------------

Modules Information:
--------------------

Processes Information:
----------------------

Assembler Information:
----------------------

Registers:
----------


И ещё один, от следующего запуска
скрытый текст: показать
EurekaLog 6.1.03

Application:
-------------------------------------------------------
1.1 Start Date : Wed, 7 Aug 2013 18:17:31 +0400
1.2 Name/Description: SASPlanet.Debug.exe
1.3 Version Number : 13.5.25.7259
1.4 Parameters :
1.5 Compilation Date: Sat, 25 May 2013 04:02:44 +0400
1.6 Up Time : 4 minutes, 0 second

Exception:
------------------------------------------------------------
2.1 Date : Wed, 7 Aug 2013 18:21:32 +0400
2.2 Address :
2.3 Module Name : SASPlanet.Debug.exe
2.4 Module Version: 13.5.25.7259
2.5 Type : EMemoryLeak
2.6 Message : Memory Leak: Total size=260 - Count=3.
2.7 ID : 6CA8
2.8 Count : 1
2.9 Status : New
2.10 Note :

Computer:
----------------------------------------------------------------------------------------
5.3 Free Memory : 559 Mb
5.5 Free Disk : 224.6 Gb
5.7 Processor : Intel(R) Atom(TM) CPU N2600 @ 1.60GHz
5.8 Display Mode: 1024 x 600, 32 bit
5.9 Display DPI : 96
5.10 Video Card : Intel(R) Graphics Media Accelerator 3600 Series (driver 8.14.8.1075)

Operating System:
-----------------------------------
6.1 Type : Microsoft Windows 7
6.2 Build # : 7601
6.3 Update :
6.4 Language: Russian
6.5 Charset : 0


Call Stack Information:
-------------------------------------------------------------------------------------------------------------------------------------------------------------
|Address |Module |Unit |Class |Procedure/Method |Line |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
|+Memory Leak: Type=TInternalPerformanceCounter; Total size=84; Count=1 |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
|005698BA|SASPlanet.Debug.exe|u_InternalPerformanceCounter.pas |TInternalPerformanceCounterFactory |Build |196[1] |
|0056AB28|SASPlanet.Debug.exe|u_InternalPerformanceCounterListForDebugOneClass.pas|TInternalPerformanceCounterListForDebugOneClass|Create |51[3] |
|0056B2B7|SASPlanet.Debug.exe|u_InternalPerformanceCounterListForDebug.pas |TInternalPerformanceCounterListForDebug |GetCounterByClass|80[4] |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
| |
|+Memory Leak: Type=TBerkeleyDB; Total size=176; Count=2 |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
|00583822|SASPlanet.Debug.exe|u_BerkeleyDBFactory.pas |TBerkeleyDBFactory |CreateDatabase |83[1] |
|00574869|SASPlanet.Debug.exe|u_BerkeleyDBPool.pas |TBerkeleyDBPool |Acquire |216[48]|
-------------------------------------------------------------------------------------------------------------------------------------------------------------

Modules Information:
--------------------

Processes Information:
----------------------

Assembler Information:
----------------------

Registers:
----------

Причем что интересно. Сначала не хотела запускаться только одна карта, спутник. Но остальные работали. А после двух перезапусков программы теперь не работают уже 4 карты из 5

САС при запуске вообще ничего не говорит и визуально не пытается восстановить кеш...
Последний раз редактировалось cycler 07 авг 2013, 18:31, всего редактировалось 1 раз.
cycler
Новичок
 
Сообщения: 32
Зарегистрирован: 15 июн 2013, 10:01
Благодарил (а): 10 раз.
Поблагодарили: 2 раз.

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

Сообщение zed » 07 авг 2013, 18:31

1. Что пишет в sdb.log?
2. Пробовали запускать восстановление при помощи sdb_util?

версия 130525.7259 ночная

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

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

Сообщение cycler » 07 авг 2013, 18:37

Содержимое sdb.log
скрытый текст: показать
07-08-2013 18:00:12.269 BerkeleyDB Env: MoveFile: rename d:\sas.planet\cache_db\yasat\env\__db.002 to temporary file: Input/output error d:\sas.planet\cache_db\yasat\
07-08-2013 18:00:12.285 EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:12.301 EBerkeleyDBExeption: EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:16.918 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:18.338 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:19.289 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:20.475 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:20.475 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:20.475 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:20.491 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:20.491 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:21.645 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:42.034 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:42.565 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:00:42.565 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:17:37.034 BerkeleyDB Env: PANIC: fatal region error detected; run recovery d:\sas.planet\cache_db\yasat\
07-08-2013 18:17:37.050 EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:17:37.066 EBerkeleyDBExeption: EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:12.143 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:12.876 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:15.450 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:22.829 BerkeleyDB Env: PANIC: fatal region error detected; run recovery d:\sas.planet\cache_db\yamapng\
07-08-2013 18:21:22.845 EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:22.860 EBerkeleyDBExeption: EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:23.609 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:24.998 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:24.998 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:21:25.013 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:34:15.845 BerkeleyDB Env: PANIC: fatal region error detected; run recovery d:\sas.planet\cache_db\yasat\
07-08-2013 18:34:15.860 EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:34:15.876 EBerkeleyDBExeption: EAccessViolation: Access violation at address 00573378 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:34:17.795 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000
07-08-2013 18:34:17.795 EAccessViolation: Access violation at address 00574757 in module 'SASPlanet.Debug.exe'. Read of address 00000000

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

Обновить САС и запустить, посмотреть что скажет?
cycler
Новичок
 
Сообщения: 32
Зарегистрирован: 15 июн 2013, 10:01
Благодарил (а): 10 раз.
Поблагодарили: 2 раз.

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

Сообщение zed » 07 авг 2013, 18:43

cycler писал(а):тогда пропало 4гига тестово накаченного кеша..

По какой причине?
cycler писал(а):Обновить САС и запустить, посмотреть что скажет?

Запустить восстановление (для начала можно просто Recover environment [cmd: db_recover -v], а если не поможет, то полное - Restore cache after crash: Recover & Verify (default)), а затем обновить САС и посмотреть что скажет. Просто обновление САС уже не спасёт.
Хитрости GoogleEarth - то, чего вы не знаете о гугле

За это сообщение автора zed поблагодарил:
cycler (07 авг 2013, 18:56)
Рейтинг: 5.26%
 
Аватара пользователя
zed
Гуру
 
Сообщения: 2888
ICQ: 357167611
Зарегистрирован: 16 авг 2008, 20:21
Откуда: Беларусь, Могилёв
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение cycler » 07 авг 2013, 18:56

zed писал(а):
cycler писал(а):тогда пропало 4гига тестово накаченного кеша..

По какой причине?

Да кто ж знает то.. Я тогда на ночь поставил скачивать регион, утром смотрю - карта серая (настройка стояла - использовать только кеш Беркли). Запустил восстановление, но даже самый жёсткий режим не вернул карту к жизни. Вообще, тот случай не оч.хороший для примера, комп был стационарный, воткнутый на фирме безо всяких юпсов, так что вполне возможно ночной скачок питалова угробил часть файлов.. Но факт остаётся фактом - 4гига на харде и серый фон в САСе.
zed писал(а):
cycler писал(а):Обновить САС и запустить, посмотреть что скажет?

Запустить восстановление (для начала можно просто Recover environment [cmd: db_recover -v], а если не поможет, то полное - Restore cache after crash: Recover & Verify (default)), а затем обновить САС и посмотреть что скажет. Просто обновление САС уже не спасёт.

Эх, я уже полное запустил, не вовремя прочёл.. Спасибо большое за участие!!!
Можно ли прервать восстановление без ущерба для данных? Есть подозрение что процесс затянется более чем на сутки.
cycler
Новичок
 
Сообщения: 32
Зарегистрирован: 15 июн 2013, 10:01
Благодарил (а): 10 раз.
Поблагодарили: 2 раз.

Пред.След.

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

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

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