FAGLF03 TFC_COMPARE_VZ Secondary index differs

Hi,
In the logs of TFC_COMPARE_VZ I find many accounts with difference in the upper portion and in lower portion I find many documents with the message "Secondary index differs. Account type: S $account number".
I've adjusted by executing TFC_ADJUST_VZ but still I find the same message.
I am not sure, what this message means and how it is affecting current documents or if it is an information or error?
I would appreciate if someone may share his/her own experience with similar situation.
Regards,
Amir

Hi Amir,
the error message 'secondary index differs' is most likely due to a change in the GL control settings, specifically, you have switched on/off 'Line item management' or 'open item management' for the account. As a result, the documents exist in the summary tables, but not the line item tables, e.g. BSIS. Try running report RFSEPA01 to generate the missing entries, it should resolve the problem.
Regards
Corinna

Similar Messages

What is the "No database index" means when you Creating Secondary Indexes?

HI,
   I'm Creating Secondary Indexes in the maintenance screen of the table(se11)
   There are three options under "Non-unique Index":
   1.Index on all database systems
   2.For selected database systems
   3.No database index
My questions is :
What do u mean by "No Database Index" and when is it used.
Can anybody plz tell me what's the difference of this three options ?
Here is what i found in the help:
   No database index: The index is not created in the database. If you
   choose this option for an index that already exists in the database,
   it is deleted when you activate this option.

Hi,
It is clear from the help documentation,
Here see what the help document says:
Create the index in the database (selection)
Whether an index improves or worsens performance often depends on the database system. You can therefore set whether an index defined in the ABAP Dictionary should be created in the database.
This makes it easier to install a platform-specific customer system.
You can set this option as follows:
1. Index in all database systems: The index is always created in the database.
2. In selected database systems: The index is created depending on the database system used. In this option, you must specify the databases in which the indexes are to be created. You can do this either on an inclusive (list of systems on which it should be created) or an exclusinve (list of systems on which it should not be created) basis. In either case, you can list up to four different database systems.
3. No database index:: The index is not created in the database. If you set this option for an index that already exists in the database, it is deleted when you activate the table in the ABAP Dictionary.
Note: Unique indexes have an extra function, and must therefore always be created in the database. The database system prevents entries or index fields being duplicated. Since programs may rely on this database function, you cannot delete unique indexes from the database.
Hope it helps you,
Regards,
Abhijit G. Borkar

Secondary Index vs Secondary Indices

Hi All,
In the earlier version already we have the primary index,secondary indexes,But now iam going through the enhancements in NW 7.0 In this they mentioned Secondary indices as the new enhancement with NW 7.0,I know how to create the Secondary indices ,But i am getting the conffusion between secondary indexes (already we have) and the new Secondary Indices,So please could any one elobarate this or atleast URL'S which are relavant to this topic,It would be very help full to me.
Thank you..
Srihasa

new index are just different at workbench level, but are the same at database level. You may assign them to a Y or Z package (instead of the sap package, it was seen as a modification of the standard). They also have a dedicated object directory entry (R3TR XINX). http://help.sap.com/saphelp_erp2005vp/helpdata/EN/85/685a41cdbf8047e10000000a1550b0/frameset.htm
[Note 1257033 - Cookbook: Modification/enhancement for standard SAP system|http://service.sap.com/sap/support/notes/1257033]

Secondary Index with or without MANDT field

HI ABAP Guru's,
What is necessary to add field MANDT while creation of secodary index in DBS.
But i some body my superiors challanged to me with out using MANDT our secoday index won't works.
But i tested few scenarios i am not get differnce.
please advice me exactly which scenarios it is mandatory.
Below are the Time taken with deffrent scnarios i created one test program to get the time with secondary index with out secodary index secondary index with mndat fiels
**&with out creation of seconday index
*1st time -57,103,681
2nd Time-55,388,294
**before creation of seconday index with out mandt
I1st time execution-324,119
2nd time progrm execution--391,134
3rd time progrm execution-327,046
4th time progrm execution336,774
5th time progrm execution359,100
6t time progrm execution-328,027
*before creation of seconday index with mandtiI1st time execution-367,623
2nd time progrm execution365,139
3rd-352,328
4th-369,122
5th-352,236
6th380,590
7th466,810
Thanks In Advance,
Kandula.
Edited by: Thomas Zloch on Nov 18, 2011 1:08 PM

Vishnu Tallapragada wrote:
So if you are maintaining multiple client data on the same database, then not adding MANDT to index will have undesirable effects as any select based on secondary index may return records that are not belonging to this client and deletes and additions on the index from multiple clients will lead to data integrity issues.
Wrong!
WHERE clause decides about data being selected, deleted or what-ever.
Index decides only about HOW data is accessed (if used), not WHAT data is accessed.
If your database returns a different result depending on the indexdefinition,
you should log a call at your DB vendor immediately, because this is a bug.
In general, as the client has usually only a small number of distinct values, it is not a good field,
to convince the database, that this index is a good idea. But on high volume tables it can be very selective
as far as the number of result records is concerned (might cut down 50% when 2 clients!).
In addition it is a very short field, so it should not cost much storage (esp. when compressable).
Szenario:
MANDT+IDX-Field with two clients and lets say 5000 record per client (so that idx access will be interesting),
assuming a given IDX value will return 50 records (25 in each client).
So the select will be
... WHERE MANDT=sy-mandt AND IDX=value
Accesing the index with only IDX will result in stepping down the index-tree (say 3 blocks) and then reading leafblocks
to get the 50 hits for IDX-value (assuming 30 records per leafblock -> 2 leafblocks required to gret the 50 records)
Right now you have accessed 5 blocks to get the address of 50 records that still need to be checked against MANDT.
So there is need to get 50 blocks (may be less, depending on clustering) to do a filter on MANDT
and get the final 25 records for the result.
If you put the MANDT field into the index it might require more space, so that we assume 20 records per leaf block now.
But since you can now filter MANDT already on the index blocks, you will again only need to get 5 blocks and
have the adress of the required 25 target records.
So getting the result is 55 blockinspections without MANDT in index and 30 blockinspections with MANDT in index in this case.
Now you can start pushing around values and statistics an calculate at what amount of data and average
size of resultsets it becomes right or wrong to include MANDT. It may turn out both ways, allthough I think
with MANDT being small, it is usually loss of brain cycles to calculate around for this.
You simply include it, it will cost only little space and it will never be wrong.
You leave it out, you will gain little space, but might end up with performance loss.
If you have only one client in the system, you can safely go with the saving space strategie, as long as you do not need
a UNIQUE secondary index.
Volker

What are the disadvantages of secondary index

Hi all,
Can anybody tell me what are the disadvantages of creating secondary index?
Also tell me what are the precautions should be taken to create a secondary index?

Hi Vinil,
You can search on SCN with the same subject... you will get lots of threads discussed on it...
Still for your reference...
secondary indices use disk space, not memory space. They are only in memory when they are used. Disk space is roughly width times number of records, can be GBs.
Main disadvantages are:
+ indexes are updated when table is changed, i.e. the additional index makes other operations slower. You must check the importance of your application, if it is much lower than the standard usage than you can not create a secondary index.
+ Secondary indices can confuse the database optimzer, especially if you use field which appear also in other indices. DB calculates usefulness of different indices by some assumptions (check other sources for details), if two indices are similar, than the assumptions can lead to wrong decisions. Your new index can be used for other statements, even when it is not optimal there. Result your index causes problems somewhere else!
Hope it will solve your problem..
Thanks & Regards
ilesh 24x7
ilesh Nandaniya

Help me with Points to be noted While creating a Secondary Index.

Hi,
There is a Secondary index created on a Z table which already have 9 secondary indexes. This is the 10th index that is created.
The Index is created as follows
MANDT             Client
DOCNUM_REF     Document number
The Table data is huge and it is more than 4Lakh records.
I have done the following analyses.
1) The fields to be used are not in any other indexes.
2) The Data is mostly different, i.e. The document reference field is having distinct data
select a~docnum a~werks_o a~docnum_ref a~natop
         a~m_icms a~m_ipi
         b~lgort_out b~mov_est
         b~item b~matnr
    appending table ti_requisicoes
    from zsytmm_reqnfcb as a
   inner join zsytmm_reqnfit as b
      on a~branch_o eq b~branch_o
     and a~requi    eq b~requi
     and a~mask     eq b~mask
     for all entries in ti_doc_saida_del
   where a~docnum_ref   eq ti_doc_saida_del-docnum.
What else I need to check , so that the index improves the performance. The table is using in 300 reports.

Ravishankar Lanjewar wrote:
@SAP LEARNER,
>
> There is a Secondary index created on a Z table which already have 9 secondary
> indexes. This is the 10th index that is created.
>
>
> I will not recommand to create index any more on this table. If you want to create secondary index for on above table which you have mention. You don't create index only for hamper of performance of single program/report.
>
> Don't create more than 4 to 5 index on sinlge table.
>
> Refere the tread Link:[Why to create Secondary index ?|Re: When is a secondary index used (in select or where)]
Sounds like another myth that is widely spread across SAP community.
Remember, complex systems like modern DBMS do not like generalizations. I personally know standard SAP tables with 9 standard secondary indexes. In the meantime the hardware became fast enough to update several secondary indexes without really significant problems. Of course indexes require space, of course one should create indexes that are not similar and differ from each other with more than one field for example. In other words, think before creating!
But it's again incorrect to say "do not create because you already have 9 others". You did not even ask what fields are in the affected table, what are the existing indexes.
Ravishankar Lanjewar wrote:
> I will recommand to delete all the index and create 4 to 5 fresh index while doing analysis for all SQL statement using where use list depends on where condition of SQL.
I am now trying to imagine the effort to analyze 300 reports using this table and all corresponding selects. And probably you will drop supporting indexes for several reports. Some of them may be CEO/CFO-relevant reports that will run minutes/hours instead of seconds. And I would like to see the reaction of CEO when he finds out that it was the result of your "optimization" activities.

Can we create secondary indexes in pooled and cluster table?

hello all
can we create secondary indexes in pooled and cluster table?

Hi,
Yes, you can.
Refer the below links
[http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm|http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm]
[http://help.sap.com/saphelp_40b/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm|http://help.sap.com/saphelp_40b/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm]
Regards,
SB

Reg. Secondary indexes

HI,
While using Secondary index,
If I am having a table and I set fields f3,f4,f5 as secondary index1, f6,f7,f8 as secondary index2, f9,f10,f11 as secondary index3 for using them for selecting fields for 3 different programs respectively.
Here i have some doubts---
For doing like this, will the table be affected performance wise? if yes how? Then what will be solution for using those fields?
pls suggest.
thanks
points will be awarded

Hi everyone,
I agree with Rob, in the sense I would not create any secondary indices on standard tables, if possible (unless recommended by a SAP note).
In Z tables -> well, the performance of SELECT statements for those fields is improved, for sure. But every time you want to INSERT/UPDATE/DELETE on the table, SAP takes more time to do the operation, because it has to populate the data in the table, and also update the indices. So be careful and check the performance on your test systems before transporting to productive environment.
I hope it helps. Best regards,
Alvaro

Creation of secondary indexes due to heavy flow of messages in ecc smq2

Hi gurus,
So we are facing smq2 issues from last 15 days in Ecc system due to some Time Limit Exceed and some times Object is Locked by the user xxxx
So finally we decided to go for creating seconday indexes in Ecc side , So here my question is there any thing required from Pi side while creating
Secondary indexes why i am asking this question is there is no issues From PI end after reaching to target(ECC) system only messages got stucking
in smq2 and facing issues .Below is the interface details.
ECC-FSCM
SAP ECC 6.0
FSCM
CreditCommitment_In and CreditCommitment_Out
CC_ProxySender_FSCM
CC_ProxyReceiver_FSCM
Plz reply back .
Regards
Madhu

If you had gone through the replies in your previous post, Iñaki Vilaand myself already provided the report name which needs to be scheduled to clear the messages in queues.
Plz provide the permanent fix for this issue

Difference between primary eindex and secondary index?

hi experts
pls answer me
difference between primary eindex and secondary index?
rewads apply.
thanks.
naresh.

hi,
check this link.
http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/frameset.htm
A difference is made between Primary & Secondary indexes to a table. the primary index consists of the key fields of the table and a pointer to the non-keys-fields of the table. The Primary index is generated automatically when a table is created and is created in the datebase as the same times as the table. It is also possible to define further indexes to a table in the ABAP/4 dictionary, which are then referred to as Secondary indexes.
Always it is not mandatory that an index should have all the key fields of a table. To see the index of a table
goto SE11->specify table name->click on the indexes... button on the application toolbar.
Based on your requirement you can you any of those index fields in the where clause of your query. Always its a better practice to use the index fields in the order specified. While selecting the records from a table it is always better to select the fields in the same order as specified in the table.

Regarding Secondary Index in a Table

hi
if i create a secondary index in a table is it obligatory or optional to have first field as MANDT (Client field) if the table is client dependent & how many secondary indexes(MAXIMUM) can be created for a table.
Regards

Hi,
Check the below Link
How to transport a secondary index on P master data table?
Hope this helps you.
Regards,
Anki Reddy

Regarding secondary index

how and when we create secondary indexes and what are the advantages and disadvantages of secondary indexes?

Hi
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
Regards

Secondary Index Select Statement Problem

Hi friends.
I have a issue with a select statement using secondary index,
SELECT SINGLE * FROM VEKP WHERE VEGR4 EQ STAGE_DOCK
                                  AND VEGR5 NE SPACE
                                  AND WERKS EQ PLANT
        %_HINTS ORACLE
        'INDEX("&TABLE&" "VEKP~Z3" "VEKP^Z3" "VEKP_____Z3")'.
given above statement is taking long time for processing.
when i check for the same secondary index in vekp table i couldn't see any DB index name with vekp~z3 or vekp^z3 or vekp____z3.
And the sy-subrc value after select statement is 4. (even though values avaliable in VEKP with given where condition values)
My question is why my select statement is taking long time and sy-subrc is 4?
what happens if a secnodary index given in select statement, which is not avaliable in that DB Table?

Hi,
> ONe more question: is it possible to give more than one index name in select statement.
yes you can:
read the documentation:
http://download.oracle.com/docs/cd/A97630_01/server.920/a96533/hintsref.htm#5156
index_hint:
This hint can optionally specify one or more indexes:
- If this hint specifies a single available index, then the optimizer performs
a scan on this index. The optimizer does not consider a full table scan or
a scan on another index on the table.
- If this hint specifies a list of available indexes, then the optimizer
considers the cost of a scan on each index in the list and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes from this list and merge the results, if such an
access path has the lowest cost. The optimizer does not consider a full
table scan or a scan on an index not listed in the hint.
- If this hint specifies no indexes, then the optimizer considers the
cost of a scan on each available index on the table and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes and merge the results, if such an access path
has the lowest cost. The optimizer does not consider a full table scan.
Kind regards,
Hermann

Using a byte[] as a secondary index's key within the Collection's API

I am using JE 4.1.7 and its Collections API. Overall I am very satisfied with the ease of using JE within our applications. (I need to know more about maintenance, however!) My problem is that I wanted a secondary index with a byte[] key. The key contains the 16 bytes of an MD5 hash. However, while the code compiles without error when it runs JE tell me
Exception in thread "main" java.lang.IllegalArgumentException: ONE_TO_ONE and MANY_TO_ONE keys must not have an array or Collection type: example.MyRecord.hash
See test code below. I read the docs again and found that the only "complex" formats that are acceptable are String and BigInteger. For now I am using String instead of byte[] but I would much rather use the smaller byte[]. Is it possible to trick JE into using the byte[]? (Which we know it is using internally.)
-- Andrew
package example;
import com.sleepycat.je.Environment;
import com.sleepycat.je.EnvironmentConfig;
import com.sleepycat.persist.EntityStore;
import com.sleepycat.persist.PrimaryIndex;
import com.sleepycat.persist.SecondaryIndex;
import com.sleepycat.persist.StoreConfig;
import com.sleepycat.persist.model.Entity;
import com.sleepycat.persist.model.PrimaryKey;
import com.sleepycat.persist.model.Relationship;
import com.sleepycat.persist.model.SecondaryKey;
import java.io.File;
@Entity
public class MyRecord {
@PrimaryKey
private long id;
@SecondaryKey(relate = Relationship.ONE_TO_ONE, name = "byHash")
private byte[] hash;
public static MyRecord create(long id, byte[] hash) {
MyRecord r = new MyRecord();
r.id = id;
r.hash = hash;
return r;
public long getId() {
return id;
public byte[] getHash() {
return hash;
public static void main( String[] args ) throws Exception {
File directory = new File( args[0] );
EnvironmentConfig environmentConfig = new EnvironmentConfig();
environmentConfig.setTransactional(false);
environmentConfig.setAllowCreate(true);
environmentConfig.setReadOnly(false);
StoreConfig storeConfig = new StoreConfig();
storeConfig.setTransactional(false);
storeConfig.setAllowCreate(true);
storeConfig.setReadOnly(false);
Environment environment = new Environment(directory, environmentConfig);
EntityStore myRecordEntityStore = new EntityStore(environment, "my-record", storeConfig);
PrimaryIndex<Long, MyRecord> idToMyRecordIndex = myRecordEntityStore.getPrimaryIndex(Long.class, MyRecord.class);
SecondaryIndex<byte[], Long, MyRecord> hashToMyRecordIndex = myRecordEntityStore.getSecondaryIndex(idToMyRecordIndex, byte[].class, "byHash");
// END

We have highly variable length data that we wish to use as keys. To avoid massive index sizes and slow key lookup we are using MD5 hashes (or something more collision resistant should we need it). (Note that I am making assumptions about key size and its relation to index size that may well inaccurate.)Thanks for explaining, that makes sense.
It would be the whole field. (I did consider using my own key data design using the @Persistent and @KeyField annotations to place the MD5 hash into two longs. I abandoned that effort because I assumed (again) that lookup with a custom key design would slower than the built-in String key implementation.)A composite key class with several long or int fields will not be slower than a single String field, and will probably result in a smaller key since the UTF-8 encoding is avoided. Since the byte array is fixed size (I didn't realize that earlier), this is the best approach.
--mark

When is a secondary index used (in select or where)

HI All,
We are confused (and new to ABAP) on the various postings on SDN concerning this topic. Replies seem to vary.
We have the following select statement:
SELECT date1 FROM table2
WHERE material (from a stored internal table) = material-table2
AND order (from a stored internal table) = order-table2
AND delivery method (from a stored internal table) = specific value of table2.
For a second index to be created, would we create the index for only date1 (since it's the only field we are selecting from table 2) or an index with date1, material, order, delivery method or just what's in the WHERE clause of material, order and delivery method?
How can you be sure that an index will be used?
Thank you!

> We are confused (and new to ABAP)
seem you are very very new.
Your question is actually not ABAP indexes etc are SQL and can be found in many textbooks also on Wiki pages. ABAP uses SQL, but does not change much.
The use index is determined nearly only by the WHERE clause. You want to know the phone number of somebody and you know the name and the address. The Index uses the name and the address as a telephone book. The phone number comes from the table not the index! This is not the secondary index, but the primary index.
If you search in the internet for phone number, then you can use also a secondary index, i.e. you know only the complete address but not the name. A phone book would not help here.
Which index is used, if often very simple as in the example, but can become very difficult. That is done by a sophisticated program of the database, the optimizer. Check other resoucres for details.
Siegfried

FAGLF03 TFC_COMPARE_VZ Secondary index differs

Similar Messages

Maybe you are looking for