Oracle备份恢复 – 专业Oracle数据库恢复，或许是您恢复数据的最后机会@phone: - 专业Oracle数据库恢复技术支持 | Page 16
专业Oracle数据库恢复，或许是您恢复数据的最后机会@phone:
在ORACLE 12C中对rman的功能有了不少增强,在以前的文章中写过功能,这里另外补充rman增强的两个小功能(sql语句和数据文件分割)
数据库版本
select * from v$
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
12.1.0.1.0
Production
TNS for Linux: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
rman对sql语句支持增强
[oracle@xifenfei tmp]$ rman target /
Recovery Manager: Release 12.1.0.1.0 - Production on Sat Jun 1 14:07:50 2013
Copyright (c) , Oracle and/or its affiliates.
All rights reserved.
connected to target database: CDB (DBID=)
RMAN& sele
using target database control file instead of recovery catalog
RMAN& alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
Statement processed
-------------------
RMAN& desc v$log
----------------------------------------- -------- ----------------------------
VARCHAR2(3)
VARCHAR2(16)
FIRST_CHANGE#
FIRST_TIME
NEXT_CHANGE#
这里看到rman只是sql语句中的select和desc用法
rman分割数据文件增强
CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored
RMAN& backup incremental level 1 section size 30M datafile 1 format '/tmp/system_%U.rman';
Starting backup at 01-JUN-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=27 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=269 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=24 device type=DISK
no parent backup or copy of datafile 1 found
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA/cdb/system01.dbf
backing up blocks 1 through 3840
channel ORA_DISK_1: starting piece 1 at 01-JUN-13
channel ORA_DISK_2: starting incremental level 1 datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA/cdb/system01.dbf
……………………
backing up blocks 96001 through 99840
channel ORA_DISK_3: starting piece 26 at 01-JUN-13
channel ORA_DISK_1: finished piece 24 at 01-JUN-13
piece handle=/tmp/system_02ob3pg1_24_1.rman tag=TAG518 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:08
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA/cdb/system01.dbf
backing up blocks 99841 through 101120
channel ORA_DISK_1: starting piece 27 at 01-JUN-13
channel ORA_DISK_2: finished piece 25 at 01-JUN-13
piece handle=/tmp/system_02ob3pg1_25_1.rman tag=TAG518 comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:00:07
channel ORA_DISK_3: finished piece 26 at 01-JUN-13
piece handle=/tmp/system_02ob3pg1_26_1.rman tag=TAG518 comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:06
channel ORA_DISK_1: finished piece 27 at 01-JUN-13
piece handle=/tmp/system_02ob3pg1_27_1.rman tag=TAG518 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 01-JUN-13
备份文件情况
[oracle@xifenfei tmp]$ ll -ltr system*
-rw-r----- 1 oracle dba
1 14:45 system_02ob3pg1_1_1.rman
-rw-r----- 1 oracle dba
9535488 Jun
1 14:45 system_02ob3pg1_2_1.rman
-rw-r----- 1 oracle dba
1 14:45 system_02ob3pg1_4_1.rman
-rw-r----- 1 oracle dba
1 14:45 system_02ob3pg1_3_1.rman
-rw-r----- 1 oracle dba
1 14:45 system_02ob3pg1_5_1.rman
-rw-r----- 1 oracle dba
1 14:45 system_02ob3pg1_6_1.rman
-rw-r----- 1 oracle dba
1 14:46 system_02ob3pg1_7_1.rman
-rw-r----- 1 oracle dba
1 14:46 system_02ob3pg1_8_1.rman
-rw-r----- 1 oracle dba
1 14:46 system_02ob3pg1_9_1.rman
-rw-r----- 1 oracle dba
1 14:46 system_02ob3pg1_11_1.rman
-rw-r----- 1 oracle dba
1 14:46 system_02ob3pg1_10_1.rman
-rw-r----- 1 oracle dba
1 14:46 system_02ob3pg1_12_1.rman
-rw-r----- 1 oracle dba
1 14:46 system_02ob3pg1_13_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_14_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_15_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_17_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_16_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_18_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_19_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_20_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_21_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_22_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_23_1.rman
-rw-r----- 1 oracle dba
1 14:47 system_02ob3pg1_24_1.rman
-rw-r----- 1 oracle dba
1 14:48 system_02ob3pg1_25_1.rman
-rw-r----- 1 oracle dba
1 14:48 system_02ob3pg1_26_1.rman
-rw-r----- 1 oracle dba
6291456 Jun
1 14:48 system_02ob3pg1_27_1.rman
在12C之前的版本，ORACLE 11GR2只是对于全备的备份集备份(非增量,非copy备份方式)方式支持数据文件分割备份功能,对于11.2之前的版本均不支持该功能.在12C中rman可以支持对于全备,增量备份,copy备份全部支持分割数据文件备份(CONTROLFILE,SPFILE不支持)
Posted in ,
在有些情况下,我们仅有一份rman备份,而这个时候rman 备份有出现坏块,使得我们的还原/恢复工作无法继续下去,导致数据大量丢失.我们可以通过设置event 来跳过坏块,最大程度抢救数据
rman备份数据文件
C:\Users\XIFENFEI&rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Thu Jun 6 20:31:19 2013
Copyright (c) , Oracle and/or its affiliates.
All rights reserved.
connected to target database: XIFENFEI (DBID=)
RMAN& backup tablespace users format 'f:/users_bak.rman';
Starting backup at 06-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=197 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00004 name=E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF
channel ORA_DISK_1: starting piece 1 at 06-JUN-13
channel ORA_DISK_1: finished piece 1 at 06-JUN-13
piece handle=F:\USERS_BAK.RMAN tag=TAG154 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 06-JUN-13
切换归档日志
SQL& alter s
System altered.
System altered.
System altered.
Database log mode
Archive Mode
Automatic archival
Archive destination
E:\oracle\product\11.2.0\dbhome_1\RDBMS
Oldest online log sequence
Next log sequence to archive
Current log sequence
重命名数据文件
SQL& shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
--------------------------------------
e:\oracle\oradata\XIFENFEI&move USERS01.DBF USERS01_bak.DBF
1 个文件。
--------------------------------------
SQL& startup
ORACLE instance started.
Total System Global Area
Fixed Size
1385052 bytes
Variable Size
Database Buffers
Redo Buffers
6053888 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF'
破坏备份集
这里很明显,我通过ue把rman备份集中的T修改为了A,肯定破坏了文件,使之出现坏块
rman还原数据文件
C:\Users\XIFENFEI&rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Thu Jun 6 21:02:41 2013
Copyright (c) , Oracle and/or its affiliates.
All rights reserved.
connected to target database: XIFENFEI (DBID=, not open)
RMAN& restore datafile 4;
Starting restore at 06-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=63 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00004 to E:\ORACLE\ORADATA\XIFENFEI\USERS
channel ORA_DISK_1: reading from backup piece F:\USERS_BAK.RMAN
channel ORA_DISK_1: ORA-19870: error while restoring backup piece F:\USERS_BAK.R
ORA-19612: datafile 4 not restored due to missing or corrupt data
failover to previous backup
creating datafile file number=4 name=E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF
Finished restore at 06-JUN-13
这里可以清晰的看到rman报ORA-19612错误，restore 失败,alert日志为:
Thu Jun 06 21:02:31 2013
ALTER DATABASE OPEN
Errors in file E:\ORACLE\diag\rdbms\xifenfei\xff\trace\xff_dbw0_7400.trc:
ORA-01157: ????/?????? 4 - ??? DBWR ????
ORA-01110: ???? 4: 'E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF'
ORA-27041: ??????
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Errors in file E:\ORACLE\diag\rdbms\xifenfei\xff\trace\xff_ora_4272.trc:
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF'
ORA-1157 signalled during: ALTER DATABASE OPEN...
Thu Jun 06 21:02:33 2013
Checker run found 1 new persistent data failures
Thu Jun 06 21:03:23 2013
Corrupt block 101 found during reading backup piece, file=F:\USERS_BAK.RMAN, corr_type=3
Reread of blocknum=101, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=101, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=101, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=101, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=101, file=F:\USERS_BAK.RMAN, found same corrupt data
Continuing reading piece F:\USERS_BAK.RMAN, no other copies available.
rman备份集有坏块，导致rman还原无法正常进行下去,还原后的数据文件大小
观察已经正常还原出来数据文件情况
SQL& select CHECKPOINT_CHANGE#,file# from v$datafile_
CHECKPOINT_CHANGE#
------------------ ----------
SQL& recover database datafile 4 ;
ORA-00274: illegal recovery option DATAFILE
SQL& recover datafile 4;
ORA-00279: change 18379 generated at 01/20/:56 needed for thread 1
ORA-00289: suggestion :
E:\ORACLE\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC_.0001
ORA-00280: change 18379 for thread 1 is in sequence #1
Specify log: {&RET&=suggested | filename | AUTO | CANCEL}
rman只是还原了很小的一部分文件,做恢复提示需要从归档日志seq 1开始(某些情况可能需要其他归档,总之不是正常情况),证明rman还原异常
设置event事件还原
ORACLE instance shut down.
SQL& startup pfile='e:/pfile.txt'
ORACLE instance started.
Total System Global Area
Fixed Size
1385052 bytes
Variable Size
Database Buffers
Redo Buffers
6053888 bytes
Database mounted.
------------------------------------ ----------- ------------------------------
19548 trace name context forev
er, 19549 trace name context f
Event 19548:This will attempt to restore content of the corrupted block if it is possible.
Event 19549:This will suppress erroring out during restore
rman还原数据文件
RMAN& restore datafile 4;
Starting restore at 06-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=63 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00004 to E:\ORACLE\ORADATA\XIFENFEI\USERS
channel ORA_DISK_1: reading from backup piece F:\USERS_BAK.RMAN
channel ORA_DISK_1: piece handle=F:\USERS_BAK.RMAN tag=TAG154
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 06-JUN-13
这里证明数据库rman有坏块通过rman还原成功,alert日志提示如下
Thu Jun 06 21:29:53 2013
WARNING: The block that appears to be block number 100
in file 4 is corrupt in backup piece F:\USERS_BAK.RMAN.
Such blocks would usually be formatted as empty
in the restored file, but event 19548 has been
set to include the block as-is in the restored
Corrupt block 102 found during reading backup piece, file=F:\USERS_BAK.RMAN, corr_type=-2
Reread of blocknum=102, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=102, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=102, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=102, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=102, file=F:\USERS_BAK.RMAN, found same corrupt data
Continuing reading piece F:\USERS_BAK.RMAN, no other copies available.
Corrupt block 258 found during reading backup piece, file=F:\USERS_BAK.RMAN, corr_type=-2
Reread of blocknum=258, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=258, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=258, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=258, file=F:\USERS_BAK.RMAN, found same corrupt data
Reread of blocknum=258, file=F:\USERS_BAK.RMAN, found same corrupt data
Continuing reading piece F:\USERS_BAK.RMAN, no other copies available.
WARNING: some data in the backup of file 4 was missing
or corrupt.
Event 19549 has been set to allow
the file to be restored anyway.
backup header block count: 5369
backup actual block count: 5212
backup header checksum: -
backup actual checksum:
Full restore complete of datafile 4 E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF.
Elapsed time: 0:00:25
checkpoint is 1570136
last deallocation scn is 1508457
这里rman还原依然遇到很多坏块,但是均跳过坏块,还是完整的恢复出来的数据文件(大小)
rman还原数据文件
RMAN& recover datafile 4;
Starting recover at 06-JUN-13
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 94 is already on disk as file E:\ORACLE\
PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC_.0001
archived log for thread 1 with sequence 95 is already on disk as file E:\ORACLE\
PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC_.0001
archived log for thread 1 with sequence 96 is already on disk as file E:\ORACLE\
PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC_.0001
archived log file name=E:\ORACLE\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC_080
1 thread=1 sequence=94
media recovery complete, elapsed time: 00:00:00
Finished recover at 06-JUN-13
这里可以明显的看到在recover过程中数据库应用的是备份后的所有归档,数据文件是正常被还原出来(坏块除外)
Database altered.
SQL& conn test/test
Connected.
SQL& select *
------------------------------ ------- ----------
SQL& select count(*) from stb101;
select count(*) from stb101
ERROR at line 1:
ORA-08103: object no longer exists
dbv检查坏块
e:\oracle\oradata\XIFENFEI&dbv file=USERS01.DBF
DBVERIFY: Release 11.2.0.3.0 - Production on Thu Jun 6 23:59:49 2013
Copyright (c) , Oracle and/or its affiliates.
All rights reserved.
DBVERIFY - Verification starting : FILE = E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF
Page 100 is marked corrupt
Corrupt block relative dba: 0x (file 4, block 100)
Bad check value found during dbv:
Data in bad block:
type: 30 format: 2 rdba: 0x
last change scn: 0x0 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x48901e01
check value in block header: 0x8311
computed block checksum: 0x20
DBVERIFY - Verification complete
Total Pages Examined
Total Pages Processed (Data) : 4952
Total Pages Failing
(Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing
(Index): 0
Total Pages Processed (Other): 7069
Total Pages Processed (Seg)
Total Pages Failing
Total Pages Empty
证明设置了event之后，rman确实跳过了备份集中的坏块,而且是直接还原了坏块内容,证明了event 1作用
在非特殊情况下强烈不建议设置相关event跳过rman中的坏块来还原/恢复数据库,这样将对数据的丢失,甚至数据库是否可以正常open不好评估,rman备份重要,确保rman备份可用也很重要.
客户使用赛门铁克做同城异地容灾部署extent rac,因某种情况导致主备容灾不同步,然后在主库中进行了若干操作,导致主库所有裸设备丢失,然后进行了一些列的操作,主库识别了裸设备,但是oracle出现异常
数据库裸设备异常
Fri May 31 22:07:39 2013
ORA-00202: control file: '/dev/rcontrol2'
ORA-27047: unable to read the header block of file
Additional information: 2
ORA-205 signalled during: ALTER DATABASE
使用备份还原控制文件后,查询数据文件头v$datafile_header.error全部为”WRONG FILE TYPE”,使用bbed去查看,10个block以内全部是0,证明数据库文件头也损坏。因为客户的数据库虽然有rman备份,但涉及到memory,对redo的信息也很敏感,所以希望能够在他们当前的情况下评估redo是否可以应用,确保他们的数据不丢失.验证文件头
DATA FILE #1:
(name #4) /dev/rsystem
creation size=128000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0 01/01/:00
Checkpoint cnt:22469 scn: 0xf9d86 05/29/:50
Stop scn: 0xffff.ffffffff 05/15/:31
Creation Checkpointed at scn:
0x9 05/20/:41
thread:1 rba:(0x1.3.10)
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
Offline scn: 0x0 prev_range: 0
Online Checkpointed at scn:
thread:0 rba:(0x0.0.0)
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
Hot Backup end marker scn: 0x0
aux_file is NOT DEFINED
File header version cannot be determined due to corruption
Dump may be suspect
V10 STYLE FILE HEADER:
Software vsn=0=0x0, Compatibility Vsn=0=0x0
Db ID=0=0x0, Db Name=''
Activation ID=0=0x0
Control Seq=0=0x0, File size=0=0x0
File Number=0, Blksiz=0, File Type=0 UNKNOWN
Tablespace #0 -
scn: 0x0 01/01/:00
Backup taken at scn: 0x0 01/01/:00 thread:0
reset logs count:0x0 scn: 0x0 reset logs terminal rcv data:0x0 scn: 0x0
prev reset logs count:0x0 scn: 0x0 prev reset logs terminal rcv data:0x0 scn: 0x0
recovered at 01/01/:00
status:0x0 root dba:0x chkpt cnt: 0 ctl cnt:0
begin-hot-backup file size: 0
Checkpointed at scn:
thread:0 rba:(0x0.0.0)
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
Backup Checkpointed at scn:
thread:0 rba:(0x0.0.0)
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
00 00 00000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0
Recovery fuzzy scn: 0x0 01/01/:00
Terminal Recovery Stamp
这里可以看出来文件头完全损坏,dump redo header
LOG FILE #1:
(name #1) /dev/rredo11
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x3c000 seq: 0x00003f9c hws: 0x2 bsz: 512 nab: 0x1763c flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x379
Low scn: 0x3ad 05/29/:39
Next scn: 0xfa0e5 05/29/:59
FILE HEADER:
Software vsn=0=0x0, Compatibility Vsn=0=0x0
Db ID=0=0x0, Db Name=''
Activation ID=0=0x0
Control Seq=0=0x0, File size=0=0x0
File Number=0, Blksiz=0, File Type=0 UNKNOWN
descrip:&&
thread: 0 nab: 0x0 seq: 0x hws: 0x0 eot: 0 dis: 0
reset logs count: 0x0 scn: 0x0
Low scn: 0x0 01/01/:00
Next scn: 0x0 01/01/:00
Enabled scn: 0x0 01/01/:00
Thread closed scn: 0x0 01/01/:00
Log format vsn: 0x0 Disk cksum: 0x0 Calc cksum: 0x0
Terminal Recovery Stop scn: 0x0
Terminal Recovery Stamp
Most recent redo scn: 0x0
Largest LWN: 0 blocks
Miscellaneous flags: 0x0
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0
验证redo header已经异常,dump redo logfile全部提示文件头错误
现在情况已经很明显,客户的库因为使用了裸设备,online 磁盘的过程中,所有的裸设备卷已经重写了文件头,oracle的datafile header信息不在了,无法正常操作完成.我们决定使用rman备份来恢复该数据库,然后想办法处理redo
注册带库备份集
在rman恢复过程中,我们遇到一个问题,客户的库rman备份策略有问题,一周一个全备,每天一个增量备份,一次归档备份,最后一次增量备份后备份了控制文件,但是最后一次归档备份之后无控制文件,而且是归档的备份发生在增量备份之后,因为是使用了带库无catalog库,我们增量恢复之后,数据不一致需要归档,但是归档,而归档的备份未记录在还原出来的控制文件中,需要人工注册带库的备份集到控制文件中
--涉及到3个节点都有配置不同的NB_ORA_CLIENT=pysa,如果在同一个节点中还原归档日志,需要配置如下
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS
'ENV=(NB_ORA_CLIENT=pysa)';
--如果在默认节点直接分配sbt通道即可
configure default device type to sbt_
--注册带库备份集
catalog device type 'sbt_tape' backuppiece 'al_744765';
通过ue打开dd出来的redo文件,我们分析得到22)全部为0,应该是和赛门铁克存储管理系统有关系,后面开始是aix的设备头信息
正常redo文件信息
该库redo信息对比(获得aix偏移量)
对比正常redo起点信息和经验我们定位到aix的设备头偏移量为),整体偏移量为22+4096)
该库的redo起点为21000h,也就是说,我们需要执行的dd语句为类似语句(redo 大小为120M)
dd if=/dev/vx/rdsk/dg/redo31 bs=512 skip=264 count=245761 of=/arch/xifenfei/redo31
dd出来所有数据后,对先要已经应用了归档的库,继续尝试recover redo
SQL& recover database usin
ORA-00279: change
generated at 05/30/:08 needed for thread
ORA-00289: suggestion : /arch/1_141.dbf
ORA-00280: change
for thread 1 is in sequence #16289
Specify log: {&RET&=suggested | filename | AUTO | CANCEL}
/arch/xifenfei/redo12
ORA-00279: change
generated at 05/30/:08 needed for thread
Specify log: {&RET&=suggested | filename | AUTO | CANCEL}
/arch/xifenfei/redo23
ORA-00279: change
generated at 05/30/:07 needed for thread
ORA-00289: suggestion : /arch/3_41.dbf
ORA-00280: change
for thread 3 is in sequence #3898
Specify log: {&RET&=suggested | filename | AUTO | CANCEL}
/arch/xifenfei/redo31
ORA-00279: change
generated at 05/30/:26 needed for thread
ORA-00289: suggestion : /arch/1_141.dbf
ORA-00280: change
for thread 1 is in sequence #16290
ORA-00278: log file '/arch/xifenfei/redo12' no longer needed for this recovery
Specify log: {&RET&=suggested | filename | AUTO | CANCEL}
/arch/xifenfei/redo11
ORA-00279: change
generated at 05/30/:09 needed for thread
ORA-00289: suggestion : /arch/3_41.dbf
ORA-00280: change
for thread 3 is in sequence #3899
ORA-00278: log file '/arch/xifenfei/redo31' no longer needed for this recovery
Specify log: {&RET&=suggested | filename | AUTO | CANCEL}
/arch/xifenfei/redo33
Log applied.
Media recovery complete.
SQL& alter dat
Database altered.
到这一步我们完整的通过dd跳过了由于赛门铁克管理磁盘导致的磁盘头损坏的块,从裸设备中复制出redo到文件系统,然后进行恢复,完整的抢救了客户的数据,减少了客户的损坏.这里温馨提示对于非常重要的系统(涉及钱),强烈建议redo多路冗余,光依靠存储容灾,备份,dg依然不够
2016 年八月
78910111213
14151617181920
21222324252627
2016 年八月 &(10)
2016 年五月 &(7)
2015 年十二月 &(4)
2015 年十月 &(4)
2015 年八月 &(10)
2015 年三月 &(1)
2015 年一月 &(1)
2014 年十二月 &(1)
2014 年十一月 &(5)
2014 年十月 &(3)
2014 年九月 &(5)
2014 年八月 &(4)
2014 年七月 &(8)
2014 年六月 &(4)
2014 年五月 &(5)
2014 年四月 &(5)
2014 年三月 &(12)
2014 年二月 &(5)
2014 年一月 &(6)
2013 年十二月 &(6)
2013 年十一月 &(3)
2013 年十月 &(4)
2013 年九月 &(4)
2013 年八月 &(17)
2013 年七月 &(4)
2013 年六月 &(12)
2013 年五月 &(18)
2013 年四月 &(9)
2013 年三月 &(8)
2013 年二月 &(11)
2013 年一月 &(6)
2012 年十二月 &(20)
2012 年十一月 &(12)
2012 年十月 &(13)
2012 年九月 &(21)
2012 年八月 &(28)
2012 年七月 &(27)
2012 年六月 &(31)
2012 年五月 &(43)
2012 年四月 &(52)
2012 年三月 &(41)
2012 年二月 &(30)
2012 年一月 &(25)
2011 年十二月 &(42)
2011 年十一月 &(43)
2011 年十月 &(15)
2011 年九月 &(26)
2011 年八月 &(52)
2011 年七月 &(32)
2011 年六月 &(23)
2011 年五月 &(16)
2011 年四月 &(33)
2011 年三月 &(30)
2011 年二月 &(14)
2011 年一月 &(13)
2010 年十二月 &(10)
2010 年十一月 &(6)
2010 年十月 &(6)
2010 年九月 &(22)
2010 年八月 &(41)
2010 年七月 &(7)
2010 年六月 &(1)
2009 年十二月 &(4)
2009 年十一月 &(5)
WP Cumulus Flash tag cloud by
9 or better.}