oracle涉及一張表的查詢(xún)語(yǔ)句，如果是第一次執(zhí)行，也就是硬解析，需要執(zhí)行的步驟涉及的對(duì)象如下：

　　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 --不是始終在內(nèi)存中

　　dependency$ 1 Interobject dependencies --不是始終在內(nèi)存中

　　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

　　可以看到硬解析的過(guò)程執(zhí)行了59次查詢(xún)，硬解析的資源消耗是相當(dāng)嚴(yán)重的，實(shí)際生產(chǎn)環(huán)境應(yīng)該盡量避免硬解析，而且查詢(xún)中涉及的好多數(shù)據(jù)字典信息并沒(méi)有全部在內(nèi)存中，比如上面進(jìn)行注釋的部分，實(shí)際查詢(xún)發(fā)現(xiàn)好多對(duì)象的信息并沒(méi)有放到dictionary cache中，這些信息可能也會(huì)根據(jù)sh

　　下面是同一條語(yǔ)句，在不同的環(huán)境下，執(zhí)行的效果，大家也可以看出軟硬解析的差別

　　一條語(yǔ)句在第一次執(zhí)行時(shí)，是硬解析

　　select * from ttest where object_id=1000;為例

　　通過(guò)set autotrace traceonly statistics發(fā)現(xiàn)

　　230 consistent gets

　　226 physical reads

　　--說(shuō)明，物理讀的同時(shí)，還是會(huì)有內(nèi)存的一致讀，因?yàn)?u>硬盤(pán)上的數(shù)據(jù)是不能直接校驗(yàn)和操作的，都必須搬到內(nèi)存中進(jìn)行

　　只將alter system flush shared_pool;

　　298 consistent gets

　　6 physical reads

　　--硬解析，一些數(shù)據(jù)字典信息還是需要physical read，表的信息并不完全在dictionary cache中，而這個(gè)查詢(xún)涉及的data又全部緩存在buffer cache中，避免了最大部分的物理讀，但記住IO操作是耗cpu和IO的，而硬解析的過(guò)程是占用cpu和latch內(nèi)存的，基本上會(huì)實(shí)時(shí)占用一顆cpu，當(dāng)大量出現(xiàn)的時(shí)候，會(huì)占用多顆cpu，這時(shí)可能整個(gè)系統(tǒng)就不能干活了。

　　全部緩存后

　　230 consistent gets

　　0 physical reads

　　--軟解析，完全沒(méi)有物理讀

　　其實(shí)還有一個(gè)軟軟解析，session_cached_cursors這個(gè)參數(shù)值很重要，這里不再細(xì)解。