跳过rman坏块进行数据恢复

运维 系统运维
如果我们仅有一份rman备份,而这个时候rman备份有出现坏块,使得我们的还原/恢复工作无法继续下去,导致数据大量丢失。怎么才能跳过这个rman坏块进行数据恢复?本文分享了一些技巧和方法,希望能帮到你。

在有些情况下,我们仅有一份rman备份,而这个时候rman 备份有出现坏块,使得我们的还原/恢复工作无法继续下去,导致数据大量丢失。我们可以通过设置event 19548/19549来跳过坏块,***程度抢救数据。

rman备份数据文件

  1. C:\Users\XIFENFEI>rman target / 
  2. Recovery Manager: Release 11.2.0.3.0 - Production on Thu Jun 6 20:31:19 2013 
  3. Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. 
  4. connected to target database: XIFENFEI (DBID=1422012639
  5. RMAN> backup tablespace users format 'f:/users_bak.rman'; 
  6. Starting backup at 06-JUN-13 
  7. using target database control file instead of recovery catalog 
  8. allocated channel: ORA_DISK_1 
  9. channel ORA_DISK_1: SID=197 device type=DISK 
  10. channel ORA_DISK_1: starting full datafile backup set 
  11. channel ORA_DISK_1: specifying datafile(s) in backup set 
  12. input datafile file number=00004 name=E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF 
  13. channel ORA_DISK_1: starting piece 1 at 06-JUN-13 
  14. channel ORA_DISK_1: finished piece 1 at 06-JUN-13 
  15. piece handle=F:\USERS_BAK.RMAN tag=TAG20130606T203154 comment=NONE 
  16. channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03 
  17. Finished backup at 06-JUN-13 

切换归档日志

  1. SQL> alter system switch logfile; 
  2. System altered. 
  3. SQL> / 
  4. System altered. 
  5. SQL> / 
  6. System altered. 
  7. SQL> archive log list; 
  8. Database log mode              Archive Mode 
  9. Automatic archival             Enabled 
  10. Archive destination            E:\oracle\product\11.2.0\dbhome_1\RDBMS 
  11. Oldest online log sequence     95 
  12. Next log sequence to archive   97 
  13. Current log sequence           97 

重命名数据文件

  1. SQL> shutdown immediate 
  2. Database closed. 
  3. Database dismounted. 
  4. ORACLE instance shut down. 
  5. -------------------------------------- 
  6. e:\oracle\oradata\XIFENFEI>move USERS01.DBF USERS01_bak.DBF 
  7. 移动了         1 个文件。 
  8. -------------------------------------- 
  9. SQL> startup 
  10. ORACLE instance started. 
  11. Total System Global Area  418484224 bytes 
  12. Fixed Size                  1385052 bytes 
  13. Variable Size             327159204 bytes 
  14. Database Buffers           83886080 bytes 
  15. Redo Buffers                6053888 bytes 
  16. Database mounted. 
  17. ORA-01157: cannot identify/lock data file 4 - see DBWR trace file 
  18. ORA-01110: data file 4: 'E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF' 

#p#

破坏备份集

破坏前

破坏后

这里很明显,我通过ue把rman备份集中的T修改为了A,肯定破坏了文件,使之出现坏块

rman还原数据文件

  1. C:\Users\XIFENFEI>rman target / 
  2. Recovery Manager: Release 11.2.0.3.0 - Production on Thu Jun 6 21:02:41 2013 
  3. Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. 
  4. connected to target database: XIFENFEI (DBID=1422012639, not open) 
  5. RMAN> restore datafile 4; 
  6. Starting restore at 06-JUN-13 
  7. using target database control file instead of recovery catalog 
  8. allocated channel: ORA_DISK_1 
  9. channel ORA_DISK_1: SID=63 device type=DISK 
  10. channel ORA_DISK_1: starting datafile backup set restore 
  11. channel ORA_DISK_1: specifying datafile(s) to restore from backup set 
  12. channel ORA_DISK_1: restoring datafile 00004 to E:\ORACLE\ORADATA\XIFENFEI\USERS 
  13. 01.DBF 
  14. channel ORA_DISK_1: reading from backup piece F:\USERS_BAK.RMAN 
  15. channel ORA_DISK_1: ORA-19870: error while restoring backup piece F:\USERS_BAK.R 
  16. MAN 
  17. ORA-19612: datafile 4 not restored due to missing or corrupt data 
  18. failover to previous backup 
  19. creating datafile file number=4 name=E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF 
  20. Finished restore at 06-JUN-13 

这里可以清晰的看到rman报ORA-19612错误,restore 失败,alert日志为:

  1. Thu Jun 06 21:02:31 2013 
  2. ALTER DATABASE OPEN 
  3. Errors in file E:\ORACLE\diag\rdbms\xifenfei\xff\trace\xff_dbw0_7400.trc: 
  4. ORA-01157: ????/?????? 4 - ??? DBWR ???? 
  5. ORA-01110: ???? 4: 'E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF' 
  6. ORA-27041: ?????? 
  7. OSD-04002: unable to open file 
  8. O/S-Error: (OS 2) 系统找不到指定的文件。 
  9. Errors in file E:\ORACLE\diag\rdbms\xifenfei\xff\trace\xff_ora_4272.trc: 
  10. ORA-01157: cannot identify/lock data file 4 - see DBWR trace file 
  11. ORA-01110: data file 4: 'E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF' 
  12. ORA-1157 signalled during: ALTER DATABASE OPEN... 
  13. Thu Jun 06 21:02:33 2013 
  14. Checker run found 1 new persistent data failures 
  15. Thu Jun 06 21:03:23 2013 
  16. Corrupt block 101 found during reading backup piece, file=F:\USERS_BAK.RMAN, corr_type=3 
  17. Reread of blocknum=101file=F:\USERS_BAK.RMAN, found same corrupt data 
  18. Reread of blocknum=101file=F:\USERS_BAK.RMAN, found same corrupt data 
  19. Reread of blocknum=101file=F:\USERS_BAK.RMAN, found same corrupt data 
  20. Reread of blocknum=101file=F:\USERS_BAK.RMAN, found same corrupt data 
  21. Reread of blocknum=101file=F:\USERS_BAK.RMAN, found same corrupt data 
  22. Continuing reading piece F:\USERS_BAK.RMAN, no other copies available. 

rman备份集有坏块,导致rman还原无法正常进行下去,还原后的数据文件大小。

#p#

观察已经正常还原出来数据文件情况

  1. SQL> select CHECKPOINT_CHANGE#,file# from v$datafile_header; 
  2. CHECKPOINT_CHANGE#      FILE# 
  3. ------------------ ---------- 
  4. 1571582          1 
  5. 1571582          2 
  6. 1571582          3 
  7. 18379          4 
  8. 1571582          5 
  9. 1571582          6 
  10. 1571582          7 
  11. SQL> recover database datafile 4 ; 
  12. ORA-00274: illegal recovery option DATAFILE 
  13. SQL> recover datafile 4; 
  14. ORA-00279: change 18379 generated at 01/20/2013 17:13:56 needed for thread 1 
  15. ORA-00289: suggestion : 
  16. E:\ORACLE\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000001_0805223583.0001 
  17. ORA-00280: change 18379 for thread 1 is in sequence #1 
  18. Specify log: {<RET>=suggested | filename | AUTO | CANCEL} 

rman只是还原了很小的一部分文件,做恢复提示需要从归档日志seq 1开始(某些情况可能需要其他归档,总之不是正常情况),证明rman还原异常

设置event事件还原

  1. SQL> shutdown abort; 
  2. ORACLE instance shut down. 
  3. SQL> startup pfile='e:/pfile.txt' mount; 
  4. ORACLE instance started. 
  5. Total System Global Area  418484224 bytes 
  6. Fixed Size                  1385052 bytes 
  7. Variable Size             327159204 bytes 
  8. Database Buffers           83886080 bytes 
  9. Redo Buffers                6053888 bytes 
  10. Database mounted. 
  11. SQL> show parameter event; 
  12. NAME                                 TYPE        VALUE 
  13. ------------------------------------ ----------- ------------------------------ 
  14. event                                string      19548 trace name context forev 
  15. er, 19549 trace name context f 
  16. orever 
  17. Event 19548:This will attempt to restore content of the corrupted block if it is possible. 
  18. Event 19549:This will suppress erroring out during restore 

rman还原数据文件

  1. RMAN> restore datafile 4; 
  2. Starting restore at 06-JUN-13 
  3. using target database control file instead of recovery catalog 
  4. allocated channel: ORA_DISK_1 
  5. channel ORA_DISK_1: SID=63 device type=DISK 
  6. channel ORA_DISK_1: starting datafile backup set restore 
  7. channel ORA_DISK_1: specifying datafile(s) to restore from backup set 
  8. channel ORA_DISK_1: restoring datafile 00004 to E:\ORACLE\ORADATA\XIFENFEI\USERS 
  9. 01.DBF 
  10. channel ORA_DISK_1: reading from backup piece F:\USERS_BAK.RMAN 
  11. channel ORA_DISK_1: piece handle=F:\USERS_BAK.RMAN tag=TAG20130606T203154 
  12. channel ORA_DISK_1: restored backup piece 1 
  13. channel ORA_DISK_1: restore complete, elapsed time: 00:00:35 
  14. Finished restore at 06-JUN-13 

这里证明数据库rman有坏块通过rman还原成功,alert日志提示如下:

  1. Thu Jun 06 21:29:53 2013 
  2. WARNING: The block that appears to be block number 100 
  3.          in file 4 is corrupt in backup piece F:\USERS_BAK.RMAN. 
  4.          Such blocks would usually be formatted as empty 
  5.          in the restored file, but event 19548 has been 
  6.          set to include the block as-is in the restored 
  7.          file. 
  8. Corrupt block 102 found during reading backup piece, file=F:\USERS_BAK.RMAN, corr_type=-2 
  9. Reread of blocknum=102file=F:\USERS_BAK.RMAN, found same corrupt data 
  10. Reread of blocknum=102file=F:\USERS_BAK.RMAN, found same corrupt data 
  11. Reread of blocknum=102file=F:\USERS_BAK.RMAN, found same corrupt data 
  12. Reread of blocknum=102file=F:\USERS_BAK.RMAN, found same corrupt data 
  13. Reread of blocknum=102file=F:\USERS_BAK.RMAN, found same corrupt data 
  14. Continuing reading piece F:\USERS_BAK.RMAN, no other copies available. 
  15. ………… 
  16. Corrupt block 258 found during reading backup piece, file=F:\USERS_BAK.RMAN, corr_type=-2 
  17. Reread of blocknum=258file=F:\USERS_BAK.RMAN, found same corrupt data 
  18. Reread of blocknum=258file=F:\USERS_BAK.RMAN, found same corrupt data 
  19. Reread of blocknum=258file=F:\USERS_BAK.RMAN, found same corrupt data 
  20. Reread of blocknum=258file=F:\USERS_BAK.RMAN, found same corrupt data 
  21. Reread of blocknum=258file=F:\USERS_BAK.RMAN, found same corrupt data 
  22. Continuing reading piece F:\USERS_BAK.RMAN, no other copies available. 
  23. WARNING: some data in the backup of file 4 was missing 
  24.          or corrupt.  Event 19549 has been set to allow 
  25.          the file to be restored anyway. 
  26.            backup header block count: 5369 
  27.            backup actual block count: 5212 
  28.               backup header checksum: -218250743 
  29.               backup actual checksum: 1442665538 
  30. Full restore complete of datafile 4 E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF.  Elapsed time: 0:00:25 
  31.   checkpoint is 1570136 
  32.   last deallocation scn is 1508457 

这里rman还原依然遇到很多坏块,但是均跳过坏块,还是完整的恢复出来的数据文件(大小)。

#p#

rman还原数据文件

  1. RMAN> recover datafile 4; 
  2. Starting recover at 06-JUN-13 
  3. using channel ORA_DISK_1 
  4. starting media recovery 
  5. archived log for thread 1 with sequence 94 is already on disk as file E:\ORACLE\ 
  6. PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000094_0805223583.0001 
  7. archived log for thread 1 with sequence 95 is already on disk as file E:\ORACLE\ 
  8. PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000095_0805223583.0001 
  9. archived log for thread 1 with sequence 96 is already on disk as file E:\ORACLE\ 
  10. PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000096_0805223583.0001 
  11. archived log file name=E:\ORACLE\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000094_080 
  12. 5223583.0001 thread=1 sequence=94 
  13. media recovery complete, elapsed time: 00:00:00 
  14. Finished recover at 06-JUN-13 

这里可以明显的看到在recover过程中数据库应用的是备份后的所有归档,数据文件是正常被还原出来(坏块除外)。

查询对象

  1. SQL> alter database open;  
  2. Database altered. 
  3. SQL> conn test/test 
  4. Connected. 
  5. SQL> select * from tab; 
  6. TNAME                          TABTYPE  CLUSTERID 
  7. ------------------------------ ------- ---------- 
  8. STB101                         TABLE 
  9. SQL> select count(*) from stb101; 
  10. select count(*) from stb101 
  11.                    * 
  12. ERROR at line 1: 
  13. ORA-08103: object no longer exists 

dbv检查坏块

  1. e:\oracle\oradata\XIFENFEI>dbv file=USERS01.DBF 
  2. DBVERIFY: Release 11.2.0.3.0 - Production on Thu Jun 6 23:59:49 2013 
  3. Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. 
  4. DBVERIFY - Verification starting : FILE = E:\ORACLE\ORADATA\XIFENFEI\USERS01.DBF 
  5. Page 100 is marked corrupt 
  6. Corrupt block relative dba: 0x01000064 (file 4, block 100) 
  7. Bad check value found during dbv: 
  8. Data in bad block: 
  9.  type: 30 format: 2 rdba: 0x01000064 
  10.  last change scn: 0x0000.00004890 seq: 0x1 flg: 0x04 
  11.  spare1: 0x0 spare2: 0x0 spare3: 0x0 
  12.  consistency value in tail: 0x48901e01 
  13.  check value in block header: 0x8311 
  14.  computed block checksum: 0x20 
  15. DBVERIFY - Verification complete 
  16. Total Pages Examined         : 12320 
  17. Total Pages Processed (Data) : 4952 
  18. Total Pages Failing   (Data) : 0 
  19. Total Pages Processed (Index): 0 
  20. Total Pages Failing   (Index): 0 
  21. Total Pages Processed (Other): 7069 
  22. Total Pages Processed (Seg)  : 0 
  23. Total Pages Failing   (Seg)  : 0 
  24. Total Pages Empty            : 298 

证明设置了event之后,rman确实跳过了备份集中的坏块,而且是直接还原了坏块内容,证明了event 19548和19549作用。

补充说明

在非特殊情况下强烈不建议设置相关event跳过rman中的坏块来还原/恢复数据库,这样将对数据的丢失,甚至数据库是否可以正常open不好评估,rman备份重要,确保rman备份可用也很重要。

责任编辑:黄丹 来源: xifenfei.com
相关推荐

2009-03-02 09:29:11

Windows Ser共享资源数据恢复

2022-03-15 09:23:25

mariaDB数据恢复数据库

2010-11-19 13:28:13

2011-08-29 16:41:14

OracleRMAN恢复数据文件的恢复

2011-08-23 11:09:36

Oraclerman恢复system表空间恢复

2023-05-05 19:16:22

Python数据清洗

2017-10-31 11:55:46

sklearn数据挖掘自动化

2011-03-09 14:18:37

SQL数据累加

2011-08-30 09:35:10

OracleRMAN不完全恢复基于时间恢复

2011-08-30 09:50:22

OracleRMAN不完全恢复基于SCN恢复

2011-08-29 17:00:47

Oracle数据库RM表空间数据块介质

2018-09-17 16:12:03

数据库数据恢复SQL Server

2019-09-30 10:12:21

机器学习数据映射

2023-05-05 19:29:41

2019-09-27 12:44:03

数据建模企业数据存储

2010-10-26 12:03:25

Oracle备份

2022-11-02 14:45:24

Python数据分析工具

2009-03-16 10:29:45

数据挖掘过滤器Access

2022-06-02 13:59:57

数据迁移数据

2009-09-08 16:50:12

使用LINQ进行数据转
点赞
收藏

51CTO技术栈公众号