Library Cache Pin 及 Library Cache Lock分析： Oracle使用两种数据结构来进行Library Cache的并发访问控制：lock和pin。lock可以被认为是解析锁，而pin则可以被认为是以读取或改变对象内容为目的所加的短时锁。之所以将Library Cache Object对象分开，使用多个锁定来保护，其中一个重要的目的就是为了提高并发。 lock比pin具有更高的级别。lock在对象handle上获得，在pin一个对象之前，必须首先获得该handle的锁定。handle可以理解为Library Cahce对象的Buffer Header，其中包含[......]
SHARED_POOL_RESERVED_SIZE参数的设置及作用
SHARED_POOL_RESERVED_SIZE参数的设置及作用： 还有一个参数是需要提及的：shared_pool_reserved_size。该参数指定了保留的共享池空间，用于满足将来的大的连续的共享池空间请求。当共享池出现过多碎片，请求大块空间会导致Oracle大范围的查找并释放共享池内存来满足请求，由此可能会带来较为严重的性能下降，设置合适的shared_pool_reserved_size参数，结合_shared_pool_reserved_min_alloc参数可以用来避免由此导致的性能下降。 这个参数理想值应该大到足以满足任何对RESERVED LIST的内存请求，而无需数[......]
使用Flush Shared Pool缓解共享池问题
使用Flush Shared Pool缓解共享池问题： 前面提到，本质上ORA-04031多数是由于SQL编写不当引起，所以如果能够修改应用绑定变量是最好的解决之道。当然如果应用不能修改，或者不能强制变量绑定，那么Oracle还提供一种应急处理方法，强制刷新共享池。 alter system flush shared_pool; 刷新共享池可以帮助合并碎片（small chunks），强制老化SQL，释放共享池，但是这通常是不推荐的做法，这是因为： ·Flush Shared Pool会导致当前未使用的cursor被清除出共享池，如果这些SQL随后需要执行，那么数据库将经历大量的硬解[......]
绑定变量和cursor_sharing
绑定变量和cursor_sharing： 如果SHARED_POOL_SIZE设置得足够大，又可以排除Bug的因素，那么大多数的ORA-04031错误都是由共享池中的大量SQL代码等导致过多内存碎片引起的。 可能的主要原因有： ·SQL没有足够的共享；·大量不必要的解析调用；·没有使用绑定变量。 实际上说，应用的编写和调整始终是最重要的内容，Shared Pool的调整根本上要从应用入手。根本上，使用绑定变量可以充分降低Shared Pool和Library Cache的Latch竞争，从而提高性能。 反复的SQL硬解析不仅会消耗大量的CPU资源，也会占用更多的内存，严重影响数据库性[......]
Shared Pool 的转储与分析
Shared Pool 的转储与分析： 使用如下命令可以对共享池Library Cache信息进行转储分析： ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level LL'; 其中LL代表Level级别，对于9.2.0及以后版本，不同Level含义如下： ·Level=1，转储Library Cache统计信息；·Level=2，转储Hash Table概要；·Level=4，转储Library Cache对象，只包含基本信息；·Level=8，转储Library Cache对象，包含详细信息（如：child[......]