[20160606]windows下使用bbed的疑问.txt

[20160606]windows下使用bbed的疑问.txt

--链接:http://blog.itpub.net/267265/viewspace-2109019/
       http://blog.itpub.net/267265/viewspace-2109558/
--我曾经提到要访问的块要+1,比如:
SCOTT@book> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SCOTT@book> create table dept2 tablespace tea as select * from dept ;
Table created.

SCOTT@book> select ora_rowscn,rowid,dept2.* from dept2 ;
  ORA_ROWSCN ROWID                    DEPTNO DNAME          LOC
------------ ------------------ ------------ -------------- -------------
13238134154 AAAW9NAAHAAAACDAAA           10 ACCOUNTING     NEW YORK
13238134154 AAAW9NAAHAAAACDAAB           20 RESEARCH       DALLAS
13238134154 AAAW9NAAHAAAACDAAC           30 SALES          CHICAGO
13238134154 AAAW9NAAHAAAACDAAD           40 OPERATIONS     BOSTON

SCOTT@book> @ &r/rowid AAAW9NAAHAAAACDAAA
      OBJECT         FILE        BLOCK          ROW DBA                  TEXT
------------ ------------ ------------ ------------ -------------------- ----------------------------------------
       94029            7          131            0 7,131                alter system dump datafile 7 block 131 ;

SCOTT@book> alter system checkpoint;
System altered.

SCOTT@book> select * from v$dbfile where file#=7;
       FILE# NAME
------------ ----------------------------------------
           7 /mnt/ramdisk/book/tea01.dbf

2.拷贝数据文件到windows:
BBED> set dba 7,132
        DBA             0x01c00084 (29360260 7,132)

--//注意windwos下使用bbedb lock+1.而在在9i的windows下测试,就不需要+1,不知道为什么?

--而我今天在取出9i(windows)的一个数据文件到另外的机器查看:

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
PL/SQL Release 9.2.0.8.0 - Production
CORE    9.2.0.8.0       Production
TNS for 32-bit Windows: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production

CREATE TABLESPACE INDX DATAFILE
  'D:\ORACLE\ORADATA\ORCL\INDX01.DBF' SIZE 10M AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED
LOGGING
ONLINE
PERMANENT
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO;

SQL> create table deptx tablespace indx as select * from scott.dept ;

SQL> select rowid x,deptx.* from deptx;

X                      DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AAALOOAAGAAAAAMAAA         10 ACCOUNTING     NEW YORK
AAALOOAAGAAAAAMAAB         20 RESEARCH       DALLAS
AAALOOAAGAAAAAMAAC         30 SALES          CHICAGO
AAALOOAAGAAAAAMAAD         40 OPERATIONS     BOSTON

SCOTT@book> @ &r/rowid AAALOOAAGAAAAAMAAA
    OBJECT       FILE      BLOCK        ROW DBA                  TEXT
---------- ---------- ---------- ---------- -------------------- ----------------------------------------
     45966          6         12          0 6,12                 alter system dump datafile 6 block 12 ;

--然后把数据文件拷贝到另外一台机器.
BED> set dba 6,12
       DBA             0x0180000c (25165836 6,12)

BED> map
File: R:\INDX01.DBF (6)
Block: 12                                    Dba:0x0180000c
-----------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes                      @0
struct ktbbh, 96 bytes                     @20
struct kdbh, 14 bytes                      @124
struct kdbt[1], 4 bytes                    @138
sb2 kdbr[4]                                @142
ub1 freespace[7946]                        @150
ub1 rowdata[92]                            @8096
ub4 tailchk                                @8188

BBED> p *kdbr[0]
rowdata[66]
-----------
ub1 rowdata[66]                             @8162     0x2c

BBED> x /rncc
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

--可以发现访问9i的数据文件是正常的,不需要在block上+1.为什么?这样很容易确定问题在块头.

$ od -tx1 -N 8192 tea01.dbf
0000000 00 a2 00 00 00 00 c0 ff 00 00 00 00 00 00 00 00
0000020 66 ff 00 00 00 20 00 00 00 05 00 00 7d 7c 7b 7a
                    ~~~~~
0000040 a0 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0020000

$ od -tx1 -N 8192 INDX01.DBF
0000000 00 00 00 00 00 20 00 00 00 05 00 00 6d 6c 6b 6a
                    ~~~~~
0000020 06 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0020000

--说明:tea01.dbf是11g的数据文件,而INDX01.DBF是9i的数据文件.对比可以发现两者存在很大的不同.不过表示块大小的
--8192 = 0x2000,11g与10g的位置不一样.
--7d 7c 7b 7a 出现的位置与9i的也不一致.

--反过来在linux的bbed打开9i的文件看看:
BBED> set filename '/home/oracle/xxx/INDX01.DBF'
        FILENAME        /home/oracle/xxx/INDX01.DBF

BBED> set block 12
        BLOCK#          12
BBED> x /1rncc rowdata
rowdata[0]                                  @8096
----------
flag@8096: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8097: 0x00
cols@8098:    3

col    0[2] @8099: 40
col   1[10] @8102: OPERATIONS
col    2[6] @8113: BOSTON

--ok正常的.看来是windows9i版本的bbed不能向上兼容,或者讲表示块大小0x2000的位置不对.注意看~
--如果你使用9i的os文件头替换11g的数据文件,就正常了.
--注意:千万不要生产系统做这个动作!!我这里仅仅测试的需要.

R:\>od -tx1 -N 8192 tea01.dbf
od -tx1 -N 8192 tea01.dbf
0000000 00 00 00 00 00 20 00 00 00 05 00 00 6d 6c 6b 6a
0000020 06 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0020000

BBED> set dba 7,131
        DBA             0x01c00083 (29360259 7,131)

BBED> map
 File: R:\tea01.dbf (7)
 Block: 131                                   Dba:0x01c00083
------------------------------------------------------------
 KTB Data Block (Table/Cluster)
 struct kcbh, 20 bytes                      @0
 struct ktbbh, 96 bytes                     @20
 struct kdbh, 14 bytes                      @124
 struct kdbt[1], 4 bytes                    @138
 sb2 kdbr[4]                                @142
 ub1 freespace[7946]                        @150
 ub1 rowdata[92]                            @8096
 ub4 tailchk                                @8188

BBED> x /1rncc rowdata
rowdata[0]                                  @8096
----------
flag@8096: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8097: 0x00
cols@8098:    3

col    0[2] @8099: 40
col   1[10] @8102: OPERATIONS
col    2[6] @8113: BOSTON


--总之问题在于windows下的bbed(目前9i版本),无法识别11g(没有测试10g)的OS头,导致计算块时出现偏移.
--也就是要访问11g的数据块要在原来的基础上+1.