分类：
2008-10-16 19:09:51
RMAN增量备份方案、增量备份的离线恢复、恢复预览、从resetlogs中恢复、文件压缩等被重新设计后变得更加强大了。
大多数人都赞同RMAN就是事实上的数据库备份工具。尽管早期版本的RMAN已经很强大，但是人们对它的期待还是有很多。很多DBA对于一些很希望有但实际上没有的特性很烦恼。很幸运，在10g中解决了很多问题并且增加了很多受期待的特性，下面就一起看一下。
增量备份
RMAN有一项增量备份的功能。但实际上你是否经常用它呢？或许偶尔，或许从来没有。
这项功能使RMAN备份上一次同级别或者更低级别的增量备份以后发生变化的数据块。例如，在第一天执行了一次全备份（level_0），在第二、三天执行了两次增量备份（level_1）。后面两次备份仅仅备份在第一天和第二天之间变化的数据块、第二天和第三天之间变化的数据块，而不是备份整个数据。这种策略降低了备份数据大小，只需要较少的空间，并且使备份窗口变得更小，降低了网络传输数量。使用增量备份的最重要的因素为了和数据仓库环境相关联。因为在数据仓库中，很多操作都是在NOLOGGING模式下进行的，并且数据的变化并没有记录在归档日志文件中，因此，没有可用来恢复数据的媒质了。由于如今数据仓库非常盘大，所以根本不会考虑使用全备份，同时也不可行。因而采用增量备份是一个可选的方法。
但为什么那么多DBA很少采用增量备份呢？一个原因就是在 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和系统管理员损坏的几率更小。
[1]
