Re: Ai files roll forwarding
Please don't get mad at me but, taking into account the questions you post, I don't think you understand the concept of after imaging.
It is as easy at that: The after image contains a log of all transaction committed since it has been enabled, regardless which backup method you've chosen ( Progress or non-Progress ) and whether you did take a backup at all or just made the enable after image think you did by marking the database as backed up. But if you are wise, you will always pair the after image with a backup. In case of a disaster when you lose your live database you can then use the backup and the after image to restore it.
How many data you lose and how long it does take to recover depends on two factors:
- The type of disaster your system was exposed to: Could be a database corruption up to a natural disaster where you lose the building in which your production server is located.
- How the disaster recovery strategy you've chosen enables you to respond.
Now you can utilize backup and after imaging in different ways to satisfy your requirements: It can range from simply enabling the after image and copy the after image extents to an equally save location as where you copy your backups to, up to a lukewarm standby in continuously rolling forward the after image to a standby site ( some of us call this poor man's replication ).
So, in case of a disaster you restore your last good backup and roll forward all after image extents you have to fill the gap between when you've taken that backup and your disaster happened. But if you can't afford the recovery time this will take you must make use of a more sophisticated strategy which could involve a standby that is ready to use when you need it. In order to achieve that standby you can buy the OpenEdge replication product from Progress (which is also based on after imaging) or you can take the after images from your live database as they get full, copy it to a standby machine and roll it forward against the standby database. The interval you chose for that process determines how much data you will lose when you lose your production machine.
Regarding confusion: Sometimes there is more than one method and different experiences and different preferences make people chose a different method. But, regardless which method you chose, make sure it fulfills your requirements, you understand it, and, most important of all, test it, test it and test it.
Last but not least: Remember that a disaster caused by nature is not the only bad thing that can happen to your database which will makes it necessary to be able to restore the database.
Heavy Regards, RealHeavyDude.
