Oracle sql解析类型, 软解析和硬解析浅析
生活随笔
收集整理的這篇文章主要介紹了
Oracle sql解析类型, 软解析和硬解析浅析
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
這篇文章是參考加甲骨論老相老師視頻所做的學(xué)習(xí)筆記:
http://www.jiagulun.com/thread-2675-1-1.html
Sql 執(zhí)行的流程分成3部分:
解析部分(Parse): Server process將sql語句在Shared pool(共享池)里解析為執(zhí)行計劃
執(zhí)行部分(Execute): Server process根據(jù)執(zhí)行計劃在DB buffer cache和數(shù)據(jù)文件里提取數(shù)據(jù).
獲取數(shù)據(jù)部分(Fetch): 獲得數(shù)據(jù)并返回給用戶.
所以可以看出解析部分是在SGA里面 Share pool里完成的.
可以從V$sgainfo 視圖查看shared pool 的當(dāng)前大小信息
Share pool里面分成許多個部分, 我們可以大概看成3個主要部分:(實際上還有Result cache等部分)
分別是Free 空間, Library Cache(庫緩存) 和 RowCache(字典緩存)
如圖:
Shared pool
而整個Shared pool的作用是用來緩存用戶的sql 語句和 和對應(yīng)執(zhí)行計劃的.
當(dāng)一條sql語句, 從user client傳到Server Process(PGA)里時, Server Process會拿著sql去Share pool里面.
Server process首先會判斷sql語句的語法是否正確, sql語句涉及的對象是否有權(quán)限.
如果上面兩步?jīng)]問題了,那么會到Share pool 里的 Library Cache尋找有無相同的sql語句和對應(yīng)的緩存計劃.
所以Server Process在share pool里頭3個動作是:
1. 判斷語法合法性
2. 判斷涉及對象權(quán)限
3. 到Library Cache里尋找緩存的sql和對應(yīng)執(zhí)行計劃.
好了由第3步得知Share pool緩存的sql語句和執(zhí)行計劃實在是緩存在share pool里的Libaray Cache里面的.
下面簡單介紹下Library cache和 Rowcache
Library cache : 在share pool里用來緩存用戶執(zhí)行過的sql語句和對應(yīng)執(zhí)行計劃.
????????????????????????
在Oracle 10g 里可以用select * from v$sgastat where pool = 'shared pool' and name ='library cache'來查看當(dāng)前l(fā)ibrary cache的大小:
(11g不適用...)
住: 數(shù)據(jù)庫負(fù)載越重free memory越小.
Rowcache : 數(shù)據(jù)字典緩存, 作用就是存放數(shù)據(jù)字典的數(shù)據(jù)啦.
??????????????????? 為什么要存放數(shù)據(jù)字典呢, 因為上面的第2步:判斷涉及對象權(quán)限? 和 硬解析中要訪問大量的表/索引..對象 而這些信息都是存放在數(shù)據(jù)字典中的.
好了現(xiàn)在說明下什么是軟解析:
當(dāng)Server process在Library cache里找到現(xiàn)成的執(zhí)行計劃時,就直接可以利用這個執(zhí)行計劃去執(zhí)行sql語句了. 我們就叫個得到執(zhí)行計劃的過程叫軟解析所以軟解析只包含上述3步動作.
硬解析:
當(dāng)sql語句是第一次運行或者其他原因, Library cache里面沒有對應(yīng)的執(zhí)行計劃,只能由Server process自己去解析成執(zhí)行計劃, 就是硬解析了.
硬解析也是在library cache里完成的.
因為1個sql語句有多種執(zhí)行方案. 解析過程中必須訪問大量的數(shù)據(jù)庫對象信息才能得到1個最佳的執(zhí)行方案成為執(zhí)行計劃,所以O(shè)racle才會吧數(shù)據(jù)字典緩存Rowcache 放到shared pool 與librarycache配合.
所以硬解析包含4步: 上述3步再加上解析成執(zhí)行計劃的這一步, 而第4步是相當(dāng)耗費資源的,? 所以通常我們會遇到第一次執(zhí)行查詢數(shù)據(jù)很慢, 然后第2 第3次就很快了, 這里就有軟解析的功勞(當(dāng)然也有 DB buffer cache的作用).
所以我們希望shared pool 里的軟解析越多越好.
可以查看v$sgastat查看硬解析和軟解析次數(shù)
如上圖
?Parse time cpu:?? 數(shù)據(jù)庫啟動以來解析花費的cpu時間
?parse time elapsed: 解析總時間
?parse count(total) : 解析總次數(shù)
?parse count(hard): 硬解析次數(shù)
?parse count(failures) : 解析失敗的次數(shù)
?parse count(describe) : Total number of parse calls on a describe cursor, 這種解析耗費資源介于硬解析與軟解析之間 11g獨有
用total次數(shù)減去上面3中解析的次數(shù)就是軟解析次數(shù)了.
http://www.jiagulun.com/thread-2675-1-1.html
Sql 執(zhí)行的流程分成3部分:
解析部分(Parse): Server process將sql語句在Shared pool(共享池)里解析為執(zhí)行計劃
執(zhí)行部分(Execute): Server process根據(jù)執(zhí)行計劃在DB buffer cache和數(shù)據(jù)文件里提取數(shù)據(jù).
獲取數(shù)據(jù)部分(Fetch): 獲得數(shù)據(jù)并返回給用戶.
所以可以看出解析部分是在SGA里面 Share pool里完成的.
可以從V$sgainfo 視圖查看shared pool 的當(dāng)前大小信息
Share pool里面分成許多個部分, 我們可以大概看成3個主要部分:(實際上還有Result cache等部分)
分別是Free 空間, Library Cache(庫緩存) 和 RowCache(字典緩存)
如圖:
Shared pool
而整個Shared pool的作用是用來緩存用戶的sql 語句和 和對應(yīng)執(zhí)行計劃的.
當(dāng)一條sql語句, 從user client傳到Server Process(PGA)里時, Server Process會拿著sql去Share pool里面.
Server process首先會判斷sql語句的語法是否正確, sql語句涉及的對象是否有權(quán)限.
如果上面兩步?jīng)]問題了,那么會到Share pool 里的 Library Cache尋找有無相同的sql語句和對應(yīng)的緩存計劃.
所以Server Process在share pool里頭3個動作是:
1. 判斷語法合法性
2. 判斷涉及對象權(quán)限
3. 到Library Cache里尋找緩存的sql和對應(yīng)執(zhí)行計劃.
好了由第3步得知Share pool緩存的sql語句和執(zhí)行計劃實在是緩存在share pool里的Libaray Cache里面的.
下面簡單介紹下Library cache和 Rowcache
Library cache : 在share pool里用來緩存用戶執(zhí)行過的sql語句和對應(yīng)執(zhí)行計劃.
????????????????????????
在Oracle 10g 里可以用select * from v$sgastat where pool = 'shared pool' and name ='library cache'來查看當(dāng)前l(fā)ibrary cache的大小:
(11g不適用...)
住: 數(shù)據(jù)庫負(fù)載越重free memory越小.
Rowcache : 數(shù)據(jù)字典緩存, 作用就是存放數(shù)據(jù)字典的數(shù)據(jù)啦.
??????????????????? 為什么要存放數(shù)據(jù)字典呢, 因為上面的第2步:判斷涉及對象權(quán)限? 和 硬解析中要訪問大量的表/索引..對象 而這些信息都是存放在數(shù)據(jù)字典中的.
好了現(xiàn)在說明下什么是軟解析:
當(dāng)Server process在Library cache里找到現(xiàn)成的執(zhí)行計劃時,就直接可以利用這個執(zhí)行計劃去執(zhí)行sql語句了. 我們就叫個得到執(zhí)行計劃的過程叫軟解析所以軟解析只包含上述3步動作.
硬解析:
當(dāng)sql語句是第一次運行或者其他原因, Library cache里面沒有對應(yīng)的執(zhí)行計劃,只能由Server process自己去解析成執(zhí)行計劃, 就是硬解析了.
硬解析也是在library cache里完成的.
因為1個sql語句有多種執(zhí)行方案. 解析過程中必須訪問大量的數(shù)據(jù)庫對象信息才能得到1個最佳的執(zhí)行方案成為執(zhí)行計劃,所以O(shè)racle才會吧數(shù)據(jù)字典緩存Rowcache 放到shared pool 與librarycache配合.
所以硬解析包含4步: 上述3步再加上解析成執(zhí)行計劃的這一步, 而第4步是相當(dāng)耗費資源的,? 所以通常我們會遇到第一次執(zhí)行查詢數(shù)據(jù)很慢, 然后第2 第3次就很快了, 這里就有軟解析的功勞(當(dāng)然也有 DB buffer cache的作用).
所以我們希望shared pool 里的軟解析越多越好.
可以查看v$sgastat查看硬解析和軟解析次數(shù)
如上圖
?Parse time cpu:?? 數(shù)據(jù)庫啟動以來解析花費的cpu時間
?parse time elapsed: 解析總時間
?parse count(total) : 解析總次數(shù)
?parse count(hard): 硬解析次數(shù)
?parse count(failures) : 解析失敗的次數(shù)
?parse count(describe) : Total number of parse calls on a describe cursor, 這種解析耗費資源介于硬解析與軟解析之間 11g獨有
用total次數(shù)減去上面3中解析的次數(shù)就是軟解析次數(shù)了.
總結(jié)
以上是生活随笔為你收集整理的Oracle sql解析类型, 软解析和硬解析浅析的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 什么是缓存里的脏数据.
- 下一篇: Oracle 事务概述