Oracle 10G 新特性——RMAN
作者：fuyuncat
RMAN增量备份方案、增量备份的离线恢复、恢复预览、从resetlogs中恢复、文件压缩等被重新设计后变得更加强大了。
大多数人都赞同RMAN就是Oracle事实上的数据库备份工具。尽管早期版本的RMAN已经很强大，但是人们对它的期待还是有很多。很多DBA对于一些很希望有但实际上没有的特性很烦恼。很幸运，在10g中解决了很多问题并且增加了很多受期待的特性，下面就一起看一下。
增量备份
RMAN有一项增量备份的功能。但实际上你是否经常用它呢？或许偶尔，或许从来没有。
这项功能使RMAN备份上一次同级别或者更低级别的增量备份以后发生变化的数据块。例如，在第一天执行了一次全备份（level_0），在第二、三天执行了两次增量备份（level_1）。后面两次备份仅仅备份在第一天和第二天之间变化的数据块、第二天和第三天之间变化的数据块，而不是备份整个数据。这种策略降低了备份数据大小，只需要较少的空间，并且使备份窗口变得更小，降低了网络传输数量。使用增量备份的最重要的因素为了和数据仓库环境相关联。因为在数据仓库中，很多操作都是在NOLOGGING模式下进行的，并且数据的变化并没有记录在归档日志文件中，因此，没有可用来恢复数据的媒质了。由于如今数据仓库非常盘大，所以根本不会考虑使用全备份，同时也不可行。因而采用增量备份是一个可选的方法。
但为什么那么多DBA很少采用增量备份呢？一个原因就是在Oracle 9i和更低版本中，RMAN会扫描所有数据块以定位哪些块需要被备份。这一操作给系统造成了很大的压力，因此增量备份不具备操作性。
Oracle 10G的RMAN对增量备份的方式进行了改进。它利用一个和文件系统中日志文件类似的文件，来跟踪从上次备份以来发生变化的数据块。RMAN需要读这个文件决定哪些块需要备份。
你可以通过执行以下命令来激活这种跟踪机制：
SQL> alter database enable block change tracking using file '/rman_bkups/change.log';
可以通过以下查询语句确定当前跟踪机制是否被激活：
SQL> select filename, status from v$block_change_tracking;
闪动恢复区域
在9i中的闪回功能依赖于回归表空间闪回到一个早期状态，这样就限制它闪回到很早的的状态。通过创建闪回日志，闪动恢复提供了一个新的解决方法。闪回日志和重做日志类似，使数据库恢复到一个早期状态。总之，你可以通过以下SQL语句为数据库创建一个闪动恢复区域，指定它的大小，并将数据库设置为闪动恢复模式：
SQL> alter system set db_recovery_file_dest = '/ora_flash_area';
SQL> alter system set db_recovery_file_dest_size = 2g;
SQL> alter system set db_flashback_retention_target = 1440;
SQL> alter database flashback on;
为了使闪回功能激活，数据库必须在归档日志模式。上述操作会在目录/ora_flash_area下创建oracle管理文件（Oracle Managed Files OMF），总的大小使2GB。数据库的变化都会记录在这些文件中，可以使数据库迅速恢复到以前的某一点。
默认情况下，RMAN也会使用/ora_flash_area目录来存储备份文件。因此，RMAN的备份全市存储在磁盘上，而不是磁带上。这样的话，你就可以设定备份数据保留多少天，时间到了后，如果需要更多空间时这些文件会被自动删除。
然而，闪动恢复区域可以不需要一个文件系统或目录，它可以是一个自动存储管理（Automatic Storage Management ASM）磁盘组。在这种情况下，闪动恢复区域可以用以下语句指定：
SQL> alter system set db_recovery_file_dest = '+dskgrp1';
通过ASM和RMAN的结合使用，你可以通过使用哪些如Serial ATA和SCSI盘等廉价的磁盘来构建可扩展的、容错性强的存储系统。这种方式不能是备份过程更快，而可以使用比磁带方式更便宜的磁盘来完成同样的事情。
另外一个好处就是避免了用户错误。永伟ASM文件不是实际的文件系统，他们被DBA和系统管理员损坏的几率更小。
增量合并
假如你有以下的备份计划：星期天做level 0的完全备份，标识为level_0；星期一做level 1的增量备份，标识为level_1_mon；星期四做level 1的增量备份，标识为level_1_tue。如果数据库在星期六被损坏了，在10G之前你不得不恢复level_0然后再将所有6个增量备份实施上去，这样会消耗很长一段时间。这也是很多dba避免使用增量备份的原因之一。
Oracle 10g的RMAN从根本上改变了这种方式，现在的增量备份命令如以下这个样子：
RMAN> backup incremental level_1 for recover of copy with tag level_0 database;
这样RMAN再做增量备份level_1备份时会和标识为level_0的完全备份合并。经过这样的备份，level_0变成了那天的完全备份了。
因此，在周四，标识为level_0的备份实际与level_1的增量备份合并，成了在周四做的完全备份。如果在周六数据库损坏了，你只需要将level_0的备份加上一些归档日志共同恢复就可以了。而不需要将增量备份也恢复。这种方式大大减少了恢复时间，使备份加速，并且避免了重新做一个增量备份。
压缩文件
在基于磁盘备份的闪动恢复区域功能中，你还有一个很大的限制：磁盘容量。特别使当通过网络实现时——实际也经常是这么用的——强烈建议创建一个尽可能小的备份。在10G的RMAN中，你可以在备份命令中插入压缩文件的命令：
RMAN> backup as compressed backupset incremental level 1 database;
请注意这使用了COMPRESS子句。它压缩的备份文件有一个很重要的特点：当恢复时，RMAN可以无需解压文件直接读取它。为了确认是否压缩，可以在输出信息中检测是否有以下内容：
channel ORA_DISK_1: starting compressed incremental level 1 datafile backupset
你还可以通过在RMAN中list output确认备份是否被压缩：
RMAN> list output;
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3 Incr 1 2M DISK 00:00:00 26-FEB-04
BP Key: 3 Status: AVAILABLE Compressed: YES Tag:
TAG20040226T100154
Piece Name:
/ora_flash_area/SMILEY10/backupset/2004_02_26/o1_mf_ncsn1_TAG20040226T100154_03w2m3lr_.bkp
Controlfile Included: Ckp SCN: 318556 Ckp time: 26-FEB-04
SPFILE Included: Modification time: 26-FEB-04
就如所有的压缩动作一样，这一方法会增大CPU的压力。但这也使你可以保留更多的备份在磁盘上以备恢复。另外，你还可以用RMAN来备份物理备份数据库以用于恢复主数据库。这一方法可以将备份资源从其他主机上卸载下来。
恢复预览
通过提供了能预览恢复操作功能，Oracle 10g变得很先进了：
RMAN> restore database preview;
… …
你还可以预览特定的恢复操作，如：
RMAN>restore tablespace users preview;
… …
预览功能使你能通过定期的检查来确认恢复时要做什么样的准备。
Resetlogs和恢复
假如你丢失了当前的在线重做日志文件又不得不做一次不完全的数据库恢复。最大的问题时resetlogs。当不完全恢复后，你必须使用resetlogs子句来打开数据，它会设置日志线程的序列号为1，删除RMAN中早期的备份，使恢复操作更容易。在Oracle 9i和更低版本中，如果你需要将数据库从resetlogs中恢复到一个早期状态，你不得不把它恢复成一个不同的样子。在Oracle 10G中，你就不需要这样做了。由于控制文件增加了一些结构，RMAN可以在一次resetlogs操作之前或之后随时利用所有的备份来恢复数据库。做备份使没有必要关闭数据库了。这一新功能意味着在一次resetlogs操作以后数据库可以迅速的被用户打开。