RMAN的实战例子

经过前面的若干，我们已经了解并尝试了rman备份的一些命令，但是在实际环境中，不可能每次备份都要求DBA一条命令一条命令来敲(dba手指头都痉挛啦，老板看着更是肉疼，早知道就是打几个字母，雇个打字的，成本不是更低么)，通过前章的学习我们已经立志一定要优化的干活，所以我们应该写好一段脚本，然后放在服务器端定时执行。DBA只需要时不时看看备份的结果就成了。

在写脚本之前，我们先明确一下我们的目标：

1、每天夜间1点执行；

2、数据库全备，同时备份控制文件及归档日志文件，备份文件保存至：D:\backup\目录下，并在完成归档日志文件备份后，自动删除已备份的归档日志；

3、备份保留7天，过期则自动删除；

4、保留操作日志备查；

以Windows环境为例(linux环境下与此基本类似，rman的脚本您甚至连改都不用改，就把调用rman脚本的命令行改改就行了)：

1、编写rman批处理文件

保存至：E:\oracleScript\backup\database_backup_jssweb.rman

RUN {CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;CONFIGURE CONTROLFILE AUTOBACKUP ON;CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'd:/backup/%F';ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT 'd:/backup/%U';BACKUP DATABASE SKIP INACCESSIBLE FILESPERSET 10PLUS ARCHIVELOG FILESPERSET 20DELETE ALL INPUT;RELEASE CHANNEL CH1;}ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;CROSSCHECK BACKUPSET;DELETE NOPROMPT OBSOLETE;

上述的各项命令均在前面几个章节中提到过，如果有看着眼生的话，再回去翻翻前面。命令是都知晓地，可能有几个参数会不明白其意义，比如：BACKUP命令中的SKIT INACCESSIBLE参数，大家表着急，静心等候俺的外。外外。。外外外。。。。(大锅，看个笔记而已，您不用拎着把菜刀到处晃吧，你你你，你别过来，我说还不成嘛)en,看到大家如此虔诚，俺就提前透露这部分内容吧。

SKIP选项 说明

SKIP INACCESSIBLE：表示跳过不可读的文件。我们知道一些offline的数据文件只要存在于磁盘上就仍然可被读取，但是可能有些文件已经被删除或移到它处造成不可读，加上这个参数就会跳过这些文件；

SKIP OFFLINE：跳过offline的数据文件；

SKIP READONLY：跳过那些所在表空间为read-only的数据文件；

注意哟，你从网上搜索rman备份脚本，可能有些脚本中会出现一项：sql 'alter system archive log current';这句是让archivelog日志归档，实际上完全没必要，我们在第三节的时候讲过，通过plus archivelog方式备份时，rman会自动对当前的archivelog进行归档。

2、编写dos批处理

保存至：E:\oracleScript\backup\database_backup_jssweb.bat

设定要备份的数据库sid为jssweb，将日志按照日期输出到E:\oracleScript\backup\logs\目录。

set oracle_sid=jssweb

rman target / msglog E:\oracleScript\backup\logs\úte:~0,10%.log cmdfile=E:\oracleScript\backup\database_backup_jssweb.rman

3、设定执行计划

控制面板->任务计划中添加计划，运行E:\oracleScript\backup\database_backup_jssweb.bat，设定日程安排中的时间。

竣工！

说是实战，实际上演练的味道依然浓厚，谁让咱这是在测试泥。上述脚本已初具雏形，当然还应该再增加一些更合理的配置，比如根据您的数据库大小，适当调整通道数量，以及加上日期的判断，根据时间进行增量备份(关于增量备份，限于篇幅这里不介绍，俺保证在外传2尽可能白话，敬请期待)。

由于三思专职dba生涯刚刚开始，所接触到的数据库在体积上都属于小型数据库(不超10G)，即使每次备份都是全备也是可以接受的，所以在备份策略上能够非常灵活，或者说随意。对于那些数百G甚至过T的数据库，我想就需要很是花些心思来考虑备份策略的问题了，在这方面三思目前还无法给出具有建设性的提议，但是有一点我想是毋庸置疑的：备份不仅仅只是在数据库崩溃时才会用到，备份是为了更好的恢复。所以我想做好备份与恢复之间开销的平衡应该是所有备份策略的终极目标吧。