备份脚本InstallRman.sh使用当中遇到的问题

发给各位老师的数据库备份脚本InstallRman.sh相信大家已经使用了一段时间了，使用过程中我也发现了一些问题，下面分享给大家。

问题1：过期的备份文件没有正常删除

问题描述：

在配置备份脚本的时候会要求设置一个“恢复窗口”的大小，比如设置为7天，但是当脚本运行一段时间之后发现7天之前的备份文件没有被删除。

问题原因：

脚本安装过程中要求设置一个“恢复窗口”的大小，实际上，脚本会根据输入的值修改RMAN的环境配置，可以进入RMAN查看：



备份脚本rmanbackup.sh中的大概110行：delete noprompt obsolete; 会根据此保留策略来删除不需要的备份。而最后两行的find命令不是用来删除备份的，而是用来删除备份脚本运行过程中产生的输出日志。

下面需要先介绍下保留窗口的概念：

RMAN有两种保留策略，一种是基于冗余的保留策略（Redundancy-Based Retention Policy），另外一种是基于恢复窗口的保留策略（Recovery Window-Based Retention Policy）。本脚本是结合基于保留窗口策略设计的。

恢复窗口表示一段时期，这段时期从当前开始然后向前延伸到能够恢复的时间点。而这个时间点就是就够做介质恢复时的最早时间点。举例来说，如果恢复窗口设置为7天，那么RMAN就要保证在做介质恢复是有能力恢复到，从当前时刻算起，一直到7天之前，这之间的任意时刻。那些做这个假设的基于时间点的恢复不需要的备份文件被RMAN标记为OBSOLETE，可以用命令delete obsolete;将其删除。

下面举一个栗子来说明：

已知：

恢复窗口设置为7天

数据库每两周做一次全备，具体时间是：1月1日，1月15日，1月29日，2月12日

数据库运行归档模式下，归档日志保存在本地磁盘，并且能够根据保留策略的要求保留足够长的时间



当前时间是1月23日，恢复能力点是1月16日。因此，1月14日的备份对于恢复是需要的，加上从序号500到850的所有的归档日志。500之前的归档日志和1月1日的备份被认为是过时的（obsolete），因为对于7天的恢复窗口它们已经不再被需要。



在这个场景中，当前时间是1月30日，恢复能力点是1月23日。注意到1月14日的备份是没有过时的，因为恢复1月28日的备份能不保证恢复最早的时间窗口，1月23日。为了保证7天的恢复窗口，必须保留1月14日的备份和500到1150的所有归档日志。

我们的典型应用是每周六做全备，恢复窗口为14天，所以，在我们的磁盘中最多可能保留3次全备加这期间的所有归档日志备份，然后下一天脚本运行时会删除最早一周的全备以及它之后到下一次全备之前的归档日志备份。

参考资料。

如果发现超过设置的恢复窗口+7天的备份仍然存在没有被删除，那么需要引入另外一个知识点：备份信息存放在哪里？

如果没有使用恢复目录，那么RMAM将备份信息保存在控制文件中。

Oracle数据库的控制文件包含了数据库正常启动和运行的关键信息。控制文件包含的信息可以分成两种类型：可以循环使用的记录和不可以循环使用的记录。而备份记录数据可被循环的记录，并且这些记录被数据库源源不断的产生，十分消耗控制文件的空间。当控制文件没有空间容纳新的记录时，控制文件要么扩展自身大小，要么复写最旧的记录。参数CONTROL_FILE_RECORD_KEEP_TIME指定了记录能够被复用之前的最小天数，默认为7天。

如果记录被覆盖重写，那么已有备份的信息就会丢失，delete noprompt obsolete;命令无法将其删除。我们实际遇到的就是这种情况。

参考资料

解决方法：

1).如备份是发生空间不足的情况，减小恢复窗口的大小，重新运行的脚本InstallRman.sh，或者进入RMAN修改。

[oracle@orcl11g ~]$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Sun Mar 1 23:03:49 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: MYDB (DBID=2764724206)

RMAN> show retention policy;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name MYDB are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 28 DAYS;

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 28 DAYS;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters are successfully stored

RMAN>

2).用操作系统命令将最近一个全备之前的所有文件都删除。

find *.bak -mtime +10 | xargs rm -f #请谨慎执行。

3).修改参数CONTROL_FILE_RECORD_KEEP_TIME，使其不小于恢复窗口。

10g及以上修改方法（使用spfile）：

[oracle@orcl11g ~]$ sqlplus  / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Sun Mar 1 23:09:18 2015

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Producti
4000
on
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
SYS@MYDB>
SYS@MYDB> alter system set control_file_record_keep_time=22;

System altered.

SYS@MYDB>

9i修改方法（使用pfile）：

在参数文件$ORACLE_HOME/dbs/initPROD.ora最后添加一行

control_file_record_keep_time=22

需要重新启动数据库。

问题2：RMAN-06091

问题描述：

在备份日志中发现如下错误：

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 05/07/2008 22:04:21
RMAN-06091: no channel allocated for maintenance (of an appropriate type)

问题原因：

RMAN尝试删除位于带库上的过时的备份时没有分配带库类型的通道。

进入RMAN，执行list backuk;命令能够发现有些备份的驱动类型是SBT_TAPE。

发生这种情况，通常是用于之前使用过某些备份软件，备份软件配置了已虚拟带库，然后讲备份文件保存到了虚拟带库中。可能由于某些原因，不再使用该备份软件，但是控制文件中的记录依然存在。delete obsolete;命令无法将其删除。

解决方法：

1）将脚本中的delete noprompt obsolete;命令替换为 allocate channel for maintenance type disk; delete obsolete device type disk; 或者联系我索要新的InstallRman.sh脚本，liutao#cashq.ac.cn（将#替换成@） 。

2）重建控制文件