與備份和恢復相關的服務級別協議的三個方面是：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;
為了保證資料庫最大可恢復性，必須多路復用控制檔案，必須多路復用聯機重做日誌，必須以歸檔日誌模式執行資料庫，並多路復用歸檔日誌檔案，最後作常規備份。
多路復用控制檔案
帝國CMS備份恢復重新整理失敗
問題 table phome ecms doesn t existselect count as total from e 解決方法一 恢復資料時候正常，沒有問題。恢復資料後要在重新整理列表裡先用最右邊的 更新快取資料 欄目裡的按順序往下點，然後，自定義頁面重新整理 欄目裡 在左邊第一列的 整站主要...
mysql備份和恢復 mysql備份和恢復
目標 備份和恢復的3種方法，掌握mysqldump命令匯出資料，source命令匯入資料 備份必要性 重要資料不丟失 資料轉移 mysqldump客戶端 作用 轉儲資料庫 搜尋資料庫進行備份 將資料轉移到另乙個sql伺服器 不一定是mysql伺服器 mysqldump h 主機名 u使用者名稱 p ...
ubuntu備份和恢復
1.備份系統 首先成為root使用者 sudo su 然後進入檔案系統的根目錄 當然，如果你不想備份整個檔案系統，你也可以進入你想要備份的目錄，包括遠端目錄或者行動硬碟上的目錄 cd 備份系統命令 tar cvpzf back.tgz exclude proc exclude lost found ...