Data conversion to Unicode during an Upgrade

ice_cube210

VIP Member
Hi List,

I had a quick question for those of you who converted your Business Data to unicode in a recent upgrade to 8.9/8.10/8.11

Did you select the unicode option while defining the Business Data and Control Table datasources in the upgrade plan. Does this tell the TC workbench to convert the data to unicode also while doing the upgrade conversion

Or did you leave them as non unicode, complete the TC workbench as you normaly would and then specifically convert the required datasources using the P93091 application..?

Thanks in Advance
 
So I would define the datasources as non unicode , complete the upgrade and then do the unicode conversion.

Thanks
 
You should leave Unicode flag "as is".
If you're upgrading, then Business Data and Control Tables
will appear as non-Unicode while Central Objects, Versions,
Data Dictionary, System, etc... will appear as Unicode.
Leave them "as is" and you'll convert them later, after
you completed the whole upgrade.
 
In our case...one year later and still no data conversion to Unicode. The performance penalty is obvious in certain areas....
 
Thats another interesting topic, whether staying on non unicode has peformance impacts. I guess this does vary from database to database.

Theoriticaly in 8.10 the middleware has to do an extra conversion step every time it reads or writes to a non unicode datasource.

In SQL Server I really dont any difference in the performance of our Xe system and the new upgraded 8.10 system
 
Sorry to hijack your thread to some degree...

But for those of you that have done the conversion, how long did the conversion process take?

Thanks!

Dan
 
Dan,

It depends on the amount of data that is being converted.

I read where one site converted their data in ten hours, a former client converted their data in three days... I've heard some large installations taking even longer.

I am interested if anyone has an algorithm to estimate the length of time the unicode conversion 'may' take.

(db)
 
I am attaching a presentation from Oracle about Unicode conversion for E1. It has one slide which details time taken for unicode conversion for various databases depending on the size of the data and hardware configuration used. Check slide/page no 16 for details

Hope this helps
 
Thanks! Based on those numbers, we'll be converting data for 8 days straight.
smile.gif
Yikes!
 
We have specific UBE's that processed in 15 minutes under Xe, moving to 8.9 increased the runtime to 45 minutes and in some cases the specific versions take 45 to 90 minutes. Needless to say, the users weren't happy. You could say that changes to the code had something to do with it, but looking at the old source code and the new, it is hard to find anything that is the obvious culprit. In our case, moving from Oracle 8i to 9i R2 was just as much a factor in performance degradation as anything else, but there definitely was a relationship between the 8.9 upgrade and UBE performance degradation that had nothing to do with the Oracle upgrade which occurred 1 month prior.

As far as time to convert is concerned, I've been told that 'your mileage may vary'. We've tossed around the idea of breaking certain large tables out into their own data sources for a staggered conversion. Our business can't be down for much more than a couple of days (scheduled on a weekend of course) let alone 7 to 14 days for a conversion.
 
Charles,

For the UBEs that are taking longer than expected, after the migration - have you valuated that all the necessary indexes were recreated?

Cut the SQL statement from the longer running version's Debug log, put it into a query analyzer (I like aqua) and see what it spits back. It might be a case were you need to add an index to one or more tables.

Then again, it could just be that Unicode is taking a percentage longer to query/process.

(db)
 
With your experience with the performance hits, which areas (Modules) for you were hit the hardest?

Thanks!
 
DB,

Yes, we ran through all of the necessary steps to be certain that all indexes in the database matched the E1 specs, and we've also added a fair number of custom indexes which were not originally in the E1 specs but have been added for sameness sake (and to ease the burden of the DBA to manage documentation of custom indexes for the next upgrade cycle.)

Some batch processing seems to take absolutely no more or less time under 8.9 than under Xe. Those jobs were mostly I/O bound anyway, as far as I can tell. The jobs where we took the biggest hit are those that perform lots and lots of logic intensive calculations, the jobs that show tons of local processor time and hardly any db access time. Put those into Performance Workbench and it cries for mercy. I might look into the Aqua tool you mentioned, just to see if the grass is greener on the other side.

I saw a demo of something at Quest which really piqued my curiosity, a generic statistics app which really looks promising. I'm waiting for Oracle to release that particular tool into the general population of JD Edwards users.

Chris, if you're reading this, I'm working on the Oracle contract issue...
 
Financials applications, mostly. We use almost every module in JDE with only a few exceptions. Some issues are resolved simply by applying the 100 or so ESUs which address memory leaks, performance opportunities, etc. We've had some issues with looping in UBE's and specific UBE's like the cost rollup and sim/freeze jobs are just horrendous after the upgrade from Xe.

Still, when everything else has been done - your typical resolutions like SQL query tuning, table and index statistics updates, data purges, even throwing hardware at it, you come back to the code and find more issues. Still, I have my theory that Unicode will help in some key areas, hurt us in a few and make no difference in most. The only way we'll really know is to do it in a lab or DEV environment and run some benchmarks against todays performance 'baseline'.
 
Charles,

That tool you saw at Quest - what was it called, if you recall?
Was it EPM?
(db)
 

Similar threads

E9.2 Printing Issue after upgrade to 9.2
Replies
2
Views
394
Segfault
E9.2 Transfer DB2 table which was created outside of JDE to Oracle database
Replies
0
Views
294
toky701202
E8.11 E1 Upgrade
Replies
3
Views
850
aasmasiddiki
  • Poll
JDE CNC role disappearing?
Replies
5
Views
504
jdeKernel
E9.2 Is there a way to simulate a configured item order to calculate sales price?
Replies
1
Views
161
MaikS90
Back
Top