共计 13008 个字符，预计需要花费 33 分钟才能阅读完成。
最近有一个同事问我一个问题，说他运行一个 SQL 语句抛出了 ORA-00600 的错误，想让我帮忙分析一下，这种问题听了确实有兴趣，了解了问题的大体情况之后，发现这个问题还是值得分析分析的，因为只是客户端调用抛出异常，没有给服务器端带来什么致命的影响，这样的问题还是很耐人寻味的。
简单沟通后，我得到了同事提供的 SQL 语句和执行环境，语句类似下面的形式：
MERGE INTO (SELECT * FROM TEST_SERVER_LOG WHERE BUY_TIME>=TO_DATE(:1 ,’YYYY-MM-DD HH24:MI:SS’)
AND BUY_TIME<to_date(:2 ,’yyyy-mm-dd=”” hh24:mi:ss’) AND PUT_DATE=TO_DATE(:3 ,’YYYY-MM-DD’)) T
USING(SELECT
TO_CHAR(:4) AS SN,
TO_NUMBER(:5) AS GROUP_ID,
TO_NUMBER(:6) AS SERVER_IP,
TO_CHAR(:7) AS SERVER_NAME,
TO_NUMBER(:8) AS WORD,
TO_NUMBER(:9) AS SERVER,
TO_NUMBER(:10) AS SCENE,
TO_CHAR(:11) AS CN_GUID,
TO_DATE(:12 ,’YYYY-MM-DD HH24:MI:SS’) AS BUY_TIME,
TO_NUMBER(:13) AS JEWEL_TOTAL,
TO_CHAR(:14) AS CN,
TO_CHAR(:15) AS CHARACTER_PUT,
TO_CHAR(:16) AS IP,
TO_NUMBER(:17) AS WEAPONID,
TO_DATE(:18 ,’YYYY-MM-DD’) AS PUT_DATE,
TO_NUMBER(:19) AS WEAPONID_NEW,
TO_NUMBER(:20) AS COUNT,
TO_NUMBER(:21) AS USER_CLASS,
TO_CHAR(:22) AS CONSUME_WAY,
TO_NUMBER(:23) AS CLIENT_STYLE,
TO_CHAR(:24) AS GAME_TYPE
FROM DUAL) A
ON (T.SN=A.SN)
WHEN NOT MATCHED THEN
INSERT(T.SN,T.GROUP_ID,T.SERVER_IP,T.SERVER_NAME,T.WORD,T.SERVER,T.SCENE,T.CN_GUID,T.BUY_TIME,T.JEWEL_TOTAL,T.CN,T.CHARACTER_PUT,
T.IP,T.WEAPONID,T.PUT_DATE,T.WEAPONID_NEW,T.COUNT,T.USER_CLASS,T.CONSUME_WAY,T.CLIENT_STYLE,T.GAME_TYPE)
VALUES(A.SN,A.GROUP_ID,A.SERVER_IP,A.SERVER_NAME,A.WORD,A.SERVER,A.SCENE,A.CN_GUID,A.BUY_TIME,A.JEWEL_TOTAL,A.CN,A.CHARACTER_PUT,
A.IP,A.WEAPONID,A.PUT_DATE,A.WEAPONID_NEW,A.COUNT,A.USER_CLASS,A.CONSUME_WAY,A.CLIENT_STYLE,A.GAME_TYPE)
这样一个语句看起来结构挺复杂，细看逻辑其实倒不复杂。最近处理了几个性能问题，其实有不少都是和 Merge 的使用有关，这个语句有什么问题呢，目前来看没有直接的问题，唯一的感觉是绑定变量不少啊，另外需要补充一下，数据库版本是 11.2.0.3
拿到语句要分析的时候，能够复现问题是非常难得的机遇，有很多的 ORA-00600 错误要复现需要上下文环境触发一定的条件才可以复现，这个问题让我省了不少事，我在 alert 日志中也发现了对应的 trace 文件。当然这类的 trace 文件说实话还是蛮枯燥的，看起来基本都是朦朦胧胧。
我没有花太多时间在这个 trace 上，转而尝试去复现这个问题，
首先我通过 v$sql 去数据库中查看这个 SQL 语句，结果查找的很仔细，竟然没有任何的信息，仿佛这个语句没有执行过一般。
然后我切换到属主用户下，尝试生成执行计划。庆幸的是这个时候问题可以复现出来了。
SQL> @600.sql
explain plan for MERGE INTO (SELECT * FROM TEST_SERVER_LOG WHERE BUY_TIME>=TO_DATE(:1 ,’YYYY-MM-DD HH24:MI:SS’)
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [qcsfbdnp:1], [4], [], [25], [], [],
[], [], [], [], [], []
由此可见，这个语句在 SQL 解析的时候就会抛出问题。对于这个报错，在 MetaLink 上进行一番查找，发现相关的 bug 还真不少，锁定了一个较为符合的 bug.
Bug 13496884 ORA-600 [qcsfbdnp:1] from Merge Statement with Bind Variables
是和执行 Merge 相关的，但是查看里面的解释，就是打补丁，没有其它的解决方法。
其实对于 ORA-00600 的错误，就类似开发中的 NULLPointerException，这类问题的边界比较模糊，排查需要花费一些精力。
我的初步感觉就是问题可能出现在两个方面。
1. 一个是 TEST_SERVER_LOG 这个表数据量非常大，是否在 Merge 中有一定的影响导致
2. 语句中含有大量的绑定变量，是否绑定变量数过多导致了 Merge 的支持出现了问题
于是我朝着这个方向进行了分析和排查。我逐个替换了绑定变量，把它暂时替换为常量，发现错误依旧出现，只是错误的参数部分会有下标的变化。
直到我把整个 using 部分的绑定变量全部替换掉，最后竟然抛出了一个看起来不大相关的错误。
T.IP,T.WEAPONID,T.PUT_DATE,T.WEAPONID_NEW,T.COUNT,T.USER_CLASS,T.CONSUME_WAY,T.CLIENT_STYLE,T.GAME_TYPE)
*
ERROR at line 30:
ORA-00904: “T”.”GAME_TYPE”: invalid identifier
看这个问题，是字段不存在，仔细查看源表中的字段信息，发现这个字段还真是不存在，我是如获至宝，好像找到了问题的原因。
select game_type from TEST_SERVER_LOG where rownum<2
*
ERROR at line 1:
ORA-00904: “GAME_TYPE”: invalid identifier
临时修复了这个问题，把这个字段先去掉，语句就可以正常解析了，但是问题的原因是什么呢，这个时候还是稀里糊涂。我尝试在 using 子句中再次添加一个绑定变量，问题再次出现。
ERROR at line 1:
ORA-00600: internal error code, arguments: [qcsfbdnp:1], [7], [], [2], [], [],
[], [], [], [], [], []
所以这个时候我的一个初步结论是，这个错误和绑定变量的个数没有关系，这个问题的直接原因还是因为语句中的一个字段不匹配导致。
那么这个问题是否和数据量有关呢，在咨询了开发的同事之后，发现字段不匹配的问题还是存在一些误解，因为开发提供的用户是另外一个，属主和我测试的也完全不一样。测试的用户中的这个 TEST_SERVER_LOG 的数据量情况如下：
SQL> select count(*)from dystat_bg.TEST_SERVER_LOG ;
COUNT(*)
———-
1
所以可以证明，这个 bug 和 TEST_SERVER_LOG 的数据量无关，和绑定变量的个数无关。
明白了这两点我们再来看看 trace 文件中的内容：
看到了这么一段，对我们分析这个 ORA-00600 的错误还是有一些帮助的。
—– Incident Context Dump —–
Address: 0x7fff07bebbc0
Incident ID: 324423
Problem Key: ORA 600 [qcsfbdnp:1]
Error: ORA-600 [qcsfbdnp:1] [4] [] [7] [] [] [] [] [] [] [] []
[00]: dbgexProcessError [diag_dde]
[01]: dbgeExecuteForError [diag_dde]
[02]: dbgePostErrorKGE [diag_dde]
[03]: dbkePostKGE_kgsf [rdbms_dde]
[04]: kgeadse []
[05]: kgerinv_internal []
[06]: kgerinv []
[07]: kgeasnmierr []
[08]: qcsfbdnp [SQL_Parser]<– Signaling
[09]: qcpibva []
[10]: qcpiapr []
[11]: qcpiafa []
[12]: qcpiaex []
[13]: qcpifn1 []
[14]: qcpifun []
[15]: qcpiapr []
[16]: qcpiafa []
[17]: qcpiaex []
[18]: qcpiexl []
报错编码是[qcsfbdnp:1], [7], [], [2], [], [], 这个代表的含义在这个日志中可以看到是熟悉 SQL 解析器的部分调用出现了问题。
而我们分析问题的时候就可以重新审视这个语句，看看是否存在一些隐患。后续我们继续补充。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2016-07/133393p2.htm
继前面一个 SQL 语句导致的 ORA-00600 错误之后，我给出了背景和初步的分析结果，今天来给出我的结论，当然说明原因不是我的本意，还有反思。
首先语句类似这样的形式：
MERGE INTO (SELECT * FROM TEST_SERVER_LOG WHERE BUY_TIME>=TO_DATE(:1 ,’YYYY-MM-DD HH24:MI:SS’)
AND BUY_TIME<to_date(:2 ,’yyyy-mm-dd=”” hh24:mi:ss’)=”” =”” and=”” put_date=”TO_DATE(:3″ ,’yyyy-mm-dd’))=”” t USING(SELECT
TO_CHAR(:4) AS SN,
TO_NUMBER(:5) AS GROUP_ID,
。。。
TO_NUMBER(:23) AS CLIENT_STYLE,
TO_CHAR(:24) AS GAME_TYPE
FROM DUAL) A
ON (T.SN=A.SN)
WHEN NOT MATCHED THEN
INSERT(T.SN,T.GROUP_ID,T.SERVER_IP,。。。)
VALUES(A.SN,A.GROUP_ID,A.SERVER_IP。。。)
运行后会报出 ORA-00600，我在初步的分析之后排除了绑定变量的个数，表中数据量大的可能因素。
在经过一番周折之后，发现问题可能出在这个语句的结构上。
当然我换一个方式来说明，我可以随便创建一个表，然后模拟这个 ORA-00600 的错误。
创建测试表 test_bug
SQL> create table test_bug as select * from dba_objects where rownum<1;
Table created.
然后使用如下的语句尝试生成执行计划。
SQL> explain plan for merge into (select * from test_bug where object_type=’TABLE’) t
using (select :1 object_id,:2 object_name,:3 objet_type from dual) a
on(t.object_id=a.object_id)
where not matched then
insert into test_bug(object_id,object_name,object_type) values(a.object_id,a.object_name,a.object_type);
explain plan for merge into (select * from test_bug where object_type=’TABLE’) t
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [qcsfbdnp:1], [1], [], [4], [], [],
[], [], [], [], [], []
当然了我无意中埋下了几个探针，如果你看到语句哪里有问题，后续分析就会明白了。
这个语句里的问题我是可以保持了 (select * from test_bug where object_type=’TABLE’) t 这个子查询，抛出了 ORA-00600 的错误，那么我再简化一番如何，简化为（select*from test_bug）t 这个子查询，同样还是会抛出一样的错误。
explain plan for merge into (select * from test_bug) t
using (select :1 object_id,:2 object_name,:3 objet_type from dual) a
on(t.object_id=a.object_id)
where not matched then
insert into test_bug(object_id,object_name,object_type) values(a.object_id,a.object_name,a.object_type);
explain plan for merge into (select * from test_bug) t
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [qcsfbdnp:1], [1], [], [4], [], [],
[], [], [], [], [], []
我们来回过头来翻翻旧账，刚刚的语句的问题在如下的几个地方，在解析的时候都没有抛出错误，可见问题是出在这些之前，那么推理只有 test_bug 相关的子查询了。
修复这几个语法之后，使用下面的方式就没有问题了。
explain plan for merge into test_bug t
using (select :1 object_id,:2 object_name,:3 object_type from dual) a
on(t.object_id=a.object_id)
when not matched then
insert (object_id,object_name,object_type) values(a.object_id,a.object_name,a.object_type);
明白了问题的原因，我们来反思一下，其实我们缩写的 merge 语句都是 merge into table_xx using(xxxx) on (xxx)的形式
在 table_xx 的地方加入子查询，可能会让我们在联想到一些语句中使用子查询的 DML 方式，但是在 merge 语句中，这个地方就是大忌，所幸的是这个问题目前的测试没有发现对线上环境产生严重的影响，但是需要引以为戒。
而对于 merge 语句的更多反思，如下：
1. 我所从事的一些调优工作中，对于 merge 的优化很难下手，因为这虽然是一个语句，但是有多重执行路径，执行计划没法确定，使用调优工具优化也给不出建议。
2. 在 10g 的版本中，如果 scheduler 中使用 PL/SQL 块，包含有 merge 语句，使用 dbms_metadata.get_ddl 竟然无法查看到完整的 DDL 信息
3. 如果你想查看到 DDL 的信息，如果通过解析 dmp 的方式，就会发现 DMP 对于这个语句的处理很是特殊，可能又会让你失望了。
这些问题会或多或少困扰到你，而我印象很深的案例，则是第 1 项中列举的，优化类的困扰。我举一个例子。
下面是我在一次系统监控中发现的一个性能问题，CPU 使用异常，而经过分析发现瓶颈来源于数据库层面的一个 SQL 语句。
看到的语句类似这样的形式：
MERGE INTO UC_OPENPLATFORM_USER t
USING (SELECT count(*) CNT from UC_OPENPLATFORM_USER where
USER_ID=:1 and PLATFORM=:2) tw
ON (tw.CNT>0)
WHEN MATCHED THEN UPDATE SET t.NAME=:3, t.UPDATE_DATE=SYSDATE
where USER_ID=:4 and PLATFORM=:5
WHEN NOT MATCHED THEN INSERT(USER_ID, PLATFORM, NAME,
CREATE_DATE, UPDATE_DATE) VALUES(:6, :7, :8, SYSDATE, SYSDATE)
查看执行计划发现里面存在大量的全表扫描，资源消耗极高。
而这个语句的逻辑其实仔细看看还能明白，就是在插入一条记录前看看表中是否含有，如果没有就插入，否则更新，但是里面使用了 count(*)的方式处理，过滤条件存在一些潜在的问题，而优化方式就是简化这种逻辑。改为如下的方式：
MERGE INTO UC_OPENPLATFORM_USER t
USING (SELECT :1 USER_ID,:2 PLATFORM from DUAL) tw
ON (tw.USER_ID=T.USER_ID and tw.PLATFORM=t.PLATFORM)
WHEN MATCHED THEN UPDATE SET t.NAME=:3, t.UPDATE_DATE=SYSDATE
where USER_ID=:4 and PLATFORM=:5
WHEN NOT MATCHED THEN INSERT(USER_ID, PLATFORM, NAME,
CREATE_DATE, UPDATE_DATE) VALUES(:6, :7, :8, SYSDATE, SYSDATE)
而对 ORA-00600 的这个问题，其实也可以进一步反思，这个 merge 使用只有一个场景，其实可以考虑使用 INSERT 语句来实现。
很多的事情都有两面性，merge 语句就是如此，而且是一种特殊的存在，我依然记得很久之前的一次技术争论中，有人说道：判断一个技术的优劣，也需要看待，到底是它带来的问题更多还是解决的问题更多？
确实如此。
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-07/133393.htm
最近有一个同事问我一个问题，说他运行一个 SQL 语句抛出了 ORA-00600 的错误，想让我帮忙分析一下，这种问题听了确实有兴趣，了解了问题的大体情况之后，发现这个问题还是值得分析分析的，因为只是客户端调用抛出异常，没有给服务器端带来什么致命的影响，这样的问题还是很耐人寻味的。
简单沟通后，我得到了同事提供的 SQL 语句和执行环境，语句类似下面的形式：
MERGE INTO (SELECT * FROM TEST_SERVER_LOG WHERE BUY_TIME>=TO_DATE(:1 ,’YYYY-MM-DD HH24:MI:SS’)
AND BUY_TIME<to_date(:2 ,’yyyy-mm-dd=”” hh24:mi:ss’) AND PUT_DATE=TO_DATE(:3 ,’YYYY-MM-DD’)) T
USING(SELECT
TO_CHAR(:4) AS SN,
TO_NUMBER(:5) AS GROUP_ID,
TO_NUMBER(:6) AS SERVER_IP,
TO_CHAR(:7) AS SERVER_NAME,
TO_NUMBER(:8) AS WORD,
TO_NUMBER(:9) AS SERVER,
TO_NUMBER(:10) AS SCENE,
TO_CHAR(:11) AS CN_GUID,
TO_DATE(:12 ,’YYYY-MM-DD HH24:MI:SS’) AS BUY_TIME,
TO_NUMBER(:13) AS JEWEL_TOTAL,
TO_CHAR(:14) AS CN,
TO_CHAR(:15) AS CHARACTER_PUT,
TO_CHAR(:16) AS IP,
TO_NUMBER(:17) AS WEAPONID,
TO_DATE(:18 ,’YYYY-MM-DD’) AS PUT_DATE,
TO_NUMBER(:19) AS WEAPONID_NEW,
TO_NUMBER(:20) AS COUNT,
TO_NUMBER(:21) AS USER_CLASS,
TO_CHAR(:22) AS CONSUME_WAY,
TO_NUMBER(:23) AS CLIENT_STYLE,
TO_CHAR(:24) AS GAME_TYPE
FROM DUAL) A
ON (T.SN=A.SN)
WHEN NOT MATCHED THEN
INSERT(T.SN,T.GROUP_ID,T.SERVER_IP,T.SERVER_NAME,T.WORD,T.SERVER,T.SCENE,T.CN_GUID,T.BUY_TIME,T.JEWEL_TOTAL,T.CN,T.CHARACTER_PUT,
T.IP,T.WEAPONID,T.PUT_DATE,T.WEAPONID_NEW,T.COUNT,T.USER_CLASS,T.CONSUME_WAY,T.CLIENT_STYLE,T.GAME_TYPE)
VALUES(A.SN,A.GROUP_ID,A.SERVER_IP,A.SERVER_NAME,A.WORD,A.SERVER,A.SCENE,A.CN_GUID,A.BUY_TIME,A.JEWEL_TOTAL,A.CN,A.CHARACTER_PUT,
A.IP,A.WEAPONID,A.PUT_DATE,A.WEAPONID_NEW,A.COUNT,A.USER_CLASS,A.CONSUME_WAY,A.CLIENT_STYLE,A.GAME_TYPE)
这样一个语句看起来结构挺复杂，细看逻辑其实倒不复杂。最近处理了几个性能问题，其实有不少都是和 Merge 的使用有关，这个语句有什么问题呢，目前来看没有直接的问题，唯一的感觉是绑定变量不少啊，另外需要补充一下，数据库版本是 11.2.0.3
拿到语句要分析的时候，能够复现问题是非常难得的机遇，有很多的 ORA-00600 错误要复现需要上下文环境触发一定的条件才可以复现，这个问题让我省了不少事，我在 alert 日志中也发现了对应的 trace 文件。当然这类的 trace 文件说实话还是蛮枯燥的，看起来基本都是朦朦胧胧。
我没有花太多时间在这个 trace 上，转而尝试去复现这个问题，
首先我通过 v$sql 去数据库中查看这个 SQL 语句，结果查找的很仔细，竟然没有任何的信息，仿佛这个语句没有执行过一般。
然后我切换到属主用户下，尝试生成执行计划。庆幸的是这个时候问题可以复现出来了。
SQL> @600.sql
explain plan for MERGE INTO (SELECT * FROM TEST_SERVER_LOG WHERE BUY_TIME>=TO_DATE(:1 ,’YYYY-MM-DD HH24:MI:SS’)
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [qcsfbdnp:1], [4], [], [25], [], [],
[], [], [], [], [], []
由此可见，这个语句在 SQL 解析的时候就会抛出问题。对于这个报错，在 MetaLink 上进行一番查找，发现相关的 bug 还真不少，锁定了一个较为符合的 bug.
Bug 13496884 ORA-600 [qcsfbdnp:1] from Merge Statement with Bind Variables
是和执行 Merge 相关的，但是查看里面的解释，就是打补丁，没有其它的解决方法。
其实对于 ORA-00600 的错误，就类似开发中的 NULLPointerException，这类问题的边界比较模糊，排查需要花费一些精力。
我的初步感觉就是问题可能出现在两个方面。
1. 一个是 TEST_SERVER_LOG 这个表数据量非常大，是否在 Merge 中有一定的影响导致
2. 语句中含有大量的绑定变量，是否绑定变量数过多导致了 Merge 的支持出现了问题
于是我朝着这个方向进行了分析和排查。我逐个替换了绑定变量，把它暂时替换为常量，发现错误依旧出现，只是错误的参数部分会有下标的变化。
直到我把整个 using 部分的绑定变量全部替换掉，最后竟然抛出了一个看起来不大相关的错误。
T.IP,T.WEAPONID,T.PUT_DATE,T.WEAPONID_NEW,T.COUNT,T.USER_CLASS,T.CONSUME_WAY,T.CLIENT_STYLE,T.GAME_TYPE)
*
ERROR at line 30:
ORA-00904: “T”.”GAME_TYPE”: invalid identifier
看这个问题，是字段不存在，仔细查看源表中的字段信息，发现这个字段还真是不存在，我是如获至宝，好像找到了问题的原因。
select game_type from TEST_SERVER_LOG where rownum<2
*
ERROR at line 1:
ORA-00904: “GAME_TYPE”: invalid identifier
临时修复了这个问题，把这个字段先去掉，语句就可以正常解析了，但是问题的原因是什么呢，这个时候还是稀里糊涂。我尝试在 using 子句中再次添加一个绑定变量，问题再次出现。
ERROR at line 1:
ORA-00600: internal error code, arguments: [qcsfbdnp:1], [7], [], [2], [], [],
[], [], [], [], [], []
所以这个时候我的一个初步结论是，这个错误和绑定变量的个数没有关系，这个问题的直接原因还是因为语句中的一个字段不匹配导致。
那么这个问题是否和数据量有关呢，在咨询了开发的同事之后，发现字段不匹配的问题还是存在一些误解，因为开发提供的用户是另外一个，属主和我测试的也完全不一样。测试的用户中的这个 TEST_SERVER_LOG 的数据量情况如下：
SQL> select count(*)from dystat_bg.TEST_SERVER_LOG ;
COUNT(*)
———-
1
所以可以证明，这个 bug 和 TEST_SERVER_LOG 的数据量无关，和绑定变量的个数无关。
明白了这两点我们再来看看 trace 文件中的内容：
看到了这么一段，对我们分析这个 ORA-00600 的错误还是有一些帮助的。
—– Incident Context Dump —–
Address: 0x7fff07bebbc0
Incident ID: 324423
Problem Key: ORA 600 [qcsfbdnp:1]
Error: ORA-600 [qcsfbdnp:1] [4] [] [7] [] [] [] [] [] [] [] []
[00]: dbgexProcessError [diag_dde]
[01]: dbgeExecuteForError [diag_dde]
[02]: dbgePostErrorKGE [diag_dde]
[03]: dbkePostKGE_kgsf [rdbms_dde]
[04]: kgeadse []
[05]: kgerinv_internal []
[06]: kgerinv []
[07]: kgeasnmierr []
[08]: qcsfbdnp [SQL_Parser]<– Signaling
[09]: qcpibva []
[10]: qcpiapr []
[11]: qcpiafa []
[12]: qcpiaex []
[13]: qcpifn1 []
[14]: qcpifun []
[15]: qcpiapr []
[16]: qcpiafa []
[17]: qcpiaex []
[18]: qcpiexl []
报错编码是[qcsfbdnp:1], [7], [], [2], [], [], 这个代表的含义在这个日志中可以看到是熟悉 SQL 解析器的部分调用出现了问题。
而我们分析问题的时候就可以重新审视这个语句，看看是否存在一些隐患。后续我们继续补充。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2016-07/133393p2.htm
