1. High Version Count问题概述在Oracle数据库10.2.0.4和11.2.0.4版本中High Version Count是一个常见且棘手的问题。简单来说当一个SQL语句存在大量子游标(child cursor)时就会出现High Version Count现象。这种现象不仅会消耗大量共享池(shared pool)内存还可能导致严重的性能问题甚至数据库挂起。1.1 什么是Version Count当一个SQL语句首次执行时Oracle会进行硬解析(hard parse)创建父游标(parent cursor)和子游标(child cursor)。后续执行相同SQL时Oracle会先计算SQL语句的hash值然后在共享池中查找匹配的父游标。如果找到匹配的父游标就会遍历其下的子游标列表寻找可重用的执行计划。如果找不到可重用的子游标就会创建新的子游标。父游标下的子游标总数就是这个SQL的version count。当version count过高时就会出现High Version Count问题。1.2 High Version Count的危害High Version Count会带来多方面的问题共享池内存消耗每个子游标都会占用共享池内存大量子游标会快速耗尽共享池空间性能下降查找和匹配大量子游标会增加CPU开销数据库挂起在某些情况下可能导致数据库完全挂起触发ORA-04031错误当共享池空间不足时出现引发其他bug如ORA-600 [kkssearchchildlist*]等2. 诊断High Version Count问题2.1 识别高Version Count的SQL首先需要找出哪些SQL存在High Version Count问题-- 查找version count超过100的SQL SELECT sql_id, version_count, sql_text FROM v$sqlarea WHERE version_count 100 ORDER BY version_count DESC;在AWR报告中默认version count超过20的SQL就会显示在order by version count部分。根据经验version count超过100就需要引起注意。2.2 分析子游标不共享的原因找到问题SQL后需要分析为什么这些SQL会产生大量子游标-- 查看特定SQL的子游标不共享原因 SELECT * FROM v$sql_shared_cursor WHERE sql_id 8n5bcvc2mwjmj;v$sql_shared_cursor视图中的Y值表示对应列存在不匹配(mismatch)情况这是导致子游标不能共享的直接原因。2.3 使用version_rpt工具诊断手工查询上述视图可能比较繁琐Oracle提供了一个名为version_rpt的小工具可以更方便地诊断High Version Count问题。这个工具可以从Oracle支持文档(DOC ID 438755.1)下载。3. 深入诊断技术3.1 CursorTrace和CursorDump当v$sql_shared_cursor无法提供足够信息时可以使用CursorTrace和CursorDump技术进行更深入的诊断。3.1.1 启用CursorTrace-- 启用CursorTrace ALTER SYSTEM SET events immediate trace name cursortrace level 577, address hash_value;CursorTrace有三个级别Level 1: 577Level 2: 578Level 3: 5803.1.2 关闭CursorTrace-- 关闭CursorTrace ALTER SYSTEM SET events immediate trace name cursortrace level 2147483648, address 1;注意在10.2.0.4以下版本存在Bug 5555371可能导致CursorTrace无法彻底关闭trace文件会不断增长。生产环境建议谨慎使用CursorTrace。3.1.3 CursorDump(11g及以上版本)-- 11g中使用CursorDump ALTER SYSTEM SET events immediate trace name cursordump level 16;CursorDump可以收集更全面的信息包括一些其他方法无法看到的px_mismatch和optimizer_mismatch信息。3.2 ProcessState Dump和Errorstack(10gR2)在10gR2中可以使用processstate dump和errorstack替代CursorDump-- 找到问题SQL对应的SPID SELECT spid FROM v$session s, v$process p WHERE s.paddr p.addr AND s.sql_id 问题SQL_ID; -- 使用oradebug进行dump ORADEBUG SETOSPID spid ORADEBUG ULIMIT ORADEBUG DUMP PROCESSSTATE 10 ORADEBUG DUMP ERRORSTACK 34. 常见导致High Version Count的SQL模式根据经验以下类型的SQL最容易导致High Version Count问题4.1 使用绑定变量的INSERT语句INSERT INTO table(column1, column2, ..., column128) VALUES (:1, :2, :3, ..., :128)特别是当表字段很多且INSERT语句中列出了所有字段时问题尤为明显。4.2 使用绑定变量的SELECT INTO语句SELECT a, b, c, ... INTO :1, :2, :3 FROM table14.3 使用INSERT...RETURNING语句INSERT INTO table(...) VALUES (...) RETURNING id INTO :id4.4 使用长IN列表且包含绑定变量SELECT * FROM table WHERE column1 IN (:1, :2, :3, ..., :128)4.5 超长SQL且包含多个绑定变量非常长的SQL语句如果使用了绑定变量更容易出现High Version Count问题。4.6 在DBLINK调用的SQL中使用绑定变量-- 不推荐的做法 SELECT * FROM tabledblink WHERE column :15. 配置参数相关问题5.1 cursor_sharing参数cursor_sharing参数设置不当容易导致High Version Count问题绝对不要使用cursor_sharingsimilar这个设置在10gR2以上版本会导致各种bug包括产生大量不可共享的子游标在11.2.0.3版本cursor_sharingsimilar与force效果相同在12c中已不支持cursor_sharingsimilar建议设置为exact除非经过充分测试否则不要设置为force5.2 Adaptive Cursor Sharing(ACS)11g引入的Adaptive Cursor Sharing特性也容易导致High Version Count问题。在未经充分测试前建议关闭此特性ALTER SYSTEM SET _optimizer_adaptive_cursor_sharingFALSE;相关bugBug 12334286High version counts with CURSOR_SHARINGFORCEBug 7213010Adaptive cursor sharing generates lots of child cursorsBug 8491399ACS does not match the correct cursor version for queries using CHAR datatype6. 常见Bug及解决方案6.1 Bug 8575528 / Patch 6795880这是10gR2中一个非常严重且隐蔽的bug会导致数据库挂起必须手工重启系统资源耗尽导致宕机触发ORA-600 [kkssearchchildlist*]或ORA-07445[kkssearchchildlist*]错误虽然在10.2.0.5中声称已修复但实际仍然常见因为修复代码默认不生效需要手动设置_cursor_features_enabled10即使设置参数仍可能遇到问题解决方案升级到11gR2调整问题SQL6.2 变长字符串绑定变量问题当表字段使用VARCHAR等变长类型而应用传入的字符串长度变化很大时会导致bind mismatch产生大量子游标。解决方案-- 设置固定的字符串buffer长度 ALTER SYSTEM SET events 10503 trace name context forever, level 4000;6.3 Bug 8981059这个bug影响所有10gR2版本是由绑定变量窥测(bind peeking)导致的。解决方案-- 关闭绑定变量窥测 ALTER SYSTEM SET _optim_peek_user_bindsFALSE;6.4 清除高Version Count的SQL对于version count特别高的SQL可以将其从共享池中清除-- 10.2.0.4和10.2.0.5中的清除方法 ALTER SESSION SET events 5614566 trace name context forever; EXEC dbms_shared_pool.purge(address, hash_value, C);注意event 5614566是为了规避Bug 5614566该bug会导致dbms_shared_pool.purge无法清除parent cursor。7. 11g中的增强特性7.1 _cursor_obsolete_threshold参数11g引入了_cursor_obsolete_threshold参数(默认100)当子游标数量超过此阈值时parent cursor会被废弃并创建新的parent cursor。这有效解决了High Version Count问题。启用方法-- 11.2.0.1 ALTER SYSTEM SET _cursor_features_enabled34 SCOPESPFILE; ALTER SYSTEM SET event106001 trace name context forever,level 1024 SCOPESPFILE; -- 11.2.0.2 ALTER SYSTEM SET _cursor_features_enabled1026 SCOPESPFILE; ALTER SYSTEM SET event106001 trace name context forever,level 1024 SCOPESPFILE;8. 最佳实践建议8.1 SQL改写建议对于INSERT INTO或SELECT INTO考虑不使用绑定变量字段很多的表INSERT时不要列出所有字段控制IN列表中绑定变量的数量或改用临时表避免编写特别长的SQL语句尽量避免在DBLINK调用的SQL中使用绑定变量8.2 配置建议设置cursor_sharingexact关闭adaptive cursor sharing对于10.2.0.4考虑升级到更高版本监控并定期清理高version count的SQL8.3 监控脚本-- 监控shared pool中SQLA区域大小 SELECT * FROM V$SGASTAT WHERE poolshared pool AND nameSQLA AND bytes/1024/1024/1024 5; -- 监控硬解析高的非绑定变量SQL SELECT FORCE_MATCHING_SIGNATURE, COUNT(1) FROM v$sql WHERE FORCE_MATCHING_SIGNATURE 0 AND FORCE_MATCHING_SIGNATURE ! EXACT_MATCHING_SIGNATURE GROUP BY FORCE_MATCHING_SIGNATURE HAVING COUNT(1) 5000 ORDER BY 2; -- 查找硬解析最多的SQL SELECT TO_CHAR(force_matching_signature), COUNT(*) hard_parses FROM v$sqlarea GROUP BY TO_CHAR(force_matching_signature) HAVING COUNT(*) 5 ORDER BY 2 DESC;9. 总结High Version Count问题在Oracle 10.2.0.4和11.2.0.4中是一个复杂且棘手的问题其产生原因多样表现形式各异。通过合理的诊断方法和适当的解决方案可以有效地应对这一问题。从11gR2开始通过_cursor_obsolete_threshold特性这个问题得到了根本性的解决。