我们的Oracle服务器有问题。 几个月前它已经升级到11g，正在运行第三方系统。 这个系统已经运行好几年了（还有其他一些问题），但是这是新的：每天一两次，CPU使用率增加，Cursor Mutex S非常明显，自从服务器启动以来，有三千万个等待事件最近）。
似乎突然之间，一些简单的INSERT已经开始给出问题了。 我们已经检查过，统计数据，索引等是否应该是最新的，大小合适的，磁盘上的空间等等……没有问题。
我们已经隔离了一个SQLexpression式作为主要的罪魁祸首。 一些类似的陈述给出了类似的问题，但我会专注于这个问题。 执行这个特定插入的'中间件'软件同时在〜70个服务器上运行。
当我们开始注意到这个问题时，这个语句在v@sql_shared_cursor有超过10,000个条目。 我们设置了一个cron作业，每5分钟清除一次游标，但是这并不能解决任何问题，只能稍微减less这个问题。
再看一下v@sql_shared_cursor ，结果是创build了许多游标的原因是INST_DRTLD_MISMATCH = Y 这很奇怪，因为中间件（我们几乎没有直接的控制）不能插入那么多的行。
我们转向供应商，问他们如何做插入。 他们回答说，他们从表WHERE 1 = 0做一个select，以获得列结构到他们的内部ADODB对象，然后填充相关的数据。 他们通常执行1到20个插页。 '批量'。
我猜测，当你进行批量更新时，背后的ADODB使得它看起来像一个批量插入，这将是Oracle把这看作批量的唯一合理原因，但是我一直无法find任何困难事实就是这个。
任何人都可以提供洞察力：
编辑：事实certificate，这可能是Linux上的Oracle的错误。 我们目前正在testing一个补丁，如果事实certificate是真的，我会在几天后自己发表一个答案。
编辑2：补丁没有解决它 – 虽然我们可能还没有find原因，我们可能通过增加重做日志的数量缓解了这个问题。 我仍然希望在某个时候写一个答案。
这原来是一个Oracle错误。 在应用下面提到的补丁之后，一个月以上没有单个语句超过50个游标，问题中描述的性能问题已经消失。
补丁：错误10636231 – INSERT .. RETURNING语句的高版本数INST_DRTLD_MISMATCH
已修改17-SEP-2011typesPATCH状态PUBLISHED
错误10636231 INSERT .. RETURNING语句的高版本计数INST_DRTLD_MISMATCH本文给出了错误10636231的简要概述。内容最近一次更新时间：2011年9月17日点击这里查看下面每个部分的细节。 影响：产品（组件）Oracle服务器（Rdbms）
认为受影响的版本范围> = 11.2.0.2，但是低于12.1
确认受影响的版本•11.2.0.2
受影响的平台通用（受影响的所有/大多数平台）
它被认为是默认行为的回归，因此：在11.2.0.2中引入了回归
修复：•12.1（后续版本）中的此问题已得到解决•11.2.0.3•11.2.0.2.3修补程序集更新•11.2.0.2 Exadata数据库的数据包修补程序8•11.2.0.1数据库云服务器数据库的数据包修补程序12•11.2.0.2 Windows平台上的补丁7
症状：相关：•泄漏（内存泄漏/增长）•互斥锁争用•受影响的共享池•由于INST_DRTLD_MISMATCH导致游标不共享•V $ SQLAREA•V $ SQL_SHARED_CURSOR
说明此问题在11.2.0.2中由bug 9380377的修复引入
使用RETURNING子句插入SQL可能不共享导致V $ SQLAREA中的VERSION_COUNT和相关问题（可能的互斥争用等）的子游标。 如果会话涉及全局事务，则会发生这种情况。 例如：如果会话在外部协调的事务（如XA）中执行，或者会话使用数据库链接。
重新发现说明：V $ SQLAREA中的高版本计数带有RETURNING子句的插入语句涉及全局事务V $ SQL_SHARED_CURSOR中的原因是INST_DRTLD_MISMATCH