在测试库发现了这个错误,检查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描述了相同的情况。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-153400/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-153400/