Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

999

积分

1

好友

942

主题
1#
发表于 2013-10-15 00:53:13 | 查看: 3083| 回复: 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. 建议定期(每天)查看数据库备份的日志,做到及时处理备份失败。

下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569     邮箱:service@parnassusdata.com
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-23 15:36 , Processed in 0.046469 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569