熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Oracle >> 正文

oracle中怎麼確定性能差的SQL語句

2013-11-13 22:24:52  來源: Oracle 

  前者很容易定位所有的操作系統都可以讓我們查看 CPU 密集型任務這些任務可以追溯到一個特定用戶一個特定應用程序模塊 CPU 密集型模塊一般都是由較差的代碼和/或結構造成而不是性能差的 SQL一旦確定模塊你必須試圖使之更有效率一個可能的解決方案是將把某些處理移除程序讓數據庫處理(高明點的 SQL存儲對象內聯函數數組處理等)

  第二個是 I/O 密集型的 SQL 語句這些語句會導致大量的數據庫 I/O(全表掃描排序更新等)並以很高代價運行幾個小時從 Oracle 開始解決了 SQL 識別問題通過查詢數據庫共享池區域我們可以很容易確定大多數 I/O 密集型 SQL 語句

  下面 SQL 語句演示了如何確定 I/O 命中率低於 %的 SQL 語句這個命中率是自從 SQL 語句第一次被解析到共享池通過所有執行的語句反應整體 I/O下面可能是最近幾分鐘或幾天的結果

  代碼如下 
sql> SELECT executions

          disk_reads

          buffer_gets

          ROUND((buffer_gets disk_reads) / buffer_gets ) hit_ratio

          sql_text

       FROM   v$sqlarea

      WHERE  executions  >

       AND    buffer_gets >

       AND    (buffer_gets disk_reads) / buffer_gets <

     order by desc ;

  EXECUTIONS DISK_READS BUFFER_GETS  HIT_RATIO SQL_TEXT

  

                           SELECT SKUPREPACK_INDCASE_IDTRANSFER_QTYUNIT_COSTUNIT_RETAILROWID

  FROM TSF_DETAIL WHERE transfer = :  order by sku

                             SELECT TRANSFERTO_STORETO_WH FROM TSFHEAD  WHERE TRANSFER = :b  AND

  TRANSFER_STATUS = A

                                SELECT SKU   FROM UPC_EAN  WHERE UPC = :b

                             SELECT SUBSTR(DESC_UP)DEPTSYSTEM_IND   FROM DESC_LOOK  WHERE

  SKU = :b

                             SELECT UNIT_COSTUNIT_RETAILSUBCLASS FROM WIN_SKUS WHERE SKU = :b

  事實上我們發現對特定的 SQL上面的數據有些誤導其實語句沒有問題考慮下面 v$sqlarea 輸出

  Executions Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

  

                                  SELECT AEMP_NO
 

  該語句的命中率很低但事實上它很有效因為SQL 是通過 UNIQUE 索引操作的物理磁盤讀取的數量幾乎與邏輯讀取一樣UNIQUE 索引顯著減少了整體的物理和邏輯磁盤 I/O 數量導致了一個令人誤解的低命中率

  下面例子命中率很好但是真的很好嗎?

  代碼如下 
Executions Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

  

                           SELECT AEMP_NO
 

  這個 SQL 語句看上去很有效但是 當我們仔細看時事情就不是那麼回事了命中率並沒有透露出該語句存在五個表連接並且每次執行進行了超過 個物理磁盤讀取這是否太多了?是否有效?若不進一步研究無法回答這兩個問題事實上這個實例中五個表的中其一個錯誤地執行了全表掃描通過重新構造 SQL我們可以減少物理磁盤 I/O 到小於 同時也顯著減少邏輯磁盤 I/O巧合的是命中率也下降到不到

  我們首選 V$SQLAREA 查詢是每個語句執行的物理磁盤 I/O 的真實報告命中率是信息性的但有時會產生誤導邏輯 I/O 相關的很少如果語句執行 個邏輯 I/O但只用了不到十分之一秒這就沒人在乎了這是總的物理 I/O幾乎消耗了所有的時間和確定潛在不正確的 SQL例如

  代碼如下 
sql> SELECT sql_text executions

  ROUND(disk_reads / executions ) reads_per_run

  disk_reads buffer_gets

  ROUND((buffer_gets disk_reads)

  / buffer_gets ) hit_ratio

  sql_text

  FROM   v$sqlarea

  WHERE  executions  >

  AND    buffer_gets >

  AND    (buffer_gets disk_reads) / buffer_gets <

  ORDER by desc ;
 

  前兩個語句會報告更具啟發性的結果

  代碼如下 
Executions Reads_Per_Run Disk_Reads Buffer_Gets Hit_Ratio Sql_Text

  

                                               SELECT

                                   SELECT
 

  從視圖 V$SQLAREA 中我們可以立即隔離所有具有高物理讀取的語句這些語句可能並不一定低效或寫得不好但恰恰是它們需要進一步調查或調整


From:http://tw.wingwit.com/Article/program/Oracle/201311/19041.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.