Creating Indexes in Cluster Tables

Hi,
I want to enable the index for the a cluster table..how is it possible..As we see for transparent tables like MSEG ,index tab is enabled but tables like BSEG the option is disabled..Please help me find a solution..
Regards
Maria

You cannot create index on cluster table in SAP.
BSEG is a cluster table, so no index, but hopefully there are "database indexes" on BSEG, which are actual database table : BSIS, BSAS, BSID, BSAS, and so on.
BSEG Access
BSAD Accounting: Secondary index for customers (cleared items)
BSAK Accounting: Secondary index for vendors (cleared items)
BSAS Accounting: Secondary index for G/L accounts (cleared items)
BSID Accounting: Secondary index for customers
BSIK Accounting: Secondary index for vendors
BSIM Secondary Index, Documents for Material
BSIS Accounting: Secondary index for G/L accounts
Create index on these tables.
Look also at
Re: Selecting data from BSEG.
Regards

Similar Messages

How to create index for particular table in R3

Hi
My load is taking too much time and it leads to process over due error. Does creating indexes on table in r3 side will solve this issue? If so how can we find out on which table does this particular data source depend. I went to maintain extract structure and findout only one table is supplying data for this data source.
Is there any other factors depend to solve this.
Thanks
kk

Hi,
it will depend on the table.... Having an index created will speed up the loading but slow down the insert therefore slowing some process perhaps...
May I ask which table it is? And which fields would you need to index?
Are you sure that bottleneck is located in R/3? Analyze your loading time in the monitor and see if this is really the case.
Otherwise you can create index for a table in Tx SE11; first check if an index is not already created...
hope this helps,
Olivier.

Why should we create index on the table after inserting data ?

Please tell me the Reason, why should we create index on the table after inserting data .
while we can also create index on the table before insertion of the data.

The choice depends on a number of factors, the main being how many rows are going to be inserted in the table as a percentage of the existing rows, or the percentage growth.
Creating index after a table has been populated works better when the tables are large or the inserts are large for the following reasons
1. The sort and creation of index is more efficient when done in batch and written in bulk. So works faster.
2. When the index is being written blocks get acquired as more data gets written. So, when a large number of rows get inserted in a table that already has an index , the index data blocks start splitting / chaining. This increases the "depth" of the inverted b-tree makes and that makes the index less efficient on I/O. Creating index after data has been inserted allows Orale to create optical block distribution/ reduce splitting / chaining
3. If an index exists then it too is routed through the undo / redo processes. Thats an overhead which is avoided when you create index after populating the table.
Regards

A query related to creating Indexes for a table

Hi ,
I am in a J2EE Banking Project using Oracle 10g as our Database .
We have created Indexes on some tables .
But this this is not called by any of our Java class .
Could anybody please let me know how these Indexes will actually improve the Performance .
Waiting for your replies .
Thanks in advance .

But in our safety database (huge & ofcourse Oracle), we use indexes just because to avoid duplicates, improve data retrieval and so on.As you pointed out indexes can do 2 things for you: enforce uniqueness and (hopefully) improve data retrieval. Enforcing uniqueness is pretty basic, but indexes don't always improve performance. Under the wrong condtions indexes can hurt performance. The ideas below refer to B-TREE indexes; other kinds of indexes have other considerations
Indexes add overhead to insert, delete, and (hopefully not - updating index columns is a Bad Idea), enough so that if you're inserting a lot of rows into a large table it is sometimes helpful to drop the indexes, load the data, and recreate the indexes when done to help performance. The more indexes a table has the more overhead DML statements need to maintain them.
Indexes help query performance under a couple of conditions. When using them as join keys to retrieve a small percentage of rows in a table (< 20% maybe; there is no firm number) indexes can help. When a query can read its columns from an index only (such as counts against a primary key index) index access can be faster than table access.
Indexes can hurt performance by adding overhead for maintenance if the index is never actually used or if used to read most of the rows in a table when a full table scan would be more efficient (why go through the extra effort to read the index and then table when you'll have to read most of the rows in the table anyway?).

When do I really need to create indexes for a table?

Once I was talking to a dba in a conference.
He told me that not always I have to create indexes for a single table, it depends of its size.
He said that Oracle read registers in blocks, and for a small table Oracle can read it fully, in a single operation, so in those cases I don't need indexes and statistcs.
So I would like to know how to calculate it.
When do I really need to create indexes for a table?
If someone know any documment that explain that, or have some tips, I'd aprecciate.
Thanks.
P.S.: The version that I'm using is Oracle 9.2.0.4.0.

Hi Vin
You mentioned so many mistakes here, I don't know where to begin ...
vprabhu_2000 wrote:
There are different kinds of Index. B-tree Index is by default. Bit map index, function based index,index organized table.
B-tree index if the table is large This is incorrect. Small tables, even those consisting of rows within just one block, can benefit from an index. There is no table size too small in which an index might not be benefical. William Robertson in his post references links to my blog where I discuss this.
and if you want to retrieve 10 % or less of data then B-tree index is good. This is all wrong as well. A FTS on a (say) million row table could very well be more efficient when retrieving (say) just 1% of data. An index could very well be more efficient when retrieving 100% of data. There's nothing special about 10% and there is no such magic number ...
>
Bit Map Index - On low cardinality columns like Sex for eg which could have values Male,Female create a bit map index. Completely and utterly wrong. A bitmap index might be the perfect type of index, better than a B-Tree, even if there are (say) 100,000 distinct values in the table. That a bitmap index is only suitable for low cardinality columns is just not true. And what if it's an OLTP application, with lot's of concurrent DML on the underlining table, do you really think a bitmap index would be a good idea ?
>
You can also create an Index organized table if there are less rows to be stored so data is stored only once in index and not in table. Not sure what you mean here but an IOT can potentially be useful if you have very large numbers of rows in the table. The number of rows has nothing to do with whether an IOT is suitable or not.
>
Hope this info helps. Considering most of it is wrong, I'm not sure it really helps at all :(
Cheers
Richard Foote
http://richardfoote.wordpress.com/

Unable to create Indexes on F table

Hi
We are unable to create Indexes on one of our Cube's fact table...I tried creating with Process chain , Batch and also tried with SE11 ...table name ... Indexes ...Activate...
Its showing active object generated but the warning msg Index does not exist in database system MSSQL still exist and not creating indexes...When I activate the indexes its not showing this warning for all other cubes...Please advice
regards

Hi Sam,.
The index creation on F table is taken care by the system itself. When you activate the cube, the DIM and F table are created and at the same time, indexes are created.
To create your own indes, though, go to se11...>F Table name-->Indeexes-it will show you system created indexes.
There will be a create sign....click there... and give the name of the index(like 1, 2). It will open up the maintain index page, where you have to mention all the parameter.
Thanbks...
Shambhu

Things to consider while Creating Indexes in the tables

Hi All,
We have some application slow issues becasue of the tables which it is calling are Heap. There are Primary keys created on few tables though. I have to think and design the indexing on those tables. What are different things need to check to design the Indexes?
Thanks
Swapna

Hi All,
We have some application slow issues becasue of the tables which it is calling are Heap. There are Primary keys created on few tables though. I have to think and design the indexing on those tables. What are different things need to check to design the Indexes?
Thanks
Swapna
Adding to what others have said create an index and check execution plan whether it is being used by optimizer or not if it is used and query runs fast that index can be kept
You should also take help of DMV
sys.dm_index_usage_stats to see whether index is being utilized or not. refer to user seek user update and user scan col. If Update is very much greater that seek/scan index is probably not utilized , you can consider removing it
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it.
My TechNet Wiki Articles

Problem while creating index for temporary table...

Hi,
i have created index for a temporary table and this script should used by multiusers.So when second user connecting to it is giving index i mean object already exists.
So what i need is when the second user connected the script should create one more index on temporary table.Will sql server provide any random way of creating indexes if the index exists already with that name??
Thank You,

Nope..
SQL Server is cleaver enough to handel this situation.
When you create a index or constraint on the Temp Table, eventhough the index name is duplicate it will allow.
But it only possible on temp tables (prefixed with single #).
To Test this,
Open Two window,
Execute the below window on the opened 2 window..
create table #test
id int
Insert Into #test values(1);
Insert Into #test values(2);
Create clustered index testindex on #test(id)
Now you wont get any error on any of the window. Rite?
To fetch the created index details, execute the below code on any one of the window..
select * from sysindexes where name like '%test%'
Now you can see the 2 rows with same indexname but refereing with different table. Yes. all the temp tables (#) will be suffixed with unique number to avoid the object already found error while multiple users connects.

Creating indexes in temprory table

Guys here is my temp table
-- Create table
create global temporary table EMP_TEMP
EMP_NO NUMBER(4),
EMP_SALARY NUMBER(7),
EMP_NAME VARCHAR2(30),
on commit preserve rows;
Now how can I created indexes on EMP_SALARY or EMP_NAME .I am not looking for primary or unique keys but just indexes.
I tried create index command but it say it is unsupported for temporory table.
please help.
thx

manushetty,
Index on temporary table, like data from temporary table, is not persistant. Also you cannot have storage clause, or tablespace...
From my index which I created above :
1 select index_name,tablespace_name,pct_free,
2         ini_trans,max_trans,initial_extent,min_extents,max_extents
3 from dba_indexes
4* where index_name = 'TOTI'
SQL> /
INDEX_NAME                     TABLESPACE_NAME                  PCT_FREE
INI_TRANS MAX_TRANS INITIAL_EXTENT MIN_EXTENTS MAX_EXTENTS
TOTI                                                                  10
         2        255
SQL> As you can see, there is no tablespace, and no storage clause (extent)
If I create the same index on a permanent table, all these parameters are not null :
SQL> create index toti on emp(sal);
Index created.
1 select index_name,tablespace_name,pct_free,
2         ini_trans,max_trans,initial_extent,min_extents,max_extents
3 from all_indexes
4* where index_name = 'TOTI'
SQL> /
INDEX_NAME                     TABLESPACE_NAME                  PCT_FREE
INI_TRANS MAX_TRANS INITIAL_EXTENT MIN_EXTENTS MAX_EXTENTS
TOTI                           SYSTEM                                 10
         2        255          65536           1 2147483645HTH,
Nicolas.

When to create index on partitioned table ?

Hi,
The original table TEST1 contain one index called INDX_HIREDATE on field HIREDATE
CREATE TABLE TEST1(
COD NUMBER PRIMARY KEY,
HIREDATE DATE);
CREATE INDEX INDX_HIREDATE ON TEST1 (HIREDATE);
I created a example partitioned table as below:
CREATE TABLE TEST2_PART(
COD NUMBER PRIMARY KEY,
HIREDATE DATE)
PARTITION BY RANGE (HIREDATE)(
PARTITION P2003 VALUES LESS THAN (TO_DATE('01/01/2004','DD/MM/YYYY')),
PARTITION P2004 VALUES LESS THAN (TO_DATE('01/01/2005','DD/MM/YYYY')),
PARTITION P3000 VALUES LESS THAN (MAXVALUE));
INSERT /*+ APPEND */ INTO TEST2 SELECT * FROM TEST1;
Questions:
Need i to create the index on TEST2 table the same way done on the TEST1 table?
ex: CREATE INDEX INDX_HIREDATE ON TEST2 (HIREDATE);
or have i need to create the global/local index on each partition?
The Primary Key index is a global for partitions??
What is the best way?
Thanks

Index creation on partitioned tables is similar to the non-partitioned tables. There is no special syntax unless you need to create LOCAL indexes. For creating local indexes, add LOCAL key word at the end of the "create index...." command.
To create local primary key index you may need to use different syntax the one used in your create table command. Refer to SQL Reference manual for actual syntax. (remember manuals are the best place for getting quick answers). All the manuals are available online (at otn.oracle.com).

Create Index on another schema table stored in my table

Hi,
I want to create index on a table column which is in another schema from my schema and the index to be stored in my schema.
ex: current user 'hr'
sql>create index idx1 on scott.emp(eno);
Does the above query works??
thanks,
Sri

Why cant you give a try?
Are you getting any error message?
See below..
SQL> show user
USER is "SCOTT"
SQL> grant select on emp to hr;
Grant succeeded.
SQL> conn
Enter user-name: hr@***
Enter password:
Connected.
SQL> show user
USER is "HR"
SQL> create index ndx on scott.emp(sal);
create index ndx on scott.emp(sal)
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> conn
Enter user-name: system@*******
Enter password:
Connected.
SQL> create index ndx on scott.emp(sal);
Index created.
SQL> drop index ndx;
Index dropped.
SQL> grant create any index to hr;
Grant succeeded.
SQL> conn
Enter user-name: hr@*******
Enter password:
Connected.
SQL> create index ndx on scott.emp(sal);
Index created.Edited by: jeneesh on Oct 8, 2012 3:53 PM

Create Index on a huge table

Hi,
We have a huge table and there is no index on this table, I want to create index on this table, we are working on Oracle 11g/Linux.
Our business users are frequently accessing this table and select statement taking very long time.
Please let me know which index type would be best suited for this and what would the command to create index on it.
Would appreciate your assistance.
Regards.

>
We have a huge table and there is no index on this table, I want to create index on this table, we are working on Oracle 11g/Linux.
Our business users are frequently accessing this table and select statement taking very long time.
Please let me know which index type would be best suited for this and what would the command to create index on it.
>
We need loads of information to suggest anything useful
a) What database version is yours? (if 11g, you have good more options)
b) What type of environment is it? OLTP or Warehouse?
c) How big is the table?
d) How many distinct values are there in that column that you want to index?
e) Would this index undergo lots of inserts/deletes/updates? That is, is this table used mainly for querying or will it undergo continous inserts/updates/deletes?
In case your environment is warehouse type where you load once and then mainly used for queries and more importantly, if that column has very few distinct columns (typical example is a GENDER column where you have only two distinct values), you will be largely benefitted from BITMAP index. If it's an OLTP environment where multiple processes will be inserting into the table, you never ever go near BITMAP index but do only B-Tree index.
Finally, have you arrived at a concrete reason on why you want to build that index now rather than when you designed the table? If you don't need an index for sure, better not have it. If you are on 11g, you can have INVISIBLE index.
Also, if it's a very large table, you may create the index nologging to avoid loads of redo generation (not recommended on production environment though). But you have to be aware that in the event of disaster recovery you will have to recreate the index after you restore the database. Also if you are on Dataguard environment, you have to take necessary precautions while doing NOLOGGING operations.
Edited by: user12035575 on Sep 11, 2011 12:37 PM

View on cluster table

hi all,
I am trying to create a view for the tables bkpg and bseg.but am unable to as the error is "bseg is cluster table".
can't we create view for cluster table. if can, how

You cannot create a view because BSEG is in a cluster table
For this reason SAP has provided some "secondary index" tables, look for :
     BSAD     Accounting: Secondary Index for Customers (Cleared Items)
     BSAK     Accounting: Secondary Index for Vendors (Cleared Items)
     BSAS     Accounting: Secondary Index for G/L Accounts (Cleared Items)
     BSID     Accounting: Secondary Index for Customers
     BSIK     Accounting: Secondary Index for Vendors
     BSIM     Secondary Index, Documents for Material
     BSIS     Accounting: Secondary Index for G/L Accounts
Regards

Hash Cluster Tables vs Partitioning

Hi All,
Can we create partition on Cluster tables?
As per understanding Cluster can give excellent performance if used carefully, in our case we need to purge our data also.
We can purge the partitions easly.
Can you help me for the comparion of these two objects?
Thanks
Sandeep

No , Oracle does not support this.
http://download.oracle.com/docs/cd/B28359_01/server.111/b32024.pdf (page 4-19).
The rules for partitioning indexes are similar to those for tables:
■ An index can be partitioned unless:
– The index is a cluster index.
– The index is defined on a clustered table
Thanks
http://swervedba.wordpress.com/

DB Size for a custom cluster table?

Hi friends,
I have a requirement where in i need to store huge attachments into SAP DB.
For that i created a Custom cluster table just like INDX table and storing the binary read attachments(PDF/JPEG) into it.
Can some one help me how much size from DB side this table would take.
Suppose i am reading a PDF file of size 3.5 MB and storign this into my custom cluster table, which would span into 1200 records, what is the DB size taken by this ?
Appreciate any help on this.
SAP Version - 4.7EE
DB - DB2
OS - AIX
Regards,
Simha
Edited by: Simha on Aug 5, 2008 7:27 AM

Hi Simha,
simple question complex answer ....
The answer mainly depends on the length of the RAW column in the INDX type table. In my answer I assume that your database is running with the default of 16K tablespace page size.
(1) if the length of the RAW column is below 4K on a unicode system or below 12K in a non unicode system,
     the ABAP RAW column is mapped to a VARCHAR FOR BIT DATA column on database level.
     VARCHAR FOR BIT DATA colunms are buffered in the database buffer pool and can benefit from DB2 row compression.
     DB2 row compression may not help for PDF or JPEG data since this data is already compressed
     but buffering will provide better performance.
     Since VARCHAR FOR BIT DATA columns will be stored in the DB2 data pages, the overall space requirement will be
     minimal if the space in the 16K pages can be used optimal. E.g. if the size of our RAW column is 8,5 K and most rows
     contain values with maximun length in this column only one row can be stored per data page.
(2) if (1) does not apply, the ABAP RAW column is mapped to a LONG VARCHAR FOR BIT DATA
     column on database level.
     LONG data is stored in seperate LONG pages on database level. The LONG data is stored in blocks of
     512 bytes time 2^N ( 512, 1024, 2048, 4K , 8K, 16K ). The overall space requirement will be
     minimal if the space in the LONG blocks can be used optimal.
Given the explanation above I would guess that in worst case you may need a factor of 2 more space in the database than your document size. Each additional row will require some bytes overhead in the DB2 data pages and will create additional index entries. So you may want a large maximum size of your RAW column but this will give you LONG data types.
If read performance is not critical I would suggest to choose 16K as your size of the RAW column. This should completely fill the LONG blocks.
If read performance is more critical you should choose a small size for the RAW column ( e.g. 2K ) to benefit from data buffering and to avoid sparsely filled data pages.
Regards
               Frank

Creating Indexes in Cluster Tables

Similar Messages

Maybe you are looking for