I. 使用恢复目录存储RMAN备份记录

1. Oracle 官方建议把恢复目录建议于独立的数据库中。如果把恢复目录与其他一些数据混杂在某库中，若该库失败则恢复目录一起丢失，这将导致恢复异常困难。
2. 在恢复目录中登记某个库被称作注册（registration）.可以在恢复目录中注册多个目标库。举例来说，你可以注册数据库 prod1,prod2,和prod3在一个单独的由用户catowner拥有的目录中，而该目录位于一个叫catdb的数据库中。 因为RMAN通过DBID即数据库的身份证来分辨各个库。每个在恢复目录中注册过的目标库都有一个唯一的DBID.
3. 恢复目录主要包括以下RMAN的使用情况信息：

l  数据文件和归档日志的备份集和备份片

l  数据文件的拷贝

l  归档日志及其拷贝

l  目标库中的表空间和数据文件

l  储存的脚本

l  RMAN的永久性配置

1. 恢复目录保存了目标库控制文件中重要的RMAN操作原数据。同步恢复目录保证与控制文件中当前信息同步。
2. RMAN 创建快照控制文件，即临时控制文件，当每次需要做全局同步时。快照临时文件保证了RMAN同步时的一致性读。数据库服务进程保证同时只有一个快照临时文件的存在，这对于保证RMAN操作不受其他进程干扰是必要的。
3. 丢失恢复目录将导致严重的恢复问题。如何备份恢复目录可参考一般数据库的备份方式。
4. 关于恢复目录的兼容性，可以通过查询恢复目录用户模式下的rcver表了解参与恢复目录使用端的版本号，示例：

SQL> SELECT * FROM rcver;

VERSION

------------

08.01.05.00

09.00.01.00

10.02.01.00

只要是8i之后版本一般不存在兼容性问题。

II 管理恢复目录

创建恢复目录

管理恢复目录中的目标库记录

同步恢复目录

恢复目录模式下的控制文件管理

备份恢复目录

导入和导出恢复目录

增强恢复目录可用性

查询恢复目录视图

更新恢复目录

删除恢复目录

1. 创建恢复目录，创建恢复目录分成三步：

• 配置恢复目录所在数据库
• 创建恢复目录拥有者
• 创建恢复目录本身

配置恢复目录数据库

若使用恢复目录，RMAN要求维护恢复目录所在模式。恢复目录储存在当前模式的默认表空间中，注意SYS不能是恢复目录的拥有者。我们强烈建议恢复目录数据库使用归档模式。同时必须分配足够的空间给恢复目录所在模式，恢复目录所占用的空间取决于使用恢复目录的目标数据库的数量。适当地为恢复目录库规划容量是必要的。应当保证恢复目录库和目标数据库的不占用同一磁盘。

创建目录拥有者

在合理配置恢复目录库后，我们来创建目录拥有者

使用目录库上的SYS帐号登录

假定当前有一个tool表空间来保存目录

使用temp临时表空间为用户默认临时表空间

如下步骤：

     CONNECT SYS/oracle@catdb AS SYSDBA

 SQL> CREATE USER rman IDENTIFIED BY cat

       TEMPORARY TABLESPACE temp

       DEFAULT TABLESPACE tools

    QUOTA UNLIMITED ON tools;

同时我们要授予 recovery_catalog_owner 权限给用户，该角色拥有管理创建恢复目录的权限。

   SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;

创建恢复目录

在创建恢复目录用户后，使用RMAN建立恢复目录，操作如下:

$ rman

RMAN> CONNECT CATALOG rman/cat@catdb   --以目录用户连接恢复目录库

RMAN> create catalog                         — 建议恢复目录

当然也可以指定使用的表空间：

RMAN> create catalog  tablespace users;

成功建立恢复目录后，可以查询目录下已经存在的目录使用的基表。

SQL>select table_name from user_tables;

2. 管理恢复目录中的目标库记录

ü  在恢复目录中注册目标数据库

ü  在恢复目录中注销目标数据库

ü  在恢复目录中重置数据库

ü  在恢复目录中移除已删除的记录

在恢复目录中注册目标数据库

首先确定恢复目录库已经打开，从目标库主机登录：

$ rman TARGET / CATALOG rman/cat@catdb

若目标库未启动，首先启动到加载模式：

RMAN> STARTUP MOUNT;

注册目标库：

RMAN> REGISTER DATABASE;

RMAN会自动在恢复目录中记录目标库的各种信息,将目标库控制文件中的

元信息复制到恢复目录中，可以使用以下命令确认注册情况：

RMAN> REPORT SCHEMA;

Report of database schema

File Size(MB)   Tablespace       RB segs Datafile Name

---- ---------- ---------------- ------- -------------------

1        307200 SYSTEM             NO    /oracle/oradata/trgt/system01.dbf

2         20480 UNDOTBS            YES   /oracle/oradata/trgt/undotbs01.dbf

3         10240 CWMLITE            NO    ...

在恢复目录中登记备份文件

若有备份文件未在控制文件或恢复目录中存在对应的记录，则需要登记该文件，此处的（control file 为目标数据库control file）。

示例：

RMAN> CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';

RMAN> CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',

     '/disk1/arch_logs/archive1_732.dbf';

RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';

在恢复目录中登记多个目标库

可以在一个恢复目录中注册多个目标库，前提是目标库的DBID唯一。

在恢复目录中注销目标库

可以使用命令： unregister database 在RMAN中注销目标数据库。当数据库被

注销，所有的RMAN记录都会丢失，所以要小心操作。

在恢复目录中移除已经删除的记录

在9i之后版本，RMAN在删除备份文件的同时会删除在恢复目录中的对应物记

录，而9i以前版本则只将对应物记录标志为delete.可以通过运行脚本

prgrmanc.sql来删除对应物记录，该脚本储存在($ORACLE_HOME/rdbms/admin)目

录下。示例如下：

% sqlplus rman/cat@catdb

SQL> @?/rdbms/admin/prgrmanc.sql删过期备份信息

同步恢复目录

当恢复目录当前状态晚于数据库控制文件中的备份信息时，则需要使用同步恢复

目录，这种情况只会出现在一段时间使用恢复目录而一段时间不使用恢复目录的

情况下，造成的时间段差异。RMAN会在您做某些操作时自动完成同步，例如

Backup命令，当然你也可以手动同步： resync catalog .

管理控制文件

数据库参数CONTROL_FILE_RECORD_KEEP_TIME决定了控制文件中记录可能被复

用的最短自然天数，因此你保证恢复目录在此期间完成同步，否则可能控制文件

中的记录丢失，则需要手动登记备份文件。CONTROL_FILE_RECORD_KEEP_TIME有

效期内需要定期同步。

备份恢复目录

备份恢复目录数据库十分重要，若恢复目录数据库丢失则所有的备份信息将丢

失，导致恢复十分困难。

备份恢复目录数据库与一般的数据库没有大的区别，以下为注意事项：

恢复目录数据库因该运行在归档模式下

使用备份策略冗余量大于一

在不同的介质上备份

不使用恢复目录记录备份信息

使用控制文件自动备份，rman中可以自动完成

结构图：

更新恢复目录

若您使用的恢复目录版本低于使用的客户端，则您需要更新恢复目录。举例来说

当前您使用了8.1版的客户端RMAN,而恢复目录是8.0版本的，则需要更新。

当恢复目录版本高于您使用的客户端，则upgrade catalog报错。更新操作实例如

下：

sqlplus> connect sys/oracle@catdb as sysdba;

sqlplus> grant TYPE to rman;

% rman TARGET / CATALOG rman/cat@catdb

UPGRADE CATALOG;

recovery catalog owner is rman

enter UPGRADE CATALOG command again to confirm catalog upgrade

UPGRADE CATALOG;

recovery catalog upgraded to version 09.02.00

DBMS_RCVMAN package upgraded to version 09.02.00

DBMS_RCVCAT package upgraded to version 09.02.00

删除恢复目录

当恢复目录不在需要时可以在所在数据库中彻底删除目录结构和数据，删除将丢

失所有注册过的备份信息，操作要小心。示例操作：

% rman TARGET / CATALOG rman/cat@catdb

Issue the DROP CATALOG command twice to confirm:

DROP CATALOG;

recovery catalog owner is rman

enter DROP CATALOG command again to confirm catalog removal

DROP CATALOG;

Oracle补全日志(Supplemental logging)特性因其作用的不同可分为以下几种：最小(Minimal),支持所有字段(all),支持主键(primary key),支持唯一键(unique),支持外键(foreign key)。包括LONG,LOB,LONG RAW及集合等字段类型均无法利用补全日志。

最小(Minimal)补全日志开启后可以使得logmnr工具支持链式行，簇表和索引组织表。可以通过以下SQL检查最小补全日志是否已经开启：

SELECT supplemental_log_data_min FROM v$database;

若结果返回YES或IMPLICIT则说明已开启最小补全日志，当使用ALL,PRIMARY,UNIQUE或FOREIGN补全日志时最小补全日志默认开启(即检查结果为IMPLICIT)。

一般情况下我们在使用逻辑备库时启用主键和惟一键的补全日志，而有时表上可能没有主键，惟一键或唯一索引；我们通过以下实验总结这种情况下Oracle的表现。

首先建立相关的测试表：

alter database add supplemental log data (primary key,unique index) columns ; create table test (t1 int , t2 int ,t3 int ,t4 int )； alter table test add constraint pk_t1 primary key (t1); –添加主键 随后使用循环插入一定量的数据 update test set t2=10;       commit;   — 更新数据

使用LOGMNR工具分析之前的操作，可以看到REDO中记录的SQL形式如下：

update “SYS”.”TEST” set “T2” = ’10’ where “T1” = ’64’ and “T2” = ’65’ and ROWID = ‘AAAMiSAABAAAOhiAA/’;

其中where字句后分别记录了主键值，被修改字段的值和原行的ROWID。

现在我们将原表上的主键去掉来观察。

alter table test drop constraint pk_t1 ; update test set t2=11;       commit;   — 更新数据 使用LOGMNR分析可以发现，REDO中的SQL记录如下： update “SYS”.”TEST” set “T2” = ’11’ where “T1” = ‘1’ and “T2” = ’10’ and “T3” = ‘3’ and “T4” = ‘4’ and ROWID = ‘AAAMiSAABAAAOhiAAA’;

当没有主键的情况下，where子句后记录了所有列值和ROWID。

以下实验在存在唯一索引情况下的表现 create unique index pk_t1 on test(t1); update test set t2=15; commit; 使用LOGMNR分析可以发现，REDO中的SQL记录如下： update “SYS”.”TEST” set “T2” = ’15’ where “T1” = ‘9’ and “T2” = ’11’ and “T3” = ’11’ and “T4” = ’12’ and ROWID = ‘AAAMiSAABAAAOhiAAI’; 以上是t1列有唯一索引但不限定not null的情况，下面我们加上not null限制 alter table test modify t1 not null； update test set t2=21; commit; 使用LOGMNR分析可以发现，REDO中的SQL记录如下： update “SYS”.”TEST” set “T2” = ’21’ where “T1” = ‘2’ and “T2” = ’15’ and ROWID = ‘AAAMiSAABAAAOhiAAB’;

如以上SQL所示，在存在唯一索引的情况下where子句后仍记录了所有列和ROWID;在存在唯一索引和非空约束的情况下表现与存在主键的情况一致。

当某个表上的列数量较多时且没有主键或唯一索引和非空约束的情况下，开启补全日志可能导致重做日志总量大幅提高。

首先建立一个存在250列的表： Drop table test; create table test ( t1 varchar2(5), t2 varchar2(5), t3 varchar2(5), t4 varchar2(5),  …t250 varchar2(5)) insert into test values (‘TEST’,’TEST’ ……);   commit; –将255个列填入数据 alter database drop supplemental log data (primary key,unique index) columns;  –关闭补全日志 set autotrace on; update test set t2=’BZZZZ’ where t1=’TEST’; commit; 可以从自动跟踪信息中看到，本条更新产生了516的重做量。 alter database add supplemental log data (primary key,unique index) columns；  –重新开启补全日志 update test set t2=’FSDSD’ where t1=’TEST’; 跟踪信息显示产生了3044的重做量。

补全日志因作用域的不同又可分为数据库级的和表级的。表级补全日志又可以分为有条件的和无条件的。有条件限制的表级补全日志仅在特定列被更新时才会起作用，有条件限制的表级补全日志较少使用，这里我们不做讨论。

下面我们来观察无条件限制表级补全日志的具体表现：

alter database drop supplemental log data (primary key,unique index) columns; alter table test add supplemental log data (primary key,unique index) columns; update test set t2=’ZZZZZ’; commit; 使用LOGMNR工具查看redo中的SQL: update “SYS”.”TEST” set “T2” = ‘ZZZZZ’ where “T1” = ‘TEST’ and “T2” = ‘AAAAA’ and “T3” = ‘TEST’……… 可以发现where子句之后包含了所有列值。 delete test; commit; 使用LOGMNR工具查看redo中的SQL: delete from “SYS”.”TEST” where “T1” = ‘TEST’ and “T2” = ‘ZZZZZ’ and “T3” = ‘TEST’ and “T4” = ‘TEST’ and “T5” …… delete操作同样在where子句之后包含了所有列值。 又我们可以针对表上字段建立特定的补全日志组，以减少where子句后列值的出现。 alter table test drop supplemental log data (primary key,unique index) columns;  –关闭表上原先的补全日志 alter table test add supplemental log group test_lgp (t1 ,t2,t3,t4,t5,t6,t12,t250) always; –创建补全日志组 update test set t2=’XXXXX’ ; commit; 使用LOGMNR工具查看redo中的SQL: update “SYS”.”TEST” set “T2” = ‘XXXXX’ where “T1” = ‘TEST’ and “T2” = ‘TEST’ and “T3” = ‘TEST’ and “T4” = ‘TEST’ and “T5” = ‘TEST’ and “T6” = ‘TEST’ and “T12” = ‘TEST’ and “T250” = ‘TEST’ and ROWID = ‘AAAMieAABAAAOhnAAA’; 如上所示重做日志中正确地显示了UPDATE操作中用户指定的字段值。 delete test; 使用LOGMNR工具查看redo中的SQL: delete from “SYS”.”TEST” where “T1” = ‘TEST’ and “T2” = ‘XXXXX’ and “T3” = ‘TEST’ …… delete操作在重做日志中仍然保留了所有列值。

针对字段较多的表，我们在能够以多个列保证数据唯一性且非空的情况下(即应用概念上的主键)来指定表上的补全日志组，以减少update操作时所产生的重做日志，而对于delete操作则无法有效改善。