客户的STANDBY丢了归档，为了不重搭建库，我尝试了下使用RMAN增量备份前滚STANDBY数据库
具体参考Rolling a Standby Forward using an RMAN Incremental Backup in 9i [ID 290817.1]，10g也适用

步骤很简单：
1.搭建一个CATALOG
2.把主库注册到CATALOG服务器中，退出
3.连接备库，CATALOG库，把备库中的数据文件作为datafilecopy ，catalog起来。注意，这里要给这些datafilecopy赋予一个TAG
4.连接主库，CATALOG库，基于上一步catalog进去的TAG，做LEVEL 1的增量备份
5.把备份集传递到备库
6.连接备库，CATALOG库，做恢复
7.注销到这些备份相关的备份集，文件。

说说在这个过程中遇到的错误

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03012: fatal error during compilation of command
RMAN-03028: fatal error code for command recover : 600
RMAN-00600: internal error, arguments [5041] [25] [########################################] [253555081] []

ML了一把没收获
后来发现这个错是因为我在主库做增量BACKUP的时候，没注册24号文件，所以该文件做的全备，无法找到该文件的增量备份。
参数1要减去1才代表file_id;

后来又出这个错
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 07/13/2010 12:44:59
ORA-00600: internal error code, arguments: [2130], [106], [100], [4], [], [], [], []

ML了一把，有个相关的 Bug 4214213 - OERI[2130] can occur when recovering a standby database [ID 4214213.8]
但是该BUG应该10201就修复了
第一个参数106应该是指file_id，测试了下，跑106的时候报错,去掉106，恢复了几个又报错
第一个感觉是，第二个参数100，是指控制文件中的文件数限制，backup cf to trace看，果然，限制是100.看了下trc，恢复进程最后的等待是control file sequential read
说明其在读取控制文件时，发生了错误，估计是这个问题；客户本来这次就新增了很多表空间，可能STANDBY的控制文件在restore的时候不能自动扩展
从主库重新生成了1个stb cf，拷贝过来用，就OK了

如果库不大，还是重搭的好，妈的问题太多了，不如重搭方便