ORA-01207:文件比控制文件更新 – 旧的控制文件 解决一例

ORA-01207:文件比控制文件更新 – 旧的控制文件 解决一例

ORA-01207: file is more recent than control file – old control file
Cause: The control file change sequence number in the data file is greater than the number in the control file. This implies that the wrong control file is being used. Note that repeatedly causing this error can make it stop happening without correcting the real problem. Every attempt to open the database will advance the control file change sequence number until it is great enough.
Action: Use the current control file or do backup control file recovery to make the control file current. Be sure to follow all restrictions on doing a backup control file recovery.

 

数据库打开遇到ORA-1207 使用隐藏参数打开数据库一例

.数据库正常打开报错ORA-01207

 

 

SQL> startup ;
ORACLE instance started.

Total System Global Area 4294967296 bytes
Fixed Size                  2074696 bytes
Variable Size             570427320 bytes
Database Buffers         3707764736 bytes
Redo Buffers               14700544 bytes
Database mounted.
ORA-01122: database file 10 failed verification check
ORA-01110: data file 10: '/dev/vg/rraw_db_ptn_indx_034_4096M'
ORA-01207: file is more recent than control file - old control file


2.首先,oracle工程师尝试使用备份进行恢复，不过经过仔细检查发现某些数据文件备份存在问题。

select FILE# from v$recover_file;

     FILE#
----------
        23
        46
        49
        95
        96
        97
        98
        99
       100
       101
       102
       103
       104
       105
       106
       107
       108
       109
       110
       111
       112
       113
       114
       115
       116
       117
       118

RMAN> list backup of datafile 98;
无。

查看之前备份的日志： /nsr/applogs/msglog.log

piece handle=/CRMFull_1_1_725150041_56186 tag=TAG20100723T210601 comment=API Version 2.0,MMS Version 4.1.0.0
channel c2: backup set complete, elapsed time: 00:23:43
channel c2: starting full datafile backupset
channel c2: specifying datafile(s) in backupset
input datafile fno=00023 name=/dev/vg_rac_dat/rraw_db_bas_indx_032_6008m
input datafile fno=00098 name=/dev/vg/rraw_db_ptn_data_014_4096M
input datafile fno=00046 name=/dev/vg_rac_dat/rraw_db_mps_indx_014_3008m
channel c2: starting piece 1 at 23-JUL-10
channel c5: finished piece 1 at 23-JUL-10
piece handle=/CRMFull_1_1_725149815_56183 tag=TAG20100723T210601 comment=API Version 2.0,MMS Version 4.1.0.0
channel c5: backup set complete, elapsed time: 00:29:24
channel c5: starting full datafile backupset
channel c5: specifying datafile(s) in backupset
input datafile fno=00024 name=/dev/vg_rac_dat/rraw_db_bas_indx_033_6008m
input datafile fno=00099 name=/dev/vg/rraw_db_ptn_data_015_4096M
input datafile fno=00047 name=/dev/vg_rac_dat/rraw_db_mps_indx_021_3008m
channel c5: starting piece 1 at 23-JUL-10
channel c7: finished piece 1 at 23-JUL-10
piece handle=/CRMFull_1_1_725148759_56173 tag=TAG20100723T210601 comment=API Version 2.0,MMS Version 4.1.0.0
channel c7: backup set complete, elapsed time: 00:47:01
channel c7: starting full datafile backupset
channel c7: specifying datafile(s) in backupset
input datafile fno=00025 name=/dev/vg_rac_dat/rraw_db_bas_indx_034_6008m
input datafile fno=00100 name=/dev/vg/rraw_db_ptn_data_021_4096M
input datafile fno=00048 name=/dev/vg_rac_dat/rraw_db_mps_indx_022_3008m
channel c7: starting piece 1 at 23-JUL-10
channel c10: finished piece 1 at 23-JUL-10
piece handle=/CRMFull_1_1_725148854_56174 tag=TAG20100723T210601 comment=API Version 2.0,MMS Version 4.1.0.0
channel c10: backup set complete, elapsed time: 00:46:31
channel c3: finished piece 1 at 23-JUL-10
piece handle=/CRMFull_1_1_725150157_56187 tag=TAG20100723T210601 comment=API Version 2.0,MMS Version 4.1.0.0
channel c3: backup set complete, elapsed time: 00:25:33

user interrupt received
Finished backup at 23-JUL-10
released channel: c1
released channel: c2  - channel 2 并没有完成工作！！ 由于Legato 备份前端退出。
released channel: c3
released channel: c4
released channel: c5
released channel: c6
released channel: c7
released channel: c8
released channel: c9
released channel: c10
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03099: job cancelled at user request

备份失败原因分析：
Legato 退出的原因还需要由其原厂家去确认。我们目前认为可能情况：
当前rman备份脚本中allocate channel的个数为10个，偏高，如果当前还有其他系统在使用昆腾的带库(8个driver)的某些driver, 那么可能存在 等待driver的timeout 。从而最终导致legato 备份主动退出。

3.使用方案2，进行重建控制文件、使用隐含参数强制将数据库打开。

CRM数据库：

— 重建控制文件

sql>
startup nomount;

CREATE CONTROLFILE REUSE DATABASE "CRM" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 192
    MAXLOGMEMBERS 3
    MAXDATAFILES 1024
    MAXINSTANCES 32
    MAXLOGHISTORY 4672
..................
-- Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');


RECOVER DATABASE USING BACKUP CONTROLFILE;
-- Create log files for threads other than thread one.
ALTER DATABASE ADD LOGFILE THREAD 2
  GROUP 5 (
    '/dev/vg_rac_sys/rraw_db_redo_251_208m',
    '/dev/vg_rac_sys/rraw_db_redo_252_208m'
  ) SIZE 200M REUSE,
  GROUP 6 (
    '/dev/vg_rac_sys/rraw_db_redo_261_208m',
    '/dev/vg_rac_sys/rraw_db_redo_262_208m'
  ) SIZE 200M REUSE,
  GROUP 7 (
    '/dev/vg_rac_sys/rraw_db_redo_271_208m',
    '/dev/vg_rac_sys/rraw_db_redo_272_208m'
  ) SIZE 200M REUSE,
  GROUP 8 (
    '/dev/vg_rac_sys/rraw_db_redo_281_208m',
    '/dev/vg_rac_sys/rraw_db_redo_282_208m'
  ) SIZE 200M REUSE;
  
-- Database can now be opened zeroing the online logs.

ALTER DATABASE OPEN RESETLOGS;

--此时会提示：

ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/dev/vg_rac_sys/rraw_db_system_2008m'

-- 尝试使用隐含参数：

SQL> create pfile='/tmp/1.ora' from spfile;


在参数文件/tmp/1.ora 中设定：

_allow_resetlogs_corruption=true
_offline_rollback_segments=(_SYSSMU1$,_SYSSMU10$,_SYSSMU11$,_SYSSMU12$,_SYSSMU13$,_SYSSMU14$,_SYSSMU15$,_SYSSMU16$,_SYSSMU17$,_SYSSMU18$,_SYSSMU19$,_SYSSMU2$,_SYSSMU20$,_SYSSMU21$,_SYSSMU22$,_SYSSMU23$,_SYSSMU24$,_SYSSMU25$,_SYSSMU26$,_SYSSMU27$,_SYSSMU28$,_SYSSMU29$,_SYSSMU3$,_SYSSMU30$,_SYSSMU31$,_SYSSMU32$,_SYSSMU33$,_SYSSMU34$,_SYSSMU35$,_SYSSMU36$,_SYSSMU37$,_SYSSMU38$,_SYSSMU39$,_SYSSMU4$,_SYSSMU40$,_SYSSMU41$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$)
_corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU10$,_SYSSMU11$,_SYSSMU12$,_SYSSMU13$,_SYSSMU14$,_SYSSMU15$,_SYSSMU16$,_SYSSMU17$,_SYSSMU18$,_SYSSMU19$,_SYSSMU2$,_SYSSMU20$,_SYSSMU21$,_SYSSMU22$,_SYSSMU23$,_SYSSMU24$,_SYSSMU25$,_SYSSMU26$,_SYSSMU27$,_SYSSMU28$,_SYSSMU29$,_SYSSMU3$,_SYSSMU30$,_SYSSMU31$,_SYSSMU32$,_SYSSMU33$,_SYSSMU34$,_SYSSMU35$,_SYSSMU36$,_SYSSMU37$,_SYSSMU38$,_SYSSMU39$,_SYSSMU4$,_SYSSMU40$,_SYSSMU41$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$)
undo_management = MANUAL

#### 尝试打开数据库

shutdown immediate;
startup nomount pfile='/tmp/1.ora';
alter database mount;
alter database open resetlogs;

ALTER TABLESPACE TEMP ADD TEMPFILE '/dev/vg_rac_sys/rraw_db_temp_10008m' REUSE;
-- End of tempfile additions.
## 重建undo tablespace
drop tablespace undotbs1;
drop tablespace undotbs2;

create undo tablespace undotbs1 datafile '/dev/vg_rac_sys/rraw_db_undo01_8008m' reuse;         
create undo tablespace undotbs2 datafile '/dev/vg_rac_sys/rraw_db_undo02_8008m' reuse;

shutdown immediate;
startup nomount;
alter system set cluster_database=true scope=spfile;
shutdown immediate;
startup;




oradb数据库:

-- 重建控制文件

sql>
alter system set cluster_database=false scope=spfile;
CREATE CONTROLFILE REUSE DATABASE "oradb" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 192
    MAXLOGMEMBERS 3
    MAXDATAFILES 1024
    MAXINSTANCES 32
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/dev/vg_rac_sys/roradb_redo1_1_raw_120m'  SIZE 120M,
  GROUP 2 '/dev/vg_rac_sys/roradb_redo1_2_raw_120m'  SIZE 120M
-- STANDBY LOGFILE
DATAFILE
  '/dev/vg_rac_sys/roradb_system_raw_500m',

;
-- Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');


RECOVER DATABASE USING BACKUP CONTROLFILE;
-- Create log files for threads other than thread one.

ALTER DATABASE ADD LOGFILE THREAD 2
  GROUP 3 '/dev/vg_rac_sys/roradb_redo2_1_raw_120m' SIZE 120M REUSE,
  GROUP 4 '/dev/vg_rac_sys/roradb_redo2_2_raw_120m' SIZE 120M REUSE;  
-- Database can now be opened zeroing the online logs.

ALTER DATABASE OPEN RESETLOGS;

--此时会提示：

ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/dev/vg_rac_sys/roradb_system_raw_500m'

-- 尝试使用隐含参数：

SQL> create pfile='/tmp/2.ora' from spfile;


在参数文件/tmp/2.ora 中设定：

_allow_resetlogs_corruption=true
_offline_rollback_segments=(_SYSSMU1$,_SYSSMU10$,_SYSSMU11$,_SYSSMU12$,_SYSSMU13$,_SYSSMU14$,_SYSSMU15$,_SYSSMU16$,_SYSSMU17$,_SYSSMU18$,_SYSSMU19$,_SYSSMU2$,_SYSSMU20$,_SYSSMU21$,_SYSSMU22$,_SYSSMU23$,_SYSSMU24$,_SYSSMU25$,_SYSSMU26$,_SYSSMU27$,_SYSSMU28$,_SYSSMU29$,_SYSSMU3$,_SYSSMU30$,_SYSSMU31$,_SYSSMU32$,_SYSSMU33$,_SYSSMU34$,_SYSSMU35$,_SYSSMU35,$,_SYSSMU36$,_SYSSMU37$,_SYSSMU38$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$)
_corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU10$,_SYSSMU11$,_SYSSMU12$,_SYSSMU13$,_SYSSMU14$,_SYSSMU15$,_SYSSMU16$,_SYSSMU17$,_SYSSMU18$,_SYSSMU19$,_SYSSMU2$,_SYSSMU20$,_SYSSMU21$,_SYSSMU22$,_SYSSMU23$,_SYSSMU24$,_SYSSMU25$,_SYSSMU26$,_SYSSMU27$,_SYSSMU28$,_SYSSMU29$,_SYSSMU3$,_SYSSMU30$,_SYSSMU31$,_SYSSMU32$,_SYSSMU33$,_SYSSMU34$,_SYSSMU35$,_SYSSMU35,$,_SYSSMU36$,_SYSSMU37$,_SYSSMU38$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$)
undo_management = MANUAL
#### 尝试打开数据库

shutdown immediate;
startup nomount pfile='/tmp/2.ora';
alter database mount;
alter database open resetlogs;
ALTER TABLESPACE TEMP ADD TEMPFILE '/dev/vg_rac_sys/roradb_temp_raw_250m' REUSE;

## 重建undo tablespace

drop tablespace undotbs1;
drop tablespace undotbs2;
create undo tablespace undotbs1 datafile '/dev/vg_rac_sys/roradb_undotbs1_raw_500m' reuse;         
create undo tablespace undotbs2 datafile '/dev/vg_rac_sys/roradb_undotbs2_raw_500m' reuse;
shutdown immediate;
startup nomount;
alter system set cluster_database=true scope=spfile;
shutdown immediate;
startup;



4.接下来，对数据库中表数据进行验证。

检查 用户 的表的count记录数

select 'select count(*) from '||owner||'.'||table_name||' ;' from dba_tables where owner in ('用户名') ;

运行[上述查询结果！]

发现2张损坏的表，并在后面重建



5.再接下来，对CRM,oradb进行了备份。
在磁带备份时，长时间没有写入，所以首先有个完整的备份，我们先将CRM,oradb数据库备份到cx的文件系统中。

/backvg/rman_target/CRM
/backvg/rman_target/oradb



      6.最后，为这次故障做总结，给出建议到用户。


建议：

1.数据库的容灾切换方案充分论证存在必要。
2.建议将当前cx存储上的裸设备迁移到dmx950上 ，从而使得dmx950能够与dmx800 进行完整的srdf容灾。
大概步骤：
1.）首先找出“CRM”,“oradb”数据库中存放在cx上的datafile
select file#,name from v$datafile where  name like '%vg%';

如：
file#   name
----     -------
98        /dev/vg/rraw_db_ptn_data_013_4096M
99        ...
100        ...
       
          其中： raw_db_ptn_data_013_4096M 为 lv的名字。

2）.shutdown immediate “CRM”,“oradb”数据库
3）.将vg 改名为 vg_old
4) .清理出2个节点上存放archive log 的文件系统。并将这2个盘，重新创建一个concurrent的卷组，卷组名为vg，并在这个新卷组上创建在步骤1中列出的lv的名字（/dev/vg/rraw_db_ptn_data_013_4096M）
5) .以vg_old 中裸设备为源，dd 到新创建的vg 中(所有在步骤1中列出的)

示例：
dd if=/dev/vg_old/rraw_db_ptn_data_013_4096M of=/dev/vg/rraw_db_ptn_data_013_4096M bs=1m

6). vg中的裸设备赋予oracle:dba 访问权限。
7). 在2台主机上创建基于cx磁盘的文件系统作为归档使用，并赋予oracle:dba 访问权限。
8). 打开数据库。

3. 建议当此前带库的备份脚本中allocate channel的个数(当前10个 -> 4或6个)，并建议legato备份软件中查看并优化驱动器获得的timeout 值。
4. 建议定期（每天）查看数据库备份的日志，做到及时处理备份失败。