Effect of Secondary Index on Performance Tuning

Hi,
I have a select statement with the below where statement.
WHERE keyz1 = IT_dfkkzk-keyz1
AND bldat IN s_pblda
AND valut IN s_pvalu.
Table from data is accessed Primary key is a combination of two fields KEYZ1 & POSZA.
We have a Secondary Index with OPBEL & KEYZ1.
Will Optimizer will use Secondary Index?
If we change the where statement as given Below
WHERE keyz1 = IT_dfkkzk-keyz1
Will the access be fast?
Should i create a secondary index on keyz1 to make it fast?
Thanks & Reagrds
Lijo Joseph

Hi Lijo Joseph,
I think, optimizer will use primary key because "WHERE keyz1" references the first part of this key. Even if you change your WHERE-statement as considered, this will not change optimizer approach.
And yes, this access should be the fastest way to access you data, besides you have more values to reduce the amount of resulting rows. For example if you could specifiy POSZA too, this would accelerate access.
Creation of another secondary index on keyz1 will not make it faster, maybe if you include bldat and valut in this key. But notice, insertion and modification of data will then be slower.
To get optimizer to use existing secondary index you have to specify OPBEL in your where condition like this:
"where OPBEL = 'X' and KEYZ1 = ....."
Herbert

Similar Messages

  • Regarding Indexes and performance tuning.

    Hi Everyone,
    I need some elaborate explanation about indexes and performance tuning.
    1. How do you find out whether the select query which I write is utilizing the indexes .
    2. Is it true that the sequence in which the indexes are defined in se11
      for eg:  MANDT
                 KNUMH
                 KOPOS
    your select query should also have the same sequence in the where clause else the indexes are not utilized well .
    3. Is there any precautions/ special method to write select queries for proper utilization of indexes.
    Thanks to all reading and answering in advance.
    Rgds,
    Anu.

    Hi
    You will find like this
    If your select like this
    select matnr mtart from mara into<itab>
    where matnr = <>..
    Go to table and see mara ..if matnr is checked as primary key,then you are using primary index.
    Check secondary index tab and see if any fields,if those fields you are using in select then you are using secondary index.
    2.Not sequence,check how many fields are checked tick as primary key,all thsoe are index.
    3.Always try to use proper primary index in select statment and avoid nested select statements.
    Thanks

  • How to combine spatial and secondary index, when extracting?

    Hi spatiallers,
    vers.: (32 bit) Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production on Sun/SunOS 5.8 (64 bit)
    In our DataWarehouse the table topo_geodata stores all topographic data in Denmark. The table has a spatial index (QT) on its SDO_geometry column named utm_geo as well as a primary key on the column topo_geo_id and 4 secondary indexes on other columns.
    The query to find all geomtries in a given munipalicy is as follows
    select count(*) as antal_AnyInteract_topo_geodata
    from topo_geodata k, topo_geodata tg
    where SDO_RELATE(tg.utm_geo, k.utm_geo, 'mask=AnyInteract querytype= WINDOW') = 'TRUE'
    and k.topo_geo_id = 961 -- geometry of a municipality
    and it returns a count of 19445 in 4 minuttes. However our users are only interested in extracting certain object types, that is a very small subselection of the 19445 geometries. The subselection is typically based on some value or a range of values in the secondary indexed columns.
    Question: How can I make the SELECT use a combination of the spatial index index and a secondary index?
    Only when a pinpoint 1 particular value of the primary key do I get fast response. When pinpointing 1 value in a secondary index as in
    select count(*) as antal1
    from topo_geodata k, topo_geodata tg
    where SDO_RELATE(tg.utm_geo, k.utm_geo, 'mask=AnyInteract querytype= WINDOW') = 'TRUE'
    and k.topo_geo_id = 961 -- Gladsaxe
    and tg.mtk_obj_id = 58476 -- has secondary index
    the performance deteriorates back to 4 min., and the queryplan shows some weird bitmap conversion followed by a bitmap-and operation.
    - Thanks in advance,
    Jens Ole Jensen
    Kort & MatrikelStyrelsen (WWW: http://www.kms.dk)
    Danmark

    Hi Jens,
    I'm not sure I understand the question, or what it is that works fast.
    In this case, the SDO_RELATE with the anyinteract mask has to be done first.
    If this takes 4 minutes, then adding additional criteria to reduce the amount of
    data returned from that subset will only add time.
    The spatial portion of the query has to be done using the spatial index, which is
    a monolithic index for the whole table, so all of the geometry data has to be searched,
    and the anyinteract applied to all of this data.
    After that set of rows comes back, then the additional predicate is applied.
    I'm not sure what this means:
    Only when a pinpoint 1 particular value of the primary key do I get fast response. You do have a few options to try to make things work faster:
    If queries included additional predicates on mtk_obj_id, you might try
    to use range partitioning.
    If the predicates on mtk_obj_id is very selective, then you might want to select
    values based on that column, then use sdo_geom.relate between that very
    small subset and the query window.
    Hope this helps, and all is well with you.
    Dan

  • Very SLOW IOT secondary indexes performance ORACLE 9i

    Hi all,
    Is it TRUE that in ORACLE 9i version secondary IOT table indexes are
    extremely slow?
    I created IOT table of 250 million rows with no OWERFLOW segment
    I created secondary index, altered it updating its block references
    Now i have that it takes about 12 minutes to get rows using that index on IOT table
    And it takes about 14 seconds in regular heap-table using the same index
    Is it of the same opera that Oracle states: that secondary indexes on IOT table
    are similar to regular indexes on performance. but in reality they are significantly slower?
    Does anyone had such situation?
    What can be done to speed up access?
    Thanks for answers.

    Hi all,
    Is it TRUE that in ORACLE 9i version secondary IOT table indexes are
    extremely slow?
    I created IOT table of 250 million rows with no OWERFLOW segment
    I created secondary index, altered it updating its block references
    Now i have that it takes about 12 minutes to get rows using that index on IOT table
    And it takes about 14 seconds in regular heap-table using the same index
    Is it of the same opera that Oracle states: that secondary indexes on IOT table
    are similar to regular indexes on performance. but in reality they are significantly slower?
    Does anyone had such situation?
    What can be done to speed up access?
    Thanks for answers.

  • How to improve select stmt performance without going for secondary index

    Hi friends,
    I have a select statement which does not contains key fields(Primary index) in where condition. And I have to improve that select stmt performance without going for the secondary indexes.
    Can you plese suggest the alternative way for this?.
    Thanks in advance,
    Ramesh.

    Hi,
    If , possible create a secondary index opf your own But if you have restriction on this, try to arrange the fields in where clause in the same order as they appear in the very table.
    This will help the performance a bit.
    Another issue, If your table doesn't contain any critical data or data in them are not updated frequently, you may go for Bufferring . it is a good alternate of Indexing with above limitations.
    For details in bufferring , check, and all the sublinks.
    [concept of buffering|http://help.sap.com/saphelp_nw04/helpdata/en/cf/21f244446011d189700000e8322d00/content.htm]
    Regards,
    Anirban

  • Database tableAUFM hitting is taking much time even secondary index created

    Hi Friends,
       There is report for Goods movement rel. to Service orders + Acc.indicator.
       We have  two testing Systems(EBQ for developer and PEQ from client side).
       EBQ system contains replica of PEQ every month.
       This report is not taking much time in EBQ.But it is taking much time in PEQ.For the selection criteria I have given,both systems  have same data(Getting same output).
    The report has the follwoing fields on the selection criteria:
    A_MJAHR     Material Doc. Year (Mandatory)
    S_BLDAT     Document Date(Optional)
    S_BUDAT     Posting Date(Optional)
    S_LGORT     Storage Location(Optional)
    S_MATNR     Material(Optional)
    S_MBLNR     Material Documen(Optional)t
    S_WERKS     Plant(Optional)
    Client not agrrying to make Material Documen as Mandatory.
    The main (first) table hit is on AUFM table .As there are non-key fileds as well in where condition,We have cretaed a secondary index as well for AUFM table on the following fields:
    BLDAT
    BUDAT
    MATNR
    WERKS
    LGORT 
    Even then also ,in PEQ sytem the report is taking very long time ,Some times not even getting the ALV output.
    What can be done to get teh report executed very fast.
    <removed by moderator>
    The part of report Soure code is as below:
    <long code part removed by moderator>
    Thanks and Regards,
    Rama chary.P
    Moderator message: please stay within the 2500 character limit to preserve formatting, only post relevant portions of the code, also please read the following sticky thread before posting.
    Please Read before Posting in the Performance and Tuning Forum
    locked by: Thomas Zloch on Sep 15, 2010 11:40 AM

    Hi Friends,
       There is report for Goods movement rel. to Service orders + Acc.indicator.
       We have  two testing Systems(EBQ for developer and PEQ from client side).
       EBQ system contains replica of PEQ every month.
       This report is not taking much time in EBQ.But it is taking much time in PEQ.For the selection criteria I have given,both systems  have same data(Getting same output).
    The report has the follwoing fields on the selection criteria:
    A_MJAHR     Material Doc. Year (Mandatory)
    S_BLDAT     Document Date(Optional)
    S_BUDAT     Posting Date(Optional)
    S_LGORT     Storage Location(Optional)
    S_MATNR     Material(Optional)
    S_MBLNR     Material Documen(Optional)t
    S_WERKS     Plant(Optional)
    Client not agrrying to make Material Documen as Mandatory.
    The main (first) table hit is on AUFM table .As there are non-key fileds as well in where condition,We have cretaed a secondary index as well for AUFM table on the following fields:
    BLDAT
    BUDAT
    MATNR
    WERKS
    LGORT 
    Even then also ,in PEQ sytem the report is taking very long time ,Some times not even getting the ALV output.
    What can be done to get teh report executed very fast.
    <removed by moderator>
    The part of report Soure code is as below:
    <long code part removed by moderator>
    Thanks and Regards,
    Rama chary.P
    Moderator message: please stay within the 2500 character limit to preserve formatting, only post relevant portions of the code, also please read the following sticky thread before posting.
    Please Read before Posting in the Performance and Tuning Forum
    locked by: Thomas Zloch on Sep 15, 2010 11:40 AM

  • Building secondary Index fails for large number(25,000,000) of records

    I am inserting 25,000,000 records of the type:
    Key --> Data
    [long,String,long] --> [{long,long}, {String}}
    using setSecondaryBulkLoad(true) and then build two Secondary indexes on {long,long} and {String} of the data portion.
         private void buildSecondaryIndex(DataAccessLayer dataAccessLayer ) {
              try {
                   SecondaryIndex<TDetailSecondaryKey, TDetailStringKey, TDetailStringRecord> secondaryIndex = store.getSecondaryIndex(dataAccessLayer.getPrimaryIndex(), TDetailSecondaryKey.class, SECONDARY_KEY_NAME);
              } catch (DatabaseException e) {
                   throw new RuntimeException(e);
    It fails when I build the SecondaryIndex probably due to Java Heap Space Error. See the failure trace below.
    I do not face this problem when I deal with 250,000 records.
    Is there a work around that without haveing to set the memory space configurations of the JVM.
    Failure Trace:
    java.lang.RuntimeException: Environment invalid because of previous exception: com.sleepycat.je.RunRecoveryException
         at com.infobionics.ibperformance.TDetailStringDAOInsertTest.buildSecondaryIndex(TDetailStringDAOInsertTest.java:444)
         at com.infobionics.ibperformance.TDetailStringDAOInsertTest.insertCellSetInOneTxn(TDetailStringDAOInsertTest.java:280)
         at com.infobionics.ibperformance.TDetailStringDAOInsertTest.mainTest(TDetailStringDAOInsertTest.java:93)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
         at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
         at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
         at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
         at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
         at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
         at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
         at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
         at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
         at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
         at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
         at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
         at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
         at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
         at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
         at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
    Caused by: Environment invalid because of previous exception: com.sleepycat.je.RunRecoveryException
         at com.sleepycat.je.dbi.EnvironmentImpl.checkIfInvalid(EnvironmentImpl.java:976)
         at com.sleepycat.je.log.LogManager.getLogEntry(LogManager.java:584)
         at com.sleepycat.je.txn.Txn.undo(Txn.java:713)
         at com.sleepycat.je.txn.Txn.abortInternal(Txn.java:631)
         at com.sleepycat.je.txn.Txn.abort(Txn.java:599)
         at com.sleepycat.je.txn.AutoTxn.operationEnd(AutoTxn.java:36)
         at com.sleepycat.je.Environment.openDb(Environment.java:505)
         at com.sleepycat.je.Environment.openSecondaryDatabase(Environment.java:382)
         at com.sleepycat.persist.impl.Store.openSecondaryIndex(Store.java:684)
         at com.sleepycat.persist.impl.Store.getSecondaryIndex(Store.java:579)
         at com.sleepycat.persist.EntityStore.getSecondaryIndex(EntityStore.java:286)
         at com.infobionics.ibperformance.TDetailStringDAOInsertTest.buildSecondaryIndex(TDetailStringDAOInsertTest.java:441)
         ... 22 more
    Caused by: java.lang.OutOfMemoryError: Java heap space
         at java.util.HashMap.resize(HashMap.java:462)
         at java.util.HashMap.addEntry(HashMap.java:755)
         at java.util.HashMap.put(HashMap.java:385)
         at java.util.HashSet.add(HashSet.java:200)
         at com.sleepycat.je.txn.Txn.addReadLock(Txn.java:964)
         at com.sleepycat.je.txn.Txn.addLock(Txn.java:952)
         at com.sleepycat.je.txn.LockManager.attemptLockInternal(LockManager.java:347)
         at com.sleepycat.je.txn.SyncedLockManager.attemptLock(SyncedLockManager.java:43)
         at com.sleepycat.je.txn.LockManager.lock(LockManager.java:178)
         at com.sleepycat.je.txn.Txn.lockInternal(Txn.java:295)
         at com.sleepycat.je.txn.Locker.nonBlockingLock(Locker.java:288)
         at com.sleepycat.je.dbi.CursorImpl.lockLNDeletedAllowed(CursorImpl.java:2357)
         at com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2297)
         at com.sleepycat.je.dbi.CursorImpl.fetchCurrent(CursorImpl.java:2227)
         at com.sleepycat.je.dbi.CursorImpl.getCurrentAlreadyLatched(CursorImpl.java:1296)
         at com.sleepycat.je.dbi.CursorImpl.getNextWithKeyChangeStatus(CursorImpl.java:1442)
         at com.sleepycat.je.dbi.CursorImpl.getNext(CursorImpl.java:1368)
         at com.sleepycat.je.Cursor.retrieveNextAllowPhantoms(Cursor.java:1587)
         at com.sleepycat.je.Cursor.retrieveNext(Cursor.java:1397)
         at com.sleepycat.je.SecondaryDatabase.init(SecondaryDatabase.java:182)
         at com.sleepycat.je.SecondaryDatabase.initNew(SecondaryDatabase.java:118)
         at com.sleepycat.je.Environment.openDb(Environment.java:484)
         at com.sleepycat.je.Environment.openSecondaryDatabase(Environment.java:382)
         at com.sleepycat.persist.impl.Store.openSecondaryIndex(Store.java:684)
         at com.sleepycat.persist.impl.Store.getSecondaryIndex(Store.java:579)
         at com.sleepycat.persist.EntityStore.getSecondaryIndex(EntityStore.java:286)
         at com.infobionics.ibperformance.TDetailStringDAOInsertTest.buildSecondaryIndex(TDetailStringDAOInsertTest.java:441)
         at com.infobionics.ibperformance.TDetailStringDAOInsertTest.insertCellSetInOneTxn(TDetailStringDAOInsertTest.java:280)
         at com.infobionics.ibperformance.TDetailStringDAOInsertTest.mainTest(TDetailStringDAOInsertTest.java:93)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    1. Does the speed of building of secondary index
    depend on the type of the data in the key? Will
    having integers in secondary key as opposed to string
    be better?The byte size of the key and data is significant of course, but the data type is not.
    2. How much are we bound of the memory? Lets assume
    my memory setting is fixed.
    a. I know with current memory settings if I set txn
    n on, I have java Heap Error.
    So will I be limited on the size of
    secondary index or
    will it just get really slow swapping
    tree information from the disk as it builds it.No. The out-of-memory error was caused by a very large transaction that holds locks. When using small transactions or non-transactional access, you won't have this problem. In general, like most databases, JE writes and reads information to/from disk as needed.
    b. Is there any other way of speeding the build of
    f secondary database?No, other then general performance tuning, nothing I know of.
    c. Will it be more beneficial not to bulk
    load when the datasize gets large
    so that secondary database is built
    incrementally?It's up to you whether you want to pay the price during an initial load or incrementally.
    d. Do you think it will help to partition the
    e original database into smaller databases
    using some criteria, and thus build
    smaller trees.          Why? You can use deferred write or non-transactional access to load any size database.
    The only weak point in this is if we have to bulk
    bulk load in one partition
    at some time increasing its size we may
    face the same problem againFace what problem?
    --mark                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Q1: Secondary Index. Q2: Fiscal Year /Period

    Hi gurus,
    I have two questions need your explain:
    Q1: To improve the query performance I am going to create some secondary indexes on an ODS, I am wondering whether this action will remove the data from the ODS therefore I have to reset the data loading process and if these indexes can be maintained while data loading automatically ?
    Q2: About fiscal year /period which technical name is 0fiscper. we know in sales order header, item also purchase order and billing ODS or CUBEs, FY/Period are existed in those models. but there are still some other dates e.g. delivery date, goods issue date, goods recieve date, document date, posting date and so on. So which date is used to generate FY/Period ?
    Thanks in advance
    Edited by: Leon Ouyang on Dec 3, 2008 4:27 PM
    Edited by: Leon Ouyang on Dec 4, 2008 1:26 AM

    Hi,
    1)The creation of index have no effect on the data stored and you need not delete or relaod the data.
    System will adjust the index with every data load to the DSO automatically.
    2)Fiscal year period depeneds upon the module from which you are using the data and you can tweak the logic for this suit your need.
    If the data source is providing the fiscal period values then well and good.
    If not then generally its mapped to those dates which are driving date of the query or the date which is going to be used by the user for the input selections in the report.
    for example if you want sales based on the posting date in the reports and user just wnt sale till month and not date then.......you map posting date to fiscal period in the transformation and use them in the reporting.
    This can vary too...there is no hard fast rule for what date it should be mapped...and it all depends upon the reporting requirement
    The good design practise is to fill it with the same date which is filling calday and calmonth objects.This will keep granuarlty as same...but if you want some other selection in the report then you can map calday to some other date and fiscal period to some thing else.
    Ajeet

  • Secondary index on vbfa table

    I have very expensive statement running against VBFA table. It comes from a customer report and doing SQL:
    SELECT /*+ FIRST_ROWS */ "VBELV"
    FROM "VBFA"
    WHERE "MANDT" = :A0 AND "VBELN" = :A1 AND ROWNUM <= :A2
    It has execution plan:
    SELECT STATEMENT ( Estimated Costs = 96.009 , Estimated #Rows = 41 )
    |
    --- COUNT STOPKEY
    |
    INDEX RANGE SCAN VBFA~0
    As you can see it is very expensive statement because VBFA is huge table and because I have only VBFA~0 index with columns:
    UNIQUE Index VBFA~0
    COLUMN DISTINCT VALUES
    MANDT      1
    VBELV       1.589.207
    POSNV      4.184
    VBELN       3.202.114
    POSNN       58.173
    VBTYP_N    18
    In order to improve performance of this report , would you recomend creating secondary index and would it be on columns: MANDT, VBELN, VBELV
    I have not seen this type of secondary index in SAP community (most of the time I see sec.index on mandt, vbeln and posnn columns) so that is why I want to double check it before I deploy it.
    Regards,
    Andrija

    Hi,
    Indexes speed up access to rows in a table. They can be created for a single column or for a series of columns.
    MANDT AND VBELN does not have index then create indexes on these columns.
    The explain statement can be used to check the effect of creating or deleting indexes (see index) on the choice of search strategy for the specified SQL statement. You can also estimate the time needed by the database system to process the specified SQL statement. The specified QUERY or SINGLE SELECT statement is not executed while the EXPLAIN statement is being executed.
    To be frank to analyze you shd generate trace file and you need to analyze.
    Oracle claims that <b>first_rows_n</b> optimization results in faster response time for certain queries, we must remember that the performance is achieved via a change to the costing.
    Use the FIRST_ROWS hint when you need only the first few hits of a query. When you need the entire result set, do not use this hint as it might result in poorer performance.
    So collect stats,Analyze table create index your query will execute faster.
    Analyze in trace file generated.Want to know indexes are used or not have a look on Explain Plan.
    Regards
    Vinod

  • 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

  • Query performance tuning beyond entity caching

    Hi,
    We have an extremely large read-only dataset stored using BDB-JE DPL. I'm seeking to tune our use of BDB while querying, and I'm wondering what options we have beyond simply attempting to cache more entities? Our expected cache hit rate is low. Can I tune things to keep more of the btree nodes and other internal structures buffered? What kind of configuration parameters should I be looking at?
    Thanks,
    Brian

    No, you don't have to preload the leaf nodes. But if you don't preload the secondary at all, you'll see more I/O when you read by secondary index.
    If you don't have enough cache to load leaf nodes, you should not call setLoadLNs(true), for primary or secondary DBs. Instead, try to load the internal nodes for all DBs if possible. You can limit the time taken by preload using PreloadConfig.
    I strongly suspect that the primary DB loads faster because it is probably written in key order, while the secondaries are not.
    The LRU-only setting is an environment wide setting and should apply to all databases, that is not a problem. If you are doing random access in general, this is the correct setting.
    Please use preload to reduce the amount of I/O that you see in the environment stats. If performance is still not adequate, you may want to look at the IO subsystem you're using -- do you know what you're getting for seek and read times? Also, you may want to turn on the Java verbose GC option and see if full GCs are occurring -- if so, tuning the Java GC will be necessary.
    --mark                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Three questions about the creation of secondary indexes in ODS design mode

    1. When we right click the Indexes folder in ODS design to select Create to create the Index folder 010, a small window pops up with a check box called "Unique", do we have to check this checkbox to create folder 010?
    2. If we would like to include 3 InfoObjects into the secondary indexes, then how many folders we need to create? Need to create 3 folders like 010, 020, and 030 and place the 3 InfoObj. into the 3 folder respectively or create only one folder 010 and place all the 3 InfoObj. into this one folder 010?
    3. In SAP documentation titled "BW Performance Tuning" about the Indices, it says "If the (uncompressed) F fact table is small, it is usually faster to drop the secondary (bitmap) indices before the load and build them up after the load"
    Someone here says secondary index is only for ODS other than for cubes, but from the above statement, F fact table is related to cubes, then how to explain it? Also the above statement is talking above the variant in process chain that when you bring in a variant to load data to cube, then the drop index and generate index variants will be automatically created, does it refer to this? And what's bitmap index?
    Thanks in advance and we will continue to give you reward points!

    Hi Kevin,
    Cube has Secondary index's. The index's that we find in the Manage of the Cube are the Secondary Index's. Please check the following link for more information.
    http://help.sap.com/saphelp_erp2004/helpdata/en/80/1a6473e07211d2acb80000e829fbfe/frameset.htm
    Also, to know about Unique indexes, use the following link
    http://help.sap.com/saphelp_erp2004/helpdata/en/9b/c743f5b40711d194f900a0c929b3c3/frameset.htm
    "The indexes displayed are the secondary indexes of the F and E fact tables for the InfoCube. The primary indexes and those defined by the user are not displayed. " (SAP help).
    This should answer your questions.
    Regards,
    Praveen.

  • Performance tuning: lite sessions and local ServletContext

    I have been doing some research on iPlanet performance tuning. In our
    current production environment (iAS6.0 SP1B, iWS4.1 SP2 on Solaris), since
    we don't use clustering there should be a couple of performance improvements
    we can make immediately:
    1. Use lite sessions (<session-impl>lite</session-impl> in ias-web.xml) - I
    believe that if you use lite sessions, the session data is stored in the kjs
    process space as opposed to the kxs process space. This, of course, means
    that if a kjs dies the user's on it will lose their session information but
    it will provide a performance improvement by reducing kxs/kjs communication.
    2. Use local ServletContexts (<distributable>false</distributable> in
    web.xml) - This should cause the ServletContext to only be stored in the
    originating JVM. So again, if a kjs dies, the user will lose their
    ServletContext but again we will get a performance improvement by reducing
    kxs/kjs communcation.
    What I want to understand is how our load balancing configuration will
    effect our production environment if we use this configuration. Right now
    we use sticky load balancing on all our servlets but we don't have our JSPs
    registered and therefore sticky load balancing cannot always be trusted to
    return users to the iAS they came from. We make up for this by using
    hardware load balancing that keeps the majority of our users sticky.
    However, using lite sessions and local ServletContexts will require that a
    user not only stick to an iAS, but to a specific kjs as well. Using sticky
    load balancing would ensure that, but since we also rely on our hardware
    load balancers, could they create a problem? If a user gets sent back to
    the iAS they came from by our hardware load balancers, will the kxs process
    be smart enough to return them to the kjs they came from? If so, then I
    think that means that we can safely switch to lite sessions and local
    ServletContexts, but if not, I think many users will lose their sessions.
    Thanks,
    Linc

    Please follow thru this link for your answers
    http://developer.iplanet.com/viewsource/char_tuningias/index.jsp
    Thanks
    Shital Patel
    Lincoln wrote:
    I have been doing some research on iPlanet performance tuning. In our
    current production environment (iAS6.0 SP1B, iWS4.1 SP2 on Solaris), since
    we don't use clustering there should be a couple of performance improvements
    we can make immediately:
    1. Use lite sessions (<session-impl>lite</session-impl> in ias-web.xml) - I
    believe that if you use lite sessions, the session data is stored in the kjs
    process space as opposed to the kxs process space. This, of course, means
    that if a kjs dies the user's on it will lose their session information but
    it will provide a performance improvement by reducing kxs/kjs communication.
    2. Use local ServletContexts (<distributable>false</distributable> in
    web.xml) - This should cause the ServletContext to only be stored in the
    originating JVM. So again, if a kjs dies, the user will lose their
    ServletContext but again we will get a performance improvement by reducing
    kxs/kjs communcation.
    What I want to understand is how our load balancing configuration will
    effect our production environment if we use this configuration. Right now
    we use sticky load balancing on all our servlets but we don't have our JSPs
    registered and therefore sticky load balancing cannot always be trusted to
    return users to the iAS they came from. We make up for this by using
    hardware load balancing that keeps the majority of our users sticky.
    However, using lite sessions and local ServletContexts will require that a
    user not only stick to an iAS, but to a specific kjs as well. Using sticky
    load balancing would ensure that, but since we also rely on our hardware
    load balancers, could they create a problem? If a user gets sent back to
    the iAS they came from by our hardware load balancers, will the kxs process
    be smart enough to return them to the kjs they came from? If so, then I
    think that means that we can safely switch to lite sessions and local
    ServletContexts, but if not, I think many users will lose their sessions.
    Thanks,
    Linc

  • Performance Tuning Tips

    Dear All,
    In our project we are facing lot of problems with the Performance, users are compaining about the poor performance of the few reports and all, we are in the process of fine tuning the reports by following the all methods/suggestions provided by SAP ( like removing the select queries from Loops, For all entries , Binary serach etc )
    But still I want to know from you people what can we check from BASIS percpective ( all the settings ) and also ABAP percpective to improve the performance.
    And also I have one more query that what is " Table Statistics " , what is the use of this ...
    Please give ur valueble suggestions to us in improving the performance .
    Thanks in Advance !

    Hi
    <b>Ways of Performance Tuning</b>
    1.     Selection Criteria
    2.     Select Statements
    •     Select Queries
    •     SQL Interface
    •     Aggregate Functions
    •     For all Entries
    Select Over more than one Internal table
    <b>Selection Criteria</b>
    1.     Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement. 
    2.     Select with selection list.
    <b>Points # 1/2</b>
    SELECT * FROM SBOOK INTO SBOOK_WA.
      CHECK: SBOOK_WA-CARRID = 'LH' AND
             SBOOK_WA-CONNID = '0400'.
    ENDSELECT.
    The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
    SELECT  CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
      WHERE SBOOK_WA-CARRID = 'LH' AND
                  SBOOK_WA-CONNID = '0400'.
    <b>Select Statements   Select Queries</b>
    1.     Avoid nested selects
    2.     Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
    3.     When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
    4.     For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit. 
    5.     Use Select Single if all primary key fields are supplied in the Where condition .
    <b>Point # 1</b>
    SELECT * FROM EKKO INTO EKKO_WA.
      SELECT * FROM EKAN INTO EKAN_WA
          WHERE EBELN = EKKO_WA-EBELN.
      ENDSELECT.
    ENDSELECT.
    The above code can be much more optimized by the code written below.
    SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
        FROM EKKO AS P INNER JOIN EKAN AS F
          ON PEBELN = FEBELN.
    Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops  only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
    <b>Point # 2</b>
    SELECT * FROM SBOOK INTO SBOOK_WA.
      CHECK: SBOOK_WA-CARRID = 'LH' AND
             SBOOK_WA-CONNID = '0400'.
    ENDSELECT.
    The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
    SELECT  CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
      WHERE SBOOK_WA-CARRID = 'LH' AND
                  SBOOK_WA-CONNID = '0400'.
    <b>Point # 3</b>
    To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields . In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
    <b>Point # 4</b>
    SELECT * FROM SBOOK INTO SBOOK_WA
      UP TO 1 ROWS
      WHERE CARRID = 'LH'.
    ENDSELECT.
    The above code is more optimized as compared to the code mentioned below for testing existence of a record.
    SELECT * FROM SBOOK INTO SBOOK_WA
        WHERE CARRID = 'LH'.
      EXIT.
    ENDSELECT.
    <b>Point # 5</b>
    If all primary key fields are supplied in the Where condition you can even use Select Single.
    Select Single requires one communication with the database system, whereas Select-Endselect needs two.
    <b>Select Statements           contd..  SQL Interface</b>
    1.     Use column updates instead of single-row updates
    to update your database tables.
    2.     For all frequently used Select statements, try to use an index.
    3.     Using buffered tables improves the performance considerably.
    <b>Point # 1</b>
    SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
      SFLIGHT_WA-SEATSOCC =
        SFLIGHT_WA-SEATSOCC - 1.
      UPDATE SFLIGHT FROM SFLIGHT_WA.
    ENDSELECT.
    The above mentioned code can be more optimized by using the following code
    UPDATE SFLIGHT
           SET SEATSOCC = SEATSOCC - 1.
    <b>Point # 2</b>
    SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
      WHERE CARRID = 'LH'
        AND CONNID = '0400'.
    ENDSELECT.
    The above mentioned code can be more optimized by using the following code
    SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
      WHERE MANDT IN ( SELECT MANDT FROM T000 )
        AND CARRID = 'LH'
        AND CONNID = '0400'.
    ENDSELECT.
    <b>Point # 3</b>
    Bypassing the buffer increases the network considerably
    SELECT SINGLE * FROM T100 INTO T100_WA
      BYPASSING BUFFER
      WHERE     SPRSL = 'D'
            AND ARBGB = '00'
            AND MSGNR = '999'.
    The above mentioned code can be more optimized by using the following code
    SELECT SINGLE * FROM T100  INTO T100_WA
      WHERE     SPRSL = 'D'
            AND ARBGB = '00'
            AND MSGNR = '999'.
    <b>Select Statements       contd…           Aggregate Functions</b>
    •     If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
    Some of the Aggregate functions allowed in SAP are  MAX, MIN, AVG, SUM, COUNT, COUNT( * )
    Consider the following extract.
                Maxno = 0.
                Select * from zflight where airln = ‘LF’ and cntry = ‘IN’.
                 Check zflight-fligh > maxno.
                 Maxno = zflight-fligh.
                Endselect.
    The  above mentioned code can be much more optimized by using the following code.
    Select max( fligh ) from zflight into maxno where airln = ‘LF’ and cntry = ‘IN’.
    <b>Select Statements    contd…For All Entries</b>
    •     The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
         The plus
    •     Large amount of data
    •     Mixing processing and reading of data
    •     Fast internal reprocessing of data
    •     Fast
         The Minus
    •     Difficult to program/understand
    •     Memory could be critical (use FREE or PACKAGE size)
    <u>Points to be must considered FOR ALL ENTRIES</u> •     Check that data is present in the driver table
    •     Sorting the driver table
    •     Removing duplicates from the driver table
    Consider the following piece of extract
    Loop at int_cntry.
           Select single * from zfligh into int_fligh
    where cntry = int_cntry-cntry.
    Append int_fligh.
    Endloop.
    The above mentioned can be more optimized by using the following code.
    Sort int_cntry by cntry.
    Delete adjacent duplicates from int_cntry.
    If NOT int_cntry[] is INITIAL.
                Select * from zfligh appending table int_fligh
                For all entries in int_cntry
                Where cntry = int_cntry-cntry.
    Endif.
    <b>Select Statements    contd…  Select Over more than one Internal table</b>
    1.     Its better to use a views instead of nested Select statements.
    2.     To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
    3.     Instead of using nested Select loops it is often better to use subqueries.
    <b>Point # 1</b>
    SELECT * FROM DD01L INTO DD01L_WA
      WHERE DOMNAME LIKE 'CHAR%'
            AND AS4LOCAL = 'A'.
      SELECT SINGLE * FROM DD01T INTO DD01T_WA
        WHERE   DOMNAME    = DD01L_WA-DOMNAME
            AND AS4LOCAL   = 'A'
            AND AS4VERS    = DD01L_WA-AS4VERS
            AND DDLANGUAGE = SY-LANGU.
    ENDSELECT.
    The above code can be more optimized by extracting all the data from view DD01V_WA
    SELECT * FROM DD01V INTO  DD01V_WA
      WHERE DOMNAME LIKE 'CHAR%'
            AND DDLANGUAGE = SY-LANGU.
    ENDSELECT
    <b>Point # 2</b>
    SELECT * FROM EKKO INTO EKKO_WA.
      SELECT * FROM EKAN INTO EKAN_WA
          WHERE EBELN = EKKO_WA-EBELN.
      ENDSELECT.
    ENDSELECT.
    The above code can be much more optimized by the code written below.
    SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
        FROM EKKO AS P INNER JOIN EKAN AS F
          ON PEBELN = FEBELN.
    <b>Point # 3</b>
    SELECT * FROM SPFLI
      INTO TABLE T_SPFLI
      WHERE CITYFROM = 'FRANKFURT'
        AND CITYTO = 'NEW YORK'.
    SELECT * FROM SFLIGHT AS F
        INTO SFLIGHT_WA
        FOR ALL ENTRIES IN T_SPFLI
        WHERE SEATSOCC < F~SEATSMAX
          AND CARRID = T_SPFLI-CARRID
          AND CONNID = T_SPFLI-CONNID
          AND FLDATE BETWEEN '19990101' AND '19990331'.
    ENDSELECT.
    The above mentioned code can be even more optimized by using subqueries instead of for all entries.
    SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
        WHERE SEATSOCC < F~SEATSMAX
          AND EXISTS ( SELECT * FROM SPFLI
                         WHERE CARRID = F~CARRID
                           AND CONNID = F~CONNID
                           AND CITYFROM = 'FRANKFURT'
                           AND CITYTO = 'NEW YORK' )
          AND FLDATE BETWEEN '19990101' AND '19990331'.
    ENDSELECT.
    <b>Internal Tables</b>
    1.     Table operations should be done using explicit work areas rather than via header lines.
    2.     Always try to use binary search instead of linear search. But don’t forget to sort your internal table before that.
    3.     A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
    4.     A binary search using secondary index takes considerably less time.
    5.     LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
    6.     Modifying selected components using “ MODIFY itab …TRANSPORTING f1 f2.. “ accelerates the task of updating  a line of an internal table.
    <b>Point # 2</b>
    READ TABLE ITAB INTO WA WITH KEY K = 'X‘ BINARY SEARCH.
    IS MUCH FASTER THAN USING
    READ TABLE ITAB INTO WA WITH KEY K = 'X'.
    If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
    <b>Point # 3</b>
    READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
    READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
    <b>Point # 5</b>
    LOOP AT ITAB INTO WA WHERE K = 'X'.
    ENDLOOP.
    The above code is much faster than using
    LOOP AT ITAB INTO WA.
      CHECK WA-K = 'X'.
    ENDLOOP.
    <b>Point # 6</b>
    WA-DATE = SY-DATUM.
    MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
    The above code is more optimized as compared to
    WA-DATE = SY-DATUM.
    MODIFY ITAB FROM WA INDEX 1.
    7.     Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
    8.    If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
    9.    "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to “ LOOP-APPEND-ENDLOOP.”
    10.   “DELETE ADJACENT DUPLICATES“ accelerates the task of deleting duplicate entries considerably as compared to “ READ-LOOP-DELETE-ENDLOOP”.
    11.   "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to “  DO -DELETE-ENDDO”.
    <b>Point # 7</b>
    Modifying selected components only makes the program faster as compared to Modifying all lines completely.
    e.g,
    LOOP AT ITAB ASSIGNING <WA>.
      I = SY-TABIX MOD 2.
      IF I = 0.
        <WA>-FLAG = 'X'.
      ENDIF.
    ENDLOOP.
    The above code works faster as compared to
    LOOP AT ITAB INTO WA.
      I = SY-TABIX MOD 2.
      IF I = 0.
        WA-FLAG = 'X'.
        MODIFY ITAB FROM WA.
      ENDIF.
    ENDLOOP.
    <b>Point # 8</b>
    LOOP AT ITAB1 INTO WA1.
      READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
      IF SY-SUBRC = 0.
        ADD: WA1-VAL1 TO WA2-VAL1,
             WA1-VAL2 TO WA2-VAL2.
        MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
      ELSE.
        INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
      ENDIF.
    ENDLOOP.
    The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
    LOOP AT ITAB1 INTO WA.
      COLLECT WA INTO ITAB2.
    ENDLOOP.
    SORT ITAB2 BY K.
    COLLECT, however, uses a hash algorithm and is therefore independent
    of the number of entries (i.e. O(1)) .
    <b>Point # 9</b>
    APPEND LINES OF ITAB1 TO ITAB2.
    This is more optimized as compared to
    LOOP AT ITAB1 INTO WA.
      APPEND WA TO ITAB2.
    ENDLOOP.
    <b>Point # 10</b>
    DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
    This is much more optimized as compared to
    READ TABLE ITAB INDEX 1 INTO PREV_LINE.
    LOOP AT ITAB FROM 2 INTO WA.
      IF WA = PREV_LINE.
        DELETE ITAB.
      ELSE.
        PREV_LINE = WA.
      ENDIF.
    ENDLOOP.
    <b>Point # 11</b>
    DELETE ITAB FROM 450 TO 550.
    This is much more optimized as compared to
    DO 101 TIMES.
      DELETE ITAB INDEX 450.
    ENDDO.
    12.   Copying internal tables by using “ITAB2[ ] = ITAB1[ ]” as compared to “LOOP-APPEND-ENDLOOP”.
    13.   Specify the sort key as restrictively as possible to run the program faster.
    <b>Point # 12</b>
    ITAB2[] = ITAB1[].
    This is much more optimized as compared to
    REFRESH ITAB2.
    LOOP AT ITAB1 INTO WA.
      APPEND WA TO ITAB2.
    ENDLOOP.
    <b>Point # 13</b>“SORT ITAB BY K.” makes the program runs faster as compared to “SORT ITAB.”
    <b>Internal Tables         contd…
    Hashed and Sorted tables</b>
    1.     For single read access hashed tables are more optimized as compared to sorted tables.
    2.      For partial sequential access sorted tables are more optimized as compared to hashed tables
    Hashed And Sorted Tables
    <b>Point # 1</b>
    Consider the following example where HTAB is a hashed table and STAB is a sorted table
    DO 250 TIMES.
      N = 4 * SY-INDEX.
      READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
      IF SY-SUBRC = 0.
      ENDIF.
    ENDDO.
    This runs faster for single read access as compared to the following same code for sorted table
    DO 250 TIMES.
      N = 4 * SY-INDEX.
      READ TABLE STAB INTO WA WITH TABLE KEY K = N.
      IF SY-SUBRC = 0.
      ENDIF.
    ENDDO.
    <b>Point # 2</b>
    Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
    LOOP AT STAB INTO WA WHERE K = SUBKEY.
    ENDLOOP.
    This runs faster as compared to
    LOOP AT HTAB INTO WA WHERE K = SUBKEY.
    ENDLOOP.
    <b>Reward if usefull</b>

  • Secondary Indexes

    Hi experts,
    I need to have an opinion on the following for performance tuning.
    Actually a report was taking long time fetching entries from the tables, so secondary index are created for BSAD, BSID, BSAK and BSIK tables, and reduced the time from 8 hours to 2 hours by this secondary index.
    Now becuase of this index, the other processes are getting hampered like a job in BW, uses the same tables. earlier it used to run in 5-10 mins it is now taking around 45-50 mins to run sometimes 2 hours to run.
    So how can we improve without hampering any processes?
    Thanks,
    Rashmi

    Hi Rashmi,
    rashmi N purohit wrote:
    Hi experts,
    >
    > I need to have an opinion on the following for performance tuning.
    >
    > Actually a report was taking long time fetching entries from the tables, so secondary index are created for BSAD, BSID, BSAK and BSIK tables, and reduced the time from 8 hours to 2 hours by this secondary index.
    >
    > Now becuase of this index, the other processes are getting hampered like a job in BW, uses the same tables. earlier it used to run in 5-10 mins it is now taking around 45-50 mins to run sometimes 2 hours to run.
    >
    > So how can we improve without hampering any processes?
    >
    > Thanks,
    > Rashmi
    Good question! Creating a new index bears always the risk to interfere with other statements applications. There is no way around
    analyzing the important (frequently executed) sql statements and come up with an index design that fits for all of them.
    You have to analyze the sql statements that are slow now in more detail.
    In order to answer your question all details (sqls indexes statisitcs execution plans ...) would be needed.
    There is no easy answer to your question.
    Kind regards,
    Hermann

Maybe you are looking for