2.3 Library Cache2.3.1 Library Cache与SQL游标Library Cache主要用于存放SQL游标，而SQL游标最大化共享是Library Cache优化的重要途径，可以使SQL运行开销最低、性能最优。
SQL语句与父游标及子游标在PL/SQL中，游标（Cursor）是数据集遍历的内存集合。而从广义上讲，游标是SQL语句在Library Cache中的内存载体。SQL语句与游标关系如下：1）一条SQL语句包含一个父游标（Parent Cursor）和一至多个子游标（Child Cursor），如图2-2所示。
图2-2 SQL语句与游标2）SQL语句通过SQL_ID唯一标识父游标，如下所示：
从上述示例可以看出，SQL语句使用SQL_ID唯一标识父游标（V$SQLAREA），同时该SQL语句仅包含一个父游标和一个子游标。3）不同的SQL语句的父游标也不同，如下所示：
可以看出，两个不同SQL语句对应的SQL_ID也不相同，产生了不同的父游标。SQL语句父游标不相同，其对应的子游标也肯定不同。关于游标内存结构介绍，可以参考5.1节。2.父游标（1）父游标特点父游标的主要特点如下：父游标是由SQL语句决定的；父游标使用SQL语句的SQL_ID唯一标识；父游标包含一到多个子游标；父游标与参数cursor_sharing紧密相关。（2）父游标组成结构父游标的主要组成结构如表2-2所示。
父游标组成结构单元之间的关系，如图2-3所示。
图2-3 父游标组成结构（3）父游标相关查询父游标信息可以通过V$SQLAREA视图进行查询。V$SQLAREA的主要特点有：V$SQLAREA中一条记录表示一个父游标，如下所示：
可以看出在V$SQLAREA视图中，SQL_ID是唯一的，从侧面也可以证明V$SQL-AREA中一条记录代表一个父游标。V$SQLAREA只包含父游标的相关信息。（4）父游标相关参数参数cursor_sharing决定父游标被共享的模式，用于减少解析带来的开销，提升SQL执行效率。cursor_sharing的3种模式如下：EXACT（默认模式），如下所示：
FORCE；SIMILAR。接下来对这3种模式进行详细介绍。1）cursor_sharing= EXACT：默认模式。只有SQL语句内容完全一样，才会共享父游标（SQL语句之间才会共享）。也就是说，当用户端发起的SQL语句只要有一点不相同，就会产生不同的父游标，从而不会共享SQL父游标。如下所示：
2）cursor_sharing = FORCE：当模式设置为FORCE时，将会强制优化器共享父游标，而不管执行计划是否最优。当条件允许时，可以采用这种方式来减少解析开销。如下所示：
可以看出，在FORCE模式下，两条内容不同的SQL强制共享了父游标（使用系统绑定变量）。FORCE模式建议不要过度使用，虽然这种模式会强制SQL共享父游标，但是这样可能会忽略CBO优化器最优的执行计划，使得SQL执行不是最优化的。3）cursor_sharing = SIMILAR：模式SIMILAR表示优化器在一定条件下会自动选择共享游标：SQL语句几乎完全相同；执行计划相同或者执行计划更优；忽略SQL语句文字内容差异。可以通过以下示例进行验证。示例1：参数变化导致游标共享差异。
可以看出，当模式设置为SIMILAR时，只要SQL语句相似就可以共享游标 。
示例2可以概括为如图2-4所示的关系。
通过图2-4可以看到，一个父游标可以包含多个子游标，从而验证了图2-2的正确性。3.子游标（1）子游标特点子游标的主要特点有：V$SQL中一条记录对应一个子游标；子游标与绑定变量（Bind Variable）、NLS参设置等相关；子游标与参数optimizer_mode紧密相关。（2）子游标组成结构子游标的主要组成结构如表2-3所示。
图2-5 子游标组成结构
有关父子游标的详细信息，可以参考5.1节。（3）子体游标相关查询子游标信息可以通以V$SQL（X$KGLCURSOR_CHILD）视图进行查询。V$SQL的主要特点有：V$SQL中一条记录代表一个子游标。如下所示：
可以看到，一个SQL_ID（父游标）包含了多条记录，每条记录代表一个子游标。V$SQL包含了父游标和子游标信息。（4）子游标相关参数参数optimizer_mode用于设置子游标的CBO优化器模式。可以通过查询V$SQL_SHARED_CURSOR. OPTIMIZER_MISMATCH验证子游标不匹配（missmatch）的原因：是否由参数optimizer_mode导致。如下所示：
可以将上面内容概括为如图2-6所示的关系。
参数optimizer_mode相关设置可参考6.1.1节。2.3.2 Library Cache内存结构
Library Cache内存结构概览Oracle使用内存管理器（KGH）对Library Cache内存进行管理。Library Cache包含了一张由Hash Bucket组成的Hash Table，每个Hash Bucket以链表的方式与Object Handle进行链接，如图2-7所示，ObjectHandle主要负责Library Cache Lock（Pin）控制；同时，Object Handle指向LCO（Library Cache Object），LCO由各种类型的对象组成，如图2-8所示。图2-7 Hash Table与Object Handle
图2-8 Object Handle与LCO
Library Cache内存相关参数参数_kgl_buckets_count决定了（Library Cache）Hash Bucket的数量，可以通过调节该参数来对（Library Cache）Hash Table进行调节。Hash Table的主要特点：Hash Table会自动扩展：当所需的Bucket的数量超过当前Hash Table中可容纳的空间时进行扩展；Hash Table自动扩展的原则为：上一次分配空间的两倍左右；Hash Table扩展将会分配新的Hash Table来替换掉当前的Hash Table，同时将原Hash Table中的Hash Bucket重新“哈希”到新的Hash Table，最后释放原Hash Table内存；参数_kgl_buckets_count与Hash Bucket关系如下所示：
Hash Bucket的数量为2的_kgl_bucket_count次方与256的乘积。我们可以通过以下示例进行验证。1）查看参数_kgl_buckets_count的配置，如下所示：
2）查看Library Cache的内存分配情况，如下所示：
可以看到：LIBRARY CACHE HASH TABLE中的size（131072）为Hash Bucket的数量，count （6394）为LCO Handle的数量；131072＝29×256，与公式完全符合；131072＝124829（Chain_Size：0）＋6092（Chain_Size：1）＋151（Chain_Size：2）。Hash Bucket是由Hash_Chain_Size不同的Hash_Chain组成的，这样的好处是可以提高Library Cache空间使用率，减少内存碎片的产生。
Library Cache DumpLibrary Cache Dump内容如下所示：可以看出，Library Cache是由Hash Buckte、LCO Handle以及LCO 等内存结构组成的。2.3.3 Library Cache Lock（Pin）
Library Cache Lock（Pin）概述（1）Library Cache Lock特点Library Cache包含了SQL解析树、执行计划以及被引用的对象等信息。同时，Library Cache还包含了同义词转换、依赖关系信息以及LCO/LCO Handle等结构。这些信息结构在PL/SQL编译、SQL语句解析执行等场景使用Library Cache Lock进行保护。Library Cache Lock主要特点有：Library Cache Lock被称为易破坏的解析锁（Parse Lock），负责对SQL/PLSQL解析树（LCO Handle）以及依赖对象进行保护；Library Cache Lock在SQL/PLSQL解析到内存时为共享（Share）模式，然后以Null模式存在；如果SQL/PLSQL的相关（引用）对象定义被更改而导致解析树发生变化，Oracle就会破坏Library Cache Lock的锁定，对引用的LCO进行无效化（Invalidate）处理。在下次调用SQL/PSQL时，需要重新解析、缓存，从而降低了数据库的性能；Library Cache Lock只有在解析树引用的LCO对象还没有被Pin入内存时才能被破坏。当这些被解析树引用的LCO对象被Pin住后，Library Cache Lock将升级为Excluseive模式，这时就不能对Library Cache Lock进行破坏操作，保护了Library Cache结构的完整性。（2）Library Cache Pin特点Library Cache Pin发生在Library Cache Lock之后，在SQL/PLSQL执行操作时产生Pin。Library Cache Pin的主要特点如下：Library Cache Pin负责对Heap0对象（LCO）以及依赖对象进行保护；Library Cache Pin是SQL/PLSQL执行调用时产生Pin；LCO被Pin，其引用的数据库对象都将被Pin；Library Cache解析树引用的数据库对象被Pin时，其对应的数据字典锁（Row Cache Enqueue Lock）就会保护这些数据库对象，防止DDL破坏；Library Cache Pin一般是Share模式，当需要修改LCO时，就需要转换成Exclusive独占模式。（3）Library Cache Lock（Pin）用途Library Cache Lock（Pin）的主要用途如下：Library Cache Lock管理并发控制；Library Cache Pin保证内存数据完整性。Library Cache Lock在解析、调用等场景被获取，Library Cache Pin在编译、执行等场景被获取，它们的主要用途是保护解析树以及内存数据对象的完整性。
Library Cache Lock（Pin）持续性Library Cache Lock（Pin）持续性分为以下几种级别：会话级（Session）：Library Cache Lock（Pin）持续到会话结束；事务级（Transaction）：Library Cache Lock（Pin）持续到事务Commit/Rollback时释放；调用级（Call）：Library Cache Lock（Pin）持续到Call结果返回时释放。
Library Cache Lock（Pin）模式（1）Library Cache Lock模式Library Cache Lock有3种模式：共享模式（S）：读取对象；排他模式（X）：修改对象；空模式（Null）：释放状态。持久存储的对象可以处于上述3种锁定模式，临时对象（Cursor）只能处于Null锁定模式。（2）Library Cache Pin模式Library Cache Pin只有2种模式：共享模式（S）：读取LCO对象；排他模式（X）：更改LCO对象。与Library Cache Lock锁定模式不同，持久存储对象和临时对象都可以用S、X模式Pin在内存中。
Library Cache Lock（Pin）争用当Library Cache Lock（Pin）处于排他模式（X）时，若其他Session需要对该Library Cache Lock（Pin）锁定的对象进行修改，就会产生Library Cache Lock（Pin）争用，对数据库库系统性能产生负面影响。Library Cache Lock（Pin）争用的主要原因如下：过量的解析：SQL没有共享；不必要的软解析；没有合理使用绑定变量。共享SQL被释放出Library Cache。没有Pin住频繁使用的SQL/PLSQL对象。参数设置不合理：参数session_cached_cursors的值设置过高。Library Cache可能保留大量无效且不被解析的Cursor，将有用的、共享的SQL“刷”出了Library Cache，导致SQL解析争用频繁。
Library Cache Lock（Pin）优化Library Cache Lock（Pin）争用优化最重要的思路就是增加SQL共享，主要考虑以下几个方面：合理使用绑定变量，增加SQL共享，减少解析；考虑使用DBMS_SHARED_POOL Pin住频繁使用的SQL/PLSQL对象；减少对PLSQL/VIEW/PACKAGE等对象的编译/重编译操作；减少PLSQL/VIEW/PACKAGE等对象的无效化（Invalidate）操作；合理使用参数cursor_sharing/optimizer_mode，增加SQL共享；合理设置参数session_cached_cursors，优化SQL解析（参考5.1节）。
相关资源：Oracle运维最佳实践-下.pdf 带书签