Comments on: Order of keys inside index blocks

By: Alberto Dell'Era

Alberto Dell'Era — Tue, 01 Sep 2009 08:29:08 +0000

@Kostas

Yes, slot#0 “contains” ‘00000000′, slot#1 “contains” ‘11111111′, and hence a new row with the key value of ‘88888888′ would be “in” slot#8, wherever it gets inserted in the block.

Note that I have placed “contains” in double quotes because actually, each slot contains the address of the index key, not the index key itself. For example, in the example of the post above, slot#0 contains the number 8020 that is the address of first byte of its key ‘00000000′.

The block dump routine simply walks the row directory (an array of 16 bit elements) starting from the first slot and prints both the address and the key value.

Note: of course the index key order is as above because my database charset is AL32UTF8, and hence the binary representation of the pure-ASCII strings I have used is ordered as the language conventions dictate. Index keys are always stored in the block using the binary value.

By: Kostas Hairopoulos

Kostas Hairopoulos — Mon, 31 Aug 2009 16:10:27 +0000

Alberto, thank you for sharing this article with us however can please give some lights in your phrase like ” … that is, the addresses in the row directory are ordered by the (binary) value of the key they point to”.
Its still not clear to me.
As far as I understand from the leaf block dump, the row slot in row directory follows the key order ( ‘0000000′ is in slot 0, ‘11111111′ is in slot 1 etc) and not the. What will be the order of a new row number 8 and value ‘88888888′ in position 7898?

Best Regards,
Kostas Hairopoulos

Thank you in advance,
khair

By: Alberto Dell'Era

Alberto Dell'Era — Wed, 01 Jul 2009 22:00:36 +0000

@Dennis Thank you very much! Your observation makes this post complete ... For better readability, here's your observation "decoded" from hex to decimal, in the same format as above: [text] 1F50=8016 address of '000000' 1F30=7984 address of '111111' 1F10=7952 address of '222222' 1EF0=7920 address of '333333' 1EE0=7904 address of '444444' 1F00=7936 address of '555555' 1F20=7968 address of '666666' 1F40=8000 address of '777777' [/text]

By: Dennis Sun

Dennis Sun — Wed, 01 Jul 2009 20:28:21 +0000

Great job. I tested it on sun sparc server(big-endians). don't need to swap the high and low 2 bytes: [text] 106751080 00000000 1F600000 1F501F30 1F101EF0 [.....`...P.0....] 106751090 1EE01F00 1F201F40 1D391D1D 1D011CE5 [..... .@.9......] row#0[8016] flag: ------, lock: 2, len=16 col 0; len 6; (6): 30 30 30 30 30 30 col 1; len 6; (6): 01 80 05 7f 00 00 row#1[7984] flag: ------, lock: 2, len=16 col 0; len 6; (6): 31 31 31 31 31 31 col 1; len 6; (6): 01 80 05 7f 00 02 row#2[7952] flag: ------, lock: 2, len=16 col 0; len 6; (6): 32 32 32 32 32 32 col 1; len 6; (6): 01 80 05 7f 00 04 row#3[7920] flag: ------, lock: 2, len=16 col 0; len 6; (6): 33 33 33 33 33 33 col 1; len 6; (6): 01 80 05 7f 00 06 row#4[7904] flag: ------, lock: 2, len=16 col 0; len 6; (6): 34 34 34 34 34 34 col 1; len 6; (6): 01 80 05 7f 00 07 row#5[7936] flag: ------, lock: 2, len=16 col 0; len 6; (6): 35 35 35 35 35 35 col 1; len 6; (6): 01 80 05 7f 00 05 row#6[7968] flag: ------, lock: 2, len=16 col 0; len 6; (6): 36 36 36 36 36 36 col 1; len 6; (6): 01 80 05 7f 00 03 row#7[8000] flag: ------, lock: 2, len=16 col 0; len 6; (6): 37 37 37 37 37 37 col 1; len 6; (6): 01 80 05 7f 00 01 [/text]

By: Alberto Dell'Era

Alberto Dell'Era — Thu, 04 Jun 2009 14:45:08 +0000

Sorry for answering late, since I’ve just got back from a internet-less vacation :)

@Cristian

the bytes are ordered in groups of two because in order to address a byte inside the block we need 16 bits (2^16 = 65535, which is enough for all configurable dimensions of the Oracle block).

We need 16+2 bytes because 16 is the length of the entry itself (see len=16 in the block dump) and 2 is the size of the pointer in the row directory that points to the entry.

@zfriese

I will check whether I can find a standard notation to express the logarithm base as well; even if the base is not strictly necessary when performing big-O analysis, I think it adds value in this context.
Thanks for your comment.

By: zfriese

zfriese — Wed, 03 Jun 2009 13:15:11 +0000

Great article! However, your use of asymptotic notation is non-standard, and might be confusing. Consider simplifying to O(log n). Binary searches have logarithmic complexity. Thanks.

By: Cristian

Cristian — Fri, 29 May 2009 15:48:28 +0000

Hi Alberto,
congratulations, i will try to follow your example writing a question in English (correct me if i make some mistakes :) ). I’ve get in trouble with the point in wich you demonstrate that items in row directory are ordered by binary value of the key. Why are the byte grouped by groups of two? Another question is about storage needed by each key, you say that in your example is 16+2 bytes: what are the 4+2 bytes over keys used for?

By: Two Excellent Index Related Blog Posts « Richard Foote’s Oracle Blog

Two Excellent Index Related Blog Posts « Richard Foote’s Oracle Blog — Mon, 25 May 2009 11:15:13 +0000

[...] second is by Alberto Dell’Era who discusses in a post called Order of keys inside index blocks exactly how Oracle orders and stores the index keys within an index block. I’ve exchanged a [...]