oracle硬解析执行步骤详解

oracle涉及一张表的查询语句，如果是第一次执行，也就是硬解析，需要执行的步骤涉及的对象如下： Tables #Queries Purpose access$ 1 Permissions used by a dependent object against its parent ccol$ 10 Constraint column-specific data cdef$ 3 Constra

 　　oracle涉及一张表的查询语句，如果是第一次执行，也就是硬解析，需要执行的步骤涉及的对象如下：

　　Tables #Queries Purpose

　　access$ 1 Permissions used by a dependent object against its parent

　　ccol$ 10 Constraint column-specific data

　　cdef$ 3 Constraint-specific definition data

　　col$ 1 Table column-specific data --不是始终在内存中

　　dependency$ 1 Interobject dependencies --不是始终在内存中

　　hist_head$ 12 Histogram header data

　　histgrm$ 3 Histogram specifications

　　icol$ 6 Index columns

　　ind$, ind_stats$ 1 Indexes, index statistics

　　obj$ 8 Objects--dictionary cache

　　objauth$ 2 Table authorizations

　　seg$ 7 Mapping of all database segments

　　syn$ 1 Synonyms

　　tab$, tab_stats$ 1 Tables, table statistics

　　user$ 2 User definitions

　　可以看到硬解析的过程执行了59次查询，硬解析的资源消耗是相当严重的，实际生产环境应该尽量避免硬解析，而且查询中涉及的好多数据字典信息并没有全部在内存中，比如上面进行注释的部分，实际查询发现好多对象的信息并没有放到dictionary cache中，这些信息可能也会根据shared pool的LRU原则进行替换。

　　下面是同一条语句，在不同的环境下，执行的效果，大家也可以看出软硬解析的差别

　　一条语句在第一次执行时，是硬解析

　　select * from ttest where object_id=1000;为例

　　通过set autotrace traceonly statistics发现

　　230 consistent gets

　　226 physical reads

　　--说明，物理读的同时，，还是会有内存的一致读，因为硬盘上的数据是不能直接校验和操作的，都必须搬到内存中进行

　　只将alter system flush shared_pool;

　　298 consistent gets

　　6 physical reads

　　--硬解析，一些数据字典信息还是需要physical read，表的信息并不完全在dictionary cache中，而这个查询涉及的data又全部缓存在buffer cache中，避免了最大部分的物理读，但记住IO操作是耗cpu和IO的，而硬解析的过程是占用cpu和latch内存的，基本上会实时占用一颗cpu，当大量出现的时候，会占用多颗cpu，这时可能整个系统就不能干活了。

　　全部缓存后

　　230 consistent gets

　　0 physical reads

　　--软解析，完全没有物理读

　　其实还有一个软软解析，session_cached_cursors这个参数值很重要，这里不再细解。