Dimitry SibiryakovВопрос первый: если какая-то запись уже изменялась в этой транзакции, информация о ней в логе объединится или удвоится?
смотря что называть "информацией о записи в логе". Она состоит из двух частей - собственно undo item (два десятка служебных байт, всегда в памяти) и undo data (собственно данные записи, могут уходить в temp). При первом апдейте в логе будет только undo item, т.к. для отката нам достаточно сделать backout. Второй апдейт приведет к update-in-place, так что в логе будет и undo item и undo data, отдельно от первого undo item-а (на другом сейвпойнте). При слиянии второго сейвпойнта с сейвпойнтом тр-ции (по окончании второго апдейта) инфа о записи объединится. Иными словами, дублирование в логе будет только на время выполнения второго апдейта и только в размере undo item, а не всей записи.

Dimitry SibiryakovИ после этого слияния в логе транзакции будет только undo item, без undo data, правильно?
насколько я помню, да

Dimitry SibiryakovТогда вопрос номер два: какое место в этой картине занимают explicit savepoint и особенно в случае, если лог транзакции не существует?
они ничем не отличаются от системных, кроме метода порождения

Dimitry SibiryakovЧисто уточнить, что я правильно понимаю:
1) В отличии от сабжа транзакции, их сабж никогда не уничтожается (и, соответственно,
порождается даже при tpb_no_auto_undo).
2) Если не было release savepoint, то их лог никогда не вливается в транзакционный.

1) уничтожается при RELEASE/ROLLBACK + tpb_no_auto_undo, ну и при завершении транзакции, естественно
2) верно

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

Dimitry SibiryakovЕщё вопрос: каков формат undo data? Дельта, message или DSC?

распакованная запись (record->rec_data)