Gida:) тогда вопрос по "правильности" сратегии отделения информации для восстановления:
...2 Сервера-промышленный и резернвый.
Раз в неделю выполняется польная офлайновая резервная копия БД. Далее копируется на резервный сервер.
На пром. сервере каждые 40 минут выполняется команда "ARCHIVE LOG", спустя минуту копируются лог файлы на резернвый сервер. Промышленная база постоянно начиняется информацией, даже в момент выполнения "ARCHIVE LOG" и копирования лог файлов.
...Вопросы:
1. Никаких подводнй камней не вылезет при одновременных транзакциях и выполнения "ARCHIVE LOG" ?
2. Насколько правильная (неправильная) такая стратегия восстангвления БД ?Когда вы делаете ARCHIVE LOG, то текущий активный лог закрывается (т.е. в него никто уже больше писать не будет), и вы можете накатываться только по нему и тем, которые имеют номер ниже, но не выше (т.к. это активные логи и по ним лучше не накатываться).
Для этого удобно, например, использовать параметр базы logarchmeth[1|2], т.к. именно в подкаталоги этого каталога, на который указывает этот параметр, будут класться закрытые логи.

GidaА вот можно ли после команды "ARCHIVE LOG" узнать время, чтобы можно было восстановиться в случае чего ?Зачем вам это время?
В db2diag.log пишется при этом номер журнала, который архивируется.
Если вы хотите восттановиться потом только по транзакциям, которые завершились до архивирования, вы просто накатываетесь по конца по логам с номерами не выше этого.
Т.е. логи с номерами выше вы просто удаляете из тех мест, где rollforward их может найти (log path, overflow log path).