oracle體系結構4500695709-資料下載頁
2025-06-25 21:29本頁面
【正文】 庫的性能。因此Oracle從8i開始引入了增量檢查點的概念。 增量檢查點Oracle從8i開始引入了檢查點隊列這么一種概念，用于記錄數(shù)據(jù)庫里面當前所有的臟數(shù)據(jù)塊的信息，DBWR根據(jù)這個隊列而將臟數(shù)據(jù)塊寫入到數(shù)據(jù)文件中。檢查點隊列按時間先后記錄著數(shù)據(jù)庫里面臟數(shù)據(jù)塊的信息，里面的條目包含RBA（Redo Block Address，重做日志里面用于標識檢查點期間數(shù)據(jù)塊在重做日志里面第一次發(fā)生更改的編號）和數(shù)據(jù)塊的數(shù)據(jù)文件號和塊號。在檢查點期間不論數(shù)據(jù)塊更改幾次，它在檢查點隊列里面的位置始終保持不變，檢查點隊列也只會記錄它最早的RBA，從而保證最早更改的數(shù)據(jù)塊能夠盡快寫入。當DBWR將檢查點隊列里面的臟數(shù)據(jù)塊寫入到數(shù)據(jù)文件后，檢查點的位置也要相應地往后移，CKPT每三秒會在控制文件中記錄檢查點的位置，以表示Instance Recovery時開始恢復的日志條目，這個概念稱為檢查點的“心跳”（heartbeat）。檢查點位置發(fā)生變更后，Oracle里面通過4個參數(shù)用于控制檢查點位置和最后的重做日志條目之間的距離。在這里面需要指出的是，多數(shù)人會將這4個參數(shù)看作控制增量檢查點發(fā)生的時間。事實上這是錯誤的，這4個參數(shù)是用于控制檢查點隊列里面的條目數(shù)量，而不是控制檢查點的發(fā)生。（1)fast_start_io_target該參數(shù)用于表示數(shù)據(jù)庫發(fā)生Instance Recovery的時候需要產生的IO總數(shù)，它通過v$filestat的AVGIOTIM來估算的。比如我們一個數(shù)據(jù)庫在發(fā)生Instance Crash后需要在10分鐘內恢復完畢，假定OS的IO每秒為500個，那么這個數(shù)據(jù)庫發(fā)生Instance Recovery的時候大概將產生500*10*60=30,000次IO，也就是我們將可以把fast_start_io_target設置為30000。（2)fast_start_mttr_target我們從上面可以看到fast_start_io_target來估算檢查點位置比較麻煩。Oracle為了簡化這個概念，從9i開始引入了fast_start_mttr_target這么一個參數(shù)，用于表示數(shù)據(jù)庫發(fā)生Instance Recovery的時間，以秒為單位。這個參數(shù)我們從字面上也比較好理解，其中的mttr是mean time to recovery的簡寫，如上例中的情況我們可以將fast_start_mttr_target設置為600。當設置了fast_start_mttr_target后，fast_start_io_target這個參數(shù)將不再生效，從9i后fast_start_io_target這個參數(shù)被Oracle廢除了。（3)log_checkpoint_timeout該參數(shù)用于表示檢查點位置和重做日志文件末尾之間的時間間隔，以秒為單位，默認情況下是1800秒。（4)log_checkpoint_interval該參數(shù)是表示檢查點位置和重做日志末尾的重做日志塊的數(shù)量，以OS塊表示。（5)90% OF SMALLEST REDO LOG除了以上4個初始化參數(shù)外，Oracle內部事實上還將重做日志文件末尾前面90%的位置設為檢查點位置。在每個重做日志中，這么幾個參數(shù)指定的位置可能不盡相同，Oracle將離日志文件末尾最近的那個位置確認為檢查點位置。SMON進程：該進程實例啟動時，執(zhí)行實例恢復，還負責清理不再使用的臨時段。在具有并行服務器選項的環(huán)境下，SMON對有故障CPU或實例進行實例恢復。SMON進程有規(guī)律地被呼醒，檢查是否需要，或者其它進程發(fā)現(xiàn)需要時可以被調用。PMON進程：該進程在用戶進程出現(xiàn)故障時執(zhí)行進程恢復，負責清理內存儲區(qū)和釋放該進程所使用的資源。例：它要重置活動事務表的狀態(tài)，釋放封鎖，將該故障的進程的ID從活動進程表中移去。PMON還周期地檢查調度進程（DISPATCHER）和服務器進程的狀態(tài)，如果已死，則重新啟動（不包括有意刪除的進程）。PMON有規(guī)律地被呼醒，檢查是否需要，或者其它進程發(fā)現(xiàn)需要時可以被調用。RECO進程：該進程是在具有分布式選項時所使用的一個進程，自動地解決在分布式事務中的故障。一個結點RECO后臺進程自動地連接到包含有懸而未決的分布式事務的其它數(shù)據(jù)庫中，RECO自動地解決所有的懸而不決的事務。任何相應于已處理的懸而不決的事務的行將從每一個數(shù)據(jù)庫的懸掛事務表中刪去。當一數(shù)據(jù)庫服務器的RECO后臺進程試圖建立同一遠程服務器的通信，如果遠程服務器是不可用或者網(wǎng)絡連接不能建立時，RECO自動地在一個時間間隔之后再次連接。RECO后臺進程僅當在允許分布式事務的系統(tǒng)中出現(xiàn)，而且DISTRIBUTED C TRANSACTIONS參數(shù)是大于0。ARCH進程：該進程將已填滿的在線日志文件拷貝到指定的存儲設備。當日志是為ARCHIVELOG使用方式、并可自動地歸檔時ARCH進程才存在。LCKn進程：是在具有并行服務器選件環(huán)境下使用，可多至10個進程（LCK0，LCK1……，LCK9），用于實例間的封鎖。Dnnn進程（調度進程）：該進程允許用戶進程共享有限的服務器進程（SERVER PROCESS）。沒有調度進程時，每個用戶進程需要一個專用服務進程（DEDICATEDSERVER PROCESS）。對于多線索服務器（MULTITHREADED SERVER）可支持多個用戶進程。如果在系統(tǒng)中具有大量用戶，多線索服務器可支持大量用戶，尤其在客戶_服務器環(huán)境中。在一個數(shù)據(jù)庫實例中可建立多個調度進程。對每種網(wǎng)絡協(xié)議至少建立一個調度進程。數(shù)據(jù)庫管理員根據(jù)操作系統(tǒng)中每個進程可連接數(shù)目的限制決定啟動的調度程序的最優(yōu)數(shù)，在實例運行時可增加或刪除調度進程。多線索服務器需要SQL*NET版本2或更后的版本。在多線索服務器的配置下，一個網(wǎng)絡接收器進程等待客戶應用連接請求，并將每一個發(fā)送到一個調度進程。如果不能將客戶應用連接到一調度進程時，網(wǎng)絡接收器進程將啟動一個專用服務器進程。該網(wǎng)絡接收器進程不是Oracle實例的組成部分，它是處理與Oracle有關的網(wǎng)絡進程的組成部分。在實例啟動時，該網(wǎng)絡接收器被打開，為用戶連接到Oracle建立一通信路徑，然后每一個調度進程把連接請求的調度進程的地址給予它的接收器。當一個用戶進程作連接請求時，網(wǎng)絡接收器進程分析請求并決定該用戶是否可使用一調度進程。如果是，該網(wǎng)絡接收器進程返回該調度進程的地址，之后用戶進程直接連接到該調度進程。有些用戶進程不能調度進程通信（如果使用SQL*NET以前的版本的用戶），網(wǎng)絡接收器進程不能將此用戶連接到一調度進程。在這種情況下，網(wǎng)絡接收器建立一個專用服務器進程，建立一種合適的連接。 本篇文章來源于：開發(fā)學院 原文鏈接：16 / 1
電大資料相關推薦
鄂ICP備17016276號-1