[20220909]bbed关于删除记录恢复的问题.txt「终于解决」

[20220909]bbed关于删除记录恢复的问题.txt「终于解决」[20220909]bbed关于删除记录恢复的问题.txt–//快下班被别人问的关于删除记录使用bbed恢复的问题,我开始以为很快讲解完,删除记录oracle仅仅打上一个标识,实际的记录还存在.–

[20220909]bbed关于删除记录恢复的问题.txt

[20220909]bbed关于删除记录恢复的问题.txt

–//快下班被别人问的关于删除记录使用bbed恢复的问题,我开始以为很快讲解完,删除记录oracle仅仅打上一个标识,实际的记录还存在.

–//实际上地方问的是多次DML(删除记录的情况),实际上只要dump还能看到,bbed还是可以恢复的,做一个例子说明:

1.环境:

SCOTT@test01p> @ver1

PORT_STRING          VERSION    BANNER                                                                       CON_ID

——————– ———- —————————————————————————- ——

IBMPC/WIN_NT64-9.1.0 12.2.0.1.0 Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 – 64bit Production      0

SCOTT@test01p> create table deptx as select * from dept ;

Table created.

SCOTT@test01p> select rowid from deptx where rownum=1;

ROWID

——————

AAAHGVAALAAAACjAAA

SCOTT@test01p> @ rowid AAAHGVAALAAAACjAAA

    OBJECT       FILE      BLOCK        ROW ROWID_DBA   DBA    TEXT

———- ———- ———- ———- ———– —— —————————————-

     29077         11        163          0  0x2C000A3  11,163 alter system dump datafile 11 block 163

SCOTT@test01p> alter system checkpoint ;

System altered.

SCOTT@test01p> alter system checkpoint ;

System altered.

2.测试:

BBED> set dba 11,164

        DBA             0x02c000a4 (46137508 11,164)

–//注:bbed for windows 访问的block要加1,主要问题在于无法识别数据文件的第0块(OS块头)

BBED> p *kdbr

rowdata[66]

———–

ub1 rowdata[66]                             @8162     0x2c

BBED> p kdbr

sb2 kdbr[0]                                 @142      8038

sb2 kdbr[1]                                 @144      8016

sb2 kdbr[2]                                 @146      7996

sb2 kdbr[3]                                 @148      7972

SCOTT@test01p> delete from deptx where deptno=20;

1 row deleted.

SCOTT@test01p> commit ;

Commit complete.

SCOTT@test01p> alter system checkpoint ;

System altered.

–//通过bbed观察如下:

BBED> p kdbr dba 11,164

sb2 kdbr[0]                                 @142      8038

sb2 kdbr[1]                                 @144      8016

sb2 kdbr[2]                                 @146      7996

sb2 kdbr[3]                                 @148      7972

BBED> x /rncc *kdbr[0]

rowdata[66]                                 @8162

———–

flag@8162: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8163: 0x00

cols@8164:    3

col    0[2] @8165: 10

col   1[10] @8168: ACCOUNTING

col    2[8] @8179: NEW YORK

BBED> x /rncc *kdbr[1]

rowdata[44]                                 @8140

———–

flag@8140: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)

lock@8141: 0x02

cols@8142:    0

–//你可以发现flag 从0x2c变成 0x3c,打上了KDRHFD标识表示删除,恢复实际上就是修改flag=0x2c(也就是取消KDRHFD标识).

–//继续:

SCOTT@test01p> delete from deptx where deptno=30;

1 row deleted.

SCOTT@test01p> commit ;

Commit complete.

SCOTT@test01p> alter system checkpoint ;

System altered.

BBED> p kdbr dba 11,164

sb2 kdbr[0]                                 @142      8038

sb2 kdbr[1]                                 @144      8016

sb2 kdbr[2]                                 @146      7996

sb2 kdbr[3]                                 @148      7972

–//偏移量还是不变,也就是这样的情况下以上两条记录都可以恢复.

SCOTT@test01p> update deptx set dname=upper(dname) where deptno=10;

1 row updated.

SCOTT@test01p> commit ;

Commit complete.

SCOTT@test01p> alter system checkpoint ;

System altered.

BBED> p kdbr dba 11,164

sb2 kdbr[0]                                 @142      8038

sb2 kdbr[1]                                 @144      8016

sb2 kdbr[2]                                 @146      7996

sb2 kdbr[3]                                 @148      7972

–//我执行update操作,但是行目录并没有修改,主要原因在于DML修改的记录长度没有变化,oracle并不会改变行目录的偏移。

–//而是就地修改相关记录信息。

SCOTT@test01p> update deptx set dname=upper(dname)||”0″ where deptno=10;

1 row updated.

SCOTT@test01p> commit ;

Commit complete.

SCOTT@test01p> alter system checkpoint ;

System altered.

BBED> p kdbr dba 11,164

sb2 kdbr[0]                                 @142      7945

sb2 kdbr[1]                                 @144      2

sb2 kdbr[2]                                 @146     -1

sb2 kdbr[3]                                 @148      7972

–//在DML后修改记录长度发生变化后,oracle在修改kdbr[0]的偏移时,同时也修改kdbr[1],kdbr[2]的信息,

–//这个应该是oracle的一个设计理念,顺手把以前没做的事情做完…

–//你可以从修改的信息可以推断,如果下次操作是插入,使用那个行目录时应该从kdbr[1],kdbr[2]选择。

–//如果你仔细观察可以发现删除记录的行目录记录的偏移记录的信息形成1个链表结构,sb2 kdbr[2] = -1 表示链表结构的尾部.

–//并且可以通过行目录偏移 kdbr[N] 是否 >= kdbh.kdbhnrow (当前为4),来确定是否指向正确的记录信息。

BBED> p kdbh dba 11,164

struct kdbh, 14 bytes                       @124

   ub1 kdbhflag                             @124      0x00 (NONE)

   b1 kdbhntab                              @125      1

   b2 kdbhnrow                              @126      4

=======================================================

   sb2 kdbhfrre                             @128      1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   

   sb2 kdbhfsbo                             @130      26

   sb2 kdbhfseo                             @132      7945

   b2 kdbhavsp                              @134      7987

   b2 kdbhtosp                              @136      7987

–//kdbhfrre = 1 ,表示链表结构的开头,也就是如果在块DML有插入时,会先使用kdbr[1]行目录.

–//你可以发现这时kdbr[1],kdbr[2]执行的偏移并没有覆盖,要恢复一定ok的.

BBED> assign  kdbr[1] = 8016;

Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y

sb2 kdbr[0]                                 @144      8016

BBED> assign  kdbr[2] = 7996;

sb2 kdbr[0]                                 @146      7996

BBED> x /rncc *kdbr[1]

rowdata[71]                                 @8140

———–

flag@8140: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)

lock@8141: 0x02

cols@8142:    0

BBED> x /rncc *kdbr[2]

rowdata[51]                                 @8120

———–

flag@8120: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)

lock@8121: 0x03

cols@8122:    0

–//修改flag取消KDRHFD标识:

BBED> assign  offset 8140 = 0x2c;

ub1 rowdata[0]                              @8140     0x2c

BBED> assign  offset 8120 = 0x2c;

ub1 rowdata[0]                              @8120     0x2c

BBED> x /2rncc *kdbr[2]

rowdata[51]                                 @8120

———–

flag@8120: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8121: 0x03

cols@8122:    3

col    0[2] @8123: 30

col    1[5] @8126: SALES

col    2[7] @8132: CHICAGO

rowdata[71]                                 @8140

———–

flag@8140: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8141: 0x02

cols@8142:    3

col    0[2] @8143: 20

col    1[8] @8146: RESEARCH

col    2[6] @8155: DALLAS

–//现在2条记录都可以显见,剩下就是恢复对应数据块的完整性以及一致性问题.

BBED> sum apply

Check value for File 11, Block 164:

current = 0x9fe2, required = 0x9fe2

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

Block Checking: DBA = 46137507, Block Type = KTB-managed data block

data header at 0x2c4027c

kdbchk: row locked by non-existent transaction

        table=0   slot=2

        lockid=3   ktbbhitc=3

Block 163 failed with check code 6101

–//lock 偏移8121 =0x0.

BBED> assign offset 8121=0x0;

ub1 rowdata[0]                              @8121     0x00

BBED> sum apply

Check value for File 11, Block 164:

current = 0x9ce2, required = 0x9ce2

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

Block Checking: DBA = 46137507, Block Type = KTB-managed data block

data header at 0x2c4027c

kdbchk: entries on the free list are not ordered

        next=8016 nrow=4 chas=1

Block 163 failed with check code 6106

BBED> assign kdbh.kdbhfrre=-1

sb2 kdbhfrre                                @128     -1

BBED> sum apply

Check value for File 11, Block 164:

current = 0x631c, required = 0x631c

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

Block Checking: DBA = 46137507, Block Type = KTB-managed data block

data header at 0x2c4027c

kdbchk: xaction header lock count mismatch

        trans=2 ilk=1 nlo=2

Block 163 failed with check code 6108

–//lock 偏移8141 =0x0.

BBED> assign offset 8141=0x0;

ub1 rowdata[0]                              @8141     0x00

BBED> sum apply

Check value for File 11, Block 164:

current = 0x611c, required = 0x611c

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

Block Checking: DBA = 46137507, Block Type = KTB-managed data block

data header at 0x2c4027c

kdbchk: the amount of space used is not equal to block size

        used=119 fsc=0 avsp=7987 dtl=8064

Block 163 failed with check code 6110

–//dtl-used-fsc = avsp

–//8064-119-0 = 7945

BBED> assign kdbh.kdbhavsp=7945;

b2 kdbhavsp                                 @134      7945

BBED> sum apply

Check value for File 11, Block 164:

current = 0x6126, required = 0x6126

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

Block Checking: DBA = 46137507, Block Type = KTB-managed data block

data header at 0x2c4027c

kdbchk: space available on commit is incorrect

        tosp=7987 fsc=0 stb=0 avsp=7945

Block 163 failed with check code 6111

BBED> assign kdbh.kdbhtosp=7945;

b2 kdbhtosp                                 @136      7945

BBED> sum apply

Check value for File 11, Block 164:

current = 0x611c, required = 0x611c

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

–//OK现在恢复完成.

SCOTT@test01p> alter system flush BUFFER_CACHE;

System altered.

SCOTT@test01p> select * from deptx;

    DEPTNO DNAME                LOC

———- ——————– ————-

        10 ACCOUNTING0          NEW YORK

        20 RESEARCH             DALLAS

        30 SALES                CHICAGO

        40 OPERATIONS           BOSTON

–//删除记录已经恢复.

–//原来deptno= 10 的记录没有覆盖,理论将也可以恢复.继续尝试看看.

BBED> assign kdbr[0]=8038

sb2 kdbr[0]                                 @142      8038

BBED> x /rncc *kdbr[0]

rowdata[93]                                 @8162

———–

flag@8162: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8163: 0x00

cols@8164:    3

col    0[2] @8165: 10

col   1[10] @8168: ACCOUNTING

col    2[8] @8179: NEW YORK

–//这样修改行目录偏移指向执行原来的位置.

BBED> sum apply

Check value for File 11, Block 164:

current = 0x6173, required = 0x6173

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

Block Checking: DBA = 46137507, Block Type = KTB-managed data block

data header at 0x2c4027c

kdbchk: xaction header lock count mismatch

        trans=2 ilk=1 nlo=0

Block 163 failed with check code 6108

BBED> assign offset 8163  = 0x02

ub1 rowdata[0]                              @8163     0x02

BBED> sum apply

Check value for File 11, Block 164:

current = 0x6373, required = 0x6373

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

Block Checking: DBA = 46137507, Block Type = KTB-managed data block

data header at 0x2c4027c

kdbchk: the amount of space used is not equal to block size

        used=118 fsc=0 avsp=7945 dtl=8064

Block 163 failed with check code 6110

–//dtl-used-fsc = avsp

–//8064-118-0 = 7946

BBED> assign kdbh.kdbhavsp=7946;

b2 kdbhavsp                                 @134      7946

BBED> assign kdbh.kdbhtosp=7946;

b2 kdbhtosp                                 @136      7946

BBED> sum apply

Check value for File 11, Block 164:

current = 0x6373, required = 0x6373

BBED> verify

DBVERIFY – Verification starting

FILE = D:APPORACLEORADATATESTTEST01PUSERS01.DBF

BLOCK = 163

–//ok,现在恢复到原始建立时的状态.

SCOTT@test01p> alter system flush BUFFER_CACHE;

System altered.

SCOTT@test01p> select * from deptx;

    DEPTNO DNAME                LOC

———- ——————– ————-

        10 ACCOUNTING           NEW YORK

        20 RESEARCH             DALLAS

        30 SALES                CHICAGO

        40 OPERATIONS           BOSTON

3.总结:

–//很久不使用bbed,有点生疏了。

–//我前面的恢复定位行目录信息时使用原来显示的信息,实际的恢复只能通过find检索0x2c,0x3c字符定位。

–//然后通过执行 x /rncc offset NNNN,确定显示的信息是否正确。获得NNNN偏移是绝对偏移,必须减去kdbh的偏移(这里是124,前面

–//有3个ITL槽),这样才能确定行目录的相对偏移值。

–//总之到对应的数据块操作相对复杂!!!

BBED> p kdbr dba 11,164

sb2 kdbr[0]                                 @142      8038

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

sb2 kdbr[1]                                 @144      8016

sb2 kdbr[2]                                 @146      7996

sb2 kdbr[3]                                 @148      7972

BBED> p kdbh dba 11,164

struct kdbh, 14 bytes                       @124

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   ub1 kdbhflag                             @124      0x00 (NONE)

   b1 kdbhntab                              @125      1

   b2 kdbhnrow                              @126      4

   sb2 kdbhfrre                             @128      1

   sb2 kdbhfsbo                             @130      26

   sb2 kdbhfseo                             @132      7945

   b2 kdbhavsp                              @134      7987

   b2 kdbhtosp                              @136      7987

BBED> x /rncc *kdbr[0]

rowdata[66]                                 @8162

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

———–

flag@8162: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8163: 0x00

cols@8164:    3

col    0[2] @8165: 10

col   1[10] @8168: ACCOUNTING

col    2[8] @8179: NEW YORK

–// 8162-124 = 8038

原文地址:https://www.cnblogs.com/lfree/archive/2022/09/21/16717220.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/4740.html

(0)
上一篇 2023-06-06 20:30
下一篇 2023-06-07

相关推荐

  • Python数据导出到Excel

    Python数据导出到Excela href=”https://www.python100.com/a/sm.html”font color=”red”免责声明/font/a a href=”https://beian.miit.gov.cn/”苏ICP备2023018380号-1/a Copyright www.python100.com .Some Rights Reserved.

    2024-08-25
    24
  • SQL Server解惑——对象命名的唯一性小结

    SQL Server解惑——对象命名的唯一性小结关于SQL Server数据库中的对象命名的唯一性问题。例如表、索引、约束等数据库对象,有时候DBA在做数据库维护时,经常要创建对象或重命名对象,此时就会遇到一个问题,对象命名的唯一性问题。虽然是一个

    2023-01-30
    149
  • mongotemplate游标查询_游标使用

    mongotemplate游标查询_游标使用一、什么是游标? 游标(Cursor)是处理数据的一种方法,为了查看或者处理结果集中的数据,游标提供了在结果集中一次一行或者多行前进或向后浏览数据的能力。 游标实际上是一种能从包括多条数据记录的结果…

    2023-02-27
    171
  • 罗景:连接效率优化实践[亲测有效]

    罗景:连接效率优化实践[亲测有效]分享嘉宾:罗景 58同城 高级架构师 编辑整理:洪鹏飞 内容来源:DataFun AI Talk《连接效率优化实践》 出品社区:DataFun **导读:**本次分享由以下几个部分构成—— 58的业务

    2023-05-22
    148
  • 全球银行最大分布式核心系统全面上线,邮储银行做到了![通俗易懂]

    全球银行最大分布式核心系统全面上线,邮储银行做到了![通俗易懂]摘要:近年来,国家陆续出台金融科技相关政策,提出创新驱动发展战略,强调以新一代信息和网络技术为支撑,拓展互联网金融,促进技术创新和商业模式创新的融合。 本文分享自华为云社区《全球银行最大分布式核心系统

    2023-06-20
    149
  • Python转换成小写字符串

    Python转换成小写字符串在Python中,字符串是一种非常常见的数据类型,我们经常需要对字符串进行各种操作,如转换大小写、截取子串、替换字符等等。在本文中,我们将主要探讨如何将一个Python字符串转换成小写字符串。

    2024-01-25
    97
  • MySQL学习笔记(11):存储过程和函数

    MySQL学习笔记(11):存储过程和函数本文更新于2019-06-23,使用MySQL 5.7,操作系统为Deepin 15.4。 SQL语句 创建存储过程或函数 创建存储过程: CREATE PROCEDURE name ({[IN|OU

    2023-03-18
    151
  • hadoop常见的文件格式及压缩算法是什么_位图文件格式

    hadoop常见的文件格式及压缩算法是什么_位图文件格式前言 该文章中将会整理一些大数据中常见的文件格式及压缩算法的理论知识,作为后期实践的理论指导。理论+实践才会更方便用这些文件格式和压缩算法。 目前hadoop中常见的文件格式有textfile、seq

    2023-06-01
    144

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注