Russian Progress User Group

Не знаю на что акцент делается в статье, а я его делаю на том, что BI файл на target может быть только больше или равным BI файлу на source и равенство между ними можно гарантированно получить после пересоздания реплики. Если возникла проблема с долгой redo фазой при накате AI файлов, то в качестве её "лечением" можно пересоздать реплику. Но по крайней мере для V10.2B я не видел, что долгая redo фаза на target базе сохранялась бы в течении длительного времени.

Сообщений таких в логе базы-источнике нет, но у меня 10.1B. Эту базу ресторил с полного бэкапа (единственное, не урезал перед бэкапом bi, но я этого никогда не делал специально) и после этого на целевой базе ничего не делал (как с другими базами где требовалось удаление старой области Old Default Area). Три дня до создания полного бэкапа было всё отлично. После этого начал проявляться эффект снежного кома - стала копиться очередь из архивных экстентов для наката на целевую базу, а время наката (~время redo phase) стало увеличиваться (и ведь большинство экстентов пустых, а накат занимает почти час!). Я так понял, что видимо Прогресс где-то зацикливается при выполнении фазы восстановления, что ведет к увеличению времени (баг?). Уверен, что не останови я AI - со временем накат пустого экстента занимал бы и 2, и 3 часа..
Ничего не остается как пересоздать целевую базу, предварительно перед бэкапом остановив сервера и урезав bi, чтобы ничего лишнего не было. Прослежу в течение следующей недели и отпишусь. Спасибо за помощь.

Юрий, но раньше такого не было на этой же версии... Возможно, имеет смысл не делать преформат после усечения bi? Возможно 512 кластеров - это довольно много? Я понимаю, что я жертвую временем для форматирования кластера при его надобности в онлайн, но возможно это будет меньшее зло по сравнению с такими тормозами при накате на резерве?
Я изменил только структуру базы - версия осталась той же. Да, бывали случаи, когда фаза восстановления занимала минут 8-10, но это было в исключительных ситуациях при старте боевой базы. На резерве все накатывалось довольно шустро (3-5 минут от силы). У меня всегда интервал между репликами равнялся 30 минутам и никогда у меня не создавалась очередь из следующих для наката экстентов (то есть все файлы за это время обрабатывались с большим запасом по времени).
Апдейт на более свежую версию - это явно не скоро. А поддерживать резервную теплую базу необходимо.

Понял, спасибо. Значит, если возникнет такая же ситуация буду пересоздавать реплику - гемор, но по-другому никак.

Остановил в ночь на субботу сервера на БД. В скрипте бэкапа перед созданием архивной копии вставил усечение bi (если база в offline), восстановил с этого бэкапа реплику. На бою после старта AI сделал преформат bi каждой базы на 512 кластеров. Буду наблюдать за поведением наката. О результатах сообщу позднее.

Кстати общая "информационная" рекомендация: перед накатом очередного AI файла записать в лог базы его размер. Это в принципе должен был бы сделать сам Progress, но он этого к сожалению не делает. К счастью это упущение легко компенсировать.

у меня всё на винде и не уверен, что с поднятым брокером я смогу командой перенаправления записать какую-то инфу в лог базы... А самое главное - для чего знать размер экстента?

если речь о целевой - то с этим проблем нет. Я смотрю на сами экстенты в директории во время наката. Возможно, что с записью в логе базы удобнее. Тут дело вкуса и предпочтений.
Кстати, пока накат ai работает без нареканий. Самые тяжелые экстенты загружаются в течение 3 минут, а в среднем в течение десятка секунд. То есть пока полёт нормальный.