当前位置:Gxlcms > mysql > ORA-12899:valuetoolargeforcolumn

ORA-12899:valuetoolargeforcolumn

时间:2021-07-01 10:21:17 帮助过:39人阅读

ORA-12899: value too large for column,本来以为程序修改导致字段长度变了,就改了一张表的结构。结果可好,导下一张表依然报错

昨天,同事导数据,本来一直好用的文件,就一直在报错:ORA-12899: value too large for column,本来以为程序修改导致字段长度变了,就改了一张表的结构。结果可好,导下一张表依然报错。。报错也好,也就确定了不是程序问题,是DB做的有问题。后来靠着强大的google找到了答案,才觉得Oracle error code也很强大!

通常会查询NLS_CHARACTERSET(数据库字符集),NLS_NCHAR_CHARACTERSET(国家字符集),应该要存储多种语言,需要字符集为UTF-8。

SELECT * FROM V$NLS_PARAMETERS WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

结果UTF-8,OK。

查看没问题的DB里 FieldA varchar2(10 char)

查看有问题的DB里 FieldA varchar2(10)

(没出现问题之前还真没注意到这两种定义是有区别的。。。)

UTF-8里一个中文字符是3 bytes,从上面的定义可以看出来,如果char/byte 定义导致的可存储数据长度相差很大了。

设置参数NLS_LENGTH_SEMANTICS可以在create table时对CHAR 或者VARCHAR2列指定使用字节(byte)或者字符(character)来定义长度。

NCHAR, NVARCHAR2, CLOB, and NCLOB 列都是基于字符(character)的。

NLS_LENGTH_SEMANTICS不会影响到SYS和SYSTEM用户表,数据字典定义都使用字节(byte)。

可以在定义列时候显示指定使用字节(byte)或者字符(character)来定义长度:

CHAR(10 BYTE) - 无论NLS_LENGTH_SEMANTICS设置成什么,都使用字节(byte)。

CHAR(10 CHAR) - 无论NLS_LENGTH_SEMANTICS设置成什么,都使用字符(char)。



select * from v$nls_parameters where parameter = 'NLS_LENGTH_SEMANTICS';

PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_LENGTH_SEMANTICS
BYTE

ALTER SYSTEM SETNLS_LENGTH_SEMANTICS=CHAR scope=BOTH;
修改完毕重启DB,show parameter NLS_LENGTH_SEMANTICS 依然是BYTE。

Update props$ set VALUE$=‘CHAT’ Where name=‘NLS_LENGTH_SEMANTICS’;

--好吧,,不知道直接update有没影响,不是product DB才可以这么嚣张的操作的。。貌似很多人不让这样改字符集,其实改完参数就应该继续往下测试,避免用这样极端的修改方式。

NLS_LENGTH_SEMANTICS值更改为了CHAR

select * from v$nls_parameters where parameter = 'NLS_LENGTH_SEMANTICS';

PARAMETER
----------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_LENGTH_SEMANTICS
CHAR

再导数据依然报错。。。

重建刚才的表,就发现之前定义varchar2(10) 变成了varchar2(10 char),也就是说修改生效了。但是为什么还是不能正常导数据呢?

后来发现,NLS_LENGTH_SEMANTICS 还有一句说明:现有列不受修改影响!!

也就是说想要通过这种方法解决问题貌似行不通了,因为不想把那几万张用户表都alter一遍。

在Create DB时候确实需要非常细致,避免类似这种错误,create之后早期也要做好必要的check避免之后发生类似问题。之前还犯过把DB字符集搞错了,结果这些参数改来改去最后还是不得不重建DB。

linux

人气教程排行