Effects Of Unicode??

[rhunt01]

Can someone give me the low-down on unicode? I have heard that we have the choice to convert or not to convert for our upgrade to 8.10. I've also been told that Unicode will be faster - but use more diskspace (at first glance this doesn't make sense. It appears that Unicode would be much more I/O constrained).

We are a domestic company - and as far as I can tell, we have no reason for Unicode. Am I wrong?

Details would be appreciated.

Thanks.

 

[cbruce]

If you go Unicode:

1. All your objects and code MUST go Unicode.

a. This means that if you made custom mods or new objects, you must slime and retrofit when you go to Unicode.
b. As you develop forward, you MUST adhere to Unicode standards of coding. If you do not, you will introduce a new class of bugs into your code.

2. You may elect to convert your DATA to Unicode or not. If you do not, then the middleware will auto-convert Unciode<->ANSI. If you do convert, then there is no additional overhead in the middleware (but your resulting data size will be bigger.)

If you've made custom mods, expect to spend a considerable amount of time:

a. Ungrading you mods
b. Trying to get your system back to a live state
c. Working out new bugs introduced by Unicode

Cheers

 

[jstooge]

Ahh...Jim's rambling on Unicode...

1. Everything other than business data and control tables must be in Unicode, so if you don't have a Unicode compliant DB, you have to get one.

2. If comparing a XE/8.0 system ON THE SAME EXACT system to the performance of 8.9/8.10/8.11...you will see a performance decrease.

3. If you compare a system with business data and control tables in Unicode to the same system with both not converted, you will see about a 25 - 35% hit in performance on the non Unicode system.

Now, with that said, most people upgrade the hardware during the software upgrade, so the effects of the Unicode performance hit can certainly be managed. Also, you can upgrade the system and not convert the data and control tables until a later date, so you can budget for the other hardware in one fiscal period, and then take the disk hardware hit in another.

While you are a domestic company, and I understand your reasoning that you really don't "need" Unicode, the push to Unicode was intended to help multinational companies, but the other reason that people don't mention is that the architecture of the system is evolving to Java which also is driving the move to Unicode.

Regards,

 

[MichaelSeymour]

Here is an FAQ Oracle put together to address common questions regarding Unicode.

Thanks

 

[JDEPrincess]

Michael...

For whatever reason, I cannot open the attachment's link. (**administrators please note**)

Could you pretty please (or someone) e-mail it to me at [email protected]?

Thank!!

Aspen <-- my name, not my location :grin:

 

[rhunt01]

I'm really not happy to hear about the 25%-35% performance hit. Unfortunately, current utilization doesn't justify upgrading our AS400 - nor would my budget allow for it if it did. However, there is one enhancement I can afford, so here is a question that gets down to the nitty gritty of OneWorld workloads on an AS400...

I have an iSeries 270 with 2350 CPW - delivered through two S-Star 600 mhz processors. However, even though this is a dual processor box - queries do not automatically use SMP. SMP is a billable feature (5722SS1 - Option 26). With that being said, the system divvies out linear query processing between two processor - but no SMP.

As of V5R2 and the new SQE (Sequel Query Engine), IBM has been touting that SQE and SMP eligible queries can now be processed in half the time with SMP enabled. So the question becomes, with SMP enabled, do OneWorld interactive applications and UBE's typically utilize the SQE and SMP - or are they typically very serial queries handed off to the CQE (classic query engine), which won't use SMP?

In the end, I am hoping that a several thousand dollar billable option can compensate for my Unicode performance hit.

Any insight would be appreciated.

Thanks in advance.

 

[SQLGAL]

Ryan,

My gut feel is that you should wait till 8.11 and do it then only because "they’ll" force you to convert. You WILL need a much bigger machine then to handle the same workload.

As for SMP, here are some answers:
SMP will help regardless of path taken by the query optimizer (SQE or CQE). It is true that SQE will leverage SMP more heavily than CQE, possibly providing more help. SMP could be a double edged sword, so user be warned. Reason behind that is that if there is a particularly poor (aka unoptimized or runaway) query, for example coming from QBE or similar ad-hoc feature, SMP may opt to use all processors to satisfy that query. If that query is going to take a long time (minutes, hours), it could monopolize your system’s CPU for that time frame. Most people don’t run into this problem, but some have. How do they solve it? Kill the job, baby. However, pain would have already been felt by all of your interactive users before you take that action.

Jen

 

[AllisonD]

Quite a while ago I was told by IBM that SMP would not work on our 730-2068 8-way. That feature code would not support hardware multi threading. It may no longer be an issue but I'd check again before purchasing and be specific about your model and feature code just to play it safe.