How to minimize index size?

hi,
We current face a problem: the size of the index.
In our case, one transaction record has about 10 fields. The total size of a transaction is about 110 bytes. (We did implement "ExternalizableLite" interface.
The key for the transaction is a Long object.
And we need to put 7 indices against those transactions. The data type we are putting indices on are:
long, String, int, int, String, int, long.
We found out: Putting 0.43 million records into the cache without index, the JVM costs < 300M memory. But it costs 800M memory with index. So around 500M memory is spent on the index. That's very expensive. I guess the items in index data structure are stored as java Objects. Am I right?
Is there anyway to optimize the index so that it will take smaller space?
Thank you very much!
Yan

Yan,
For each index we maintain two additional maps (instances of java.util.HashMap) - one for a reverse index and one for a forward index. The reverse index size is a cardinal number for the value (size of the value domain). The forward index size is of the key set size.
Extra memory cost for the HashMap itself is about 30 bytes. Extra cost for each extracted indexed value is 12 (the object reference size) plus the size for the value itself. For example, the extra size for Long value is 20 (12+8) and for a String is 12 + the string length. There is also an additional reference (12 bytes) cost for indexes with a large cardinal number and a small additional cost (about 4 bytes) for sorted indexes.
With this in mind you can calculate an approximate index cost. For an indexed long value of large cardinal it's going to be about 80 bytes (30 + 30 + 20). For an indexed string of an average length of 20 chars it's going to be about 112 (30 + 30 + 12 + 20*2).
To summarize, the index cost is relatively high for small objects, but it's constant and becomes less and less expensive for larger objects.
Since the index is evenly distributed across the cluster, (and memory is cheap :-) adding an extra storage enabled node is a very easy way out.
Regards,
Gene

Similar Messages

Pdf file is too big (7MB). Need a pdf file with max size 4MB. How to minimize the size of a pdf file?

pdf file is too big (7MB). Need a pdf file with max size 4MB. How to minimize the size of a pdf file?

The other alternative is the Save As Other>Reduce File Size. The PDF Optimizer gives you more control. You might also use the audit feature in the PDF Optimizer to see where the size problem is coming from. You might find that in the WORD file you can select and image and then go to the FORMAT (pictures) menu and select compress for all of the bitmaps in the file. That will typically use 150 dpi by default that is adequate for most needs.

HOW to Minimize Screen Size in Screen Painter

HI all,
I am developing one module pol program for material transfer.
in that i have to develop one screen like dialog box not like normal screen on which i want to display error.
and after cliking the push button on it i will see the normal screen.
how can i show screen as dialog box. or how to minimize the screen size to look like dialog box.
please do the need ful.
points will be rewarded.
thanks
vinod

hi
good
While calling you will use like this..
Calling a single screen is a special case of embedding a screen sequence. If you want to prevent the called screen from covering the current screen completely, you can use the CALL SCREEN statement with the STARTING AT and ENDING AT options:
CALL SCREEN <scrn>
STARTING AT <X1> <Y1>
ENDING AT <X2> <Y2>.
This calls the screen number <scrn> as a modal dialog box. When the screen is displayed, the screen that had called it is visible but inactive. The STARTING AT and ENDING AT additions specify the top left-hand and bottom right-hand corners of the dialog box respectively. In the screen attributes of screen <scrn>, you must set the Modal dialog box attribute. This defines how the interface elements are positioned on the screen.
thanks
mrutyun^

Reports - Image resolution : How to minimize file size of exported report?

Our reports are currently using high quality images which makes the file size bigger. Is there any way to reduce the exported report's file size?
Please provide us the way to use lower quality images in reports to minimize the file size.
NOTE: In these reports we are embedding the images (with ".jpg" format) programatically at runtime. Also we are using Crystal Reports XI (Product Version 11.5.0.313) with .Net 1.1 framework.

Using an image program like Photoshop or Paint Shop Pro you need to reduce the number of colors and DPI while maintaining as much of the clarity as possible.
Here's what steps will help.
Open the image you want to change.
Check the 'Count of Colors used' in the tool you're using. If more than 256 (8 bit) you'll not be able to do much to reduce colors, but most likely the image has a palette of 17.6 million colors (24 bit)
If a color image, try reducing to 8bit, 10bit or 12bit. If a b&w change it to grey scale and reduce. Some forms can be reduced to 16 (4 bit).
Next, check the DPI, usually in the 'image information' tool. If it's more than 200 try reducing to 200.
Save the image in BMP format with RLE compress if possible. Look at it in the image tool to see if it has held up.
We recently pulled 11 pages from a PDF to PNG, changed them to greyscale BMP at 4bit 200DPI and it reduced the RPT file size from 317000k to 2000k.

How to minimize the size of JButton?

how can i determine the size of a JButton? the default size of a JButton on the frame is too big.

The default size of a button is determined by the lenth of the text in the button and a margin. You can remove the margin:
button.setMargin( new Insets(0, 0, 0, 0) );

How to decrease the size of the JS and CSS File

Hi experts,
I m facing a bandwidth problem because i m accessing an application from a PDA and i noticed that it takes a very long time to load a very simple page. After some investigation, i noticed that its because the JS and CSS files downloaded are rather big.
sapUrMapi_ie6.js (Size: 301 KB)
sapWdSsr_ie6.js (Size: 79 KB)
ur_ie6.css (Size: 247KB).
Any idea how to minimize the size of these files or any workaround as to this problem ?
Your help will be much appreciated.
Regards,
Daniel

Hi,
Check this link this may be helpful to you
http://help.sap.com/saphelp_nw04/helpdata/en/b5/7e1141e109ef6fe10000000a1550b0/frameset.htm
Regards,
SURYA

Command for "How to find Cursor Size" in Oracle Stored Procedure"

Hi
Can u tell me....
How to find Cursor Size" in Oracle Stored Procedure........
I want command for that........

why don't you try select count(*) from your_table;That requires running the same query twice - or rather running two different queries twice. Besides it still doesn't guarantee anything, because Oracle's read consistency model only applies at the statement level (unless you're running in a serialized transaction).
This is such a common requirement - users are wont to say "well Google does it" - it seems bizarre that Oracle cannot do it. The truth is that that Google cheats. Firstly it guesses the number on the basis of information in its indexes and refines the estimate as pages are returned. Secondly, Google is under no onus to kepp all its data and indexes synchronized - two simultaneous and identical queries which touch different Google servers can return different results. Oracle Text works the same way, which is why we can get a count with CTX_QUERY.COUNT_HITS in estimate mode.
Cheers, APC
blog: http://radiofreetooting.blogspot.com
.

Report to find all table and index sizes

Hi all,
Good day..
Is there any report.sql or so to find out the sizes of all the tables and indexes in a database.
thanks,
baskar.l

1.To get table size
What will be the table size if?
<or>
break on report
set line 200
COMPUTE SUM LABEL "Total Reclaimable Space" OF "KB Free Space" ON REPORT
column "Table Size" Format a20
column "Actual Data Size" Format a20
column "KB Free Space" Format "9,99,999.99"
select table_name,
round((blocks*8),2)||'kb' "Table size",
round((num_rows*avg_row_len/1024),2)||'kb' "Actual Data size",
pct_free,
round((blocks*8),2) - (round((blocks*8),2)*pct_free/100) - (round((num_rows*avg_row_len/1024),2)) "KB Free Space"
from user_tables
where round((blocks*8),2) - (round((blocks*8),2)*pct_free/100) - (round((num_rows*avg_row_len/1024),2)) > 0
order by round((blocks*8),2) - (round((blocks*8),2)*pct_free/100) - (round((num_rows*avg_row_len/1024),2)) desc
2.To get index size
How to size the Index
Hth
Girish Sharma

How to control the size of live data in Coherence?

How to control the size of live data in Coherence?
See the following statement:
Pause times increase as the amount of live data in the heap increases. We recommend not exceeding 70% live data in your heap. This includes primary data, backup data, indexes, and application data.
--Excerpted from http://coherence.oracle.com/display/COH35UG/Best+Practices

In any Java program, it is good practice to make sure your live objects leave some room in the heap for "scratch space." Without this, you will spend too much time in GC, and, in the worst cases, run out of memory. In the general case, you can see how much live data your application requires by looking at the heap used after a full GC's. For Coherence, you should ensure that live data, as you say, is under 70% of the maximum heap size.
Coherence provides you tools to help enforce this policy. [http://coherence.oracle.com/display/COH35UG/local-scheme] describes how to size limit your cache. By implementing an eviction policy, you can control what happens when a size limit is exceeded.

How to utilize index in selection statement

hi
how to utilize index in selection statement and how is it reduces performance whether another alternative is there to reduce performance .
thanks

Hi Suresh,
For each SQL statement, the database optimizer determines the strategy for accessing data records. Access can be with database indexes (index access), or without database indexes (full table scan).The cost-based database optimizer determines the access strategy on the basis of:
*Conditions in the WHERE clause of the SQL statement
*Database indexes of the table(s) affected
*Selectivity of the table fields contained in the database indexes
*Size of the table(s) affected
*The table and index statistics supply information about the selectivity of table fields, the selectivity of combinations of table fields, and table size. Before a database access is performed, the database optimizer cannot calculate the exact cost of a database access. It uses the information described above to estimate the cost of the database access.The optimization calculation is the amount by which the data blocks to be read (logical read accesses) can be reduced. Data blocks show the level of detail in which data is written to the hard disk or read from the hard disk.
Inroduction to Database Indexes
When you create a database table in the ABAP Dictionary, you must specify the combination of fields that enable an entry within the table to be clearly identified. Position these fields at the top of the table field list, and define them as key fields.
After activating the table, an index is created (for Oracle, Informix, DB2) that consists of all key fields. This index is called a primary index. The primary index is unique by definition. As well as the primary index, you can define one or more secondary indexes for a table in the ABAP Dictionary, and create them on the database. Secondary indexes can be unique or non-unique. Index records and table records are organized in data blocks.
If you dispatch an SQL statement from an ABAP program to the database, the program searches for the data records requested either in the database table itself (full table scan) or by using an index (index unique scan or index range scan). If all fields requested are found in the index using an index scan, the table records do not need to be accessed.
A data block shows the level of detail in which data is written to the hard disk or read from the hard disk. Data blocks may contain multiple data records, but a single data record may be spread across several data blocks.
Data blocks can be index blocks or table blocks. The database organizes the index blocks in the form of a multi-level B* tree. There is a single index block at root level, which contains pointers to the index blocks at branch level. The branch blocks contain either some of the index fields and pointers to index blocks at leaf level, or all index fields and a pointer to the table records organized in table blocks. The index blocks at leaf level contain all index fields and pointers to the table records from the table blocks.
The pointer that identifies one or more table records has a specific name. It is called, for example, ROWID for Oracle databases. The ROWID consists of the number of the database file, the number of the table block, and the row number within the table block.
The index records are stored in the index tree and sorted according to index field. This enables accelerated access using the index. The table records in the table blocks are not sorted.
An index should not consist of too many fields. Having a few very selective fields increases the chance of reusability, and reduces the chance of the database optimizer selecting an unsuitable access path.
Index Unique Scan
If, for all fields in a unique index (primary index or unique secondary index), WHERE conditions are specified with '=' in the WHERE clause, the database optimizer selects the access strategy index unique scan.
For the index unique scan access strategy, the database usually needs to read a maximum of four data blocks (three index blocks and one table block) to access the table record.
select * from VVBAK here vbeln = '00123' ......end select.
In the SELECT statement shown above, the table VVBAK is accessed. The fields MANDT and VBELN form the primary key, and are specified with '=' in the WHERE clause. The database optimizer therefore selects the index unique scan access strategy, and only needs to read four data blocks to find the table record requested.
Index Range Scan
select * from VVBAP here vbeln = '00123' ......end select.
In the example above, not all fields in the primary index of the table VVBAP (key fields MANDT, VBELN, POSNR) are specified with '=' in the WHERE clause. The database optimizer checks a range of index records and deduces the table records from these index records. This access strategy is called an index range scan.
To execute the SQL statement, the DBMS first reads a root block (1) and a branch block (2). The branch block contains pointers to two leaf blocks (3 and 4). In order to find the index records that fulfill the criteria in the WHERE clause of the SQL statement, the DBMS searches through these leaf blocks sequentially. The index records found point to the table records within the table blocks (5 and 6).
If index records from different index blocks point to the same table block, this table block must be read more than once. In the example above, an index record from index block 3 and an index record from index block 4 point to table records in table block 5. This table block must therefore be read twice. In total, seven data blocks (four index blocks and three table blocks) are read.
The index search string is determined by the concatenation of the WHERE conditions for the fields contained in the index. To ensure that as few index blocks as possible are checked, the index search string should be specified starting from the left, without placeholders ('_' or %). Because the index is stored and sorted according to the index fields, a connected range of index records can be checked, and fewer index blocks need to be read.
All index blocks and table blocks read during an index range scan are stored in the data buffer at the top of a LRU (least recently used) list. This can lead to many other data blocks being forced out of the data buffer. Consequently, more physical read accesses become necessary when other SQL statements are executed
DB Indexex :Concatenation
In the concatenation access strategy, one index is reused. Therefore, various index search strings also exist. An index unique scan or an index range scan can be performed for the various index search strings. Duplicate entries in the results set are filtered out when the search results are concatenated.
Select * from vvbap where vbeln in ('00123', '00133', '00134').
endselect.
In the SQL statement above, a WHERE condition with an IN operation is specified over field VBELN. The fields MANDT and VBELN are shown on the left of the primary index. Various index search strings are created, and an index range scan is performed over the primary index for each index search string. Finally, the result is concatenated.
Full Table Scan
select * from vvbap where matnr = '00015'.
endselect
If the database optimizer selects the full table scan access strategy, the table is read sequentially. Index blocks do not need to be read.
For a full table scan, the read table blocks are added to the end of an LRU list. Therefore, no data blocks are forced out of the data buffer. As a result, in order to process a full table scan, comparatively little memory space is required within the data buffer.
The full table scan access strategy is very effective if a large part of a table (for example, 5% of all table records) needs to be read. In the example above, a full table scan is more efficient than access using the primary index.
In Brief
Index unique scan: The index selected is unique (primary index or unique secondary index) and fully specified. One or no table record is returned. This type of access is very effective, because a maximum of four data blocks needs to be read.
Index range scan: The index selected is unique or non-unique. For a non-unique index, this means that not all index fields are specified in the WHERE clause. A range of the index is read and checked. An index range scan may not be as effective as a full table scan. The table records returned can range from none to all.
Full table scan: The whole table is read sequentially. Each table block is read once. Since no index is used, no index blocks are read. The table records returned can range from none to all.
Concatenation: An index is used more than once. Various areas of the index are read and checked. To ensure that the application receives each table record only once, the search results are concatenated to eliminate duplicate entries. The table records returned can range from none to all.
Regards,
Balaji Reddy G
***Rewards if answers are helpful

How to reorganization index in new tablespace

How to reorganization index in new tablespace? for size? for? number of extents? or both?

What's Oracle version?
Why you want to reorg your index?
You could rebuild your index
alter index <index_name> rebuild tablespace <tablespace_name>check Jonathan's note regarding index rebuild,
http://jonathanlewis.wordpress.com/2008/02/09/index-rebuild-10g/

Getting same index size despite different table size

Hello,
this question arose from a different thread, but touches a different problem, which is why I have decided to post it as a separate thread.
I have several tables of 3D points.
The points roughly describe the same area but in different densities, which means the tables are of different sizes. The smallest contains around 3million entries and the largest around 37 million entries.
I applied an index with
CREATE INDEX <index name>
ON <table name>(<column name>)
INDEXTYPE is MDSYS.SPATIAL_INDEX
PARAMETERS('sdo_indx_dims=3');
My problem is that I am trying to see how much space the index occupies for each table.
I used the following syntax to get the answer to this:
SELECT usim.sdo_index_name segment_name, bytes/1024/1024 segment_size_mb
FROM user_segments us, user_sdo_index_metadata usim
WHERE usim.SDO_INDEX_NAME = <spatial index name>
AND us.segment_name = usim.SDO_INDEX_TABLE;
(thanks Reggie for supplying the sql)
Now, the curious thing is that in all cases, I get the answer
SEGMENT_NAME SEGMENT_SIZE_MB
LIDAR_POINTS109_IDX .0625
(obviously with a different sement name in each case).
I tried to see what an estimated index size would be with
SDO_TUNE.ESTIMATE_RTREE_INDEX_SIZE
And I get estimates ranging from 230MB in the case of 3million records up to 2.9 for the case of 37million records.
Does anyone have an idea why I am not getting a different actual index size for the different tables?
Any help is greatly appreciated!!!
Cheers,
F.

It looks like your indexes didn't actually create properly. Spatial indexes are a bit different to 'normal' indexes in this regard. A BTree index will either create or not. However, when creating a spatial index, something may fail, but the index structure will remain and it will appear to be valid according to the data dictionary.
Consider the following example in which the SRID has a problem:
SQL> CREATE TABLE INDEX_TEST (
2 ID NUMBER PRIMARY KEY,
3 GEOMETRY SDO_GEOMETRY);
Table created.
SQL>
SQL> INSERT INTO INDEX_TEST (ID, GEOMETRY) VALUES (1,
2 SDO_GEOMETRY(2001, 99999, SDO_POINT_TYPE(569278.141, 836920.735, NULL), NULL, NULL)
3
SQL> INSERT INTO user_sdo_geom_metadata VALUES ('INDEX_TEST','GEOMETRY',
2 MDSYS.SDO_DIM_ARRAY(
3 MDSYS.SDO_DIM_ELEMENT('X',0, 1000, 0.0005),
4 MDSYS.SDO_DIM_ELEMENT('Y',0, 1000, 0.0005)
5 ), 88888);
1 row created.
SQL>
SQL> CREATE INDEX INDEX_TEST_SPIND ON INDEX_TEST(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX INDEX_TEST_SPIND ON INDEX_TEST(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: SRID 88888 does not exist in MDSYS.CS_SRS table
ORA-29400: data cartridge error
Error - OCI_NODATA
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
SQL> SELECT usim.sdo_index_name segment_name, bytes/1024/1024 segment_size_mb,
2 usim.sdo_index_status
2 FROM user_segments us, user_sdo_index_metadata usim
3 WHERE usim.SDO_INDEX_NAME = 'INDEX_TEST_SPIND'
4 AND us.segment_name = usim.SDO_INDEX_TABLE;
SEGMENT_NAME SEGMENT_SIZE_MB SDO_INDEX_STATUS
INDEX_TEST_SPIND .0625 VALID
1 row selected.
SQL>When you ran the CREATE INDEX statement did it say "Index created." afterwards or did you get an error?
Did you run the CREATE INDEX statement in SQL*Plus yourself or was it run by some software?
I suggest you drop the indexes and try creating them again. Watch out for any errors. Chances are its an SRID issue.

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

Index size increases than table size

Hi All,
Let me know what are the possible reasons for index size greater than the table size and in some cases index size smaller than table size . ASAP
Thanks in advance
sherief

hi,
The size of a index depends how inserts and deletes occur.
With sequential indexes, when records are deleted randomly the space will not be reused as all inserts are in the leading leaf block.
When all the records in a leaf blocks have been deleted then leaf block is freed (put on index freelist) for reuse reducing the overall percentage of free space.
This means that if you are deleting aged sequence records at the same rate as you are inserting, then the number of leaf blocks will stay approx constant with a constant low percentage of free space. In this case it is most probably hardly ever worth rebuilding the index.
With records being deleted randomly then, the inefficiency of the index depends on how the index is used.
If numerous full index (or range) scans are being done then it should be re-built to reduce the leaf blocks read. This should be done before it significantly affects the performance of the system.
If index access’s are being done then it only needs to be rebuilt to stop the branch depth increasing or to recover the unused space
here is a exemple how index size can become larger than table size:
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as admin
SQL> create table rich as select rownum c1,'Verde' c2 from all_objects;
Table created
SQL> create index rich_i on rich(c1);
Index created
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1179648 144 9
INDEX 1179648 144 9
SQL> delete from rich where mod(c1,2)=0;
29475 rows deleted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1179648 144 9
INDEX 1179648 144 9
SQL> insert into rich select rownum+100000, 'qq' from all_objects;
58952 rows inserted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1703936 208 13
INDEX 2097152 256 16
SQL> insert into rich select rownum+200000, 'aa' from all_objects;
58952 rows inserted
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 2752512 336 21
INDEX 3014656 368 23
SQL> delete from rich where mod(c1,2)=0;
58952 rows deleted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 2752512 336 21
INDEX 3014656 368 23
SQL> insert into rich select rownum+300000, 'hh' from all_objects;
58952 rows inserted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 3014656 368 23
INDEX 4063232 496 31
SQL> alter index rich_i rebuild;
Index altered
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 3014656 368 23
INDEX 2752512 336 21
SQL>

Index size per table

Oracle 11.1.7.0
We have partitioned, non-partitioned indexes.
1. Is there a way to find index size per table. As break down by table and index name how much each index is taking and where space is being used.
2. Also, Is there a way to find free space within an allocated index?
Edited by: user628400 on Nov 26, 2009 12:13 PM

Hello,
To collect statistics about indexes you must VALIDATE it first then put the datas
into a Table.
So this is the way I use:
1. Create a Table to collect the datas:
create table my_index_stats (
index_name varchar2(30),
height number(8),
del_lf_rows number(8),
distinct_keys number(8),
rows_per_key number(10,2),
blks_gets_per_access number(10,2),
btree_space number(12,0),
used_space number(12,0),
pct_used number(12,0)
/2. Validate the Index
validate index "<schema>"."<index_name>";3. Collect the datas
insert into my_index_stats
select NAME, HEIGHT, DEL_LF_ROWS, DISTINCT_KEYS, ROWS_PER_KEY,
BLKS_GETS_PER_ACCESS, BTREE_SPACE, USED_SPACE, PCT_USED
from INDEX_STATS;
commit;Then, you query the Table MY_INDEX_STATS and the USED_SPACE gives you an idea (in Bytes) of the space used inside the index.
The BTREE_SPACE gives you the size of the Index.
So from BTREE_SPACE and USED_SPACE you can know the wastage space of your Index.
Hope it can help,
Best regards
Jean-Valentin
Edited by: Lubiez Jean-Valentin on Nov 26, 2009 10:02 PM

How to minimize index size?

Similar Messages

Maybe you are looking for