ORACLE 硬解析和軟解析 軟軟解析
分類: Oracle
當客戶端程式,將SQL語句透過監聽器傳送到Oracle時, 會觸發一個Server process生成,來對該客戶程式服務。Server process得到SQL語句之後,對SQL語句進行Hash運算,然後根據Hash值到library cache中查詢,如果存在,則直接將library cache中的快取的執行計劃拿來執行,最後將執行結果返回該客戶端,這種SQL解析叫做軟解析;如果不存在,則會對該SQL進行解析parse,然後執行,返回結果,這種SQL解析叫做硬解析。
1.硬解析的步驟
硬解析一般包括下面幾個過程:
1)對SQL語句進行語法檢查,看是否有語法錯誤。比如select from where 等的拼寫錯誤,如果存在語法錯誤,則推出解析過程;
2)透過資料字典(row cache),檢查SQL語句中涉及的物件和列是否存在。如果不存在,則推出解析過程。
3)檢查SQL語句的使用者是否對涉及到的物件是否有許可權。如果沒有則推出解析;
4)透過最佳化器建立一個最優的執行計劃。這個過程會根據資料字典中的物件的統計資訊,來計算多個執行計劃的cost,從而得到一個最優的執行計劃。這一步涉及到大量的資料運算,從而會消耗大量的CPU資源;(library cache最主要的目的就是透過軟解析來減少這個步驟);
5)將該遊標所產生的執行計劃,SQL文字等裝載進library cache中的heap中。
2.軟解析
所謂軟解析,就是因為相同文字的SQL語句存在於library cache中,所以本次SQL語句的解析就可以去掉硬解析中的一個活多個步驟。從而節省大量的資源的耗費。
3.軟軟解析
所謂的軟軟解析,就是不解析。當設定了session_cached_cursors引數時,當某個session第三次執行相同的SQL語句時,則會把該SQL語句的遊標資訊轉移到該session的PGA中。這樣,當該session在執行該SQL語句時,會直接從PGA中取出執行計劃,從而跳過硬解析的所有步驟。
SQL> show parameter cursor;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cursor_sharing string EXACT
cursor_space_for_time boolean FALSE
open_cursors integer 300
session_cached_cursors integer 20
open_cursors設定每個session(會話)最多能夠同時開啟多少個cursors(遊標)。
================================================
摘自:http://www.itpub.net/thread-796685-1-1.html
SESSION_CACHED_CURSORS的值就是說的是一個session可以快取多少個cursor,讓後續相同的SQL語句不再開啟遊標,從而避免軟解析的過程來提高效能。(繫結變數是解決硬解析的問題),軟解析同硬解析一樣,比較消耗資源.所以這個引數非常重要。
oracle有一個概念,那就是session cursor cache,中文描述就是有一塊記憶體區域,用來儲存關閉了的cursor。當一個cursor關閉之後,oracle會檢查這個cursor的request次數是否超過3次,如果超過了三次,就會放入session cursor cache,這樣在下次parse的時候,就可以從session cursor cache中找到這個statement, session cursor cache的管理也是使用LRU。
session_cached_cursors這個引數是控制session cursor cache的大小的。session_cached_cursors定義了session cursor cache中儲存的cursor的個數。這個值越大,則會消耗的記憶體越多。
另外檢查這個引數是否設定的合理,可以從兩個statistic來檢查。
SQL> select name,value from v$sysstat where name like '%cursor%';
NAME VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative 16439
opened cursors current 55
session cursor cache hits 8944
session cursor cache count 101
cursor authentications 353
SQL> select name,value from v$sysstat where name like '%parse%';
NAME VALUE
---------------------------------------------------------------- ----------
parse time cpu 0
parse time elapsed 0
parse count (total) 17211
parse count (hard) 1128
parse count (failures) 2
parse count(total)就是總的parse次數中,session cursor cache hits就是在session cursor cache中找到的次數,所佔比例越高,效能越好。如果比例比較低,並且有剩餘記憶體的話,可以考慮加大該引數。
Oracle 9i及以前,該引數預設是0,10G上預設是20。
1.硬解析的步驟
硬解析一般包括下面幾個過程:
1)對SQL語句進行語法檢查,看是否有語法錯誤。比如select from where 等的拼寫錯誤,如果存在語法錯誤,則推出解析過程;
2)透過資料字典(row cache),檢查SQL語句中涉及的物件和列是否存在。如果不存在,則推出解析過程。
3)檢查SQL語句的使用者是否對涉及到的物件是否有許可權。如果沒有則推出解析;
4)透過最佳化器建立一個最優的執行計劃。這個過程會根據資料字典中的物件的統計資訊,來計算多個執行計劃的cost,從而得到一個最優的執行計劃。這一步涉及到大量的資料運算,從而會消耗大量的CPU資源;(library cache最主要的目的就是透過軟解析來減少這個步驟);
5)將該遊標所產生的執行計劃,SQL文字等裝載進library cache中的heap中。
2.軟解析
所謂軟解析,就是因為相同文字的SQL語句存在於library cache中,所以本次SQL語句的解析就可以去掉硬解析中的一個活多個步驟。從而節省大量的資源的耗費。
3.軟軟解析
所謂的軟軟解析,就是不解析。當設定了session_cached_cursors引數時,當某個session第三次執行相同的SQL語句時,則會把該SQL語句的遊標資訊轉移到該session的PGA中。這樣,當該session在執行該SQL語句時,會直接從PGA中取出執行計劃,從而跳過硬解析的所有步驟。
SQL> show parameter cursor;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cursor_sharing string EXACT
cursor_space_for_time boolean FALSE
open_cursors integer 300
session_cached_cursors integer 20
open_cursors設定每個session(會話)最多能夠同時開啟多少個cursors(遊標)。
================================================
摘自:http://www.itpub.net/thread-796685-1-1.html
SESSION_CACHED_CURSORS的值就是說的是一個session可以快取多少個cursor,讓後續相同的SQL語句不再開啟遊標,從而避免軟解析的過程來提高效能。(繫結變數是解決硬解析的問題),軟解析同硬解析一樣,比較消耗資源.所以這個引數非常重要。
oracle有一個概念,那就是session cursor cache,中文描述就是有一塊記憶體區域,用來儲存關閉了的cursor。當一個cursor關閉之後,oracle會檢查這個cursor的request次數是否超過3次,如果超過了三次,就會放入session cursor cache,這樣在下次parse的時候,就可以從session cursor cache中找到這個statement, session cursor cache的管理也是使用LRU。
session_cached_cursors這個引數是控制session cursor cache的大小的。session_cached_cursors定義了session cursor cache中儲存的cursor的個數。這個值越大,則會消耗的記憶體越多。
另外檢查這個引數是否設定的合理,可以從兩個statistic來檢查。
SQL> select name,value from v$sysstat where name like '%cursor%';
NAME VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative 16439
opened cursors current 55
session cursor cache hits 8944
session cursor cache count 101
cursor authentications 353
SQL> select name,value from v$sysstat where name like '%parse%';
NAME VALUE
---------------------------------------------------------------- ----------
parse time cpu 0
parse time elapsed 0
parse count (total) 17211
parse count (hard) 1128
parse count (failures) 2
parse count(total)就是總的parse次數中,session cursor cache hits就是在session cursor cache中找到的次數,所佔比例越高,效能越好。如果比例比較低,並且有剩餘記憶體的話,可以考慮加大該引數。
Oracle 9i及以前,該引數預設是0,10G上預設是20。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/500314/viewspace-1192382/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 徹底弄懂oracle硬解析、軟解析、軟軟解析Oracle
- Oracle的硬解析和軟解析Oracle
- ORACLE SQL解析之硬解析和軟解析OracleSQL
- 軟解析和硬解析
- Oracle SQL的硬解析和軟解析OracleSQL
- Oracle 硬解析與軟解析Oracle
- Oracle中的遊標、硬解析、軟解析、軟軟解析、解析失敗Oracle
- Oracle的軟解析(soft prase)和硬解析(hard prase)Oracle
- SQL大致流程、SPM、軟軟、軟、硬解析SQL
- ORACLE的軟 軟 軟 解析!Oracle
- 草稿 - 遊標,硬解析,軟解析 等
- soft parse(軟解析),hard parse(硬解析)
- 在oracle 10.2.0.5分析硬解析及軟解析及軟軟解析獲取shared pool latch機制系列五Oracle
- oracle實驗記錄 (分析oracle硬解析&軟解析&fast soft parse)OracleAST
- 軟解析、硬解析的一個小測試
- 共享池之八:軟解析、硬解析、軟軟解析 詳解一條SQL在library cache中解析涉及的鎖SQL
- 硬解析和物理讀取與軟解析和邏輯讀取
- oracle實驗記錄 (分析oracle硬解析&軟解析&fast soft parse(2))OracleAST
- Oracle - 共享遊標、父子游標、硬軟解析Oracle
- 硬解析物理讀VS軟解析邏輯讀 測試
- 【體系結構】sql語句解析過程小實驗 軟解析、硬解析SQL
- 父遊標 子游標和軟硬解析記載-02
- 關於軟解析(soft parse)與硬解析(hard parse),以及session cached cursors (asktom)Session
- 遊標引數shared_cached_cursors和軟軟解析
- 深入解析Laravel的中介軟體Laravel
- 【軟考之線性表解析】
- 解析軟體專案管理(轉)專案管理
- 專案管理軟體功能全解析專案管理
- 解析訊息中介軟體之RabbitMQMQ
- 軟體測試面試過程解析面試
- 等待模擬-library cache 軟解析
- Koa 系列 —— Koa 中介軟體機制解析
- 中介軟體的引數解析過程
- Android 軟鍵盤響應事件解析Android事件
- Linux 核心的軟中斷深入解析Linux
- 【專題】深入解析軟體測試外包
- [軟考考點解析]軟體設計師--常用媒體檔案格式
- windows10怎麼設定軟體解析度_windows10調整軟體解析度的方法Windows