是否使用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/[email protected]
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 文件，它也会跳过