[20150513]人为破坏数据块.txt

简介: [20150513]人为破坏数据块.txt --演示的目的,参考链接: http://www.askmaclean.com/archives/oracle-make-block-physical-corruption.

[20150513]人为破坏数据块.txt

--演示的目的,参考链接:
http://www.askmaclean.com/archives/oracle-make-block-physical-corruption.html

--不要在生产系统测试!!!!!

1.建立测试环境:

SCOTT@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

SCOTT@test> create table depty as select * from dept ;
Table created.

SCOTT@test> select rowid,depty.* from depty ;
ROWID                    DEPTNO DNAME          LOC
------------------ ------------ -------------- -------------
AAAPbxAAEAAAAUkAAA           10 ACCOUNTING     NEW YORK
AAAPbxAAEAAAAUkAAB           20 RESEARCH       DALLAS
AAAPbxAAEAAAAUkAAC           30 SALES          CHICAGO
AAAPbxAAEAAAAUkAAD           40 OPERATIONS     BOSTON

SCOTT@test> @ &r/lookup_rowid AAAPbxAAEAAAAUkAAA
      OBJECT         FILE        BLOCK          ROW DBA                  TEXT
------------ ------------ ------------ ------------ -------------------- ----------------------------------------
       63217            4         1316            0 4,1316               alter system dump datafile 4 block 1316

--保证脏块写盘.
SCOTT@test> alter system checkpoint;
System altered.

--安全需要备份数据文件.
RMAN> backup datafile 4 format '/tmp/users_%u' ;
Starting backup at 2015-05-13 12:02:58
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00004 name=/mnt/ramdisk/test/users01.dbf
channel ORA_DISK_1: starting piece 1 at 2015-05-13 12:02:59
channel ORA_DISK_1: finished piece 1 at 2015-05-13 12:03:00
piece handle=/tmp/users_01q6r3rj tag=TAG20150513T120259 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2015-05-13 12:03:00

2.开始测试:

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

RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 1316 clear;

Starting blockrecover at 2015-05-13 12:07:46
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 devtype=DISK
Finished blockrecover at 2015-05-13 12:07:46

SCOTT@test> select rowid,depty.* from depty ;
select rowid,depty.* from depty
                          *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 1316)
ORA-01110: data file 4: '/mnt/ramdisk/test/users01.dbf'


RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 1316 ;

Starting blockrecover at 2015-05-13 12:08:51
using channel ORA_DISK_1

channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00004
channel ORA_DISK_1: reading from backup piece /tmp/users_01q6r3rj
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/tmp/users_01q6r3rj tag=TAG20150513T120259
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:02

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished blockrecover at 2015-05-13 12:08:54

==补充说明,10g不支持如下格式:
RMAN> recover datafile 4 block 1316 ;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "block": expecting one of: "archivelog, auxiliary, allow, check, comma, delete, from, high, noredo, noparallel, parallel, ;, skip, test, until, undo"
RMAN-01007: at line 1 column 20 file: standard input

RMAN> recover datafile 4 block 1316 clear;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "block": expecting one of: "archivelog, auxiliary, allow, check, comma, delete, from, high, noredo, noparallel, parallel, ;, skip, test, until, undo"
RMAN-01007: at line 1 column 20 file: standard input
================

SCOTT@test> select rowid,depty.* from depty ;

ROWID                    DEPTNO DNAME          LOC
------------------ ------------ -------------- -------------
AAAPbxAAEAAAAUkAAA           10 ACCOUNTING     NEW YORK
AAAPbxAAEAAAAUkAAB           20 RESEARCH       DALLAS
AAAPbxAAEAAAAUkAAC           30 SALES          CHICAGO
AAAPbxAAEAAAAUkAAD           40 OPERATIONS     BOSTON

--数据恢复.


== >
补充一点:11g才可以使用如下,10g不行!在11g下做的测试,省略许多步骤:

RMAN> RECOVER DATAFILE 4 BLOCK 1523 clear;

Starting recover at 2015-05-13 15:14:09
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
Finished recover at 2015-05-13 15:14:10

 

RMAN> RECOVER corruption list;

Starting recover at 2015-05-13 15:15:52
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3

channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00004
channel ORA_DISK_1: reading from backup piece /tmp/users_3gq6rf0g
channel ORA_DISK_1: piece handle=/tmp/users_3gq6rf0g tag=TAG20150513T151319
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished recover at 2015-05-13 15:16:00

SCOTT@test> select rowid,depty.* from depty ;
ROWID                  DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AABKCeAAEAAAAXzAAA         10 ACCOUNTING     NEW YORK
AABKCeAAEAAAAXzAAB         20 RESEARCH       DALLAS1
AABKCeAAEAAAAXzAAC         30 SALES          CHICAGO
AABKCeAAEAAAAXzAAD         40 OPERATIONS     BOSTON
AABKCeAAEAAAAXzAAE         50 MARKETING      LONDON

目录
相关文章
|
5月前
|
存储 Unix 数据挖掘
【北亚服务器数据恢复】LUN映射出错导致文件系统一致性出错的数据恢复案例
服务器数据恢复环境: san环境下的存储上一组由6块硬盘组建的RAID6,划分为若干LUN,MAP到跑不同业务的服务器上,服务器上层是SOLARIS操作系统+UFS文件系统。 服务器故障: 业务需求需要增加一台服务器跑新增的应用,工作人员在原服务器在线的状态下将其中一个lun映射到一台新服务器上。实际上这个刚映射过去的卷已经map到了solaris生产系统上的某个lun上了。新服务器对这个映射过来的卷进行初始化,原来的solaris系统上的磁盘报错,重启服务器后这个卷已经无法挂载了。 联系原厂工程师寻求帮助,原厂工程师检测后执行了fsck操作,完成fsck操作后文件系统挂载成功,查看数据时发
|
存储 关系型数据库 块存储
Ceph 磁盘损坏现象和解决方法
Damaged disks 对于存储系统,磁盘是消耗品,损坏是很常见的,所以这篇文章记录一下 Ceph 中出现磁盘损坏时的现象,以及如何定位和更换损坏的磁盘。
2089 0
|
2月前
|
数据库 OceanBase
"磁盘空洞"通常指的是磁盘上有空间未被使用
【2月更文挑战第29天】"磁盘空洞"通常指的是磁盘上有空间未被使用
12 2
|
2月前
|
存储 运维 安全
服务器数据恢复—存储互斥不当导致VMFS卷损坏的数据恢复案例
某公司的信息管理平台,通过3台虚拟机共享了一台存储设备供企业内部使用,存储设备中存放了公司内部重要的数据文件。 由于业务增长的需要,管理员又在这个存储网络上连接了一台Windows server服务器,结果这台存储变得不可用了。 管理员对该存储进行故障排查时发现存储中虚拟磁盘丢失,分区表丢失。重启该存储设备后故障依旧。 由于存储中的数据十分重要,没有备份。管理员为了安全起见,联系北亚企安数据恢复中心寻求帮助。 经过硬件工程师的检测,没有发现存储存在硬件故障。存储中的硬盘经过硬件工程师的检测后也没有发现任何物理故障,都可以正常读取。基本上可以排除故障是由于硬件导致的。
|
存储
无主复制系统(2)-读修复和反熵
复制模型应确保所有数据最终复制到所有副本。在一个失效节点重新上线后,如何追上错过的写入?Dynamo风格的数据存储系统常用机制
65 0
|
安全 测试技术 Windows
警惕可执行文件:三类危险TXT类型文件
假如您收到的邮件附件中有一个看起来是这样的文件:QQ 放送.txt,您是不是认为它肯定是纯文本文件?我要告诉您,不一定!它的实际文件名可以是QQ 放送.txt{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}.{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}在注册表里是HTML文件关联的意思。
2640 0
|
Oracle 关系型数据库 测试技术
[20180306]数据块检查和2.txt
[20180306]数据块检查和2.txt --//昨天测试修改检查和偏移为0x0(偏移在16,17字节),在修改前面的15字节为0,一般数据块可以通过检查. --//链接:http://blog.
899 0
|
测试技术 数据库 数据库管理
[20180306]数据块检查和.txt
[20180306]数据块检查和.txt --//如果数据块检查和不对,数据库无法读取相应块,会报错. --//检查和位于块偏移16字节处. ub1 flg_kcbh                            @15 ub2 chkval...
769 0