NVARCHAR2字段超长问题：ORA-00910: specified length too long for its datatype

NVARCHAR2字段超长问题：ORA-00910: specified length too long for its datatype
前几天在IMP的时候遇到了个问题：
IMP-00017: following statement failed with ORACLE error 910:
"CREATE TABLE "T_CSL_DYNAITEMDATAENTRY" ("FID" VARCHAR2(44) NOT NULL ENABLE,"
" "FITEMDATAID" VARCHAR2(44) NOT NULL ENABLE, "FITEMID" VARCHAR2(44) NOT NUL"
"L ENABLE, "FKEYNUMBER" NVARCHAR2(500) NOT NULL ENABLE, "FKEYNAME" NVARCHAR2"
"(500) NOT NULL ENABLE, "FDATAELEMENT" NUMBER(10, 0) NOT NULL ENABLE, "FVALU"
"ETYPE" NUMBER(10, 0) NOT NULL ENABLE, "FYEAR" NUMBER(10, 0) NOT NULL ENABLE"
", "FPERIOD" NUMBER(10, 0) NOT NULL ENABLE, "FVALUE" NUMBER(21, 6), "FDYNAIT"
"EMTYPE" NUMBER(10, 0), "FTEXTVALUE" NVARCHAR2(4000), "FGRADENUMBER" VARCHAR"
"2(80))  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 STORAGE(INITIAL 15728"
"640 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "EAS_D_CH"
"INAMOBILE_STANDARD" LOGGING NOCOMPRESS"
IMP-00003: ORACLE error 910 encountered
ORA-00910: specified length too long for its datatype
查找了网上的一些资料，由于两个系统分别为LINUX同SOLARIS，因此最初检查了数据库字符集：
SQL> select userenv('language') from dual;
USERENV('LANGUAGE')
----------------------------------------------------
AMERICAN_AMERICA.UTF8
检查结果两个系统相同为UTF8。
由于SQLARIS为测试环境，系统配置相对比较差一些，因此考虑资源配置的因素，将SOLARIS中/etc/system 中进行了相应修改：
SHMMAX=4294967295
SHMMIN=1
SHMMNI=100
SHMSEG=10
SEMMNI=100
SEMMSL=60
SEMMNS=200
SEMOPM=100
SEMVMX=32767
set nproc=10000 并加入此行，将原先系统默认的进程的最大数目为3000修改成10000
但通过测试后还是没有成功。实在不想打表同数据的主意，但看来也只好这么搞了。

对于NVARCHAR2的字符长度的限制产生疑问，手工在SOLARIS中建这张表，同样报这个错误。在metalink.oracle.com查找解决方式，查看到Tom Villane对于相同问题的一个解释，摘抄如下：

You will have to change the value of NVARCHAR2 to less than 4000 in order to create the table. I don't have a database with your specific character set, so you will have to experiment with different values (2000, 3000, 3500 .etc...) until you are able to create the table.
没办法手工建表后发现在SOLARIS上最大只能将NVARCHAR2建到2000的长度，郁闷！但怎么将IMP的这张表同数据导入呢？
试验用JDBC数据同步复制两张表的数据，但还是由于这个错误，而无法同步；
将正事生产环境上的这个字段改小成2000EXP这张表后在SOLARIS上IMP还是相同的错误；
又有个新的问题：NVARCHAR2最长2000～4000的限制是什么原因而决定的?
数据库的版本肯定是一样的，字符和其他全部已经修改了。现今唯一的最大差异就是系统平台，狠狠心吧。懒人最不喜欢的就是做那种无聊的系统，但也只好把SOLARIS重新安装成了LINUX，之后还安装了相同版本的数据库。
但最终依然没有解决，最终判断出了NVARCHAR2字符限制的起因：
NVARCHAR2的字符最大限制是由于系统的硬件环境而决定的，具体构成和规律未知！！！！！
看来ORACLE对系统环境的依赖还真市够大的了。
没办法了，开始打表的主意吧！
打开这张表查看里面的具体数据，此列是可以为NULL的，看里面很多行都是空的，只是个别行中有100多个汉字，因此判断此列也许为备注之类的数据列。
既然不是关键数据，而且是要搞到测试环境里面，那多这列少这列就没多大意义，可以大胆的处理了。
正事库的操作：
首先把库中的这张表EXP出来；
在正事库中将这张表的NVARCHAR2列删除掉；
到处没有NVARCHAR2列的表；
删除这张已经缺列的表；
把刚才EXP出来的表再IMP进去恢复
（当然还有一种回复的方式就是闪回，但要牵扯闪回表和按照时间戳再闪回一次，因此我还是能懒就懒了，解决问题为主了。）
在测试库的操作；
把缺列的表DMP备份FTP到测试机器上；
看库里有没有这张表，要有就DROP掉；
导入这个缺列的表；
手工建立缺失的列；

最终搞定，数据虽然没有，但由于是测试环境也就无所谓了，能用就OK了！真要是正式环境也不会这么烂的机器了，当然也不会有这个情况。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7652889/viewspace-627087/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7652889/viewspace-627087/