【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列5

bisal發表於2013-09-07
優化

Flushing(清空) SHARED POOL

       在使用大量literal SQL的系統中，shared pool隨時間推移會產生大量碎片進而導致併發能力的下降。Flushing shared pool能夠使得很多小塊碎片合併，所以經常能夠在一段時間內恢復系統的效能。清空之後可能也會產生短暫的效能下降(補充：因為需要做第一次的硬解析)，因為這個操作同時也會把沒造成shared pool碎片的共享SQL也清除了。清空shared pool的命令是：

ALTER SYSTEM FLUSH SHARED_POOL;(補充：不支援SESSION級別的)

注意：如果顯式的使用以上命令，即使是用DBMS_SHARED_POOL.KEEP而被保留的那些物件可能也會被釋放掉，包括它們佔用的記憶體。如果是隱式的flush(由於shared pool上的記憶體壓力)這個時候“kept"的物件不會被釋放。
注意：如果sequence使用了cache選項，沖刷shared pool有可能會使sequence在其範圍內產生不連續的記錄。
使用DBMS_SHARED_POOL.KEEP('sequence_name','Q')來保持sequence會防止這種不連續的情況發生。

DBMS_SHARED_POOL.PURGE
       也可以不重新整理整個shared pool，而只清空其中的單個物件。下面的文件說明了10g和11g中如何清空library cache heap。
Document:751876.1
DBMS_SHARED_POOL.PURGE Is Not Working On 10.2.0.4

使用 V$ 檢視 (V$SQL 和 V$SQLAREA)
       注意有一些V$檢視需要獲取相關的latch來返回查詢的資料。用來展示library cache和SQL area的檢視就是值得注意的。所以我們建議有選擇性的執行那些需要訪問這種型別檢視的語句。特別需要指出的是，查詢V$SQLAREA會在library cache latch上產生大量的負載，所以一般可以使用對latch訪問比較少的v$sql做替代——這是因為V$SQLAREA的輸出是基於shared pool中所有語句的GROUP BY操作，而V$SQL沒有用GROUP BY操作。

MTS, Shared Server 和 XA

       由於多執行緒伺服器(MTS)的User Global Area (UGA)是存放在shared pool中的，所以會增加shared pool的負載。在Oracle7上的XA session也會產生同樣的問題，因為他們的UGA也是在shared pool裡面(在Oracle8/8i開始XA session不再把UGA放到shared pool中)。在Oracle8中Large Pool可以被用來減少MTS對shared pool活動的影響——但是，Large Pool中的記憶體分配仍然會使用"shared pool latch"。

       使用dedicate connections(專有連線)替代MTS可以使UGA在程式私有記憶體中分配而不是shared pool。私有記憶體分配不會使用"shared pool latch"，所以在有些情況下從MTS切換到專有連線可以幫助減少競爭。

       在Oracle9i中，MTS被改名為"Shared Server"。但是對於shared pool產生影響的行為從根本上說還是一樣的。 

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

相關文章