學習Oracle時，你可能會遇到Oracle Shared Pool問題，這裡將介紹Oracle Shared Pool問題的解決方法，在這裡拿出來和大家分享一下。我們從一個用戶請求開始講，Oracle的簡要的工作機制是怎樣的，首先一個用戶進程發出一個連接請求，如果使用的是主機命名或者是本地服務命中的主機名使用的是機器名(非IP地址)，那麼這個請求都會通過DNS服務器或HOST文件的服務名解析然後傳送到Oracle監聽進程，監聽進程接收到用戶請求後會采取兩種方式來處理這個用戶請求，下面我們分專用服務器和共享服務器分別采用這兩種方式時的情況來講：
專用服務器模式下：一種方式是監聽進程接收到用戶進程請求後，產生一個新的專用服務器進程，並且將對用戶進程的所有控制信息傳給此服務器進程，也就是說新建的服務器進程繼承了監聽進程的信息，然後這個服務器進程給用戶進程發一個RESEND包，通知用戶進程可以開始給它發信息了，用戶進程給這個新建的服務器進程發一個CONNECT包，服務器進程再以ACCEPT包回應用戶進程，至此，用戶進程正式與服務器進程確定連接。我們把這種連接叫做HAND-OFF連接，也叫轉換連接。
另一種方式是監聽進程接收到用戶進程的請求後產生一個新的專用服務器進程，這個服務器進程選用一個TCP/IP端口來控制與用戶進程的交互，然後將此信息回傳給監聽進程，監聽進程再將此信息傳給用戶進程，用戶進程使用這個端口給服務器進程發送一個CONNECT包，服務器進程再給用戶進程發送一個ACCEPT包，至此，用戶進程可以正式向服務器進程發送信息了。這種方式我們叫做重定向連接。HAND-OFF連接需要系統平台具有進程繼承的能力，為了使Windows NT/2000支持HAND-OFF必須在HKEY_LOCAL_MacHINE>SOFTWARE>Oracle>HOMEX中設置USE_SHARED_SOCKET。
共享服務器模式下：只有重定向連接的方式，工作方式是監聽進程接收到用戶進程的請求後產生一個新的調度進程，這個調度進程選用一個TCP/IP端口來控制與用戶進程的交互，然後將此信息回傳給監聽進程，監聽進程再將此信息傳給用戶進程，用戶進程使用這個端口給調度進程發送一個CONNECT包，調度進程再給用戶進程發送一個ACCEPT包，至此，用戶進程可以正式向調度進程發送信息了。可以通過設置MAX_DISPIATCHERS這個參數來確定調度進程的最大數目，如果調度進程的個數已經達到了最大，或者已有的調度進程不是滿負荷，監聽進程將不再創建新的調度進程，而是讓其中一個調度進程選用一個TCP/IP端口來與此用戶進程交互。調度進程每接收一個用戶進程請求都會在監聽進程處作一個登記，以便監聽進程能夠均衡每個調度進程的負荷，所有的用戶進程請求將分別在有限的調度進程中排隊，所有調度進程再順序的把各自隊列中的部分用戶進程請求放入同一個請求隊列，等候多個Oracle的共享服務器進程進行處理（可以通過SHARED_SERVERS參數設置共享服務器進程的個數），也就是說所有的調度進程共享同一個請求隊列，共享服務器模式下一個實例只有一個請求隊列，共享服務器進程處理完用戶進程的請求後將根據用戶進程請求取自不同的調度進程將返回結果放入不同的響應隊列，也就是說有多少調度進程就有多少響應隊列，然後各個調度進程從各自的響應隊列中將結果取出再返回給用戶進程。
以上我們講完了用戶與ORACLE的連接方式，下面我們要講ORACLE服務器進程如何處理用戶進程的請求，當一個用戶進程發出了一條SQL語句：UPDATE TABBLEA SET SALARY=SALARY*2；首先服務器進程將對該語句進行檢查語句有效性的語法檢查和確保語句能夠正常運行的語義檢查，首先檢查該語句的語法的正確性（語法檢查），接著對照數據字典對語句中涉及的表、索引、視圖等對象及用戶的權限進行檢查（語義檢查），如果以上任一檢查沒有通過，就返回一個錯誤，但不會明確的指出是語法檢查出錯還是語義檢查出錯，它只會返回一個ORA-*****的錯誤碼。如果檢查通過以後，服務器進程把這條語句的字符轉換成ASCII等效數字碼（注意SQL中使用*是個例外，如果表的字段改變了，同樣是SELECT * FROM TABLEA轉換成的ASCII是不同的，其實它在語義檢查時就明確的變成了操作具體字段的SQL語句了），接著這個ASCII碼被傳遞給一個HASH函數，並返回一個HASH值，服務器進程將到Oracle Shared Pool的共享PL/SQL區去查找是否存在同樣的HASH值，如果存在，服務器進程將使用這條語句已高速緩存在Oracle Shared Pool中的已分析過的版本來執行（軟解析），如果不存在，則必須進行以下兩個步驟：語句的優化(生成執行計劃)和生成執行編碼：服務器進程根據Oracle選用的優化模式以及數據字典中是否存在相應對象的統計數據和是否使用了存儲大綱來生成一個執行計劃或從存儲大綱中選用一個執行計劃，最後再生成一個編譯代碼（硬解析）。
ORACLE將這條語句的本身實際文本、HASH值、編譯代碼、與此語句相關聯的任何統計數據和該語句的執行計劃緩存在Oracle Shared Pool的共享PL/SQL區。V$librarycache中的幾個參數解釋Pins: (Execution)即SQL實際執行的次數，不包括用戶提交的語法語義檢查失敗的SQL。Reloads: (Parse)未找到相同HASH_VALUE的次數，即必須進行硬解析的次數。Invalidations: (Parse)因對象更改，使得所有引用這個對象的緩存執行計劃失效而必須再次硬解析的次數。只要DDL更改了一個對象，所有與此有關的緩存在共享池中執行計劃都將立即失效，它的失效不是在下次執行SQL時才發現其失效，而是DDL更改對象後立即就失效。主要表現在DDL發生後v$sql的HASH_VALUE仍保持不變，但PLAN_HASH_VALUE立即變為0，再次運行SQL語句時則會向v$sql插入一條新的緩沖記錄HASH_VALUE，PLAN_HASH_VALUE都重新計算。原來的緩沖記錄仍然還存在。
服務器進程通過Oracle Shared Pool鎖存器來申請可以向哪些共享PL/SQL區中緩存這些內容，也就是說被Oracle Shared Pool鎖存器鎖定的PL/SQL區中的塊不可被覆蓋，因為這些塊可能正在被其它進程所使用。在SQL分析階段將用到LIBRARY CACHE，從數據字典中核對表、索引、視圖及用戶的權限的時候，需要將數據字典從磁盤讀入LIBRARY CACHE，因此，在讀入之前也要使用LIBRARY CACHE鎖存器來申請用於緩存數據字典。
