oracle優化--shared_pool (3)

總的來說，減少parsing 是調優library_cache的主要方針
1.確保使用者能使用共享SQL語句。
2.防止已經PARSING過的語句被淘汰掉，使用方法就是分配足夠的記憶體。結合free_memory來看
3.避免表被改造
4.把一些SQL語句PINNING，避免它走LRU演算法。

通過以下方法可以降低應用系統中因為PARSE過於頻繁而導致的系統問題：
1.使用繫結變數
2.儘量不要使用動態SQL語句
3.連上來的使用者儘量不要更改他們優化器的相關設定
4.對於開發程式設計師來說，對於動態變數，要有一套命名規範，對於空格也要有一個標準
4.儘可能的使用儲存過程。
5.有些SQL語句是一樣的，但他們不能共享，通過v$SQL_SHARED_CURSOR
6.儘量要用同一個使用者連線
7.儘量使用pl/sql，呼叫PL/SQL包的時候，用不通使用者連上來。
8.在OLTP系統業務高峰中避免DDL的操作。
對於OLAP系統來說，以上的優化方法均不適用，建議不適用繫結變數

下面介紹一個重要的效能檢視：v$librarycache，他 描述了library_cache的各項指標
gets 找的次數
gethits 在記憶體裡找到了的次數
gethitratio:找到的百分比
PINS：找到了執行的次數
PINhit:執行之後成功的次數
pinhitration：執行的命中率
reload: 已經解析過了，但是某種原因，可能因為LRU演算法，時間一長就被淘汰了，就需要重解析
invalidation: 如果一個物件改變了，那已經編譯好的執行計劃也無效了，需要重新解析

如何檢視LIBRARY_CACHE的命中率？
SQL>select namespace,gethitratio,pinhitratio,reload,invalidation from v$library_cache;
注意：reload和invalidation接近0比較好

reload的百分比儘量要小於1%.
SQL>select sum(pins) "executions",sum(reload) "cache misses",sum(reload)/sum(pins)
from v$library_cache；這個語句就是查詢reload的百分比

這裡我們也要注意v$library_cache也是一個累計值，可能不準確，我們可以像statspack那種方法一樣，取
兩次值，我們進行相減，然後再計算。如果reload的值大於1%, 說明library_cache有點小了，但我們也要看看v$sgastat中的free_memory的大小，在業務的高峰期執行ddl，也會導致invalidation的增大。

下面在介紹幾個關於SQL的效能檢視：v$SQL,v$SQLAREA,V$SQLTEXT

SQL>select sql_text from v$sqlarea where execution < 5 order by upper(sql_text);
這就是檢視在LIBRARY裡檢視次數小於5的語句。

如何檢視現在正在執行哪些SQL語句？
SQL>select sql_text,users_executing,executing,loads from v$sqlarea;
然後我們可以查詢這條語句的完整資訊？
SQL>select * from v$sqltext where sql_text like 'select * from emp where ......'

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25116248/viewspace-1058097/，如需轉載，請註明出處，否則將追究法律責任。