JD Edwards upgrade–make it faster

This is going to be a bit of a tease post, apologies.  Want to reduce your TC times from 50 hours to 2.5?

I’ve been recently engaged by a client to see what can be done with their upgrade window.  Everyone that has more than 1TB of data will start to push the upgrade window boundaries for their go-live weekend.  What I’m saying is, out of the box upgrading E1 with standard methodologies will take 12 –> 24+ hours with 1TB+ of data in normal circumstances.  Unless you have exadata, then it might take 15 minutes.

Remember that the data upgrade part of the upgrade process is generally only a small piece.  You still need to reconcile data in XE, then upgrade, then reconcile and then test again – this can take a lot of time.  You need to always make the technical piece more efficient to take the pressure off the other teams.

As you are aware there are 3 types of TC’s in the upgrade process (I’m talking specifically table conversions – data only update).

• *MERGE
• *ALTER
• UBE

Each type of TC does what the name implies.  *MERGE is generally merging the contents of two tables into 1.  For example, F0911 and F0911T into F0911TCTEMP and then a rename back to F0911 and a heap of indexes along the way.

*ALTER is all about adding columns with default values.  ALTER TABLE X ADD COLUMN Y…  Sometimes when you are dealing with a large table (50000000 rows), this ALTER can take longer than a generation and a load (funny isn’t it!).

And UBE, my favourite.  UBE’s are generally the worst performers of all.  they are UBE, because generally they cannot do the table upgrade in any form os set based logic, so we go back to simple RAT (Row at a Time) processing.  RAT for 50 million rows!!!  No thanks.

So how can we make this process faster – or what sort of improvements can be gained with some tweaking?

I’ve been able to take the F4072 and F4074 upgrade times from 50 hours to 1.5.  That’s not all, F42119 from about 20 hours to 2.5.  This is using the same hardware and the same software (well, JD Edwards and a database), but re-engineering the scripts to use the power of the database, not just archaic slow RAT logic that is supported with the JD Edwards middleware.

I’ll start posting a little more detail about these tweaks.  So it might be that the upgrade that you thought impossible is very possible.

You must also be open to “pre-upgrading” your data.  Of course if you are a large rich multinational, you might consider goldenGate to be your silverBullet – which it could easily be.  But you could also kill this bird with a simple implementation of oracle streams or some simple triggers to pre-upgrade all of your tables and then only apply the logic to changes into the 9.1 database.  Of course for goldenGate or streams or triggers, you still need to reverse engineer all of the TC’s and apply that logic.