Data Dic

[Former Member]

Hi all,

How do you know a select statment uses a primary index or a secondary index.How and y do u create a secondary indx.

Thanks in advance,

ALEX

[Former Member]

Hi alex,

- y do u create a secondary indx.

<b>1. SECONDARY INDEX.

They are generally used for faster access.</b>

EG.

In a table there are 10 fields.

1,2 are primary fields (primary index)

2. But the table is queried many times

on field number 6 (eg).

So we can create a NEW Index

(Secondary index)

only on that 6th field.

3. Due to this,

the sql will become faster

because NOW

the database will search on the

basis of secnodary index (made on 6th field)

4. We cannot directly come to know whether the database,

is really using the secondary index or not.

It all depends upon the SQL and its where conditions.

At most, as per documentaiton, we can give HINTS for oracle sql.

regards,

amit m.

[Former Member]

Creating Secondary Indexes

Procedure

1,.In the maintenance screen of the table, choose Indexes.

If indexes already exist on the table, a list of these indexes is displayed. Choose .

2.In the next dialog box, enter the index ID and choose

The maintenance screen for indexes appears.

3.Enter an explanatory text in the field Short text.

You can then use the short text to find the index at a later time, for example with the R/3 Repository Information System.

4.Select the table fields to be included in the index using the input help for the Field name column. The order of the fields in the index is very important. See What to Keep in Mind for Secondary Indexes.

If the values in the index fields already uniquely identify each record of the table, select Unique index.

5.A unique index is always created in the database at activation because it also has a functional meaning (prevents double entries of the index fields).

6.If it is not a unique index, leave Non-unique index selected.

In this case you can use the radio buttons to define whether the index should be created for all database systems, for selected database systems or not at all in the database.

7.Select for selected database systems if the index should only be created for selected database systems.

Click on the arrow behind the radio buttons. A dialog box appears in which you can define up to 4 database systems with the input help. Select Selection list if the index should only be created on the given database systems. Select Exclusion list if the index should not be created on the given database systems. Choose .

8.Choose Activate.

Regards

[Former Member]

Hi

Through select statement we cant justify wheteher it is using primary or secondary index

You can search a table for data records that satisfy certain search criteria faster using an index.

An index can be considered a copy of a database table that has been reduced to certain fields. This copy is always in sorted form. Sorting provides faster access to the data records of the table, for example using a binary search. The index also contains a pointer to the corresponding record of the actual table so that the fields not contained in the index can also be read.

The primary index is distinguished from the secondary indexes of a table. 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.



Table SCOUNTER in the flight model contains the assignment of the carrier counters to airports. The primary index on this table therefore consists of the key fields of the table and a pointer to the original data records.

You can also create further indexes on a table in the ABAP 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 sorting of the primary index for the access. Different indexes on the same table are distinguished with a three-place index identifier.

Unique Indexes

An entry in an index can refer to several records that have the same values for the index fields. A unique index does not permit these multiple entries. The index fields of a unique index thus have key function, that is they already uniquely identify each record of the table.

The primary index of a table is always a unique index since the index fields form the key of the table, uniquely identifying each data record.

You can define a secondary index as a unique index when you create it. This ensures that there are no double records in the table fields contained in the index. An attempt to maintain an entry violating this condition in the table results in termination due to a database error.

The accessing speed does not depend on whether or not an index is defined as a unique index. A unique index is simply a means of defining that certain field combinations of data records in a table are unique.



A unique index for a client-dependent table must contain the client field.



Creating Secondary Indexes

Procedure

1)In the maintenance screen of the table, choose Indexes
If indexes already exist on the table, a list of these indexes is displayed.
Choose Create(F5). .

2)In the next dialog box, enter the index ID and choose Continue( Enter)
The maintenance screen for indexes appears.

3)Enter an explanatory text in the field Short text.
You can then use the short text to find the index at a later time, for example
with the R/3 Repository Information System.

4)Select the table fields to be included in the index using the input help for the Field name column.
The order of the fields in the index is very important. See What to Keep in Mind for Secondary Indexes.

5)If the values in the index fields already uniquely identify each record of the table, select Unique index.
A unique index is always created in the database at activation because it also has a functional meaning (prevents double entries of the index fields).

6)If it is not a unique index, leave Non-unique index selected.
In this case you can use the radio buttons to define whether the index should be created for all database systems, for selected database systems or not at all in the database.

7)Select for selected database systems if the index should only be created for selected database systems.
Click on the arrow behind the radio buttons. A dialog box appears in which you can define up to 4 database systems with the input help. Select Selection list if the index should only be created on the given database systems. Select Exclusion list if the index should not be created on the given database systems. Choose Continue(ENter).

8)Choose Continue( Enter) .

Result

The secondary index is automatically created in the database during activation if the corresponding table was already created there and index creation was not excluded for the database system.

You can find information about the activation flow in the activation log, which you can call with Utilities -->Activation log. If errors occurred when activating the index, the activation log is automatically displayed.


How to Check if an Index is Used

Procedure

Open a second session and choose System>Utilities>Performance trace.

The Trace Requests screen appears.

Select Trace on.

The SQL trace is activated for your user, that is all the database operations under your user are recorded.

In the first window, perform the action in which the index should be used.

If your database system uses a cost-based optimizer, you should perform this action with as representative data as possible. A cost-based optimizer tries to determine the best index based on the statistics.

In the second session, choose Trace off and then Trace list.

Result

The format of the generated output depends on the database system used. You can determine the index that the database used for your action with the EXPLAIN function for the critical statements (PREPARE, OPEN, REPOPEN).

What to Keep in Mind for Secondary Indexes

How well an existing index supports data selection from a table largely depends on whether the data selected with the index represents the data that will ultimately be selected. This can best be shown using an example.

An index is defined on fields FIELD1, FIELD2, FIELD3 and FIELD4 of table BSPTAB in this order. This table is accessed with the SELECT statement:

SELECT * FROM BSPTAB WHERE FIELD1 = X1 AND FIELD2 = X2 AND FIELD4= X4.

Since FIELD3 is not specified more exactly, only the index sorting up to FIELD2 is of any use. If the database system accesses the data using this index, it will quickly find all the records for which FIELD1 = X1 and FIELD2 = X2. You then have to select all the records for which FIELD4 = X4 from this set.

The order of the fields in the index is very important for the accessing speed. The first fields should be those which have constant values for a large number of selections. During selection, an index is only of use up to the first unspecified field.

Only those fields that significantly restrict the set of results in a selection make sense for an index.

The following selection is frequently made on address file ADRTAB:

SELECT * FROM ADRTAB WHERE TITEL = ‘Prof.’ AND NAME = X AND VORNAME = Y.

The field TITLE would rarely restrict the records specified with NAME and FIRSTNAME in an index on NAME, FIRSTNAME and TITLE, since there are probably not many people with the same name and different titles. This would not make much sense in this index. An index on field TITLE alone would make sense for example if all professors are frequently selected.

Additional indexes can also 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.

For this reason, tables in which entries are very frequently written generally should only have a few indexes.

The database system sometimes does not use a suitable index for a selection, even if there is one. The index used depends on the optimizer used for the database system. You should therefore check if the index you created is also used for the selection (see How to Check if an Index is Used).).

Creating an additional index could also have side effects on the performance. This is because an index that was used successfully for selection might not be used any longer by the optimizer if the optimizer estimates (sometimes incorrectly) that the newly created index is more selective.

The indexes on a table should therefore be as disjunct 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.

Reward all helpfull answers

Regards

Pavan