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這個參數值很重要，這裡不再細解。
