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