This is still not fixed in 10.1C
Accoring to Progress KB Solution ID: P65028, it's fixed. Our fixed variable 8MB AI extents started out at an average of 5 seconds when applied to the target DB. After about 18,000 iterations of applying these individual extents, it slowed down to 10 minutes per extent.
Let's wait 4 months and see if it slows down again. This time I restructured the target DB extents with more reserved fixed extents than the source DB.
P65028
Fixes:
Upgrade to OpenEdge 10.1C, where code changes were implemented to improve the REDO processing.
Whether upgrading is possible or not, re-baseline the hotspare database as follows:
1.) Take an online probkup of the live database, (live.bak) This will cause an ai switch, so be sure that there is a new ai note available to switch into.
2.) Note in the live database.lg the entry:
"Switched to ai extent 99999. (3777)"
3.) prostrct create hotspare -blocksize <same_as_live.db> using same extent structure as live database
4.) prorest live.bak hotspare
5.) Begin ai rollforward from the note listed in step 2
Consider using FIXED ai extents and ensure that none of the database extents are growing into the variable extent (ie last extent)
They did fix some of the cases where the long redo problem existed. I've seen that that is true.
But it is quite possible that there is more than one similar issue and that your issue has not been fixed.