Big Cheese wrote:А вот как при отсутствии журнала безопасно оперировать с индексными страницами B-Tree (вставлять, удалять страницы) - мне непонятно...
Это можно делать в "системной транзакции" - при необходимости "расщепить/склеить" страницы индекса делается отдельная транзакция, причём изменения, внесённые такой транзакцией не являются частью доступного пользователю состояния базы данных. Техника обеспечения атомарности при этом ничем не отличается от обычных пользовательских транзакций.
Вообще, насколько я понимаю, любая операция, которая переводит образ базы на диске из одного согласованного состояния в другое и при этом не атомарна с точки зрения disk I/O (пишет более одного disk I/O unit) - должна быть сначала прописана в журнале, иначе восстановление после сбоя в общем случае невозможно. Оговорюсь еще раз - я в этом вопросе дилетант, хотелось бы узнать, что об этом думают специалисты...
Для обеспечения восстанавливаемости по алгоритму WAL необходима инфомация undo и redo, информация о том, как завершились транзакции (commit, abort), а также информация о том, какая часть базы уже не требует актуализации, так как recovery для неё уже успешно закончился. В IB, судя по по ссылкам от Merle, информации undo и redo находятся прямо в страницах данных; никакой дополнительной информация о том, до какой точки дошёл recovery не нужна, так как транзакция ни будет зафиксирована, пока страницы данных не окажутся сброшенными на диск; а информация о завершении транзакций хранится отдельно.
B итоге, так как страницы данных самодостаточны для успешого undo и redo, в том числе и для recovery, то этот самый transaction inventory table или как она там в IB называется, фактически и является журналом. В каком-то смысле это как журнал координатора распределённой транзакции, а каждая отдельная странице со своим набором изменений - это как самодостаточный участник распределённой транзакции, при условии, что координатор всегда может всем сообщить общий итог.
Поэтому если информация об итоге всех транзакций всегда идёт сначала в отдельный transaction inventory, то восстанавливаемость гарантируется. Но при условии атомарности отдельной операции со страницей (что на самом деле не может быть 100% обеспечено с существующей технологией дисков, для защиты от таких проблем в том же SQL Server имеется torn page detection). Но слабое место у IB здесь, как уже было сказано, производительность - ввиду необходимости перед подтверждением commit сбросить на диск все грязные страницы, тронутые транзакцией.
