Oracle中SQL語句執行效率的查找與解決

1、識別佔用資源較多的語句的方法(4種方法)

　　1.測試組和最終用戶反饋的與反應緩慢有關的問題。

　　2.利用V_$SQLAREA視圖提供了執行的細節。(執行、讀取磁盤和讀取緩衝區的次數)

　　• 數據列

　　EXECUTIONS：執行次數

　　DISK_READS：讀盤次數

　　COMMAND_TYPE：命令類型(3:select,2:insert;6:update;7delete;47:pl/sql程序單元)

　　OPTIMIZER_MODE：優化方式

　　SQL_TEXT：Sql語句

　　SHARABLE_MEM：佔用shared pool的內存多少

　　BUFFER_GETS：讀取緩衝區的次數

　　• 用途

　　1、幫忙找出性能較差的SQL語句

　　2、幫忙找出最高頻率的SQL

　　3、幫忙分析是否須要索引或改善聯接

　　監控當前Oracle:family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">的session，如出現時鐘的標誌，表示此進程中的sql運行時間較長。

　　4. Trace工具：

　　a)查看數據庫服務的初始參數：timed_statistics、user_dump_dest和max_dump_file_size

　　b)Step 1: alter session set sql_trace=true

　　c)Step 2: run sql;

　　d)Step 3: alter session set sql_trace=false

　　e)Step 4:使用 「TKPROF」轉換跟蹤文件

　　f)Parse，解析數量大一般代表須要增長數據庫服務器的共享池大小，

　　query或current提取數量大代表若是沒有索引，語句可能會運行得更有效，

　　disk提取數量代表索引有可能改進性能，

　　library cache中多於一次的錯過代表須要一個更大的共享池大小

　2、如何管理語句處理和選項

　　•基於成本(Cost Based) 和基於規則(Rule Based) 兩種優化器， 簡稱爲CBO 和RBO

　　•Optimizer Mode參數值:

　　Choose：若是存在訪問過的任何表的統計數據 ，則使用基於成本的Optimizer,目標是得到最優的經過量。若是一些表沒有統計數據，則使用估計值。若是沒有可用的統計數據，則將使用基於規則的Optimizer。

　　All_rows：老是使用基於成本的Optimizer，目標是得到最優的經過量。

　　First_rows_n：老是使用基於成本的Optimizer，目標是對返回前N行(「n」能夠是1，10，100或者1000)得到最優的響應時間。

　　First_rows：用於向後兼容。使用成本與試探性方法的結合，以便快速傳遞前幾行。

　　RULE：老是使用基於規則的Optimizer

　　3、使用數據庫特性來得到有助於查看性能的處理統計信息(解釋計劃和AUTOTRACE)

　　No1: Explain Plan

　　A)使用Explain工具須要建立Explain_plan表，這必須先進入相關應用表、視圖和索引的全部者的賬戶內. (@D:\oracle\ora92\rdbms\admin\utlxplan)

　　B) 表結構：

　　STATEMENT_ID：爲一條指定的SQL語句肯定特定的執行計劃名稱。若是在EXPLAN PLAN語句中沒有使用SET STATEMENT_ID，那麼此值會被設爲NULL。

　　OPERATION：在計劃的某一步驟執行的操做名稱，例如：Filters，Index，Table，Marge Joins and Table等。

　　OPTION：對OPERATION操做的補充，例如：對一個表的操做，OPERATION多是TABLE ACCESS，但OPTION可能爲by ROWID或FULL。

　　Object_Owner：擁有此database Object的Schema名或Oracle賬戶名。

　　Object_name：Database Object名

　　Object_type：類型，例如：表、視圖、索引等等

　　ID：指明某一步驟在執行計劃中的位置。

　　PARENT_ID：指明從某一操做中取得信息的前一個操做。經過對與ID和PARENT_ID使用Connect By操做，咱們能夠查詢整個執行計劃樹。

C)EXPLAIN搜索路徑解釋

　　•全表掃描(Full Table Scans)(無可用索引,大量數據,小表 ,全表掃描hints,HWM(High Water Mark), Rowid掃描)

　　•索引掃描

　　索引惟一掃描(Index Unique Scans)

　　索引範圍掃描(Index Range Scans)

　　索引降序範圍掃描(Index Range Scans Descending)

　　索引跳躍掃描(Index Skip Scans)

　　全索引掃描(Full Scans)

　　快速全索引掃描(Fast Full Index Scans)

　　索引鏈接(Index Joins)

　　位圖鏈接(Bitmap Joins)

　　•如何選擇訪問路徑： CBO首先檢查WHERE子句中的條件以及FROM子句，肯定有哪些訪問路徑是可用的。而後CBO使用這個訪問路徑產生一組可能的執行計劃，再經過索引、表的統計信息評估每一個計劃的成本，最後優化器選擇成本最低的一個。

　　•表的鏈接方式：

　　Nested Loops會循環外表(驅動表)，逐個比對和內表的鏈接是否符合條件。在驅動表比較小，內表比較大，並且內外表的鏈接列有索引的時候比較好。當SORT_AREA空間不足的時候，Oracle也會選擇使用NL。基於Cost的Oracle優化器(CBO)會自動選擇較小的表作外表。(優勢：嵌套循環鏈接比其餘鏈接方法有優點,它能夠快速地從結果集中提取第一批記錄,而不用等待整個結果集徹底肯定下來。缺點：若是內部行源表(讀取的第二張表(內表)已鏈接的列上不包含索引,或者索引不是高度可選時, 嵌套循環鏈接效率是很低的。若是驅動行源表(從驅動表中提取的記錄)很是龐大時,其餘的鏈接方法可能更加有效。)

　　SORT- merge JOIN，將兩表的鏈接列各自排序而後合併，只能用於鏈接列相等的狀況，適合兩表大小相若的狀況(在缺少數據的選擇性或者可用的索引時,或者兩個源表都過於龐大(超過記錄數的5%)時,排序合併鏈接將比嵌套循環連更加高效。可是,排列合併鏈接只能用於等價鏈接(WHERE D.deptno=E.dejptno,而不是WHERE D.deptno>=E.deptno)。排列合併鏈接須要臨時的內存塊,以用於排序(若是SORT_AREA_SIZE設置得過小的話)。這將致使在臨時表空間佔用更多的內存和磁盤I/O。)

HASH JOIN在其中一表的鏈接列上做散列，所以只有另一個表作排序合併，理論上比SORT JOIN會快些，需?/td>

　　"FONT-FAMILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">或FULL。

　　Object_Owner：擁有此database Object的Schema名或Oracle賬戶名。

　　Object_name：Database Object名

　　Object_type：類型，例如：表、視圖、索引等等

　　ID：指明某一步驟在執行計劃中的位置。

　　PARENT_ID：指明從某一操做中取得信息的前一個操做。經過對與ID和PARENT_ID使用Connect By操做，咱們能夠查詢整個執行計劃樹。

　　C)EXPLAIN搜索路徑解釋

　　•全表掃描(Full Table Scans)(無可用索引,大量數據,小表 ,全表掃描hints,HWM(High Water Mark), Rowid掃描)

　　•索引掃描

　　索引惟一掃描(Index Unique Scans)

　　索引範圍掃描(Index Range Scans)

　　索引降序範圍掃描(Index Range Scans Descending)

　　索引跳躍掃描(Index Skip Scans)

　　全索引掃描(Full Scans)

　　快速全索引掃描(Fast Full Index Scans)

　　索引鏈接(Index Joins)

　　位圖鏈接(Bitmap Joins)

　　• 如何選擇訪問路徑： CBO首先檢查WHERE子句中的條件以及FROM子句，肯定有哪些訪問路徑是可用的。而後CBO使用這個訪問路徑產生一組可能的執行計劃，再經過索引、表的統計信息評估每一個計劃的成本，最後優化器選擇成本最低的一個。

　　• 表的鏈接方式：

　　Nested Loops會循環外表(驅動表)，逐個比對和內表的鏈接是否符合條件。在驅動表比較小，內表比較大，並且內外表的鏈接列有索引的時候比較好。當SORT_AREA空間不足的時候，Oracle也會選擇使用NL。基於Cost的Oracle優化器(CBO)會自動選擇較小的表作外表。(優勢：嵌套循環鏈接比其餘鏈接方法有優點,它能夠快速地從結果集中提取第一批記錄,而不用等待整個結果集徹底肯定下來。缺點：若是內部行源表(讀取的第二張表(內表)已鏈接的列上不包含索引,或者索引不是高度可選時, 嵌套循環鏈接效率是很低的。若是驅動行源表(從驅動表中提取的記錄)很是龐大時,其餘的鏈接方法可能更加有效。)