Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Alex.Che, Вы писали:

AC>>Oracle не в счёт, т.к. большинством голосов его обозвали гибридом
M>Зверюги, ну гибрид он. То есть не блокировочник, и журнал у него есть.
M>И у Postgres'а есть, у кого-то конечно нет, но это совершенно не связанные вещи.

по-моему "журнала" у PGSQL нет (могу ошибаться). У него система версионности похожая на IB.

M>Без оного, как правило, вариантов не много. Либо быстрые обновления, но остутствие автоматического восстановления, либо гарантия восстановления, но медленные обновления (или быстрые обновления но медленная фиксация).

я рекомендую почитать статьи общего плана
Общее описание транзакций и архитектур серверов. Л. Козленко.
http://www.osp.ru/os/2002/04/067_print.htm
http://www.osp.ru/os/2002/05/058_1_print.htm
http://www.osp.ru/os/2002/11/062_print.htm
http://www.osp.ru/os/2003/02/059_print.htm

M>В конечном итоге в IB,как я понимаю гарантии восстановления таки нет.
M>Если же подробнее, то некое подобие Undo-журнала встроено непосредственно в Transaction Manager, соответственно при нормальной работе в случае сбоя все в порядке. Но, поскольку при данной реализации физически "журнал" перемешан с живыми данными, то сбой при чистке "журнала", приводит к проблемам.
M>Насколько я понял в Yaffi эти проблемы решены.. Интересно как?

никаких проблем тут нет, и в YA соответственно отсутствующие проблемы никто не решал.
каждая версия записи маркируется номером транзакции. В БД хранится список стостояния транзакций.
Если транзакция committed — версию читать можно. Не committed — нельзя. Вот и все.
Если был сбой, то в списке состояния транзакций их состояния не изменились. Соответственно их
версии остались non-committed, и игнорируются при чтении (и вычищаются как мусор).

Да, при update каждый раз создается новая версия записи, и это слегка замедляет работу.
но как правило кооперативная сборка мусора работает нормально, и большое кол-во версий
накапливается редко.
В общем, никаких проблем с "восстановлением" после сбоя сервера нет.