Shared Cursor

Shared Cursor里存储目标SQL的SQL文本、解析树、该SQL所涉及的对象定义、该SQL所使用的绑定变量和长度，以及该SQL的执行计划等信息。
Shared Cursor又细分为Parent Cursor（父游标）和Child Cursor（子游标）两种类型，可以通过视图vsqlarea查看缓存在库缓存中的Parent Cursor，视图vsql查看Child Cursor。
在Oracle数据库里，任意一个目标SQL一定会同时对应两个Shared Cursor，一个是Parent Cursor，另一个是Child Cursor，Parent Cursor存储该SQL的SQL文本，而SQL真正被重用的解析树和执行计划存储在Child Cursor中。
为了尽量减少对应Hash Bucket中库缓存对象句柄链表的长度，Oracle设计了这种嵌套的Parent Cursor和Child Cursor并存的结构。
Oracle根据目标SQL的SQL文本的哈希值去相应的Hash Bucket中找匹配的Parent Cursor，而哈希运算是对大小写敏感的。
Oracled 解析目标SQL时去库缓存中查找匹配Shared Cursor的过程，分这样几步：
1.根据目标SQL的SQL文本的Hash值去Hash Buckets中找匹配的Hash Bucket
2.去匹配Hash Bucket中查找匹配Parent Cursor
3.在匹配Parent Cursor中查找匹配Child Cursor
4.如果第2步找不到匹配的Parent Cursor，则意味着此时没有可以共享的解析树和执行计划，Oracle从头开始解析上述SQL，新生成一个Parent Cursor和一个Child Cursor，并把它们挂在对应的Hash Bucket中。
5.如果第3步找到了匹配的Child Cursor，则Oracle会把存储于该Child Cursor中的解析树和执行计划直接拿过来重用，而不用再头开始解析。
6.如果第3步找不到匹配的Child Cursor，则意味着没有可以共享的解析树和执行计划，接下来Oracleb也会从头开始解析上述目标SQL，新生成的一个Child Cursor，并把这个Child Cursor挂在对应的Parent Cursor下。
硬解析
硬解析（Hard Parse)是指Oracle在执行目标SQL时，在库缓存中找不到可以重用的解析树和执行计划，而不得不从头开始解析目标SQL并生成相应的Parent Cursor和Child Cursor的过程。
硬解析实际上有两种类型：
一种是在库缓存中找不到匹配的Parent Cursor，此时Oracle会从头开始解析目标SQL，新生成一个Parent Cursor和一个Child Cursor，并把它们挂在对应的Hash Bucket中；
另一种是找到了匹配的Parent Cursor但未找到匹配的Child Cursor，此时Oracle也会从头开始解析该目标SQL，新生成一个Child Cursor，并把这个Child Cursor挂在对应的Parent Cursor下。
硬解析的危害：
1.硬解析可能会导致Shared Pool Latch的争用。Latch作用之一是保护共享内存的分配。常表现为CPU占用率居高不下。
2.硬解析可能会导致库缓存相关Latch(如Library Cache Latch)和Mutex的争用。无论哪种类型的硬解析，都需要扫描相关的Hash Backet中的库缓存对象句柄链表，而扫描库缓存对象句柄链表这个动用是要持有Library Cache Latch的（Latch另一个作用是用于共享SGA内存结构的并发访问控制），所以如果有一定数量的并发硬解析，则也可能会导致Library Cache Latch的争用。和Shared Pool Latch一样，一旦发生大量的Library Cache Latch的争用，系统的性能和可扩展性也会受到严重影响。需要注意是，从11GR1开始，Oracle用Mutex替换了库缓存相关Latch，所以在Oracle11GR1及其后续版本中，将不再存在库缓存相关Latch的争用，取而代之的是Mutex的争用（可以将Mutex理解成是一种轻量级的Latch，Mutex主要用于共享SGA内存结构的并发访问控制），Oracle引入了一系统等待事件来描述这种Mutex的争用，比如"Cursor:pin S",“Cursor:pin X”,“Cursor:pin S wait on X”,“Cursor:Mutex S”,“Cursor:metex X”,"Library cache:mutex X"等。
Oracle在做硬解析时对Shared Pool Latch和Library Cache Latch的持有过程：
Oracle首先持有Library Cache Latch，在库缓存中扫描相关Hash Bucket中的库缓存对象句柄链表，以查看是否有匹配的Parent Cursor，然后释放Library Cache Latch,(这里释放的原因显然是因为没有找到匹配的Parent Cursor)。
接下来是硬解析的后半部分，首先持有Library Cache Latch，然后在不释放Library Cache Latch的情况下持有Shared Pool Latch，以便从Shared Pool中申请分配内存，成功申请后就会释放Shared Pool Latch，最后再释放Library Cache Latch。详细过程请看熊军老师的文章：http://www.laoxiong.net/shared-pool-latch-and-library-cache-latch.html
理想情况下，OLTP类型系统每秒硬解析的数量应该控制在20以下。
软解析
软解析(Soft Parse)是指Oracle在执行目标SQL时，在Library Cache中找到匹配的Parent Cursor和Child Cursor，并将存储在Child Cursor中的解析树和执行计划直接拿过来用而无须从头开始解析的过程。
软解析的优势：
1.软解析不会导致Shared Pool Latch的争用。
2.软解析虽然也可能会导致库缓存相关Latch和Mutex的争用，但软解析持有库缓存相关Latch的次数要少，而且软解析对某些Latch的持有时间会比硬解析短，意味着即使产生了库缓存相关Latch的争用，软解析的争用程度也没有硬解析那么严重，即库缓存相关Latch和Mutex的争用所带来的系统性能和可扩展性的问题对软解析来说要比硬解析少很多。
基本于以上原因，如果OLTP类型的系统在执行目标SQL时能够广泛使用软解析，则系统的性能和可扩展性就会比全部使用硬解析时有显著提升，执行目标SQL时需要消耗的系统资源也会显著降低（主要体现在CPU上）。