這些年來，Oracle數據庫備份和恢復方式已經發生了重大變化，特別是在Recovery ManagerRMAN）功能有了進一步改善之后。中培偉業《Oracle數據庫管理與性能調優》培訓專家賈老師在這里對沒有RMAN之前，以及有了RMAN之后，DBA如何備份數據，以及RMAN如何改善這一過程進行了詳細介紹。

賈老師介紹，很久之前的Oracle 5，那時候的備份是這么做的：關閉數據庫，復制所有的相關文件，然后再次啟動數據庫。這種備份方式屬于冷備份，因為數據庫在備份發生時是不運行的。這是能夠確保一致性的備份，一個DBA可以使用這個備份進行回滾，通常不會有任何問題，但恢復卻是一個苦差事，而且只能在聯機恢復日志可用時才能進行。

Oracle 6的發布，引發了數據庫備份的下一次進化。它的恢復操作會改變向量，回滾段和表空間。這種備份是熱備份，在線備份也變得可用。

復制與指定表空間相關的文件，Oracle可以重建和恢復表空間。當然archivelog也需要復制，為了“熱”備份整個數據庫，上面所示的兩個命令需要在數據庫每個表空間中運行。當然這是數據庫相比之前版本來說的一個優勢，現在數據庫可以繼續運行，而與此同時備份也在進行。不過，這是一個手動過程，需要DBA編寫腳本。整個數據庫必須重建和恢復，表空間的時間點恢復并不可用。

進入Oracle 8，備份和恢復得到了進一步改進。表空間時間點恢復，增量備份，并行備份和恢復都是可用的。這也是首次引入Recovery Manager概念的版本，但由于處于早期階段，因此其帶來的問題甚至比解決的還有多，所以沒有其并未被廣泛采用。

Oracle 8提供的兩個較大的改進是表空間時間點恢復和增量備份，這兩個功能是緊密相關的。正是因為增量備份功能的存在，時間點恢復才能夠使用。以后再也沒有必要一次次的執行完整備份。在一個星期內執行一次完整備份就夠了，用增量備份自上次完全備份后保存所做的更改來完成之前的完整備份的功能就足夠了。的確，現在需要使用兩種備份來完全恢復和重建一個數據庫，但增量備份文件比完整備份要小得多，這使得Oracle數據庫可以被恢復至任何執行過增量備份的時間點。不僅可以恢復和重建數據庫，也可以克隆數據庫在某一時間點的內容盡管這一過程在當時來說比現在更復雜。要記住，RMAN并不是非常可靠，所以DBA不準備放棄他們的備份腳本以支持這種新的備份和恢復技術。

Oracle 9迎來了一個更可靠的Recovery Manager，更多的DBA愿意使用RMAN，測試其功能。它提供給DBA的用于創建完整和增量備份的接口更為可靠，使用其恢復和重建一個數據庫也更為簡單。

Oracle 1011繼續改進RMAN，提高其可靠性，前者采用自動存儲管理(ASM)，將其集成到RMAN中，更好地管理數據庫空間，后者提供了從當前目標數據庫備份或一個運行中的目標數據庫創建克隆的功能。系統網絡帶寬支持這樣的操作，進行最新的克隆是完全可能的。當然，克隆將永遠不會完全同步運作中的數據庫，相對于最近的事務，克隆需要保持一致性，這時候恢復將會停止，但克隆運行中的數據庫將允許近期事務在克隆開始時繼續運行。所有這一切是可以使用RMAN提供的接口來進行，可以從本地O/ S調度器執行腳本。Oracle12延伸了這些改進，讓RMAN可以從一個RMAN備份集中恢復和重建單個表，這是一個曾經在老版本中被歸入expimp范疇的任務，在9i R2以后的版本中，其被歸入expdpimpdp范疇。

“時間不等人。”這句話用在Oracle為了提高數據庫備份，恢復和重建的能力，而給數據庫備份和恢復帶來的變化上再合適不過。以往那些執行手動腳本，關閉數據庫創建一個備份，數據庫運行中必須顯式地備份每個單獨的表空間的日子一去不復返了。RMAN現在是一個“日常”用字如果你的日常工作是運行Oracle數據庫上的數據中心，手動腳本等其他任何類型的備份不再是必要的。RMAN很容易實現可靠的備份，DBA已將該技術視為理所當然。但是，正如這里介紹的，從最早版本Oracle開始，備份和恢復已經走了很長的路，DBA的世界里應該對這樣的變化感到欣喜，盡管他們可能還沒意識到。