oracle 體系結構初步認識（一）
剛開始學習oracle，記錄一下自己的學習筆記，如有錯誤，還望各位大牛多多指教。
首先先上一張oracle體系結構中相對比較重要的圖，如下
當我們輸入一條簡單的命令時候，例如第一次輸入update table_name t set t.a=30;當我們執行這一條sql的時候，我們這一條sql現在share pool（共享池）中的Data Dictionary cache（數據字典緩沖區）中進行語義語法分析，語法解析就是分析sql語句是否有問題，語義解析就是分析是否存在語句中相對應的表以及列，分析完之後將在Library Cache(庫高速緩存)產生相對應得執行計劃，這一個操作記錄也會緩存到Redo Log Buffer中，相對於更新的數據也會更新到Datebase Buffer Cache的髒塊中，當我們點擊commit的時候，將會觸發LGWR，將日志緩沖區寫到日志文件中，但是commit時並不會觸發DBWn，不會把相對應更新的數據寫到DBWn中，而這個時候數據庫down了，Data Dictionary cache更新的數據也會丟失，這時候我們是通過Redo Log files通過SMON恢復Redo Log Buffer中緩存的操作記錄，Date files以及Control files還原Database Buffer Cache的相關內容。下面稍微詳細的介紹下後台幾個進程相關的功能以及相對應的觸發機制：
LGWR 日志寫入進程（ Log Writer）
LGWR
日志寫入進程負責將重做日志緩沖區的日志條目寫入磁盤上的聯機重做日志文件。
當運行 DML或 DDL語句時， 服務器進程首先要將事務的變化記載到重做日志緩沖區， 然後才會寫入數據高速緩沖區， 並且重做日志緩沖區的內容將會被寫入聯機重做日志文件， 以避免系統出現意外帶來的數據損失（ 如果操作系統斷電， 內存中的重做日志緩沖區的內容會丟失， 而存在磁盤上的聯機日志文件則不會丟失） ， 這項任務由 LGWR 來完成。
重做日志緩沖區是一個循環結構， LGWR 將重做日志緩沖區中的重做記錄寫入聯機重 做日志文件後， 相應的緩沖區內容將被清空， 保證 Oracle 有空閒的重做日志緩沖區可以寫入。
在出現以下情況時 LGWR 會開始工作：
在 DWBR 進程將髒緩沖區寫入數據文件之前。
//預寫協議
在重做日志記錄達到緩沖區的三分之一。
日志緩沖區記錄的日志多於 1M。
每隔 3 秒鐘。
//重做日志緩沖區是循環使用的， 要騰出足夠的空間給新的記錄使用
提交事務（ 執行 Commit） 。
//提交事務相當於確定保存修改， 不存入日志文件就有丟失的可能
官方文檔中LGWR開始工作的情況:
A user commits a transaction (see "Committing Transactions"on page 10-10).
用戶提交了事務
An online redo log switch occurs.
發生聯機重做日志切換
Three seconds have passed since LGWR last wrote.
自LGWR最後一次寫入已經過了3秒/每隔3秒
The redo log buffer is one-third full or contains 1 MB of buffered data.
重做日志緩沖區達到1/3滿或者已緩存了1MB的數據
DBWn must write modified buffers to disk.
DBWn必須將修改的緩沖區寫到磁盤
Oracle 總是先記載數據變化到重做日志緩沖區， 然後才修改數據高速緩存。 與之類似， 在後台進程 DBWn將髒緩沖區寫入到數據文件之前， 首先要由後台進程 LGWR 將重做日志緩沖區寫入到重做日志中。 與數據高速緩存相比， 重做日志緩沖區相對要小得多， 但寫入頻率高的多， Oracle 必須要確保重做日志緩沖區總有足夠的空間容納新事務， 因此每隔 3秒鐘或重做日志緩沖區已有三分之一填滿時 LGWR 會自動工作。
另外， Oracle 采用了快速提交機制， 當執行 COMMIT操作時， 並不是將“髒緩沖區”數 據寫入到數據文件中， 而是將重做日志緩沖區的內容寫入到重做日志文件中， 以確保數據庫完整性。 此時即使系統出現意外情況（ 如掉電、 系統崩潰等） ， 因為被提交事務已經記載到了存放在磁盤上的聯機重做日志文件中， 將來在重新啟動數據庫時系統會自動進行實例恢復， 並將事務所修改數據寫入到數據文件中， 從而避免了數據丟失。
DBWn數據庫寫入進程（ Database Writer）
數據庫寫入進程負責將數據庫高速緩沖區（ 髒緩沖區） 的內容寫入到數據文件。
盡管有一個數據庫寫進程（DBW0 ） 適用於大多數系統， 但數據庫管理員可以配置額外的進程（ DBW0-DBW9， 最多10 個進程） ， 以提高寫入性能， 通過設置初始化參數DB_WRITER_PROCESSES 來完成。 如果你的系統修改數據嚴重，這些額外的 DBWn進程在單處理器系統不是非常有用。
當數據庫高速緩沖區的塊被修改， 它被標記為髒緩沖區並添加到以 SCN（ SystemChange Number， 系統更改號， 這裡可以看做“時間”） 為順序的 LRUW（ LRUWriter） 列表。
同時， 這個順序與重做日志緩沖區的順序一致。
在出現以下情況時 DBWn進程會開始工作：
系統發出檢查點指令。
//同步數據， 詳見檢查點進程（ CKPT） 。
髒緩沖區個數達到指定阈值。
服務進程搜索一定數目的數據塊後， 不能找到自由緩沖區。
數據寫入計時時間到。
//客戶端執行 SELECT\INSERT\UPDATE\DELETE語句時， 都需要訪問數據庫高速緩沖區。 如果是第一次訪問， 必須要將數據由數據文件讀取到數據庫高速緩沖區， 所以 Oracle 必須要確保數據高速緩存總是存在足夠的“自由緩沖區”以容納新數據。 當 DBWn進程將髒緩沖區的數據塊寫入到數據文件後， Oracle 將把“髒緩沖區”標記為“自由緩沖區”。 因此， 為了保證有足夠“自由緩沖區”來存放新的數據塊， 需要 DBWn進程工作。
表空間脫機或進入只讀狀態。
執行刪除或截斷表操作。
執行 ALTER TABLESPACE … BEGIN BACKUP命令 alter systemflush buffer_cache/checkpoint
//需要同步數據， 原理同檢查點。
CKPT檢查點進程（ Checkpoint）
CKPT檢查點進程的作用是執行一個“檢查點”， 同步數據庫的所有數據文件、 控制文件和重做日志文件。 當執行檢查點時， 系統促使 DBWn將數據緩沖區中數據的變化寫入數據文件， 同時完成對數據文件和控制文件的更新， 記錄下當前數據庫的結構和狀態。 在執行一個檢查點之後， 數據庫處於一個完整狀態。 在數據庫發生崩潰後， 可以將數據庫恢復到上一個檢查點。
Oracle 數據庫在執行涉及數據變化的語句時， 會針對任何修改生成一個順序遞增 SCN（ SystemChange Number） 值， 並且會將 SCN 值連同事務的變化一起記載到重做日志緩沖區。 在數據文件、 控制文件頭部以及重做日志文件中都記載有該值。 Oracle 通過比較各種文件的 SCN 值， 確定文件是否損壞、 系統是否異常， 最終確定系統是需要進行實例恢復還是介質恢復。 在發出檢查點時， 數據文件、 控制文件和重做日志的 SCN 值完全一致。
進程 CKPT在以下情況下會開始工作：
發生日志切換。
關閉實例(SHUTDOWN ABORT除外)。
手工執行檢查點操作。
由初始化參數 LOG_CHECKPOINT_INTERVAL和LOG_CHECKPOINT_TIMEOUT強制發出。
SMON 系統監控進程（ SystemMonitor）
SMON 系統監控進程主要作用是強制對數據庫進行恢復操作。 在實例啟動時， 如果上一次數據庫是非正常關閉， 並且重做日志文件和控制文件的 SCN 值是不同的， Oracle 將自動在重新打開數據庫之前， 通過執行重做日志文件的記錄， 來同步所有數據文件、 控制文件和重做日志文件， 確保所有數據庫文件的一致性， 然後才打開數據庫。
如果檢查點進程一例中， 第四步完成後發生系統掉電、 崩潰， 那麼數據會不會丟失呢？
當然不會。 我們知道， 系統掉電， 導致內存中的數據（ 數據庫高速緩沖區） 的數據丟失。 那麼自然上例中的第五步無法完成（ 無法從數據庫高速緩沖區寫入數據文件） ， 但是由於此時已寫入聯機日志文件。 因此， 此時數據將從聯機日志文件中更新， 而更新的數據量是多少， 自然就是由 SCN 決定。 這一過程我們成為“實例恢復”。 該過程不需要數據庫管理員手工干預， 由 SMON 進程自動完成。
該進程還負責在啟動實例時清理臨時段和合並區（ Extent） 碎片等工作。 所以 SMON進程的工作歸納如下：
進行實例恢復
合並數據文件的自由空間
釋放數據文件的臨時段
PMON 進程監控進程（ Process Monitor）
PMON 進程監控進程負責對失敗的用戶進程或服務進程進行恢復。 當用戶進程連接到Oracle 服務器時， Oracle 將在服務器端分配相應的服務進程。 這時由 PMON 進程來監視用戶進程的執行情況。 當由於種種原因， 用戶對 Oracle 數據庫的連接， 發生崩潰、 掛起或異常終止現象時， 該進程負責清除服務進程所占用的資源， 回滾沒有完成的事務。
當 PMON 檢測到用戶進程失敗時， 進行的工作歸納如下：
回滾當前用戶的事務
釋放當前用戶加的表或行級鎖
釋放用戶的其他資源
重新啟動死掉的調度進程
假定我們在客戶端運行 SQL*Plus 並通過網絡訪問 Oracle 服務器， 那麼 Oracle 將在服務器端分配相應的服務進程。 假如用戶異常終止 SQL*Plus， 或出現網絡斷開或客戶端死機的情況， PMON 就必須檢測到這種情況， 並釋放掉服務進程所占用的資源。
