- 最后登录
- 2017-5-4
- 在线时间
- 81 小时
- 威望
- 999
- 金钱
- 2391
- 注册时间
- 2013-9-11
- 阅读权限
- 150
- 帖子
- 1124
- 精华
- 5
- 积分
- 999
- UID
- 1220
|
1#
发表于 2013-10-15 00:53:13
|
查看: 3053 |
回复: 0
数据库打开遇到ORA-1122 使用隐藏参数打开数据库一例
.数据库正常打开报错ORA-1122
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. 建议定期(每天)查看数据库备份的日志,做到及时处理备份失败。
|
|