Index leaf blocks???

Can anybody explain me the details of index leaf blocks?
What are the possible usage of those?

Hi DKar,
index leaf block is the smallest unit of a btree index, they are used to store the rowid of the indexed rows.
Their usage is transparent to you.
I suggest to take a look here:
http://download-uk.oracle.com/docs/cd/B14117_01/server.101/b10743/schema.htm#sthref883
search for: The Internal Structure of Indexes
Regards
Acr

Similar Messages

Index Range Scan / Deleted Leaf Blocks

Hello guys,
i have such a scenario on a big index / table which i can not reproduce on my test database, so i need to know how oracle handles the index range scan.
For example:
TABLE TAB with the following columns NR (number), I_DATE (date), TEXT (VARCHAR2(50))
INDEX I_TAB on the column I_DATE.
Now the index has blevel 2 and many leaf blocks. And now my question.
Query: SQL> SELECT * from TAB WHERE I_DATE < 10.10.2004
The index had stored some values which are a less than 2003 but these ones are already deleted (so the leaf blocks are gone to the freelist), but it was not reorganized.
The execution plan is a INDEX RANGE SCAN on the INDEX I_TAB. Does the branch block still have pointers to the deleted leaf blocks which contained only 2003 values before (and so the INDEX RANGE SCAN scans all these blocks too) or are the pointers to these leaf blocks deleted in the branch block?
Thanks and Regards
Stefan

You can verify it by yourself. See following:
SELECT count(*) FROM index_test;
==> 1569408
SELECT count(*) FROM index_test WHERE id <= 2;
==> 12
-- Delete all except first 12 rows
DELETE FROM index_test WHERE id > 2;
-- Query and SQL Trace
BEGIN
FOR C IN (SELECT /*+index(index_test index_test_idx) deleted */ * FROM INDEX_TEST WHERE ID < 1000000) LOOP
NULL;
END LOOP;
END;
SELECT /*+index(index_test index_test_idx) deleted */ *
FROM
INDEX_TEST WHERE ID < 1000000
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3490 0 12
total 3 0.00 0.01 0 3490 0 12
==> 3490 logical reads only for 12 rows and range scan??
-- Index tree dump
ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME TREEDUMP LEVEL 67513'
----- begin tree dump
branch: 0x1000124 16777508 (0: nrow: 6, level: 2)
branch: 0x100b1ca 16822730 (-1: nrow: 557, level: 1)
leaf: 0x1000125 16777509 (-1: nrow: 512 rrow: 12)
leaf: 0x1000126 16777510 (0: nrow: 484 rrow: 0)
leaf: 0x1000127 16777511 (1: nrow: 479 rrow: 0)
leaf: 0x1000128 16777512 (2: nrow: 479 rrow: 0)
leaf: 0x1000139 16777529 (3: nrow: 479 rrow: 0)
leaf: 0x100013a 16777530 (4: nrow: 478 rrow: 0)
branch: 0x100b401 16823297 (0: nrow: 558, level: 1)
leaf: 0x100b1c9 16822729 (-1: nrow: 449 rrow: 0)
leaf: 0x100b1cb 16822731 (0: nrow: 449 rrow: 0)
leaf: 0x100b1cc 16822732 (1: nrow: 449 rrow: 0)
==> leaf:3488, branch: 7
This means that almost all the branch and leaf nodes are read only for 12 keys.
You can cross check this with the result of "10200" event which traces cr reads. You would find out that the blocks that are read by the query are exactly same as all the index blocks.
This is what you mean? that the deleted leaf blocks(which contain no actual data) are read by range scan? Through the simple test, the anwer is "yes".

Index / Root Block - Branch Nodes - Leaf Nodes

Hello guys,
i readed many documentations about indeces and performance issues. In many cases i could optimize my queries.
But one thing, i didn't find while i was searching for documents.
What value/fact specifies the following:
1) How much branch nodes can a root block contain/handle?
2) How much leaf nodes can a branch node contain/handle?
3) How much values can a leaf node contain/handle?
It there any rule that specifies at which point the branch block / leaf block should be splitted?
Maybe you can give me a link to a documentation about that topic or explain by yourself....
Thanks :-)
Regards
Stefan

All of these will be a function of:
1.) block_size
2.) PCTFREE specified at index creation time.
3.) Size of the key values being indexed.
An index on a very small table will start out as one block. The root block will itself be a leaf block. When it fills, Oracle will split it, and you'll end up with a root block pointing to two different leaf blocks. When one of those leaf blocks fills, Oracle will split again, and you'll end up with one root block pointing to three leaf blocks. After some time, and a lot of data, you'll end up splitting so many times that the root block will be filled with pointers to leaf blocks. At this point, when a leaf block splits, there will be no room to add a pointer to the new leaf block in the root block. So, Oracle will recursively execute another split, this time on the root block, and this is when the BLEVEL of the index will grow. So, Oracle will always split a block on demand, when there is no space left in the block.
Also, a block split can happen if there is not an open ITL slot available on the block, but I won't go into those details now.
Hope that helps,
-Mark

Interpreting an index data block dump

I have seen a few postings about reading index data blocks, mine doesnt quite look like those.
Ok: 11Gr1 (linux)
Tracing down a hot block issue with an index, I performed
alter system dump datafile 11 block 4030208;
Looking at the Web page "Index Block Dump: Index Only Section Part II (Station To Station)" and others they show a dump like this:
row#0[8021] flag: ——, lock: 0, len=15
col 0; len 5; (5): 42 4f 57 49 45
col 1; len 6; (6): 02 01 48 8a 00 00
row#1[8002] flag: ——, lock: 0, len=19
col 0; len 9; (9): 4d 41 4a 4f 52 20 54 4f 4d
col 1; len 6; (6): 02 01 48 8a 00 02
row#2[7987] flag: ——, lock: 0, len=15
col 0; len 5; (5): 5a 49 47 47 59
col 1; len 6; (6): 02 01 48 8a 00 01
—– end of leaf block dump —–
End dump data blocks tsn: 8 file#: 8 minblk 84234 maxblk 84234
I dont see anything that "obvious" in my dump. Am I looking at something other then an leaf block perhaps?
I am expecting/hoping to see some sort of pairs for an index like X(y number, z number)
Block dump from cache:
Dump of buffer cache at level 4 for tsn=6, rdba=50167552
BH (0x275f2aec8) file#: 11 rdba: 0x02fd7f00 (11/4030208) class: 4 ba: 0x274992000
set: 111 bsz: 8192 bsi: 0 sflg: 0 pwc: 0, 25 lid: 0x00000000,0x00000000
dbwrid: 2 obj: 127499 objn: 77784 tsn: 6 afn: 11
hash: [0x403d34650,0x403d34650] lru: [0x333f32878,0x209f4ea88]
lru-flags: hot_buffer
ckptq: [NULL] fileq: [NULL] objq: [0x22dede3f8,0x30ff9c3f8]
st: XCURRENT md: NULL tch: 2
flags: block_written_once redo_since_read gotten_in_current_mode
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [34]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 6 rdba: 0x02fd7f00 (11/4030208)
scn: 0x0001.19bccf84 seq: 0x02 flg: 0x04 tail: 0xcf841002
frmt: 0x02 chkval: 0x987f type: 0x10=DATA SEGMENT HEADER - UNLIMITED
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x0000000274992000 to 0x0000000274994000
274992000 0000A210 02FD7F00 19BCCF84 04020001 [................]
274993FF0 00000000 00000000 00000000 CF841002 [................]
Extent Control Header
Extent Header:: spare1: 0      spare2: 0      #extents: 66     #blocks: 10239
                  last map 0x00000000 #maps: 0      offset: 4128
      Highwater:: 0x047feb5b ext#: 65     blk#: 731    ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 9946
mapblk 0x00000000 offset: 65
                   Unlocked
     Map Header:: next 0x00000000 #extents: 66   obj#: 127499 flag: 0x40000000
Extent Map
   0x02fd7f01 length: 127
   0x0339ea80 length: 128
...

Some time ago, I wrote a python script to print decimal form integer values from an index block dump. I don't know if it will help you, but it may be a start. It only prints the integer equivalent of the first column in the index, as that is what I needed at the time.
It is called as...
18:55:31 oracle@oh1xcwcdb01 /u02/admin/wcperf/udump >./blockdump.py wcperf1_ora_21618.trc
col 0: [ 4] c4 48 2a 53 converts to 71418200 on line #526 in the block dump.
col 0: [ 5] c4 48 2a 53 1d converts to 71418228 on line #640 in the block dump.
col 0: [ 6] c5 08 02 20 61 3f converts to 701319662 on line #648 in the block dump.
col 0: [ 6] c5 08 03 2f 33 17 converts to 702465022 on line #785 in the block dump.
col 0: [ 6] c5 08 03 2f 33 5f converts to 702465094 on line #793 in the block dump.
col 0: [ 6] c5 08 03 2f 40 38 converts to 702466355 on line #801 in the block dump.
col 0: [ 6] c5 08 03 30 09 5c converts to 702470891 on line #809 in the block dump.
col 0: [ 6] c5 08 03 32 61 05 converts to 702499604 on line #817 in the block dump.
col 0: [ 6] c5 08 03 33 0b 06 converts to 702501005 on line #827 in the block dump.
col 0: [ 6] c5 08 03 33 19 4b converts to 702502474 on line #835 in the block dump.
col 0: [ 6] c5 08 03 33 44 3d converts to 702506760 on line #843 in the block dump.
col 0: [ 6] c5 08 03 33 45 08 converts to 702506807 on line #851 in the block dump.
col 0: [ 6] c5 08 03 33 4e 5a converts to 702507789 on line #859 in the block dump.
col 0: [ 6] c5 08 03 33 5f 3b converts to 702509458 on line #867 in the block dump.
col 0: [ 6] c5 09 01 01 21 64 converts to 800003299 on line #875 in the block dump.
col 0: [ 6] c5 09 01 01 22 3b converts to 800003358 on line #883 in the block dump.
18:55:41 oracle@oh1xcwcdb01 /u02/admin/wcperf/udump >...and the script itself is below...
#!/usr/bin/python
#Author:        Steve Howard
#Date:          March 23, 2009
#Organization: AppCrawler
#Purpose:       Simple script to print integer equivalents of block dump values in index.
import fileinput
import string
import sys
import re
#boo=1
boo=0
j=0
for line in fileinput.input([sys.argv[1:][0]]):
j=j+1
if re.match('^col 0:', line):
    #print line
    dep=int(string.replace(string.split(string.split(line,"]")[1])[0],"c","")) - 1
    #print dep
    i=0
    tot=0
    exp=dep
    for col in string.split(string.split(line,"]")[1]):
      if i > 0:
        tot = tot + ((int(col, 16) - 1) * (100**exp))
        exp = exp - 1
      i = i + 1
    print line.rstrip("\n") + " converts to " + str(tot) + " on line #" + str(j) + " in the block dump."

Leaf blocks,blevel,clustering factor

Hi,
I am trying to understand what is the meaning of
leaf_blocks,clustering_factor,blevel
Regards
MMU

For a non-technical but still pretty useful explanation of the CLUSTERING_FACTOR (and how not to use it!), see: http://www.dizwell.com/prod/node/22
Leaf blocks are the index equivalent of table blocks: blocks of disk space in which your index entries are actually stored. Indexes also have branch blocks and a root block which act as 'signposts' to the leaf nodes: "If you're looking for the entries beginning with E, those are in that leaf block over there. Entries beginning with F start in that other leaf block there, though".
Depending on how many 'signposts' you have to read before you get to the actual leaf block entry you're interested in, the index can have a smaller or bigger "blevel". Sometimes, we talk about the index having a "height": if you have to visit a root node, which points you off to one of the branch nodes, which then points you to the leaf entry you want, that's a height of 3. It also happens to be a blevel of 2. The difference is probably not worth worrying about for now. Suffice it to say: an index with a blevel of (say) 2 is going to be a lot quicker and more efficient to use than one with a blevel of (say) 5.
The optimiser uses those statistics to decide whether or not it's worth its while using the index to satisfy a query or not.

Leaf Block Dump / Output varies

Hello guys,
i have faced the following issues on a leaf block dump:
First)
row#0[8024] flag: ------, lock: 0, len=12, data:(6): 00 40 76 fa 00 00
col 0; len 2; (2): c1 02
col 1; NULL
row#1[7998] flag: ------, lock: 0, len=14, data:(6): 00 40 76 fa 00 02
col 0; len 2; (2): c1 03
col 1; len 2; (2): c1 02
.......Second)
1103F5A90 3D91D858 000C0100 03303130 0944454C [=..X.....010.DEL]
1103F5AA0 494E535F 494E0832 30303730 36303106 [0505.20070601.]
1103F5AB0 30303535 3331063D 91D85800 0D010003 [005531.=..X.....]
1103F5AC0 30313009 44454C49 4E535F49 4E083230 [010.DAT050_IN.20]
1103F5AD0 30373036 30310630 30353533 34063D91 [070601.005534.=.]
1103F5AE0 D858000E 01000330 31300944 454C494E [.X.....010.DAT03]
1103F5AF0 535F494E 08323030 37303630 31063030 [S_IN.20070601.00]
1103F5B00 35353334 063D91D8 58000F01 00033031 [5534.=..X.....01]
1103F5B10 30094445 4C494E53 5F494E08 32303037 [0.DAT050_IN.2007]Sometimes i am facing the row#n output like in the first example and sometimes i am facing only the "real data" like in the second example when i am doing a leaf block dump. Both examples are from different indeces...
When does one occur? Has anyone any idea?
Regards
Stefan

Hi,
File is truncated by trace file limit. Yeah but the file is not big enough.. i only dumped one block.. and the limit is up to 10MB
But as far as I'm aware, a memory dump is normally not included in block dump. Did you check what's at the top? Really interesting... i have done the same on our test system on the same index.. and there the section leaf block dump includes the information. The same command on the same index (i have cloned the database 3 days ago to our test system).
Leaf block dump
===============
row#0[3514] flag: ---D--, lock: 2, len=39
col 0; len 3; (3): 30 31 30
col 1; len 9; (9): 44 45 4c 49 4e 53 5f 49 4e
col 2; len 8; (8): 32 30 30 37 30 36 30 31
col 3; len 6; (6): 30 30 35 35 31 39
col 4; len 6; (6): 3d 91 d7 d8 00 13
----- end of leaf block dump -----Can this leaf block cleaned out (by deletes) and not include any pointers anymore?
I have compared the leaf block attributes:
-> kdxcoavs 3298 (with row#n entries)
-> kdxcoavs 6988 (without row#n entries)
So the dump were are no row#n entries has much more available space - this would be confirm my guess.
Regards
Stefan

Index block dump: "header address" doesn't match rdba

I did a dump on index leaf block, and I found "header address" doesn't match rdba, what's the "header address"? I also found several leaf blocks have the same "header address".
buffer tsn: 11 rdba: 0x1684d120 (90/315680)
========> 0x1684d120 (1)
header address 4403265988=0x1067481c4
========> 0x1067481c4 (2)
*** SERVICE NAME:(SYS$USERS) 2009-08-04 04:37:36.335
*** SESSION ID:(14234.24426) 2009-08-04 04:37:36.335
Start dump data blocks tsn: 11 file#: 90 minblk 315680 maxblk 315680
buffer tsn: 11 rdba: 0x1684d120 (90/315680)
========> 0x1684d120 (1)
scn: 0x0324.dda9ec3d seq: 0x01 flg: 0x04 tail: 0xec3d0601
frmt: 0x02 chkval: 0xeb2a type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Block header dump: 0x1684d120
Object id on Block? Y
seg/obj: 0x7ca10 csc: 0x324.dda9ec3d itc: 17 flg: O typ: 2 - INDEX
     fsl: 0 fnx: 0x1684cf72 ver: 0x01
Itl           Xid                  Uba         Flag Lck        Scn/Fsc
Leaf block dump
===============
header address 4403265988=0x1067481c4
========> 0x1067481c4 (2)
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: opcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 5
kdxconro 0
kdxcofbo 36=0x24
kdxcofeo 7672=0x1df8
kdxcoavs 7636
kdxlespl 0
kdxlende 0
kdxlenxt 373579108=0x16445d64
kdxleprv 377801347=0x1684ca83
kdxledsz 0
kdxlebksz 7672
----- end of leaf block dump -----Thanks,
Daniel

Hi user646745
You didn't say why you need to do index block dump ?
Also take are that block structures and dumps some time are different from a ver to ver it 9i and 10g. Unless you now what exectaly you are looking for
Thanks

How much time it take to rebuild an index for a table with 20 millions rows

Hi all,
i need to rebuild the index of a table containing 20 000 000 row (i don't know why the other people working on this didn't think of rebuilding the index regularly, because i asked and apparently it has never been done :cry: :cry:) i am not a sql developper nor a DBA so i can't mesure how long it take to rebuild the index, does any one have an idea (aproximativly of course :aie:), the other question is there any formula to use in order to calculate how often to rebuild the indexes (i can for example retieve how much rows are delated or inserted daily ...)
Thanks again
Taha

taha wrote:
:aie: that's why i am asking because i don't know (and to be sure which solution is best)
so the table is like this (the columns) :
45 varchar2, 5 timestamp, 30 Number no LOB columns, (15 indexes : 5 unique indexes and that those indexes uses at a maximum 4 columns)15 indexes - 100,000 deletes: this could mean 1,500,000 block visits to maintain index leaf blocks as the table rows are deleted. If you're unlucky this could turn into 1,500,000 physical block read requests; if you're lucky, or the system is well engineered this could be virtually no physical I/O. The difference in time could be huge. At any rate it is likely to be 1,500,000 redo entries at 250 - 300 bytes per entry for a total of about 400MB of redo (so how large are your redo logs and how many log switches are you going to cause).
yes the tables is used by an application so (update, insert ) can take place at any time
for the deletion , there is the batch which does a mass delete on the table ( 4 or 5 time each day)
You haven't answered the question - how long does it take to do a sample batch delete.
If you can enable SQL tracing, or take a before/after snapshot of v$sesstat or v$session_event for the session as it does the delete then you can get some idea of where the time is going - for all you know it might be spending most of its time waiting for a lock to do away.
>
"How many leaf blocks are currently allocated to the index(es) ?" how can i answer to this question ? may be if i check the all_objects table ?
If you keep your statistics up to date then dba_indexes is a good place, cross-checked with dba_segments, and you can use the dbms_space package for more detail. I have a code sample on my blog which allows you to compare the current size of your indexes with the size they would be if rebuilt at some specific percentage: http://jonathanlewis.wordpress.com/index-sizing/ (It's such good code that Oracle Corp. has copied it into MOS note 989186.1)
Regards
Jonathan Lewis

Oracle Table Indexes

Hello.
I'm in the process of putting some indexes on tables for performance improvement of queries run.
eg the foll query -
SELECT MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, BPT_BP_SHRT_NM, MPH_SEC_ID, SEC_SEC_NM, NMS_SEC_NUM, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER, BPT_BSNS_PRTNR_VER, SEC_SEC_MASTER_VER FROM MPH_MKT_PRICE_HSTRY left outer join NMS_NUM_SCHEME on NMS_SEC_ID=MPH_SEC_ID AND NMS_NUM_SCHM='CUSIP',BPT_BSNS_PRTNR,SEC_SEC_MASTER WHERE MPH_ENTITY_ID=BPT_ENTITY_ID AND MPH_STCK_EXCHNG_ID=BPT_BP_ID AND MPH_SEC_ID=SEC_SEC_ID ORDER BY MPH_SEC_ID DESC
The Explain plan in PL/SQL developer shows "Table Access Full" scan for 2 tables - BPT_BSNS_PRTNR AND MPH_MKT_PRICE_HSTRY.
I created the foll 2 indexes and now the explain plan shows "index fast full" scan on these tables -
1) create index mph_3 on mph_mkt_price_hstry(MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, MPH_SEC_ID, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER);
2) create index BPT_8 on bpt_bsns_prtnr(BPT_BP_SHRT_NM,BPT_BSNS_PRTNR_VER,BPT_ENTITY_ID,BPT_BP_ID);
My question here is that I have included columns in the select clause also in the indexes and the scan type has improved from table access full to index fast full scan. Is this correct ? Should select columns be also a part of indexes ? My take was that indexes contain columns in "where" clause or columns where joins are implemented and not select columns.
Please suggest.

An Index that includes all the columns of the SELECT clause with those of the WHERE clause is a "skinny table".
Using such an Index avoids accesses to the table entirely.
There are situations where the DBA or Designer may choose to create such an Index.
Downsides ?*
If there are too many columns in the Index, the Index itself may become too large. When the index is too large for Oracle to be able to cache blocks, Oracle may have to undertake multiple single block read calls to the OS if accessing many rows. This can make the index counter-productive.
Index maintenance overheads increase -- the probability that the index also has to be updated with every UPDATE statement on the table increases. Also, every INSERT and DELETE makes that much more effort updating the Index Leaf Blocks (ie the size of the update to the Index is larger, the Index Key being larger).
Some queries might be executed using Skip Scan Search of the index when, properly, it might have made more sense to put those query columns in a seperate index.

Usage of reverse key index

Hi,
Any body can explain the usage of reverse key index.
Thanks and regards,

It could be an option if you have lots of inserts simultaniously (and I mean lots not 2 a second - rather 1000'ds).
If the index field comes like this 1000, 1001, 1002, 1003, 1004 etc etc then the very same index leaf blocks will be hit when using a "normal" index - if it is reverse, you will spread the IO load on many blocks - and might give a better performance. If reversed it will be 0001, 1001, 2001, 3001, 4001 instead (inserwise).
BUT .... be aware when using ... between, GT og LT on those reversed indexed fields - index skip scans are not possible - so you may sacrifice performance in the selects.
We have used it for audit records, where we had many many records being inserted from 20 simult. processes (java stuff), just reading off a jms queue and inserting. We had lots of waits - then we reversed index. And we do not have any appl. selecting the audit records.
Mette

BITMAP index and BLEVEL

Hi All,
We have one BITMAP index on a flag column (Y/N).Table is non partitioned with 3.4 million records.
Following are index stats.
select INDEX_NAME,INDEX_TYPE,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,CLUSTERING_FACTOR,NUM_ROWS,SAMPLE_SIZE,DEGREE FROM DBA_INDEXES WHERE
INDEX_NAME='LATE_VER_FLG_CAX_IDX' AND OWNER='EQHUB'
INDEX_NAME           INDEX_TYPE     BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS SAMPLE_SIZE DEGREE
LATE_VER_FLG_CAX_IDX BITMAP             11         716             2             72783      72783       72783 1
select last_analyzed,sample_size,num_rows from dba_indexes where index_name='LATE_VER_FLG_CAX_IDX';
LAST_ANALYZED      SAMPLE_SIZE   NUM_ROWS
31.Jan.09/00:29:41       72783      72783
NAME                      HEIGHT     BLOCKS    LF_ROWS    LF_BLKS LF_ROWS_LEN    BR_ROWS    BR_BLKS DEL_LF_ROWS DISTINCT_KEYS BTREE_SPACE USED_SPACE   PCT_USED
LATE_VER_FLG_CAX_IDX          12       4352          0          0                      1          1           0             0        8028
CREATE BITMAP INDEX "EQHUB"."LATE_VER_FLG_CAX_IDX" ON "EQHUB"."BBO_CORPORATE_ACTIONS" ("LATEST_VERSION_FLAG")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 2097152 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "ETDHUB_EQHUB_INDEX"
SQL> select LATEST_VERSION_FLAG,count(*) from BBO_CORPORATE_ACTIONS group by LATEST_VERSION_FLAG;
L   COUNT(*)
N    2265303
Y    1189116I am wondering
1.What can be done to reduce index BLEVEL/HEIGHT? (i assume COALESCE will not help)..Should i rebuild the index?
2.Why BTREE_SPACE is only showing 8028 where dba_segments is showing index size =34 MB?
3.Why PCT_USED is NULL?
Is that so BLEVEL/PCT_USED not relative for BITMAP Indexes?
I found that no query is using this index for last 60 days and performance is getting degraded due to FTS.
Should i REBUILD the index so that i can reduce BLEVEL/HEIGHT/INDEX_SIZE and improve query performance with INDEX ACCESS.
Regards,
Bhavik Desai

Bhavik Desai wrote:
You perfectely caught the DML pattern.There are 4 daily ELT jobs which INSERT 300 and UPDATE 250 records/execution.
May i ask you,upon which observation,you point this?Also it would be greate if you tell me how did you calculate 67% PCT_FREE.
This was based on the fact that an update to a single row in a table could result in a copy of an entire bitmap index chunk being made; so you need to leave a lot of space free in the leaf blocks to allow for these copies because you really don't want to cause an index leaf block split to occur - especially since that would tend to cascade up the index and cause a branch block split as well. On this basis, pctfree 51 should be adequate for most cases, but setting it to 67 (a) allows you to do a couple of updates/clones to the same chunk before you hit a problem, and (b) helps to keep the chunks smaller which helps to reduce the undo and redo a bit.
This has just reminded me of a little detail - I am a little surprised by the fact that you got an index into this state in 10.2, because that release of Oracle seems to avoid creating a long chain of clones of the same index chunk when you do a series of small updates, and it is the chain of clones that results in branch blocks split running up the index and exploding it to an enormous height. Has this database been upgraded from 9i (or even 10.1) some time in the fairly recent past ?
>
I still dont understand,
1.Why there is no difference in BTREE_SPACE?
2.Why PCT_USED is NULL?
I've just run a quick test on 10.2.0.1 and 10.2.0.3 creating a table with a y/n/null column and creating a bitmap index on it. The results from index_stats didn't match across versions, and the 10.2.0.3 stats were clearly garbage - very similar to yours. For the moment I would assume that something has been broken in 10.2.0.3 with this use of the validate command.
>
If we consider Franck Pachot's observation,then it would be better to convert the BITMAP to BTREE.Is this a normal bitmap behavior?Randolf's observation about the numbers of rows involved is most relevant: it doesn't look like an index that the optimizer should consider using for anything other than select flag, count(*), and changing from a bitmap to a btree won't make any difference. In other words, unless you can point to an important piece of code and say "it makes tis bit run much better" maybe the index shouldn't exist at all.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The temptation to form premature theories upon insufficient data is the bane of our profession."
Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear".

Why Index size is bigger than table size?

Dear All,
I found in my database my tables sizes is coming around 30TB (All Tables in Database). and my index size for the same is 60TB. This is data ware housing environment.
How the index size and table size are differing?
Why they are differing? why index size is bigger than table size?
How to manage the size?
Please give me clear explanation and required information on the above.
Regards
Suresh

There are many reasons why the total space allocated indexes could be larger than the total space allocated to tables. Sometimes it's a mark of good design, sometimes it indicates a problem. In your position your first move is to spend as little time as possible in deciding whether your high-level summary is indicative of a problem, so you need to look at a little more detail.
As someone else pointed out - are you looking at the sizes because you are running out of space, or because you have a perceived performance problem. If not, then your question is one of curiosity.
If it's about performance then you should be looking for code (either through statspack/AWR or sql_trace) that is performing badly and use the analysis of that code to help you identify suspect indexes.
If it's about space, then you need to do some simple investigations aimed at finding a few indexes that can be "shrunk" or dropped. Pointers for this are:
select
        table_owner, table_name, count(*)
from
        dba_indexes
group by
        table_owner, table_name
having
        count(*) > 2   -- adjust to keep the output short
order by
        count(*) desc;This tells you which tables have the most indexes - check the sizes of the tables and indexes and then check the index definitions for the larger tables with lots of indexes.
Second quick check - join dba_tables to dba_indexes by table_name, and report the table blocks and index leaf blocks in desending order of leaf block count. Look for indexes which are very big, and also bigger than their underlying tables. There are special cases (and bugs) that can cause indexes to be much bigger than they need to be ... this report may identify a couple of anomalies that could benefit from an emergency fix followed (possibly) by a strategic fix.
Regards
Jonathan Lewis

RAC에서 Current Block과 CR Block

RAC 환경에서 시퀀스를 캐싱을 많이 할 경우 Index Leaf Block Contention 감소시켜서 속도를 증가 시킬수 있다고 들었습니다.
Row가 Insert 될 때마다 가장 큰 Key를 가진 Index Leaf Block이 값이 계속 증가하면서 바뀌므로, 이것은 RAC 환경에서 노드간 Current Block과 CR Block의 높은 전송량을 유발하며 성능 저하 현상을 일으킨다고 하는데요.
"노드간 Current Block과 CR Block의 높은 전송량을 유발" 한다는 말이 잘 이해가 안가는데 설명 부탁드립니다.

두가지에 대한 정의
cr block : Consistent Read block
하나가 업데이트 중인데 커밋이 되지 않았을 경우 읽기 일관성을 위해
누군가 select하게 되면 과거의 이미지를 만들어야 하는데 이는 언두세그먼트에가서 과거의 이미지를 찾아서 만들어야 한다. 이는 하나의 버퍼로 사용되지 않고 이 때 생성되는 버퍼블록이 cr block입니다. ( 과거와 현재의 ..버퍼 ) insert, delete는 cr block에 포함되지 않습니다. update만 해당됩니다.
current block
DML을 통해서 수정을 위해서 데이터를 읽을 때에 segment의 block을 읽을 때에 이것을 current block이라 한다. select의 경우에는 full scan 할 경우에 segment header를 읽는 것이 current block이 된다.
누군가 테스트를 한 것인데 너무 좋은 자료라 올립니다.
출처>
http://www.insight-tec.com/en/mailmagazine/vol159.html
X$BH
Last time, I viewed STATE column of X$BH in a single server and in a single session and examined the following points:
CR block is not created by SELECT or INSERT queries.
CR block is created by UPDATE queries.
There are some cases where CR block is not created by UPDATE queries, though. I will analyze these cases in this issue. DELETE queries operate almost the same as UPDATE queries.
The following is the testing environment:
(Environment)
Linux 2.4.2-2
Oracle9i EE Release 9.2.0.1.0
(Table configuration)
SQL> desc test
Name Type
ID1 NUMBER
ID2 NUMBER
TEXT VARCHAR2(2000)
*Grant INDEX (TEST_IDX) to ID1
Table contains following data.
ID1 ID2 TEXT
1 1 insight
2 2 insight
3 3 insight
I executed the following statement last time.
SQL> update test set id1 = 1 where id2 =2;
WHERE clause specifies the row ID2. As ID2 is not indexed, full scan will be performed to update.
The following query specifies ID1 in WHERE clause. As ID1 is indexed, index scan will be performed to update.
(UPDATE query)
SQL> update test set id1 = 1 where id1 =2;
*ID1 is specified in WHERE clause so that index scan
is performed.
(Status of database buffer)
SQL> select
o.object_name
,decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec'
,6,'irec',7,'write',8,'pi') STATE
, count(*) BLOCK
from x$bh b , dba_objects o
where b.obj = o.data_object_id
and o.object_name like 'TEST%'
group by o.object_name, state
OBJECT_NAME STATE BLOCKS
TEST xcur 2
TEST_IDX xcur 1
CR block is not created, as you see. Regarding index, there is only one block on database buffer. When I previously performed full scan under the condition where there was no data to be updated, CR block was not created.
Status of database buffer when there is no target data
to be updated at full scan.
SQL> update test set id1=3 where id2=5;
*ID2 is not indexed. There is no such data as ID2=5.
0 row updated
OBJECT_NAME STATE DBARFIL DBABLK BA
TEST xcur 1 70913 54D28000
TEST xcur 1 70914 54D20000
CR blocks are created in the following cases.
CR block is created (in a single session)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UPDATE SELECT INSERT
Full scan Yes No --
Index scan No No --
In a single session environment, CR blocks are created only by UPDATE query at full scan. Why CR blocks are created under this condition?
CR block itself is a read consistent block, but I wonder why CR block is created in a single session environment. I assume that CR block is created to create rollback information or to satisfy lock function.
CR block is not created at index scan because it is possible to identify ROWID of target data from the index. As UPDATE process is performed by each row, CR block is not necessary.
Lastly, I will examine a mechanism of current block updating, which is quite different from the one of full scan and of index scan.
The following table indicates the changes in the buffer address of a current block at index scan.
UPDATE at index scan:
[Before UPDATE]
OBJECT_NAME STATE DBABLK BA
TEST xcur 18716 54D0E000 <-target block
TEST_IDX xcur 18724 54D04000
[After UPDATE]
OBJECT_NAME STATE DBABLK BA
TEST xcur 18716 54D0E000 <-target block
TEST_IDX xcur 18724 54D04000 *No changes
I don't see any changes in the buffer address. This means that the data in the current block is updated directly.
The following table indicates the changes in the buffer address of an XCUR block at full scan.
UPDATE at full scan:
[Before UPDATE]
OBJECT_NAME STATE DBABLK BA
TEST xcur 18717 54C3A000 <-target block
[After UPDATE]
OBJECT_NAME STATE DBABLK BA
TEST xcur 18717 551F2000 <-target block
TEST cr 18717 54C3A000 *BA is changed
|
BA of current block before being updated
I see changes in the buffer address. In addition, the current block is changed to CR block after updating. The process is performed as follows:
1. A current block (XCUR) in 54C3A000 is copied to 551F2000.
2. The current block is changed to CR block.
3. Update process is performed to XCUR.

GC current block busy

Hi ,
I have two node Oracle RAC.Version is 11.2.0.2
When i do an online inquire transaction for higher load, I am observing 'gc current block busy' in AWR as one of the top events.GV$SESSION_WAIT
doesnt show anything as below.
Kindly let me know how to tune it.
AWR top events.
DB CPU   32   64.34
log file sync 5,972 9 2 18.36 Commit
gc current block busy 2,448 7 23 13.32 Cluster
gc current block 2-way 4,665 3 1 5.41 Cluster
gc current grant busy 2,446 1 0 2.20 Cluster
SQL> SELECT
INST_ID,
EVENT,
P1 FILE_NUMBER,
P2 BLOCK_NUMBER,
WAIT_TIME
FROM
GV$SESSION_WAIT
WHERE
EVENT IN ('buffer busy global cr', 'global cache busy',
            'buffer busy global cache');
2    3    4    5    6    7    8    9   10   11
no rows selectedThanks

user10698496 wrote:
I have two node Oracle RAC.Version is 11.2.0.2
When i do an online inquire transaction for higher lRoad, I am observing 'gc current block busy' in AWR as one of the top events.GV$SESSION_WAIT
doesnt show anything as below.
Kindly let me know how to tune it.(Note: Your query against v$session_Wait doesn't seem to match the events listed in the AWR.)
(Note 2: Your snapshot seems to be for a very short time - which doesn't really give an idea of how serious the problem may be in the bigger picture.)
There are many GC events that you won't see in v$session_wait because the session doesn't know the event consuming the time until after the wait has completed - so when you check v$session_wait you will often see "gc cr request", or "gc current request" (I think I may have the names wrong, but I don't have an instance in front of me right now) - these are known as "placeholders" to Oracle and may change to things like "gc current block 2-way" or "gc current block 3-way".
You've looked at the ADDM (so you're licensed for the diagnostic), and seen the top object. Had you not done so I would have suggested looking at the "Segments by .." sections of the AWR report, checking the two sections on CR and CUR traffic; then check the "SQL ordered by ...." sections for the sections on global cache time. If your offenders are insert statements that match primary key indexes then you probably need to stop the instances from inserting into the same index leaf block at the same time.
A key question to ask is whether the primary key is a meaningless value generated by an Oracle sequence; if so have you set the sequence cache size to a large enough value (in the order of thousands or tens of thousands). This is the first step in resolving sequence-based RAC issues. (There are other strategies - but we need more information to determine best action.)
Regards
Jonathan Lewis
P.S. The best place on the Internet for information about details of how RAC works and the interpretation of RAC events is probably Riyaj Shamsudeen's blog at: http://orainternals.wordpress.com/
Edited by: Jonathan Lewis on May 14, 2012 8:24 AM

INI_TRANS for TABLE and INDEX

Hi,
My DB version is 10.2.0.3
As by default the INI_TRANS of tables is 1 and for indexes is 2. For some reasons I have to increase the INI_TRANS of a table to 5, then what value do I set for INI_TRANS of indexes on that table?
I have read somewhere that INI_TRANS of indexes to be set twice as of table's INI_TRANS. Means if tables INI_TRANS is 5 then index INI_TRANS must be set to 10. Is it true? If yes then what is the logic behind this?
Thanks,
Oratest
Edited by: oratest on Feb 4, 2013 3:26 PM

oratest wrote:
My DB version is 10.2.0.3
As by default the INI_TRANS of tables is 1 and for indexes is 2. For some reasons I have to increase the INI_TRANS of a table to 5, then what value do I set for INI_TRANS of indexes on that table?
I have read somewhere that INI_TRANS of indexes to be set twice as of table's INI_TRANS. Means if tables INI_TRANS is 5 then index INI_TRANS must be set to 10. Is it true? No.
There is no useful guideline for a generic setting. Consider the contradictory scenes:
a) Five sessions insert five separate rows into a single table block - taking up 5 ITL slots. There is an index on the table, but the five rows just inserted hold such different values that their index entries go to 5 different index leaf blocks: the index doesn't need initrans 5.
b) Using ASSM 80 different sessions insert a row each into a table - the nature of ASSM means that (on average) there will be 5 rows inserted into 16 different blocks - the table ASSM needs to be 5. However, the indexed column in this case is generated by a sequence and all 80 index entries ought to be inserted into the same leaf block, so you need initrans to be 80 on the index. (Except Oracle will do index leaf block splits to work around problems of initrans being too small on concurrent inserts.
You have to consider the nature of the indexes and the pattern of data change for every single index separately - and then you might set initrans on the index to NO MORE THAN the table initrans + 1 because (a) that won't waste too much space (b) it's probably not going to let too much contention happen (c) Oracle will dynamically extend the ITL in most cases, (d) if it's bad for one particular index you'll notice it pretty quickly - and there will be other problems (buffer busy waits) to deal with on that index anyway.
Regards
Jonathan Lewis

Index leaf blocks???

Similar Messages

Maybe you are looking for