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

[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;
--当然如果还有备份,可以不要从这个备份集来恢复.

上一篇:Oracle 数据库优化的R方法(Method R)


下一篇:分享6个实用的HTML5本地存储(Local Storage)教程