[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.
--链接: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.
