[20160904]在記憶體修改資料.txt

[20160904]在記憶體修改資料.txt

--測試一下,是否可以在記憶體crack資料塊的資料.

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 t1 (id number,name varchar2(20));

insert into t1 values (1,'AAAA');

commit ;

--分析表略.

2.測試:

SCOTT@test01p> select rowid,t1.* from t1;

ROWID                      ID NAME

------------------ ---------- --------------------

AAAZuzAAJAAAACOAAA          1 AAAA

SCOTT@book> select rowid,t1.* from t1;

AAAVpqAAEAAAAePAAA          1 AAAA

SCOTT@book> @ &r/rowid AAAVpqAAEAAAAePAAA

    OBJECT       FILE      BLOCK        ROW ROWID_DBA            DBA                  TEXT

---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------

     88682          4       1935          0  0x100078F           4,1935               alter system dump datafile 4 block 1935

SYS@book> @ &r/bh 4 1935

HLADDR              DBARFIL     DBABLK      CLASS CLASS_TYPE         STATE             TCH CR_SCN_BAS CR_SCN_WRP CR_UBA_FIL CR_UBA_BLK CR_UBA_SEQ BA               OBJECT_NAME

---------------- ---------- ---------- ---------- ------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- --------------------

0000000084B95950          4       1935          1 data block         xcur                2          0          0          0          0          0 000000006BAC6000 T1

--STATE=xcur BA=000000006BAC6000

SYS@book> alter system checkpoint ;

System altered.

--//通過bbed觀察:

BBED> set dba 4,1935

        DBA             0x0100078f (16779151 4,1935)

BBED> x /rnc *kdbr[0]

rowdata[0]                                  @8177

----------

flag@8177: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8178: 0x01

cols@8179:    2

col    0[2] @8180: 1

col    1[4] @8183: AAAA

BBED> dump /v

File: /mnt/ramdisk/book/users01.dbf (4)

Block: 1935                              Offsets: 8177 to 8191                            Dba:0x0100078f

-----------------------------------------------------------------------------------------------------------

2c010202 c1020441 41414101 066871                                       l ,......AAAA..hq

<32 bytes per line>

BBED> p kcbh.chkval_kcbh

ub2 chkval_kcbh                             @16       0xd253

--可以發現'AAAA'現在在該塊offset=8183.

--8183 = 0x1ff7,ba=0x000000006BAC6000 ba + 0x1FF7 = 0x000000006BAC6000+0x1FF7+1 = 0x000000006BAC7ff8

3.先通過oradebug确定判斷是否正确.

SYS@book> oradebug setmypid

Statement processed.

SYS@book> oradebug peek 0x000000006BAC7ff8 4

[06BAC7FF8, 06BAC7FFC) = 41414141

SYS@book> oradebug poke 0x000000006BAC7ff8 4 0x41424344

BEFORE: [06BAC7FF8, 06BAC7FFC) = 41414141

AFTER:  [06BAC7FF8, 06BAC7FFC) = 41424344

--依舊修改為'ABCD'.

AAAVpqAAEAAAAePAAA          1 DCBA

--昏！順序是颠倒的，不過已經修改過來了。并且不需要計算檢查和。如果重新整理buffer cache。

SCOTT@book> alter system flush buffer_cache;

--可以發現有改動回來了，因為資料塊的資訊沒有改動。