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