ORACLE的工作機(jī)制.docx

ORACLE的工作機(jī)制-1肖亞峰(xyf_tck)我們從一個(gè)用戶請(qǐng)求開(kāi)始講,ORACLE的簡(jiǎn)要的工作機(jī)制是怎樣的,首先一個(gè)用戶進(jìn)程發(fā)出一個(gè)連接請(qǐng)求,如果使用的是主機(jī)命名或者是本地服務(wù)命中的主機(jī)名使用的是機(jī)器名(非IP地址)，那么這個(gè)請(qǐng)求都會(huì)通過(guò)DNS服務(wù)器或HOST文件的服務(wù)名解析然后傳送到ORACLE監(jiān)聽(tīng)進(jìn)程,監(jiān)聽(tīng)進(jìn)程接收到用戶請(qǐng)求后會(huì)采取兩種方式來(lái)處理這個(gè)用戶請(qǐng)求,下面我們分專用服務(wù)器和共享服務(wù)器分別采用這兩種方式時(shí)的情況來(lái)講：專用服務(wù)器模式下：一種方式是監(jiān)聽(tīng)進(jìn)程接收到用戶進(jìn)程請(qǐng)求后，產(chǎn)生一個(gè)新的專用服務(wù)器進(jìn)程，并且將對(duì)用戶進(jìn)程的所有控制信息傳給此服務(wù)器進(jìn)程，也就是說(shuō)新建的服務(wù)器進(jìn)程繼承了監(jiān)聽(tīng)進(jìn)程的信息，然后這個(gè)服務(wù)器進(jìn)程給用戶進(jìn)程發(fā)一個(gè)RESEND包，通知用戶進(jìn)程可以開(kāi)始給它發(fā)信息了，用戶進(jìn)程給這個(gè)新建的服務(wù)器進(jìn)程發(fā)一個(gè)CONNECT包，服務(wù)器進(jìn)程再以ACCEPT包回應(yīng)用戶進(jìn)程，至此，用戶進(jìn)程正式與服務(wù)器進(jìn)程確定連接。我們把這種連接叫做HAND-OFF連接，也叫轉(zhuǎn)換連接。另一種方式是監(jiān)聽(tīng)進(jìn)程接收到用戶進(jìn)程的請(qǐng)求后產(chǎn)生一個(gè)新的專用服務(wù)器進(jìn)程，這個(gè)服務(wù)器進(jìn)程選用一個(gè)TCP/IP端口來(lái)控制與用戶進(jìn)程的交互，然后將此信息回傳給監(jiān)聽(tīng)進(jìn)程，監(jiān)聽(tīng)進(jìn)程再將此信息傳給用戶進(jìn)程，用戶進(jìn)程使用這個(gè)端口給服務(wù)器進(jìn)程發(fā)送一個(gè)CONNECT包，服務(wù)器進(jìn)程再給用戶進(jìn)程發(fā)送一個(gè)ACCEPT包，至此，用戶進(jìn)程可以正式向服務(wù)器進(jìn)程發(fā)送信息了。這種方式我們叫做重定向連接。HAND-OFF連接需要系統(tǒng)平臺(tái)具有進(jìn)程繼承的能力，為了使WINDOWS NT/2000支持HAND-OFF必須在HKEY_LOCAL_MACHINESOFTWAREORACLEHOMEX中設(shè)置USE_SHARED_SOCKET。共享服務(wù)器模式下：只有重定向連接的方式，工作方式是監(jiān)聽(tīng)進(jìn)程接收到用戶進(jìn)程的請(qǐng)求后產(chǎn)生一個(gè)新的調(diào)度進(jìn)程，這個(gè)調(diào)度進(jìn)程選用一個(gè)TCP/IP端口來(lái)控制與用戶進(jìn)程的交互，然后將此信息回傳給監(jiān)聽(tīng)進(jìn)程，監(jiān)聽(tīng)進(jìn)程再將此信息傳給用戶進(jìn)程，用戶進(jìn)程使用這個(gè)端口給調(diào)度進(jìn)程發(fā)送一個(gè)CONNECT包，調(diào)度進(jìn)程再給用戶進(jìn)程發(fā)送一個(gè)ACCEPT包，至此，用戶進(jìn)程可以正式向調(diào)度進(jìn)程發(fā)送信息了?？梢酝ㄟ^(guò)設(shè)置MAX_DISPIATCHERS這個(gè)參數(shù)來(lái)確定調(diào)度進(jìn)程的最大數(shù)目，如果調(diào)度進(jìn)程的個(gè)數(shù)已經(jīng)達(dá)到了最大，或者已有的調(diào)度進(jìn)程不是滿負(fù)荷，監(jiān)聽(tīng)進(jìn)程將不再創(chuàng)建新的調(diào)度進(jìn)程，而是讓其中一個(gè)調(diào)度進(jìn)程選用一個(gè)TCP/IP端口來(lái)與此用戶進(jìn)程交互。調(diào)度進(jìn)程每接收一個(gè)用戶進(jìn)程請(qǐng)求都會(huì)在監(jiān)聽(tīng)進(jìn)程處作一個(gè)登記，以便監(jiān)聽(tīng)進(jìn)程能夠均衡每個(gè)調(diào)度進(jìn)程的負(fù)荷，所有的用戶進(jìn)程請(qǐng)求將分別在有限的調(diào)度進(jìn)程中排隊(duì)，所有調(diào)度進(jìn)程再順序的把各自隊(duì)列中的部分用戶進(jìn)程請(qǐng)求放入同一個(gè)請(qǐng)求隊(duì)列，等候多個(gè)ORACLE的共享服務(wù)器進(jìn)程進(jìn)行處理（可以通過(guò)SHARED_SERVERS參數(shù)設(shè)置共享服務(wù)器進(jìn)程的個(gè)數(shù)），也就是說(shuō)所有的調(diào)度進(jìn)程共享同一個(gè)請(qǐng)求隊(duì)列，共享服務(wù)器模式下一個(gè)實(shí)例只有一個(gè)請(qǐng)求隊(duì)列，共享服務(wù)器進(jìn)程處理完用戶進(jìn)程的請(qǐng)求后將根據(jù)用戶進(jìn)程請(qǐng)求取自不同的調(diào)度進(jìn)程將返回結(jié)果放入不同的響應(yīng)隊(duì)列，也就是說(shuō)有多少調(diào)度進(jìn)程就有多少響應(yīng)隊(duì)列，然后各個(gè)調(diào)度進(jìn)程從各自的響應(yīng)隊(duì)列中將結(jié)果取出再返回給用戶進(jìn)程。以上我們講完了用戶與ORACLE的連接方式，下面我們要講ORACLE服務(wù)器進(jìn)程如何處理用戶進(jìn)程的請(qǐng)求，當(dāng)一個(gè)用戶進(jìn)程發(fā)出了一條SQL語(yǔ)句：UPDATE TABBLEA SET SALARY=SALARY*2；首先服務(wù)器進(jìn)程將對(duì)該語(yǔ)句進(jìn)行檢查語(yǔ)句有效性的語(yǔ)法檢查和確保語(yǔ)句能夠正常運(yùn)行的語(yǔ)義檢查，首先檢查該語(yǔ)句的語(yǔ)法的正確性（語(yǔ)法檢查），接著對(duì)照數(shù)據(jù)字典對(duì)語(yǔ)句中涉及的表、索引、視圖等對(duì)象及用戶的權(quán)限進(jìn)行檢查（語(yǔ)義檢查），如果以上任一檢查沒(méi)有通過(guò)，就返回一個(gè)錯(cuò)誤，但不會(huì)明確的指出是語(yǔ)法檢查出錯(cuò)還是語(yǔ)義檢查出錯(cuò)，它只會(huì)返回一個(gè)ORA-*的錯(cuò)誤碼。如果檢查通過(guò)以后，服務(wù)器進(jìn)程把這條語(yǔ)句的字符轉(zhuǎn)換成ASCII等效數(shù)字碼（注意SQL中使用*是個(gè)例外，如果表的字段改變了，同樣是SELECT * FROM TABLEA轉(zhuǎn)換成的ASCII是不同的，其實(shí)它在語(yǔ)義檢查時(shí)就明確的變成了操作具體字段的SQL語(yǔ)句了），接著這個(gè)ASCII碼被傳遞給一個(gè)HASH函數(shù)，并返回一個(gè)HASH值，服務(wù)器進(jìn)程將到SHARED POOL的共享PL/SQL區(qū)去查找是否存在同樣的HASH值，如果存在，服務(wù)器進(jìn)程將使用這條語(yǔ)句已高速緩存在SHARED POOL中的已分析過(guò)的版本來(lái)執(zhí)行（軟解析），如果不存在，則必須進(jìn)行以下兩個(gè)步驟：語(yǔ)句的優(yōu)化(生成執(zhí)行計(jì)劃)和生成執(zhí)行編碼：服務(wù)器進(jìn)程根據(jù)ORACLE選用的優(yōu)化模式以及數(shù)據(jù)字典中是否存在相應(yīng)對(duì)象的統(tǒng)計(jì)數(shù)據(jù)和是否使用了存儲(chǔ)大綱來(lái)生成一個(gè)執(zhí)行計(jì)劃或從存儲(chǔ)大綱中選用一個(gè)執(zhí)行計(jì)劃，最后再生成一個(gè)編譯代碼（硬解析）。（這里要注意的是，語(yǔ)法語(yǔ)義分析在前，計(jì)算HASH_VALUE在后，算出HASH_VALUE后只要找到相同的HASH_VALUE就使用這條緩存執(zhí)行計(jì)劃，語(yǔ)義分析在前確保了用戶的使用權(quán)限等問(wèn)題，不存在算出HASH_VALUE，再找到相同HASH_VALUE緩存執(zhí)行計(jì)劃而不能使用的情況。也不是先算HASH_VALUE，然后找緩存執(zhí)行計(jì)劃，找到后再語(yǔ)義檢查這個(gè)步驟也是錯(cuò)的）ORACLE將這條語(yǔ)句的本身實(shí)際文本、HASH值、編譯代碼、與此語(yǔ)句相關(guān)聯(lián)的任何統(tǒng)計(jì)數(shù)據(jù)和該語(yǔ)句的執(zhí)行計(jì)劃緩存在SHARED POOL的共享PL/SQL區(qū)。V$librarycache中的幾個(gè)參數(shù)解釋Pins: (Execution)即SQL實(shí)際執(zhí)行的次數(shù)，不包括用戶提交的語(yǔ)法語(yǔ)義檢查失敗的SQL。Reloads: (Parse)未找到相同HASH_VALUE的次數(shù)，即必須進(jìn)行硬解析的次數(shù)。Invalidations: (Parse)因?qū)ο蟾?，使得所有引用這個(gè)對(duì)象的緩存執(zhí)行計(jì)劃失效而必須再次硬解析的次數(shù)。只要DDL更改了一個(gè)對(duì)象，所有與此有關(guān)的緩存在共享池中執(zhí)行計(jì)劃都將立即失效，它的失效不是在下次執(zhí)行SQL時(shí)才發(fā)現(xiàn)其失效，而是DDL更改對(duì)象后立即就失效。主要表現(xiàn)在DDL發(fā)生后v$sql的HASH_VALUE仍保持不變，但PLAN_HASH_VALUE立即變?yōu)?,再次運(yùn)行SQL語(yǔ)句時(shí)則會(huì)向v$sql插入一條新的緩沖記錄HASH_VALUE，PLAN_HASH_VALUE都重新計(jì)算。原來(lái)的緩沖記錄仍然還存在。服務(wù)器進(jìn)程通過(guò)SHARED POOL鎖存器來(lái)申請(qǐng)可以向哪些共享PL/SQL區(qū)中緩存這些內(nèi)容，也就是說(shuō)被SHARED POOL鎖存器鎖定的PL/SQL區(qū)中的塊不可被覆蓋，因?yàn)檫@些塊可能正在被其它進(jìn)程所使用。在SQL分析階段將用到LIBRARY CACHE，從數(shù)據(jù)字典中核對(duì)表、索引、視圖及用戶的權(quán)限的時(shí)候，需要將數(shù)據(jù)字典從磁盤(pán)讀入LIBRARY CACHE，因此，在讀入之前也要使用LIBRARY CACHE鎖存器來(lái)申請(qǐng)用于緩存數(shù)據(jù)字典。ORACLE的工作機(jī)制-2肖亞峰(xyf_tck)生成編譯代碼之后，接著下一步服務(wù)器進(jìn)程要準(zhǔn)備開(kāi)始更新數(shù)據(jù)，服務(wù)器進(jìn)程將到DB BUFFER中查找是否有相關(guān)對(duì)象的緩存數(shù)據(jù)，下面分兩個(gè)可能進(jìn)行解釋：如果沒(méi)有，服務(wù)器進(jìn)程將在表頭部請(qǐng)求一些行鎖，如果成功加鎖，服務(wù)器進(jìn)程將從數(shù)據(jù)文件中讀入這些行所在的第一個(gè)數(shù)據(jù)塊(db block)（DB BLOCK是ORACLE的最小操作單元，即使你想要的數(shù)據(jù)只是DB BLOCK中很多行中的一行或幾行，ORACLE也會(huì)把這個(gè)DB BLOCK中的所有行都讀入DB BUFFER中）放入DB BUFFER中空閑的區(qū)域或者覆蓋已被擠出LRU列表的非臟數(shù)據(jù)塊緩沖區(qū)，并且排列在LRU列表的頭部，如果這些非臟數(shù)據(jù)緩沖區(qū)寫(xiě)完也不能滿足新數(shù)據(jù)的請(qǐng)求時(shí)，會(huì)立即觸發(fā)DBWN進(jìn)程將臟數(shù)據(jù)列表中指向的緩沖塊寫(xiě)入數(shù)據(jù)文件，并且清洗掉這些緩沖區(qū)，來(lái)騰出空間緩沖新讀入的數(shù)據(jù)，也就是在放入DB BUFFER之前也是要先申請(qǐng)DB BUFFER中的鎖存器，成功鎖定后，再寫(xiě)入DB BUFFER，然后把這個(gè)塊的頭部事務(wù)列表及SCN信息及被影響的行數(shù)據(jù)原值寫(xiě)入回滾段中，以便ORACLE在ROLLBACK時(shí)可以利用當(dāng)前數(shù)據(jù)塊和回滾段重構(gòu)數(shù)據(jù)塊的前映像或遞歸重構(gòu)出前前映像來(lái)實(shí)現(xiàn)讀一致性。（回滾段可以存儲(chǔ)在專門(mén)的回滾表空間中，這個(gè)表空間由一個(gè)或多個(gè)物理文件組成，并專用于回滾表空間，回滾段也可在其它表空間中的數(shù)據(jù)文件中開(kāi)辟。）然后在LOG BUFFER中生成日志，服務(wù)器程將該語(yǔ)句影響的被讀入DB BUFFER塊中的這些行的ROWID及將要更新的原值和新值及SCN等信息,以及回滾段的修改信息(即對(duì)某某回滾段地址進(jìn)行了什么修改)逐條的寫(xiě)入REDO LOG BUFFER，在寫(xiě)入REDO LOG BUFFER之前也是先請(qǐng)求REDO LOG BUFFER塊的鎖存器，成功鎖定之后才開(kāi)始把REDOLOG寫(xiě)入REDOLOG BUFFER。當(dāng)寫(xiě)入達(dá)到REDO LOG BUFFER大小的三分之一或?qū)懭肓窟_(dá)到1M或超過(guò)三秒后或發(fā)生檢查點(diǎn)時(shí)或者COMMIT時(shí)或者DBWN之前觸發(fā)LGWR進(jìn)程，LGWR將把REDO LOG BUFFER中的數(shù)據(jù)寫(xiě)入磁盤(pán)上的重做日志文件，已被寫(xiě)入重做日志文件的REDO LOG BUFFER中的塊上的鎖存器被釋放，并可被后來(lái)寫(xiě)入的信息所覆蓋。回滾段其實(shí)也有BUFFER（在DB BUFFER中開(kāi)辟），回滾段BUFFER中的內(nèi)容是最早向磁盤(pán)上回滾段中寫(xiě)的，寫(xiě)完這些才會(huì)生成日志BUFFER中的內(nèi)容，原因是日志中必須要記錄回滾段的新舊變化以便在恢復(fù)時(shí)從日志中的記錄的回滾段新舊變化對(duì)回滾段再次重寫(xiě)，記住，REDO不光是對(duì)數(shù)據(jù)文件依據(jù)日志文件重寫(xiě)，也要依據(jù)日志文件對(duì)回滾段重寫(xiě)，而且重寫(xiě)回滾段要先于重寫(xiě)數(shù)據(jù)文件，要理解REDO就是重來(lái)一遍，所謂重來(lái)一遍就要跟正常的的先后順利一樣重做一遍（正常的操作中的順序就是先讀入DB BUFFER，寫(xiě)回滾段buffer,后寫(xiě)回滾段，后寫(xiě)日志BUFFER，后改寫(xiě)DB BUFFER，后寫(xiě)日志最后寫(xiě)數(shù)據(jù)文件）區(qū)別是REDO時(shí)不用再記日志了，這樣解釋后相信大家應(yīng)該理解為什么日志中也必須要記錄回滾段的信息了，只有這樣才可以對(duì)正常操作中的一個(gè)ROLLBACK動(dòng)作進(jìn)行恢復(fù)，即在REDO過(guò)程中利用即時(shí)重寫(xiě)的數(shù)據(jù)塊和回滾段重構(gòu)出一個(gè)當(dāng)時(shí)適用的前鏡像來(lái)rollback。當(dāng)一個(gè)重做日志文件寫(xiě)滿后，LGWR將切換到下一個(gè)重做日志文件，重做日志文件也是循環(huán)工作方式。如果是歸檔模式，歸檔進(jìn)程還將前一個(gè)寫(xiě)滿的重做日志進(jìn)程寫(xiě)入歸檔日志文件。當(dāng)DB BUFFER改寫(xiě)之后，服務(wù)器進(jìn)程在臟數(shù)據(jù)列表中建立一條指向此DB BUFFER緩沖塊的指針。接著服務(wù)器進(jìn)程會(huì)從數(shù)據(jù)文件讀入第二個(gè)數(shù)據(jù)塊(db block)重復(fù)以上讀入，建立回滾段，寫(xiě)LOG BUFFER，改寫(xiě)DB BUFFER，放入臟列表的動(dòng)作，當(dāng)臟數(shù)據(jù)列表達(dá)到一定長(zhǎng)度時(shí)，DBWN進(jìn)程將臟數(shù)據(jù)列表中指向的緩沖塊全部寫(xiě)入數(shù)據(jù)文件，也就是釋放加在這些DB BUFER塊上的鎖存器，并在修改相應(yīng)塊的頭部的SCN號(hào)（一次UPDATE操作只對(duì)應(yīng)一個(gè)SCN）。前面說(shuō)過(guò)DBWN動(dòng)作之前會(huì)先觸發(fā)LGWR，這用以確保寫(xiě)入數(shù)據(jù)文件的改變首先會(huì)被記錄在日志文件中。實(shí)際上ORACLE可以從數(shù)據(jù)文件中一次讀入多個(gè)塊放入DB BUFFER，然后再對(duì)這些塊建回滾段、再記日志等等，也就是每次操作的對(duì)象是DB BLOCK的復(fù)數(shù)，而不僅限于一次操作一個(gè)DB BLOCK，可以通過(guò)參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT來(lái)設(shè)置一次讀入的塊的個(gè)數(shù)。注意，不管是否提交，用戶的所有更改都會(huì)被記錄在日志文件中，用戶級(jí)回滾的動(dòng)作（rollback）沒(méi)有對(duì)應(yīng)的COMMIT SCN。在密集事務(wù)的情況下,LGWR可以把多個(gè)COMMIT產(chǎn)生的REDO條目批量寫(xiě)入REDO LOG FILE，但每個(gè)COMMIT之間有十分之一秒的間隔，且會(huì)產(chǎn)生不同的COMMIT SCN。LGWR正常情況下是一個(gè)休眠進(jìn)程,會(huì)被一定的條件觸發(fā),喚醒,比如COMMIT就是一個(gè)喚醒條件，一旦LGWR被喚醒，LGWR將把喚醒時(shí)間點(diǎn)之前LOG BUFFER中產(chǎn)生的所有內(nèi)容(從上次LGWR喚醒后到本次喚醒前之間寫(xiě)入LOG BUFFER的內(nèi)容)寫(xiě)入LOG FILE，直到LGWR完成后，LGWR才可以被再次觸發(fā)，在LGWR觸發(fā)到完成期間所有對(duì)數(shù)據(jù)庫(kù)的操作仍然可以不間斷的加入LOG BUFFER。在這段時(shí)間內(nèi)，LGWR不再接收其它條件的觸發(fā)，比如緊跟前一個(gè)COMMIT之后的其它COMMIT（復(fù)數(shù)）都要等待LGWR完成后才可以再次觸發(fā)LGWR，并在LGWR下次被觸發(fā)時(shí)，將積累的REDO BUFFER條目一次性寫(xiě)入REDO LOG，后繼的COMMIT不會(huì)單個(gè)單個(gè)的觸發(fā)LGWR。如果要查找的數(shù)據(jù)已緩存，則根據(jù)用戶的SQL操作類型決定如何操作，如果是SELECT則查看DB BUFFER塊的頭部是否有事務(wù)，如果有，將利用回滾段進(jìn)行重構(gòu)出一致性塊再讀取，如果沒(méi)有則比較SELECT的SCN與DB BUFFER塊頭部的SCN如果比自己大，仍然同上，如果比自己小則認(rèn)這是一個(gè)非臟緩存，可以直接從這個(gè)DB BUFFER塊中讀取。如果是UPDATE則即使在DB BUFFER中找到一個(gè)沒(méi)有事務(wù)，而且SCN比自己小的非臟緩存數(shù)據(jù)塊，服務(wù)器進(jìn)程仍然要到表的頭部對(duì)這條記錄申請(qǐng)加鎖，加鎖成功則進(jìn)行后續(xù)動(dòng)作，如果不成功，則要等待前面的進(jìn)程解鎖后才能進(jìn)行動(dòng)作。ORACLE的工作機(jī)制-3肖亞峰(xyf_tck)只有當(dāng)SQL語(yǔ)句影響的所有行所在的最后一個(gè)塊被讀入DB BUFFER并且重做信息被寫(xiě)入REDO LOG BUFFER（僅是指重做日志緩沖，而非重做日志文件）之后，用戶才可以發(fā)出COMMIT，COMMIT觸發(fā)LGRW，但并不強(qiáng)制立即DBWN來(lái)釋放所有相應(yīng)的DB BUFFER塊上的鎖，也就是說(shuō)有可能出現(xiàn)已COMMIT，但在隨后的一段時(shí)間內(nèi)DBWN還在寫(xiě)這條語(yǔ)句涉及的數(shù)據(jù)塊的情形，表頭部的行鎖，并不是在COMMIT一發(fā)出就馬上釋放，實(shí)際上要等到相應(yīng)的DBWN進(jìn)程結(jié)束才會(huì)釋放。一個(gè)用戶請(qǐng)求鎖定另一個(gè)用戶已COMMIT的資源不成功的機(jī)會(huì)是存在的。COMMIT發(fā)出后會(huì)將回滾段中的前映像標(biāo)識(shí)為已提交.DML語(yǔ)句會(huì)產(chǎn)生一個(gè)SCN號(hào)，DBWN觸發(fā)時(shí)寫(xiě)入到數(shù)據(jù)塊的頭部，COMMIT時(shí)也會(huì)產(chǎn)生一個(gè)SCN號(hào)，也會(huì)被寫(xiě)入數(shù)據(jù)塊的頭部。在數(shù)據(jù)塊的頭部只存儲(chǔ)一個(gè)最新的SCN號(hào)，COMMIT之后這個(gè)事務(wù)插槽可以被另外一個(gè)事務(wù)使用。如果用戶ROOLBACK，則服務(wù)器進(jìn)程會(huì)根據(jù)數(shù)據(jù)文件塊和DB BUFFER中塊的頭部的事務(wù)列表和SCN以及回滾段地址重構(gòu)出相應(yīng)的修改前的副本，并且用這些原值來(lái)還原當(dāng)前數(shù)據(jù)文件中已修改但未提交的改變。如果有多個(gè)前映像，服務(wù)器進(jìn)程會(huì)在一個(gè)前映像的頭部找到前前映像的回滾段地址，一直重構(gòu)出同一事務(wù)下的最早的一個(gè)前映像為止。一旦發(fā)出了COMMIT，用戶就不能ROLLBACK，這使得COMMIT后DBWN進(jìn)程還沒(méi)有全部完成的后續(xù)動(dòng)作得到了保障。下面我們要提到檢查點(diǎn)的作用，ckpt的觸發(fā)，有以下幾種情況：1.當(dāng)發(fā)生日志組切換的時(shí)候2.當(dāng)滿足log_checkpoint_timeout、log_checkpoint_interval、fast_start_io_target、fast_start_mttr_target參數(shù)設(shè)置的時(shí)候3.當(dāng)運(yùn)行alter system switchlogfile的時(shí)候4.當(dāng)運(yùn)行alter systemckeckpoint的時(shí)候5.當(dāng)運(yùn)行alter tablespacetbs_name begin backupend backup的時(shí)候6.當(dāng)運(yùn)行alter tablespacedatafile offline的時(shí)候7.系統(tǒng)正常關(guān)閉時(shí)只有在4.7兩種情況下發(fā)生完全檢查點(diǎn)。發(fā)生完全檢查點(diǎn)時(shí)，首先系統(tǒng)記錄檢查點(diǎn)對(duì)應(yīng)的Checkpoint SCN，并記錄下該時(shí)刻修改的DB BUFFER對(duì)應(yīng)的日志文件的最新的重做字節(jié)地址（Redo Byte Address (RBA)），然后DBWN進(jìn)程將這個(gè)重做字節(jié)地址（RBA）之前已發(fā)生的DB BUFFER中的臟緩沖寫(xiě)入數(shù)據(jù)文件（之所以要以重做字節(jié)地址（RBA）為標(biāo)志是因?yàn)樵跈z查點(diǎn)發(fā)生到檢查點(diǎn)完成之間的時(shí)間內(nèi)，系統(tǒng)還在一直不斷的產(chǎn)生修改，這些修改所產(chǎn)生的DB BUFFER臟緩沖，以及日志條目將不會(huì)影響這次檢查點(diǎn)最后確認(rèn)的一致性結(jié)果，也就是最后確認(rèn)這個(gè)Checkpoint SCN之前的系統(tǒng)是一致的）。最后把Checkpoint SCN和RBA更新至控制文件，Checkpoint SCN更新至每個(gè)數(shù)據(jù)文件頭部，表明當(dāng)前數(shù)據(jù)庫(kù)是一致的。日志切換并不導(dǎo)致一個(gè)完全檢點(diǎn)的發(fā)生，比如有三個(gè)日志文件組,當(dāng)發(fā)生日志切換時(shí)發(fā)生檢查點(diǎn),而發(fā)生日志切換一般是因?yàn)楫?dāng)前的LGWR正在寫(xiě)重做日志,也就是LGWR當(dāng)剛寫(xiě)滿2號(hào)日志就立即觸發(fā)檢查點(diǎn),于是系統(tǒng)開(kāi)始核對(duì)3號(hào)日志中記錄的REDO項(xiàng)目所對(duì)應(yīng)的數(shù)據(jù)是否已經(jīng)從DB BUFFER中寫(xiě)入數(shù)據(jù)文件(不管事務(wù)是否已提交),如果沒(méi)有寫(xiě)入,檢查點(diǎn)就觸發(fā)DBWN進(jìn)程將這些緩沖塊寫(xiě)入數(shù)據(jù)文件,顯然LGWR因此而發(fā)生等待,除此以外,檢查點(diǎn)還讓DBWN進(jìn)程將在2號(hào)日志中對(duì)應(yīng)修改的DB BUFFER塊寫(xiě)入數(shù)據(jù)文件,然后繼續(xù)LGWR進(jìn)程,直到LGWR進(jìn)程將LGWR觸發(fā)之前存在于REDO LOG BUFFER中的所有緩沖（包含未提交的重做信息）寫(xiě)入重做日志文件,檢查點(diǎn)再更新數(shù)據(jù)文件,控制文件頭部SCN。其實(shí)LGWR等待的并不是CKPT的完成，而是等待CKPT觸發(fā)的DBWN進(jìn)程的完成?？梢韵胂駭嚯姇r(shí)可能既有未COMMIT的事務(wù)，也可能同時(shí)存在已COMMIT但DBWN未完成的情況，如果斷電時(shí)有一個(gè)已COMMIT但DBWN動(dòng)作沒(méi)有完成的情況存在，因?yàn)橐呀?jīng)COMMIT，COMMIT會(huì)觸發(fā)LGWR進(jìn)程，所以不管DBWN動(dòng)作是否已完成，該語(yǔ)句將要影響的行及其產(chǎn)生的結(jié)果一定已經(jīng)記錄在重做日志文件中了，則實(shí)例重啟后，SMON進(jìn)程從控制文件中記錄的上一次重做字節(jié)地址（RBA）開(kāi)始，按照重做日志文件中的條目對(duì)數(shù)據(jù)文件和回滾段重新做一遍即前滾，注意這些條目的操作在斷電之前有的已經(jīng)被DBWN寫(xiě)入了數(shù)據(jù)文件，有的還沒(méi)有來(lái)得及寫(xiě)，不管有沒(méi)有寫(xiě)進(jìn)數(shù)據(jù)文件，前滾時(shí)都會(huì)再重新寫(xiě)一次（9I之前是這樣的），9I之后，由于也在日志中記錄了DBWN改寫(xiě)的塊信息，系統(tǒng)會(huì)過(guò)濾掉已寫(xiě)入的條目而只重做那些未寫(xiě)入的條目。對(duì)于一個(gè)未提交事務(wù)，分幾種情況來(lái)描述：1）LGWR與DBWN一致的情況即一個(gè)語(yǔ)句執(zhí)行完成后很長(zhǎng)時(shí)間也沒(méi)有COMMIT，這種情況一般不存在DBWN來(lái)不及完成的情況。只是沒(méi)有COMMIT而已。那么SMON將在前滾完成后,利用回滾段重構(gòu)出具有最小SCN的前映像,并把它的值寫(xiě)回原位。2）事務(wù)執(zhí)行中斷電，即可能存在LGWR與DBWN不同步的情況（因?yàn)镈BWN之前會(huì)觸發(fā)LGWR，所以DBWN對(duì)數(shù)據(jù)文件的修改一定會(huì)被先記錄在重做日志文件中。因此只可能存在已寫(xiě)入重做日志而未來(lái)得及寫(xiě)入數(shù)據(jù)文件的情況存在。而不可能存在已寫(xiě)入數(shù)據(jù)文件卻沒(méi)有寫(xiě)入日志文件的情況。），這種情況下SMON也會(huì)先前滾一點(diǎn)（即把數(shù)據(jù)文件與相應(yīng)的日志文件先同步再回滾，之所以說(shuō)前滾一點(diǎn)，是指僅LGWR與DBWN之間進(jìn)度的差距，而不是把這條語(yǔ)句進(jìn)行到底再回滾，因?yàn)槿罩疚募杏涗浀氖菆?zhí)行語(yǔ)句操作的一個(gè)個(gè)塊的修改信息，而不只是記錄一條執(zhí)行語(yǔ)句的字面內(nèi)容），然后利用回滾段重構(gòu)出具有最小SCN的前映像,并把它的值寫(xiě)回原位。由此可見(jiàn)，實(shí)例失敗后用于恢復(fù)的時(shí)間由兩個(gè)檢查點(diǎn)之間的間隔大小來(lái)決定，我們可以通個(gè)四個(gè)參數(shù)設(shè)置檢查點(diǎn)執(zhí)行的頻率，LOG_CHECKPOINT_IMTERVAL決定了兩個(gè)檢查點(diǎn)之間寫(xiě)入重做日志文件的系統(tǒng)物理塊的大小，LOG_CHECKPOINT_TIMEOUT決定了兩個(gè)檢查點(diǎn)之間的時(shí)間長(zhǎng)度，F(xiàn)AST_START_IO_TARGET決定了用于恢復(fù)時(shí)需要處理的塊的大小，F(xiàn)AST_START_MTTR_TARGET直接決定了用于恢復(fù)的時(shí)間的長(zhǎng)短。檢查點(diǎn)的作用就是不斷的確認(rèn)LGWR與DBWN之間的同步情況，以便實(shí)例失敗后從上一個(gè)檢查點(diǎn)開(kāi)始恢復(fù)，問(wèn)題是兩個(gè)檢查點(diǎn)之間LGWR與DBWN大部分的操作是同步的，只是一小部分沒(méi)有同步，這種傳統(tǒng)的檢查點(diǎn)使實(shí)例恢復(fù)做了比較多的無(wú)用功，因此，ORACLE引入了增量檢查點(diǎn)，增量檢查點(diǎn)會(huì)在上一次傳統(tǒng)檢查點(diǎn)發(fā)生后到下一次傳統(tǒng)檢查點(diǎn)發(fā)生之前，不斷的更新記錄在控制文件中重做字節(jié)地址（RBA）（CKPT進(jìn)程每三秒更新一次，見(jiàn)下面DBWN講述），這樣實(shí)例失敗后將直接從控制文件中記錄的最后更新的重做字節(jié)地址（RBA）開(kāi)始進(jìn)行前滾和回滾，這就省略掉了恢復(fù)時(shí)大部份的重做日志的重做（即使在9I以后的版本里也省略掉了大部分的過(guò)濾重做日志條目的時(shí)間）。（對(duì)以上描述做一個(gè)簡(jiǎn)單的比喻：比如一個(gè)貿(mào)易公司下設(shè)經(jīng)營(yíng)部、貨運(yùn)部、監(jiān)督部，經(jīng)營(yíng)部負(fù)責(zé)貿(mào)易合同的簽訂與記錄，貨運(yùn)部負(fù)責(zé)按合同號(hào)的順序把貨物送達(dá)，監(jiān)督部負(fù)責(zé)定期檢查確認(rèn)經(jīng)營(yíng)部簽訂的合同與貨運(yùn)部貨物送達(dá)情況之間的同步情況，監(jiān)督部每月檢查一次，每次檢查時(shí)，先確認(rèn)當(dāng)時(shí)正在裝車的貨物的合同號(hào)，并要求貨運(yùn)部把在這個(gè)合同號(hào)之前的所有還存在臨時(shí)倉(cāng)庫(kù)中的未送貨物全部送達(dá)。等貨運(yùn)部完成監(jiān)督部下達(dá)的任務(wù)后，監(jiān)督部在檢查本上記錄下本次開(kāi)始檢查時(shí)那票正在裝車的貨物的合同號(hào)，本次檢查完成。如果這個(gè)公司發(fā)生了一次人事大換血，公司重新開(kāi)業(yè)后，監(jiān)督部就會(huì)從檢查本上記錄的合同號(hào)開(kāi)始，檢查在這之后所有發(fā)生的合同及貨物送達(dá)情況，要求貨運(yùn)部把所有客戶確認(rèn)的但還未送達(dá)的貨物送達(dá)。把所有客戶未確認(rèn)的貨物收回。監(jiān)督部發(fā)現(xiàn)這次重新開(kāi)業(yè)后的工作量實(shí)在是太大了，幾乎核對(duì)了整整一個(gè)月的幾萬(wàn)單合同（好在不是半年檢查一次_），為了防止今后出現(xiàn)這種情況，監(jiān)督部增加了一項(xiàng)工作內(nèi)容，每三天派人去記錄一下貨運(yùn)部正在裝車的那票貨的合同號(hào)，今后如果發(fā)生類似情況，監(jiān)督部就從最后一次記錄的合同號(hào)開(kāi)始核對(duì)，這樣工作量就小多了。）ORACLE的工作機(jī)制-4肖亞峰(xyf_tck)在這里我們要說(shuō)一下回滾段存儲(chǔ)的數(shù)據(jù)，假如是delete操作，則回滾段將會(huì)記錄整個(gè)行的數(shù)據(jù)，假如是update,則回滾段只記錄行被修改了的字段的變化前的數(shù)據(jù)（前映像），也就是沒(méi)有被修改的字段是不會(huì)被記錄的，假如是insert，則回滾段只記錄插入記錄的rowid。這樣假如事務(wù)提交，那回滾段中簡(jiǎn)單標(biāo)記該事務(wù)已經(jīng)提交；假如是回退，則如果操作是delete,回退的時(shí)候把回滾段中數(shù)據(jù)重新寫(xiě)回?cái)?shù)據(jù)塊，操作如果是update，則把變化前數(shù)據(jù)修改回去，操作如果是insert，則根據(jù)記錄的rowid把該記錄刪除。注意，檢查點(diǎn)除了觸發(fā)LGWR和DBWN向數(shù)據(jù)塊頭部寫(xiě)SCN和COMMIT SCN，檢查點(diǎn)還向控制文件和數(shù)據(jù)文件頭部寫(xiě)SCN，而用戶的DML和COMMIT僅是向數(shù)據(jù)塊頭部寫(xiě)SCN和COMMIT SCN而不更新控制文件和數(shù)據(jù)文件的SCN，SMON的前滾是以文件頭部的SCN為起始點(diǎn)的也就是從前一個(gè)檢查點(diǎn)開(kāi)始，SMON的回滾是回滾所有回滾段中未標(biāo)識(shí)為已提交的數(shù)據(jù)塊，用戶的回滾是回滾與此事務(wù)有關(guān)的回滾段中未標(biāo)識(shí)為已提交的數(shù)據(jù)塊。下面我們要講DBWN如何來(lái)寫(xiě)數(shù)據(jù)文件，在寫(xiě)數(shù)據(jù)文件前首先要找到可寫(xiě)的空閑數(shù)據(jù)塊，ORACLE中空閑數(shù)據(jù)塊可以通過(guò)FREELIST或BITMAP來(lái)維護(hù)，它們位于一個(gè)段的頭部用來(lái)標(biāo)識(shí)當(dāng)前段中哪些數(shù)據(jù)塊可以進(jìn)行INSERT。在本地管理表空間中ORACLE自動(dòng)管理分配給段的區(qū)的大小，只在本地管理的表空間中才能選用段自動(dòng)管理，采用自動(dòng)段空間管理的本地管理表空間中的段中的空閑數(shù)據(jù)塊的信息就存放在段中某些區(qū)的頭部，使用位圖來(lái)管理（最普通的情況是一個(gè)段的第一個(gè)區(qū)的第一個(gè)塊為FIRST LEVEL BITMAP BLOCK，第二個(gè)塊為SECOND LEVEL BITMAP BLOCK，第三個(gè)塊為PAGETABLE SEGMENT HEADER，再下面的塊為記錄數(shù)據(jù)的數(shù)據(jù)塊，F(xiàn)IRST LEVEL BITMAP BLOCK的父數(shù)據(jù)塊地址指向SECOND LEVEL BITMAP BLOCK，SECOND LEVEL BITMAP BLOCK的父數(shù)據(jù)塊地址指向PAGETABLE SEGMENT HEADER，F(xiàn)IRST LEVEL BITMAP BLOCK記錄了它所管理的所有塊（包括頭部三個(gè)塊，不僅僅指數(shù)據(jù)塊）的狀態(tài)，標(biāo)識(shí)的狀態(tài)有Metadata、75-100% free、50-75% free、25-50% free、0-25% free、full、unformatted，在SECOND LEVEL BITMAP BLOCK中有一個(gè)列表，記錄了它管理的FIRST LEVEL BITMAP BLOCK，PAGETABLE SEGMENT HEADER中記錄的內(nèi)容比較多，除了記錄了它管理的SECOND LEVEL BITMAP BLOCK，還記錄了各個(gè)區(qū)的首塊地址以及各個(gè)區(qū)的DB BLOCK的個(gè)數(shù)，段的各個(gè)區(qū)所對(duì)應(yīng)的FIRST LEVEL BITMAP BLOCK的塊地址以及區(qū)里面記錄數(shù)據(jù)的數(shù)據(jù)塊的起始地址。如果一個(gè)區(qū)擁有很多塊，這時(shí)會(huì)在一個(gè)區(qū)里出現(xiàn)兩個(gè)或多個(gè)FIRST LEVEL BITMAP BLOCK，這些FIRST LEVEL BITMAP BLOCK分別管理一個(gè)區(qū)中的一些塊，當(dāng)區(qū)的數(shù)據(jù)塊比較少時(shí)，一個(gè)區(qū)的FIRST LEVEL BITMAP BLOCK可以跨區(qū)管理多個(gè)區(qū)的數(shù)據(jù)塊，BITMAP BOLCK最多為三級(jí)）。采用手動(dòng)管理的本地管理表空間中的段和數(shù)據(jù)字典管理的表空間中的段中的空閑數(shù)據(jù)塊的管理都使用位于段頭部的空閑列表來(lái)管理，例如SYSTEM表空間是本地管理表空間，但是它是采用了手動(dòng)段空間管理，所以也是用FREELIST來(lái)管理段中的空閑數(shù)據(jù)塊的?？臻e列表是一個(gè)邏輯上的鏈表，在段的HEADER BLOCK中記錄了一個(gè)指向第一個(gè)空閑塊的BLOCK ADDRESS，第一個(gè)DB BLOCK中同時(shí)也記錄了指向下一個(gè)空閑塊的BLOCK ADDRESS。以此形成一個(gè)單向鏈表。如果段上有兩個(gè)FREE LIST則會(huì)在段頭部的HEADER BLOCK存有兩個(gè)指針?lè)謩e指向兩個(gè)空閑塊并建立獨(dú)立的兩個(gè)單向鏈表?？臻e列表的工作方式：首先當(dāng)建立一個(gè)段時(shí)，初始分配的第一個(gè)區(qū)的第一個(gè)塊會(huì)成為段的頭塊，初始分配的第一個(gè)區(qū)的其它塊將全部加入空閑列表，再次擴(kuò)展一個(gè)區(qū)時(shí)，這個(gè)區(qū)中的塊立即全部加入空閑列表，擴(kuò)展一次加入一次。與位圖管理不同的是用空閑列表時(shí)區(qū)的頭部將不記錄區(qū)里面空閑塊的信息。當(dāng)其中空閑空間小于PCTFREE設(shè)置的值之后，這個(gè)塊從空閑列表刪除，即上一個(gè)指向它的塊中記錄的下一個(gè)空閑塊地址更改為其它空閑塊的地址，使得這個(gè)塊類似于被短路，當(dāng)這個(gè)塊中的內(nèi)容降至PCTUSED設(shè)置的值之下后，這個(gè)數(shù)據(jù)塊被再次加入空閑列表，而且是加入到空閑列表前端，即頭塊直接指向它，它再指向原頭塊指向的空閑塊，位于空閑列表中的數(shù)據(jù)塊都是可以向其中INSERT的塊，但是INSERT都是從空閑列表指向的第一個(gè)塊開(kāi)始插入，當(dāng)一個(gè)塊移出了空閑列表，但只要其中還有保留空間就可以進(jìn)行UPDATE，當(dāng)對(duì)其中一行UPDATE一個(gè)大數(shù)據(jù)時(shí)，如果當(dāng)前塊不能完全放下整個(gè)行，只會(huì)把整個(gè)行遷移到一個(gè)新的數(shù)據(jù)塊，并在原塊位置留下一個(gè)指向新塊的指針，這叫行遷移。如果一個(gè)數(shù)據(jù)塊可以INSERT，當(dāng)插入一個(gè)當(dāng)前塊裝不下的行時(shí)，這個(gè)行會(huì)溢出到兩個(gè)或兩個(gè)幾上的塊中，這叫行鏈接。如果用戶的動(dòng)作是INSERT則服務(wù)器進(jìn)程會(huì)先鎖定FREELIST，然后找到第一個(gè)空閑塊的地址，再釋放FREELIST，當(dāng)多個(gè)服務(wù)器進(jìn)程同時(shí)想要鎖定FREELIST時(shí)即發(fā)生FREELIST的爭(zhēng)用，也就是說(shuō)多個(gè)進(jìn)程只在同時(shí)INSERT時(shí)才會(huì)發(fā)生FREELIST爭(zhēng)用，可以在非采用自動(dòng)段空間管理的表空間中創(chuàng)建表時(shí)指定FREELIST的個(gè)數(shù)，默認(rèn)為1，如果是在采用自動(dòng)段空間管理的表空間中創(chuàng)建表，即使指定了FREELIST也會(huì)被忽略，因?yàn)榇藭r(shí)將使用BITMAP而不是FREELIST來(lái)管理段中的空閑空間。采用自動(dòng)段空間管理還會(huì)忽略的參數(shù)有PCTUSED和FREELIST GROUPS。如果用戶動(dòng)作是UPDATE或DELETE等其它操作，服務(wù)器進(jìn)程將不會(huì)使用到FREELIST和BITMAP，因?yàn)椴灰ふ乙粋€(gè)空閑塊，而使用鎖的隊(duì)列。對(duì)數(shù)據(jù)塊中數(shù)據(jù)操作必須使用transaction entries，即事務(wù)入口。在建立段時(shí)我們可以通過(guò)MINTRANS和MAXTRANS參數(shù)指定它的最大值和最小值，MAXTRANS規(guī)定了在段中每一個(gè)塊上最大并發(fā)事務(wù)數(shù)量，可以輸入1到255之間的值。我們可以把它比喻為是一些長(zhǎng)在塊頭部的事務(wù)插座，每個(gè)插座后面是一個(gè)可以伸縮的操作手，當(dāng)事務(wù)進(jìn)程插到一個(gè)插座上時(shí)相當(dāng)于找到一個(gè)可以操作數(shù)據(jù)塊中數(shù)據(jù)行的操作手，通過(guò)這個(gè)操作手，事務(wù)進(jìn)程可以對(duì)塊中數(shù)據(jù)進(jìn)行INSERT、UPDATE、DELETE等操作。在沒(méi)有超過(guò)MAXTRANS設(shè)定的最大值時(shí)，如果transaction entries不夠用，則會(huì)在塊上自動(dòng)分配一個(gè)，但不會(huì)影響其它塊中的transaction entries數(shù)量。只不過(guò)INSERT操作必須要先找到空閑塊然后才能INSERT。那么DBWN是根據(jù)什么順序來(lái)寫(xiě)DB BUFFER中的臟數(shù)據(jù)的呢？ORACLE從8I開(kāi)始加入新的數(shù)據(jù)結(jié)構(gòu)-檢查點(diǎn)隊(duì)列(Buffer Checkpoint Queue)。檢查點(diǎn)隊(duì)列是一個(gè)鏈接隊(duì)列。這個(gè)隊(duì)列的按照Buffer塊第一次被修改的順序排列，分別指向被修改的Buffer塊。在DB_Buffer中的數(shù)據(jù)被第一次被修改時(shí)，會(huì)記錄所生成的REDO LOG條目的位置RBA作為該Buffer的Low RBA，記錄在該Buffer的頭部（Buffer Header），如果該數(shù)據(jù)繼續(xù)被修改，則把該塊修改的最新的REDO LOG的RBA作為High RBA記錄在該Buffer的頭部。如果DB_Buffer中的塊沒(méi)有被修改的數(shù)據(jù)，則該塊的頭部不會(huì)有Low RBA和High RBA的信息。檢查點(diǎn)隊(duì)列按照被修改塊的Low RBA的遞增值鏈接修改塊，沒(méi)有被修改的塊因?yàn)闆](méi)有Low RBA，而不會(huì)加入到檢查點(diǎn)隊(duì)列中。在沒(méi)有檢查點(diǎn)發(fā)生時(shí)DBWR就按照檢查點(diǎn)隊(duì)列的Low RBA的升序，將被修改的塊寫(xiě)入到數(shù)據(jù)文件中。當(dāng)塊被寫(xiě)入到數(shù)據(jù)文件后，該塊會(huì)從檢查點(diǎn)隊(duì)列中斷開(kāi)。DBWR繼續(xù)寫(xiě)下一個(gè)塊。CKPT進(jìn)程每三秒記錄檢查點(diǎn)隊(duì)列中對(duì)應(yīng)的最小Low RBA到控制文件中，也就是更新控制文件中的CheckPointRBA，當(dāng)實(shí)例崩潰時(shí)，恢復(fù)將從CheckPointRBA所指向的日志位置開(kāi)始。這就是增量檢查點(diǎn)的行為和定義。CKPT進(jìn)程也會(huì)記錄檢查點(diǎn)位置到數(shù)據(jù)文件的頭部，但是只是日志切換時(shí)才寫(xiě)。而不是每三秒。當(dāng)檢查點(diǎn)發(fā)生時(shí)，DBWN不會(huì)一直不停的寫(xiě)DB BUFFER中臟數(shù)據(jù)，它將寫(xiě)到檢查點(diǎn)隊(duì)列的開(kāi)始?jí)K的Low RBA的值大于該檢查點(diǎn)的Checkpoint RBA的值時(shí)停止寫(xiě)入，然后完成這次檢查點(diǎn)，CKPT進(jìn)程將記錄該檢查點(diǎn)的有關(guān)信息到控制文件中去。 ORACLE的工作機(jī)制-5肖亞峰(xyf_tck)下面來(lái)講一下ORACLE鎖的機(jī)制，分鎖存器和鎖兩種。鎖存器是用來(lái)保護(hù)對(duì)內(nèi)存結(jié)構(gòu)的訪問(wèn)，比如對(duì)DB BUFFER中塊的鎖存器申請(qǐng)，只有在DBWN完成后，這些DB BUFFER塊被解鎖。然后用于其它的申請(qǐng)。鎖存器不可以在進(jìn)程間共享，鎖存器的申請(qǐng)要么成功要么失敗，沒(méi)有鎖存器申請(qǐng)隊(duì)列。主要的鎖存器有SHARED POOL鎖存器，LIBRARY CACHE鎖存器，CACHE BUFFERS LRU CHAIN鎖存器，CACHE BUFFERS CHAINS鎖存器，REDO ALLOCATION鎖存器，REDO COPY鎖存器。ORACLE的鎖是用來(lái)保護(hù)數(shù)據(jù)訪問(wèn)的，鎖的限制比鎖存器要更寬松，比如，多個(gè)用戶在修改同一表的不同行時(shí)，可以共享一個(gè)表上的一個(gè)鎖，鎖的申請(qǐng)可以按照被申請(qǐng)的順序來(lái)排隊(duì)等候，然后依次應(yīng)用，這種排隊(duì)機(jī)制叫做隊(duì)列（ENPUEUE），如果兩個(gè)服務(wù)器進(jìn)程試圖對(duì)同一表的同一行進(jìn)行加鎖，則都進(jìn)入鎖的申請(qǐng)隊(duì)列，先進(jìn)的加鎖成功，后面的進(jìn)程要等待，直到前一個(gè)進(jìn)程解鎖才可以加鎖，這叫做鎖的爭(zhēng)用，而且一旦加鎖成功，這個(gè)鎖將一直保持到用戶發(fā)出COMMIT或ROOLBACK命令為止。如果兩個(gè)用戶鎖定各自的一行并請(qǐng)求對(duì)方鎖定的行的時(shí)候?qū)l(fā)生無(wú)限期等待即死鎖，死鎖的發(fā)生都是由于鎖的爭(zhēng)用而不是鎖存器的爭(zhēng)用引起的，ORACLE在遇到死鎖時(shí)，自動(dòng)釋放其中一個(gè)用戶的鎖并回滾此用戶的改變。正常情況下發(fā)生鎖的爭(zhēng)用時(shí)，數(shù)據(jù)的最終保存結(jié)果由SCN來(lái)決定哪個(gè)進(jìn)程的更改被最終保存。兩個(gè)用戶的服務(wù)器進(jìn)程在申請(qǐng)同一表的多個(gè)行的鎖的時(shí)候是可以交錯(cuò)進(jìn)入鎖的申請(qǐng)隊(duì)列的。只有其中發(fā)生爭(zhēng)用才會(huì)進(jìn)行等待。創(chuàng)建表時(shí)指定的MAXTRANS參數(shù)決定了表中的一個(gè)數(shù)據(jù)塊同時(shí)最多可以被幾個(gè)事務(wù)鎖定。下面來(lái)講一下ORACLE的讀一致性機(jī)制，ORACLE的讀一致性保證了事務(wù)之間的高度隔離性。下面是幾個(gè)關(guān)于回滾段讀一致性和死鎖的事例：有表：Test (id number(10) 有記錄1000000條SQL create table test (idnumber(10)tablespaceusers;表已創(chuàng)建。SQL begin2 foriin 1.1000000 loop3 insertinto test values(i);4 endloop;5 commit;6 end;7 /PL/SQL過(guò)程已成功完成一，大SELECT，小UPDATEA會(huì)話-Select * from test;-設(shè)scn=101-執(zhí)行時(shí)間09:10:11B會(huì)話-Update test set id=9999999 where id=1000000-設(shè)scn=102-執(zhí)行時(shí)間09:10:12我們會(huì)發(fā)現(xiàn)B會(huì)話會(huì)在A會(huì)話前完成，A會(huì)話中顯示的ID=100000是從回滾段中讀取的，因?yàn)锳會(huì)話在讀到ID=1000000所在的BLOCK時(shí)發(fā)現(xiàn)BLOCK上有事務(wù)信息，因