请问一个关于恢复控制文件的奇怪问题~！每次都提示我CF比DBF会旧

请问一个关于恢复控制文件的奇怪问题~！每次都提示我CF比DBF会旧，好奇怪，我的具体操作步骤如下：
1.走脚本和backup database全备到vtl、物理带库与本地
2.关闭 immediate
3.删除CF
4.startup nomount
5.restor cf或者走脚本把cf恢复
6.alter database mount；
7.alter database open 时提示我要resetlog或者noreset
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done


SQL> recover database using backup controlfile until cancel;
ORA-00279: change 8209762987492 generated at 09/03/2010 11:19:47 needed for
thread 1
ORA-00289: suggestion : /data1/oracle/dbs/arch/0000000077_0001.log
ORA-00280: change 8209762987492 for thread 1 is in sequence #77


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/sandata/cs_test/testg1/logfile/redo02.log
ORA-00310: archived log contains sequence 88; sequence 77 required
ORA-00334: archived log: '/sandata/cs_test/testg1/logfile/redo02.log'


ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/sandata/cs_test/testg1/datafile/system01.dbf'

然后这样都是这个问题~！提示我cf比dbf旧，然也我查过他们2个文件的scn和cnt都一样啊，加上关库之后不是SCN和CNT不会变化吗？在MOUNT的状体也不会变化啊~！请问是什么问题怎样恢复过来呢？我只能重建CF·！谢谢

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/home/oracle/orabase/oradata/ORACLE/system01.dbf'


SQL>  select file#, status, checkpoint_change# from v$datafile;

     FILE# STATUS  CHECKPOINT_CHANGE#
---------- ------- ------------------
         1 SYSTEM              829375
         2 ONLINE              829375
         3 ONLINE              829375
         4 ONLINE              829375

SQL>  select file#, status, fuzzy, checkpoint_change# from v$datafile_header;

     FILE# STATUS  FUZ CHECKPOINT_CHANGE#
---------- ------- --- ------------------
         1 ONLINE  NO              830705
         2 ONLINE  NO              830705
         3 ONLINE  NO              830705
         4 ONLINE  NO              830705

仔细看看   scn是不一致的

你这种测试方式，通过restore这种方式是有问题的，恢复的控制文件必然与数据文件不一致

通过重建控制文件方式是最简单的恢复方式

那为什么会做成不一致的呢？

数据库关闭后   要统一scn的

你的备份是在关闭之前形成的啊  所以必然不一致的