ORACLE的工作機制-1

ORACLE的工作機制-1 (by xyf_tck)

我們從一個使用者請求開始講,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值，伺服器程式將到SHARED POOL的共享PL/SQL區去查詢是否存在同樣的HASH值，如果存在，伺服器程式將使用這條語句已快取記憶體在SHARED POOL中的已分析過的版本來執行（軟解析），如果不存在，則必須進行以下兩個步驟：語句的優化(生成執行計劃)和生成執行編碼：伺服器程式根據ORACLE選用的優化模式以及資料字典中是否存在相應物件的統計資料和是否使用了儲存大綱來生成一個執行計劃或從儲存大綱中選用一個執行計劃，最後再生成一個編譯程式碼（硬解析）。（這裡要注意的是，語法語義分析在前，計算HASH_VALUE在後，算出HASH_VALUE後只要找到相同的HASH_VALUE就使用這條快取執行計劃，語義分析在前確保了使用者的使用許可權等問題，不存在算出HASH_VALUE，再找到相同HASH_VALUE快取執行計劃而不能使用的情況。也不是先算HASH_VALUE，然後找快取執行計劃，找到後再語義檢查這個步驟也是錯的）ORACLE將這條語句的本身實際文字、HASH值、編譯程式碼、與此語句相關聯的任何統計資料和該語句的執行計劃快取在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都重新計算。原來的緩衝記錄仍然還存在。

伺服器程式通過SHARED POOL鎖存器來申請可以向哪些共享PL/SQL區中快取這些內容，也就是說被SHARED POOL鎖存器鎖定的PL/SQL區中的塊不可被覆蓋，因為這些塊可能正在被其它程式所使用。在SQL分析階段將用到LIBRARY CACHE，從資料字典中核對錶、索引、檢視及使用者的許可權的時候，需要將資料字典從磁碟讀入LIBRARY CACHE，因此，在讀入之前也要使用LIBRARY CACHE鎖存器來申請用於快取資料字典。