11g中关于控制文件自动备份的改进
在之前做一个测试演示的时候，使用的是11gR2的库，在说rman的备份配置的时候有一个功能时控制文件的自动备份，
CONFIGURE CONTROLFILE AUTOBACKUP ON/OFF;
然后自己简单介绍了下，说controlfile autobackup功能还是蛮实用的，一般还是建议开启。之前自己在10g的环境中也测试过，印象中数据库级的一些操作，比如创建表空间，删除数据文件等等，都会重新生成对应的控制文件，然而在演示的时候，竟然还是掉了链子。
我们创建了一个表空间，没有自动备份控制文件，然后我们又创建了一个表空间，还是没有生成备份控制文件，在短时间内做了几个操作，都没有生成控制文件的备份，自己都有点怀疑数据库是不是故意不配合啊。如果这样，rman里面配置控制文件的自动备份感觉就没有什么实际意义了。
回来后，自己找了套10gR2的库，做了同样的操作，这个时候autobackup的功能又好使了。
我们短时间内创建了一个表空间，然后删除，然后再创建。
SQL> create tablespace data3 datafile '/u02/oracle/oradata/TEST10G/data03.dbf' size 5M;1
Tablespace created.
SQL> drop tablespace data3;
Tablespace dropped.
SQL> create tablespace data3 datafile '/u02/oracle/oradata/TEST10G/data03.dbf' size 5M reuse;
Tablespace created.
查看控制文件的备份路径，发现生成了3个对应的控制文件备份。尽管大小都一样。-rw-r----- 1 oracle dba 14745600 Aug 8 23:16 ctl_c-1135735312-20150808-0d
-rw-r----- 1 oracle dba 14745600 Aug 8 23:17 ctl_c-1135735312-20150808-0e
-rw-r----- 1 oracle dba 14745600 Aug 8 23:17 ctl_c-1135735312-20150808-0f
这个时候就有些疑惑，倒底在演示的环境和自己之后测试环境有哪些不同之处，翻来覆去找差别，也做了一些测试，发现原来还是数据库版本的不同。
在10g的版本中，开启控制文件的自动备份，这个时候发生了创建表空间，数据文件变更的操作时，会立即生成控制文件的备份。
当然在11g里面也不是不生成控制文件，在一定的时候之后，查看备份目录还是会生成一个备份控制文件。所以控制文件自动备份功能还是起作用的，但是似乎还是有一定的延迟。
对于这个问题，没有立刻就查看官方文档求证，自己从一些trace日志里面挖掘挖掘，看看有什么发现。
结果我把延时创建的控制文件的时间戳和关键字在trace文件里搜了一圈，发现有一个文件中刚好有我需要找的内容。
less TEST_m000_6627.trc
Starting control autobackup
*** 2015-08-01 21:11:08.014
Control autobackup written to DISK device
handle '/u02/ora11g/flash_recovery_area/TEST/ctl_c-2182319634-20150801-10'
通过日志就能够看到，后台是开始做了一个autobackup的操作，
这个时候查看了metalink，找到一篇相关的文章。
RMAN CONTROLFILE AUTOBACKUP NOT CREATED DURING DB STRUCTURE CHANGE (文档 ID 1068182.1)
在这篇文章中解释了这个延时的原因，还是基于性能的考虑。避免因为大量的数据库级变更产生了大量的控制文件备份。‘
官方的解释还是比较详细的。会在后台触发MMON去做控制文件的自动备份。
FIX
In order to increase performance the controlfile autobackup creation after structural changes, has been deferred.
In previous releases, one controlfile autobackup is created with each DDL command that makes structural changes in the database and we can see in the alert.log a message about controlfile autobackup creation after each DDL command executed. This can provoke serious performance problems when multiple structural changes are made together.
From Oracle Database Release 11g Release 2, RMAN takes only one control file autobackup when multiple structural changes contained in a script have been applied (for example, adding tablespaces, altering the state of a tablespace or datafile, adding a new online redo log, renaming a file, and so on ) .
In this release, the controlfile autobackups are created by MMON slaves after few minutes of the structural changes, which increases performance.
So, It's the expected behaviour to get the controlfile autobackup several minutes after the structural change on the database and it's also expected that no message about controlfile autobackup creation will appear in the alert.log.
There will be generated one MMON slave trace file with the controlfile creation information, that will be a file named:
SID__m000_<OS_PID>.trc
当然我们可以更近一步，比如我们知道控制文件备份是一个延时的过程，那么这个延时的默认值是多少呢，是5分钟。
1 select a.ksppinm name, b.ksppstvl value, a.ksppdesc description
2 from x$ksppi a, x$ksppcv b
3* where a.indx = b.indx and a.ksppinm like '%control%delay%'
NAME VALUE DESCRIPTION
------------------------------ -------------------- --------------------------------------------------------------------------------
_controlfile_autobackup_delay 300 time delay (in seconds) for performing controlfile autobackups
所以通过这个案例我们可以发现很多时候在10g的基础上还是做了很多的改进和优化，很多功能的细节之中都加入了更多的考量，从这一点上来说，控制文件的延时自动备份还是合理的。
我们在分析这个问题的时候，还是需要细心，自己主动去发现问题，自己先去求证，再查看官方的解释，没准就会有意外的收获。