Разобрался, почему db_recover не работал - там нужна ещё небольшая конфигурация env (при помощи DB_CONFIG), чтобы recover мог найти файлы с БД.
В ближайшее время исправлю sdb_utils, чтобы всё работало как положено.
Восстановление убитого кэша Беркли (BerkeleyDB)
Модератор: Tolik
-
zed
- Гуру
- Сообщения: 2888
- Зарегистрирован: 16 авг 2008, 20:21
- Благодарил (а): 89 раз
- Поблагодарили: 568 раз
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
Новая версия: 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:
Или, говоря по-русски, тут не гарантируется полное восстановление кэша при падении САСа или винды.
2. Normal - файл лога пишется синхронно (после каждого коммита из буфера в памяти, производится запись в лог), но не даётся гарантий, что винда сбросит буфер и данные действительно запишутся в файл. Определяющий флаг - DB_TXN_WRITE_NOSYNC:
Или, говоря по-русски, тут не гарантируется полное восстановление кэша только при падении винды. Если же упадёт только САС, то по логам возможно всё восстановить. В 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) теоретически можно добиться ещё большего прироста в скорости.
Содержит исправление бага #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) теоретически можно добиться ещё большего прироста в скорости.
-
zed
- Гуру
- Сообщения: 2888
- Зарегистрирован: 16 авг 2008, 20:21
- Благодарил (а): 89 раз
- Поблагодарили: 568 раз
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
Новая версия: sdb_util_1.0.2.7.7z
- добавлена поддержка версионного Беркли
- переработан вызов консольных утилит, с оглядкой на пути с русскими символами
- исправлен глюк, когда не весь текст сообщения от утилит выводился в окно лога
- добавлена поддержка версионного Беркли
- переработан вызов консольных утилит, с оглядкой на пути с русскими символами
- исправлен глюк, когда не весь текст сообщения от утилит выводился в окно лога
-
Tolik
- Гуру
- Сообщения: 2604
- Зарегистрирован: 28 янв 2011, 10:38
- Благодарил (а): 283 раза
- Поблагодарили: 587 раз
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
Что за хрень у меня бегает по карте?
Недавно обновил ночнушку (130701.7325), до этого 3 месяца не обновлял (130408.7232).
На разных картах.
Недавно обновил ночнушку (130701.7325), до этого 3 месяца не обновлял (130408.7232).
На разных картах.
-
zed
- Гуру
- Сообщения: 2888
- Зарегистрирован: 16 авг 2008, 20:21
- Благодарил (а): 89 раз
- Поблагодарили: 568 раз
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
Tolik писал(а):Что за хрень у меня бегает по карте?
http://sasgis.org/mantis/view.php?id=1995
http://sasgis.org/mantis/view.php?id=2002
-
cycler
- Новичок
- Сообщения: 32
- Зарегистрирован: 15 июн 2013, 10:01
- Благодарил (а): 10 раз
- Поблагодарили: 2 раза
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
Вот и слетел мой намученный кеш!!!!!!!! Ой батюшки мои то....(((
Началось с совершенно безобидной операции - скопирнул в /cache 4гига тайлового кеша, собирался добавить его в имеющийся 200гиговый кеш беркли. Но там уже была папка такого же зума и чтобы проверить, где они пересекаются, я запросил у САС текущее покрытие z16-м зумом. САС думала-думала, но так ничего и не выдала, как будто z16 зума и в помине не было. Тогда я стал приближать карту к 16 зуму, так САС быстрее выдаёт покрытие, но в момент приближения прога зависла, висела 5мин, вырубил через диспетчер. После запуска от кеша пяти карт остался только кеш одного генштаба....((((
При просмотре карты прямо на её месте серый фон и такое сообщение (которое то пропадает то снова появляется) - "Access violation at address 0052cbfc in module 'sasplanet.exe'. Read of address 00000000"
Скажите, мне кердык, да???
(версия 130525.7259 ночная, винда 7 стартовая)
Вот содержимое *.elf
САС при запуске вообще ничего не говорит и визуально не пытается восстановить кеш...
Началось с совершенно безобидной операции - скопирнул в /cache 4гига тайлового кеша, собирался добавить его в имеющийся 200гиговый кеш беркли. Но там уже была папка такого же зума и чтобы проверить, где они пересекаются, я запросил у САС текущее покрытие z16-м зумом. САС думала-думала, но так ничего и не выдала, как будто z16 зума и в помине не было. Тогда я стал приближать карту к 16 зуму, так САС быстрее выдаёт покрытие, но в момент приближения прога зависла, висела 5мин, вырубил через диспетчер. После запуска от кеша пяти карт остался только кеш одного генштаба....((((
При просмотре карты прямо на её месте серый фон и такое сообщение (которое то пропадает то снова появляется) - "Access violation at address 0052cbfc in module 'sasplanet.exe'. Read of address 00000000"
Скажите, мне кердык, да???
(версия 130525.7259 ночная, винда 7 стартовая)
Вот содержимое *.elf
- скрытый текст: показать
- скрытый текст: показать
САС при запуске вообще ничего не говорит и визуально не пытается восстановить кеш...
Последний раз редактировалось cycler 07 авг 2013, 18:31, всего редактировалось 1 раз.
-
zed
- Гуру
- Сообщения: 2888
- Зарегистрирован: 16 авг 2008, 20:21
- Благодарил (а): 89 раз
- Поблагодарили: 568 раз
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
1. Что пишет в sdb.log?
2. Пробовали запускать восстановление при помощи sdb_util?
2. Пробовали запускать восстановление при помощи sdb_util?
Очень старая. Возможно какие-то давно пофикшенные баги стали причиной сбоя.версия 130525.7259 ночная
-
cycler
- Новичок
- Сообщения: 32
- Зарегистрирован: 15 июн 2013, 10:01
- Благодарил (а): 10 раз
- Поблагодарили: 2 раза
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
Содержимое sdb.log
Обновить САС и запустить, посмотреть что скажет?
- скрытый текст: показать
Обновить САС и запустить, посмотреть что скажет?
-
zed
- Гуру
- Сообщения: 2888
- Зарегистрирован: 16 авг 2008, 20:21
- Благодарил (а): 89 раз
- Поблагодарили: 568 раз
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
По какой причине?cycler писал(а):тогда пропало 4гига тестово накаченного кеша..
Запустить восстановление (для начала можно просто Recover environment [cmd: db_recover -v], а если не поможет, то полное - Restore cache after crash: Recover & Verify (default)), а затем обновить САС и посмотреть что скажет. Просто обновление САС уже не спасёт.cycler писал(а):Обновить САС и запустить, посмотреть что скажет?
-
cycler
- Новичок
- Сообщения: 32
- Зарегистрирован: 15 июн 2013, 10:01
- Благодарил (а): 10 раз
- Поблагодарили: 2 раза
Re: Восстановление убитого кэша Беркли (BerkeleyDB)
Да кто ж знает то.. Я тогда на ночь поставил скачивать регион, утром смотрю - карта серая (настройка стояла - использовать только кеш Беркли). Запустил восстановление, но даже самый жёсткий режим не вернул карту к жизни. Вообще, тот случай не оч.хороший для примера, комп был стационарный, воткнутый на фирме безо всяких юпсов, так что вполне возможно ночной скачок питалова угробил часть файлов.. Но факт остаётся фактом - 4гига на харде и серый фон в САСе.zed писал(а):По какой причине?cycler писал(а):тогда пропало 4гига тестово накаченного кеша..
Эх, я уже полное запустил, не вовремя прочёл.. Спасибо большое за участие!!!zed писал(а):Запустить восстановление (для начала можно просто Recover environment [cmd: db_recover -v], а если не поможет, то полное - Restore cache after crash: Recover & Verify (default)), а затем обновить САС и посмотреть что скажет. Просто обновление САС уже не спасёт.cycler писал(а):Обновить САС и запустить, посмотреть что скажет?
Можно ли прервать восстановление без ущерба для данных? Есть подозрение что процесс затянется более чем на сутки.