1、課后總結一、Oracle 運行機制一、用戶與ORACLE 的連接方式用戶進程發出連接請求，請求通過 DNS 效勞器或 HOST 文件的效勞名解析后傳送到 ORACLE 監聽進程，監聽進程一樣用兩種方式來處置用戶請求，咱們將在兩種不同效勞器中分析：在專用效勞器模式下， 一種方式是監聽進程收到用戶請求后產生一個新的專用效勞器進程， 新建的效勞器進程繼承了監聽進程的信息，效勞器進程發一個 RESEND 包給用戶進程，用戶進程接收到那么回發一個 CONNECT 包，效勞器進程再以 ACCEPT 包回應，二者之間確信 HAND-OFF 連接也稱轉換連接。另一種方式是監聽進程收到用戶進程的請求后產生一個新

2、的專用效勞器進程，新建的效勞器進程選用一個 TCP/IP 端口來操縱與用戶進程的交互， 然后將此信息傳回監聽進程， 監聽進程再將此信息傳給用戶進程， 用戶進程利用那個端口給新建的效勞器進程發送一個 CONNECT 包，效勞器進程回發用戶進程一個ACCEPT 包，至此成立連接，也稱重定向連接。在共享效勞器下 ，只有重定向連 接的方式。通過 設置MAX_DISPIATCHERS來確信調度進程的最大數量，假設個數達到最大，或已有的調度進程不是滿負荷，監聽進程將再也不創建新的調度進程，而是讓其中一個調度進程需用一個TCP/IP端口來與用戶交互。 所有的調度進程共享同一個請求隊列，共享效勞器模式下一個實

3、例只有一個請求隊列，有多少調度進程就有多少相應隊列，然后各個調度進程從各自的響應隊列中將結果掏出再返回給用戶進程。二、 ORACLE 效勞器進程處置用戶進程請求的方式當一個用戶進程發出了一條SQL 語句，第一效勞器進程將對該語句進行檢查語句有效性的語法檢查和確保語句能夠正常運行的語義檢查，假設以上任一檢查未通過，就返回一個ORA-*的錯誤碼。假設檢查通過，效勞器進程把語句的字符轉換成 ASCII 等效數字碼，接著 ASCII 碼被傳遞給一個 HASH 函數，并返回一個 HASH 值，效勞器進程將到 SHARED POOL 的共享 PL/SQL 區去查找是不是存在一樣的 HASH 值，假設存在，

4、效勞器進程將在 SHARED POOL 中軟解析語句，假設不存在，那么在 SHARED POOL 中硬解析語句。 ORACLE 將這條語句的本身實際文本、 HASH 值、編譯代碼、 與語句相關的統計數據及其執行打算緩存在 SHARED POOL 的共享 PL/SQL 區。只要 DDL 更改了一個對象，所有與此有關的緩存在共享池中執行打 算 都 將 當 即 失 效 。 要緊 表 此 刻DDL發 生 后v$sql的HASH_VALUE 仍維持不變，但 PLAN_HASH_VALUE 當即變成0,再次運行 SQL 語句時那么會向 v$sql 插入一條新的緩沖記錄 HASH_VALUE ，PLAN_H

5、ASH_VALUE 都從頭計算。 原先的緩沖記錄仍然還存在。被 SHAREDPOOL 鎖存器鎖定的PL/SQL 區中的塊不可被覆蓋，因為這些塊可能正在被其它進程所利用。、編譯以后的更新數據方式效勞器進程將到DB BUFFER 中查找是不是有相關對象的緩存數據，下面分兩個可能進行說明：假設沒有，效勞器進程將在表頭部請求一些行鎖，假設成功加鎖，效勞器進程將從數據文件中讀入行所在的第一個數據塊(dbblock) 放入 DB BUFFER 中的空閑區域或覆蓋已被擠出LRU 列表的非臟數據塊緩沖區，并排列在LRU 列表的頭部，在放入DBBUFFER 之前也是要先申請DB BUFFER 中的鎖存器，成功鎖

6、定后，再寫入DB BUFFER ，然后把那個塊的頭部事務列表及SCN信息及被阻礙的行數據原值寫入回滾段中，以便ORACLE在ROLLBACK時能夠利用當前數據塊和回滾段重構數據塊的前映像 或遞歸重構出 前前映像 來實現讀一致性。然后在LOGBUFFER中生成日記，效勞器程將該語句阻礙的被讀入DBBUFFER 塊中的這些行的ROWID及將要更新的原值和新值及SCN等信息,和回滾段的修改信息逐條寫入REDOLOGBUFFER。當寫入達到 REDO LOG BUFFER 大小的三分之一或寫入量達到 1M 或超過三秒后或發生檢查點時或 COMMIT 時或 DBWN 之前觸發 LGWR 進程，LGWR

7、將把 REDO LOG BUFFER中的數據寫入磁盤上的重做日記文件，已被寫入重做日記文件的REDO LOG BUFFER 中的塊上的鎖存器被釋放，并可被后來寫入的信息所覆蓋。在REDO 進程中利用即時重寫的數據塊和回滾段重構出一個那時適用的前鏡像來rollback 。當一個重做日記文件寫滿后， LGWR 將切換到下一個重做日記文件，重做日記文件也是循環工作方式。若是是歸檔模式， 歸檔進程還將前一個寫滿的重做日記進程寫入歸檔日記文件。當 DB BUFFER 改寫以后，效勞器進程在臟數據列表中成立一條指向此DB BUFFER 緩沖塊的指針。接著效勞器進程會從數據文件讀入第二個數據塊(dbbloc

8、k) 重復以上動作，當臟數據列表達到必然長度時，DBWN進程將臟數據列表中指向的緩沖塊全數寫入數據文件。DBWN動作之前會先觸發LGWR 。不管是不是提交， 用戶的所有更改都會被記錄在日記文件中。在密集事務的情形下,LGWR 能夠把多個 COMMIT 產生的 REDO 條款批量寫入 REDO LOG FILE ，但每一個 COMMIT 之間有十分之一秒的距離，且會產生不同的COMMIT SCN 。LGWR 正常情形下是一個休眠進程 ,會被必然的條件觸發 ,喚醒。緊跟前一個 COMMIT 以后的其它 COMMIT （復數）都要等待 LGWR 完成后才能夠再次觸發 LGWR ，并在 LGWR 下次

9、被觸發時，將積存的 REDO BUFFER 條款一次性寫入 REDO LOG ，后繼的 COMMIT 可不能單個單個的觸發 LGWR 。若已緩存， 那么依照用戶的SQL 操作類型決定如何操作，若是是 SELECT 那么查看 DB BUFFER 塊的頭部是不是有事務，若是有，將利用回滾段進行重構出一致性塊再讀取， 若是沒有那么比較 SELECT的 SCN 與 DB BUFFER 塊頭部的 SCN 若是比自己大，仍然同上， 若是比自己小那么認這是一個非臟緩存， 能夠直接從那個DBBUFFER塊中讀取。若是是UPDATE那么即便在DBBUFFER中找到一個沒有事務，而且SCN比自己小的非臟緩存數據塊

10、，效勞器進程仍然要到表的頭部對這條記錄申請加鎖，加鎖成功那么進行后續動作，若是不成功， 那么要等待前面的進程解鎖后才能進行動作。二、事務當在應用程序中執行第一條SQL 語句時，開始事務；當執行COMMIT或 ROLLBACK 語句時，終止事務。當執行事務操作 （DML 語句）時，Oracle 會被作用表上加表鎖，以避免其他用戶改變表結構；同時會在被作用行上加行鎖， 以避免其他事務在相應行上執行DML 操作。為了確保數據庫數據的讀一致性，不許諾其他用戶讀取臟數據（未提交數據）。假定會話 A 將雇員 SCOTT 工資修改成 2000 （未提交），那么其他會話將只能查詢到原先的工資。只有在會話A 提

11、交了事務以后，其他會話才能查詢到新工資。會話 A：UPDATE emp SET sal=2000WHERE ename=T om;會話 B：SELECT sal FROM emp WHERE ename=Tom;SAL-3000利用 COMMIT 語句能夠提交事務。當執行了 COMMIT 語句以后，會確認事務轉變，終止事務，刪除保留點，釋放鎖。當利用 COMMIT 語句終止事務以后，其他會話將能夠查看到事務轉變后的新數據。保留點（ savepoint ）是事務中的一點，用于取消部份事務。當終止事務時，會自動刪除該事務所概念的所有保留點。在執行 ROLLBACK 命令時，通過指定保留點能夠取消部份事務。設置保留點sacepoint a;或exec (a);取消部份事務rollback to a;或exec (a);取消全數事務rollback;或exec ；可不能取得新的數據轉變，從而確保取得特