TeilnehmerТаки версии - это не журнал и у firebird - действительно совсем нет журналирования! А СУБД без журнала транзакций - это не серьезно...
Ну не обязательно.
В блокировочниках журнал обязан быть для UNDO во время ROLLBACK. В версионниках типа Oracle и InnoDB (MySQL) ещё и для версий данных.

PostgreSQL и Firebird не имеют этих проблем по определению.

Также журнал нужен, если запись в сами таблицы кэшируется (для REDO во время восстановления).
Именно поэтому в PostgreSQL он всё таки есть.

А FireBird наверно сразу данные на диск сбрасывает. Так это? careful write это что?

Читаю про careful write.
1. да, это сброс всех данных сразу на диск, но по окончании транзакции. (Здесь я задумался: а если я изменил данных больше, чем помещается в памяти?)
2. в interbase 6.0 по умолчанию sync режим записи отключён. А в firebird ?
3. из-за careful write Firebird не может делать backward index scan - поиск по индексу в обратном направлении. PostgreSQL (да и многие другие) может.

Gluk (Kazan) В Oracle журнал используется ТОЛЬКО для восстановления. Ни для rollback-ов, ни для версионности. Для этих целей ведется UNDO (также защищенный журналом)
Прошу прощения. Я действительно всех тонкостей не знаю.

Apex Teilnehmer
hvladВерсии - это и есть журнал.


Таки версии - это не журнал и у firebird - действительно совсем нет журналирования! А СУБД без журнала транзакций - это не серьезно...

Именно. Журнал - это грубо говоря, когда берем копию базы трех дневной давности и применяем к ней журнал, в результате чего получаем консистентную БД по состоянию на последнюю зафиксированную транзакцию перед сбоем.

Careful write - и база консистентна не только перед сбоем, но и после него!!! Вообще в любой момент времени!!!
А платят за это отсутствие backward index scan и небольшой потерей скорости (по сравнению с Oracle, разумеется)

А восстановление на любой момент времени - Incremental Backup. Как часто делаешь, так часто и восстанавливаешься.
Не знаю как в Oracle, но в SQLServer нужно было логи тоже архивировать (backup-ить), чтобы потом по ним восстановить.
Ибо если у тебя база полетела, то и за консистентность логов ты тоже отвечать не можешь!!!

Разница конечно же есть, но она не в сути, а в объёмах. Кому-то выгоднее журнал архивить, кому-то - инкрементный бэкап.

Gluk (Kazan)Журнал сохраняется ПОСТОЯННО в процессе работы, в STANDBY-конфигурации на другой сервер.
Так что он всегда сохранен вовремя :) тем и ценен
Первая дельная мысль. В PostgreSQL >= 8.0 тоже самое сделали.
Правда в Firebird есть mirror database. Но, наверное, это не полная альтернатива.

hvladPS Обсуждение деталей работы FB здесь офтопик, imho. Есть более правильный форум - велкам туда, если есть желание :)
По-моему этот форум назвается "Сравнение СУБД". Или я ошибаюсь?
Кстати, спасибо за ответы.
hvlad3. Нет. Не из-за careful write. А для гарантии безблокировочной работы (речь о блокировках страниц индекса). В принципе более сложный алгоритм уже обсуждён и ждёт того, кто его реализует. Но потребность невелика :)
Знаешь, я тоже это не из пальца высосал, а прочитал в официальной документации Interbase (какую-то ссылку вчера Google выкинул по запросу carefull writes Interbase или careful writer Interbase).
Суть в том, что если pageA ссылается на pageB, то pageB пишется на диск раньше чем pageA. Но чтобы по индексу можно было искать в обоих направлениях, нужен двухсвязный список, т.е. чтобы pageA ссылалась на pageB и pageB ссылалась на pageA. И что тогда писать первым?