Can OE12 AI files be applied to an OE11 DB?

ron

ron

Member
Linux 9.2 -- OE 11.7.20 --> OE 12.8.3

We are getting close to the end of a major project upgrading from OE 11 to OE 12 and changing from Classic AppServers (on Windows) to PASOE on the DB server.

Conversions/upgrades have been done and thoroughly tested on numerous non-production servers -- the final stage of upgrading the Production server is scheduled for early January.

At the time of conversion of Production the 'old' Production will be running on OE 11.7.20 and we will have a full copy of the Production server already upgraded to OE 12.8.3 and so we plan to copy the DB backups from the 'old' server to the 'new' server -- restore them with OE11 -- run conv1112 -- then start-up the 'new' server (having fixed-up all the IPs and hostnames, etc).

Having tested that process several times we are confident in it working OK.

We have plans for backing-out if we hit trouble upgrading Production, but the auditors have asked a question that I can't answer. If we carry-out the conversion and start running with the new server running OE12 and after running for some time we encounter a problem that requires us to revert to the 'old' server. This would be a dreadful thing to happen, of course! But, if we could apply the AI files generated after the conversion to the OE 11 DB at least we would not lose updates to the DB. However, I presume that OE 11 would not accept and process AI files from OE 12. Is that correct?

Ron.
 
> I presume that OE 11 would not accept and process AI files from OE 12. Is that correct?

Invalid after image version number found in ai file header. Please verify your Progress version, OS version, or AI block size are correct. (752)

Plus you can apply AI files only to a database restored from backup. You can't restore V12 backup using prorest from V11.7. Otherwise probkup/prorest would work as the "revert" option.

> If we carry-out the conversion and start running with the new server running OE12 and after running for some time we encounter a problem that requires us to revert to the 'old' server.

It's possible to revert V12 db to the version 11.7 but it's unsupported and rather risky. We tested this possibility long time ago and abandoned this idea.
 
I recently had a customer that wanted to be able to revert from oe12 back to oe11 if something were to go wrong after going live with their migration. We scripted, and tested, a reverse dump & load. We would have needed 6 or 8 hours to revert a couple TB of databases.

They almost exercised the capability when there were serious problems with a component that they had been unable to test properly in non-prod environments. Luckily a last minute Heisenbug experiment “fixed” the issue and they were able to carry on with oe12. (A debug message was added to the code and the problem went away… possibly because the code was recompiled.)
 
I'd suggest a follow-up conversation with the auditor about the perceived business risk. If they want the option to invoke a post-migration fallback, after a go/no-go decision has been made for "go" and new writes are happening in OE 12, then that suggests to me that they don't have confidence in the pre-migration testing. So they should specify what they feel hasn't been sufficiently tested. If they can't, then this is FUD (fear, uncertainty, doubt).

Falling back to 11.7 and keeping the data committed in OE 12 would involve a dump and load. And that means more testing, scripting, etc., i.e. more cost. It also would involve some amount of downtime, based on your quality of hardware, quantity of data, and D&L configuration, so the cost of that downtime would need to be factored into the business decision to fall back.
 
> It's possible to revert V12 db to the version 11.7 but it's unsupported and rather risky.

The difference between the V11 and V12 db structures is the metaschema and the version in the db extent blocks. If there are no application data in Schema Area and if you can postpone for a while the schema changes after migration to V12 then you can revert database back to V11 almost instantly using old Schema Area from V11 and the current db extents from V12. I even wrote a program to update the extent header blocks automatically. In our case it was a multi-terrabyte database and D&L was not an option. We thought about the fast revert option only as of the last resort. The thorough testing before the migration was the main option.
 
No, Rob, neither. TDE is planned to be implemented a few weeks after the upgrades of OE and the change to PASOE. We don't have Replication; we have a 'cold' DR server and ship AI to it every 12 minutes. The business accepts the risk of losing up to 12 mins of transactions.

Thanks for the responses -- I was pretty sure that applying OE12 AI to an OE11 DB wouldn't work. We have a process to "simultaneously" dump from one DB and load into another. It takes about 3 hours and it looks like that might be the only option. However -- the testing of this upgrade has been so exhaustive that I think the likelihood of having to revert is negligible -- but auditors often ask difficult questions.
 
I asked about replication because not everyone is aware that, as of OE 12.3, it is possible to upgrade replicated databases to OE 12.x without having to reseed.

And I asked about TDE because there is a data-loss bug in proutil -C conv1112 when TDE is in use with certain conditions.
 
You must log in or register to reply here.
Back
Top