Долгий roll forward на hot-swap БД

Обсуждение вопросов по администрированию СУБД Progress OpenEdge
Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 18 дек 2013, 10:40


Аватара пользователя
dmi
Старожил
Сообщения: 1523
Зарегистрирован: 27 сен 2001, 03:00
Откуда: Москва

Re: Долгий roll forward на hot-swap БД

Сообщение dmi » 18 дек 2013, 12:41

/dmi

http://pro4gl.ru - 4gl блог

Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 18 дек 2013, 13:01


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Re: Долгий roll forward на hot-swap БД

Сообщение George » 18 дек 2013, 16:37


Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 19 дек 2013, 08:13


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Re: Долгий roll forward на hot-swap БД

Сообщение George » 19 дек 2013, 12:57


Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 19 дек 2013, 14:17

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

Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Re: Долгий roll forward на hot-swap БД

Сообщение George » 19 дек 2013, 16:24


Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 19 дек 2013, 16:43

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

Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 20 дек 2013, 08:12


Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Re: Долгий roll forward на hot-swap БД

Сообщение George » 20 дек 2013, 08:38


Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 20 дек 2013, 09:10


Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 20 дек 2013, 09:25

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

Аватара пользователя
George
Старожил
Сообщения: 2871
Зарегистрирован: 12 май 2004, 17:03
Откуда: Питер

Re: Долгий roll forward на hot-swap БД

Сообщение George » 20 дек 2013, 09:49


Аватара пользователя
Fuelfire
Старожил
Сообщения: 137
Зарегистрирован: 23 авг 2007, 10:01
Откуда: г. Королёв

Re: Долгий roll forward на hot-swap БД

Сообщение Fuelfire » 20 дек 2013, 10:17

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