oracle ora 00910,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/,如需轉載,請注明出處,否則將追究法律責任。
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的oracle ora 00910,NVARCHAR2字段超长问题:ORA-00910: specified length too long for its datatype的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: activiti 生命周期_一文让你读懂
- 下一篇: dvt高危患者的护理措施_dvt的预防及