Index size

Hello!
I have found 'general purpose' info about estimated size of the text indexes. Where I find more info about size of each index segment ?
(ie: I_TABLE, K_TABLE, R_TABLE, N_TABLE, I_INDEX and P_TABLE).
Thanks,
Laszlo

0.035 (3.5%) is a starting point. If you have content sources outside the farm, if you've increased how much of a file is indexed, or if you're doing funny things with the partitions it usually works out to about 15%.
Jason Warren
@jaspnwarren
jasonwarren.ca
habaneroconsulting.com/Insights

Similar Messages

  • 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

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

  • 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 increased after import

    hi i mentioned already the index creation problem when i am trying to create index using script after import of table.So droped the table and created table using script and index also without data,then i started to import at tablelevel with indexes=n then ia m importing data from the production database.
    The size of the 2 indexes in production is 750 and 1200 mb each in test db both index size increased around double 1200 and 1700 mb each.I used same script in both db.Why this is increased here i took the export with compress=y full database export.Why the index size increased? when i created the index with initial extent and next extent size respective 800 and 100 mb.Whether is it the reason?
    with regards
    ramya

    i gave initial 1000 and next 100 for the index size around 1.1 gb in production but here in test why this became around 1.7 gb,eventhough the pct increase is 50 it should come around 1.3 maximum.Whether it will give any performance problem
    wiht regards
    ramya

  • Index Size Increase (Rebuild with Parallel)

    All,
    I'm not sure whether or not this is an Exadata problem, but we saw it happen on our Exadata machine (maybe the larger extents are impacting this). However, I thought this forum might have an idea, especially if it’s a generic RDBMS issue instead of an Exadata one
    I am running my Production EDW on an Exadata V2 quarter-rack running 11.2.0.2 BP7 RDBMS and GI and 11.2.2.3.2 ESS on OEL5.5
    We have started to implement HCC compression due to space pressure. Last Thursday/Friday, we attempted to compress our largest table:
    • 20bn rows, 3.7Tb in size, DEGREE 2, INSTANCE 1, 2555 partitions
    • 8 bitmap partitioned indexes each with DEGREE 20, INSTANCE 1. Total size AFTER the rebuild: 1.3Tb (significantly greater than before!!)
    • ‘Archive High’ HCC compression applied to the oldest 10% partitions (255).
    • Remaining partitions were left uncompressed.
    Because of the fact our biggest tables make use of bitmap indexes, in order for us to use HCC (which doesn’t like bitmaps), we had to:
    • Disable all bitmap indexes
    • Compress the oldest 10% of partitions with archive high HCC compression
    • Rebuild the indexes for these partitions (255 total, 8 bitmap indexes each)
    • Gather statistics
    • Rebuild the indexes for the rest of the partitions (the remaining 90%). This took BY FAR the longest time.
    During the last step, the index rebuilds seemed to take an excessive length of time – to rebuild all 8 bitmap indexes on one partition was about 3 minutes. This, obviously, had a big impact on the end users as this happens to be the table that most feeds hit (of course…!). We happened to run into the nightly batch too, which was as fantastic as you can probably imagine.
    On Monday, we noticed that the tablespace for the indexes had ballooned by about 800Gb and figured out that the culprit was mainly the table’s indexes. Some index partitions had increased up to 20x (the degree of parallelism used to rebuild the index). Further research shows that we have seen this for other tables with varying results (if an index had DEGREE 8, we might see it increase by 8 times, etc).
    We had the same issue in our Development environment as well. When we rebuilt the same indexes in Development (and Production) with no parallelism (DEGREE 1), we were able to rebuild 6 entire partitions (with 8 indexes each) in less than one minute: an 18x performance improvement. I suspect that the underlying table having DEGREE 2 allowed it to use the SmartScan, but still.
    Obviously, increasing the index size by 20x was not meant to be part of the HCC compression results. We’ve saved 3.1Tb in total with HCC, but we have increased the size of the indexes just on this one table alone by 1Tb! However, we also saw this happen on index partitions which had NOT been compressed by HCC – which seems to rule out HCC being a factor in this (probably?)
    We have seen this on another table which is partitioned with bitmap indexes. However, we only saw this increase in those indexes which had DEGREE >1. There were two other indexes on that table which were serial and saw NO increase in space usage.
    I don’t know whether we see this because of…
    • bitmap indexes
    • bitmap partitioned indexes
    • indexes on partitioned tables
    • tables which use SmartScan
    • HCC
    • Exadata
    • 11.2
    • Larry Ellison hates me and wants to make my life miserable by introducing random errors just to annoy me
    • All/any/none of the above
    This sounds like it’s a bug to me with the indexes being parallelized. Anyone else seen this happen?
    Any ideas, advice, jokes, cash appreciated...
    Mark

    The thing that makes me doubt it's related to the default partition size is that if we rebuild the indexes serially, the size is reduced by orders of magnitude. I do think it's somewhere in that ball park, though...
    I'm not sure if this isn't related to Exadata - the default extent size is 4Mb (and we haven't changed that). For eight bitmap indexes, that means the initially allocated extents (we don't defer) for just one partition total 32Mb.
    Yes, sorry, by 'ballooning by Monday morning', I was using some poetic license. The reason being that we actually lost a disk on the Thursday morning and replaced it on Thursday evening. Obviously, that masked the amount of usable space until the disk had re-balanced. The 'ballooning' has been definitively proven to be related to the degree of parallelism.
    Our plan is to create the indexes serially - after all, it doesn't appear that parallelism speeds up their rebuilds during the batch (which is why they were set so high originally). First of all, I have to persuade certain power users to accept the reduction in parallelism at the object-level (not a best practice, anyway) and get them to use optimizer hints in their queries. I've been fighting this fight for a while because users can inadvertently consume ridiculous amounts of parallel slaves and compromise the stability of the system.
    I will check the extents - previously, I had just been querying segment usage by partition. Maybe the extents might help pinpoint the cause...

  • 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

  • Index size 3 times more then table

    table cnmas
    record 134 only
    but there is lot of dml operation on this table
    SQL&gt; SELECT COUNT(*) FROM CNMAS;
    COUNT(*)
    134
    1* SELECT SUM(BYTES)/1024/1024 FROM USER_SEGMENTS WHERE SEGMENT_NAME='CNMAS'
    SQL&gt; /
    SUM(BYTES)/1024/1024
    4
    1* SELECT SUM(BYTES)/1024/1024 FROM USER_SEGMENTS WHERE SEGMENT_NAME='PK_CNMAS_CN_DOC_NO'
    SQL&gt; /
    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 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

    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

  • 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

  • Table index size in DB02 smaller after upgrade

    SAP ERP 6.0, DB2 9.5, AIX 5.3.  After we upgraded to SPS 15 / EHP4 / Netweaver EHP1 SPS02 using the downtime minimized method (shadow instance created) the index sizes for the tables are showing reduced sizes. When looking in DB02 under  History -> "tables and indexes" all the tables show a drop in index sizes.   I have compared the indexes to a pre upgrade copy of the system and all the indexes are still defined and active in the upgrades system.  Can somebody please explain why the size drop?  Is this a reporting error or what?

    Hi Eddie,
    DB2 V8.2 did not allow to retrieve table/index size information from DB2 directly. Therefore the SAP DB2 database interface and the CCMS code tried to do some size estimation based on cardinality and table/index width. DB2 V9.1+ provides table function ADMIN_GET_TAB_INFO to retrieve size information directly from DB2. Since this size information is much more accurate the SAP DB2 database interface and the CCMS code have been changed to use this table function.
    So the phantom-"shrink" you observed may be related to the switch from size estimation to the size retrieved from ADMIN_GET_TAB_INFO . This may have happened directly after the V9.5 upgrade ( size retrieved differently in SAP DB2 database interface ) or after the SAP release upgrade ( change in CCMS ABAP coding ).
    Regards
                     Frank

  • 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

  • Sort Index Size failed in file

    Hi Experts,
    Do you have any idea why we get this error in MDS log file? I am sure you must have come across it, what could be a fix for it?
    We have observed Log info "Sort Index Size failed in file" logged into MDS Log file while doing following:
    It happens during following processes:
    a)_Master Slave Sync between Master and Slave Repo->> MDSAdminServer@GetAndApplyMasterChangeRep_
    2010-08-05T12:00:01.012 14 23 Condition: pos < sortIndexSize failed in file /export/home/builder/mdm.build/7.1.03.xx/Cpp/MDM/Servers/MDS /DataMgmt/Update.cpp , line 1097
    MDSAdminServer@GetAndApplyMasterChangeRep Dbg.cpp 65
    Admin SRM_MDM_CATALOG_CHILDPROD3-DB- HA:1527/PMDORCL_21_20_4_3
    b)_Remove Records from Data Manager->> CatMgr@RemoveRecords336_
    2010-07-30T21:00:02.378 42 23 Condition: pos < sortIndexSize failed in file /export/home/builder/mdm.build/7.1.03.xx/Cpp/MDM/Servers/MDS/DataMgmt/Update.cpp , line 1097
    MDSAdminServer@GetAndApplyMasterChangeRep Dbg.cpp 65
    Admin SRM_MDM_CATALOG_CHILDPROD3-DB- HA:1527/PMDORCL_21_20_4_3
    c)_Update Records  from Data Manager->> CatMgr@ModifyRecords326_
    2010-08-04T22:24:11.602 43 23 Condition: pos < sortIndexSize failed in file /export/home/builder/mdm.build/7.1.03.xx/Cpp/MDM/Servers/MDS/DataMgmt/Update.cpp , line 1097 CatMgr@RemoveRecords336 Dbg.cpp 65 49 harrik3 SRM_MDM_CATALOG <PROD3-DB-HA:1527/PMD[Oracle]>
    As the Log Info name indicates "Sort Index Size failed in file", we are wondering is there anything to do with the -Size of Index File. Is there any parameter in DB side or in MDS which controls logging file size. May be that file size is not allowing Index sorting to be written into that file and file gets overflown due to less file size and MDS Logs this "Log Info". And since Indexing is not completed and not written into Index file, eventually the search made thru Advance Search gets weird and start throwing null pinter exception in browser because Index is not present for some searches.
    This error seems like some unhandled exception code in program- Update.cpp at line 1097.
    I would appreciate if you can throw some light on this and how to avoid this?
    Regards
    Pravin

    Hi Jignesh and Ravi,
    There is no Repo schema change and we made sure that we create new slave after any Repo schema change. I dont think there is an issue with master-slave, but issue probably lies some where else.
    In fact my original question is scrambled. Let me mention it again clearly.  Its not alone master-slave sync we get this log info-" Sort Index Size failed in file". Actually we get it during following 3 operations:
    a) On Master Slave Sync between Master and Slave Repo->> MDSAdminServer@GetAndApplyMasterChangeRep
    b) OnRemove Records from Data Manager in master->> CatMgr@RemoveRecords336
    c) On Updating Records in Data Manager->> CatMgr@ModifyRecords326
    Is there anything to do with the -Size of Index File. Is there any parameter in DB side or in MDS which controls logging file size.  This error seems like some unhandled exception code in program- Update.cpp at line 1097.
    _Pravin

Maybe you are looking for

  • Exporting to Nero Digital Format

    I am trying to install this plugin to premier cs3 http://www.nero.com/nero7/enu/tutorial_adobe_premiere.html So I can export directly to nero Digital - does anybody know how to get it to work ? I followed the instructions and I can't get the export t

  • Web redirect not working on MAC OS X WLC 5508

    Hi, I have a problem with Mac OS X-users. When connecting to the guest-network, the Mac does not get redirected to the login-web. I have tried to manually type in the url and IP-adress to the login-page, but cannot reach it. It works with all other d

  • I m getting error to access apex plz help

    hi anyone , help me my error log is.. [Wed Aug 01 15:57:10 2007] [notice] FastCGI: process manager initialized [Wed Aug 01 15:57:15 2007] [error] [client 192.168.0.27] [ecid: 1185964034:192.168.0.27:1040:484:1,0] mod_plsql: /pls/apex/apex HTTP-404 ap

  • What is the maximum Artboard size of CS4?

    We currently use CS3 in our Art Dept at the sign company I work for. Sometimes designing/layout for some projects can be a pain when they go beyond the max artboard size constraint in CS3. This is especially true in my dept which does all the large f

  • Why doesn't library on iphone show up in itunes library on computer

    Why don't all iphone apps show up in itunes library ( I installed 10.7 itunes prog if that makes any difference)