在Oracle中，SQL的解析过程的硬解析、软解析和软软解析的区别有哪些？

在Oracle中，每条SQL语句在正式执行之前都需要经过解析（Parse），根据解析的过程可以分为3种类型：硬解析（Hard Parse）、软解析（Soft Parse）和软软解析（Soft Soft Parse），软软解析也叫快速解析（Fast Parse）。DDL语句是从来不会共享使用的，也就是说DDL语句每次执行都需要进行硬解析。但是，DML语句和SELECT语句会根据情况选择是进行硬解析，还是进行软解析或者进行软软解析。SQL的解析过程大致可以参考下图：

Oracle在解析和执行目标SQL时，会先去当前会话的PGA中查找是否存在匹配的缓存会话游标（Session Cursor）。当Oracle第一次解析和执行目标SQL时（显然是硬解析），当前会话的PGA中肯定不存在匹配的会话游标，这时Oracle会新生成一个会话游标和一对共享游标（包含一个父游标和一个子游标），这其中的共享游标会存储能被所有会话共享、重用的内容（比如目标SQL的解析树、执行计划等），而会话游标则会经历一次Open、Parse、Bind、Execute、Fetch和Close中的一个或多个阶段。

对会话游标（Session Cursor）和共享游标（Shared Cursor）之间的关联关系如下总结：

l 无论是硬解析、软解析还是软软解析，Oracle在解析和执行目标SQL时，始终会先去当前会话（Session）的PGA中寻找是否存在匹配的缓存会话游标。

l 如果在当前会话的PGA中找不到匹配的缓存会话游标，那么Oracle就会去SGA的库缓存（Library Cache）中查找是否存在匹配的父游标。如果在库缓存中找不到匹配的父游标，那么Oracle就会新生成一个会话游标和一对共享游标（即父游标和子游标）；如果找到了匹配的父游标，但找不到匹配的子游标，那么Oracle就会新生成一个会话游标和一个子游标（这个子游标会被挂在之前找到的匹配父游标下）。无论哪一种情况，这两个过程对应的都是硬解析。

l 如果在当前会话的PGA中找不到匹配的缓存会话游标，但在库缓存中找到了匹配的父游标和子游标，那么Oracle会新生成一个会话游标并重用刚刚找到的匹配父游标和子游标，这个过程对应的就是软解析。

l 如果在当前会话的PGA中找到了匹配的缓存会话游标，那么此时Oracle就不再需要新生成一个会话游标，并且也不再需要像软解析那样得去SGA的库缓存中查找匹配的父游标了，因为Oracle此时可以重用找到的匹配会话游标，并且可以通过这个会话游标直接访问到该SQL对应的父游标，这个过程就是软软解析。

硬解析（Hard Parse）、软解析（Soft Parse）和软软解析（Soft Soft Parse）的比对参考下表：

下面详解介绍硬解析（Hard Parse）、软解析（Soft Parse）和软软解析（Soft Soft Parse）：

（一）硬解析（Hard Parse）

硬解析（Hard Parse）是指Oracle在执行目标SQL时，在库缓存（Library Cache）中找不到可以重用的解析树和执行计划，而不得不从头开始解析目标SQL并生成相应的父游标（Parent Cursor）和子游标（Child Cursor）的过程。

硬解析实际上有两种类型：一种是在库缓存中找不到匹配的父游标（Parent Cursor），此时Oracle会从头开始解析目标SQL，新生成一个父游标和一个子游标，并把它们挂在对应的HashBucket中；另外一种是找到了匹配的父游标但未找到匹配的子游标，此时Oracle也会从头开始解析该目标SQL，新生成一个子游标，并把这个子游标挂在对应的父游标下。

硬解析大致可以分为5个执行步骤：

（1）语法分析。

（2）权限与对象检查。

（3）在共享池中检查是否有完全相同的之前完全解析好的。如果存在，则直接跳过步骤（4）和步骤（5），运行SQL，此时算SOFT PARSE。

（4）选择执行计划。

（5）产生执行计划。

需要注意的是，创建解析树、生成执行计划对于SQL的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。这就是在很多项目中，倡导开发设计人员对功能相同的代码要努力保持代码的一致性，以及要在程序中多使用绑定变量的原因。

在硬解析时，需要申请闩的使用，而闩的数量在有限的情况下需要等待。大量的闩的使用由此造成需要使用闩的进程排队越频繁，性能则逾低下。具体来说，硬解析的危害性体现在以下几点上：

①　硬解析可能会导致Shared Pool Latch的争用。无论是哪种类型的硬解析，都至少需要新生成一个Child Cursor，并把目标SQL的解析树和执行计划载入该Child Cursor里，然后把这个Child Cursor存储在库缓存中。这意味着Oracle必须在Shared Pool中分配出一块内存区域用于存储上述Child Cursor，而在Shared Pool中分配内存这个动作是要持有Shared Pool Latch的（Oracle数据库中Latch的作用之一就是保护共享内存的分配），所以如果有一定数量的并发硬解析，可能就会导致Shared Pool Latch的争用，而一旦发生大量的Shared Pool Latch争用，系统的性能和可扩展性是会受到严重影响的（常常表现为CPU的占用率居高不下，接近100％）。

②　硬解析可能会导致库缓存相关Latch（如Library Cache Latch）和Mutex的争用。无论是哪种类型的硬解析，都需要扫描相关Hash Bucket中的库缓存对象句柄链表，而扫描库缓存对象句柄链表这个动作是要持有Library Cache Latch的（Oracle数据库中Latch的另外一个作用就是用于共享SGA内存结构的并发访问控制），所以如果有一定数量的并发硬解析，则也可能会导致Library Cache Latch的争用。和Shared Pool Latch一样，一旦发生大量的Library Cache Latch的争用，系统的性能和可扩展性也会受到严重影响。这里需要注意的是，从11gR1开始，Oracle用Mutex替换了库缓存相关Latch，所以在Oracle 11gR1及其后续的版本中，将不再存在库缓存相关Latch的争用，取而代之的是Mutex的争用（你可以简单地将Mutex理解成是一种轻量级的Latch，Mutex主要也是用于共享SGA内存结构的并发访问控制），Oracle也因此引入了一系列新的等待事件来描述这种Mutex的争用，比如“Cursor:pinS”、“Cursor:pinX”、“Cursor:pin S wait on X”、"Cursor:mutex S'、“Cursor:mutex X”、“Library cache：mutex X”等。

正是因为大量的硬解析可能会导致Shared Pool Latch、库缓存相关Latch/Mutex的争用，进而会严重影响系统的性能和可扩展性，所以才有“硬解析是万恶之源”这样的说法，但实际上，这种说法是不准确的。硬解析是非常不好，它的危害性也有目共睹，但硬解析是否会对系统造成损坏实际上取决于系统的类型，对于高并发的OLTP类型的系统而言，硬解析确实会严重影响系统的性能和可扩展性；但对于OLAP/DSS类型的系统而言，并发的数量很少，目标SQL也很少被并发重复执行，而且在执行目标SQL时硬解析所耗费的时间和资源与该SQL总的执行时间和资源消耗相比是微不足道的，这种情况下用硬解析是没问题的，此时硬解析对系统性能的影响微乎其微，可以忽略不计。所以更为准确的说法应该是一一对于OLTP类型的系统而言，硬解析是万恶之源！

（二）软解析（Soft Parse）

软解析（Soft Parse)是指Oracle在执行目标SQL时，在Library Cache中找到了匹配的父游标（Parent Cursor）和子游标（Child Cursor），并将存储在子游标中的解析树和执行计划直接拿过来重用而无须从头开始解析的过程。和硬解析相比，软解析的优势主要体现在如下这几个方面：

（1）软解析不会导致Shared Pool Latch的争用。因为软解析能够在库缓存中找到匹配的Parent Cursor和Child Cursor，所以它不需要生成新的Parent Cursor和Child Cursor.这意味着软解析根本就不需要持有Shared Pool Latch以便在Shared Pool中申请分配一块共享内存区域，既然不需要持有Shared Pool Latch，自然不会有Shared Pool Latch的争用，即Shared Pool Latch的争用所带来的系统性能和可扩展性的问题对软解析来说并不存在。

（2）软解析虽然也可能会导致库缓存相关Latch（如Library Cache Latch）和Mutex的争用，但软解析持有库缓存相关Latch的次数要少，而且软解析对某些Latch（如Library Cache Latch）的持有时间会比硬解析短，这意味着即使产生了库缓存相关Latch的争用，软解析的争用程度也没有硬解析那么严重，即库缓存相关Latch和Mutex的争用所带来的系统性能和可扩展性的问题对软解析来说要比硬解析少很多。我们在3.1.12节中己经介绍过：硬解析会先持有LibraryCacheLatch，并且在不释放LibraryCacheLatch的情况下持有Shared Pool Latch以便从Shared Pool中申请分配内存，成功申请后就会释放Shared Pool Latch，最后再释放Library Cache Latch。而软解析是不需要持有Shared Pool Latch的，所以与软解析比起来，硬解析持有Library Cache Latch的时间会更长，当然对Library Cache Latch争用的程度就会更严重。

正是基于上述两个方面的原因，如果OLTP类型的系统在执行目标SQL时能够广泛使用软解析，那么系统的性能和可扩展性就会比全部使用硬解析时有显著的提升，执行目标SQL时需要消耗的系统资源（主要体现在CPU上）也会显著降低。

（三）软软解析（Soft Soft Parse）

软软解析（Soft Soft Parse）是指若参数SESSION_CACHED_CURSORS的值大于0，并且该会话游标所对应的目标SQL解析和执行的次数超过3次，则此时该会话游标会被直接缓存在当前会话的PGA中的。若该SQL再次执行的时候，则只需要对其进行语法分析、权限对象分析之后就可以直接从当前会话的PGA中将之前缓存的匹配会话游标直接拿过来用就可以了，这就是软软解析。

当一个SQL语句以硬解析的方式解析和执行完毕后，这个目标SQL所对应的共享游标（Shared Cursor）就己经被缓存在库缓存中，它所对应的会话游标（Session Cursor）也已使用完毕，这时候会根据参数SESSION_CACHED_CURSORS的不同而存在如下这两种情况：

①　如果参数SESSION_CACHED_CURSORS的值等于0，那么会话游标就会正常执行Close操作。在这种情况下，当同一条目标SQL再次重复执行时（显然是软解析），此时是可以找到匹配的共享游标的，但依然找不到匹配的会话游标（因为之前硬解析时对应的会话游标己经被Close掉了），这意味着Oracle还必须为该SQL新生成一个会话游标，并且该会话游标还会再经历一次Open、Parse、Bind、Execute、Fetch和Close中的一个或多个阶段。

②　如果参数SESSION_CACHED_CURSORS的值大于0，并且该会话游标所对应的目标SQL解析和执行的次数超过3次，那么Oracle就不会对会话游标执行Close操作，而是会将其标记为Soft Closed，同时将其缓存在当前会话的PGA中。这样做的好处是，当目标SQL再次被重复执行时，此时共享游标和会话游标就都能够找到匹配记录了，这意味着Oracle己经不需要为该SQL再新生成一个会话游标，而是只需要从当前会话的PGA中将之前己经被标记为Soft Closed的匹配会话游标直接拿过来用就可以了。显然，和软解析比，此时Oracle就省掉了Open一个新的会话游标所需要耗费的资源和时间。另外，Close一个现有会话游标也不需要做了（只需要将其标记为Soft Closed，同时将其缓存在当前会话的PGA中就可以了）。当然，剩下的Parse、Bind、Execute、Fetch还是需要做的，这个过程就是所谓的“软软解析”。

从上述分析过程可以看出，软软解析与软解析比起来，其好处主要体现在如下两个方面：

①　和软解析比，软软解省去了OPEN一个新的会话游标和CLOSE一个现有会话游标所需要耗费的资源和时间。

②　和软解析比，软软解析在持有库缓存相关Latch的次数方面会更少。这是因为缓存在PGA中的会话游标所在的Hash Bucket中己经存储了目标SQL的父游标的库缓存对象句柄地址，Oracle根据这个库缓存对象句柄地址就可以直接去库缓存中访问对应的父游标了，而不再需要先持有库缓存相关Latch，再去库缓存的相应Hash Bucket的父游标所在的库缓存对象句柄链表中查找匹配的父游标了，所以软软解析在持有库缓存相关Latch的次数方面会比软解析要少。

& 说明：

有关SQL解析的更多内容可以参考我的BLOG：http://blog.itpub.net/26736162/viewspace-2140502/

本文选自《Oracle程序员面试笔试宝典》，作者：李华荣。

---------------优质麦课------------