在测试库发现了这个错误，检查trace文件，发现是在进行交换分区的时候出现的，询问了一下同事，发现导致这个问题的原因是在交换分区的时候指定了一个临时表。

如果Oracle进行对临时表执行这个错误，那么在这里应该显示错误信息，指出不应该使用临时表，而不是报一个600错误。

下面这个例子简单的重现问题：

SQL> CREATE TABLE T_PART (ID NUMBER, NAME VARCHAR2(30)) PARTITION BY RANGE(ID)
  2  (PARTITION P1 VALUES LESS THAN (10),
  3  PARTITION P2 VALUES LESS THAN (MAXVALUE));

表已创建。

SQL> CREATE TABLE T_EXCHANGE (ID NUMBER, NAME VARCHAR2(30));

表已创建。

SQL> INSERT INTO T_PART SELECT ROWNUM, TNAME FROM TAB;

已创建12行。

SQL> COMMIT;

提交完成。

SQL> ALTER TABLE T_PART EXCHANGE PARTITION P1 WITH TABLE T_EXCHANGE;

表已更改。

SQL> SELECT COUNT(*) FROM T_EXCHANGE;

  COUNT(*)
----------
         9

SQL> CREATE GLOBAL TEMPORARY TABLE T_EXCHANGE_TEMP (ID NUMBER, NAME VARCHAR2(30));

表已创建。

SQL> ALTER TABLE T_PART EXCHANGE PARTITION P1 WITH TABLE T_EXCHANGE_TEMP;
ALTER TABLE T_PART EXCHANGE PARTITION P1 WITH TABLE T_EXCHANGE_TEMP
*
第 1 行出现错误:
ORA-00600: 内部错误代码，参数: [ktsircinfo_num1], [2147483647], [0], [0], [], [], [], []

测试的版本9204，对应的trace文件中的主要信息为：

Dump file e:\oracle\admin\ytk92\udump\ytk92_ora_2280.trc
Sun Jan 20 01:13:00 2008
ORACLE V9.2.0.4.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Instance name: ytk92

Redo thread mounted by this instance: 1

Oracle process number: 14

Windows thread id: 2280, image: ORACLE.EXE

*** SESSION ID:(11.135) 2008-01-20 01:13:00.890
*** 2008-01-20 01:13:00.890
ksedmp: internal or fatal error
ORA-00600: 内部错误代码，参数: [ktsircinfo_num1], [2147483647], [0], [0], [], [], [], []
Current SQL statement for this session:
ALTER TABLE T_PART EXCHANGE PARTITION P1 WITH TABLE T_EXCHANGE_TEMP
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
_ksedmp+327          CALLrel  _ksedst+0           
_ksfdmp.108+14       CALLrel  _ksedmp+0            3
027174D3             CALLreg  00000000             228D20 3
026ABCC3             CALLrel  02717450             228D20 33B004C 1A92D80 3
                                                   4D9C094
_ktsircinfo+179      CALLrel  _kgeasnmierr+0       228D20 33B004C 1A92D80 3 4
                                                   7FFFFFFF 4 0 4 0
_kkbptsi_pack_tbl_s  CALLrel  _ktsircinfo+0       
eg_info+93                                        
_atbFMexchange+2586  CALLrel  _kkbptsi_pack_tbl_s  4D9C5B4 6BBD3774
                              eg_info+0           
_atbdrv+6333         CALLrel  _atbFMexchange+0     4D9D9EC 4D9D928 4D9D9D8
                                                   4D9D9E4 6BB99D3C 4D9D988
                                                   4D9D990 4D9D994
..1.5_1.filter.29+9  CALLrel  _atbdrv+0           
59                                                
_opiosq0+2487        CALLrel  _opiexe+0            4 0 4D9DDC8
_kpooprx+236         CALLrel  _opiosq0+0           3 E 4D9DE60 24
_kpoal8+561          CALLrel  _kpooprx+0           4D9E730 4D9E648 43 1 0 24
_opiodr+1244         CALLreg  00000000             5E 14 4D9E72C
_ttcpip+2554         CALLreg  00000000             5E 14 4D9E72C 0
_opitsk+750          CALLrel  _ttcpip+0           
_opiino+1547         CALLrel  _opitsk+0            0 0 22EED8 336F670 D8 0
_opiodr+1244         CALLreg  00000000             3C 4 4D9FBD4
_opidrv+563          CALLrel  _opiodr+0            3C 4 4D9FBD4 0
_sou2o+25            CALLrel  _opidrv+0           
_opimai+266          CALLrel  _sou2o+0            
_OracleThreadStart@  CALLrel  _opimai+0           
4+961                                             
7C80B680             CALLreg  00000000            
 
--------------------- Binary Stack Dump ---------------------

Metalink中的Bug No. 4581483描述了相同的情况。