Russian Progress User Group

ну вряд ли данные будут записываться в экстент b2.
я все равно буду разрушать AI, так как ai-экстент самой большой базы накатывается уже 1 час. Собственно, это единственная база, которая тормозит процесс. Плюс утверждение о том, что нормальный after Image после truncate bi и удаления области в target-базе - это баг, также подвигает меня сделать новую резервную базу. Вот только нет уверенности, что ситуация не повторится. Что необходимо посмотреть на target-базе?

Быстро посмотреть не получится... При старте базы отрабатывает тот же redo phase. накат ai, скопившихся с ночи, начавшийся в 9:40 пришлось отменить. Завтра напишу результат. На бою он равен 511. Я после урезания bi делаю отдельно преформат на 512 кластеров.

На следующей неделе напишу как ведет себя AI. Кстати, хотел спросить - Юрий, не подскажете, в чем смысл создания резервной базы по варианту, предложенному в статье, ссылку на которую я дал в своем первом посте этой темы? Что-то я не понимаю, почему необходимо начинать переключение экстентов с 99999-го. Есть в этом какой-то практический смысл?

да, все эти статьи я прочитал, когда пытался понять что же происходит. Как раз в одной из них (во второй, по-моему) советуют делать truncate bi на базе-источнике, а не на целевой. Поясните, если я создаю пустую базу, а потом делаю prorest (как в варианте из статьи) - чем это кардинально отличается от способа - когда я перед созданием Full бэкапа в оффлайне сделаю truncate bi, bigrow 512 и по существующему st сделаю рестор бэкапа на резервной базе? По-моему, Bi на целевой базе не должен быть большим и "запутанным".
На мой взгляд в описанном в статье способе просто делается акцент на создание резервной базы и запуск AI без останова сервера (а следовательно без возможности сделать truncate bi).