Semen Popov,

Оно пытается найти ещё логи, но не может, т.к. не имеет доступ к логам от этой базы на tsm.
Добавьте в конец команды опцию noretrieve.

Semen PopovMark BarinsteinОно пытается найти ещё логи, но не может, т.к. не имеет доступ к логам от этой базы на tsm.
А можно тут по-подробнее? Как проверить этот доступ? И как его предоставить? Ответ на эти вопросы, возможно, поможет решить другую нашу проблему ...
Почему не имеет доступа к логам от этой базы?
Стандартное поведение DB2 при rollforward такое: оно, пытаясь найти доступные логи, в конце концов лезет в архивные пути за ними, если в предыдущих не нашло. Если при этом возникает ошибка - rollforward заканчивается с ошибкой.

Ошибка, например, может быть связана с тем, что в параметрах восстановленной на другой TSM ноде базы по-прежнему указано, что архивные логи лежат в TSM. Но, т.к. новое имя TSM ноды отличается, то rollforward посылает запрос в нее, а там логов нет - они в оригинальной ноде. А в rollforward нет возможности указать опцию '-fromnode', например, как в restore.
Для этого и придуман параметр noretrieve - не лезть искать журналы в архиве.
Конечно, в этом случае можно сконфигурировать систему, чтоб rollforward лез в оригинальную ноду за логами, но так делать не надо в случае, описанном выше. Иначе после наката оно начнет архивировать логи в оригинальную ноду, и там получится каша - оригинальная система тоже туда свои логи продолжает архивировать.

Другая проблема с этой не связана - это баг какой-то, скорее всего.