分类： Oracle
2007-11-16 13:34:24
一、建立增量备份
如果数据库运行于不归档模式下，那么你只能在数据库干净关闭的情况下(以NORMAL、IMMEDIATE、TRANSACTIONAL方式关闭)才能进行一致性的增量备份，如果数据库运行于归档模式下，那即可以在数据库关闭状态进行，也可以在数据库打开状态进行备份。再次说明了打开归档模式的优势，归档日志也就是多占些磁盘空间，好处不是一些是很多，可是也相当于又给数据库加了层保险啊。
建立增量备份也是相当简单，实质就是一个参数INCREMENTAL LEVEL=n，在执行BACKUP命令时加上即可，例如，建立一个增量级别0的全库备份：
RMAN> BACKUP INCREMENTAL LEVEL=0 DATABASE;
再例如，建立一个增量级别1的users01.dbf数据文件备份
RMAN> BACKUP INCREMENTAL LEVEL=1 TABLESPACE SYSTEM DATAFILE 'F:ORAHOME1ORADATAJSSWEBUSERS01.DBF';
注：Rman默认创建的增量备份是Differential方式，如果要建立Cumulative方式的增量备份，在执行BACKUP命令时显式指定即可，例如：
RMAN> BACKUP INCREMENTAL LEVEL=2 CUMULATIVE DATABASE;
关于增量备份概念性解释，比如Differential与Cumulative两种方式间的区别请参考本篇外传，括弧，外传整理中，如果您看到本篇的时候外传还没出，这个。。。。表着急，耐心等候，面包牛奶都会有的。
二、建立镜像复制
首先大家需要明了这个概念，rman中的镜像复制实质与通过操作系统copy命令备份相同，甚至连命令的格式都相似，只不过直接应用操作系统的copy命令复制数据文件时，只是文件拷贝，而rman的copy则能够在复制的同时，验证数据的有效性。
个人认为rman中的镜像复制应用有限，而且也体现不出rman的优势，所以俺也只是大致了解了概念，没有进行过实际操作，感兴趣的朋友可以自己做做试验，这里就不多做介绍了。
三、建立冗余备份
RMAN提供了一种更谨慎的备份策略：Duplexed方式备份，其实质即是在生成备份集的同时，向指定位置生成指定份数(最大不超过4份)的备份集复制，以避免在灾难性事故时数据库损坏和备份丢失的情况下导致完全崩溃，提高备份可用性。当然，这是人类美好的愿意，对于那些没有异机异地备份条件的，假如机房发生火灾、地震之类大灾难，就算dba把备份文件复制了100份也照样玩完，上述是个假设，万勿对号入座，火灾、地震也不是哪都会发生地，大家好好活着，别害怕。
RMAN中提供了三种方式实现Duplexed方式备份：
1、在RMAN中执行BACKUP命令时显式指定COPIES参数。例如：
RMAN> BACKUP COPIES 3 DATABASE;
上述命令将会在全库备份的同时，自动生成当前备份集的2份拷贝到默认备份目录。
2、在RUN｛｝命令块中利用SET BACKUP COPIES命令为该命令块中所有的BACKUP命令设置Duplexed方式，例如：
RMAN> RUN{
2>SET BACKUP COPIES 2;
3>BACKUP DEVICE TYPE DISK FORMAT 'D:BACKUP1\%U','D:BACKUP2\%U'
4>TABLESPACE USERS,SALES;
5>}
上述命令将生成两份备份集，分别存储到d:ackup1和d:ackup2目录。
3、通过CONFIGURE ..... BACKUP COPIES命令设置预定义的备份Duplexed方式。
CONFIGURE ... BACKUP COPIES命令可以为指定的设备类型设置默认的备份拷贝数量。这个配置仅适用于数据文件与归档重做日志文件和备份，并且，只有在使用自动分配的通道时才能够使用CONFIGURE ... BACKUP COPIES命令设置的配置。例如：
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
RMAN> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE disk TO 2;
RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE disk TO 2;
上述命令将disk设置上数据文件与归档文件的拷备数量设置为2，当再执行BACKUP DATABASE备份时，即会自动生成2份数据文件的备份集。
四、设置RMAN备份的保存策略
策略，啧啧，想不到咱也能说出这么专业的词儿啊，人家说专家就是能把任何事务都描述的很专业，我一定要再多学几个类似的词，要让自己离专家的距离更近一些，或者，我直接搬到eygle他们家床头边上住去~~~~
如果你的数据库非常大，并且备份执行也比较频繁(废话，不大不频繁也得这么干，优秀的dba一定要拥有对应其身份的良好的工作习惯)，有必要对你这些备份文件的保存制订合理的策略。该挪的挪，该搬的搬，该删除的删，合理释放，最大化利用有限的磁盘空间嘛。
在通过RMAN创建的备份片段中，由于备份文件也是由rman创建和维护，所以手工删除并不明智，并且RMAN也提供了备份保留策略，合理制订，由RMAN自动删除过旧的备份文件更加安全也更加方便。
RMAN中提供了两种备份保留策略：基于时间，和基于冗余数量
为RMAN设置了备份保留策略之后，RMAN会自动判断哪些备份集或镜像复制文件不必再保留。这些备份文件将会被标记为“废弃(Obsolete)”，可以通过REPORT OBSOLETE命令查看当前处于废弃状态的备份文件，或者通过DELETE OBSOLETE命令删除这些废弃的备份。例如：
RMAN> report obsolete;
正在使用目标数据库控制文件替代恢复目录
RMAN 保留策略将应用于该命令
将 RMAN 保留策略设置为 3 天的恢复窗口
已废弃的备份和副本报表
类型 关键字 完成时间 文件名/句柄
-------------------- ------ ------------------ --------------------
备份集 21 04-7月 -07
备份段 21 04-7月 -07 D:BACKUPC-3391142503-20070704-01
RMAN> delete obsolete;
RMAN 保留策略将应用于该命令
将 RMAN 保留策略设置为 3 天的恢复窗口
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=14 devtype=DISK
删除以下已废弃的备份和副本:
类型 关键字 完成时间 文件名/句柄
-------------------- ------ ------------------ --------------------
备份集 21 04-7月 -07
备份段 21 04-7月 -07 D:BACKUPC-3391142503-20070704-01
是否确定要删除以上对象 (输入 YES 或 NO)? y
已删除备份段
备份段 handle=D:BACKUPC-3391142503-20070704-01 recid=21 stamp=627061645
1 对象已删除
在执行删除命令时有两点需要了解：
如果被判断为废弃的备份是一个单独数据文件的镜像复制，那么在执行DELETE命令时将直接删除这个镜像复制文件。
如果被判断为废弃的备份是一个备份集中的一部分，则必须等到整个备份集中所有其它文件都被废弃之后，才能删除这个备份集。
1、基于时间的备份保留策略。
说的简单些，就是你希望数据库最早能恢复到几天前。比如将恢复时间段设置为7，那么RMAN所保留的备份即是可以保证你将数据库恢复到一周内任何时刻下那些文件。
设置基于时间的备份保留策略可以通过CONFIGURE命令，例如：
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS;
注：n=大于0的正整数
执行该命令后，RMAN将始终保留那些将数据库恢复到n天前的状态时需要用到的备份，比如，恢复时间段被设置为7天，那么各个数据文件的备份必须满足如下条件：
SYSDATE-(SELECT CHECKPOINT_TIME FROM V$DATAFILE)>=7
任何不满足上述条件的备份都将被RMAN废弃并可通过DELETE OBSOLETE命令删除。Ok,基本知识讲完了，下面考验你的时刻到了，提问：如果满足条件的备份你也想删，咋整？啥？DEL？D你个大头鬼，再回去看看第二章。
2、基于冗余数量的备份保留策略
基于冗余数量实质即某个数据文件以各种形式（包括备份集和镜像复制）存在的备份的数量。如果某个数据文件的冗余备份数量超出了指定数量，RMAN将废弃最旧的备份。
同样，基于数量的备份保留策略也是通过CONFIGURE命令设置，例如：
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS;
同上：n=大于0的正整数
你也可以通过下列命令设置成不采用任何备份保留策略：
RMAN> CONFIGURE RETENTION POLICY TO NONE;
五、备份优化
RMAN中的备份优化(Backup Optimization)是指在备份过程中，如果满足特定条件，RMAN将自动跳过某些文件而不将它们包含在备份集中以节省时间和空间。说的直白些就是能不备的它就不备了，不像原来甭管文件有没有备份过统统再备一遍。由上可知，优化就是偷懒嘛，en,我也要优化的干活:)
话说回来，这个懒也不是什么时候都能偷的，ooo，说错了，是优化。通常必须满足如下几个条件的情况下，才能够启用备份优化的功能：
CONFIGURE BACKUP OPTIMIZATION参数置为on；
执行的BACKUP DATABASE或BACKUP ARCHIVELOG命令中带有ALL或LIKE参数。
分配的通道仅使用了一种设备类型，也就是没有同时分配使用sbt与disk的多个通道。（我知道我知道，通道还没讲，你也等着看外传吧。不过在这儿可以简单描述一下我的理解，In my opinion，sbt与disk就像一条是公路，一条是海路，而通道则相当于你选择了走公路之后，还得选择是走北三环，还是走北五环，还是两条一块走）
打开备份优化设置通过如下命令：
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
那么在进行备份优化时，RMAN是如何判断要备份的文件是否需要被优化呢，这个算法就相当复杂了，而且可能影响优化算法的因素也非常多，假如某库在上午9点被执行过一次全库备份，等下午3点再次执行全库备份时，备份的文件没有变动而且也已经被备份过时，才会跳过这部分文件。所以理论上备份优化仅对于只读表空间或offline表空间起作用。当然对于已经备份过的archivelog文件，它也会跳过(注：上述言论出自yangtingkun大牛，哎，我说老yang你能不能再多说两句，再给我们来一段20W字左右的简短发言呗，哎，你别走啊，你跑什么呀。。。。。。。)。
