oracle 體系結構初步認識(一)

剛開始學習oracle,記錄一下自己的學習筆記,如有錯誤,還望各位大牛多多指教。

首先先上一張oracle體系結構中相對比較重要的圖,如下wKiom1ZlZOGAw9XOAAK_Uw3mxg0089.jpg當我們輸入一條簡單的命令時候,例如第一次輸入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
●每隔 秒鐘。
//重做日誌緩衝區是循環使用的, 要騰出足夠的空間給新的記錄使用
●提交事務( 執行 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_INTERVALLOG_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 就必須檢測到這種情況, 並釋放掉服務進程所佔用
的資源。


spacer.gif

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章