SQL語句是動態生成的,結構大致如下
select a.columnname from tablename a,tablename b
where a.columnname=b.columnname 
and a.columnname in (值xx,值xx,值xx,...) 
    or a.columnname in (值xx,值xx,值xx,...)
    .....
    or a.columnname in (值xx,值xx,值xx,...)
整個SQL語句不含空格共102594個字節.
如果將 in (值xx,值xx,值xx,...)裡面的值減少一些,小於101754字節時執行這個SQL語句就不會報錯了.
是不是SQL語句最長長度的限制?網上搜了一下關於SQL語句最長長度的問題,也是眾說紛紜的.
我的Oracle版本是9204.

解决方案 »

  1.   

    查了一下,
    9i版本的话:
      SQL statement最长:65535 Byte, 就是64K.
      Middleware的话,32K也有可能。
      使用DBMS_SQL的话,可以超过64K。10g版本的话:
      完全没有长度限制。LZ的句子里面,In 后面,最长大概有多少呢?
      

  2.   

    看的是Oracle 9i datebase ref r2里面的。
    还有这个长度,好像是不包括空白的。
      

  3.   

    做了一些測試,發現跟SQL語句長度好像又沒啥關係.
    昨天請分公司的同事執行了一下這個SQL語句(他們的表結構跟我們一樣,只是資料量大小不一),結果沒有報錯,他們Oracle版本也跟我們一樣是9204的.
    更神奇的是我發現把tablename b的PK刪掉,SQL語句就可以執行了,再加上就又不行.所以想不通的就是
    1.將   in   (值xx,值xx,值xx,...)裡面的值減少一些,SQL語句就可以執行
    2.或者將tablename b的PK刪掉,SQL語句也可以執行
    實在不行,我就考慮換種SQL寫法了,只是碰到這樣的問題不知道原因,解決不了有些不甘心,呵呵.
      

  4.   

    根据你的现象,可以做如下简单推理:
    1、sql语句本身是合法的
    2、有可能是sql优化机制的问题,导致当B表有主键索引时失败而没有时成功
    3、也有可能是当前session的可用资源瓶颈问题,可以通过执行计划查看sql执行代价,in   (值xx,值xx,值xx,...)   
            or   a.columnname   in   (值xx,值xx,值xx,...) 
            ..... 
            or   a.columnname   in   (值xx,值xx,值xx,...) 的逻辑如果使用了索引,那么会有对索引总值列表个数次的访问,如果B表还有索引,有可能造成当前会话可用资源耗竭或某些节点溢出从而出现内部错误
    4、也有可能是关于sql长度和索引消耗的参数设置问题,不过本人还真不知道这方面的参数
    建议对比下两个系统的设置1、从sql优化角度分析
    通过以下语句对比下两个系统的sql优化模式,如果有不同的地方把有问题的机器的参数设置成和没问题的机器相同的参数再试一下
    sqlplus username/password@connection_string
    show parameter optimizer2、从系统资源角度分析
    对比两台服务器的pga和sga设置,如果有不同,建议
      

  5.   

    我把問題又簡化了一下.A表,B表資料都被我truncate掉了.執行還是報ora-00600,跑執行計劃也是報這個錯.A表是partition table,B表是普通表.我另建了一個表結構跟表A一樣的普通表C代替表A執行SQL就OK.我另外找了一個數據庫建partition表A,表B.執行是OK的.這是不是說問題就出在這個數據庫的跟partition有關的一個參數設定上呢?
      

  6.   

    执行时报错ORA-00600,是因为undo段出了问题,还是从这方面着手想想你的数据库的设置.如果有备份的话,可以先进行一下数据库的恢复,再执行一下你的SQL语句,看是不是还报错ORA-00600.