Oracle BBED 使用建议

[oracle@oralinux lib]$ make -f ins_rdbms.mk
$ORACLE_HOME/rdbms/lib/BBED

为了确认创建，查看是否已创建BBED可执行文件。在这个例子中，make命令在rdbms/lib目录中被执行。 BBED可以放在任何一个DBA喜欢的地方。此外，如果需要的话请更改权限。

-rwxr-xr-x 1 oracle dba 434057 Aug 25 16:26 BBED

为了证实该实用程序确实运行，要调用它。本例使用10g版本，这表明发行2.0.0.0.0版本，9.0.4版本也是如此。除了著作权的变化，发行的版本在相当长的一段时间没有改变。

[oracle@oralinux lib]$ ./BBED

Password:

BBED: Release 2.0.0.0.0 – Limited Production on Wed Aug 27 16:17:06 2015

Copyright (c) 1982, 2005, Oracle. All rights reserved.

************* !!! For Oracle Internal Use only !!! ***************

BBED>

请注意，会提示用户输入密码。几乎所有在网上搜到的BBED参考文献都会提到，如果一个人首选使用BBED的动机够强，那他一定够聪明能确定自己的密码。密码是blockedit。它被看作是在BBED十六进制转储文件中的BLOCKEDIT。在/ usr/ bin中使用XXD创建BBED转储，然后在文件中查找’BBED>“。上面的几行就是BLOCKEDIT。

里程数可能会有所不同，但可以使用装载了Oracle8.1.6的BBED.EXE，这与上一次Windows版本被列入RDBMS软件安装有关，也可以在更高版本的Oracle数据文件中使用该可执行文件。

准备工作就绪后，再看语法和示例。首先：从客户的角度来看，BBED是个未公开的、不受支持的实用程序。如果没有引导借助Oracle Support使用这个工具，DBA会独立运行。如果不知道要做什么，就不要在生产数据库中使用BBED。如果不能承受失败，就不要在任何数据库上使用BBED。提取使用此工具的数据库备份。

如果DBA需要恢复数据，并发现自己陷入困境，迄今做的很多努力也没用，这是最后的解决办法。可能会有更大更好的工具，但“此时此地”的工具就是BBED。

如果需要此工具来保存/救援/恢复生产数据库，对DBA最有利的是先冷备份，然后提取备份的副本作为测试平台。换句话说，操作文件与实际文件分开。如果DBA尝试恢复数据，将其从救援实例转换回生产实例。

关于BBED的Oracle文档，在公共领域内检索，包括在MetaLink上搜，或是我们现在知道的My Oracle Support，几乎找不到。 MetaLink文档62015.1有（假设它仍然存在于OSS内）一个说明，“BBED只是一个支持工具，不应与客户进行讨论。”文档内容在邮件列表中可用，而且支持协议可以这本书内阻止其出版。 (详见http://www.freelists.org/post/oracle-l/is-it-the-bbed    )

尽管如此，有关此工具和其他工具的信息可以从Oracle软件附带的信息库中收集到。$ORACLE_HOME/rdbms/mesg 包含一个名为BBEDus.msg的文件。提取或识别文件，仔细阅读其内容以得知此工具是如何运行的。信息库末尾是有效的位置参数的列表，其中之一就是HELP。Oracle的Windows安装仍然包含信息库，虽然不再包含BBED.EXE。

开始运行BBED前，有必要大概了解数据块周围的路径，包括如何在一个表中由行获得内部块的信息。这个以及其他信息，通常包括绝对文件号，完整路径和数据文件的名称，块中数据文件的大小，数据块地址，块编号，块大小和块类型等信息。

DBA需要一个报告工具输出有关块的信息。不止一种方法可以得到这个信息，但最简单的是基于使用内置的名为DBMS_ROWID所提供的PL / SQL。

至少在Oracle8i中这十大功能和一个程序的文件包已经可用，但使用这个文件包对DBA而言是全新的。几个功能信息借助OUT参数，在一个过程中结合。围绕DBMS_ROWID.ROWID_INFO创建自己的包装过程，使之可重复使用。

在EMP表中名为Scott的分析师将被晋升为经理。改变SQL * Plus以外的表数据的步骤如下：

1.如果ROWID未知，获取其信息

2.  关闭数据库，并采取冷备份

3.  用参数文件启动bbed，请务必提供相关的数据文件

4.  找到数据块地址

5.  在字符串分析师开始的地方找到偏移，并确认数据/位置

6.   模式更改为编辑，除非parfile已包含该信息

7.      修改数据

8.      确认数据变化

9.     运用此变化

10.  重新启动数据库，并查找此变化

所选择的方法是用户对这些数据已经有所了解，例如，用户想要更改的记录，以及ROWID/ DBA信息。这个例子中dba仍然是4,32。

关闭数据库并采取冷备份，同时使用跟以前一样的PARFILE后，就可以启动一个BBED会话。启动后，浏览到DBA4,32并设置偏移为0，这样DBA就有一个已知的起始位置供搜索/查找操作遵循。

[oracle@oralinux bbed]$ bbed parfile=bbed.par

Password:

BBED: Release 2.0.0.0.0 – Limited Production on Sun Aug 31 17:55:58 2015

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

************* !!! For Oracle Internal Use only !!! ***************

BBED> set dba 4,32

DBA             0x01000020 (16777248 4,32)

BBED> set offset 0

OFFSET          0

find命令将会转储多行。搜索字符串时，可以使用C标志。

BBED> find /c SCOTT

File: /opt/app/oracle/oradata/ORCL2/users01.dbf (4)

Block: 32               Offsets: 7864 to 8191           Dba:0x01000020

————————————————————————

53434f54 5407414e 414c5953 5403c24c 430777bb 04130101 0102c21f ff02c115

2c010803 c24e5305 434c4152 4b074d41 4e414745 5203c24f 280777b5 06090101

0103c219 33ff02c1 0b2c0108 03c24d63 05424c41 4b45074d 414e4147 455203c2

4f280777 b5050101 010103c2 1d33ff02 c11f2c01 0803c24d 37064d41 5254494e

0853414c 45534d41 4e03c24d 630777b5 091c0101 0103c20d 3302c20f 02c11f2c

010803c2 4c43054a 4f4e4553 074d414e 41474552 03c24f28 0777b504 02010101

03c21e4c ff02c115 2c010803 c24c1604 57415244 0853414c 45534d41 4e03c24d

630777b5 02160101 0103c20d 3302c206 02c11f2c 010803c2 4b640541 4c4c454e

0853414c 45534d41 4e03c24d 630777b5 02140101 0102c211 02c20402 c11f2c01

0803c24a 4605534d 49544805 434c4552 4b03c250 030777b4 0c110101 0102c209

ff02c115 1006dbbf

<32 bytes per line>

转储当前偏移并确认SCOTT被找到。

BBED> dump /v dba 4,32 offset 7864 count 32

File: /opt/app/oracle/oradata/ORCL2/users01.dbf (4)

Block: 32      Offsets: 7864 to 7895  Dba:0x01000020

——————————————————-

53434f54 5407414e 414c5953 5403c24c l SCOTT.ANALYST.?

430777bb 04130101 0102c21f ff02c115 l C.w?……?..?

<16 bytes per line>

输出向DBA表明，SCOTT开始于DBA内的7864偏移。计数超过六个位置就是ANALSYT开始的地方。为了证实这一点，将偏移（具体地说，可以增加或减少位置，如+4或-3）移动到7870，并再次转储内容。

BBED> set offset 7870

OFFSET          7870

BBED> d /v

File: /opt/app/oracle/oradata/ORCL2/users01.dbf (4)

Block: 32      Offsets: 7870 to 7901  Dba:0x01000020

——————————————————-

414e414c 59535403 c24c4307 77bb0413 l ANALYST.?C.w?..

01010102 c21fff02 c1152c01 0803c24e l ….?..?,…?

<16 bytes per line>

注意最后一个转储命令使用的句法。如果不知道位置，可以在第一次转储中将其设置为完成。现在是时候用MANAGER 替换ANALYST，这是通过修改命令来完成的。现在修改它并转储以确认变化。修改可以通过多种格式（同FIND）完成，所以可读性最简单的情况就是找到它并通过字符串进行修改，这就是/ C的操作。不要忘了，如果有必要更改编辑模式（BBED> set mode edit）。

BBED> modify /c MANAGER

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

File: /opt/app/oracle/oradata/ORCL2/users01.dbf (4)

Block: 32               Offsets: 7870 to 7901           Dba:0x01000020

————————————————————————

4d414e41 47455203 c24c4307 77bb0413 01010102 c21fff02 c1152c01 0803c24e

<32 bytes per line>

BBED> d /v

File: /opt/app/oracle/oradata/ORCL2/users01.dbf (4)

Block: 32      Offsets: 7870 to 7901  Dba:0x01000020

——————————————————-

4d414e41 47455203 c24c4307 77bb0413 l MANAGER.?C.w?..

01010102 c21fff02 c1152c01 0803c24e l ….?..?,…?

<16 bytes per line>

现在计算总和，这是用来检查或设置块的校验总和值，并应用变化。

BBED> sum

Check value for File 4, Block 32:

current = 0x26b5, required = 0x32ae

BBED> sum apply

Check value for File 4, Block 32:

current = 0x32ae, required = 0x32ae

到现在为止还挺好。假设数据块中有变化，有两种正确的方式来检查值，但不能使用转储命令。一种是使用SQL * Plus，但是在BBED内，用户可以打印行数据。 SCOTT的行数目仍然是8（或7，认为BBED在0 开始），所以可以使用以下组合：

BBED> p *kdbr[7]

rowdata[235]

————

ub1 rowdata[235]                            @7856     0x2c

BBED> x /rnccntnnn

rowdata[235]                                @7856

————

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

lock@7857: 0x01

cols@7858:    8

col    0[3] @7859: 7788

col    1[5] @7863: SCOTT

col    2[7] @7869: MANAGER

col    3[3] @7877: 7566

col    4[7] @7881: 19-APR-87

col    5[2] @7889: 3000

col    6[0] @7892: *NULL*

col    7[2] @7893: 20

在BBED恢复过程中，客户不会应用redo，而是将文件从过去一个点的状态跳跃到与剩余数据库一致的状态。文件中指定要编辑的部分是文件头。需要三个结构的信息：kcvfhckp，kcvfhcpc和kcvfhccc。其他地方发表的是关于这些项目的解码表，这些一般都容易理解。内核相关的码以k开始，fh看起来像文件头，其余都与检查点相关。具体来说，需要以下选项中好的值：

· kscnbas – last change SCN

· kcvcptim – time of the last change

· kcvfhcpc – checkpoint count

· kcvfhccc – a checkpoint checker value, which is one less than kcvfhcpc

对于文件头，有人对kcvfh结构的输出感兴趣。?p kcvfh?结构的输出很长，但浏览该输出是很有趣的。数据库的名字（这里是指ORCL2）如何拼写出来也很有意思。

BBED> p kcvfh

struct kcvfh, 676 bytes                     @0

struct kcvfhbfh, 20 bytes                @0

ub1 type_kcbh                         @0        0x0b

ub1 frmt_kcbh                         @1        0xa2

ub1 spare1_kcbh                       @2        0x00

ub1 spare2_kcbh                       @3        0x00

ub4 rdba_kcbh                         @4        0x01800001

ub4 bas_kcbh                          @8        0x00000000

ub2 wrp_kcbh                          @12       0x0000

ub1 seq_kcbh                          @14       0x01

ub1 flg_kcbh                          @15       0x04 (KCBHFCKV)

ub2 chkval_kcbh                       @16       0x8f50

ub2 spare3_kcbh                       @18       0x0000

struct kcvfhhdr, 76 bytes                @20

ub4 kccfhswv                          @20       0x00000000

ub4 kccfhcvn                          @24       0x0a200100

ub4 kccfhdbi                          @28       0x266ecc46

text kccfhdbn[0]                      @32      O

text kccfhdbn[1]                      @33      R

text kccfhdbn[2]                      @34      C

text kccfhdbn[3]                      @35      L

text kccfhdbn[4]                      @36      2

这里是个测试案例。新建一个表空间（BB），用户（BB）和表（EMP），其中表有斯科特的EMP表的三行及三列。数据文件是bb01.dbf，创建大小为100K。备份存在于三行所在的位置。当前实例已删除三行，其目的是通过恢复旧数据文件以还原数据。因此，要得到新的文件列表以供参数文件内使用，且bb01.dbf的副本是旧版本。真正需要的只有两个文件–一个具有良好的SCN状态和旧文件，但无论如何都要被列出。

1 /opt/app/oracle/oradata/ORCL2/system01.dbf 513802240

2 /opt/app/oracle/oradata/ORCL2/undotbs01.dbf 36700160

3 /opt/app/oracle/oradata/ORCL2/sysaux01.dbf 272629760

4 /opt/app/oracle/oradata/ORCL2/users01.dbf 5242880

5 /opt/app/oracle/oradata/ORCL2/example01.dbf 104857600

6 /opt/app/oracle/oradata/ORCL2/bb01.dbf 106496

替换该文件，并发出启动命令。用户应该看到有关?bad? 文件的错误。

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area  922746880 bytes

Fixed Size                  1222624 bytes

Variable Size             281020448 bytes

Database Buffers          633339904 bytes

Redo Buffers                7163904 bytes

Database mounted.

ORA-01113: file 6 needs media recovery

ORA-01110: data file 6: ‘/opt/app/oracle/oradata/ORCL2/bb01.dbf’

当前检查点数目不一定需要，但由于它可以直接从数据库中拉出，可以看清它是什么。还可以在BBED文件本身中清楚地显示出来。当前的SCN为689110，坏文件是685758。

SQL> select distinct checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

——————

689110

SQL> select change# from v$recover_file;

CHANGE#

———-

685758

启动一个bbed会话，并打印 kcvfhckp 结构。前几行会显示出来，感兴趣的值是SCN和上一次的值。

BBED> p kcvfhckp

struct kcvfhckp, 36 bytes                   @484

struct kcvcpscn, 8 bytes                 @484

ub4 kscnbas                           @484      0x000a83d6

ub2 kscnwrp                           @488      0x0000

ub4 kcvcptim                             @492      0x2799048e

十六进制值0x000a83d6应转换为689110，基数为10（十进制）。使用互联网上的Windows的科学计算器，或者手动得到十进制值。比较有趣的方式是手动。十六进制值重要的那部分是a83d6。十六进制转换为二进制，每个十六进制字符在二进制中是XXXX。现在有：

二进制1010100001111010110是689110，这很好。现在打印kcvfhcpc和kcvfhccc。该系统的数据文件用于设置dba 1,1。

BBED> p kcvfhcpc

ub4 kcvfhcpc                                @140      0x0000004a

BBED> p kcvfhccc

ub4 kcvfhccc                                @148      0x00000049

另外，这一切的最终并发症是考虑到服务器上运行平台上数据的字节顺序。是大端与小端。该数据库是在PC上运行Oracle Enterprise Linux ，所以成了小端。前两个值的顺序必须颠倒（一对一对地）。总结旧文件中所做的更改，请参照下表。

对十六进制编辑/ X和文件6、块1的dba 使用修改命令。

当四个修改语句完成后，执行 “sum dba x,1 apply? ”，其中?x?是你的文件编号。如果应用更改后，启动时出错，请从下表中检查SCN值输出：

SELECT FILE#, CHANGE# FROM V$RECOVER_FILE; and

SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#

FROM V$LOG V1, V$LOGFILE V2

WHERE V1.GROUP# = V2.GROUP#;

如果恢复的文件SCN与其他文件的完全不同，那么修改命令中十六进制值的字节顺序可能已被颠倒。

SQL> startup

ORACLE instance started.

Total System Global Area  922746880 bytes

Fixed Size                  1222624 bytes

Variable Size             281020448 bytes

Database Buffers          633339904 bytes

Redo Buffers                7163904 bytes

Database mounted.

ORA-01122: database file 6 failed verification check

ORA-01110: data file 6: ‘/opt/app/oracle/oradata/ORCL2/bb01.dbf’

ORA-01207: file is more recent than control file – old control file