标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,769)
- DB2 (22)
- MySQL (77)
- Oracle (1,610)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (592)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- 2025年的Oracle 8.0.5数据库恢复
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
月归档:六月 2013
跳过rman坏块恢复
在有些情况下,我们仅有一份rman备份,而这个时候rman 备份有出现坏块,使得我们的还原/恢复工作无法继续下去,导致数据大量丢失.我们可以通过设置event 19548/19549来跳过坏块,最大程度抢救数据
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) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: XIFENFEI (DBID=1422012639) 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=TAG20130606T203154 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03 Finished backup at 06-JUN-13
切换归档日志
SQL> alter system switch logfile; System altered. SQL> / System altered. SQL> / System altered. SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination E:\oracle\product\11.2.0\dbhome_1\RDBMS Oldest online log sequence 95 Next log sequence to archive 97 Current log sequence 97
重命名数据文件
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 418484224 bytes Fixed Size 1385052 bytes Variable Size 327159204 bytes Database Buffers 83886080 bytes 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) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: XIFENFEI (DBID=1422012639, 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 01.DBF 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 MAN 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_header; CHECKPOINT_CHANGE# FILE# ------------------ ---------- 1571582 1 1571582 2 1571582 3 18379 4 1571582 5 1571582 6 1571582 7 SQL> recover database datafile 4 ; ORA-00274: illegal recovery option DATAFILE SQL> recover datafile 4; ORA-00279: change 18379 generated at 01/20/2013 17:13:56 needed for thread 1 ORA-00289: suggestion : E:\ORACLE\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000001_0805223583.0001 ORA-00280: change 18379 for thread 1 is in sequence #1 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
rman只是还原了很小的一部分文件,做恢复提示需要从归档日志seq 1开始(某些情况可能需要其他归档,总之不是正常情况),证明rman还原异常
设置event事件还原
SQL> shutdown abort; ORACLE instance shut down. SQL> startup pfile='e:/pfile.txt' mount; ORACLE instance started. Total System Global Area 418484224 bytes Fixed Size 1385052 bytes Variable Size 327159204 bytes Database Buffers 83886080 bytes Redo Buffers 6053888 bytes Database mounted. SQL> show parameter event; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ event string 19548 trace name context forev er, 19549 trace name context f orever
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 01.DBF channel ORA_DISK_1: reading from backup piece F:\USERS_BAK.RMAN channel ORA_DISK_1: piece handle=F:\USERS_BAK.RMAN tag=TAG20130606T203154 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 file. 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: -218250743 backup actual checksum: 1442665538 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\ARC0000000094_0805223583.0001 archived log for thread 1 with sequence 95 is already on disk as file E:\ORACLE\ PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000095_0805223583.0001 archived log for thread 1 with sequence 96 is already on disk as file E:\ORACLE\ PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000096_0805223583.0001 archived log file name=E:\ORACLE\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000094_080 5223583.0001 thread=1 sequence=94 media recovery complete, elapsed time: 00:00:00 Finished recover at 06-JUN-13
这里可以明显的看到在recover过程中数据库应用的是备份后的所有归档,数据文件是正常被还原出来(坏块除外)
查询对象
SQL> alter database open; Database altered. SQL> conn test/test Connected. SQL> select * from tab; TNAME TABTYPE CLUSTERID ------------------------------ ------- ---------- STB101 TABLE 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) 1982, 2011, 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: 0x01000064 (file 4, block 100) Bad check value found during dbv: Data in bad block: type: 30 format: 2 rdba: 0x01000064 last change scn: 0x0000.00004890 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 : 12320 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) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 298
证明设置了event之后,rman确实跳过了备份集中的坏块,而且是直接还原了坏块内容,证明了event 19548和19549作用
补充说明
在非特殊情况下强烈不建议设置相关event跳过rman中的坏块来还原/恢复数据库,这样将对数据的丢失,甚至数据库是否可以正常open不好评估,rman备份重要,确保rman备份可用也很重要.
记录因磁盘头被重写,抢救redo恢复经历
客户使用赛门铁克做同城异地容灾部署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 MOUNT...
使用备份还原控制文件后,查询数据文件头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: 0x0000.00000000 01/01/1988 00:00:00 Checkpoint cnt:22469 scn: 0x0000.7b4f9d86 05/29/2013 22:09:50 Stop scn: 0xffff.ffffffff 05/15/2013 00:08:31 Creation Checkpointed at scn: 0x0000.00000009 05/20/2007 21:52:41 thread:1 rba:(0x1.3.10) enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Offline scn: 0x0000.00000000 prev_range: 0 Online Checkpointed at scn: 0x0000.00000000 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Hot Backup end marker scn: 0x0000.00000000 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 - rel_fn:0 Creation at scn: 0x0000.00000000 01/01/1988 00:00:00 Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0 reset logs count:0x0 scn: 0x0000.00000000 reset logs terminal rcv data:0x0 scn: 0x0000.00000000 prev reset logs count:0x0 scn: 0x0000.00000000 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000 recovered at 01/01/1988 00:00:00 status:0x0 root dba:0x00000000 chkpt cnt: 0 ctl cnt:0 begin-hot-backup file size: 0 Checkpointed at scn: 0x0000.00000000 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Backup Checkpointed at scn: 0x0000.00000000 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 External cache id: 0x0 0x0 0x0 0x0 Absolute fuzzy scn: 0x0000.00000000 Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00 Terminal Recovery Stamp 01/01/1988 00:00:00
这里可以看出来文件头完全损坏,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: 0x0000.7b458379 Low scn: 0x0000.7b4583ad 05/29/2013 01:32:39 Next scn: 0x0000.7b4fa0e5 05/29/2013 22:17: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: 0x00000000 hws: 0x0 eot: 0 dis: 0 reset logs count: 0x0 scn: 0x0000.00000000 Low scn: 0x0000.00000000 01/01/1988 00:00:00 Next scn: 0x0000.00000000 01/01/1988 00:00:00 Enabled scn: 0x0000.00000000 01/01/1988 00:00:00 Thread closed scn: 0x0000.00000000 01/01/1988 00:00:00 Log format vsn: 0x0 Disk cksum: 0x0 Calc cksum: 0x0 Terminal Recovery Stop scn: 0x0000.00000000 Terminal Recovery Stamp 01/01/1988 00:00:00 Most recent redo scn: 0x0000.00000000 Largest LWN: 0 blocks Miscellaneous flags: 0x0 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
验证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_tape; --注册带库备份集 catalog device type 'sbt_tape' backuppiece 'al_21395_1_816744765';
分析redo
通过ue打开dd出来的redo文件,我们分析得到20000h(10*8192)全部为0,应该是和赛门铁克存储管理系统有关系,后面开始是aix的设备头信息
正常redo文件信息
该库redo信息对比(获得aix偏移量)
对比正常redo起点信息和经验我们定位到aix的设备头偏移量为1000h(4096),整体偏移量为21000h(10*8192+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 using backup controlfile; ORA-00279: change 2069348436 generated at 05/30/2013 16:18:08 needed for thread 1 ORA-00289: suggestion : /arch/1_16289_623109141.dbf ORA-00280: change 2069348436 for thread 1 is in sequence #16289 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /arch/xifenfei/redo12 ORA-00279: change 2069348436 generated at 05/30/2013 16:18:08 needed for thread 2 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /arch/xifenfei/redo23 ORA-00279: change 2069348436 generated at 05/30/2013 16:18:07 needed for thread 3 ORA-00289: suggestion : /arch/3_3898_623109141.dbf ORA-00280: change 2069348436 for thread 3 is in sequence #3898 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /arch/xifenfei/redo31 ORA-00279: change 2069455373 generated at 05/30/2013 20:03:26 needed for thread 1 ORA-00289: suggestion : /arch/1_16290_623109141.dbf ORA-00280: change 2069455373 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 2069475956 generated at 05/30/2013 20:04:09 needed for thread 3 ORA-00289: suggestion : /arch/3_3899_623109141.dbf ORA-00280: change 2069475956 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 database open resetlogs; Database altered.
到这一步我们完整的通过dd跳过了由于赛门铁克管理磁盘导致的磁盘头损坏的块,从裸设备中复制出redo到文件系统,然后进行恢复,完整的抢救了客户的数据,减少了客户的损坏.这里温馨提示对于非常重要的系统(涉及钱),强烈建议redo多路冗余,光依靠存储容灾,备份,dg依然不够
通过基表获取segment header block
数据库不能open的时候,可以通过dul挖取相关基表(user$,obj$,ts$,tab$,seg$,file$),从而来获得segment header信息,然后通过dump该block,结合shell脚本获得extents分布脚本来获得extent分布
SELECT NVL (u.name, 'SYS'), o.name, o.subname, so.object_type, s.type#, DECODE (BITAND (s.spare1, 2097408), 2097152, 'SECUREFILE', 256, 'ASSM', 'MSSM'), ts.ts#, ts.name, ts.blocksize, f.file#, s.block#, s.blocks * ts.blocksize, s.blocks, s.extents, s.iniexts * ts.blocksize, s.extsize * ts.blocksize, s.minexts, s.maxexts, DECODE (BITAND (s.spare1, 4194304), 4194304, bitmapranges, NULL), TO_CHAR ( DECODE ( BITAND (s.spare1, 2097152), 2097152, DECODE (s.lists, 0, 'NONE', 1, 'AUTO', 2, 'MIN', 3, 'MAX', 4, 'DEFAULT', 'INVALID'), NULL)), DECODE (BITAND (s.spare1, 2097152), 2097152, s.groups, NULL), DECODE (BITAND (ts.flags, 3), 1, TO_NUMBER (NULL), s.extpct), DECODE (BITAND (ts.flags, 32), 32, TO_NUMBER (NULL), DECODE (s.lists, 0, 1, s.lists)), DECODE (BITAND (ts.flags, 32), 32, TO_NUMBER (NULL), DECODE (s.groups, 0, 1, s.groups)), s.file#, BITAND (s.cachehint, 3), BITAND (s.cachehint, 12) / 4, BITAND (s.cachehint, 48) / 16, NVL (s.spare1, 0), o.dataobj# FROM chf.user$ u, chf.obj$ o, chf.ts$ ts, ( SELECT DECODE (BITAND (t.property, 8192), 8192, 'NESTED TABLE', 'TABLE') OBJECT_TYPE, 2 OBJECT_TYPE_ID, 5 SEGMENT_TYPE_ID, t.obj# OBJECT_ID, t.file# HEADER_FILE, t.block# HEADER_BLOCK, t.ts# TS_NUMBER FROM chf.tab$ t) so, chf.seg$ s, chf.file$ f WHERE s.file# = so.header_file AND s.block# = so.header_block AND s.ts# = so.ts_number AND s.ts# = ts.ts# AND o.obj# = so.object_id AND o.owner# = u.user#(+) AND s.type# = so.segment_type_id AND o.type# = so.object_type_id AND s.ts# = f.ts# AND s.file# = f.relfile# and o.name in('XIFENFEI','T_XIFENFEI');