備份和恢復問題以及失敗類型

與備份和恢復相關的服務級別協議的三個方面是：MTBF（平均無故障時間）  MTTR （平均恢復時間）和數據丟失
作爲DBA目標就是增加MTBF減少MTTR和數據丟失
失敗類型：
1.語句失敗
數據錯誤，權限錯誤，空間錯誤，邏輯錯誤
空間管理問題是一個常見問題。包括：由於表空間已滿而無法擴張某個段；耗盡撤銷表空間；運行使用磁盤排序的查詢或使用臨時表時臨時空間不足；某個用戶達到配額；某個對象達到其最大區間限制。
如果將數據文件設置爲自動擴展或者啓用可恢復的空間分配，那麼可能減輕空間問題的影響。
如果某個語句失敗，則此語句將回滾，其他任何DML語句將保持完好，而且不會提交。
2.用戶進程失敗
用戶並非註銷的異常退出；終端的重新啓動，導致地址違規的程序。
PMON後臺進程通過定時輪詢所有服務器進程來確定會話的狀態。如果某個服務器進程報告丟失了與某用戶進程的聯繫，此時PMON進程會解決這個問題。如果指定的會話位於某個事務的中部，那麼PMON進程
會首先回滾這個事物並釋放該會話的所有鎖定，然後終止該服務器進程，同時將PGA釋放回操作系統。
如果會話異常終止，系統將自動回滾處於活動狀態的事務。
3.網絡故障
偵聽器  網絡接口卡 路由
一個偵聽器每次只能爲一個聯接請求提供服務，並且需要在適當的時間內啓動一個服務器進程並且將該服務器進程連接到某個用戶進程。如果數據庫同時接收到大量的連接請求，那麼用戶在嘗試連接數據庫時
可能會收到錯誤消息。配置多個偵聽器（每個偵聽器位於一個不同的地址/端口組合上）可以避免這個問題。
4用戶錯誤
閃回查詢，閃回刪除，閃回數據庫和完全恢復
5.介質失敗
控制文件，聯機重做日誌應當始終通過多路複用技術進行保護。
數據文件無法被多路複用。一旦某個文件被損壞，那麼唯一的選擇是從備份中還原這個數據文件。所謂還原文件，就是從其備份位置提取文件，然後將其放回預想位置。此後對文件進行恢復。已還原的備份處於過期
狀態，而“恢復”意味着通過應用從聯機和歸檔的重做日誌中提取的變更將數據文件恢復至受損之時的狀態。
恢復需要使用歸檔的重做日誌。歸檔的重做日誌是在每次日誌切換後生成的聯機重做日誌文件副本。
爲了應對介質失敗，我們必鬚生成控制文件，聯機重做日誌文件以及歸檔的重做日誌文件的多個多路複用副本，此外還必須對控制文件，數據文件，以及歸檔日誌文件進行備份。
多路複用並才能不能保護數據文件，數據文件必須通過硬件冗餘受到保護。硬件冗餘指常用的raid系統或oracle自己的ASM。
6.實例失敗
實例失敗後，數據庫完全可能丟失已提交的事物和存儲未提交的事物。這就是所謂的受損或不一致數據庫。
導致這種情況的原因是服務器進程在內存中進行工作，這些進程更新了數據庫緩衝區緩存內的數據塊與撤銷塊。最後，DBWn進程將更改後的數據塊寫至數據文件。
DBWn進程用於選擇髒髒緩衝區進行寫操作的算法考慮了性能問題，從而首先寫入最不活躍的數據塊，畢竟對每秒仲都在發生變化的數據塊進行頻繁的寫操作是不可取的。不過，這意味着在任意給定的時刻，完全可能
存在尚未寫至數據文件的已提交事務以及已被寫至事務文件的未提交事務，也就是說，commit命令與數據文件的寫操作不存在任何聯繫。當然，被應用於數據塊和撤銷塊的所有變更都已經存在於重做日誌文件中。

LGWR進程實際上會採用一種非常積極的算法進行寫操作。LGWR進程儘可能實時地進行寫操作，並且在執行commit命令時確實會完成實時寫操作。這正是實例恢復的關鍵。實例失敗後oracle數據庫將受到損壞，但是
在磁盤上的重做日誌流中始終存在着修正損害所需的足夠信息。
 

實例恢復
如果數據庫損壞--即包含未提交數據或丟失已提交數據，那麼oracle會檢測到這種狀況，並且能夠通過執行實例恢復來刪除損壞。
實例恢復不僅可以重新構成在崩潰時未被保存至數據文件的任何已提交事務，而且可以回滾已被寫至數據文件的任何未提交事物。這種恢復時完全自動的，我們無法隨意停止實例恢復過程。
恢復機制：實例恢復只不過是使用聯機重做日誌文件的內容將數據庫緩衝區緩存重新構建至崩潰之前的狀態。
怎樣才能調用實例恢復呢？使用startup命令
首先，在數據庫過度到加載模式時，SMON進程會讀取控制文件，隨後在數據庫過渡到打開模式時，SMON進程會查看所有數據文件和聯機重做日誌文件的文件頭，此時，如果已經出現了實例失敗，由於文件頭
沒有全部同步，因此SMON進程會發現實例失敗，從而進入實例恢復例程，而數據庫只能在前滾階段結束之後才能被真正打開。


調整實例恢復
實例恢復能夠保證不造成損壞，但是數據庫能夠打開之前需要耗費大量的時間來完成實例恢復的前滾操作。這個時間取決於兩個因素：需要讀取的重做數，以及應用重做需要在數據文件上完成的讀寫操作數。
檢查點保證了在某個特定的時間，DBWn進程已將構成一個特定系統更改號的所有數據變更都寫入數據文件。在一個實例崩潰事件中，只有SMON進程需要重演從上一個檢查點位置開始生成的重做。無論是否提交
在這個檢查點位置之前多有的全部變更都已寫入數據文件。因此，顯然不需要使用重做來重新構造在該檢查點位置之前已提交的事物。此外，在這個檢查點之前未提交事務所左的變更也會被寫入數據文件，因此也不
需要重新構造該檢查點位置之前的撤銷數據，回滾需要使用的這些數據已經存在與磁盤上的撤銷段內了。
檢查點位置越金，實例恢復就越快。如果檢查點位置是最近的，那麼不需要前滾，此時可以立即打開實例並直接進入回滾階段，不過，實現這種操作的代價很大。爲了前移檢查點位置，DBWn進程必須將變化的數據塊寫至磁盤，過多的磁盤I/O會削弱數據庫性能。但是另一方面，如果不頻繁使用DBWN進程，那麼在實例崩潰之後，SMON就必須處理千兆字節的重做以及在數據文件上執行數百萬次的讀寫操作，實例失敗後的MTTR可能會延長數小時。
fast_start_mttr_target這個參數使得對實例恢復時間的控制變得十分容易。
設置fast_start_mttr_target參數值越小，DBWn進程將會更努力地藏時最小化檢查點位置與實際時間的間隔。不過需要注意的是，這只是個目標，如果設置了一個不切實際的較小值，那麼DBWn物理如何也不可能達到要求。
MTTR顧問程序，這個顧問程序可以讓您確定實例失敗後需要的恢復時間，此外，從V$INSTANCE_rECOVER視圖也能獲得這些信息。
如果將fast_Start_mttr_target設置爲非零值，將產生兩個效果。首先它設置了恢復目標，也產生了次生效應：啓用檢查點自動調整機制，檢查點自動調整機制檢查有關計算機使用情況的統計信息。如磁盤I/O速率和CPU使用情況，如果發現能力有剩餘，它將利用此能力寫出數據庫緩衝區緩存的其他髒緩衝區，從而前移檢查點位置。這樣一來，即使將fast_Start_mttr_target參數設置爲較大的值，時間恢復數據也完全可能大大減少。
如果將fast_start_mttr_target 設置爲非零值，將啓用檢查點自動調整。
檢查點位置由DBWn自動前移。這個過程稱爲增量檢查點。
除此之外還有完整檢查點和局部檢查點。
如果將所有髒緩衝區都寫入磁盤，就會出現完整檢查點。
只有兩種情況纔會執行完整檢查點：1有序關閉2dba要求這麼做
當使用normal,immediate,transactional選項關閉數據庫時，都會執行檢查點：在關閉和卸載數據庫之前。DBWn會將所有髒緩衝區刷新到磁盤中。這意味着，在次打開數據庫時，不需要執行任何恢復操作。
alter system checkpoint;

爲了保證數據庫最大可恢復性，必須多路複用控制文件，必須多路複用聯機重做日誌，必須以歸檔日誌模式運行數據庫，並多路複用歸檔日誌文件，最後作常規備份。
多路複用控制文件