oracle優化--shared_pool (1)

說到優化，我們們先從shared_pool開始說起，shared_pool(共享池),裡面包括了library_cache,dictionary_cache，library_cache存的是編譯好的SQL語句和PL/SQL.裡面遵循的是lru演算法，而dictionary_cache裡面存的是使用過的資料字典的資訊，是比較靜態的資訊,我們要優化共享池，主要優化的就是library_cache，我們首先對shared_pool有個簡單的瞭解，首先，我們不能單獨調整library_cache和library_cache的大小，我們只能調整全域性的shared_pool_size,但現在oracle推出了一個自動記憶體管理，在記憶體管理模式下，我們只需要調整sga_target這個引數，系統會根據情況自動調整其他引數，比如：db_cache_size,shared_pool_size,large_pool_size,java_pool_size.如果我們想手工管理記憶體，只需要直接修改shared_pool_size就可以了。
在這裡，我們先說一說當我們執行一條SQL語句之後，oracle內部都做了什麼？
當我們執行一個SQL語句的時候，oracle會對它進行編譯(parse),但在編譯之前，會先查詢，如果發現已經編譯好了，就直接共享了，這種編譯叫做軟編譯，如果沒有查到，就會把文字編譯成一個可以執行的程式碼，儲存在library_cache中。如果兩個語句想共享一個執行程式碼的時候，會有條件，oracle自動決定一個語句和共享池裡的一個語句是否一樣。具體
過程如下：
1.發出的sql語句會和shared_pool已經存在的進行對比，如果一樣，就利用已經編譯好的程式碼。
2.比較的過程是先hash，產生hash值，對比hash值，如果hash值不同，說明根本就不一樣。這時就硬解析了。
3.如果發現hash值是一樣的，oracle 會把這個字串進行逐個比較，看看是否完全相同，必須是完全一樣的，空格，大小寫和註釋，一個不同都不好使：
select * from scott.emp;
select * From scott.emp;
select * from scott.emp 這三個就不一樣，不能共享。
所以，shared_pool對效能影響的主要問題就是：在library_cache裡最大化的共享已經編譯好的SQL程式碼。
在生產中有兩種資料庫：OLTP和OLAP
OLTP:用的人多，每次執行的時間非常短
OLAP:用的人少，但每次執行的時間卻非常長。
所以，如果要提高OLTP系統的效能，就需要提高軟解析的數量，減少硬解析，因為對於OLAP系統來說，不需要操心reparing(重解析),因為重解析的時間相對於查詢的時間來說實在是微不足道啊。
--TO BE CONTINUED[@more@]

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