INDEX Creation for Query Optimization

Hi Experts
I have the below query:
SELECT A~VBELN A~POSNR A~MATNR A~KWMENG A~KBMENG
A~ERDAT A~ERZET A~PSTYV D~AUART E~ETTYP E~EDATU
INTO TABLE INT_RES
FROM VBAK AS D INNER JOIN VBAP AS A
ON D~VBELN EQ A~VBELN
INNER JOIN VBEP AS E
ON E~VBELN EQ A~VBELN AND
E~POSNR EQ A~POSNR
WHERE D~VBELN IN S_VBELN AND
D~AUART IN S_AUART AND
D~VKORG IN S_VKORG AND
D~VBTYP EQ 'C' AND
( ( A~MATNR LIKE C_PREFIX_SP AND ZZ_MSPOSNR NE 0 AND KBMENG EQ 0 ) OR
( MATNR LIKE C_PREFIX_FP AND KWMENG NE A~KBMENG ) ) AND
A~ABGRU EQ SPACE AND
A~MTVFP IN R_MTVFP AND
A~PRCTR IN R_PRCT AND
E~ETENR EQ '1'.
I tried many ways of re-writing the query - yet performance could not be improved. Now I need to create an INDEX and check if it works out?
Could you please help me suggesting upon which table and which fields in which order I can create an effective INDEX?
Please Help

Hi,
Check which selection criteria are polulated when you run the query.
Also one issue might be with using the LIKE keyword in the where clause.
( ( A~MATNR LIKE C_PREFIX_SP AND ZZ_MSPOSNR NE 0 AND KBMENG EQ 0 ) OR
( MATNR LIKE C_PREFIX_FP AND KWMENG NE A~KBMENG ) ) AND
Instead of using this, I would suggest you get all the materials from material master using the like operator and pass them in a range to this query.
select matnr from mara into it_mara
where matnr like c_prefix_sp.
select matnr from mara appending table it_mara where matnr like c_prefix_fp.
"Loop at it_mara and populate a range. Which will then be used in the select query
That might help improve the performance.
regards,
Advait

Similar Messages

  • Any software for Query Optimization?

    Hi,
    Is there any software to be used for query Optimization
    Please help me

    3rd party tools suck (if they did not Oracle would incorporate them in its optimizer long ago). The best tools are:
    1. Gather table and index statistics
    2. Use CBO (FIRST_ROWS, ALL_ROWS)
    3. SQL*Plus AUTOTRACE
    4. EXPLAIN PLAN
    5. SET SQL_TRACE = TRUE + TKPROF
    6. Statspack
    7. Enterprise manager (new Ora10g, did not try it)
    All from Oracle...

  • Authorization Object for role creation for query display?

    Hi,
    Can Anybody here tell me what is the Authorization object that we use for role creation for query display?
    I want to assign a role to the newly designed query! that query does not have any role so far!
    Pls suggest me
    Thanks,
    Ravi

    Hi,
    I could make the authorization tab green by entering the authorization object!
    But user tab still remains red as it is not allowing me to enter my username in the user tab!
    in the user tab  i am unable to enter my user name?
    Any suggestions?
    Thanks,
    Ravi

  • What would be the optimal index creation for this horribly written sql in a third party app that I cannot change?

    SQL:
           SELECT *      FROM ORDERS WHERE ORDERNO = {STR} AND ITEMNO = {##} AND STEP = {##}

    That's almost certainly the wrong question.  You don't want the index(es) that will optimize that single query.  You want the index(es) that will optimize your system as a whole.
    The absolute best choice for that query would be a clustered index on ORDERNO, ITEMNO, STEP.  But each table can only have one clustered index so you would have to drop any clustered index you currently have and then create the new one.  But creating
    or dropping a clustered index can be time consuming on a large table.
    So in the absence of any other information, I would recommend trying a nonclustered index on ORDERNO, ITEMNO, STEP.  That will be faster to do and faster to drop if you decide it's not helping.
    Tom

  • Indexes creation for cubes

    Hi all,
    I cretaed a Cube in the BW system. When I choose infoprovider>cube>manage>performance, we have two indexes options: "check indexes" and "check aggregate indexes", I would like to know the difference between them.
    Below we have the "data base statistics section", when I click the "create statistics (batch) button", a new screen is shown, and there you can select two options: "refresh DB statistics after each data load" and "also refresh statisctics after delta upload", I would like to know the meaning of both options.
    Kindly Help,
    Thanks
    Laura Gómez

    Hi,
    Infocube Index
    InfoCubes (fact, dimension tables) are fully indexed and usually do not require additional indices.
    The indexing as follows: Fact Table (consists of dimension IDs and key figures) B-tree indices for InfoCube dimensions (“high cardinality”) should be set only in special cases. The dimension should be very large (in comparison to the fact table) and the maintenance time for bitmap indices (deletion and re-build) should have significant impact. You should be aware of the fact that the B-tree index cannot be used for the star join and hence, reduces query performance. In the Performance Tab of the InfoCube use drop and recreate the system defined indices to perk up the performance.http://help.sap.com/saphelp_nw04/helpdata/en/83/0ac9be421f874b8533f3b315230b32/frameset.htm

  • Spatial index creation for table with more than one geometry columns?

    I have table with more than one geometry columns.
    I'v added in user_sdo_geom_metadata table record for every column in the table.
    When I try to create spatial indexes over geometry columns in the table - i get error message:
    ERROR at line 1:
    ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
    ORA-13203: failed to read USER_SDO_GEOM_METADATA table
    ORA-13203: failed to read USER_SDO_GEOM_METADATA table
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 8
    ORA-06512: at line 1
    What is the the solution?

    I'v got errors in my user_sdo_geom_metadata.
    The problem does not exists!

  • Regarding the dead lock while index creation

    Hi,
    We have a requirement where we are trying to load and create the index for few cubes simulatneously, but it has resulted in dead lock situation, can you please tell us about this problem in detail.
    Thanks

    Hi Mahesh,
    This kind of problem will arrive when the index creation for ur data targets are happening and those data targets shares some common data like master data, since both will be refering to the same, usually dead locks situation comes into picture
    thanks,
    vinay
    Edited by: vinaykumarhs on Mar 20, 2011 12:26 AM

  • Aggregate Query Optimization (with indexes) for trivial queries

    Table myTable, which is quite large, has an index on the month column.
    "select max(month) from myTable" uses this index and returns quickly.
    "select max(month) from myTable where 1 = 1" does not use this index, falls through to a full table scan, and takes a very long time.
    Can this possibly be a genuine omission in the query optimizer, or is there some setting or another to convince it to perform the latter query more sanely?

    Oracle 11.2.0.1
    SQL> select table_name, num_rows from dba_tables where table_name = 'DWH_ADDRESS_MASTER';
    TABLE_NAME                                 NUM_ROWS
    DWH_ADDRESS_MASTER                        295729948
    SQL> explain plan for select max(last_update_date) from DWH.DWH_ADDRESS_MASTER;
    | Id  | Operation                  | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT           |                        |     1 |     8 |     4   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE            |                        |     1 |     8 |            |          |
    |   2 |   INDEX FULL SCAN (MIN/MAX)| DWH_ADDRESS_MASTER_N1  |     1 |     8 |     4   (0)| 00:00:01 |
    SQL> explain plan for select max(last_update_date) from DWH.DWH_ADDRESS_MASTER where 1 = 1;
    | Id  | Operation                   | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |                        |     1 |     8 |     4   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE             |                        |     1 |     8 |            |          |
    |   2 |   FIRST ROW                 |                        |     1 |     8 |     4   (0)| 00:00:01 |
    |   3 |    INDEX FULL SCAN (MIN/MAX)| DWH_ADDRESS_MASTER_N1  |     1 |     8 |     4   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------------------

  • Weird result of oracle query before and after function base index creation

    Hi All,
    Here is the unique situation we are facing after creating just an index.
    The query result before the index and the query result after the index do not match.
    This is very illogical situation. Shidhar and me have done lot of R&D, also tried to get lots info from Google but we couldn't decipher the reason for that.
    I am giving you all the details about the query, index and tables with following steps.
    Please let us know if anything is going wrong from our side or is it a bug at oracle level which is a rarest possibility but a possibility.
    Step 1 :- Create table
    create table TEMP_COMP
    ID VARCHAR2(10),
    GROUP_ID VARCHAR2(10),
    TRAN_DATE DATE,
    AMT_1 NUMBER,
    AMT_2 NUMBER,
    AMT_3 NUMBER
    Step 2 :- Insert Sample data
    set feedback off
    set define off
    prompt Deleting TEMP_COMP...
    delete from TEMP_COMP;
    commit;
    prompt Loading TEMP_COMP...
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('01', 'G01', to_date('01-03-2007', 'dd-mm-yyyy'), 1, 11, 111);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('02', 'G01', to_date('02-03-2007', 'dd-mm-yyyy'), 2, 22, 222);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('03', 'G01', to_date('03-03-2007', 'dd-mm-yyyy'), 3, 33, 333);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('04', 'G01', to_date('04-03-2007', 'dd-mm-yyyy'), 4, 44, 444);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('05', 'G01', to_date('05-03-2007', 'dd-mm-yyyy'), 5, 55, 555);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('06', 'G01', to_date('01-03-2008', 'dd-mm-yyyy'), 6, 66, 666);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('07', 'G01', to_date('02-03-2008', 'dd-mm-yyyy'), 7, 77, 777);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('08', 'G01', to_date('03-03-2008', 'dd-mm-yyyy'), 8, 88, 888);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('09', 'G01', to_date('04-03-2008', 'dd-mm-yyyy'), 9, 99, 999);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('10', 'G01', to_date('05-03-2008', 'dd-mm-yyyy'), 10, 100, 1000);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('01', 'G01', to_date('01-03-2007', 'dd-mm-yyyy'), 1, 11, 111);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('02', 'G01', to_date('02-03-2007', 'dd-mm-yyyy'), 2, 22, 222);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('03', 'G01', to_date('03-03-2007', 'dd-mm-yyyy'), 3, 33, 333);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('04', 'G01', to_date('04-03-2007', 'dd-mm-yyyy'), 4, 44, 444);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('05', 'G01', to_date('05-03-2007', 'dd-mm-yyyy'), 5, 55, 555);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('06', 'G01', to_date('01-03-2008', 'dd-mm-yyyy'), 6, 66, 666);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('07', 'G01', to_date('02-03-2008', 'dd-mm-yyyy'), 7, 77, 777);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('08', 'G01', to_date('03-03-2008', 'dd-mm-yyyy'), 8, 88, 888);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('09', 'G01', to_date('04-03-2008', 'dd-mm-yyyy'), 9, 99, 999);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('10', 'G01', to_date('05-03-2008', 'dd-mm-yyyy'), 10, 100, 1000);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('01', 'G02', to_date('01-03-2007', 'dd-mm-yyyy'), 1, 11, 111);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('02', 'G02', to_date('02-03-2007', 'dd-mm-yyyy'), 2, 22, 222);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('03', 'G02', to_date('03-03-2007', 'dd-mm-yyyy'), 3, 33, 333);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('04', 'G02', to_date('04-03-2007', 'dd-mm-yyyy'), 4, 44, 444);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('05', 'G02', to_date('05-03-2007', 'dd-mm-yyyy'), 5, 55, 555);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('06', 'G02', to_date('01-03-2008', 'dd-mm-yyyy'), 6, 66, 666);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('07', 'G02', to_date('02-03-2008', 'dd-mm-yyyy'), 7, 77, 777);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('08', 'G02', to_date('03-03-2008', 'dd-mm-yyyy'), 8, 88, 888);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('09', 'G02', to_date('04-03-2008', 'dd-mm-yyyy'), 9, 99, 999);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('10', 'G02', to_date('05-03-2008', 'dd-mm-yyyy'), 10, 100, 1000);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('01', 'G03', to_date('01-03-2007', 'dd-mm-yyyy'), 1, 11, 111);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('02', 'G03', to_date('02-03-2007', 'dd-mm-yyyy'), 2, 22, 222);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('03', 'G03', to_date('03-03-2007', 'dd-mm-yyyy'), 3, 33, 333);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('04', 'G03', to_date('04-03-2007', 'dd-mm-yyyy'), 4, 44, 444);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('05', 'G03', to_date('05-03-2007', 'dd-mm-yyyy'), 5, 55, 555);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('06', 'G03', to_date('01-03-2008', 'dd-mm-yyyy'), 6, 66, 666);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('07', 'G03', to_date('02-03-2008', 'dd-mm-yyyy'), 7, 77, 777);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('08', 'G03', to_date('03-03-2008', 'dd-mm-yyyy'), 8, 88, 888);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('09', 'G03', to_date('04-03-2008', 'dd-mm-yyyy'), 9, 99, 999);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('10', 'G03', to_date('05-03-2008', 'dd-mm-yyyy'), 10, 100, 1000);
    insert into TEMP_COMP (ID, GROUP_ID, TRAN_DATE, AMT_1, AMT_2, AMT_3)
    values ('11', 'G01', to_date('03-03-2008', 'dd-mm-yyyy'), 100, 200, 300);
    commit;
    prompt 41 records loaded
    set feedback on
    set define on
    prompt Done.
    Step 3 :- Execute the query.
    SELECT GROUP_ID
    , SUM(LAST_YR_REV) as "Year_2007_Amt"
    , SUM(CURR_YR_REV) as "Year_2008_Amt"
    FROM (
    SELECT GROUP_ID,
    CASE WHEN TO_CHAR(TRAN_DATE,'YYYYMM') BETWEEN'200701'AND'200712'THEN SUM(AMT_1) ELSE 0 END AS LAST_YR_REV ,
    CASE WHEN TO_CHAR(TRAN_DATE,'YYYYMM') BETWEEN'200801'AND'200812'THEN SUM(AMT_1) ELSE 0 END AS CURR_YR_REV
    FROM TEMP_COMP t
    WHERE GROUP_ID ='G01'
    AND TO_CHAR(TRAN_DATE,'YYYYMM') BETWEEN'200601'AND'200912'
    GROUP BY GROUP_ID, TRAN_DATE
    GROUP BY GROUP_ID
    The result of above query
    GROUP_ID Year_2007_Amt Year_2008_Amt
    G01 30 180
    Step 4 : Create composite index
    create index GROUP_ID_TRAN_DATE_IDX on TEMP_COMP (GROUP_ID, TO_CHAR(TRAN_DATE,'YYYYMM'))
    Step 5 : Execute once again query from step 3.
    SELECT GROUP_ID
    , SUM(LAST_YR_REV) as "Year_2007_Amt"
    , SUM(CURR_YR_REV) as "Year_2008_Amt"
    FROM (
    SELECT GROUP_ID,
    CASE WHEN TO_CHAR(TRAN_DATE,'YYYYMM') BETWEEN'200701'AND'200712'THEN SUM(AMT_1) ELSE 0 END AS LAST_YR_REV ,
    CASE WHEN TO_CHAR(TRAN_DATE,'YYYYMM') BETWEEN'200801'AND'200812'THEN SUM(AMT_1) ELSE 0 END AS CURR_YR_REV
    FROM TEMP_COMP t
    WHERE GROUP_ID ='G01'
    AND TO_CHAR(TRAN_DATE,'YYYYMM') BETWEEN'200601'AND'200912'
    GROUP BY GROUP_ID, TRAN_DATE
    GROUP BY GROUP_ID
    The result of above query
    GROUP_ID Year_2007_Amt Year_2008_Amt
    G01 0 210
    Thanks
    Sunil

    I just wanted to make a comment. The predicates in both your queries are flawed I believe. You convert a date column to a character and then you say only pick the converted result between two sets of characters.
    TO_CHAR(TRAN_DATE,'YYYYMM') BETWEEN'200601'AND'200912'It should be coded like this for a proper date range comparison:
    TRAN_DATE BETWEEN TO_DATE('200601','YYYYMM') AND TO_DATE('200912','YYYYMM')That will eliminate the need for you to create FBI that you created. You should now be able to create a regular (B*Tree) index on the TRAN_DATE column.
    Also, now that we have the structure of your tables and sample data, what business question are you trying to answer? I think there is a better query that can be written if we know the requirements.
    Hope this helps!

  • Spatial query index creation fails with ORA-13282: failure on initializatio

    Hi,
    I have an Oracle 10g 10.2.0.5.0 database newly installed. Spatial index creation fails:
    ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
    ORA-13282: failure on initialization of coordinate transformation
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
    The script I am trying to run is:
    Insert into USER_SDO_GEOM_METADATA
    (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
    Values
    ('SOME_TABLE', 'geo',
    "SDO_DIM_ARRAY"(
    "SDO_DIM_ELEMENT"('X',600000,900000,0.001),
    "SDO_DIM_ELEMENT"('Y',150000,400000,0.001)), 23700);
    CREATE INDEX IX_GEO_SOME_TABLE ON SOME_TABLE (GEO) INDEXTYPE IS MDSYS.SPATIAL_INDEX ;
    Earlier I had some issues with NLS settings in relation to Spatial, but in this particular case setting the NLS_LANG for AMERICAN_AMERICA does not help. I found this comment http://www.orafaq.com/forum/t/127312/2/ but would not like to hack around with MDSYS table content. Any help is highly appreciated.
    Regards, Tamas

    Tamas,
    1 . . .Are you indexing a table that already has geometries or an empty table?
    . . . .If the former, do all the geometries in that table have the same (not NULL) SRID (23700)?
    2 . .The link you posted suggests a parsing problem since in Hungarian (23700), the decimal seperator is a comma (not a period). Accordingly, I believe the edit to mdsys.sdo_cs_srs.WKTEXT would be:
    PROJCS["HD72 / EOV", GEOGCS [ "HD72", DATUM ["Hungarian Datum 1972 (EPSG ID 6237)", SPHEROID ["GRS 1967 (EPSG ID 7036)", 6378160, 298,247167427]], PRIMEM [ "Greenwich", 0,000000 ], UNIT ["Decimal Degree", 0,01745329251994328]], PROJECTION ["Egyseges Orszagos Vetuleti (EPSG OP 19931)"], UNIT ["Meter", 1]]
                                                                                                                                         ^                                    ^                                   ^                                                                                                  Regards,
    Noel

  • Is aggregate DB index is required for query performance

    Hi,
    Cube mange tab when i check for the aggregate DB index it shows red, here my doubt is, is the DB index is required for query performance
    is the check statics should be in green?
    Please let me know
    Regards,
    Kiran

    Hi,
    Yes it improves the reports performance..
    Using the Check Indexes button, you can check whether indexes already exist and whether these existing indexes are of the correct type (bitmap indexes).
    Yellow status display: There are indexes of the wrong type
    Red status display: No indexes exist, or one or more indexes are faulty
    You can also list missing indexes using transaction DB02, pushbutton Missing Indexes. If a lot of indexes are missing, it can be useful to run the ABAP reports SAP_UPDATE_DBDIFF and SAP_INFOCUBE_INDEXES_REPAIR.
    See SAP Help
    http://help.sap.com/saphelp_nw2004s/helpdata/en/80/1a6473e07211d2acb80000e829fbfe/content.htm
    Thanks
    Reddy

  • I am looking for a way to automate index creation using Adobe Reader Pro without having to use the screen user interface, as the indexing has to be run by a batch process.

    I am looking for a way to automate index creation using Adobe Reader Pro without having to use the screen user interface, as the indexing has to be run by a batch process.

    [discussion moved to Creating, Editing & Exporting PDFs forum.]

  • Fast index creation suggestions wanted

    Hi:
    I've loaded a table with a little over 100,000,000 records. The table has several indexes which I must now create. Need to do this as fast as possible.
    I've read the excellent article by Don Burleson (http://www.dba-oracle.com/oracle_tips_index_speed.htm) but still have a few questions.
    1) If the table is not partitioned, does it still make sense to use "parallel"?
    2) The digit(s) following "compress" indicate the number of consective columns at the head of the index that have duplicates. True?
    3) How will the compressed index effect query performance (vs not compressed) down the line?
    4) In the future I will be doing lots and lots of updates on the indexed columns of the records as well as lots of record deletes and inserts into/out-of the table. Will these updates/inserts/deletes run faster or slower given that the indexes are compressed vs if they were not?
    5) In order to speed up the sorting, is it better to add datafiles to the TEMP table or create more TEMP tables (remember, running "parallel")
    Thanks in Advance

    There are people who would argue that excellent and Mr. Burleson do not belong in the same sentence.
    1) Yes, you can still use parallel (and nologging) to create the index, but don't expect 20 - 30 times faster index creation.
    2) It is the number of columns to compress by, they may not neccesarily have duplicates. For a unique index the default is number of columns - 1, for a non-unique index the default is the number of columns.
    3) If you do a lot of range scans or fast full index scans on that index, then you may see some performance benefit from reading fewer blocks. If the index is mostly used in equality predicates, then the performance benefit will likely be minimal.
    4) It really depends on too many factors to predict. The performance of inserts, updates and deletes will be either
    A) Slower
    B) The same
    C) Faster
    5) If you are on 10G, then I would look at temporary tablespace groups which can be beneficial for parallel operations. If not, then allocate as much memory as possible to sort_area_size to minimize disk sorts, and add space to your temporary tablespace to avoid unable to extend. Adding additional temporary tablespaces will not help because a user can only use one temporary tablespace at a time, and parallel index creation is only one user.
    You might want to do some searching at Tom Kyte's site http://asktom.oracle.com for some more responsible answers. Tom and Don have had their disagreements in the past, and in most of them, my money would be on Tom to be corerct.
    HTH
    John

  • Index ignored in query??

    This is probably a basic question about indexes, thanks for your insights.
    I have a table VOUCHER with some columns including a TICKETNO column for which there is a primary key index, defined as follows:
    CREATE UNIQUE INDEX VOUCHER_PK ON VOUCHER (TICKETNO)
    The table contain approximately 20 million records.
    We are using Oracle 9i RAC on HP-UX 11.11
    I am running the following query, which runs for 20 minutes and then fails:
    Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
    With the Partitioning and Real Application Clusters options
    JServer Release 9.2.0.8.0 - Production
    SQL> select count(*) from VOUCHER
    2 where TICKETNO between 100000 and 100100
    3
    SQL> /
    select count(*) from VOUCHER
    ERROR at line 1:
    ORA-01555: snapshot too old: rollback segment number 741 with name
    "_SYSSMU741$" too small
    I am confused... Why counting 100 records with an indexed column takes so long and fail?

    Thanks for the feedback. I am going to run the ANALYZE suggestion tonight.
    Here are the results of the queries asked for:
    SELECT Table_Name, Status FROM User_Indexes WHERE Index_Name = 'VOUCHER_PK';
    OWNER TABLE_NAME STATUS
    SMVDBA VOUCHER VALID
    SELECT Column_Name FROM User_Ind_Columns WHERE Index_Name = 'VOUCHER_PK';
    COLUMN_NAME
    TICKETNO
    SELECT Last_Analyzed FROM User_Indexes WHERE Index_Name = 'VOUCHER_PK';
    LAST_ANAL
    SELECT Last_Analyzed FROM User_Tables WHERE Table_Name = 'VOUCHER';
    LAST_ANAL
    21-FEB-08
    EXPLAIN PLAN FOR
    select count(*) from VOUCHER
    where TICKETNO between 100000 and 100100;
    Explained
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('', '', 'ALL'));
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | | | |
    | 1 | SORT AGGREGATE | | | | |
    | 2 | TABLE ACCESS FULL | VOUCHER | | | |
    Note: rule based optimization, PLAN_TABLE' is old version
    10 rows selected.
    EXPLAIN PLAN FOR
    select /*+ INDEX(V VOUCHER_PK) */ count(*) from VOUCHER V
    where TICKETNO between 100000 and 100100;
    Explained.
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('', '', 'ALL'));
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 1 | 18 | 5 |
    | 1 | SORT AGGREGATE | | 1 | 18 | |
    | 2 | INDEX FAST FULL SCAN| VOUCHER_PK | 83788 | 1472K| 5 |
    Note: cpu costing is off, PLAN_TABLE' is old version
    10 rows selected.

  • Oracle 11g on Linux : Query Optimization issue

    Hi guru,
    I am facing one query optimization related problem in group by query
    Table (10 million Records)
    Product(ProductId number,ProductName varchar(100),CategoryId VARCHAR2(38),SubCategoryId VARCHAR2(38))
    Index
    create index idxCategory on Product (CategoryId,SubCategoryId)
    Query1:To find product count for all CategoryId and SubCategoryId
    select CategoryId,SubCategoryId,count(*) from Product group by CategoryId,SubCategoryId
    Above query is not using index idxCategory and doing table scan which is very costly.
    When I fire Query2: select count(*) from Product group by CategoryId,SubCategoryId
    then it is properly using index idxCategory and very fast.
    Even I specified hint in Query1 but it is not using hint.
    Can anybody suggest why oracle is not using index in Query1 and what should I do so that Query1 will use Index.
    Thanks in advance.

    user644199 wrote:
    I am facing one query optimization related problem in group by query
    Query1:To find product count for all CategoryId and SubCategoryId
    select CategoryId,SubCategoryId,count(*) from Product group by CategoryId,SubCategoryId
    Above query is not using index idxCategory and doing table scan which is very costly.
    When I fire Query2: select count(*) from Product group by CategoryId,SubCategoryId
    then it is properly using index idxCategory and very fast.
    Even I specified hint in Query1 but it is not using hint.
    Can anybody suggest why oracle is not using index in Query1 and what should I do so that Query1 will use Index.The most obvious reason that the table needs to be visited would be that the columns "CategoryId" / "SubCategoryId" can be NULL but then this should apply to both queries. You could try the following to check the NULL issue:
    select CategoryId,SubCategoryId,count(*) from Product where CategoryId is not null and SubCategoryId is not null group by CategoryId,SubCategoryId
    Does this query use the index?
    Can you show us the hint you've used to force the index usage and the EXPLAIN PLAN output of the two queries including the "Predicate Information" section? Use DBMS_XPLAN.DISPLAY to get a proper output, and use the \ tag before and after when posting here to format it using fixed font. Use the "Quote" button in the message editor to see how I used the \ tag here.
    Are above queries representing the actual queries used or did you omit some predicates etc. for simplicity?
    By the way, VARCHAR2(38) and ...ID as name, are these columns storing number values?
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

Maybe you are looking for