NLS_LENGTH_SEMANTICS = CHAR import is too slow

[zigz...@yahoo.com]

I am converting a database from its current character set WE8ISO88591 to AL32UTF8
I am using NLS_LENGTH_SEMANTICS to CHAR so I do not have to increase column lengths.

I follow Oracle instructions:
144808.1
313175.1

Except import which takes way too long.

I took a full export of WE8ISO8859p1 Database and now importing it in AL32UTF8.

It is always difficult to prove where the slowness is coming from; but I think it has to do something with NLS_LENGTH_SEMANTICS. On the same
server; if new database was in WE8ISO8859P1, a 5 million row table import took 2 hours; but in Al32UTF8 with NLS_LENGTH_SEMANTICS it is taking 1 day!!!

Any idea how to improve the performance of import.

[Mladen Gogala]

On Sat, 04 May 2013 13:38:13 -0700, zigzagdna wrote:

> Any idea how to improve the performance of import.

http://www.youtube.com/watch?v=B11QLCQk9Mo



--
Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com

[zigz...@yahoo.com]

On Saturday, May 4, 2013 5:48:25 PM UTC-4, Mladen Gogala wrote:
> On Sat, 04 May 2013 13:38:13 -0700, zigzagdna wrote: > Any idea how to improve the performance of import. http://www.youtube.com/watch?v=B11QLCQk9Mo -- Mladen Gogala The Oracle Whisperer http://mgogala.byethost5.com

I am looking for something worth while! I cannot find anything on internet on inner working of NLS_LENGTH_SEMANTICS=CHAR but there is something defintely present which makes import painfully slow.

[zigz...@yahoo.com]

[Mladen Gogala]

On Sat, 04 May 2013 19:26:24 -0700, zigzagdna wrote:


> I am looking for something worth while! I cannot find anything on
> internet on inner working of NLS_LENGTH_SEMANTICS=CHAR but there is
> something defintely present which makes import painfully slow.

You are funny. You made a diagnosis and now are looking for something
"worth while". Try with the tuning process. If you need help, try
attaching a 10046 trace file.

[ddf]

Can you post any proof that the NLS_LENGTH_SEMANTICS setting is causing your 'problem'? It's SO easy to jump to conclusions and impossible to jump back. Possibly you should provide evidence of your findings rather than speculation.

"Pardon me," said Milo to the first man who happened by; "can you tell me where I am?"

"To be sure," said Canby; "you're on the Island of Conclusions. Make yourself at home. You're apt to be here for some time."

"But how did we get here?" asked Milo, who was still a bit puzzled by being there at all.

"You jumped, of course," explained Canby. "That's the way most everyone gets here. It's really quite simple: every time you decide something without having a good reason, you jump to Conclusions whether you like it or not. It's such an easy trip to make that I've been here hundreds of times."

"But this is such an unpleasant-looking place," Milo remarked.

"Yes, that's true," admitted Canby; "it does look much better from a distance."

As he spoke, at least eight or nine more people sailed onto the island from every direction possible.

"Well, I'm going to jump right back," announced the Humbug, who took two or three practice bends, leaped as far as he could, and landed in a heap two feet away.

"That won't do at all," scolded Canby, helping him to his feet. "You can never jump away from Conclusions. Getting back is not so easy. That's why we're so terribly crowded here."


David Fitzjarrell

[TheBoss]

ddf <ora...@msn.com> wrote in
news:86131c63-6f55-499b...@googlegroups.com:

:-)

http://www.youtube.com/watch?v=Xmm7bMU459o
[The Phantom Tollbooth: Chapter 13 - Unfortunate Conclusions]
[fragment starts at about 8:50]

http://www.youtube.com/watch?v=Llg5VODW6n4
[The Phantom Tollbooth, 1970 film based on the book]

--
Jeroen

[zigz...@yahoo.com]

On Saturday, May 4, 2013 4:38:13 PM UTC-4, zigz...@yahoo.com wrote:

> I am converting a database from its current character set WE8ISO88591 to AL32UTF8 I am using NLS_LENGTH_SEMANTICS to CHAR so I do not have to increase column lengths. I follow Oracle instructions: 144808.1 313175.1 Except import which takes way too long. I took a full export of WE8ISO8859p1 Database and now importing it in AL32UTF8. It is always difficult to prove where the slowness is coming from; but I think it has to do something with NLS_LENGTH_SEMANTICS. On the same server; if new database was in WE8ISO8859P1, a 5 million row table import took 2 hours; but in Al32UTF8 with NLS_LENGTH_SEMANTICS it is taking 1 day!!! Any idea how to improve the performance of import.

I myself never belived that NLS_LNEGTH_SEMANTICS will cause such extreme slowness; but did not what else it could be.
Root cause of such slowness turned out not to be import;
but HP UNIX's Process Resource Manager. Process Resource Manager controls how much resources (CPU) one can use. It turns out it has some bugs and those bugs made everything extrenely slow when import was running. As a DBA; it is hard for me to know what is causing such slowness; but eventually with the help of storage group and UNIX group, root cuase was idnetified and fixed. One wonders why HP UNIX sells this buggy software.

[Mladen Gogala]

On Tue, 07 May 2013 19:25:34 -0700, zigzagdna wrote:

> One wonders why HP UNIX sells this buggy software.

Do you know anyone other than Oracle selling bug-free software?

[Gerard H. Pille]

Mladen Gogala wrote:
> On Tue, 07 May 2013 19:25:34 -0700, zigzagdna wrote:
>
>> One wonders why HP UNIX sells this buggy software.
>
> Do you know anyone other than Oracle selling bug-free software?
>
>
>

µicro$oft springs to mind.

[Mladen Gogala]

Microsoft is no longer 800 LBS gorilla it once was. It has lost of weight
and the performance with Windows 8 is less than stellar. Hopefully, they'll
be smarter than Icaza who has ruined GNOME, and bring back the venerated
"Start" button. The "metro" is not what I want. However, their office
suite is second to none. Active directory and Exchange are excellent
software. There are many good and sound products at MS. As for the GNOME,
I have switched to XFCE and have not looked back. XFCE is a decent desktop
environment which doesn't attempt to turn my laptop into a cell phone.