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

时间: 2024-09-19 22:20:56

[20150601]rman备份出现坏块.txt的相关文章

[20160523]rman备份与检查点2.txt

[20160523]rman备份与检查点2.txt --写过几篇关于检查点的文章,测试看看如果rman做备份时是否写检查点. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING         VERSION        BANNER ------------------- -------------- ---------------------------------------------------------------------------- x86

[20160524]rman备份与检查点4.txt

[20160524]rman备份与检查点4.txt --链接: http://blog.itpub.net/267265/viewspace-2105221/ http://blog.itpub.net/267265/viewspace-2105223/ --昨晚仔细思考,重复测试看看,使用新的控制文件是否可以恢复.感觉我的问题在于我做了catalog注册了备份文件时丢失某些信息.重新 --测试看看. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING      

[20160523]rman备份与检查点3.txt

[20160523]rman备份与检查点3.txt --从前面的测试可以发现: --1.通过以上信息可以确定备份文件会写检查点. --2.而且备份文件是先写检查点,再做备份. --我这里就产生1个疑问,假设某个数据文件备份时间很长,这样数据文件的某个数据块的scn可能大于文件头的CHECKPOINT_CHANGE#.当我 --们恢复使用不完全恢复到某个时间点或者SCN,应该使用那个备份文件呢?做一个测试来说明问题. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRIN

[20160722]对象C_OBJ#_INTCOL#有坏块.txt

[20160722]对象C_OBJ#_INTCOL#有坏块.txt --前几天看到的帖子,一直没时间测试,链接如下: http://www.itpub.net/thread-2063836-1-1.html --我以前按照eygle的链接http://www.eygle.com/archives/2012/05/event_38003_c_obj_intcol.html做过测试,测试在11.2.0.2下做的. --通过设置alter system set event='38003 trace n

[20161118]rman备份的疑问2.txt

[20161118]rman备份的疑问2.txt --这个是我前几天做测试时遇到的疑问,不知道为什么rman 备份要修改数据块的dba地址. --我在itpub上也问了这个问题,链接http://www.itpub.net/thread-2071504-1-1.html,可惜没有人解答. --具体细节不清楚,读取数据文件然后重新编码组织数据,将kcbh.rdba_kcbh的后2位放入tailchk中,设置spare3_kcbh=0x0001, --也许为了区分备份与数据文件,当然还有别的目的,再

[20140424]oracle的逻辑坏块.txt

[20140424]oracle的逻辑坏块.txt 今天上午本来想做一个11GR2的Automatic block media repair,链接如下:http://blog.itpub.net/267265/viewspace-1148315/ 但是我遇到一个奇怪的问题,检查和的计算问题: SYS@test> @ver BANNER --------------------------------------------------------------------------------

ORA-19566 exceeded limit of 0 corrupt blocks数据坏块处理

    问题描述 RMAN备份失败,报错如下:   channel ch1: starting piece 1 at 02-NOV-12 released channel: ch1 RMAN-00571: RMAN-00569: ==== ERROR MESSAGE STACK FOLLOWS ============ RMAN-00571: ========= RMAN-03009: failure of backup command on ch1 channel at 11/02/2012

oracle中RMAN备份和检查逻辑坏块

1. RMAN备份时是默认检查物理坏块. 2. 如果要检查逻辑坏块,可以用如下语句: $ rman target / RMAN> backup check logical validate database; 注上述语句,只是检查,不会备份的. 3. 如果要在备份的同时,进行逻辑坏块检查,可以用: $ rman target / RMAN> backup check logical database; 4.如果发现坏逻辑如何处理,下面补充一篇教程. 利用RMAN检测数据库坏块的脚本 虽然我们也

[20150811]模拟坏块处理.txt

[20150811]模拟坏块处理.txt --如果存在备份,修复坏块还是相对简单的.在11g下: select * from V$DATABASE_BLOCK_CORRUPTION; --在rman下执行: blockrecover corruption list; --如果数据块没有使用,没有分配data_object_id而出现坏块,如何恢复呢?一般采用的方法建立新对象的方法,格式化这个数据块. --具体测试如下: 1.建立测试环境: SCOTT@test> @ver1 PORT_STRIN