RMAN恢复目录

是否使用RMAN恢复目录（Recovery Catalog

　　你可能从其他人或书上听过RMAN恢复目录（也有可能是其他名字，RMAN Recovery Catalog的翻译较多较杂，以下简称恢复目录），旁人的表达或书中模糊不清的描述，导致很多朋友一直对其实际意义和作用感到疑惑。在我看来，可以将其视作存储RMAN备份恢复相关信息的数据库（在物理形式上可以对应成Oracle中的一个SCHEMA）。

　　当没有恢复目录时，RMAN相关的备份信息，比如归档文件路径、备份集路径等均存储在目标数据库的控制文件中，不过考虑到控制文件并不能无限增长，而且控制文件也不仅仅是用来存储与备份相关的信息，因此RMAN也有一个专门的备份信息存储地，这就是恢复目录了。当待备份的数据库注册到恢复目录之后，RMAN相关的信息除了保存在控制文件中外（控制文件实际上只保存一部分），更加详细的信息就都被存储在恢复目录中。

　　提示：强烈建议不要将恢复目标数据库放到目标数据库中。

　　创建恢复目录非常简单，RMAN提供了CREATE CATALOG命令，但是在创建恢复目录之前，首先需要为该恢复目录创建一个独立表空间和对应的 SCHEMA ，详细操作步骤如下：

　（1）创建一个独立的表空间：

SQL>CREATE TABLESPACE RMANTBS DATAFILE 'f:\oracle\oradata\bakdb\rmantbs01.dbf'  size 50m;

Tablespace created.

　　注意千万不要将恢复目录创建在要备份的目录数据库。

　　由于恢复目录通常不会太大，这里数据文件仅分配了50MB的空间。

　　（2）创建一个独立的 SCHEMA ，用来记录备份信息，并授予相关权限：

SQL>GRANT CONNECT,RESOURCE,RECOVERY_CATALOG_OWNER TO RMANCT IDENTIFIED BY RMANCT;

Grant succeeded.

　　（3）通过RMAN连接到新创建的恢复目录中：

F:\oracle>RMAN CATALOG RMANCT/RMANCT

Recovery Manager: Release 10.2.0.1.0 - Production on Fri Apr 24 11:11:06 2009

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

connected to recovery catalog database

　　（4）在RMAN中创建 CATALOG ：

RMAN>CREATE CATALOG TABLESPACE RMANTBS;

recovery catalog created

　　这样恢复目录就算创建完了，一个恢复目录数据库可以同时为多个目标数据库提供服务，不过要使用恢复目录执行备份操作前，首先需要在恢复目录中注册该数据库，注册也非常简单，一条命令即可，步骤如下：

　　首先以CATALOG模式连接到目标数据库和恢复目录（连接恢复目录只需要在连接时指定CATALOG参数即可）：

F:\oracle>RMAN TARGET / CATALOG RMANCT/RMANCT@BAKDB

Recovery Manager: Release 10.2.0.1.0 - Production on Fri Apr 24 11:16:36 2009

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

connected to target database: JSSBOOK (DBID=1419729528)

connected to recovery catalog database

　　可以通过如下命令注册数据库：

RMAN> REGISTER DATABASE;

database registered in recovery catalog

starting full resync of recovery catalog

full resync complete

　　这之后进行的操作，比如创建备份等操作信息都会存入恢复目录中。

　　对于注册到恢复目录，是否就必须或者只能以CATALOG模式进行备份或恢复操作了呢？当然不是，恢复目录只是RMAN中的一个可选项，而不是必选项，备份信息是否记入CATALOG取决于执行RMAN操作时是否连接到了CATALOG，也就是说，即使目标数据库已经注册到恢复目录中，但连接时没有以CATALOG模式连接，则备份信息仍然是只存入目标端数据库的控制文件，相当于NOCATALOG模式。

　　另外，已经注册到 CATALOG 中的数据库希望取消注册怎么办呢？使用U NREGISTER 命令即可：

RMAN>UNREGISTER DATABASE;

database name is "JSSBOOK" and DBID is 1419729528

Do you really want to unregister the database (enter YES or NO)? yes

database unregistered from the recovery catalog

　　如果DBA要管理的Oracle数据库较多，那么对于这些数据库的备份，建议使用恢复目录统一管理，这样既方便备份和恢复操作，而且安全性也相对比较高（执行完备份操作后，单独备份恢复目录数据库即可，无须担心被备份的数据库控制文件丢失可能造成的影响）。不过如果DBA仅管理一个或者数个Oracle数据库，那么我想NOCATALOG模式操作起来会更加方便。

8.5.7 是否启用备份优化

　　RMAN 中的备份优化（Backup Optimization）是指在备份过程中，如果满足特定条件，RMAN将自动跳过某些文件，而不会再将它们包含在备份集中，以节省时间和空间。说得直白些就是能不备份的它就不备份了，不像原来甭管文件有没有备份过统统再备份一遍。由上可知，优化就是偷懒嘛，en，俺也要优化的干活:）

　　不过话说回来，这个懒也不是什么时候都能偷的，哦，说错了，是优化。通常必须在满足如下几个条件的情况下，才能够启用备份优化的功能：

• CONFIGURE BACKUP OPTIMIZATION 参数置为 ON 。
• 执行的BACKUP DATABASE或BACKUP ARCHIVELOG命令中带有ALL或LIKE参数。
• 分配的通道仅使用了一种设备类型，也就是不能同时分配使用 SBT 与 DISK 的多个通道。

　　通过如下命令打开备份优化设置：

RMAN> CONFIGURE BACKUP OPTIMIZATION ON;

　　那么在进行备份优化时，RMAN是如何判断要备份的文件是否需要被优化呢？这个算法就相当复杂了，而且可能影响优化算法的因素也非常多，假如某库在上午9点被执行过一次全库备份，等下午3点再次执行全库备份时，备份的文件没有变动而且也已经被备份过时，才会跳过这部分文件。所以理论上备份优化仅对于只读表空间或 OFFLINE 表空间起作用。当然对于已经备份过的 ARCHIVELOG 文件，它也会跳过