Re: NLS_LENGTH_SEMANTICS = CHAR import is too slow
From: <zigzagdna_at_yahoo.com>
Date: Tue, 7 May 2013 19:25:34 -0700 (PDT)
Message-ID: <2e89a133-3e6c-46eb-8a31-f447c8a08f46_at_googlegroups.com>
On Saturday, May 4, 2013 4:38:13 PM UTC-4, zigz..._at_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.
Date: Tue, 7 May 2013 19:25:34 -0700 (PDT)
Message-ID: <2e89a133-3e6c-46eb-8a31-f447c8a08f46_at_googlegroups.com>
On Saturday, May 4, 2013 4:38:13 PM UTC-4, zigz..._at_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. Received on Wed May 08 2013 - 04:25:34 CEST