I had an issue with restoring my Progress database and the AI roll forward process that has me a little stumped. I restored the backup from 5/27 12:30AM without incident. During the evening I went and copied over the AI files for that day as seen at the very bottom. Below I copied the command prompt for the session I was using during the roll forward operation.
C:\Intergy\DB>rfutil medman -C roll forward -a D:\int_bkp\CopyAI\medman.a4
OpenEdge Release 10.1B0347 as of Tue Feb 3 10:20:44 EST 2009
** The database was last changed Thu May 27 21:13:10 2010. (831)
** The after-image file expected Tue May 25 21:00:04 2010. (832)
** Those dates don't match, so you have the wrong copy of one of them. (833)
roll forward open D:\int_bkp\CopyAI\medman.a4 error: -1. (11014)
I got a response from Donald Church that explained what’s going on:
“Glad to hear that the training is proving useful – and I think I know what is happening with your AI roll. According to your screenshots, you restored a backup that was made at 12:30 AM on 27 May. This would mean that at that time an AI switch would have occurred, the previous AIs copied to the backup folder and all copied AIs would have been remarked as empty. (This is assuming you had used the backup script and not a manual backup)
What the message in the Roll Forward of .a4 is telling you is that at some point after the restore, around 9:13 PM, the database was started and records began to be written. So if you imagine for a moment that the database was on record 10,000 at the time of backup, the AI file immediately started would have recorded record 10,001. But by starting the database at 9:13, a new record 10,001 was written along with whatever data followed thereafter. Now fast forward to 10:20 PM when you attempt the Roll Forward – you are asking the database to accept the original record 10,000 from the AI file when it is now on record 10,012 or something due to the database running since the restore. In a nutshell, by using the database after the restore, you invalidated all those AI records since they are sequential for only the original data.
This is similar to the issue in the movie ‘Back to the Future, Part II’ – Doc and Marty couldn’t fix what Biff did with the sports almanac in the future because if they traveled to the future, it would be the alternate future where Biff was powerful. The solution to your problem is the same as what they did in the movie – go to the past and fix it there. Restore the database from the backup again and Roll Forward the AIs without starting the database this time. That will make the numbers be in sequence and work.
The only caveat to all this is whether or not AI was turned on after you did the original restore – if so, you might have AI data based off all the records that the database added after the restore at 9:13 PM. Luckily, RFUTIL is pretty smart and will notice those records don’t match on time stamps and have wrong sequence numbers.”
C:\Intergy\DB>rfutil medman -C roll forward -a D:\int_bkp\CopyAI\medman.a4
OpenEdge Release 10.1B0347 as of Tue Feb 3 10:20:44 EST 2009
** The database was last changed Thu May 27 21:13:10 2010. (831)
** The after-image file expected Tue May 25 21:00:04 2010. (832)
** Those dates don't match, so you have the wrong copy of one of them. (833)
roll forward open D:\int_bkp\CopyAI\medman.a4 error: -1. (11014)
I got a response from Donald Church that explained what’s going on:
“Glad to hear that the training is proving useful – and I think I know what is happening with your AI roll. According to your screenshots, you restored a backup that was made at 12:30 AM on 27 May. This would mean that at that time an AI switch would have occurred, the previous AIs copied to the backup folder and all copied AIs would have been remarked as empty. (This is assuming you had used the backup script and not a manual backup)
What the message in the Roll Forward of .a4 is telling you is that at some point after the restore, around 9:13 PM, the database was started and records began to be written. So if you imagine for a moment that the database was on record 10,000 at the time of backup, the AI file immediately started would have recorded record 10,001. But by starting the database at 9:13, a new record 10,001 was written along with whatever data followed thereafter. Now fast forward to 10:20 PM when you attempt the Roll Forward – you are asking the database to accept the original record 10,000 from the AI file when it is now on record 10,012 or something due to the database running since the restore. In a nutshell, by using the database after the restore, you invalidated all those AI records since they are sequential for only the original data.
This is similar to the issue in the movie ‘Back to the Future, Part II’ – Doc and Marty couldn’t fix what Biff did with the sports almanac in the future because if they traveled to the future, it would be the alternate future where Biff was powerful. The solution to your problem is the same as what they did in the movie – go to the past and fix it there. Restore the database from the backup again and Roll Forward the AIs without starting the database this time. That will make the numbers be in sequence and work.
The only caveat to all this is whether or not AI was turned on after you did the original restore – if so, you might have AI data based off all the records that the database added after the restore at 9:13 PM. Luckily, RFUTIL is pretty smart and will notice those records don’t match on time stamps and have wrong sequence numbers.”
No comments:
Post a Comment