[20121116]通过bbed观察行链接与行迁移.txt

[20121116]通过bbed观察行链接与行迁移.txt

    如果应用中出现大量的行链接与行迁移,对应用的性能多少存在影响。一般情况下,行迁移主要是update后,行记录变大,导致原来
的数据块无法容纳,在原来的块保留指针,其他信息放在其他块中。而行链接主要是行记录太大,1个数据块无法容纳,导致使用多块保存。
我想通过bbed简单观察这种情况:

1.建立测试环境:

SQL> select * from v$version where rownum
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

SQL> create table t  ( a number,b varchar2(3000),c varchar2(3000) , d varchar2(3000), e varchar2(3000) ) tablespace test;
Table created.

SQL> create unique index p_t on t(a);
Index created.

SQL> insert into t (a) values (1);
1 row created.

SQL> commit ;
Commit complete.

SQL> select rowid ,t.a from t;
ROWID                       A
------------------ ----------
AAAdD/AAIAAAACOAAA          1

SQL> @ lookup_rowid AAAdD/AAIAAAACOAAA

    OBJECT       FILE      BLOCK        ROW
---------- ---------- ---------- ----------
    119039          8        142          0

SQL> alter system checkpoint;
System altered.


2.使用bbed观察:
BBED> set dba 8,142
        DBA             0x0200008e (33554574 8,142)

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

BBED> x /rn
rowdata[0]                                  @8182
----------
flag@8182: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8183: 0x01
cols@8184:    1

col    0[2] @8185: 1

--可以发现仅仅记录一个值a,其他因为都是NULL,不记录。利用这个特性,在建表时,把经常为NULL的字段放在后面,可以一定程度节约空间。

3.现在修改字段c,看看情况:
SQL> update t set c=lpad('c',3000,'c') where a=1;
1 row updated.

SQL> commit ;
Commit complete.

SQL> alter system checkpoint;
System altered.

--注意要退出bbed再进入,才能看到信息:
BBED> set dba 8,142
        DBA             0x0200008e (33554574 8,142)

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

BBED> x /rncc
rowdata[0]                                  @5172
----------
flag@5172: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@5173: 0x02
cols@5174:    3

col    0[2] @5175: 1
col    1[0] @5178: *NULL*
col 2[3000] @5179: ccccccccccccccccc (太长截断)

-- 可以发现修改c字段后,一个数据块依旧能容纳记录,并没有出现行链接或者迁移的情况。
--另外对比前面看,前面的行记录在偏移8182处,修改后行记录在偏移5175处。
--如果查看8182处信息,可以发现修改前的信息依旧存在。

BBED>  set offset 8182
        OFFSET          8182

BBED> x /rncc
rowdata[3010]                               @8182
-------------
flag@8182: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8183: 0x00
cols@8184:    1

col    0[2] @8185: 1

4.现在修改字段b,d,看看情况:
SQL> update t set b=lpad('b',3000,'b') , d=lpad('d',3000,'d') where a=1;
1 row updated.

SQL> commit ;
Commit complete.

SQL> alter system checkpoint;
System altered.

BBED> p *kdbr[0]
rowdata[0]
----------
ub1 rowdata[0]                              @2157     0x28

BBED> x /rnc
rowdata[0]                                  @2157
----------
flag@2157: 0x28 (KDRHFF, KDRHFH)
lock@2158: 0x01
cols@2159:    2
nrid@2160:0x0200008f.0

col    0[2] @2166: 1
col 1[3000] @2169: bbbbbbbbbbbbbbbbbbbbbbbbbbbbb (太长截断)

--可以发现cols=2记录两个字段,nrid在偏移2160处记录了0x0200008f.0,这个就是字段的其他信息在dba=0x0200008f,小数点后面的0,表示行号。
--另外可以发现前面修改的信息依旧存在。
BBED> set offset 8182
        OFFSET          8182

BBED> x /rnc
rowdata[6025]                               @8182
-------------
flag@8182: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8183: 0x00
cols@8184:    1

col    0[2] @8185: 1

BBED> set offset 5172
        OFFSET          5172

BBED> x /rncc
rowdata[3015]                               @5172
-------------
flag@5172: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@5173: 0x01
cols@5174:    3

col    0[2] @5175: 1
col    1[0] @5178: *NULL*
col 2[3000] @5179: ccccccccccccccccccccc (太长截断)

现在再看看DBA=0x0200008f情况。

BBED> set dba 0x0200008f
        DBA             0x0200008f (33554575 8,143)

BBED> p *kdbr[0]
rowdata[0]
----------
ub1 rowdata[0]                              @2179     0x04

BBED> x /rcc
rowdata[0]                                  @2179
----------
flag@2179: 0x04 (KDRHFL)
lock@2180: 0x01
cols@2181:    2

col 0[3000] @2182: ccccccccc (太长截断)
col 1[3000] @5185: ddddddddd (太长截断)

5.最后在修改e看看情况:

SQL> update t set e=lpad('e',3000,'e')  where a=1;
1 row updated.

SQL> commit ;
Commit complete.

SQL> alter system checkpoint;
System altered.

BBED> set dba 8,142
        DBA             0x0200008e (33554574 8,142)

BBED> p *kdbr[0]
rowdata[0]
----------
ub1 rowdata[0]                              @2157     0x28

BBED> x /rnc
rowdata[0]                                  @2157
----------
flag@2157: 0x28 (KDRHFF, KDRHFH)
lock@2158: 0x02
cols@2159:    2
nrid@2160:0x0200008f.0

col    0[2] @2166: 1
col 1[3000] @2169: bbbbbbbbbbbb (太长截断)

BBED> set dba 0x0200008f
        DBA             0x0200008f (33554575 8,143)

BBED> p *kdbr[0]
rowdata[0]
----------
ub1 rowdata[0]                              @2179     0x00

BBED> x /rccc
rowdata[0]                                  @2179
----------
flag@2179: 0x00 (NONE)
lock@2180: 0x02
cols@2181:    1
nrid@2182:0x0200008b.0

col 0[3000] @2188: ccccccccccccc (太长截断)

--可以dba=8,143存在nrid=0x0200008b.0,字段d,e在另外的块中。

BBED> set dba 0x0200008b
        DBA             0x0200008b (33554571 8,139)

BBED> p *kdbr[0]
rowdata[0]
----------
ub1 rowdata[0]                              @2179     0x04

BBED> x /rcc
rowdata[0]                                  @2179
----------
flag@2179: 0x04 (KDRHFL)
lock@2180: 0x01
cols@2181:    2

col 0[3000] @2182: dddddddddddd (太长截断)
col 1[3000] @5185: eeeeeeeeeeee (太长截断)

--另外大家注意flag标志的变化,这个超出我的能力。

6.看看一些sql语句的执行情况:

SQL> alter system flush BUFFER_CACHE;
System altered.

SQL> alter session set events '10046 trace name context forever, level 12';
Session altered.

SQL> select substr(e,1,10) from t where a=1;

SUBSTR(E,1,10)
--------------------
eeeeeeeeee

SQL> alter session set events '10046 trace name context off';
Session altered.

--查看跟踪文件发现:

PARSING IN CURSOR #8 len=38 dep=0 uid=84 ct=3 lid=84 tim=1353072283364176 hv=1310139427 ad='daec3c10' sqlid='69c8h6j71f913'
select substr(e,1,10) from t where a=1
END OF STMT
PARSE #8:c=2000,e=1548,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=2144302522,tim=1353072283364170
EXEC #8:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2144302522,tim=1353072283364336
WAIT #8: nam='SQL*Net message to client' ela= 4 driver id=1650815232 #bytes=1 p3=0 obj#=0 tim=1353072283364411
WAIT #8: nam='db file sequential read' ela= 33 file#=4 block#=57171 blocks=1 obj#=119040 tim=1353072283364582
WAIT #8: nam='db file sequential read' ela= 24 file#=8 block#=142 blocks=1 obj#=119039 tim=1353072283364721
WAIT #8: nam='db file sequential read' ela= 16 file#=8 block#=143 blocks=1 obj#=119039 tim=1353072283364814
WAIT #8: nam='db file scattered read' ela= 75 file#=8 block#=136 blocks=6 obj#=119039 tim=1353072283365020
FETCH #8:c=1000,e=646,p=9,cr=4,cu=0,mis=0,r=1,dep=0,og=1,plh=2144302522,tim=1353072283365093
STAT #8 id=1 cnt=1 pid=0 pos=1 bj=119039 p='TABLE ACCESS BY INDEX ROWID T (cr=4 pr=9 pw=0 time=0 us cost=0 size=1515 card=1)'
STAT #8 id=2 cnt=1 pid=1 pos=1 bj=119040 p='INDEX UNIQUE SCAN P_T (cr=1 pr=1 pw=0 time=0 us cost=0 size=0 card=1)'
WAIT #8: nam='SQL*Net message from client' ela= 224 driver id=1650815232 #bytes=1 p3=0 obj#=119039 tim=1353072283374046
FETCH #8:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=2144302522,tim=1353072283374090
WAIT #8: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=119039 tim=1353072283374123

--可以发现出现db file sequential read,db file scattered read等待事件。
--file#=4 block#=57171(这个是索引)-》file#=8 block#=142 blocks=1=> file#=8 block#=143 blocks=1=>file#=8 block#=136 blocks=6 .
--不知道为什么最后是db file scattered read,要读6个块。

SQL> select * from dba_extents where wner=user and segment_name='T';

OWNER  SEGMENT_NAME PARTITION_NAME       SEGMENT_TYPE       TABLESPACE_NAME       EXTENT_ID    FILE_ID   BLOCK_ID      BYTES     BLOCKS RELATIVE_FNO
------ ------------ -------------------- ------------------ -------------------- ---------- ---------- ---------- ---------- ---------- ------------
SCOTT  T                                 TABLE              TEST                          0          8        136      65536          8            8



上一篇:17.3. 管理 Hive


下一篇:搭建云平台和DevOps实践环境