Index size greated then Table Size

Hi all,
We are running BI7.0 in our environment.
One of the tables' index size is much greated than the table itself. The Details are listed below:
Table Name: RSBERRORLOG
Total Table Size: 141,795,392 KB
Total Index Size: 299,300,576 KB
Index:
F5: Index Size / Allocated Size: 50%
Is there any reason that the index should grow more than Table? If so, would Reorganizing index help and if this can be controlled?
Please letme know on this as I am not very clear on DB much.
Thanks and Regards,
Raghavan

Hi Hari
Its basically degenerated index. You can follow the below steps
1. Delete some entries from RSBERRORLOG.
BI database growing at 1 Gb per day while no data update on ECC
2. Re-organize this table from BRSPACE . Now the size of the table would be very less. I do not remember if this table has a LONG RAW field ( in that case export /import) of this table would be required. ---Basis job
3. Delete and recreate Index on this table
You will gain lot of space.
I assumed you are on Oracle.
More information on reoganization is LINK: [Reorg|TABLE SPACE REORGANIZATION !! QUICK EXPERT INPUTS;
Anindya
Regards
Anindya

Similar Messages

Index size greater than table size

HI ,
While checking the large segments , I came to know that index HZ_PARAM_TAB_N1 is larger than table HZ_PARAM_TAB . I think it's highly fragmented and requires defragmentation . Need your suggestion on the same that how can I collect more information on the same . Providing you more information .
1.
select sum(bytes)/1024/1024/1024,segment_name from dba_segments group by segment_name having sum(bytes)/1024/1024/1024 > 1 order by 1 desc;
SUM(BYTES)/1024/1024/1024 SEGMENT_NAME
81.2941895 HZ_PARAM_TAB_N1
72.1064453 SYS_LOB0000066009C00004$$
52.7703857 HZ_PARAM_TAB
2. Index code
<pre>
COLUMN_NAME COLUMN_POSITION
ITEM_KEY 1
PARAM_NAME 2
</pre>
Regards
Rahul

Hi ,
Thanks . I know that rebuild will defragment it . But as I'm on my new site , I was looking for some more supporting information before drafting the mail on the same that it requires re org activity .It's not possible for an index to have the size greater than tables as it contains only 2 columns values + rowid . Whereas tables contains 6 columns .
<pre>
Name      Datatype      Length      Mandatory      Comments
ITEM_KEY      VARCHAR2      (240)      Yes      Unique identifier for the event raised
PARAM_NAME      VARCHAR2      (2000)      Yes      Name of the parameter
PARAM_CHAR      VARCHAR2      (4000)
     Value of the parameter only if its data type is VARCHAR2.
PARAM_NUM      NUMBER
     Value of the parameter only if its data type is NUM.
PARAM_DATE      DATE
     Value of the parameter only if its data type is DATE.
PARAM_INDICATOR      VARCHAR2      (3)      Yes      Indicates if the parameter contains existing, new or >replacement values. OLD values currently exist. NEW values create initial values or replace existing values.</pre>
Regds
Rahul

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>

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.

Indexes, Clusters, Views and Table Size

Hi
Anyone can kindly tell me how to check the size of tables,
indexs, cluster and views? what are the commands to check the
size? Thank you so much!
Xiong

I believe you just need to query
user_segments,dba_segments,all_segments, Whichever you have
access to.
SELECT segment_name,segment_type,bytes/1024 "KB",extents
FROM
user_segments
where segment_type in ('TABLE','INDEX','CLUSTER');
I don't think views take up any storage aside from their
definition in the Data Dictionary. Views are Logical.

Lightroom 1.1 export size different then import size

Just recevied lightroom 1.1. My camera a D200 puts out a 10x7 image and when export to photoshop the size comes out to be 16x10 at 360 rez. Can you control the export size

You can control the size in the Export menu that pops up when you click on the export button or File > Export. Use the Image Settings section. Set the resolution and then "Constrain Maximum Size". Fill in both boxes with the same value (which allows for both vertical and horizontal images). LR will enlarge or reduce the size as required. For example, if you want an 8 x 10, you would put 10" into both of the Constain Maximum Size boxes.
John

Dump File Size vs Database Table Size

Hi all!
Hope you're all well. If Datapump estimates that 18 million records will produce a 2.5GB dumpfile, does this mean that 2.5GB will also be consumed on the database table when this dump file is imported into a database?
Many thanks in advance!
Regards
AC

does this mean that 2.5GB will also be consumed on the database table when this dump file is imported into a database?No since the size after import depends on various factors like block size, block storage parameters etc.

TABLE SIZE 및 INDEX SIZE(크기) 계산

제품 : ORACLE SERVER
작성날짜 : 2002-10-15
TABLE SIZE 및 INDEX SIZE(크기) 계산
===================================
1. TABLE SIZE 계산 공식(ORACLE BLOCK SIZE : 2K 로 가정)
$ sqlplus scott/tiger
SQL> SELECT GREATEST(4, ceil(ROW_COUNT /
((round(((1958 - (initrans * 23)) *
((100 - PCTFREE) /100)) / ADJ_ROW_SIZE)))) * BLOCK_SIZE)
TableSize_Kbytes
FROM dual;
*. 한 개의 BLOCK에 Available 한 Bytes - 1958
*. 각 initrans 는 23 Bytes
*. PCT_FREE : Table 의 pctfree 값(default 10)
*. ADJ_ROW_SIZE : 각 row 의 평균 SIZE 추정치
*. ROW_COUNT : table 의 row 의 갯수
*. BLOCK_SIZE : 1 block의 크기 (단위: K)
예) table 이름이 EMP 일 경우
ROW_COUNT : select count(*) from emp;
ADJ_ROW_SIZE :
analyze table emp compute statistics;
(또는 건수가 매우 많을 때에는 compute 대신 estimate 사용)
select avg_row_len
from user_tables
where table_name='EMP';
2. INDEX SIZE 계산 공식
SQL> SELECT GREATEST(4, (1.01) * ((ROW_COUNT /
((floor(((2048 - 113 - (initrans * 23)) *
(1 - (PCTFREE/100))) /
((10 + uniqueness) + number_col_index +
(total_col_length)))))) * DB_BLOCK_SIZE))
IndexSize_Kbytes
FROM dual;
*. 한 개의 block에 available 한 bytes ( 1935 or 2048 - 113 )
*. 각 initrans 는 23 Bytes
*. ROW_COUNT : table 의 row 의 갯수
*. PCTFREE : Index 의 pctfree 값(default 10)
*. number_col_index : Index 에서 column 의 수
*. total_col_length : Index 의 길이 추정치
*. uniqueness : 만일 unique index 이면 1, non-unique index 이면 0.
*. DB_BLOCK_SIZE : 1 block의 크기 (단위: K)

데이터블록 레이아웃을 보면..
Data Block Layout
Block header에는 cache layer와 Transaction layer을 가지고 있습니다.
Data layer에는 Table directory, Row directory, Free space, Row data
이렇게 나누어지구요..
v$type_size를 보면.. KCB와 KTB의 크기가 실제로 헤더의 크기입니다.
여기서는 92로 계산되었는데..
2048-92=1956 으로 나옵니다.
여기서의 값이 아닐지요? 2바이트가 차이나긴 하군요.;
COMPONENT TYPE DESCRIPTION TYPE_SIZE
KCB KCBH BLOCK COMMON HEADER 20
KTB KTBIT TRANSACTION VARIABLE HEADER 24
KTB KTBBH TRANSACTION FIXED HEADER 48

Problem with table size (initial extent)

Hi,
I have imported a table from my client's database, which shows the following size parameters as displayed from the user_segments table :-
bytes : 33628160
blocks : 4105
extents : 1
initial_extent : 33611776
next_extent : 65536
The number of rows in the table is 0 (zero). I am wondering how the table size could become so large, while other tables in the schema in the same tablespace have normal initial extent size.
I then created a tablespace with an initial and next extent of 64k each, and imported the data into the tablespace, after which the table size and the initial extent for the table remained to be 33611776. This is the problem with 4-5 other tables out of a total of 500 tables.
Of course if i drop and recreate the table, there is no problem, and the initial extent size and the table size becomes 64k, same as per the tablespace.
Any suggestions? I do not want to drop the tables and recreate them.
Because of this problem, even an attempt to import a blank database is consuming 2 GB of hard disk space.
Thanks in advance
DSG

I don't think you can stop the extent from being allocated when you import the table.
Even if you try to let the table inherit storage parameters from the tablespace, it will still allocate as many 64K extents as it needs to get to the 33M size in the table's (imported) storage parameter. I have also seen that when trying to change storage during an import like that, you can look in dba_tables and see the table has an ititial setting of 33M even though when you look in dba_segments you'll see that every extent allocated was in fact 64K. The dba_tables table is getting populated directly from the import and will therefore report the wrong number.
Perhaps you can import then create table as... to put the tables in a better storage set up. (Letting tables inherit from the tablespace is the best way to go...no fragmentation that way). You might want to get the client to let you revamp the storage since theres no good reason to have one huge extent like that.

SAP Table index size is greater than the size of the actual table

Hello Experts,
We are resolving an issue related to database performance. The present database size is 9 Terabytes. The analysis of response times through ST03N shows that the db time is 50% of the total response time. We are planning to reorganize the most updated tables (found from DB02old tx).
Here we see that the size of the index for a table is greater than the actual size of the table. Is this possible, if yes then how can we reorganize the index as it does not allow us to reorganize the index using brspace command.
Hope to hear from you soon, and if any additional activities you can suggest to improve the performance of the database will be appreciated.
Thank you

Hi Zaheer,
online redef may help you (for a little while) , but also check WHY the index became fragmented.
Improper settings can bring the index fragmented again and you have reoccuring reorg needs.
i.e.
check if PCT_INCREASE >0 if you are using Dictionary Managed Tablespaces or locally managed tablespaces that uses a "User" allocation policy. Set it to 0 to generate uniform next extents in the online reorg.
select
            SEGMENT_NAME,
            SEGMENT_TYPE,
            round((NEXT_EXTENT*BLOCKS)/(EXTENTS*BYTES))*(BYTES/BLOCKS),
            PCT_INCREASE
        from
            DBA_SEGMENTS
        where
            OWNER='SAPR3'
        and
            SEGMENT_TYPE in ('INDEX',
                            'TABLE')
        and
            PCT_INCREASE > 0
        and segment_name in ('Yourtable','Yourindex')
In the following cases, it may be worthwhile to rebuild the index:
     --> the percentage of the space used is bad - lower than 66%: PCT_USED
     --> deleted leaf blocks represent more than 20% of total leaf blocks: DEL_LF_ROWS
     --> the height of the tree is bigger than 3: HEIGHT or BLEVEL
select
name,
'----------------------------------------------------------'    headsep,
'height               '||to_char(height,     '999,999,990')     height,
'blocks               '||to_char(blocks,     '999,999,990')     blocks,
'del_lf_rows          '||to_char(del_lf_rows,'999,999,990')     del_lf_rows,
'del_lf_rows_len      '||to_char(del_lf_rows_len,'999,999,990') del_lf_rows_len,
'distinct_keys        '||to_char(distinct_keys,'999,999,990')   distinct_keys,
'most_repeated_key    '||to_char(most_repeated_key,'999,999,990') most_repeated_key,
'btree_space          '||to_char(btree_space,'999,999,990')       btree_space,
'used_space           '||to_char(used_space,'999,999,990')        used_space,
'pct_used                     '||to_char(pct_used,'990')          pct_used,
'rows_per_key         '||to_char(rows_per_key,'999,999,990')      rows_per_key,
'blks_gets_per_access '||to_char(blks_gets_per_access,'999,999,990') blks_gets_per_access,
'lf_rows      '||to_char(lf_rows,    '999,999,990')||'        '||+
'br_rows      '||to_char(br_rows,    '999,999,990')                  br_rows,
'lf_blks      '||to_char(lf_blks,    '999,999,990')||'        '||+
'br_blks      '||to_char(br_blks,    '999,999,990')                  br_blks,
'lf_rows_len '||to_char(lf_rows_len,'999,999,990')||'        '||+
'br_rows_len '||to_char(br_rows_len,'999,999,990')                  br_rows_len,
'lf_blk_len   '||to_char(lf_blk_len, '999,999,990')||'        '||+
'br_blk_len   '||to_char(br_blk_len, '999,999,990')                br_blk_len
from
index_stats where index_name = 'yourindex'
bye
yk

Index size 3 times more then table

table cnmas
record 134 only
but there is lot of dml operation on this table
SQL> SELECT COUNT(*) FROM CNMAS;
COUNT(*)
134
1* SELECT SUM(BYTES)/1024/1024 FROM USER_SEGMENTS WHERE SEGMENT_NAME='CNMAS'
SQL> /
SUM(BYTES)/1024/1024
4
1* SELECT SUM(BYTES)/1024/1024 FROM USER_SEGMENTS WHERE SEGMENT_NAME='PK_CNMAS_CN_DOC_NO'
SQL> /
SUM(BYTES)/1024/1024
12
table have 134 record
table size 4 m.b
index size 12 m.b
whats the REASON?????????????
thanks
kuljeet pal singh

INDEX DETAILS
SELECT INI_TRANS,MAX_TRANS,INITIAL_EXTENT,NEXT_EXTENT,MIN_EXTENTS,MAX_EXTENTS,PCT_INCREASE FROM USER_INDEXES WHERE INDEX_NAME='PK_CNMAS_CN_DOC_NO';
INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
2 255 10485760 4194304 1 2147483645 0
TABLE DETAILS
SQL> SELECT PCT_FREE,PCT_USED,INI_TRANS,MAX_TRANS,INITIAL_EXTENT,NEXT_EXTENT,MIN_EXTENTS,MAX_EXTENTS,PCT_INCREASE FROM USER_TABLES WHERE TABLE_NAME='CNMAS';
PCT_FREE PCT_USED INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
10 40 1 255 532480 4194304 1 2147483645 0

Index size keep growing while table size unchanged

Hi Guys,
I've got some simple and standard b-tree indexes that keep on acquiring new extents (e.g. 4MB per week) while the base table size kept unchanged for years.
The base tables are some working tables with DML operation and nearly same number of records daily.
I've analysed the schema in the test environment.
Those indexes do not fulfil the criteria for rebuild as follows,
- deleted entries represent 20% or more of the current entries
- the index depth is more then 4 levels
May I know what cause the index size keep growing and will the size of the index reduced after rebuild?
Grateful if someone can give me some advice.
Thanks a lot.
Best regards,
Timmy

Please read the documentation. COALESCE is available in 9.2.
Here is a demo for coalesce in 10G.
YAS@10G>truncate table t;
Table truncated.
YAS@10G>select segment_name,bytes from user_segments where segment_name in ('T','TIND');
SEGMENT_NAME              BYTES
T                         65536
TIND                      65536
YAS@10G>insert into t select level from dual connect by level<=10000;
10000 rows created.
YAS@10G>commit;
Commit complete.
YAS@10G>
YAS@10G>select segment_name,bytes from user_segments where segment_name in ('T','TIND');
SEGMENT_NAME              BYTES
T                        196608
TIND                     196608We have 10,000 rows now. Let's delete half of them and insert another 5,000 rows with higher keys.
YAS@10G>delete from t where mod(id,2)=0;
5000 rows deleted.
YAS@10G>commit;
Commit complete.
YAS@10G>insert into t select level+10000 from dual connect by level<=5000;
5000 rows created.
YAS@10G>commit;
Commit complete.
YAS@10G>select segment_name,bytes from user_segments where segment_name in ('T','TIND');
SEGMENT_NAME              BYTES
T                        196608
TIND                     327680Table size is the same but the index size got bigger.
YAS@10G>exec show_space('TIND',user,'INDEX');
Unformatted Blocks .....................               0
FS1 Blocks (0-25) .....................               0
FS2 Blocks (25-50) .....................               6
FS3 Blocks (50-75) .....................               0
FS4 Blocks (75-100).....................               0
Full Blocks        .....................              29
Total Blocks............................              40
Total Bytes.............................         327,680
Total MBytes............................               0
Unused Blocks...........................               0
Unused Bytes............................               0
Last Used Ext FileId....................               4
Last Used Ext BlockId...................          37,001
Last Used Block.........................               8
PL/SQL procedure successfully completed.We have 29 full blocks. Let's coalesce.
YAS@10G>alter index tind coalesce;
Index altered.
YAS@10G>select segment_name,bytes from user_segments where segment_name in ('T','TIND');
SEGMENT_NAME              BYTES
T                        196608
TIND                     327680
YAS@10G>exec show_space('TIND',user,'INDEX');
Unformatted Blocks .....................               0
FS1 Blocks (0-25) .....................               0
FS2 Blocks (25-50) .....................              13
FS3 Blocks (50-75) .....................               0
FS4 Blocks (75-100).....................               0
Full Blocks        .....................              22
Total Blocks............................              40
Total Bytes.............................         327,680
Total MBytes............................               0
Unused Blocks...........................               0
Unused Bytes............................               0
Last Used Ext FileId....................               4
Last Used Ext BlockId...................          37,001
Last Used Block.........................               8
PL/SQL procedure successfully completed.The index size is still the same but now we have 22 full and 13 empty blocks.
Insert another 5000 rows with higher key values.
YAS@10G>insert into t select level+15000 from dual connect by level<=5000;
5000 rows created.
YAS@10G>commit;
Commit complete.
YAS@10G>select segment_name,bytes from user_segments where segment_name in ('T','TIND');
SEGMENT_NAME              BYTES
T                        262144
TIND                     327680Now the index did not get bigger because it could use the free blocks for the new rows.

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

Size of schema / table / index

Hi,
Is there some direct queries or DBA views to find the following
1. current size of a particular schema
2. used, max, free size of a particular schema
3. size of each index in a schema
4. size of each table in a schema
TIA
regards,
Prakash

Alok,
dba_free_space doesn't give any clue at the schema level.
Prakash,
1. sum(bytes) from dba_segments where owner='YOURUSER'
2. not clear for me what do you want here.
3. user_segments (or dba|all_segments with owner) and segment_type like 'INDEX%'
4. user_segments (or dba|all_segments with owner) and segment_type like 'TABLE%'
Nicolas.

Index size bigger than table name? why?

I have a table student_enrollwment_item_tbl with primary key "pk_stu_enroll_item" - STU_ENROLL_ID, TASK_ID, PART_ID, ITEM_ID.
Table structure is as following:
Name Null? Type
STU_ENROLL_ID NOT NULL NUMBER
ITEM_ID NOT NULL VARCHAR2(15)
PART_ID NOT NULL NUMBER(2)
TASK_ID NOT NULL VARCHAR2(10)
QUESTION_NO NOT NULL VARCHAR2(25)
FLASH_NO NOT NULL NUMBER(3)
ITEM_NO NUMBER(3)
The table is 1856 MB in size, while the index is 2730 MB in size. I am surprised since 'size of index > size of table'. Why will it happen?

1) As seen from the result of the following sql, the PCT_FREE is 10. It's not bad.
select index_name, table_name, ini_trans, max_trans, initial_extent, min_extents, max_extents,
freelists, freelist_groups, pct_free, leaf_blocks from all_indexes
where table_name = 'STUDENT_ENROLLMENT_ITEM_TBL';
INDEX_NAME TABLE_NAME INI_TRANS MAX_TRANS INITIAL_EXTENT MIN_EXTENTS MAX_EXTENTS FREELISTS FREELIST_GROUPS PCT_FREE LEAF_BLOCKS
pk_stu_enroll_item STUDENT_ENROLLMENT_ITEM_TBL 2 255 379125760 1 2147483645 1 1 10 323428
2) The pattern is like this:
I regards it as being not sequential, but with a lot of distinct values.
STU_ENROLL_ID ITEM_ID PART_ID TASK_ID QUESTION_NO FLASH_NO ITEM_NO
10005085 C31001008 1 C310010 8 9 8
10005085 C31001009 1 C310010 9 10 9
10005085 C31001010 1 C310010 10 11 10
10005086 0 0 C310010 0 0 0
10005086 0 1 C310010 0 1 0
10005086 C31001001 1 C310010 1 2 1
10005086 C31001002 1 C310010 2 3 2
10005086 C31001003 1 C310010 3 4 3
10005086 C31001004 1 C310010 4 5 4
10005086 C31001005 1 C310010 5 6 5
10005086 C31001006 1 C310010 6 7 6
10005086 C31001007 1 C310010 7 8 7
10005086 C31001008 1 C310010 8 9 8
10005086 C31001009 1 C310010 9 10 9
10005086 C31001010 1 C310010 10 11 10
10005055 C31001005 1 C310010 5 6 5
10005055 C31001006 1 C310010 6 7 6
10005055 C31001007 1 C310010 7 8 7
10005055 C31001008 1 C310010 8 9 8
3) Not many deletes have been ran in the table as I know.
I still cannot figure out the reason. Please help. Thanks.

Index size greated then Table Size

Similar Messages

Maybe you are looking for