Good day,
I ran a few tests with online full and incremental backups. I performed an online full backup and subsequent incremental backups on a source machine. Copied these files to a target server and tried applying the files to a source database with the same name but different filesystem location. The full backup restored as expected however when trying to apply the incrementals, I received a message stating that the restore failed, database updated. This occurs even if I create a new database with the same structure as the source database (different filesystem path). No single user or mutli-user sessions were started for this database. This problem only occurs for a database with a particular name. A database with another name restores fine. Even if I create multiple databases with the same name in different paths they all return the same error.
I tested the same restore on another server following the exact sequences with no problem. I verified the backups and they which produced no errors. I have searched through the KB's but with no luck. Could anybody perhaps shed some light on the matter.
Thank you
Edgar
I think this won't work.
When you do a full online backup, you get a time-consistent copy of the active database as it existed at a moment in time, shortly after the backup starts. In this backup, there are likely to be active transactions (though not always) and bi log notes for recent activity. When you restore the database, all that gets put back the way it was. It is similar to a crashed database. When you open it, crash recovery is performed and any incomplete transactions are backed out. Backing out incomplete transactions causes new data block changes to be made and the data block version numbers change too. However, just doing an incremental restore should not send the database though crash recovery. Opening it with a 4GL session or starting a server will though.
If you try to do a restore of an incremental backup on top of the recovered full online backup, the incremental may contain changes that were made by those same active transactions after the full backup was made. Most likely those active transactions were committed. But if they were rolled back following the online restore, then there will be inconsistencies in the combination of the incremental and the rolled back changes.
gus
Thank you Gus for the feedback.
You have highlighted a very crucial point namely data inconsistencies between source and target databases which can occur when restoring a database when any inflight-transactions get backed out on the database you are restoring to while in the mean time during the backup intervals on the source database, these transactions are comitted. I haven't seen this scenario as yet whilst testing these restores but could very well happen. I will however address this in a new thread (how does active transactions affect incremental and after-image backups/ restores and Best Practice methods of avoiding these scenarios).
My problem though was that I could not restore an incremental backup directly after a full backup was restored to a target database. Message " <database name> has been updated, incremental restore not possible. (6773)". According to the Progress KB's this can happen when a broker was started on the target database after the full restore was complete but before the incremental backup was restored. This was not the issue in my scenario as no processes were started against the target database.
I then ran another test. The source server has Progress 9.1E04 and the target server Progress 9.1E (no sp). I restored these files to another test machine with Progress 9.1E01. The incremental restore failed. I installed service pack 4 on the test server and the full restore with incrementals worked fine. My apologies for not highlighting these differences in my initial post.
I'm trying to find a KB entry which highlight this subtle difference. I suppose it's always safer to ensure all platforms are running the same software version and applicable service packs.
Thanks anyway,
Edgar
Ah. I misunderstood your scenario. I thought you were starting up the database after the full restore and then trying to restore the incremental.
Since it works when you use 9.1E04, it is possible that there was some bug-fix made to correct the problem. Perhaps perusing the bug database would shed some light.
gus