Index on a DB Table

Hello Experts,
I need to create an index on a transparent table. I have question before I go and create the index. Can anybody (means developer) create an index on a table? What impact does it have on the R/3 system and on the Database? Is BASIS only supposed to create the index? I appreciate any inputs you have for me.
Thanks.

Hi,
Creating additional indexes can place a load on the system since they must be adjusted each time the table contents change. Each additional index therefore slows down the insertion of records in the table.
It is NOT mandatory that only BASIS has to create index. If you have auth you can create.
PS : Please analyse the impact on the database before creating indexes
a®

Similar Messages

INDEX UNIQUE SCAN instead of   INDEX FULL SCAN or TABLE ACCESS FULL

I have calculated statistics in all tables and indexes
I have a table and a view and when I put it
SELECT *
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
Itâs OK. I NEED IT (INDEX UNIQUE SCAN)
But If I put
SELECT A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
In table A make a TABLE ACCESS FULL.
Then If I put:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
Itâs OK. I NEED IT (INDEX UNIQUE SCAN)
Finally, If I put other tables and views in the query (I NEED IT)
For example:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID
INNER JOIN TABLE_Câ¦.
LEFT JOIN VIEW_Dâ¦.
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX FULL SCAN (FIELD_A_TABLE_A_PK)
I need INDEX UNIQUE SCAN instead of INDEX FULL SCAN or TABLE ACCESS FULL.
How can obtain it?
What happens???
Thanks!

Notice the difference in cardinality between your two select statements:
SELECT STATEMENT, GOAL = ALL_ROWS Cost=5 Cardinality=1
SELECT STATEMENT, GOAL = ALL_ROWS Cost=10450 Cardinality=472161Apparently since the optimizer believed the first statement was going to return one row, it used an index. But in the second statement it believed it was going to return nearly the whole table (didn't you say it had around 500k rows?). Hence full table scan.

Can we change the fields of database unique index in a customised table?

Hi all..
I want to know that can we create or change or delete the database unique index of a customized table?
In my case, there is a customised table with 4 primary keys with all the records to be maintained thru transaction code SM30.
There is database unique index maintained for this table which has 2 fields. These 2 fields are out of the 4 primary fields of the table.I hope I have made myself clear!
Now when I am trying to insert a record in the table it give me a short dump.( It says duplication of records is not allowed)
The reason being that the new record that I am trying to insert in the database table has those 2 fields for which the unique index is maintained is the same as an already existing record.And the other two fields are different from the already existing record.So overall the combination of the 4 primary fields is different.
Please tell me how shall I proceed now?
I also tried to change the Unique index but it is asking me some kind of authrization(You are not authorized to make changes (authorization object S_DEVELOP)).Also I am not sure whether changing the unique index is feasible or not.?
Thanks.

hi
I think you will not be able to do unique indexing withou the help of primary keys,so use all the primary keys into the table field selections and and then create indexing otherwise dupilication of keys can occur. if you are not able to keep the primary keys then go for non unique key indexing,where you have to add the client field and the any keys of your wish.

Creating a bit map index on a partitioned table

Dear friends,
I am trying to create a bitmap index on a partitioned table but am receiving the following ORA error. Can you please let me know on how to create a local bit map index as the message suggests?
ERROR at line 1:
ORA-25122: Only LOCAL bitmap indexes are permitted on partitioned tables
Trying to use the keyword local in front leads to wrong syntax.
Thanks in advance !!
Somnath

ORA-25122 Only LOCAL bitmap indexes are permitted on partitioned tables
Cause: An attempt was made to create a global bitmap index on a partitioned table.
Action: Create a local bitmap index instead
Example of a Local Index Creation
CREATE INDEX employees_local_idx ON employees (employee_id) LOCAL;
Example is about btree and I think it will work for bitmap also.

Non-Partitioned Global Index on Range-Partitioned Table.

Hi All,
Is it possible to create Non-Partitioned Global Index on Range-Partitioned Table?
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Please help me in identifying other 3 indexes types by referring below ouputs!!!
select INDEX_NAME,TABLE_NAME,PARTITIONING_TYPE,LOCALITY from dba_part_indexes where TABLE_NAME='CS_BILLING';
INDEX_NAME TABLE_NAME PARTITI LOCALI
CSB_CLIENT_CODE CS_BILLING RANGE LOCAL
select index_name,index_type,table_name,table_type,PARTITIONED from dba_indexes where table_name='CS_BILLING';
INDEX_NAME INDEX_TYPE TABLE_NAME TABLE_TYPE PAR
CSB_CREATE_DATE NORMAL CS_BILLING TABLE NO
CSB_SUBMIT_ORDER NORMAL CS_BILLING TABLE NO
CSB_CLIENT_CODE NORMAL CS_BILLING TABLE YES
CSB_ORDER_NBR NORMAL CS_BILLING TABLE NO
select INDEX_OWNER,INDEX_NAME,TABLE_NAME,COLUMN_NAME from dba_ind_columns where TABLE_NAME='CS_BILLING';
INDEX_OWNER INDEX_NAME TABLE_NAME COLUMN_NAME
RPADMIN CSB_CREATE_DATE CS_BILLING CREATE_DATE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING SUBMIT_TO_INVOICE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING ORDER_NBR
RPADMIN CSB_CLIENT_CODE CS_BILLING CLIENT_CODE
RPADMIN CSB_ORDER_NBR CS_BILLING ORDER_NBR
select dip.index_name, dpi.locality, dip.partition_name, dip.status
from dba_part_indexes dpi, dba_ind_partitions dip
where dpi.table_name ='CS_BILLING'
and dpi.index_name = dip.index_name;
INDEX_NAME LOCALI PARTITION_NAME STATUS
CSB_CLIENT_CODE LOCAL CSB_2006_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2006_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_4Q USABLE
select * from dba_part_indexes
where table_name ='CS_BILLING'
and locality = 'GLOBAL';
no rows selected
-Yasser
Edited by: YasserRACDBA on Mar 5, 2009 11:45 PM

Yaseer,
Is it possible to create Non-Partitioned and Global Index on Range-Partitioned Table?
Yes
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
You got local index and 3 non-partitioned "NORMAL" b-tree tyep indexes
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Above staement will create non-partitioned index
Here is an example of creating global partitioned indexes
CREATE INDEX month_ix ON sales(sales_month)
   GLOBAL PARTITION BY RANGE(sales_month)
      (PARTITION pm1_ix VALUES LESS THAN (2)
       PARTITION pm2_ix VALUES LESS THAN (3)
       PARTITION pm3_ix VALUES LESS THAN (4)
        PARTITION pm12_ix VALUES LESS THAN (MAXVALUE));Regards

Transport of secondary index on /BIC/P table

Hi All,
I have created a secondary index on '/BIC/P table and it is not allowing me to assign a transport object as the table itself is temporary and it gets created automatically in the target system when we activate the info-object.
Is there any way to transport the secondary index directly on the /BIC/P table ?
Its urgent.
Thanks
Soumya

Soumya,
Sorry for not being clear enough: you can change the package of this index and transport it but since the P table could be regenerated automatically by the BW application when you change your IObj you may now get into troubles when importing a change.
Indeed having now a local $TMP table with a non-local object underneath may not please your target system and even not your DEV system...
One can always bypass SAP BW application; for instance creating indexes directly in the database; but this is at its own risk!
hoping this will explain a bit further your issue
Olivier.

Create/drop index on a busy table

Hello,
It's kind-a of a funny question but how do you create or drop a index on a very busy table? (by making the users wait...)
I tried:
lock table <table> in exclusive mode
then in another session (session2)
update <table> set col1 = 'a';
(this session now waits)
then back a the first session:
create index bla on <table> (col1);
And what happens is that the lock is released immediatelly, and in session2 the update updates and I get the standard "RESOURCE BUSY" error.
Any ideas on how to do that ?
Thanks

Jozsef wrote:
Hi there,
I have done similar things couple of times before and I have used a pretty good method to obtain a rough (and it was really a rough, but enough) estimation.
Sorry folks, it does not work properly for create index...this method only works for SELECT statments, SO IGNORE IT :(
It nearly works in 10g:
| Id | Operation              | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | CREATE INDEX STATEMENT |       | 10000 | 40000 |    10   (0)| 00:00:01 |
|   1 | INDEX BUILD NON UNIQUE| T1_I1 |       |       |            |          |
|   2 |   SORT CREATE INDEX    |       | 10000 | 40000 |            |          |
|   3 |    TABLE ACCESS FULL   | T1    | 10000 | 40000 |     6   (0)| 00:00:01 |
Note
   - estimated index size: 196K bytesThe "Note" tells you Oracle's estimate of the final space allocation needed for the index. There are various reasons why the estimate is not very accurate, and why it's not a good estimate of the space requirement in the TEMP tablespace, but it gives you a figure that is probably in the right ballpark (factor of 2 out, either way, probably).
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"For every expert there is an equal and opposite expert."
Arthur C. Clarke

Create an index on a huge table

hi gurus
I am going to create an index on a very large table(194GB) with the temporary tablespace size is 80G.
I am afraid that during the index creation the temporary tablespace is not enouth to hold the data needed
to create the index,because i only have 80g in temporary tablespace. How do i estimated the size i need to create a such large index and is there an effcient way to do such index creation?
thank u in advance.

Jozsef wrote:
Hi there,
I have done similar things couple of times before and I have used a pretty good method to obtain a rough (and it was really a rough, but enough) estimation.
Sorry folks, it does not work properly for create index...this method only works for SELECT statments, SO IGNORE IT :(
It nearly works in 10g:
| Id | Operation              | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | CREATE INDEX STATEMENT |       | 10000 | 40000 |    10   (0)| 00:00:01 |
|   1 | INDEX BUILD NON UNIQUE| T1_I1 |       |       |            |          |
|   2 |   SORT CREATE INDEX    |       | 10000 | 40000 |            |          |
|   3 |    TABLE ACCESS FULL   | T1    | 10000 | 40000 |     6   (0)| 00:00:01 |
Note
   - estimated index size: 196K bytesThe "Note" tells you Oracle's estimate of the final space allocation needed for the index. There are various reasons why the estimate is not very accurate, and why it's not a good estimate of the space requirement in the TEMP tablespace, but it gives you a figure that is probably in the right ballpark (factor of 2 out, either way, probably).
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"For every expert there is an equal and opposite expert."
Arthur C. Clarke

Index for a PSA table is not in the "customer" namespace

Hi,
While loading data through infosource 0CO_OM_WBS_1 to
data target 0IMFA_1 loading failes and the reason given is that the system reads data from PSA table /BIC/B0001060000 of 0IM_FA_IQ_9 and the index generated for this table supplied return code 14.
I found no notes in the subject - with the syntax :
Index for a PSA table is not in the "customer" namespace.
thanks in advance for your help.

Hi,
I think you need to speak to your basis guys / DBA as index created on PSA table is not in your tablespace. He should be able to help you.
Vikash

Indexes on a fact table

Hi All,
We are trying to build a data warehouse. The data marts would be accessed by cognos reporting layer. In the data marts we have around 9 dimension tables and 1 fact table. For each month we will have around 21-25 million records in the fact table. Out of 9 dimensions there dim1 and dim2 have 21 million and 10 million records respectively. The rest 7 dimensions are very small like less than 10k records.
In cognos reports they are trying to join the some dimension tables and the fact table to populate some reports. they are taking around 5-6 min.
I have around 8 B-Tree indexes on this fact table with all possible combination of columns. I believe that these many indexes is not improving the performance. So I decided to create a aggregated table with measures. But in cognos there are some reports which give detailed information from the fact table and that are taking around 8 min.
please advice as to what type indexes can be created on fact tables.
I read that we can create bit map indexes based on join conditions but the documentation says that it can include columns only from dimension tables and not fact tables. Should the indexed columns be keys in dimensional tables?
I have observed that the fact table is around 1.5gb. But each index is around 1.9 -2gb. I was kind of surprised when I saw that figure. Does it imply that index scan and table lookup would take more time than the full table scan? And hence it is not using the indexes.
Any help is greatly appreciated.
Thanks
Hari

What sort of queries are you running? Do you have an example (with a query plan)?
Are indexes even useful? Or are you accessing too much data to make indexes worthwhile?
Are you licensed to use partitioning? If so, are your fact tables partitioned? Are the queries doing partition pruning?
Are you using parallelism? If so, is parallel query actually being invoked?
If creating aggregate tables is a potentially useful strategy, you would want to use materialized views with query rewrite.
Justin

How can I create index(uniqie index) for a existed table?

Hi guys,
I want to create a index for a existed table, it should be unique index. I did it using se11, "indexes," and select the radio button "unqiue index", of course the fields as well. But when I activate it, I get a waring and therefore can not create this index. But if I select radio button "non-uniqe index", it works.
However I have to reate a unqiue index.
How can I do it?
Thanks in advance
Regards,
Liying

HI Wang
You can create your index via SE11, enter the table name, click change, choose Go To, Indexes. Here create your index with the key fields that you want. To use the index, your select statement WHERE clause, you must have the key fields of the index in the order that they appear in the index. The "optimizer" will choose the index depending on your fields of the WHERE clause.
One thing to remember is that when you create indexes for tables, the update or insert of these tables may have a slower response then before, I for one have never seen a big problem as of yet.
this Document may help u on primary and secondary indexes :
http://jdc.joy.com/helpdata/EN/cf/21eb20446011d189700000e8322d00/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
If it helps Reward the points
Regards,
Rk
Message was edited by:
Rk Pasupuleti

Index creation in BKPF table

Hello Gurus,
I have a bad performance in IDCP transaction, i read the sap note 511819 and this recommend create an index in BKPF table with fields:
'MANDT'
'BUKRS'
'XBLNR'
But i see in the system the table have an index with fields:
MANDT
BUKRS
BSTAT
XBLNR
Is necessary the index creation if already exists one index with this fields?
The table have 150 million rows and 9 indexes.
What is your suggestion?
Best regards,
Ernesto Castro.

HI,
If you have already index 001 with MANDT BUKRS BSTAT XBLNR
fields than it's not necessary to create another index with MANDT BUKRS XBLNR fields.
you need to create index 001 on following table only as described in note.
table : VBRK fields : MANDT XBLNR
table : LIKP fields: MANDT XBLNR
also activate this index only during the least critical time ( when maximum free resources available )
regards,
kaushal

How to prevent Oracle from using an index when joining two tables ...

How to prevent Oracle from using an index when joining two tables to get an inline view which is used in an update statement?
O.K. I think I have to explain what I mean:
When joining two tables which have many entries sometimes it es better not to use an index on the column used as join criteria.
I have two tables: table A and table B.
Table A has 4.000.000 entries and table B has 700.000 entries.
I have a join of both tables with a numeric column as join criteria.
There is an index on this column in table A.
So I instead of
where (A.col = B.col)I want to use
where (A.col+0 = B.col)in order to prevent Oracle from using the index.
When I use the join in a select statement it works.
But when I use the join as inline view in an update statement I get the error ORA-01779.
When I remove the "+0" the update statement works. (The column col is unique in table B).
Any ideas why this happens?
Thank you very much in advance for any help.
Regards Hartmut

I think you should post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your query resp. update statement. Please use the \[code\] and \[code\] tags to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Usually if you're using the CBO (cost based optimizer) and have reasonable statistics gathered on the database objects used the optimizer should be able to determine if it is better to use the existing index or not.
Things look different if you don't have statistics, you have outdated/wrong statistics or deliberately still use the RBO (rule based optimizer). In this case you would have to use other means to prevent the index usage, the most obvious would be the already mentioned NO_INDEX or FULL hint.
But I strongly recommend to check in first place why the optimizer apparently seems to choose an inappropriate index access path.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Table with FK with no Index created will LOCK TABLE during DML ?

Hi all,
Know that always create index for FK on table as FK's value will 99.9% be use in Where query on table.
Had seen info with regards to the above and had not been successfull trying to simulate the above using:
DROP TABLE "TABLE2";
CREATE TABLE "TABLE2"
   (     "A2" VARCHAR2(10 BYTE),
      CONSTRAINT "PK_A2" PRIMARY KEY ("A2") ENABLE
Insert into TABLE2 (A2) values ('AAA');
Insert into TABLE2 (A2) values ('BBB');
Insert into TABLE2 (A2) values ('CCC');
DROP TABLE "TABLE1";
CREATE TABLE "TABLE1"
   (     "A1" VARCHAR2(10 BYTE),
     "A2" VARCHAR2(10 BYTE),
     "A3" VARCHAR2(10 BYTE),
      CONSTRAINT "PK_A1" PRIMARY KEY ("A1"),
      CONSTRAINT "FK_A1_A2" FOREIGN KEY ("A2")
       REFERENCES "LSD"."TABLE2" ("A2") ENABLE
Insert into TABLE1 (A1,A2,A3) values ('111','AAA','yyy');
Insert into TABLE1 (A1,A2,A3) values ('222','BBB','ZZZ');
When i UPDATE A3 in TABLE1 using '111' record in SQLPlus without COMMIT,
I was able to UPDATE A3 using '222' in another SQLPlus session, so it does not seems like table is LOCK.
Questions.
1. Am using 10GR2, is the above not applicable to 10G ?
2. Or had understand the above concept wrongly ?
Thanks In Advance
Zack

Hi Legatti,
I was able to UPDATE A3 using '222' in another SQLPlus session, so it does not seems like table is LOCK.   Thought that when updating more than 1 record in TABLE1 will caused TABLE1 to be LOCK.
Now, try to perform an update on the TABLE1 like below:    SQL>update table1 set A3='aaa' where A1=111;
And open an another session and perform this SQL below    SQL>delete from table2 where A2='BBB'; -- now it's hangs
Yes !!! Very interesting, it hangs until i do a COMMIT on the UPDATE
and DELETE session shows ORA-02292 Integrity Constraint violated as child record found.
Now, when i create a index for A2 on TABLE1, it DOES NOT HANG and shows ORA-2292 immediately.
So, is this the result of having no index for FK column (A2) on TABLE1 and when doing DML ,
before COMMIT, will result in TABLE2 to be hang upon doing DML on TABLE2 ?
Thanks for the valuable lesson learned.
Zack

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.

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 on a DB Table

Similar Messages

Maybe you are looking for