以下的文章主要是從相關(guān)用戶的請求開始入手的,Oracle數(shù)據(jù)庫完整的相關(guān)工作機制是如何運行得出？首先如果某個用戶相關(guān)進程發(fā)出一個相關(guān)的連接請求的話,如果你所使用的是主機命名或者是本地服務命中的主機名使用的是機器名(非IP地址)。

那么這個請求都會通過DNS服務器或HOST文件的服務名解析然后傳送到Oracle監(jiān)聽進程,監(jiān)聽進程接收到用戶請求后會采取兩種方式來處理這個用戶請求,下面我們分專用服務器和共享服務器分別采用這兩種方式時的情況來講：

專用服務器模式下：

一種方式是監(jiān)聽進程接收到用戶進程請求后，產(chǎn)生一個新的專用服務器進程，并且將對用戶進程的所有控制信息傳給此服務器進程，也就是說新建的服務器進程繼承了監(jiān)聽進程的信息，然后服務器進程給用戶進程發(fā)一個RESEND包，通知用戶進程可以開始給它發(fā)信息了，用戶進程給這個新建的服務器進程發(fā)一個CONNECT包，服務器進程再以ACCEPT包回應用戶進程，致此，用戶進程正式與服務器進程確定連接。

我們把這種連接叫做HAND-OFF連接，也叫轉(zhuǎn)換連接。另一種方式是監(jiān)聽進程接收到用戶進程的請求后產(chǎn)生一個新的專用服務器進程，這個服務器進程選用一個TCP/IP端口來控制與用戶進程的交互，然后將此信息回傳給監(jiān)聽進程，監(jiān)聽進程再將此信息傳給用戶進程。

用戶進程使用這個端口給服務器進程發(fā)送一個CONNECT包，服務器進程再給用戶進程發(fā)送一個ACCEPT包，致此，用戶進程可以正式向服務器進程發(fā)送信息了。

這種方式我們叫做重定向連接。HAND-OFF連接需要系統(tǒng)平臺具有進程繼承的能力，為了使WINDOWS NT/2000支持HAND-OFF必須在HKEY_LOCAL_MACHINE>SOFTWARE>Oracle>HOMEX中設置USE_SHARED_SOCKET。

共享服務器模式下：

只有重定向連接的方式，工作方式是監(jiān)聽進程接收到用戶進程的請求后產(chǎn)生一個新的調(diào)度進程，這個調(diào)度進程選用一個TCP/IP端口來控制與用戶進程的交互，然后將此信息回傳給監(jiān)聽進程，監(jiān)聽進程再將此信息傳給用戶進程，用戶進程使用這個端口給調(diào)度進程發(fā)送一個CONNECT包，調(diào)度進程再給用戶進程發(fā)送一個ACCEPT包，致此，用戶進程可以正式向調(diào)度進程發(fā)送信息了。

可以通過設置MAX_DISPIATCHERS這個參數(shù)來確定調(diào)度進程的***數(shù)目，如果調(diào)度進程的個數(shù)已經(jīng)達到了***，或者已有的調(diào)度進程不是滿負荷，監(jiān)聽進程將不再創(chuàng)建新的調(diào)度進程，而是讓其中一個調(diào)度進程選用一個TCP/IP端口來與此用戶進程交互。

調(diào)度進程每接收一個用戶進程請求都會在監(jiān)聽進程處作一個登記，以便監(jiān)聽進程能夠均衡每個調(diào)度進程的負荷，所有的用戶進程請求將分別在有限的調(diào)度進程中排隊，所有調(diào)度進程再順序的把各自隊列中的部分用戶進程請求放入同一個請求隊列。

等候多個Oracle數(shù)據(jù)庫的共享服務器進程進行處理（可以通過SHARED_SERVERS參數(shù)設置共享服務器進程的個數(shù)），也就是說所有的調(diào)度進程共享同一個請求隊列，共享服務器模式下一個實例只有一個請求隊列，共享服務器進程處理完用戶進程的請求后將根據(jù)用戶進程請求取自不同的調(diào)度進程將返回結(jié)果放入不同的響應隊列，也就是說有多少調(diào)度進程就有多少響應隊列，然后各個調(diào)度進程從各自的響應隊列中將結(jié)果取出再返回給用戶進程。

以上我們講完了用戶與Oracle的連接方式，下面我們要講Oracle服務器進程如可處理用戶進程的請求，當一個用戶進程發(fā)出了一條SQL語名：UPDATE TABBLEA SET SALARY=SALARY*2；首先，服務器進程把這條語句的字符轉(zhuǎn)換成ASCII等效數(shù)字碼，接著這個ASCII碼被傳遞給一個HASH函數(shù)，并返回一個HASH值，服務器進程將到SHARED POOL 的共享PL/SQL區(qū)去查找是否存在同樣的HASH值。

如果存在，服務器進程將使用這條語句已高速緩存在SHARED POOL中的已分析過的版本來執(zhí)行，如果不存在，服務器進程將對該語句進行語法分析，首先檢查該語句的語法的正確性，接著對語句中涉及的表、索引、視圖等對象進行解析，并對照數(shù)據(jù)字典檢查這些對象的名稱以及相關(guān)結(jié)構(gòu)，并根據(jù)Oracle選用的優(yōu)化模式以及數(shù)據(jù)字典中是否存在相應對象的統(tǒng)計數(shù)據(jù)和是否使用了存儲大綱來生成一個執(zhí)行計劃或從存儲大綱中選用一個執(zhí)行計劃，然后再用數(shù)據(jù)字典核對此用戶對相應對象的執(zhí)行權(quán)限，***生成一個編譯代碼。

Oracle數(shù)據(jù)庫將這條語名的本身實際文本、HASH值、編譯代碼、與此語名相關(guān)聯(lián)的任何統(tǒng)計數(shù)據(jù)和該語句的執(zhí)行計劃緩存在SHARED POOL的共享PL/SQL區(qū)。服務器進程通過SHARED POOL 鎖存器來申請可以向哪些共享PL/SQL區(qū)中緩存這此內(nèi)容，也就是說被SHARED POOL鎖存器鎖定的PL/SQL區(qū)中的塊不可被覆蓋，因為這些塊可能被其它進程所使用。

在SQL分析階段將用到LIBRARY CACHE，從數(shù)據(jù)字典中核對表、視圖等結(jié)構(gòu)的時候，需要將數(shù)據(jù)字典從磁盤讀入LIBRARY CACHE，因此，在讀入之前也要使用LIBRARY CACHE鎖存器來申請用于緩存數(shù)據(jù)字典。 生成編譯代碼之后，接著下一步服務器進程要準備開始更新數(shù)據(jù)，服務器進程將到DB BUFFER中查找是否有相關(guān)對象的緩存數(shù)據(jù)，

下面分兩個可能進行解釋：

如果沒有，服務器進程將在表頭部請求一些行鎖，如果成功加鎖，服務器進程將從數(shù)據(jù)文件中讀這些行所在的數(shù)據(jù)塊放入DB BUFFER中空閑的區(qū)域或者覆蓋已被擠出LRU列表的非臟數(shù)據(jù)塊緩沖區(qū)，并且排列在LRU列表的頭部，如果這些非臟數(shù)據(jù)緩沖區(qū)寫完也不能滿足新數(shù)據(jù)的請求時，會立即觸發(fā)DBWN進程將臟數(shù)據(jù)列表中指向的緩沖塊寫入數(shù)據(jù)文件，并且清洗掉這些緩沖區(qū)，來騰出空間緩沖新讀入的數(shù)據(jù)，也就是在放入DB BUFFER之前也是要先申請DB BUFFER中的鎖存器。

成功鎖定后，再寫入DB BUFFER，然后服務器程將該語句影響的被讀入DB BUFFER塊中的這些行的ROWID及將要更新的原值和新值及SCN等信息逐條的寫入REDO LOG BUFFER，在寫入REDO LOG BUFFER之前也是先請求REDO LOG BUFFER塊的鎖存器，成功鎖定之后才開始寫入，當寫入達到REDO LOG BUFFER大小的三分之一或?qū)懭肓窟_到1M或超過三秒后或發(fā)生檢查點時或者DBWN之前發(fā)生，LGWR將把REDO LOG BUFFER中的數(shù)據(jù)寫入磁盤上的重做日志文件。

已被寫入重做日志文件的REDO LOG BUFFER中的塊上的鎖存器被釋放，并可被后來寫入的信息所覆蓋，REDO LOG BUFFER以循環(huán)的方式工作。當一個重做日志文件寫滿后，LGWR將切換到下一個重做日志文件，如果是歸檔模式，歸檔進程還將前一個寫滿的重做日志進程寫入歸檔日志文件，重做日志文件也是循環(huán)工作方式。寫完所有的REDO LOG BUFFER之后，服務器進程開始改寫這個DB BUFFER塊頭部的事務列表并寫入SCN，然后COPY包含這個塊的頭部事務列表及SCN信息的數(shù)據(jù)副本放入回滾段中，我們將回滾段中的副本稱為數(shù)據(jù)塊的“前映像”。

（回滾段可以存儲在專門的回滾表空間中，這個表空間由一個或多個物理文件組成，并專用于回滾表空間，回滾段也可在其它表空間中的數(shù)據(jù)文件中開辟。）然后改寫這個DB BUFFER塊的數(shù)據(jù)，并在其頭部寫入對應的回滾段地址，如果對一行數(shù)據(jù)多次UPDATE而不COMMIT則在回滾段中將會有多個“前映像”，除***個“前映像”含有SCN信息外，其它的每個“前映像”的頭部還含有SCN信息和“前前映像”的回滾段地址。

一次UPDATE操作只對應一個SCN。然后服務器進程在臟數(shù)據(jù)列表中建立一條指向此緩沖塊的指針。接著服務器進程會從數(shù)據(jù)文件讀入第二個塊重復以上讀入，記日志，建立回滾段，修改，放入臟列表的動作，當臟數(shù)據(jù)列表達到一定長度時，DBWN進程將臟數(shù)據(jù)列表中指向的緩沖塊全部寫入數(shù)據(jù)文件，也就是釋放加在這些DB BUFER 塊上的鎖存器。其實Oracle數(shù)據(jù)庫可以一次從數(shù)據(jù)文件中讀入幾個塊放入DB BUFFER，可以通過參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT來設置一次讀入的塊的個數(shù)。

如果要查找的數(shù)據(jù)已緩存，則根據(jù)用戶的SQL操作類型決定如何操作，如果是SELECT 則查看DB BUFFER塊的頭部是否有事務，如果有，將從回滾段讀取，如果沒有則比較SELECT 的SCN與DB BUFFER塊頭部的SCN如果比自己大，仍然從回滾段讀取，如果比自己小則認這是一個非臟緩存，可以直接從這個DB BUFFER塊中讀取。如果是UPDATE則即使在DB BUFFER中找到一個沒有事務，而且SCN比自己小的非臟緩存數(shù)據(jù)塊，服務器進程仍然要到表的頭部對這條記錄申請加鎖，加鎖成功則進行后續(xù)動作，如果不成功，則要等待前面的進程解鎖后才能進行動作。

只有當SQL語句影響的所有行所在的***一個塊被讀入DB BUFFER并且重做信息被寫入REDO LOG BUFFER（僅是指重做日志緩沖，而非重做日志文件）之后，用戶才可以發(fā)出COMMIT，COMMIT觸發(fā)LGRW，但并不強制立即DBWN來釋放所有相應的DB BUFFER塊上的鎖，也就是說有可能出現(xiàn)已COMMIT，但在隨后的一段時間內(nèi)DBWN還在寫這條語句涉及的數(shù)據(jù)塊的情形，表頭部的行鎖，并不是在COMMIT一發(fā)出就馬上釋放，實際上要等到相應的DBWN進程結(jié)束才會釋放。

一個用戶請求鎖定另一個用戶已COMMIT的資源不成功的機會是存在的，從COMMIT到DBWN進程結(jié)束之間的時間很短，如果恰巧在這個時間斷電，由于COMMIT已觸發(fā)LGWR進程，所以這些未來得及寫入數(shù)據(jù)文件的改變會在實例重啟后由SMON進程根據(jù)重做日志文件來前滾。如果未COMMIT就斷電，由于DBWN之前觸發(fā)LGWR，所有DBWN在數(shù)據(jù)文件上的修改都會被先一步記入重做日志文件，實例重啟后，SMON進程再根據(jù)重做日志文件來回滾。

如果用戶ROOLBACK，則服務器進程會根據(jù)數(shù)據(jù)文件塊和DB BUFFER中塊的頭部的事務列表和SCN以及回滾段地址找到回滾段中相應的修改前的副本，并且用這些原值來還原當前數(shù)據(jù)文件中已修改但未提交的改變。如果有多個“前映像”，服務器進程會在一個“前映像”的頭部找到“前前映像”的回滾段地址，一直找到同一事務下的最早的一個“前映像”為止。一旦發(fā)出了COMMIT，用戶就不能ROOLBACK，這使得COMMIT后DBWN進程還沒有全部完成的后續(xù)動作得到了保障。

下面我們要提到檢查點的作用，當一個全部檢查點發(fā)生的時候，首先讓LGWR進程將REDO LOG BUFFER中的所有緩沖（包含未提交的重做信息）寫入重做日志文件，然后讓DBWN進程將DB BUFFER中所有已提交的緩沖寫入數(shù)據(jù)文件（不強制寫未提交的）。

然后更新控制文件和數(shù)據(jù)文件頭部的SCN，表明當前數(shù)據(jù)庫是一致的，如果在發(fā)生檢點之前斷電，并且當時有一個未提交的改變正在進行，實例重啟之后，SMON進程將從上一個檢查點開始核對這個檢查點之后記錄在重做日志文件中已提交的和未提交改變，因為DBWN之前會觸發(fā)LGWR，所以DBWN對數(shù)據(jù)文件的修改一定會被先記錄在重做日志文件中。

因此，斷電前被DBWN寫進數(shù)據(jù)文件的改變將通過重做日志文件中的記錄進行還原，叫做回滾，如果斷電時有一個已提交，但DBWN動作還沒有完全完成的改變存在，因為已經(jīng)提交，提交會觸發(fā)LGWR進程，所以不管DBWN動作是否已完成，該語句將要影響的行及其產(chǎn)生的結(jié)果一定已經(jīng)記錄在重做日志文件中了，則實例重啟后，SMON進程根據(jù)重做日志文件進行前滾。

由此可見，實例失敗后用于恢復的時間由兩個檢查點之間的間隔大小來決定，我們可以通個四個參數(shù)設置檢查點執(zhí)行的頻率，LOG_CHECKPOINT_INTERVAL決定了兩個檢查點之間寫入重做日志文件的系統(tǒng)物理塊的大小，LOG_CHECKPOINT_TIMEOUT決定了兩個檢查點之間的時間長度，F(xiàn)AST_START_IO_TARGET決定了用于恢復時需要處理的塊的大小，F(xiàn)AST_START_MTTR_TARGET直接決定了用于恢復的時間的長短。

SMON進程執(zhí)行的前滾和回滾與用戶的回滾是不同的，SMON是根據(jù)重做日志文件進行前滾或回滾，而用戶的回滾一定是根據(jù)回滾段的內(nèi)容進行回滾的。在這里我們要說一下回滾段存儲的數(shù)據(jù)，假如是delete操作，則回滾段將會記錄整個行的數(shù)據(jù)，假如是update,則回滾段只記錄被修改了的字段的變化前的數(shù)據(jù)（前映像），也就是沒有被修改的字段是不會被記錄的，假如是insert，則回滾段只記錄插入記錄的rowid。

這樣假如事務提交，那回滾段中簡單標記該事務已經(jīng)提交；假如是回退，則如果操作是是delete,回退的時候把回滾段中數(shù)據(jù)重新寫回數(shù)據(jù)塊，操作如果是update，則把變化前數(shù)據(jù)修改回去，操作如果是insert，則根據(jù)記錄的rowid 把該記錄刪除。

下面我們要講DBWN如何來寫數(shù)據(jù)文件，在寫數(shù)據(jù)文件前首先要找到可寫的空閑數(shù)據(jù)塊，Oracle中空閑數(shù)據(jù)塊可以通過FREELIST或BITMAP來維護，它們位于一個段的頭部用來標識當前段中哪些數(shù)據(jù)塊可以進行INSERT。

在本地管理表空間中Oracle數(shù)據(jù)庫自動管理分配給段的區(qū)的大小，區(qū)的分配信息存儲在組成表空間的數(shù)據(jù)文件的頭部，而數(shù)據(jù)字典管理的表空間用戶可以在創(chuàng)建時決定區(qū)的大小，并且區(qū)的分配信息是存儲在數(shù)據(jù)字典中的，只在本地管理的表空間中才能選用段自動管理，采用自動段空間管理的本地管理表空間中的段中的空閑數(shù)據(jù)塊的信息就存放在段的頭部并且使用位圖來管理，采用手動管理的本地管理表空間中的段和數(shù)據(jù)字典管理的表空間中的段中的空閑數(shù)據(jù)塊的管理都使用位于段頭部的空閑列表來管理，

空閑列表的工作方式：

首先一個空的數(shù)據(jù)塊被加入空閑列表，當其中空閑空間小于PCTFREE設置的值之后，這個塊從空閑列表刪除，當這個塊中的內(nèi)容降至PCTUSED設置的值之下后，這個數(shù)據(jù)塊被再次加入空閑列表，位于空閑列表中的數(shù)據(jù)塊都是可以向其中INSERT的塊，當一個塊移出了空閑列表，但只要其中還有保留空間就可以進行UPDATE，當對其中一行UPDATE一個大數(shù)據(jù)時，如果當前塊不能完全放下整個行，只會把整個行遷移到一個新的數(shù)據(jù)塊，并在原塊位置留下一個指向新塊的指針，這叫行遷移。

如果一個數(shù)據(jù)塊可以INSERT，當插入一個當前塊裝不下的行時，這個行會溢出到兩個或兩個幾上的塊中，這叫行鏈接。如果用戶的動作是INSERT 則服務器進程會先鎖定FREELIST，然后找到空閑塊的地址，再釋放FREELIST，當多個服務器進程同時想要鎖定FREELIST時即發(fā)生FREELIST的爭用，可以在非采用自動段空間管理的表空間中創(chuàng)建表時指定FREELIST的個數(shù)。

默認為1，如果是在采用自動段空間管理的表空間中創(chuàng)建表，即使指定了FREELIST也會被忽略，因為此時將使用BITMAP而不是FREELIST來管理段中的空閑空間。如果用戶動作是UPDATE服務器進程將不會使用到FREELIST和BITMAP，因為不要去尋找一個空閑塊，而使用鎖的隊列。

【編輯推薦】

1. Oracle 查詢記錄相關(guān)效率的查詢
2. Oracle并發(fā)連接數(shù)的設置方案
3. Oracle存取LONG類型字段的方案描述
4. Oracle存取LONG類型字段的方案描述
5. Oracle查詢優(yōu)化4大方面的主要途徑