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.

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".

Reduce Clustering Factor

Hii All
Is there any way to reduce clustering factor on exist table? or is there any way to make closer datablocks of same value of the table ?
Best Regards

you may check this article - http://www.dizwell.com/prod/node/22
CF affects CBO decision, the data layout affects CF, rebuilding the table changes CF:
create table T1 as select * from dba_objects order by object_id;
create index I1 on T1(object_id);
analyze table T1 compute statistics;
select t.blocks, i.clustering_factor from dba_tables t, dba_indexes i
where t.table_name=i.table_name and t.table_name=’T1’;
BLOCKS CLUSTERING_FACTOR
173 161
set autotrace trace explain
select * from t1 where object_id=7632;
set autotrace off
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 78 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 78 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I1 | 1 | | 1 (0)| 00:00:01 |
insert into T1 select * from dba_objects order by object_name;
analyze table T1 compute statistics;
select t.blocks, i.clustering_factor from dba_tables t, dba_indexes i
where t.table_name=i.table_name and t.table_name=’T1′;
BLOCKS CLUSTERING_FACTOR
382 25281
set autotrace trace explain
select * from t1 where object_id=7632;
set autotrace off
Execution Plan
Plan hash value: 1704772559
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 156 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 2 | 156 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I1 | 2 | | 1 (0)| 00:00:01 |
alter index I1 rebuild;
analyze table T1 compute statistics;
select t.blocks, i.clustering_factor from dba_tables t, dba_indexes i
where t.table_name=i.table_name and t.table_name=’T1′;
BLOCKS CLUSTERING_FACTOR
382 25281
create table T2 as select * from T1;
truncate table t1;
insert into T1 select * from T2 order by object_id;
analyze table T1 compute statistics;
select t.blocks, i.clustering_factor from dba_tables t, dba_indexes i
where t.table_name=i.table_name and t.table_name=’T1′;
BLOCKS CLUSTERING_FACTOR
370 359
set autotrace trace explain
select * from t1 where object_id=7632;
set autotrace off
Execution Plan
Plan hash value: 1704772559
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 156 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 2 | 156 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I1 | 2 | | 1 (0)| 00:00:01 |
————————————————————————————

Reg : Clustering Factor -

Hi Experts,
I was reading about Indexes and the 'Clustering Factor' (CF). Every where it says like -
>
If CF is closer to the no. of Blocks --> Index is Clustered and rows are well-Ordered.
If CF is closer to the no. of Rows --> Index is not-Clustered and rows are not Ordered.
>
This is fine and understandable.
What I'm not getting is - When and how does the CF gets changed? Is it the DML operations which changes it?
Any pointer on this is highly appreciated. Thanks.
Ranit B.

>
When and how does the CF gets changed? Is it the DML operations which changes it?
>
Short answer - YES - it is DML that both determines it to begin with and changes it over time.
The CF of an index is determined by the relative order of the index key values IN THE TABLE. So any operation that changes that relative order will tend to change the CF also.
One way to intentionally change the CF for an index is to rebuild the table (not the index) based on data sorted by an indexes key values.
One key point to remember is that the ideal data order for one index may be the worst order possible for one or more other indexes. So while reordering the table data may give you the ideal CF for one index it may make the CF for other, perhaps more important, indexes worse.
The doc, if you haven't read it already, is always the first place to look for information.
See the section on 'Index Clustering Factor' in the Database Concepts doc. The example in that section illustrates CF
http://docs.oracle.com/cd/E11882_01/server.112/e10713/indexiot.htm
>
Index Clustering Factor
The index clustering factor measures row order in relation to an indexed value such as employee last name. The more order that exists in row storage for this value, the lower the clustering factor.
The clustering factor is useful as a rough measure of the number of I/Os required to read an entire table by means of an index:
•If the clustering factor is high, then Oracle Database performs a relatively high number of I/Os during a large index range scan. The index entries point to random table blocks, so the database may have to read and reread the same blocks over and over again to retrieve the data pointed to by the index.
•If the clustering factor is low, then Oracle Database performs a relatively low number of I/Os during a large index range scan. The index keys in a range tend to point to the same data block, so the database does not have to read and reread the same blocks over and over.
The clustering factor is relevant for index scans because it can show:
•Whether the database will use an index for large range scans
•The degree of table organization in relation to the index key
•Whether you should consider using an index-organized table, partitioning, or table cluster if rows must be ordered by the index key
>
Then the '11.5.3.1 Assessing I/O for Blocks, not Rows' section in the Performance Tuning Guide has the specifics about how the Optimizer costs are affected by CF and Example 11-3 'Effects of Clustering Factor on Cost' illustrates that
http://docs.oracle.com/cd/B28359_01/server.111/b28274/optimops.htm#i82433
>
Oracle does I/O by blocks. Therefore, the optimizer's decision to use full table scans is influenced by the percentage of blocks accessed, not rows. This is called the index clustering factor. If blocks contain single rows, then rows accessed and blocks accessed are the same.
However, most tables have multiple rows in each block. Consequently, the desired number of rows could be clustered together in a few blocks, or they could be spread out over a larger number of blocks.
Although the clustering factor is a property of the index, the clustering factor actually relates to the spread of similar indexed column values within data blocks in the table. A lower clustering factor indicates that the individual rows are concentrated within fewer blocks in the table. Conversely, a high clustering factor indicates that the individual rows are scattered more randomly across blocks in the table. Therefore, a high clustering factor means that it costs more to use a range scan to fetch rows by rowid, because more blocks in the table need to be visited to return the data. Example 11-3 shows how the clustering factor can affect cost.

Clustering Factor

Does anyone know where I might find some information regarding the index clustering factor. I have found that I have some indexes with very high factors and I would like to know what I could do to decrease it.
Thanks,
Tammy
null

Well, clustering_factor will have considerable impact on helping optimizer for choosing index scan or FTS.
If the CLUSTERING_FACTOR is closer to the number of Blocks, then the table is wellordered and fewerblocks would need to be read to satisfy a query.
If the CLUSTERING_FACTOR is closer to the number of Rows in the Table, then the table is NOT well ordered.
Clustering_factor is depends on the order of data in the datablocks. If the data is well ordered, you will have good clustering_factor else the clustering factor be = num_rows.
Read the following link, you will get much more info.
http://www.dizwell.com/prod/node/22
Jaffar

Clustering factor of index

Hi,
I found some where that if clustering_factor in an index is very than leaf_blocks, the table is not well organised.
In my database I found this condition is true, & I want to make my table much organized.
What can I do to do that, & what is the basic fundamental of clustering_factor.
Any help will be highly appreciated.
Thanks
Deepak

You would have to copy all the data to a temporary table, truncate the table, and then re-insert all the data sorted in the same order as the index. However, one doesn't normally do this! Bear in mind that you can only really optimise the clustering factor for one of the indexes on a table, so by improving it for one index you may make it worse for others.
Generally the clustering factor is used (by the optimiser) to determine the suitability of an index for a query, not as an indication that the data is stored in the "wrong" order.

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 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

Optimizer is not using the right index

Hi gurus,
there's something I understand. If someone can explains, it'll be greatly appreciated.
Env:
10gR2 on Redhat AS
The
SQL> desc stock_detail
Name Null? Type
NO NOT NULL NUMBER(15)
BP_CODE NOT NULL VARCHAR2(10)
STOC_CAT_CODE NOT NULL VARCHAR2(6)
BUIL_CODE NOT NULL VARCHAR2(8)
LOCA_CODE NOT NULL VARCHAR2(8)
LOCA_SUB_CODE NOT NULL VARCHAR2(6)
ITEM_NO NOT NULL NUMBER(8)
QTY NOT NULL NUMBER(6)
DEFAULT_SHELF NOT NULL VARCHAR2(1)
CREATION_DATE NOT NULL DATE
CREATION_USER NOT NULL VARCHAR2(8)
CM_NO NUMBER(15)
LANDING_COST NUMBER(11,2)
SUPPLI_COST NUMBER(11,2)
RMA_DEADLINE DATE
MOD_USER VARCHAR2(8)
MOD_DATE DATE
RECEP_DATE DATE
NOTE VARCHAR2(2000)
FLAG VARCHAR2(1)
REFUS VARCHAR2(1)
STOC_MOVE_REAS_CODE VARCHAR2(6)
I have many indexes on this table. (like 5 or 6).
There's one with item + business_unit (lets say INDEX_A)
And there's one with item + category + business_unit (lets say INDEX_B)
The following sql is always using the wrong index
select nvl(sum(sd.qty),0)
from stock_detail sd, location lo
where sd.item_no = 419261 <- In INDEX_A & INDEX_B
and sd.STOC_CAT_CODE='REG' <- In INDEX_B
and sd.bp_code = 'TECMTL' <- In INDEX_A & INDEX_B
and sd.buil_code <> 'TRANSIT'
and sd.buil_code = lo.buil_code
and sd.loca_code = lo.code
and sd.loca_sub_code = lo.sub_code
and nvl(lo.restricted, 'N') = 'Y';
This SQL always use the INDEX_A. INDEX_B is far better.
Stats of the index uactually used (INDEX_A):
Last Analyzed 2007-10-18 22:04:38
Blevel 1
Distinct Keys 72124
Clustering Factor 105368
Leaf Blocks 339
Average Leaf Blocks Per Key 1
Average Data Blocks Per Key 1
Number of Rows 110285
Sample Size 110285
Stats of the index I want to be used (INDEX_B)
Last Analyzed 2007-10-18 22:04:46
Blevel 2
Distinct Keys 77407
Clustering Factor 103472
Leaf Blocks 551
Average Leaf Blocks Per Key 1
Average Data Blocks Per Key 1
Number of Rows 110285
Sample Size 110285
Is there a way to use the right index without adding a hint?
Thanks in advance.
Message was edited by:
(made a mistkae on the stats of index B)

I assume the execution path is a nested loop driving of the table with the constant inputs.
The key difference in the stats is that the second index has a blevel of 2. I'd guess that the cost of using the first index is 1, and the cost of using the second index is three.
The basic cost of accessing a table through an index is:
blevel +
index selectivity (ix_sel) * leaf blocks +
table selectivity (ix_sel_with_filtering) * clustering_factor.
However, if the blevel is 1, then Oracle ignores it.
Your index and table selectivities in both cases are 1/distinct_keys (since this is 10.2)
The numbers involved with the leaf block and clustering factor calculations are so small (and similar) that the difference of 2 in the add-on for the blevel is the deciding factor.
According to the statistics, though, the choice of index shouldn't make much difference to the performance, since the number of rows (and blocks) visited is likely to be the same. However, if you have an uneven distribution of values for individual columns, you may need a histogram on that column so that the optimizer can see the effect it has on the expected work.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
P.S. I suppose it's probably fair to mention that I wrote a pretty good book about how the optimizer works: http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html

Backup Frequency

Hi all,
I want to know in the production database how frequently backup is taken. Whether each transaction is backedup or at a regular interval backup taken say every hour or 2 hr or daily once.
If every transactions is backed up then how to take backup of that using RMAN or anyother backup strategy.
Thanks in advance,
Swadhin

Following are the statistics genarated by analyze comand which are used by optimzer to determine the most efficient way to execute the sql statement.
Table Statistics
Number of rows
Number of blocks
Avg. row Length
Number of distinct values in column
Number of nulls
histograms
Indexe
Number of leaf blocks
Levels
Clustering factor
and IO, CPU performance

Index not picked when bind parameter can be null?

Hi,
In my query i have a primary key say deptid and has an unique index defined.
when i do a query as
select * from dept where ((deptid = :pDeptId) or (:pDeptId is null))
index is not picked up and a full table scan happens.
Can one explain why?
Thanks
Manish

Solomon Yakobson wrote:
I purposely chose small table. Yes, optimizer calculated costs are such that FTS cost is same as combined cost of index fast scan + table access by rowid. And that is exactly what I am questioning. Set aside what you call "boundary" cases where rows are sparse enough (e.g. your example with lots of deleted rows) and similar scenarios (e.g. pctfree is very large, etc.) FTS is always less costly than index fast scan + table access by rowid by at least one IO. I understand, I am splitting hairs a bit since the difference is negligible, but still it is a sub-optimal plan.Solomon,
and yes, in those circumstances you describe the FTS will be chosen, so what is your point? Your test case represents such an "odd" scenario (sparse, large pctfree, etc., less rows than blocks, a clustering factor of the index less than the number of blocks of the table), so what do you want to prove using this test case? It doesn't represent the "normal" circumstances where the FTS is less costly.
In passing, the cost of the FTS and the combined operation are not the same in my default 10.2.0.4 database, the FTS is more expensive, as I've outlined previously.
The reason: It takes at least 1 multi-block I/O request to read the 5 blocks of the table. The optimizer assumes that the time it takes to perform a multi-block read request is 26ms when using default NOWORKLOAD system statistics with 8KB default block size. It assumes further it takes 12ms to perform a single-block read request, so the cost (expressed in single-block reads) of performing a single multi-block read request is 2.16. Since Oracle 9i, there is a hidden parameter "_table_scan_cost_plus_one" set to "true", it used to be "false" in 8i, making the cost 3.16, so we end up with a rounded cost of 3 for the FTS.
The cost of the combined index + table access is 2, one I/O for the index, plus one I/O for the table access. So from an optimizer perspective this plan is not sub-optimal, but the superior one, mainly due to the fact that one gets added to the table scan cost from 9i on, and you have the unusual clustering factor of 1.
As you can see, it takes a lot of "boundary" conditions that this happens, and it's all down to the fact that the table is so small, that is has only 4 rows in 5 blocks, and the clustering factor of the index is less than the number of blocks of the table, which is quite unusual. A "optimal" clustering factor usually corresponds to the number of blocks of the table, a "bad" clustering factor corresponds to the number of rows.
Therefore I suggested to "adjust" the clustering factor to a more usual value, but there is actually nothing usual about this test case since you have less rows than blocks.
So I guess you can say whatever you want about this being a "sub-optimal" plan, but I really don't see the point it makes, given the flawed test case. Run it with a more reasonable setup and the FTS will be used in those cases where it is reasonable according to the inputs the CBO gets.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

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

Error: 1012704 Dynamic Calc processor cannot lock more than [25] ESM blocks

Dear All,
I get the Following Error in the Essbase console when I try to Execute any CalcScript.
Error: 1012704 Dynamic Calc processor cannot lock more than [25] ESM blocks during the calculation, please increase CalcLockBlock setting and then retry(a small data cache setting could also cause this problem, please check the data cache size setting)_+
Please find the detailed output of the Statics of my Planning Applications Database and outline.
please help guys........
GetDbStats:
-------Statistics of AWRGPLAN:Plan1 -------
Dimension Name Type Declared Size Actual Size
===================================================================
HSP_Rates SPARSE 11 11
Account DENSE 602 420
Period DENSE 19 19
Year SPARSE 31 31
Scenario SPARSE 6 6
Version SPARSE 4 4
Currency SPARSE 10 10
Entity SPARSE 28 18
Departments SPARSE 165 119
ICP SPARSE 80 74
LoB SPARSE 396 344
Locations SPARSE 57 35
View SPARSE 5 5
Number of dimensions : 13
Declared Block Size : 11438
Actual Block Size : 7980
Declared Maximum Blocks : 3.41379650304E+015
Actual Maximum Blocks : 1.87262635317E+015
Number of Non Missing Leaf Blocks : 10664
Number of Non Missing Non Leaf Blocks : 2326
Number of Total Blocks : 12990
Index Type : B+ TREE
Average Block Density : 0.01503759
Average Sparse Density : 6.936782E-010
Block Compression Ratio : 0.001449493
Average Clustering Ratio : 0.3333527
Average Fragmentation Quotient : 19.3336
Free Space Recovery is Needed : No
Estimated Bytes of Recoverable Free Space : 0
GetDbInfo:
----- Database Information -----
Name : Plan1
Application Name : AWRGPLAN
Database Type : NORMAL
Status : Loaded
Elapsed Db Time : 00:00:05:00
Users Connected : 2
Blocks Locked : 0
Dimensions : 13
Data Status : Data has been modified
since last calculation.
Data File Cache Size Setting : 0
Current Data File Cache Size : 0
Data Cache Size Setting : 3128160
Current Data Cache Size : 3128160
Index Cache Size Setting : 1048576
Current Index Cache Size : 1048576
Index Page Size Setting : 8192
Current Index Page Size : 8192
Cache Memory Locking : Disabled
Database State : Read-write
Data Compression on Disk : Yes
Data Compression Type : BitMap Compression
Retrieval Buffer Size (in K) : 10
Retrieval Sort Buffer Size (in K) : 10
Isolation Level : Uncommitted Access
Pre Image Access : No
Time Out : Never
Number of blocks modified before internal commit : 3000
Number of rows to data load before internal commit : 0
Number of disk volume definitions : 0
Currency Info
Currency Country Dimension Member : Entity
Currency Time Dimension Member : Period
Currency Category Dimension Member : Account
Currency Type Dimension Member :
Currency Partition Member :
Request Info
Request Type : Data Load
User Name : admin@Native Directory
Start Time : Mon Aug 15 18:35:51 2011
End Time : Mon Aug 15 18:35:51 2011
Request Type : Customized Calculation
User Name : 6236@Native Directory
Start Time : Tue Aug 16 09:44:10 2011
End Time : Tue Aug 16 09:44:12 2011
Request Type : Outline Update
User Name : admin@Native Directory
Start Time : Tue Aug 16 10:50:02 2011
End Time : Tue Aug 16 10:50:02 2011
ListFiles:
File Type
Valid Choices: 1) Index 2) Data 3) Index|Data
>>Currently>> 3) Index|Data
Application Name: AWRGPLAN
Database Name: Plan1
----- Index File Information -----
Index File Count: 1
File 1:
File Name: C:\Oracle\Middleware\user_projects\epmsystem1\EssbaseServer\essbaseserver1\APP\AWRGPLAN\Plan1\ess00001.ind
File Type: INDEX
File Number: 1 of 1
File Size: 8,024 KB (8,216,576 bytes)
File Opened: Y
Index File Size Total: 8,024 KB (8,216,576 bytes)
----- Data File Information -----
Data File Count: 1
File 1:
File Name: C:\Oracle\Middleware\user_projects\epmsystem1\EssbaseServer\essbaseserver1\APP\AWRGPLAN\Plan1\ess00001.pag
File Type: DATA
File Number: 1 of 1
File Size: 1,397 KB (1,430,086 bytes)
File Opened: Y
Data File Size Total: 1,397 KB (1,430,086 bytes)
File Size Grand Total: 9,421 KB (9,646,662 bytes)
GetAppInfo:
-------Application Info-------
Name : AWRGPLAN
Server Name : GITSHYPT01:1423
App type : Non-unicode mode
Application Locale : English_UnitedStates.Latin1@Binary
Status : Loaded
Elapsed App Time : 00:00:05:24
Users Connected : 2
Data Storage Type : Multidimensional Data Storage
Number of DBs : 3
List of Databases
Database (0) : Plan1
Database (1) : Plan2
Database (2) : Plan3

ESM Block Issue
Cheers..!!

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".

How to Reduce Clusetering Factor on Table?

I am seeing a very high clustering factor on an SDO geometry table in our 10g RAC DB on our Linux boxes. This slow performance is repeateable on othe r Linux as well as Solaris DBs for the same table. Inserts go in at a rate of 44 milliseconds per insert and we only have about 27000 rows in the table. After viewing a VERY slow insert of about 600 records into this same table, I saw the clustering factor in OEM. The clustering factor is nearly identical to the # rows in the table indicating that useability of the index is fairly low now. I have referenced Metalink Tech Note 223117.1 and, while it affirms what I've seen, I am still trying to determine how to reduce the Clustering Factor. The excerpt on how to do this is below:
"The only method to affect the clustering factor is to sort and then store the rows in the table in the same order as in they appear in the index. Exporting rows and putting them back in the same order that they appeared originally will have no affect. Remember that ordering the rows to suit one index may have detrimental effects on the choice of other indexes."
Sounds great, but how does one actually go about storing the rows in the table in the same order as they appear in the index?
We have tried placing our commits after the last insert as well as after every insert and the results are fairly neglible. We also have a column of type SDE.ST_GEOMETRY in the table and are wondering if this might also be an issue. Thanks in advance for any help.
Matt Sauter

Joel is right that the clustering factor is going to have absolutely no effect on the speed of inserts. The clustering factor is merely one, purely statistical, factor the optimiser makes use of to determine how to perform a SELECT statement (i.e., do I bother to use this index or not for row retrieval). It's got nothing to do with the efficiency of inserts.
If I were you, I'd be looking at factors such as excessive disk I/O taking place for other reasons, inadequate buffer cache and/or enqueue and locking issues instead.
If you're committing after every insert, for example, then redo will have to be flushed (a commit is about the only foreground wait event -i.e., one that you get to experience in real time- that Oracle has, so a commit after every insert's really not a smart idea). If your redo logs are stored on, say, the worst-performing disk you could buy that's also doing duty as a fileserver's main hard disk, then LGWR will be twiddling its thumbs a lot! You say you've tested this, and that's fine... I'm just saying, it's one theoretical possibility in these sorts of situations. You still want to make sure you're not suffering any log writer-related waits, all the same.
Similarly, if you're performing huge reads on a (perhaps completely separate) table that is causing the buffer cache to be wiped every second or so, then getting access to your table so your inserts can take place could be problematic. Check if you've got any database writer waits, for example: they are usally a good sign of general I/O bottlenecks.
Finally, you're on a RAC... so if the blocks of the table you're writing to are in memory over on another instance, and they have to be shipped to your instance, you could have high enqueue waits whilst that shipment is taking place. Maybe your interconnect is not up to the job? Maybe it's faulty, even, with significant packet loss along the way? Even worse if someone's decided to switch off cache fusion transfer for the datafiles invoved (for then block shipment happens by writing them to disk in one instance and reading from disk in the other). RAC adds a whole new level of complexity to things, so good luck tracking that lot down!!
Also, maybe you're using Freelists and Freelist groups rather than ASSM, so perhaps you're fighting for access to the freelist with whatever else is happening on your database at the time...
You get the idea: this could be a result of activity taking place on the server for reasons completely unconnected with your insert. It could be a feature of Spatial (with which not many people will be familiar, so good luck if so!) It could be a result of the way your RAC is configured. It could be any number of things... but I'd be willing to bet quite a bit that it's got sod-all to do with the clustering factor!
You'll need to monitor the insert using a tool like Insider or Toad so you can see if waits and so on happen, more or less in real time -or start using the built-in tools like Statspack or AWR to analyze your workload after it's completed- to work out what your best fix is likely to be.

Leaf blocks,blevel,clustering factor

Similar Messages

Maybe you are looking for