Здравствуйте.chuk_and_gekЛоги накатили как положено. Все завершилось без ошибок.А как это - "как положено"?
До конца журнала или до точки во времени, предшествующей удалению одной таблицы и записей из другой?

chuk_and_gekБекап был с опцией- INCLUDE LOGS, накатка была именно этих логов.
Если мы пред восстановлением базу дропаем, то при восстановлении все таблички присутствуют.
А при восстановлении в существующу - их нет?Как сказано в DROP DATABASE , оно удаляет в т.ч. и журналы базы.
Поэтому, если вы перед drop не скопировали журналы в другое место, и потом в rollforward не указали путь к ним, то оно и не найдёт журнальные записи, соответствующие вашим удалениям.
Если же вы восстанавливаетесь в существующую базу, то журналы остаются на месте, rollforward может их найти и применить эти записи.

chuk_and_gekКоманды drop database мы не давали. Мы дропнули только одну таблицу и думали, что из бэкапа, сделанного ранее, она должна восстановиться, также как и строки, удаленные из другой таблицы. Но нет. Ни того, ни другого.Ещё раз:
rollforward - это такая команда, которая применяет все журнальные записи, которые оно смогло найти во всех ему доступных журналах до указанной точки во времени или до последней записи.
Если оно нашло запись об удалении таблицы в журналах, то таблица будет удалена.
Если не нашло - например, из-за того, что вы указали накатиться до точки во времени, когда произошло удаление, или вы указали to end of logs, но не сделали доступными для rollforward журнал, где есть отметка об удалении таблицы (не обнаружив следующий по порядку журнал, rollforward остановится), - то таблица останется в базе.

chuk_and_gekА в чем тогда смысл бекапа и восстановления одного табличного пространства?
Для восстановления в существующую- необходимо удалять все логи, а если база рабочая? (просто все затеялось из-за того, что в БД есть табл.пространство с блобами, захотели делать бекап TS без блобов- раз в неделю, а с блобами- раз в месяц. В базе живут несколько независимых задач.) Если удалять логи, то как восттанавливать по TS?Основное предназначение архивов табличных пространств это не восстановление случайно удалённых данных или таблиц (хотя и эти проблемы тоже можно решать восстановлением табличного пространства), а более быстрое восстановление после сбоев дисковой подсистемы.
Если страницы данных или индексов побились только в определённом табличном пространстве, то вместо того, чтобы восстанавливать всю базу из архива, достаточно восстановить это табличное пространство и накатить его по журналам.
При этом действительно есть смысл архивировать более часто те пространства, данные в которых чаще меняются, ведь чем меньший объём изменений надо будет накатить по журналам, тем быстрее пройдёт восстановление.

Теперь по поводу восстановления случайно удалённых данных.
Вы тоже можете использовать архив табличного пространства для этого, но тут есть не очень приятные особенности.
Во-первых вам не надо для этого удалять журналы.
Вы можете накатывать табличное пространство не до конца журналов, а до точки во времени, предшествующей операции (delete, например), действие которой надо отменить. Но там есть особенности, связанные со ссылочной целостностью и нахождением этиой таблицы в разных табличных пространствах, о чем лучше почитать здесь:
Rolling forward changes in a table space .
Кроме того, для восстановления удалённой таблицы можно использовать предложение RECOVER DROPPED TABLE команды ROLLFORWARD .
Также в v9 вы можете использовать восстановление в новую БД из архива табличных пространств.
См. REBUILD examples .
Т.е. вы можете восстановить только табличные пространства, содержащие вашу таблицу, из которой вы удалили данные, накатить эти табличные пространства до момента удаления данных в ней, а потом выгрузить сожержимое этой таблицы.