了解哪些參數(shù)控制了數(shù)據(jù)庫實例崩潰的修復時間，并且知道9i數(shù)據(jù)庫如何做實例崩潰恢復是這篇文章的目的，主要參考9i new feather，加入自己的理解，可能理解得不好，請大家指正。另外基礎(chǔ)性的東西往往有些枯燥大家自己根據(jù)愛好選擇吧！
概論
非正常當機時間對業(yè)務(wù)的影響非常大。Oracle9i增加了很多減少當機時間的特性。
----快速recovery。
----減少任何故障對最終用戶的影響。
如何實現(xiàn)最小的i/o recovery
假如要減少非計劃當機時間，恢復時間必須降到最低。而恢復過程中i/o操作的數(shù)量直接影響著數(shù)據(jù)庫的恢復時間。控制崩潰恢復時間的兩個基礎(chǔ)是
--讀出redo log變化信息的時間
--讀，更改，寫這些變化所影響的數(shù)據(jù)塊的時間。
..oracle9i介紹了一個雙通道實例或者崩潰恢復來縮減恢復時間。
這里介紹的雙通道恢復不能用于介質(zhì)恢復，這個特性只用于實例或者崩潰恢復。
如何最小化i/o恢復
日志文件經(jīng)常包含在發(fā)生錯誤時不是臟塊的變化數(shù)據(jù)塊。在oracle9i,日志里增加了顯示哪些塊已經(jīng)被成功寫到磁盤的信息，在進行恢復時這些塊將不會被操作，因此總體恢復時間將被縮減。這個特性不需要dba進行任何操作和配置。
想約束恢復一個崩潰所需要的時間，有兩個時間因素必須控制好：
1:讀log file所需要的時間.這依靠于日志文件設(shè)備的數(shù)據(jù)傳輸速率,和恢復過程中需要讀的日志數(shù)量.
2:在崩潰時在buffer cache中的已經(jīng)被修改的數(shù)據(jù)塊的讀寫時間.這依靠于限制cache中被修改而不寫入data file中的塊的數(shù)量,使這個數(shù)量符合在你需要的恢復時間內(nèi)能夠讀寫的文件數(shù)量.
日志文件中很有可能記錄了一部分在崩潰時buffer中的一些雖然已經(jīng)被改變,但并不是臟塊的紀錄.這些數(shù)據(jù)塊已經(jīng)在崩潰前成功的寫入磁盤了.在恢復過程中不需要再對他們進行讀和檢查操作，這將可以節(jié)省大量時間.
新特性中,恢復時需要讀log兩次,第一次找到哪些塊需要恢復,第二次恢復那些需要恢復的塊.第一次的連續(xù)讀非?？?相對于以前的方法,這些額外增加的時間是非常少的.
fast-start time-based recovery limit
在恢復的時候，oracle9i實例重演從checkpoint redo byte address (checkpoint RBA))開始的所有變化，checkpoint RBA是存放在controlfile里的，需要recovery時,checkpoint RBA決定了重做日志流內(nèi)開始應(yīng)用recovery的位置。
提前checkpoint RBA的位置能夠減少recovery time.為了提前checkpoint RBA，buffer cache里的臟塊必須被寫到數(shù)據(jù)文件里。這個操作就是檢查點操作。但是相應(yīng)的過分頻繁的檢查點操作會影響數(shù)據(jù)庫性能。所以我們必須考慮如何取得性能和恢復速度的平衡。
fast-start time-based recovery limit
特點：可以設(shè)置很多的不同維護級別，包括恢復數(shù)據(jù)庫的時間范圍。
DBA必須能夠可靠的設(shè)置一個用來恢復數(shù)據(jù)庫的時間限制
oracle9i引入了基于時間點的快速恢復，這個屬性答應(yīng)dba指定一個多少秒內(nèi)恢復數(shù)據(jù)庫的目標。oracle9i實例自動計算來設(shè)定合適的內(nèi)部參數(shù)，以達到指定的目標。現(xiàn)在設(shè)置秒級的恢復時間限制非常輕易，以前這項工作非常困難而且準確性也很差！
基于時間點的恢復限制
前面我們提到了恢復時間取決于讀取log files的時間和處理需要恢復的數(shù)據(jù)塊的時間。
其中參數(shù)log_checkpoint_interval設(shè)定了恢復過程中將要被讀的重做記錄的數(shù)目。fast_start_io_target控制了需要被恢復的數(shù)據(jù)塊數(shù)目。然而，DBA可以通過單獨設(shè)置參數(shù)來設(shè)置基于秒級的恢復時間限制。LOG_CHECKPOINT_TIMEOUT限制了上一檢查點和最近的重做記錄之間的秒數(shù)。但他對于設(shè)置恢復時間限制來說都是不夠精確的！
新參數(shù)fast_start_mttr_target答應(yīng)DBA指定數(shù)據(jù)庫進行崩潰恢復需要的秒數(shù)。
實際上這個參數(shù)被轉(zhuǎn)化為設(shè)置參數(shù)FAST_START_IO_TARGET,LOG_CHECKPOINT_INTERVAL兩個參數(shù)。這個特性大大簡化了限定數(shù)據(jù)庫恢復時間，并增加了準確性。ast_start_mttr_target是一個動態(tài)參數(shù)，可以在線修改。例如：
alter system set fast_start_mttr_target =60;
在一個單實例數(shù)據(jù)庫配置中fast_start_mttr_target的值是一個估測的崩潰平均恢復時間。在rac里。最壞的情況下，實例崩潰恢復時間是所有的在open
(read/write open)狀態(tài)的實例的fast_start_mttr_target參數(shù)值的和。但是實際的恢復時間會少一些因為初始化和文件打開只需要做一次。
然而，有一種情況下，在rac環(huán)境中，恢復時間會更少。因為一個失敗的單實例會被其他的已經(jīng)打開的實例恢復到正常狀態(tài)。需要失敗恢復去覆蓋rac中所有實例 的情況是一種比較極端的，很少發(fā)生的事情?！?shù)fast_start_mttr_target的范圍是0-3600的一個整數(shù)。
0是默認的，這表示恢復時間不是由這個參數(shù)來控制的。推薦大小取決于sga的大小。數(shù)據(jù)庫的啟動，取決于很多變化的因素，包括維護級別協(xié)定。我們發(fā)現(xiàn)恢復時間隨著維護級別的偏重于不影響性能的變化，恢復時間線性增長。
性能下降可以通過察看檢查點后額外增加的塊數(shù)目檢測到。這些塊作為一個嚴格限制恢復時間的結(jié)果。檢查點統(tǒng)計被存放在statspack的輸出中，也可以在v$instance_recovery視圖中查到（列為ckpt_block_writes).
在實例恢復時，oracle9i實例o重演以檢查點重做字節(jié)地址為起始的變化。
推進檢查點位置能夠控制恢復時間？檢查點的推進由四個參數(shù)控制。
– DB_BLOCK_MAX_DIRTY_TARGET
– FAST_START_IO_TARGET
– LOG_CHECKPOINT_INTERVAL
– LOG_CHECKPOINT_TIMEOUT
DB_BLOCK_MAX_DIRTY_TARGET：指定了buffer cache中dirty
buffer的最大數(shù)目。
FAST_START_IO_TARGET:指定了需要恢復的數(shù)據(jù)塊數(shù)目，9i之前，這個參數(shù)控制了將要被讀和寫的數(shù)據(jù)塊的數(shù)目，在雙通道恢復中，這個參數(shù)等于需要被恢復的數(shù)據(jù)塊數(shù)目。
LOG_CHECKPOINT_INTERVAL：指定檢查點和redo log結(jié)尾中間最大的重做記錄數(shù)目。
LOG_CHECKPOINT_TIMEOUT：指定了檢查點處的重做記錄多少秒開始寫入。
注重：就算沒有任何參數(shù)限定，檢查點推進也會被最小日志得90%大小所控制。即：oracle強制這一行為是通過確認檢查點
和最近重做記錄之間的重做塊的數(shù)目小于最小的日志的90%,假如參數(shù)log_checkpoint_interval的值小于最小日志的90%,那么最小日志的大小將不再影響檢查點行為。
參數(shù)變化
db_block_max_dirty_target參數(shù)已經(jīng)被去掉。
假如fast_start_io_target or log_checkpoint_interval被指定，他們會自動覆蓋由fast_start_mttr_target參數(shù)計算出來的值。
log_checkpoint_timeout沒有改變。
新參數(shù)fast_start_mttr_target被內(nèi)在的解釋成兩個參數(shù):
fast_start_io_target和log_checkpoint_interval.假如這兩個參數(shù)沒有顯式的指定,計算值將生效.
假如fast_start_io_target或者log_checkpoint_interval被顯式指定,這個內(nèi)部計算的值將被忽略,指定的值將替代計算值.
利用規(guī)則計算一些任務(wù)比如:初始化,文件打開,讀日志,從數(shù)據(jù)文件中讀取數(shù)據(jù)塊,寫數(shù)據(jù)塊到數(shù)據(jù)文件中,這是一個適應(yīng)性的規(guī)則,首先用內(nèi)部計算來評估這些操作,然后當系統(tǒng)監(jiān)測到可利用的現(xiàn)實數(shù)據(jù)后,會對這個數(shù)據(jù)進行替代.因此這個評估是比較精確的,因為服務(wù)器對自己的環(huán)境和獨特的i/og更了解.因為人工計算完成這些操作所需要的時間,并通過這些來計算控制恢復時間的參數(shù)是一項復雜的任務(wù),因此這個特性大大簡化了任務(wù),并增加了實例恢復時間的準確性.
視圖v$instance_recovery的變化
增加了3個新列.這些列取代了以前的僅僅為了版本兼容而留下列的信息.
新列是:
TARGET_MTTR:用戶設(shè)置的參數(shù)FAST_START_MTTR_TARGET的值.
ESTIMATED_MTTR:根據(jù)目前臟塊數(shù)目和日志塊數(shù)目,評估的現(xiàn)在進行恢復所需要的時間.
CKPT_BLOCK_WRITES:檢查點寫完的塊數(shù)目.
oracle9i實例最初用在恢復時對i/o速率的內(nèi)部評估來計算這些參數(shù)的值.通過系統(tǒng)監(jiān)測,計算出實際的i/0速率,并用這些信息來為以后的恢復做更精確的計算.因此,恢復時間評估會越來越精確.
oracle9i實例調(diào)整檢查點速率來適應(yīng)參數(shù)的目標值,然而這不是一個硬指標,因此很可能評估的恢復時間和目標設(shè)置不等. 視圖v$instance_recovery是用來監(jiān)測檢查點以及檢查點對恢復的影響.每30秒,oracle9i數(shù)據(jù)庫計算一個目前恢復需要
時間的評估,并將這個值放入v$instance_recovery視圖,這答應(yīng)dba檢測現(xiàn)時的恢復評估時間,并跟fast_start_mttr_target指定的目標值進行比較.
因為不必要的檢查點的產(chǎn)生,設(shè)置一個非常小的系統(tǒng)恢復時間將會對性能產(chǎn)生負面影響,為了幫助治理員監(jiān)測這個參數(shù)設(shè)置較小時對數(shù)據(jù)庫的影響,這個視圖也顯示了額外的因為檢查點引起的數(shù)據(jù)庫寫入操作,它是列CKPT_BLOCK_WRITES.
