Новая версия:
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) теоретически можно добиться ещё большего прироста в скорости.
