这些年来，Oracle数据库备份和恢复方式已经发生了重大变化，特别是在Recovery Manager(RMAN)功能有了进一步改善之后。那么接下来，就让我们来回顾下，在没有RMAN之前，以及有了RMAN之后，DBA如何备份数据，以及RMAN如何改善这一过程。
回到很久之前的Oracle 5，那时候的备份是这么做的：关闭数据库，复制所有的相关文件，然后再次启动数据库。这种备份方式属于冷备份，因为数据库在备份发生时是不运行的。这是能够确保一致性的备份，一个DBA可以使用这个备份进行回滚，通常不会有任何问题，，但恢复却是一个苦差事，而且只能在联机恢复日志可用时才能进行。
Oracle 6的发布，引发了数据库备份的下一次进化。它的恢复操作会改变向量，回滚段和表空间。这种备份是热备份，在线备份也变得可用。使用Oracle 6, DBA可以执行:
ALTER TABLESPACE
ALTER TABLESPACE
复制与指定表空间相关的文件，Oracle可以重建和恢复表空间。当然archivelog也需要复制，为了“热”备份整个数据库，上面所示的两个命令需要在数据库每个表空间中运行。当然这是数据库相比之前版本来说的一个优势，现在数据库可以继续运行，而与此同时备份也在进行。不过，这是一个手动过程，需要DBA编写脚本。整个数据库必须重建和恢复，表空间的时间点恢复并不可用。
进入Oracle 8，备份和恢复得到了进一步改进。表空间时间点恢复，增量备份，并行备份和恢复都是可用的。这也是***引入Recovery Manager概念的版本，但由于处于早期阶段，因此其带来的问题甚至比解决的还有多，所以没有其并未被广泛采用。
Oracle 8提供的两个较大的改进是表空间时间点恢复和增量备份，这两个功能是紧密相关的。正是因为增量备份功能的存在，时间点恢复才能够使用。以后再也没有必要一次次的执行完整备份。在一个星期内执行一次完整备份就够了，用增量备份(自上次完全备份后保存所做的更改)来完成之前的完整备份的功能就足够了。的确，现在需要使用两种备份来完全恢复和重建一个数据库，但增量备份文件比完整备份要小得多，这使得Oracle数据库可以被恢复至任何执行过增量备份的时间点。不仅可以恢复和重建数据库，也可以克隆数据库在某一时间点的内容(尽管这一过程在当时来说比现在更复杂)。要记住，RMAN并不是非常可靠，所以DBA不准备放弃他们的备份脚本以支持这种新的备份和恢复技术。
Oracle 9迎来了一个更可靠的Recovery Manager，更多的DBA愿意使用RMAN，测试其功能。它提供给DBA的用于创建完整和增量备份的接口更为可靠，使用其恢复和重建一个数据库也更为简单，使用以下命令即可：
RESTORE DATABASE;
RECOVER DATABASE;
from the RMAN>prompt.
Oracle 10和11继续改进RMAN，提高其可靠性，前者采用自动存储管理(ASM)，将其集成到RMAN中，更好地管理数据库空间，后者提供了从当前目标数据库备份或一个运行中的目标数据库创建克隆的功能。系统网络带宽支持这样的操作，进行***的克隆是完全可能的。(当然，克隆将永远不会完全同步运作中的数据库，相对于最近的事务，克隆需要保持一致性，这时候恢复将会停止，但克隆运行中的数据库将允许近期事务在克隆开始时继续运行。)所有这一切是可以使用RMAN提供的接口来进行，可以从本地O/ S调度器执行脚本。Oracle12延伸了这些改进，让RMAN可以从一个RMAN备份集中恢复和重建单个表，这是一个曾经在老版本中被归入exp和imp范畴的任务，在9i R2以后的版本中，其被归入expdp和impdp范畴。
“时间不等人。”这句话用在Oracle为了提高数据库备份，恢复和重建的能力，而给数据库备份和恢复带来的变化上再合适不过。以往那些执行手动脚本，关闭数据库创建一个备份，数据库运行中必须显式地备份每个单独的表空间的日子一去不复返了。RMAN现在是一个“日常”用字(如果你的日常工作是运行Oracle数据库上的数据中心)，手动脚本等其他任何类型的备份不再是必要的。RMAN很容易实现可靠的备份，DBA已将该技术视为理所当然。但是，正如这里介绍的，从最早版本Oracle开始，备份和恢复已经走了很长的路，DBA的世界里应该对这样的变化感到欣喜，尽管他们可能还没意识到。
