数据库版本12.1.0.2

首先具体的备份策略是怎样的？每天一个全备吗？

其次想确认一下，为何判断是控制文件过大引起的备份缓慢？

最后缓慢是多慢？能否以命令行的方式给出实际的显示？

可以使用第三方备份软件如NBU、CV等来备份数据库，他有自己专门的catalog数据库用于存储备份信息，源库的控制文件通过设置CONTROL_FILE_RECORD_KEEP_TIME参数记录少量信息即可。

当然也可以自己搭一个catalog库，所有需要备份的数据库共用一个，通过脚本完成备份。

@Kamus您好：

1、备份策略是每天一个level0 级别备份，昨天恢复时使用的是5月8日的level 0 级别备份集 

2、不是备份慢，是恢复慢，控制文件大小53M

3、具体恢复过程如下：

RMAN> startup nomount pfile='/tmp/pfilezxcxdb.ora';

Oracle instance started

Total System Global Area    6442450944 bytes

Fixed Size                     3725224 bytes

Variable Size               1358956632 bytes

Database Buffers            5066719232 bytes

Redo Buffers                  13049856 bytes

RMAN> restore controlfile from '/data/20190509/DB/ZXCX_dqu13btv_1_1_20190509_11706.ctl';

Starting restore at 2019-05-22 20:51:51

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=680 device type=DISK

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

output file name=/data/oradata/zxcx/controlfile/control01.ctl

Finished restore at 2019-05-22 20:51:53

RMAN> alter database mount;

Statement processed

released channel: ORA_DISK_1

RMAN> catalog start with '/data/20190509/DB/';

Starting implicit crosscheck backup at 2019-05-22 20:53:07

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=198 device type=DISK

......

等待了2小时，命令一直没有响应

由于catalog库跟恢复服务器物理隔离，所以将catalog库的用户导出到跟恢复服务器同一网络上的一台机器后，使用rman target / catalog xxx/xxx@catadb进行恢复，同样使用的以上catalog start with命令，以及后期的restore database命令，都比较快，30分钟整库恢复完成（库大小10G以内）

首先你既然只是用控制文件存储了备份信息，而没有使用catalog库，那么实际上在恢复的时候，是不需要做catalog start with操作的，难道直接list backup里面没有你想恢复的备份集吗？

对于catalog start with这样的操作，我本人的经验很少，不确认这一步是不是会由于控制文件较大而很缓慢（实际上50多MB的控制文件也并不算很大），那么有以下建议。

1. 跳过catalog start with，直接做recover database，看看耗时如何？

2. 在数据库的等待事件里看一下，rman进程在catalog start with的时候处于什么等待中，有助于判断为何catalog start with缓慢

3. 按照章芋文的建议，可以设置源库的CONTROL_FILE_RECORD_KEEP_TIME参数，以减少在控制文件中存储的内容，但是根据你提供的数据库在10GB大小左右，可以判断其实数据文件并没有多少，按理说这个数量不至于影响到2个小时没有反应的情况

4. 还可以优化备份策略，比如无需每天level 0备份，在中间增加一些level 1的备份