[20160528]bbed观察行目录变化.txt

[20160528]bbed观察行目录变化.txt

如果使用bbed观察kdbr,可以发现记录的是相对偏移量,这个偏移我一直认为从kdbh算起.而对于数据块前面有ITL槽信息,对于有2个ITL的块,
使用assm的表空间,一般我看到都是100.如果一个块上有多个事务,ITL槽会增加,kdbh的地址就会发生变化,这样记录在kdbr的行目录信息
就存在变化,通过例子来说明:

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

create table t (id number,name varchar2(20));
insert into t select rownum ,'aaaa' from dual connect by level<=4;
commit ;

SCOTT@book> select ora_rowscn,rowid,t.* from t;
  ORA_ROWSCN ROWID                        ID NAME
------------ ------------------ ------------ --------------------
13237974561 AAAW8VAAEAAAAIkAAA            1 aaaa
13237974561 AAAW8VAAEAAAAIkAAB            2 aaaa
13237974561 AAAW8VAAEAAAAIkAAC            3 aaaa
13237974561 AAAW8VAAEAAAAIkAAD            4 aaaa

SCOTT@book> @ &r/rowid AAAW8VAAEAAAAIkAAA
      OBJECT         FILE        BLOCK          ROW DBA                  TEXT
------------ ------------ ------------ ------------ -------------------- ----------------------------------------
       93973            4          548            0 4,548                alter system dump datafile 4 block 548 ;

SCOTT@book> alter system checkpoint;
System altered.

2.通过bbed观察:
BBED> set dba 4,548
        DBA             0x01000224 (16777764 4,548)

BBED> p kdbr
sb2 kdbr[0]                                 @118      8044
sb2 kdbr[1]                                 @120      8055
sb2 kdbr[2]                                 @122      8066
sb2 kdbr[3]                                 @124      8077

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

BBED> x /rnc
rowdata[0]                                  @8144
----------
flag@8144: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8145: 0x01
cols@8146:    2

col    0[2] @8147: 1
col    1[4] @8150: aaaa

--注意看看kdbr[0]与实际的偏移相差100.
BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 548                                   Dba:0x01000224
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes                      @0
struct ktbbh, 72 bytes                     @20
struct kdbh, 14 bytes                      @100
struct kdbt[1], 4 bytes                    @114
sb2 kdbr[4]                                @118
ub1 freespace[8018]                        @126
ub1 rowdata[44]                            @8144
ub4 tailchk                                @8188

--注意看kdbh的偏移是100.如果一个块有多个事务,itl槽会增加.看看情况.

--session 1:注意不要提交.我的update前后字段长度没有变化,也就是原地替换.
update t set name='1111' where id=1;

--session 2:
update t set name='2222' where id=2;

--session 3:
update t set name='3333' where id=3;

SCOTT@book> alter system checkpoint;
System altered.

3.再次观察数据块(注意bbed要退出在进入):
BBED> set dba 4,548
        DBA             0x01000224 (16777764 4,548)

BBED> p kdbr
sb2 kdbr[0]                                 @142      8020
sb2 kdbr[1]                                 @144      8031
sb2 kdbr[2]                                 @146      8042
sb2 kdbr[3]                                 @148      8053

--如果与前面对比可以发现记录的偏移量减少了24.正好是ITL槽的长度.不知道oracle为什么这样设计,如果记录的是绝对偏移量,不是减
--少许多计算吗?

BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 548                                   Dba:0x01000224
------------------------------------------------------------
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[7994]                        @150
ub1 rowdata[44]                            @8144
ub4 tailchk                                @8188

--可以发现kdbh现在的偏移是124,因为增加一个ITL槽.

BBED> p ktbbh
struct ktbbh, 96 bytes                      @20
   ub1 ktbbhtyp                             @20       0x01 (KDDBTDATA)
   union ktbbhsid, 4 bytes                  @24
      ub4 ktbbhsg1                          @24       0x00016f15
      ub4 ktbbhod1                          @24       0x00016f15
   struct ktbbhcsc, 8 bytes                 @28
      ub4 kscnbas                           @28       0x150b76aa
      ub2 kscnwrp                           @32       0x0003
   sb2 ktbbhict                             @36       3
   ub1 ktbbhflg                             @38       0x32 (NONE)
   ub1 ktbbhfsl                             @39       0x00
   ub4 ktbbhfnx                             @40       0x01000220
   struct ktbbhitl[0], 24 bytes             @44
      struct ktbitxid, 8 bytes              @44
         ub2 kxidusn                        @44       0x0009
         ub2 kxidslt                        @46       0x0014
         ub4 kxidsqn                        @48       0x0000327d
      struct ktbituba, 8 bytes              @52
         ub4 kubadba                        @52       0x00c00305
         ub2 kubaseq                        @56       0x06a9
         ub1 kubarec                        @58       0x10
      ub2 ktbitflg                          @60       0x0001 (NONE)
      union _ktbitun, 2 bytes               @62
         sb2 _ktbitfsc                      @62       0
         ub2 _ktbitwrp                      @62       0x0000
      ub4 ktbitbas                          @64       0x00000000
   struct ktbbhitl[1], 24 bytes             @68
      struct ktbitxid, 8 bytes              @68
         ub2 kxidusn                        @68       0x000a
         ub2 kxidslt                        @70       0x001b
         ub4 kxidsqn                        @72       0x00009dc4
      struct ktbituba, 8 bytes              @76
         ub4 kubadba                        @76       0x00c00e44
         ub2 kubaseq                        @80       0x1e7f
         ub1 kubarec                        @82       0x0c
      ub2 ktbitflg                          @84       0x0001 (NONE)
      union _ktbitun, 2 bytes               @86
         sb2 _ktbitfsc                      @86       0
         ub2 _ktbitwrp                      @86       0x0000
      ub4 ktbitbas                          @88       0x00000000
   struct ktbbhitl[2], 24 bytes             @92
      struct ktbitxid, 8 bytes              @92
         ub2 kxidusn                        @92       0x0008
         ub2 kxidslt                        @94       0x001b
         ub4 kxidsqn                        @96       0x0000236b
      struct ktbituba, 8 bytes              @100
         ub4 kubadba                        @100      0x00c000ca
         ub2 kubaseq                        @104      0x0761
         ub1 kubarec                        @106      0x02
      ub2 ktbitflg                          @108      0x0001 (NONE)
      union _ktbitun, 2 bytes               @110
         sb2 _ktbitfsc                      @110      0
         ub2 _ktbitwrp                      @110      0x0000
      ub4 ktbitbas                          @112      0x00000000

--现在是3个ITL槽.

BBED> p kdbh
struct kdbh, 14 bytes                       @124
   ub1 kdbhflag                             @124      0x00 (NONE)
   sb1 kdbhntab                             @125      1
   sb2 kdbhnrow                             @126      4
   sb2 kdbhfrre                             @128     -1
   sb2 kdbhfsbo                             @130      26
   sb2 kdbhfseo                             @132      8020
   sb2 kdbhavsp                             @134      7994
   sb2 kdbhtosp                             @136      7994

--在补充前面的学习,人为修改kdbhavsp=7993.

BBED> assign kdbhavsp=7993
sb2 kdbhavsp                                @134      7993

BBED> sum apply
Check value for File 4, Block 548:
current = 0xf388, required = 0xf388

BBED> verify
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 548

Block Checking: DBA = 16777764, Block Type = KTB-managed data block
data header at 0x7f3b9b8af27c
kdbchk: the amount of space used is not equal to block size
        used=70 fsc=0 avsp=7993 dtl=8064
Block 548 failed with check code 6110

--可以对比我以前的测试dtl不再是8088,而是8064,减少了24字节.
-- [20160527]快速提交的一个疑问.txt  http://blog.itpub.net/267265/viewspace-2108017/

-- // dtl - used +fsc
-- // 8064-70+0=7994

-- used 可以这样计算
SCOTT@book> select 8064-8020+14+4+8 from dual ;
8064-8020+14+4+8
----------------
              70

BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 548                                   Dba:0x01000224
------------------------------------------------------------
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[7994]                        @150
ub1 rowdata[44]                            @8144
ub4 tailchk                                @8188

-- 说明: kdbh 占用14 ,kdbt[1] 占用4 , kdbr[4 占用8个字节.

时间: 2024-10-23 08:45:07

[20160528]bbed观察行目录变化.txt的相关文章

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

[20121116]通过bbed观察行链接与行迁移.txt     如果应用中出现大量的行链接与行迁移,对应用的性能多少存在影响.一般情况下,行迁移主要是update后,行记录变大,导致原来的数据块无法容纳,在原来的块保留指针,其他信息放在其他块中.而行链接主要是行记录太大,1个数据块无法容纳,导致使用多块保存.我想通过bbed简单观察这种情况: 1.建立测试环境: SQL> select * from v$version where rownum BANNER ----------------

[20170411]bbed删除记录的恢复.txt

[20170411]bbed删除记录的恢复.txt --//昨天上午做的测试,链接:http://blog.itpub.net/267265/viewspace-2136933/ --//我当时并没有选择恢复记录,仅仅看删除的内容.因为这样恢复是存在许多问题. --//执行 drop function scott.sleep ; 删除sys.source$相关记录仅仅是该命令的一小部分,恢复 --//sys.source$相关记录会存在许多问题,但是如果是应用数据恢复还是可以,实际上以前我的博客

[20170412]bbed恢复修改记录(不等长).txt

[20170412]bbed恢复修改记录(不等长).txt --//昨天做了删除记录恢复测试,今天测试update记录如何还原通过bbed. --//实际上类似的测试我自己做了好几次,都是按照别人的帖子依葫芦画瓢,没有很好理解一些内在的东西. http://blog.itpub.net/267265/viewspace-2137000/ http://blog.itpub.net/267265/viewspace-2107060/ http://blog.itpub.net/267265/vie

从370行目录看网络服务

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 随着时代的变迁,各行各业异军突起.在很多大行业内,衍生出许多新的行业,成为一个细分的新行业.而且,这些新生行业可能成为一个主导行业. 但是,我们看到,这些新生的行业并没有被认可,仍然将他们归纳在大行业内.尤其是在网络上,一些新生行业没有得到重视,依然被划分在一些大行业内.因为,许多网站建立的时候,这些行业还没有兴起,或者还没有足够的理由成为一

[20150522]bbed与数据块检查和.txt

[20150522]bbed与数据块检查和.txt --我现在基本拿bbed学习,基本是拿bbed查看,而使用bvi修改数据.我感觉这种方便1写. --实际上使用bbed的好处就是修改数据块检查和不一致,而使用bbed修改很简单仅仅需要执行sum apply就ok了. --对比dbv与bbed确定检查和位置. 1.建立测试环境: SCOTT@test> @ &r/ver1 PORT_STRING                    VERSION        BANNER -------

[20150529]使用bbed解决丢失的归档.txt

[20150529]使用bbed解决丢失的归档.txt -- 以前跟别人探讨过这个问题,我个人的观点通过bbed等手段来跳过丢失的归档来恢复存在许多问题. -- 我以前个人的主张是通过别的手段抽取数据文件的数据,结合logminer来重新整合数据.但是如果抽取的logminer很多,会非常麻烦. --实际上无论那种方式,都存在许多问题,这里通过例子来说明bbed如何解决跳过丢失的归档. 1.测试环境建立: SCOTT@test> @ &r/ver1 PORT_STRING          

[20150527]bbed解决数据文件大小问题.txt

[20150527]bbed解决数据文件大小问题.txt --模拟一个数据文件大小不一致的问题. 1.建立测试环境: SCOTT@test> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ---------------------------------------------------------------- x86

Linux下用Python脚本监控目录变化代码分享

  这篇文章主要介绍了Linux下用Python脚本监控目录变化代码分享,本文直接给出实现代码,需要的朋友可以参考下 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 #!/usr/bin/env python #coding=utf-8   import os from pyinotify import WatchManager, Notifier, ProcessEven

git-Git命令行目录能不能修改

问题描述 Git命令行目录能不能修改 能不能把目录 修改到D盘工作目录下 而不是在C盘 解决方案 可以直接在你需要使用git的文件夹里面右击打开一个git bash ,此时就是在你这个文件夹下打开了一个git 或者可以直接使用cd命令切换啊 不知道是不是你想要的 解决方案二: 还想弱弱的问一句 cd的话怎么切换 解决方案三: 你先cd到对应的目录,然后再执行git命令