开发者社区> lfreeali> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

[20150601]rman备份出现坏块.txt

简介: [20150601]rman备份出现坏块.txt --昨天看链接: http://www.jydba.net/磁盘损坏造成RMAN备份文件有坏块的恢复案例/ --提到如果备份片存在坏块的恢复案例,他使用的参数,我自己从来没见过.
+关注继续查看

[20150601]rman备份出现坏块.txt

--昨天看链接:
http://www.jydba.net/磁盘损坏造成RMAN备份文件有坏块的恢复案例/

--提到如果备份片存在坏块的恢复案例,他使用的参数,我自己从来没见过.
alter system set event='19548 trace name context forever', '19549 trace name context forever' scope=spfile;

-- oerr ora 19548,oerr ora 19548 都没有查询到信息.

还是通过例子做一个测试:

1.建立测试环境:
SYS@test> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx            10.2.0.4.0     Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi

CREATE TABLESPACE MSSM DATAFILE
  '/mnt/ramdisk/test/mssm01.dbf' SIZE 16256K AUTOEXTEND OFF
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT MANUAL
FLASHBACK ON;

--随便在这个表空间上建立了2张表.
create table deptx tablespace mssm as select  * from scott.dept ;

2.备份表空间mssm.
SYS@test> alter  tablespace mssm read only ;
Tablespace altered.

RMAN> backup tablespace mssm format '/home/oracle/mssm/mssm_20150601.bak';
Starting backup at 2015-06-01 09:29:11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=139 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00006 name=/mnt/ramdisk/test/mssm01.dbf
channel ORA_DISK_1: starting piece 1 at 2015-06-01 09:29:11
channel ORA_DISK_1: finished piece 1 at 2015-06-01 09:29:12
piece handle=/home/oracle/mssm/mssm_20150601.bak tag=TAG20150601T092911 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2015-06-01 09:29:13

$  cp /mnt/ramdisk/test/mssm01.dbf /home/oracle/mssm/mssm01.dbf_20150601

--做一个"友善"的破坏,将备份文件mssm_20150601.bak的"YORK"换成"GGGG",我使用bvi软件.

3.删除mssm01.dbf,测试恢复是否可行:

SYS@test> alter database datafile 6 offline ;
Database altered.

--改名原来的文件:
$  cd /mnt/ramdisk/test/
$  mv mssm01.dbf mssm01.dbf_xxx

--开始恢复看看:
RMAN> restore datafile 6;
Starting restore at 2015-06-01 09:35:52
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=142 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00006 to /mnt/ramdisk/test/mssm01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/mssm/mssm_20150601.bak
ORA-19870: error reading backup piece /home/oracle/mssm/mssm_20150601.bak
ORA-19612: datafile 6 not restored due to missing or corrupt data
failover to previous backup

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/01/2015 09:35:53
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 6 found to restore

--可以发现无法恢复数据文件6.

4.设置参数:
SYS@test> alter system set event='19548 trace name context forever', '19549 trace name context forever' scope=spfile;
System altered.

--重启数据库,继续恢复看看.

SYS@test> startup mount
ORACLE instance started.

Total System Global Area    473956352 bytes
Fixed Size                    2084776 bytes
Variable Size               260046936 bytes
Database Buffers            201326592 bytes
Redo Buffers                 10498048 bytes
Database mounted.

RMAN> restore datafile 6;
Starting restore at 2015-06-01 09:41:47
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=153 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00006 to /mnt/ramdisk/test/mssm01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/mssm/mssm_20150601.bak
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/mssm/mssm_20150601.bak tag=TAG20150601T092911
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 2015-06-01 09:41:50

--这次可以恢复成功!

SYS@test> alter database open read only;
Database altered.

SYS@test> select * from scott.deptx;
select * from scott.deptx
                    *
ERROR at line 1:
ORA-00376: file 6 cannot be read at this time
ORA-01110: data file 6: '/mnt/ramdisk/test/mssm01.dbf'

SYS@test> alter database datafile 6 online ;
Database altered.

SYS@test> select * from scott.deptx;
select * from scott.deptx
                    *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 6, block # 10)
ORA-01110: data file 6: '/mnt/ramdisk/test/mssm01.dbf'
--可以发现恢复后,读取表scott.deptx存在错误.

$  dbv file=/mnt/ramdisk/test/mssm01.dbf blocksize=8192
DBVERIFY: Release 10.2.0.4.0 - Production on Mon Jun 1 09:55:44 2015
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
DBVERIFY - Verification starting : FILE = /mnt/ramdisk/test/mssm01.dbf
Page 10 is marked corrupt
Corrupt block relative dba: 0x0180000a (file 6, block 10)
Bad check value found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x0180000a
last change scn: 0x0002.f445ace5 seq: 0x2 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xace50602
check value in block header: 0x893e
computed block checksum: 0x40b
DBVERIFY - Verification complete
Total Pages Examined         : 2032
Total Pages Processed (Data) : 1
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 1
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 1970
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 59
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Highest block SCN            : 4101920976 (2.4101920976)


5.使用bbed观察:
BBED> set dba 6,10
        DBA             0x0180000a (25165834 6,10)


BBED> x /4rncc rowdata
rowdata[0]                                  @8096
----------
flag@8096: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8097: 0x00
cols@8098:    3

col    0[2] @8099: 10
col   1[10] @8102: ACCOUNTING
col    2[8] @8113: NEW GGGG

rowdata[26]                                 @8122
-----------
flag@8122: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8123: 0x00
cols@8124:    3

col    0[2] @8125: 20
col    1[8] @8128: RESEARCH
col    2[6] @8137: DALLAS

rowdata[48]                                 @8144
-----------
flag@8144: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8145: 0x00
cols@8146:    3

col    0[2] @8147: 30
col    1[5] @8150: SALES
col    2[7] @8156: CHICAGO

rowdata[68]                                 @8164
-----------
flag@8164: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8165: 0x02
cols@8166:    3

col    0[2] @8167: 40
col   1[10] @8170: OPERATIONS
col    2[6] @8181: BOSTON

--可以发现读取的记录确实存在一个字段存在col    2[8] @8113: NEW GGGG.
BBED> set dba 6,10
        DBA             0x0180000a (25165834 6,10)

BBED> sum
Check value for File 6, Block 10:
current = 0x893e, required = 0x8d35

BBED> sum apply
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
Check value for File 6, Block 10:
current = 0x8d35, required = 0x8d35

SYS@test> alter system flush buffer_cache;
System altered.

SYS@test> select * from scott.deptx;
      DEPTNO DNAME          LOC
------------ -------------- -------------
          10 ACCOUNTING     NEW GGGG
          20 RESEARCH       DALLAS
          30 SALES          CHICAGO
          40 OPERATIONS     BOSTON

--总结:
--备份是恢复最后1个环节,如果备份集存在"瑕疵",可以通过参数来先恢复,尽可能的减少损失.
alter system set event='19548 trace name context forever', '19549 trace name context forever' scope=spfile;
--当然如果还有备份,可以不要从这个备份集来恢复.

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
[20171204]关于rman备份疑问4.txt
[20171204]关于rman备份疑问4.txt --//上午排除我几天在做rman测试的疑问. --//链接如下:http://blog.itpub.net/267265/viewspace-2148029/ --//顺便测试备份集包含5个数据文件的情况(本来不想做,还是做看看),验证自己的判断是否正确.
1045 0
[20171201]关于rman备份疑问3.txt
[20171201]关于rman备份疑问3.txt --//上午排除我几天在做rman测试的疑问. --//链接如下:http://blog.itpub.net/267265/viewspace-2148029/ --//顺便测试备份集包含4,5个数据文件的情况,验证自己的判断是否正确.
892 0
[20161101]rman备份与数据文件变化7.txt
[20161101]rman备份与数据文件变化7.txt --//想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --//去年已经测试了建立备份集的情况,一直想做一次image copy的测试,一直脱,主要原因自己不想做这个测试.
1095 0
[20161118]rman备份的疑问2.txt
[20161118]rman备份的疑问2.txt --这个是我前几天做测试时遇到的疑问,不知道为什么rman 备份要修改数据块的dba地址。 --我在itpub上也问了这个问题,链接http://www.itpub.net/thread-2071504-1-1.html,可惜没有人解答。
663 0
[20161114]rman备份的疑问.txt
[20161114]rman备份的疑问.txt --这个是我前几天做测试时遇到的疑问,不知道为什么rman 备份要修改数据块的dba地址。 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                  ...
731 0
[20150717]备份变大.txt
[20150717]备份变大.txt --前几天别人系统升级,11.2.0.3升级到11.2.0.4出现备份增大的情况,我看了他升级的文档,感觉最大的可能建立了restore point。
801 0
[20150715]Wrong Results.txt
[20150715]Wrong Results.txt http://afatkulin.blogspot.com/2015/07/wrong-results.html --重复测试: SCOTT@test> @ver1 PORT_STRING    ...
915 0
[20150601]模拟ora-00600[2608]错误.txt
[20150601]模拟ora-00600[2608]错误.txt --前几天在测试使用bbed解决丢失的归档,链接: http://blog.itpub.net/267265/viewspace-1676438/ [20150529]使用bbed解决丢失的归档.
800 0
[20150529]man tmux less.txt
[20150529]man tmux less.txt --在linux下有一个小问题(我测试几个版本都存在这个问题),如果在tmux下使用man显示文档时,如果按q退出,会清除屏幕显示.
679 0
[20120615]rman备份问题.txt
[20120615]rman备份问题.txtbackup spfile;Starting Control File and SPFILE Autobackup at 2012-06-15 09:37:09RMAN-00571: =================...
750 0
+关注
lfreeali
熟悉oracle数据库性能优化,rman备份,数据库恢复技术.
2121
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载