前兩天我在工作中遇到這樣一個(gè)問題，我們有一個(gè)程序是用來增量抽取EBS 中的表數(shù)據(jù)的，有的是全量抽取，即先刪除原表中的數(shù)據(jù)，然后重新抽取數(shù)據(jù)，示例代碼如下：

truncate table ods_emp drop storage;
 insert into ods_emp select * from emp;

另外一種方式是增量抽取，用的是merge語句，這里就不寫了;)

接觸過EBS庫存模塊的同志們知道，INV中的物料表是MTL_SYSTEM_ITEM_B，這個(gè)表的字段那叫一個(gè)多！我之前搞錯(cuò)了，用的是第一種方案提取的，這就會(huì)導(dǎo)致我的程序運(yùn)行之后數(shù)據(jù)會(huì)大量減少（原因是臨時(shí)表只有一兩天的數(shù)據(jù)，大家懂得）。恰好這問題是在調(diào)試程序時(shí)出現(xiàn)的，并且不只是我負(fù)責(zé)的INV出現(xiàn)了問題，其他同事的模塊也有。于是項(xiàng)目經(jīng)理怒了，發(fā)話：今天誰搞不完，加班！

      我可不想加班，趕緊把語句由INSERT寫成MERGE。寫完一運(yùn)行，報(bào)錯(cuò)：

  哦，原來是字符超長了。在這里我就不把之前的程序?qū)戇@里了，以免嚇到大家。我用下面的代碼來模擬這個(gè)錯(cuò)誤吧：

SQL> DECLARE
  v_str VARCHAR();
  v_cnt NUMBER;
 BEGIN
  v_str := RPAD('select count(*) from emp',);
  EXECUTE IMMEDIATE v_str INTO v_cnt;
  dbms_output.put_line('v_cnt: '||v_cnt);
 END;
 /
DECLARE
*

第 1 行出現(xiàn)錯(cuò)誤:

ORA-06502: PL/SQL: 數(shù)字或值錯(cuò)誤 :  字符串緩沖區(qū)太小
ORA-06512: 在 line 5

我想這還不好辦嘛，直接把varchar2改成long?？墒沁€是報(bào)錯(cuò)了：

SQL> DECLARE
  v_str LONG;
  v_cnt NUMBER;
 BEGIN
  v_str := RPAD('select count(*) from emp',);
  EXECUTE IMMEDIATE v_str INTO v_cnt;
  dbms_output.put_line('v_cnt: '||v_cnt);
 END;
 /
DECLARE
*

第 1 行出現(xiàn)錯(cuò)誤:

ORA-06502: PL/SQL: 數(shù)字或值錯(cuò)誤 :  字符串緩沖區(qū)太小
ORA-06512: 在 line 5

我之前在網(wǎng)上查的是LONG類型支持2G的大小，不知為啥，這次報(bào)錯(cuò)了。平時(shí)由于工作的限制，很少接觸像LONG,LOB,CLOB等大數(shù)據(jù)類型，以后可得仔細(xì)研究下了。

自己當(dāng)時(shí)有點(diǎn)兒著急了，也想不出合適的辦法來，只能請(qǐng)教同事了。還真有一個(gè)同事遇到過，她把字符串變量定義成CLOB類型，具體請(qǐng)看代碼：

DECLARE 
 v_str CLOB;
 v_temp_str VARCHAR();
 v_cnt NUMBER;
 BEGIN
 dbms_lob.createtemporary(v_str,true);--創(chuàng)建一個(gè)臨時(shí)lob
 v_temp_str := RPAD('select count(*) ',);
 dbms_lob.append(v_str,v_temp_str);--把臨時(shí)字符串付給v_str
 v_temp_str := RPAD('from emp ',);
 dbms_lob.append(v_str,v_temp_str);--把臨時(shí)字符串付給v_str
 EXECUTE IMMEDIATE v_str INTO v_cnt;
 dbms_output.put_line('v_cnt: '||v_cnt);
 dbms_lob.freetemporary(v_str);--釋放lob
 END;

運(yùn)行結(jié)果：v_cnt: 14

總結(jié)：1.用CLOB類型可以處理字符串超長的情況；

         2.ORACLE 的大數(shù)據(jù)類型還須研究。