Open Edge Upgrade -- Started thread under DB Admin too

sekarv

New Member
Hi,

We are in the process of upgrading from 9.1e version (32bit) to open edge 10.02B (64 bit). At this point in time we have made the appropriate changes to our code to remove deprecated features and are currently testing our application. Before we upgrade our production environment i had a few questions / concerns for which i would need to seek help from this forum.

a) What kind of rollback strategies can be employed while performing the above upgrade? I am aware of initial backup (9.1e) or dump and load but is there any thing else which can be considered and which would be faster without losing transactions. Because once migrated to open edge and we face any issues after around 3 weeks it will then become almost impossible to go back to 9.1 e without dump and load. Is there anything else we can do to mitigate the risks ?

b) I do understand that moving from a 32bit version to 64 bit will help enhance application / database performance (by tuning the appropriate params) are there any drawbacks specific to performance or any other items which we would need to test prior our production move. I believe this was tried earlier in our 9.1d version but somehow we did not proceed. Hence i am lil skeptical of how this would behave.

All your inputs on this will be highly appreciated.

Thanks,
Sekar
 
There's no going back except by doing a d&l.

Well, in theory, you /could/ have some code that writes a transaction log in a replayable format of some sort. But unless your software already has such a capability it sounds like a pretty big project to me.

You should get much better performance if you test adequately ahead of time, tune appropriately and take advantage of new features. Properly implemented type 2 storage areas are a huge win. I know a consultant who would be happy to help (see below).

Keep in mind that many 64 bit things are going to be bigger. That means it will use more RAM. So you need to make sure that you have that RAM and that the Progress parameters which consume RAM are retuned to account for the change. One big thing that is often over looked are r-code size (which impacts -mmax among others).

Not directly related to 32 bits vs 64 but related to 9.x vs 10.x is -tmpbsize... the default value changes to 4 with oe10 and this will have a significant impact on how temp tables behave. This can impact both RAM usage and disk usage in the -T directory as well as performance of temp-table code. If your application makes heavy use of temp-tables you may want to specify -tmpbsize 1.

Also -- resist the urge to panic. I have seen customers pull the plug over conversions over the discovery of bugs that have been in their software for years. They finally notice the bug on conversion day because people are paying attention -- but running code that they never actually use in real life! I've seen some close calls for pretty weak reasons too. This is where testing, testing and more testing are your friend.
 
thanks Tom for your valuable inputs. i will certainly work on the details as mentioned by you and properly plan our testing strategy before implementation. We as progress devlopers whole heartedly wish to move to open edge but are little skeptical as we do not want it to cause problems by any means.

Regards
Sekar
 
If you make the move in a reasonably careful and planned manner it will be painless and very beneficial.

The only times I have ever seen problems are when people do the cowboy routine, don't bother to plan or test (or get help where they need it) and then blame the tool for the result.
 
Re: betting on hockey

Hi Tom:

We use Protop frequently on 9.1E for application/database performance monitoring. Please let me know whether Protop is available for OE 10.2B as well?

Thanks,
Ravish
 
Hi Tom:

We use Protop frequently on 9.1E for application/database performance monitoring. Please let me know whether Protop is available for OE 10.2B as well?

Thanks,
Ravish
 
ProTop is giving below error while running against 10.B03 database. Please advise.

More than one _ActBuffer records found by a unique FIND. (3166)
More than one _ActBuffer records found by a unique FIND. (3166)
Press space bar to continue.

After pressing space bar:
More than one _ActBuffer records found by a unique FIND. (3166)
 
Back
Top