[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.