[20190910] index leaf block TERM what character representation .txt

[20190910] index leaf block TERM what character representation .txt

- // do index block dump, some of the root, branch node appears TERM, never concerned with characters, explore simple look.

1. Environment:
SCOTT test01p @> @ ver1

PORT_STRING VERSION BANNER CON_ID
------------------------------ ------ ------------------------------------------ -------- ---------- --------------------------------------
IBMPC / 12.2.0.1.0 the Oracle Enterprise Database 12c WIN_NT64-9.1.0 Edition Release 12.2.0.1.0 - 64bit Production 0

SCOTT @ test01p> Create Table T AS SELECT TO_CHAR (rownum, 'the FM' || LPAD ( '0', 20 is , '0')) from Dual Connect V1 by Level <= 2000;
the Table Created.

SCOTT @ test01p> Create index i_t_v1 ON T (V1);
index Created.

SCOTT@test01p> select header_file,header_block from dba_segments where owner=user and segment_name='I_T_V1';
HEADER_FILE HEADER_BLOCK
----------- ------------
         11          506

SCOTT@test01p> @ treedump i_t_v1
old   1: select object_id from user_objects where object_name = upper('&&1') and object_type = 'INDEX'
new   1: select object_id from user_objects where object_name = upper('i_t_v1') and object_type = 'INDEX'
 OBJECT_ID
----------
     27931

old   1: alter session set events 'immediate trace name treedump level &m_index_id'
new   1: alter session set events 'immediate trace name treedump level      27931'
Session altered.         - // dump the contents:

2. Check the dump:

----- begin tree dump
branch: 0x2c001fb 46137851 (0: nrow: 9, level: 1)

*** 2019-09-10T20:55:45.660043+08:00 (TEST01P(3))
   leaf: 0x2c001fc 46137852 (-1: row:224.224 avs:832)
   leaf: 0x2c001fd 46137853 (0: row:224.224 avs:832)
   leaf: 0x2c001fe 46137854 (1: row:224.224 avs:832)
   leaf: 0x2c001ff 46137855 (2: row:224.224 avs:832)
   leaf: 0x2c003e0 46138336 (3: row:224.224 avs:832)
   leaf: 0x2c003e1 46138337 (4: row:224.224 avs:832)
   leaf: 0x2c003e2 46138338 (5: row:224.224 avs:832)
   leaf: 0x2c003e3 46138339 (6: row:224.224 avs:832)
   leaf: 0x2c003e4 46138340 (7: row:208.208 avs:1344)
----- end tree dump

--//0x2c001fb  = set dba 11,507 = alter system dump datafile 11 block 507
--//转储root节点.

SCOTT@test01p> alter system checkpoint ;
System altered.

SCOTT@test01p> alter system dump datafile 11 block 507;
System altered.

--//转储内容:
Block header dump:  0x02c001fb
 Object id on Block? Y
 seg/obj: 0x6d1b  csc:  0x0000000000a2b4d9  itc: 1  flg: E  typ: 2 - INDEX
     brn: 0  bdba: 0x2c001f8 ver: 0x01 opc: 0
     inc: 0  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn  0x0000000000a2b4d9
Branch block dump
=================
header address 629538892=0x2586004c
kdxcolev 1
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 8
kdxcofbo 44=0x2c
kdxcofeo 7852=0x1eac
kdxcoavs 7808
kdxbrlmc 46137852=0x2c001fc
kdxbrsno 0
kdxbrbksz 8060
kdxbr2urrc 0
row#0[8034] dba: 46137853=0x2c001fd
col 0; len 20; (20):  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 32 32 35
--//30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 32 32 35 = 00000000000000000225
col 1; TERM
--//出现TERM.
row#1[8008] dba: 46137854=0x2c001fe
col 0; len 20; (20):  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 34 34 39
col 1; TERM
row # 2 [7982] dba: 46137855 = 0x2c001ff
col 0; 20 only; (20): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 36 37 33
Col. 1; TERM
Row # 3 [7956] dba: 46138336 = 0x2c003e0
col 0; 20 only; (20): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 38 39 37
Col. 1; TERM
Row # 4 [7930] dba: 46138337 = 0x2c003e1
col 0; 20 only; (20): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 31 32 31
Col. 1; TERM
Row # 5 [7904] dba: 46138338 = 0x2c003e2
col 0; 20 only; (20): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 33 34 35
Col. 1; TERM
row # 6 [7878] dba: 46138339 = 0x2c003e3
col 0; 20 only; (20): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 35 36 39
Col. 1; TERM
#. 7 Row [7852] DBA: 46.13834 million = 0x2c003e4
COL 0; 20 is len; (20 is): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 39 33 is 31 is 37 [
COL. 1; the TERM
----- Block of Branch dump ----- End
End dump the Data Blocks TSN: 4 File #: 11 minblk and MaxBlk 507 507

- // dump can be found TERM, represents the end, that is, leaf nodes do not need to be saved complete key, only partially ok.
- // here certainly do not see the contents of the corresponding encoded TERM see preceding dump file as follows:.

The Dump of from 0x0000000025860000 to 0x0000000025862000 Memory
025 860 000 0000A206 02C001FB 00A2B4DD 04.01 million [.............. ..]
025.86001 million 0000AFCD 00000002 00006D1B 00A2B4D9 [......... ...... m]
025.86002 million 00.008 million 00,320,001 02C001F8 0000ffff [2 ......... ......]
025.86003 million 80.008 million 00000000 00000000 00000000 [................]
025.86004 million 00A2B4D9 00000000 00000000 02,800,001 [................]
025860050 00000000 002C0008 1E801EAC 02C001FC  [......,.........]
025860060 00000000 00001F7C 1F481F62 1F141F2E  [....|...b.H.....]
025860070 1EE01EFA 1EAC1EC6 00000000 00000000  [................]
025860080 00000000 00000000 00000000 00000000  [................]
        Repeat 486 times
025861EF0 00000000 00000000 02C003E4 30303014  [.............000]
025861F00 30303030 30303030 30303030 39373130  [0000000000000179]
025861F10 03E3FE33 301402C0 30303030 30303030  [3......000000000]
025861F20 30303030 31303030 FE393635 02C003E2  [00000001569.....]
025861F30 30303014 30303030 30303030 30303030  [.000000000000000]
025861F40 34333130 03E1FE35 301402C0 30303030  [01345......00000]
025861F50 30303030 30303030 31303030 FE313231  [000000000001121.]
025861F60 02C003E0 30303014 30303030 30303030  [.....00000000000]
025861F70 30303030 39383030 01FFFE37 301402C0  [000000897......0]
025861F80 30303030 30303030 30303030 30303030  [0000000000000000]
025861F90 FE333736 02C001FE 30303014 30303030  [673......0000000]
025861FA0 30303030 30303030 34343030 01FDFE39  [0000000000449...]
025861FB0 301402C0 30303030 30303030 30303030  [...0000000000000]
025861FC0 30303030 FE353232 00000000 00000000  [0000225.........]
                   ~~~~~~~~
025861FD0 00000000 00000000 00000000 00000000  [................]
        Repeat 1 times
025861FF0 00000000 00000000 00000000 B4DD0601  [................]

- // Note the underscore can know the contents of the corresponding term code is 0xFE.
- // special course my example, if the above indexing unique index on such a situation will not arise, because it rowid in front of the index key values .

See 3.bbed Observation:
BBED> 11,508 SET DBA
        the DBA 0x02c001fc (46,137,852 11,508)
- // NOTE: bbed block the windows appear to be offset + 1'd.

BBED> P kd_off
B2 kd_off [0] 100 @ 8060
B2 kd_off [. 1] @ 102 0
B2 kd_off [2] @ 104 8034
B2 kd_off [. 3] @ 106 8008
B2 kd_off [. 4] @ 108 7982
B2 kd_off [. 5] @ 110 7956
B2 kd_off [. 6] @ 112 7930
B2 kd_off [. 7 ] 114 @ 7904
- // BBED see indexing structure has some problems, kd_off [0], kd_off [ 1] does not actually shifted from point kd_off [2] start..

BBED> X / RCX * kd_off [2]
rowData [186] @ 8110
------------
DBA Child: 0x02c001fd
Separator Key:
COL 0 [20 is] @ 8115: 00000000000000000225
COL. 1 [0] @ 8136: the TERM * *

BBED> X / RCX kd_off * [. 3]
rowData [160.] @ 8084
------- -----
Child DBA: 0x02c001fe
Separator Key:
COL 0 [20 is] @ 8089: 00000000000000000449
COL. 1 [0] @ 8110: the TERM * *
--- // offset in question here is an offset 8110. start recording, it is estimated bbed the bug.

BBED> dump / v offset 8110
 File: D: \ APP \ ORACLE \ ORADATA \ the TEST \ TEST01P \ USERS01.DBF (11)
 Block: 508 Offsets: 8110 to 8191 Dba: 0x02c001fc
- -------------------------------------------------- -------------------------------------------------- ------
 fd01c002 14303030 30303030 30303030 30303030 30303232 35fe0000 00000000 l ??.00000000000000000225?.....
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
 00000000 00000000 00000000 00000106 ddb4                                l ................荽
 <32 bytes per line>

BBED> x /rcx offset 8110
rowdata[186]                                @8110
------------
child dba:     0x02c001fd
separator key:
col   0[20] @8115: 00000000000000000225
col    1[0] @8136: *TERM*

BBED> dump /v offset 8109 count 2
 File: D:\APP\ORACLE\ORADATA\TEST\TEST01P\USERS01.DBF (11)
 Block: 508 Offsets: 8109 to 8110 Dba: 0x02c001fc
--------------------------------------- -------------------------------------------------- ------------------
 FEFD  L
 <32 bytes per Line>

- // BBED display command to display the x offset col 1 has a problem, in fact, is the length of the column 0. offset 8110 is another record.
- // can be found in the corresponding ASCII code is actually TERM 0xFE. This fine resolution issues I've encountered. Links:
- // HTTP: //blog.itpub.net/267265/viewspace-1291526/=> length problem [20141008] index string .txt

- // index for the length of the string:
- // 1. when the string length 127 or less, using a length of 1 byte.
- @ 2 or greater when a character string 128 used to hold a length of 2 bytes, the contents of the string length + 0x8000..
- // 3 I can not understand why different ways and save the data block, oracle to create two different ways to save string.

- // was very understanding why the oracle to create two different ways to save characters string, now understand.

- // once wrote "varchar2 (4000) How to save" at the following link:
- // HTTP: = //blog.itpub.net/267265/viewspace-2148818/> [20,171,218] VARCHAR2 (4000) how to save .txt

- // If a line can be stored in a data block (data block), then its first line (row header) the required capacity of not less than 3 bytes (byte). After the header information is stored sequentially in the row
- // is the length of the column (column length) and a column value of each column (column value). Long before a column value stored in the column, as the column does not exceed 250 bytes, the byte 1 stored thereon using Oracle
- // length of the column; column values, such as more than 250 bytes, 3 bytes are used to store its column length. Column data (column data) storage space required depends on the data type of this column (datatype). As
- a column data type of a variable-length // if (variable length), then the required space to store the column values may be updated as data grow or shrink.

- // then summarized:
-... 1 // If the column value 250 bytes or less in length, Oracle column using 1-byte length to store its content length field
. - If the column value 2 // length than 250 bytes, 3 bytes are used to store its column length. Use 0xfe front 1 byte (represented by more than 250), followed by two byte length of the column value.

- @ obviously 0xfe string length indicator portion of the data block, used to represent the characters save 250 words section. The index represents the 0xfe TERM use.
- // If this is greater than the length of the string index field 250, a data block can not use a similar way to save key length. Such oraclea must define a new model index string length.
- // bad language expression, or described by way of example:

4 to continue testing:
Create Table T1 (V1 VARCHAR2 (4000));
INSERT INTO T1 values (LPAD ( '. 1', 127, '. 1'));
INSERT INTO T1 values (LPAD ( '2', 128, '2'));
INSERT INTO T1 values (LPAD ( '. 3', 4000, '. 3'));
the commit;
Create index i_t1_v1 ON T1 (V1);
ALTER System the checkpoint;

SCOTT @ test01p> header_file SELECT, WHERE owner = header_block from DBA_SEGMENTS and segment_name = User 'I_T1_V1';
hEADER_FILE hEADER_BLOCK
----------- -----------------------
         . 11 410

- // index root node by bbed 11,411 observation:.

BBED> 11,412 SET DBA
        the DBA 0x02c0019c (46,137,756 11,412)

BBED>p kd_off
b2 kd_off[0]  @132      8036
b2 kd_off[1]  @134      0
b2 kd_off[2]  @136      7899

BBED> x /rcx *kd_off[2]
rowdata[4154]                               @7999
-------------
flag@7999:     0x00 (NONE)
lock@8000:     0x00
data key:
col  0[127] @8002: 11111111...1111111111
col    1[6] @8130:  0x02  0xc0  0x01  0x95  0x00  0x00

BBED> dump /v offset 8001 count 10
 File: D:\APP\ORACLE\ORADATA\TEST\TEST01P\USERS01.DBF (11)
 Block: 412                               Offsets: 8001 to 8010                            Dba:0x02c0019c
-----------------------------------------------------------------------------------------------------------
 7f313131 31313131 3131                                                  l .111111111
<32 bytes per Line>

- // 7F = 127, using a byte string length.

BBED> the dump / 138 V offset COUNT. 4
 File: D: \ the APP \ the ORACLE \ ORADATA \ the TEST \ TEST01P \ USERS01. the DBF (. 11)
 Block: Offsets 412: 138 to 141 is Dba: 0x02c0019c
----------------------------------- -------------------------------------------------- ----------------------
 501ea50e P. L?
<32 bytes per Line>

-. // byte reverse order 0x1e50 = 7760, 0x0ea5 = 3749 relative 7760,3749 offset, see the previous kd_off [2] can be seen that the absolute offset to offset plus 100.

BBED> X / offset 7860 RCX
rowData [4015] @ 7860
------------ -
Flag @ 7860: 0x00 (NONE)
Lock @ 7861: 0x00
data key:
col  0[128] @7864: 22222...22222
col    1[6] @7993:  0x02  0xc0  0x01  0x95  0x00  0x01

BBED> dump /v offset 7862 count 10
 File: D:\APP\ORACLE\ORADATA\TEST\TEST01P\USERS01.DBF (11)
 Block: 412                               Offsets: 7862 to 7871                            Dba:0x02c0019c
-----------------------------------------------------------------------------------------------------------
 80803232 32323232 3232                                                  l ..22222222
<32 bytes per line>
--//出现2次0x80.

BBED> x /rcx offset 3849
rowdata[4]                                  @3849
----------
flag@3849:     0x00 (NONE)
lock@3850:     0x00
Key Data:
COL 0 [4000] @ 3853: 3333 ............
........ 3333333
COL. 1 [. 6] @ 7854: 0xC0 0x02 0x01 0x95 0x00 0x02

BBED> the dump / 3851 V offset COUNT 10
 File: D: \ the APP \ the ORACLE \ ORADATA \ the TEST \ TEST01P \ USERS01.DBF (. 11)
 Block: 412 Offsets: 3851 to 3860 Dba: 0x02c0019c
------------ -------------------------------------------------- ---------------------------------------------
 8fa03333 33,333,333 3333 L. ? 3333333
 <32 bytes per Line>

- // 0x8fa0 -0x8000 = 0xfa0 = 4000.

- // index to the length of the string:
-. @ 1 or less when the length of the string 127, using a word represents the length of the section.
- @ 2 or greater when a character string 128 used to hold a length of 2 bytes, the contents of the string length + 0x8000..

- // oracle not understand why the previously learned data block equal to the string length of less than 250 bytes, Oracle column using 1-byte length to store its content length field.
- // Why boundary definition 250. 0xff used to hold a null value, 0xfe as> 250 encoding a portion of the length indicator is a string (in the index indicates the TERM).
- // according to this principle, oracle also reserved 0xfb, 0xfc, 0xfd, would not know where to use on....

Guess you like

Origin www.cnblogs.com/lfree/p/11503366.html