开发同事在群里反馈，客户的生产库中有报错信息：
memory notification: library cache object loaded into sga
heap size 512346k exceeds notification threshold (51200k).
并将trc文件发了过来。

通过搜索 497b0fa4 找到libraryhandle Address=0x20683af20的SQL。

继续搜索找到了子游标的LibraryHandle。

sql的子游标总数达到了4543，并且也给记录了不能共享的原因是Bind mismatch，可以通过动态性能视图v$sql_bind_capture和v$sql_shared_cursor查出绑定变量的值，再来找出不能共享的最终原因。另外MOS上有文档对此问题的详细说明。
Memory Notification: Library Cache Object loaded into SGA / ORA-600 [KGL-heap-size-exceeded] (Doc ID 330239.1)

These are warning messages that are not causing process failure. They appear as a result of event messaging mechanism and memory manager introduced starting with 10gR2 database release. As large objects in the shared pool can potentially cause problems this warning threshold was implemented. Items/SQLs which allocate more space than this warning threshold, outputs a warning to the alert log. This warning is only to inform that a given heap object exceeds the defined threshold size and a trace file is generated so that a DBA can check potentially expensive - from shared memory point of view - objects. These are purely warning messages and have no impact on the database functionality, although they are designed to indicate possible tuning opportunities in customers' applications. The messages do not imply that an ORA-4031 is about to happen immediately unless the size of shared pool is very small.

这些是不会导致进程失败的警告消息。 它们是事件消息传递机制和内存管理器从10gR2数据库版本开始引入的结果。 由于共享池中的大型对象可能会导致问题，因此实现了此警告阈值。 分配的空间大于此警告阈值的sql将向警告日志输出警告。 此警告只是通知给定的堆对象超过了定义的阈值大小，并生成跟踪文件，以便DBA可以从共享内存的角度检查潜在的昂贵对象。 这些纯粹是警告消息，对数据库功能没有影响，尽管它们被设计用来指示客户应用程序中可能的调优机会。 除非共享池的大小非常小，否则这些消息并不意味着即将发生ORA-4031。

由于客户生产环境管理的比较严格，不能登录服务器，只是需要对此给出建议，根据以上的信息分析，由于SQL不能共享导致子游标数量大量增长达到4543个，占用的内存超出了隐含参数控制的阈值50M,alert日志中记录了此警告信息，给出如下建议：
1、设置隐含参数限制SQL子游标数量
alter system set "_cursor_obsolete_threshold"=1024 scope=spfile;
2、通过动态性能视图v$sql_bind_capture和v$sql_shared_cursor查出该SQL绑定变量的值，找出不能共享的根本原因，优化此SQL。