Creating index for a big table

Hello,
We have Oracle 9.2
I have two tables TableA and TableB. TableB is created by copying part of the content of TableA. Inorder to speed up the coping process, I dropped the primary index of TableB. Now TableB has 94 million records.
Now I was trying to create the primary index for TableB with the following script:
CREATE UNIQUE INDEX USR3."TableB~0"
ON USR3.TableB(ID,COUNTER)
PCTFREE 10
INITRANS 2
MAXTRANS 255
TABLESPACE INDEX1
STORAGE(FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT)
LOGGING
NOPARALLEL
NOCOMPRESS
And I get the Oracle catch all error (ora-00600: internal error....)
And I only have the following error message: "kcbvmap: unable to find victim buffer"
The tablespace is a locally managed tablespace
Please help, how do I fix this problem.

CREATE UNIQUE INDEX USR3."TableB~0"
What's with the wacky name?

Similar Messages

Where to create index for a big partitioned table?

Hello all.
I can't make a decision.
We are going to create an index for a big partitioned table (600 GB).
Where to create it ?
1. In the same tablespace where the table resides
2. In a new tablespace created for this index on the same filesystem.
Please write your suggestions. Pros and cons.
Thank you in advance.
Message was edited by:
v838

For manageability, you can create the index partition into different tablespaces.
There won't be any performance gain segregating tables and its indexes into different tablespaces.
Jaffar

Creating index for standard SAP tables

Hi!
What are the advantages and disadvantages of creating addtional indexes for tables with massive amount of data (BSEG, BKPF, COEP, etc...).
If I create a new index it supposed to make the table access faster, for the cost of hard disk space.
Am I right?
Thank you
Tamá

Hi,
Primary and secondary indexes
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Thanks and Regards
Arun Joseph

How to create index for Telecom large table

Hi ,
I'm working on DB 10G on REHL 5 for telecom company with more than 1 million recorded per day , we need to speed the query result ,
we know there are many types of the INDEX and I'm need a professional advice to create a suitable one ,
many of our queries depend on the MSID ( the MAC address of the Modem ) column ,
Name           Null Type
STREAMNUMBER        NUMBER(9)
MSID                VARCHAR2(20)
USERNAME            VARCHAR2(20)
DOMAIN              VARCHAR2(20)
USERIP              VARCHAR2(16)
CORRELATION_ID      VARCHAR2(64)
ACCOUNTREASON       NUMBER(3)
STARTTIME           VARCHAR2(14)
PRIORTIME           VARCHAR2(14)
CURTIME             VARCHAR2(14)
SESSIONTIME         NUMBER(9)
SESSIONVOLUME       NUMBER(9)
.please any help ,

really i have 3 queries for the subscriber activity like (usage details , the date of bundle start the the total of the download , he's working out of bundle or not )
and any of the subscribers can check those queries at any time thorw web ,
select nvl(min(substr(a.starttime,1,8)),0) Service_Start_Time, nvl(sum(a.sessionvolume),0) Total_Traffic_KB
FROM aaa_bill a
where msid='84A8E46E929D'
and starttime >=(select max(fee) FROM aaa_bill
where msid='84A8E46E929D' and accountreason=5);and the expected result is
service_start_date totoal_traffic_KB
20120225                   440554the MSIDs examples
(84A8E46E7F43,
84A8E46E7A82,
84A8E46E7C84,
84A8E46E7CBF,
also i have this query ,
select
substr(nvl(
(select nvl(starttime,'0') as starttime
from (
select nvl(starttime,0) starttime,sum(sessionvolume) over(partition by msid order by starttime) sum1
from aaa_bill
where msid='84A8E46E90BC' and starttime >=(select max(fee) FROM aaa_bill
where msid='84A8E46E90BC' and accountreason=5))
where sum1>=44987000
and rownum<2)
,0),1,8) Reached_45GB
from dual;and this one ,
select min(to_char(to_date(starttime,'yyyymmddhh24miss'),'yyyy-mm-dd hh24:mi:ss')) "Accounting Start Time",
max(to_char(to_date(curtime,'yyyymmddhh24miss'),'yyyy-mm-dd hh24:mi:ss')) "Accounting Stop Time",sum(sessiontime) Duration1,
TO_CHAR (TRUNC (SYSDATE) + NUMTODSINTERVAL (sum(sessiontime), 'second'),'hh24:mi:ss') hr,
sum(sessionvolume) Traffic
from aaa_bill
where msid='84A8E46E78EF'
and starttime >=(select max(fee) FROM aaa_bill
where msid='84A8E46E78EF' and accountreason=5)
group by correlation_id
order by min(starttime);

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.

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/

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

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.

Create index partition in the table partition tablespace

Hello,
I am running a custom job that
* Creates a tablespace daily
* Creates the daily table partition in the tablespace created
* Drops the tablepartition X days old
* Drops the tablespace for that partition on X+1 day.
The above job runs perfectly, but 'm having issues with managing the indexes for these partitioned tables. In the old database (10g - Single Node), all the partitions/indexes existed in one BIG tablespace and when I imported the table creation script into the new database, I modified all the table partitions & indexes to go into their respective tablespace.
Eg:
Table_name........Partition_name.....................Index_Part_name..........................Tablespace_name
============...================............====================...........=================
TABL1...................TABL1_2012_07_16............TABL1_IDX_2012_07_16............TBS_2012_07_16
TABL1...................TABL1_2012_07_15............TABL1_IDX_2012_07_15............TBS_2012_07_15
But now when the job runs, it creates the index into the default tablespace TBS_DATA.
Table_name........Partition_name.....................Index_Part_name..........................Tablespace_name
============...================.............====================...........=================
TABL1...................TABL1_2012_08_16............TABL1_IDX_2012_08_16............TBS_DATA
TABL1...................TABL1_2012_08_15............TABL1_IDX_2012_08_15............TBS_DATA
I can issue alter index rebuild to move the indexes to its default tablespace, but how can I ensure that the index gets created in its designated tablespace?
NOTE - the partition/tablespace management job that I run only creates the table partition and not the index.
The new env is a 2-Node 11gR2 RAC cluster on Linux x86_64.
Thanks in advance,
aBBy.

Excerpt from the job -
This creates the partition into the new tablespace.
v_sql_new_part := 'alter table '||tab_owner||'.'||tab_name||' add partition '||v_new_part_nm||'
values less than (to_date('''||v_new_part_dt_formatted||''',''DD-MON-YYYY'')) tablespace '||part_tbs;
execute immediate v_sql_new_part;New tablespace for new partition - because this is a 10T database and having multiple tablespaces helps with backup/recovery.
Thanks,
aBBy.

How to create index for a column of a view

Hi,
I have created view for a table and then i am trying to create index for a column of that view. i am using the query "CREATE INDEX index_name ON view_name (col)". but Mysql is showing error like "view_name is not a base table".
How can i do that......

As mentioned this is a java forum not a mysql forum, but as I know the answer - you can't create an index directly on a view in mysql.

Not able to create index for organization

in transaction ses_admin, i created an index for business object BAS_BUPA of type 1,ie individual account.
However, i am not able to create index for BAS_BUPA of type 2
It says "No entry in table SIC_INDEX_MAIN for index object BAS_BUPA and index 2"

hi,
The index is for Business Partner, so it includes both Persons and Organizations. So, only one index needs to be created for both.
The functioning is correct, just that i missed it.

Why do we create indexes for DSOs and Cubes.What is the use of it?

Hi All,
Can you please tell me why are indexes created for DSOs and Cubes.
What is the use with the creation of indexes.
Thanks,
Sravani

HI ,
An index is a copy of a database table that is reduced to certain fields. This copy is always in sorted form. Sorting provides faster access to the data records of the table, for example, when using a binary search. A table has a primary index and a secondary index. The primary index consists of the key fields of the table and is automatically created in the database along with the table. You can also create further indexes on a table in the Java Dictionary. These are called secondary indexes. This is necessary if the table is frequently accessed in a way that does not take advantage of the primary index. Different indexes for the same table are distinguished from one another by a separate index name. The index name must be unique. Whether or not an index is used to access a particular table, is decided by the database system optimizer. This means that an index might improve performance only with certain database systems. You specify if the index should be used on certain database systems in the index definition. Indexes for a table are created when the table is created (provided that the table is not excluded for the database system in the index definition). If the index fields represent the primary keys of the table, that is, if they already uniquely identify each record of the table, the index is referred to as an unique index.
they are created on DSO and cube for the performance purpose ..and reports created on them wil be also more efficent ..
Regards,
shikha

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

Creating Index to a master table

Hello All,
I have a database table with the following fields
CLIENT
MATNR
KORDX
KCATV
VARIANT_NBR
With the initial four fields making the primary key. ( CLIENT, MATNR, KORDX, KCATV).
I would like to put an index to the table with the fields (CLIENT, VARIANT_NBR), because there are many reads in the program for the field VARIANT_NBR. Could you please put across on views on this. What all factors should I consider for creating an index in performance perspective.
Thanks in advance
Sudha

Hi,
Regarding indexes information check this link...
http://help.sap.com/saphelp_nw04/helpdata/en/cc/7c58b369022e46b629bdd93d705c8c/content.htm
and
http://www.ncsu.edu/it/mirror/mysql/doc/maxdb/en/6a/c943401a306f13e10000000a1550b0/content.htm
And also go through the below information...
They may help you in optimizing your program.
The Optimizer
Each database system uses an optimizer whose task is to create the execution plan for SQL statements (for example, to determine whether to use an index or table scan). There are two kinds of optimizers:
1) Rule based
Rule based optimizers analyze the structure of an SQL statement (mainly the SELECT and WHERE clauses without their values) and the table index or indexes. They then use an algorithm to work out which method to use to execute the statement.
2) Cost based
Cost based optimizers use the above procedure, but also analyze some of the values in the WHERE clause and the table statistics. The statistics contain low and high values of the fields, or a histogram containing the distribution of data in the table. Since the cost based optimizer uses more information about the table, it usually leads to faster database access. Its disadvantage is that the statistics have to be periodically updated.
Minimize the Search Overhead
You minimize the size of the result set by using the WHERE and HAVING clauses. To increase the efficiency of these clauses, you should formulate them to fit with the database table indexes.
Database Indexes
Indexes speed up data selection from the database. They consist of selected fields of a table, of which a copy is then made in sorted order. If you specify the index fields correctly in a condition in the WHERE or HAVING clause, the system only searches part of the index (index range scan). The primary index is always created automatically in the R/3 System. It consists of the primary key fields of the database table. This means that for each combination of fields in the index, there is a maximum of one line in the table. This kind of index is also known as UNIQUE. If you cannot use the primary index to determine the result set because, for example, none of the primary index fields occur in the WHERE or HAVING clause, the system searches through the entire table (full table scan). For this case, you can create secondary indexes, which can restrict the number of table entries searched to form the result set. You specify the fields of secondary indexes using the Abap Dictionary. You can also determine whether the index is unique or not. However, you should not create secondary indexes to cover all possible combinations of fields. Only create one if you select data by fields that are not contained in another index, and the performance is very poor. Furthermore, you should only create secondary indexes for database tables from which you mainly read, since indexes have to be updated each time the database table is changed. As a rule, secondary indexes should not contain more than four fields, and you should not have more than five indexes for a single database table. If a table has more than five indexes, you run the risk of the optimizer choosing the wrong one for a particular operation. For this reason, you should avoid indexes with overlapping contents. Secondary indexes should contain columns that you use frequently in a selection, and that are as highly selective as possible. The fewer table entries that can be selected by a certain column, the higher that column's selectivity. Place the most selective fields at the beginning of the index. Your secondary index should be so selective that each index entry corresponds to at most five percent of the table entries. If this is not the case, it is not worth creating the index. You should also avoid creating indexes for fields that are not always filled, where their value is initial for most entries in the table. If all of the columns in the SELECT clause are contained in the index, the system does not have to search the actual table data after reading from the index. If you have a SELECT clause with very few columns, you can improve performance dramatically by including these columns in a secondary index.
Formulating Conditions for Indexes
You should bear in mind the following when formulating conditions for the WHERE and HAVING clauses so that the system can use a database index and does not have to use a full table scan. Check for Equality and Link Using AND The database index search is particularly efficient if you check all index fields for equality (= or EQ) and link the expressions using AND.
Use Positive conditions
The database system only supports queries that describe the result in positive terms, for example, EQ or LIKE. It does not support negative expressions like NE or NOT LIKE. If possible, avoid using the NOT operator in the WHERE clause, because it is not supported by database indexes; invert the logical expression instead.
Using OR
The optimizer usually stops working when an OR expression occurs in the condition. This means that the columns checked using OR are not included in the index search. An exception to this are OR expressions at the outside of conditions. You should try to reformulate conditions that apply OR expressions to columns relevant to the index, for example, into an IN condition.
Using Part of the Index
If you construct an index from several columns, the system can still use it even if you only specify a few of the columns in a condition. However, in this case, the sequence of the columns in the index is important. A column can only be used in the index search if all of the columns before it in the index definition have also been specified in the condition.
Checking for Null Values
The IS NULL condition can cause problems with indexes. Some database systems do not store null values in the index structure. Consequently, this field cannot be used in the index.
Avoid Complex Conditions
Avoid complex conditions, since the statements have to be broken down into their individual components by the database system.
Hope this information had helped you.
Regards
Narin Nandivada.

ABAP Routine for Deleting and creating index for ODS in Process chains

Any pointers for the ABAP Routine code for deleting and creating index for ODS in Process chains.

Hi Sachin,
find the following ABAP code to delete ODS ondex.
data : v_ods type RSDODSOBJECT.
move 'ODSname' to v_ods .
CALL FUNCTION 'RSSM_PROCESS_ODS_DROP_INDEXES'
EXPORTING
I_ODS = v_ods.
To create index:
data : v_ods type RSDODSOBJECT.
move 'ODSname' to v_ods .
CALL FUNCTION 'RSSM_PROCESS_ODS_CREA_INDEXES'
EXPORTING
I_ODS = v_ods.
hope it helps....
regards,
Raju

Creating index for a big table

Similar Messages

Maybe you are looking for