Reg: statistics on indexes

Hi,
Need to know how to build the statistics on the primary index.
Command : brconnect -u / -c -f stats -m +I
But i don know how to build the statistics for the primary index.

Hello Ambarish,
> But now when checked in production the query is picking up the index that is primary index and in quality system it is picking up the same
So how do you get the conclusion that an index rebuild will fix the issue? Does the index sizes differ so much? What is the clustering factor? What are the wait events of the SQL statement in the quality system?
At first you need to understand the root cause of the performance problem until you can solve the problem. Many questions are still open and an index rebuild is just one "little piece of the big oracle mosaic".
> Any one please help.How to rebuild primary key index .
I have already posted the brconnect call to rebuild the primary index.
Regards
Stefan

Similar Messages

  • What is COMPUTE STATISTICS in index

    Hi,
    I need the explanations of compute statistics in index.
    what is compute statistics?
    Regards,
    B.Prakash

    Hi,
    Compute statistics tells Oracle to collect statistics during the creation of the index. The statistics are then used by the optimizer to choose a "plan of execution" when SQL statements are executed.
    Thanks

  • Statistics and indexes

    hi gurus,
    wat r bw statistics and indexes .... how to use them
    thanx in advance

    Anna,
    Indexes are structures sorted by attribute values that contains a pointer to data stored in a table.
    In plain words, when we run an indexing process on a table we basically build a pointer to that table records. That pointer has one main purpose: to enhance read performance (in our case - to enhance query performance).
    BW Statistics are used in order to analyze the performance of queries and processes in the warehouse management (for example loading processes and aggregations). In order to use BW Statistics, you will need to enable them for your infoprovider and then be able to browse them from transcation ST03 or using the Technical Content Infoprovider and Queries.
    See the Statistics How to: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5401ab90-0201-0010-b394-99ffdb15235b
    Hope it helps,
    Gili

  • Gathering schema Statistics and Index rebuilding

    I want to know after how much time we must gather the schema Statistics and Index rebuilding.
    In our system approximately 7 logfile generates in one day
    Please suggest me

    Index rebuilding sounds so much Oracle 7! Indexes today generally take care of themselves quite well, throughout inserts, deletes and updates. It rebalances itself automatically when necessary, without requiring any rebuild. As for the stats, run it for sure after large data movements (i.e. deletes and inserts). Besides that, implement table monitoring for your tables, and run once in a while dbms_stats with the options parameter as GATHER STALE. That way, Oracle will automatically know which objects need their stats refreshed.
    Daniel

  • DB Statistics & BI Indexes

    Hi All,
    I have been going through a lot of threads related to DB Statistics & BI Indexes and I am confused.
    1) How do I come to know that the DB Statistics and BI Indexes for a cube are active or created?
        Is it through RSDDSTAT where the status is X means stats are active? Is there another way to find out?
        What about BI Indexes?
    2) How do I create DB Statistics?
    3) Does creatting DB statistics for query help the query performance or creating DB statistics on cube helps the Query performance or is it both?
    4) I understand primary indexes are created while creating the cube.However, when we try to create secondary indexes through performance tab in which table the details are stored? Can it be deleted later?
    5) Is there another way to create BI Indexes other than performance tab?

    P.S: the formatting went nuts... I added *** before each of my replies... COME ON SAP!! Cant you fix this???
    Hi.
    1) How do I come to know that the DB Statistics and BI Indexes for a cube are active or created?
    Is it through RSDDSTAT where the status is X means stats are active? Is there another way to find out?
    What about BI Indexes?
    In addition to the performance tab where you got the traffic lights, you can check the indexes through tcode SE11. Just input the table name and on the next sceen click the button reading "Indexes...". A popup will show you the indexes that exist for the table you are looking at. Doubleclicking any of the indexes will take you to the details.
    You can also define a new, secondary index here. You might have to go to DB02->missing indexes to have it created on the database, even though it says it exists and is active in se11... get your basis guy in on all of this.
    2) How do I create DB Statistics?
    Through Performance tab or step in process chain, but you should schedule db stats at least once a week in that DB-maintenance-calendar-thingy you can get to with a tcode I cannot remember... DBxx where xx is two numbers...ask your basis guy.
    3) Does creatting DB statistics for query help the query performance or creating DB statistics on cube helps the Query performance or is it both?
    You cannot create statistics for a query. You can collect statistics about the query use. This is the statistics stuff you can activate from bct; the "statistics-cubes" and all that. They store the info you collect and this is then called BI Statistics. It is of absolutely no use whatsoever with regards to performance. You can learn a lot about your system by analysing this, but starting to collect the BI Statistics wont help your slow running queries.
    You can create statistics for cubes. This is the DB Stats and the effect of creating it is that the system will know how the data is distributed in the cube and because of that, it will have a better chance of reading data according to your selections faster. Much faster in some cases! This goes for both queries and loads (a load is just a special kind of query, where results are not put on the screen but in another table). Try to keep your DB Stats as up to date as you can - I always update the stats after each load and compression... It is especially important on transactional cubes, because data is more volatile here than when you only load every second day or so.
    4) I understand primary indexes are created while creating the cube.However, when we try to create secondary indexes through performance tab in which table the details are stored? Can it be deleted later?
    I dont know the tables this is stored in, but you can delete any index using SE11as mentioned above. Secondary indexes will need to be re-defined in SE11 when your system has been taken down... or if you activate the cube. In that case, only the hardwired primary indexes are created.
    5) Is there another way to create BI Indexes other than performance tab?
    I think you can only create/define an index in SE11, but you can refresh it from the Performance tab or in a process chain.
    Regards,
    Jacob
    Edited by: Jacob Jansen on Aug 10, 2010 9:56 PM

  • How to create statistics for INDEX thru GUI

    In DB13 i see messages MISSING_STATISTICS for some indexes.
    I manage for tables thru DB20. How can i create statistsics for INDEX.
    Rgds
    PR

    Hello PR,
    at first let's say you should use the BRTools to create statistics for the indexes, because of the sample method (estimate, compute) - SAP has an algorithm to choose the right sample size.
    Have a look at here:
    http://help.sap.com/saphelp_nw70/helpdata/en/f4/81e93a637bfd70e10000000a11402f/content.htm
    If you want to create statistics manually out of the R/3 ... you can use the report "RSANAORA"
    Transaction SE38 -> Report RSANAORA -> Choose your index and sample method... and go on.
    Regards
    Stefan

  • EAR4 - Gathering Statistics, unusable indexes and more

    Hi,
    Some feedback on statistics:
    1. When choosing a table -> Statistics -> gather Statistics, the minimum is to have a CASCADE option (so all the indexes will be analyzed too). I think it should be the deafult! This way there is a chance that the developers will have good statistics...
    As a bonus, an advanced tab with the rest of the options might be nice, when you have time.
    2. When choosing to gather statistics on an index, you should you dbms_stats and not ALTER INDEX... COMPUTE STATISTICS which is a deprecated syntax.
    And about indexes:
    1. When looking at the index tab of a table, unusable indexes should be visibly different - maybe just color the status column. Well, any color-coding can help to gain more infomation very fast (index types and index status). Well, I guess the same goes for disabled triggers, disabled constraints etc...
    2. When right-clicking an index in an index tab of a table, the only option is export, which makes no sense. Could you replace it with the six relevant index options, just like when we right click an index in the side bar (drop, rebuild, rename, make unusable...)
    Well, same goes for the triggers tab of a table - when right-clicking a trigger give us the trigger actions(enable/disable, drop...), not export.
    my two cents,
    Ofir

    When Choose a partitioned table from the tables list (tree view on the left), I have many tabs with details (Columns, data, indexes,etc).
    1. The last tab, SQL, doesn't generate any CREATE TABLE sql at all for the simple partition table I created (10g Release 2 on windows 2000, raptor 4.1, a table with a single partition).
    2. There is no way to see the partitions definitions - for example, the list of partitions and their ranges (or list values). I would like to have another tab for partitioned table with that information (from all_tab_partitions). Also, how can I easily see the type of partitioning and the partition key of the table?
    3. Also in the builtin reports, there is no way to get that data. The only report about partitioned tables that I see is Table -> Organization -> Partitioned -> Partitioned Tables, that only provide owner, table_name, maybe tablespace and logging (blank in my case).. I think:
    a. You should rewrite the report to use dba/all_part_tables - with columns like partitioning_type, subpartitioning_type, partition_count etc.
    b. add a report about the partition key columns per partitioned table from dba_part_key_columns.
    4. When adding an index to a partitioned table, I can't choose local/global index. The index is always created as a global index. For example, can't create bitmap index on partitioned tables because they must be local.
    Ofir

  • Update statistics / missing index

    The performance has been downgraded after the DB migration... The Query seems running slower than it used to be,
    How can I update statistics / find missing index to fix it in Oracle?

    hi....
    after the importing of the db please run the compilation script below
    SET HEAD OFF
    SET FEEDBACK OFF
    SET PAGESIZE 0
    SPOOL COM.SQL
    SELECT 'ALTER '|| OBJECT_TYPE||' '|| OBJECT_NAME ||' COMPILE ; ' FROM
    USER_OBJECTS
    WHERE STATUS = 'INVALID'
    AND OBJECT_TYPE != 'PACKAGE BODY'
    ORDER BY OBJECT_TYPE
    SELECT 'ALTER PACKAGE '|| OBJECT_NAME ||' COMPILE BODY ; ' FROM USER_OBJECTS
    WHERE STATUS = 'INVALID'
    AND OBJECT_TYPE = 'PACKAGE BODY'
    ORDER BY OBJECT_TYPE
    spool off
    @com.sql
    SET HEAD ON
    SET FEEDBACK ON
    SET PAGESIZE 100
    this will compile database objects such as packages, functions and rebuilds indexes
    regards,
    steved

  • Statistics,  Rebuilding Indexes, Performance Issues

    I have a query which use to run 2-3 sec
    After taking stats and rebuliding indexes
    This Query is taking 25 sec
    Is there anyway that I can get mt performance back?
    Collected Stats
    First Using Analyze table Compute stats
    Second DBMS_STATS.GATHER_ TABLE_STATS
    Level 12 Tracing
    TKPROF: Release 9.2.0.6.0 - Production on Sun Jun 29 13:23:11 2008
    Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
    Sort options: prsela exeela fchela
    count = number of times OCI procedure was executed
    cpu = cpu time in seconds executing
    elapsed = elapsed time in seconds executing
    disk = number of physical reads of buffers from disk
    query = number of buffers gotten for consistent read
    current = number of buffers gotten in current mode (usually for update)
    rows = number of rows processed by the fetch or execute call
    SELECT ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
    ped.eft_payee_seq_no, ped.partition_desgntr,
    ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
    ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
    ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
    FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
    WHERE ped.curr_row_ind = 'A'
    AND cp.curr_row_ind = 'A'
    AND cp.clm_payee_no = el.clm_payee_no
    AND cp.mail_zip = 'XXXXXX'
    AND ped.paye_bnk_rtng_no = 'XXXXXX'
    AND ped.paye_bnk_acct_no = 'XXXXXXX'
    AND ped.payee_bnk_acct_typ = 'XXXX'
    AND ped.eft_payee_seq_no = el.eft_payee_seq_no
    call count cpu elapsed disk query current rows
    Parse 1 0.02 0.01 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 23.46 22.91 0 1292083 0 0
    total 3 23.48 22.93 0 1292083 0 0
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 117
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 1 0.00 0.00
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 1 0.02 0.01 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 23.46 22.91 0 1292083 0 0
    total 3 23.48 22.93 0 1292083 0 0
    Misses in library cache during parse: 1
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 1 0.00 0.00
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 0 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 0 0.00 0.00 0 0 0 0
    Misses in library cache during parse: 0
    1 user SQL statements in session.
    0 internal SQL statements in session.
    1 SQL statements in session.
    Trace file compatibility: 9.02.00
    Sort options: prsela exeela fchela
    1 session in tracefile.
    1 user SQL statements in trace file.
    0 internal SQL statements in trace file.
    1 SQL statements in trace file.
    1 unique SQL statements in trace file.
    41 lines in trace file.
    ****************-----==========================================*****
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
    | 0 | SELECT STATEMENT | | 1 | 73 | 5 | | |
    | 1 | NESTED LOOPS | | 1 | 73 | 5 | | |
    | 2 | NESTED LOOPS | | 12 | 708 | 4 | | |
    | 3 | TABLE ACCESS BY GLOBAL INDEX ROWID| PAYEE_EFT_DETAIL_T | 12 | 540 | 1 | ROWID | ROW L |
    |* 4 | INDEX RANGE SCAN | TEST_PAYEE_EFT_DETAIL_T_IE21 | 12 | | 3 | | |
    | 5 | TABLE ACCESS BY GLOBAL INDEX ROWID| EFT_PAYEE_LNK_T | 1 | 14 | 1 | ROWID | ROW L |
    |* 6 | INDEX RANGE SCAN | EFT_PAYEE_LNK_PK | 1 | | 1 | | |
    |* 7 | INDEX RANGE SCAN | CLM_PAYEE_T_IE10 | 1 | 14 | | | |
    Predicate Information (identified by operation id):
    4 - access("PED"."PAYE_BNK_RTNG_NO"='XXXXXXX' AND "PED"."PAYE_BNK_ACCT_NO"='XXXXXXXXXX' AND
    "PED"."PAYEE_BNK_ACCT_TYP"='CHK' AND "PED"."CURR_ROW_IND"='A')
    6 - access("PED"."EFT_PAYEE_SEQ_NO"="LNK"."EFT_PAYEE_SEQ_NO")
    7 - access("LNK"."CLM_PAYEE_NO"="CP"."CLM_PAYEE_NO" AND "CP"."MAIL_ZIP"='XXXXXX' AND "CP"."CURR_ROW_IND"='A')
    ==++++++++++++++*************************=+++++++++++++----------------=========
    TKPROF: Release 9.2.0.6.0 - Production on Sun Jun 29 19:28:39 2008
    Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
    Sort options: prsela exeela fchela
    count = number of times OCI procedure was executed
    cpu = cpu time in seconds executing
    elapsed = elapsed time in seconds executing
    disk = number of physical reads of buffers from disk
    query = number of buffers gotten for consistent read
    current = number of buffers gotten in current mode (usually for update)
    rows = number of rows processed by the fetch or execute call
    SELECT ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
    ped.eft_payee_seq_no, ped.partition_desgntr,
    ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
    ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
    ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
    FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
    WHERE ped.curr_row_ind = 'A'
    AND cp.curr_row_ind = 'A'
    AND cp.clm_payee_no = el.clm_payee_no
    AND cp.mail_zip = 'XXXXXX'
    AND ped.paye_bnk_rtng_no = 'XXXXXXXXXX'
    AND ped.paye_bnk_acct_no = 'XXXXXXXX'
    AND ped.payee_bnk_acct_typ = 'CHK'
    AND ped.eft_payee_seq_no = el.eft_payee_seq_no
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 23.30 22.75 0 1292083 0 0
    total 3 23.30 22.75 0 1292083 0 0
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 117
    Rows Row Source Operation
    0 NESTED LOOPS
    214395 NESTED LOOPS
    214395 TABLE ACCESS BY GLOBAL INDEX ROWID PAYEE_EFT_DETAIL_T PARTITION: ROW LOCATION ROW LOCATION
    214395 INDEX RANGE SCAN TEST_PAYEE_EFT_DETAIL_T_IE21 (object id 160840)
    214395 TABLE ACCESS BY GLOBAL INDEX ROWID EFT_PAYEE_LNK_T PARTITION: ROW LOCATION ROW LOCATION
    214395 INDEX RANGE SCAN EFT_PAYEE_LNK_PK (object id 75455)
    0 INDEX RANGE SCAN CLM_PAYEE_T_IE10 (object id 71871)
    alter session set sql_trace=false
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.00 0.00 0 0 0 0
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 117
    ALTER SESSION SET SQL_TRACE = TRUE
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 1 0.00 0.00 0 0 0 0
    Misses in library cache during parse: 0
    Misses in library cache during execute: 1
    Optimizer goal: CHOOSE
    Parsing user id: 117
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 2 0.00 0.00 0 0 0 0
    Execute 3 0.00 0.00 0 0 0 0
    Fetch 1 23.30 22.75 0 1292083 0 0
    total 6 23.30 22.75 0 1292083 0 0
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 0 0.00 0.00 0 0 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 0 0.00 0.00 0 0 0 0
    Misses in library cache during parse: 0
    3 user SQL statements in session.
    0 internal SQL statements in session.
    3 SQL statements in session.
    Trace file compatibility: 9.02.00
    Sort options: prsela exeela fchela
    1 session in tracefile.
    3 user SQL statements in trace file.
    0 internal SQL statements in trace file.
    3 SQL statements in trace file.
    3 unique SQL statements in trace file.
    57 lines in trace file.
    Message was edited by:
    user644525

    I have a query which use to run 2-3 sec
    After taking stats and rebuliding indexes
    This Query is taking 25 sec
    Is there anyway that I can get mt performance back?
    PLAN_TABLE_OUTPUT
    | Id  | Operation                            |  Name                         | Rows  | Bytes | Cost  | Pstart| Pstop |
    |   0 | SELECT STATEMENT                     |                               |     1 |    73 |     5 |       |       |
    |   1 |  NESTED LOOPS                        |                               |     1 |    73 |     5 |       |       |
    |   2 |   NESTED LOOPS                       |                               |    12 |   708 |     4 |       |       |
    |   3 |    TABLE ACCESS BY GLOBAL INDEX ROWID| PAYEE_EFT_DETAIL_T            |    12 |   540 |     1 | ROWID | ROW L |
    |*  4 |     INDEX RANGE SCAN                 | TEST_PAYEE_EFT_DETAIL_T_IE21  |    12 |       |     3 |       |       |
    |   5 |    TABLE ACCESS BY GLOBAL INDEX ROWID| EFT_PAYEE_LNK_T               |     1 |    14 |     1 | ROWID | ROW L |
    |*  6 |     INDEX RANGE SCAN                 | EFT_PAYEE_LNK_PK              |     1 |       |     1 |       |       |
    |*  7 |   INDEX RANGE SCAN                   | CLM_PAYEE_T_IE10              |     1 |    14 |       |       |       |
    Predicate Information (identified by operation id):
       4 - access("PED"."PAYE_BNK_RTNG_NO"='XXXXXXX' AND "PED"."PAYE_BNK_ACCT_NO"='XXXXXXXXXX' AND
                  "PED"."PAYEE_BNK_ACCT_TYP"='CHK' AND "PED"."CURR_ROW_IND"='A')
       6 - access("PED"."EFT_PAYEE_SEQ_NO"="LNK"."EFT_PAYEE_SEQ_NO")
       7 - access("LNK"."CLM_PAYEE_NO"="CP"."CLM_PAYEE_NO" AND "CP"."MAIL_ZIP"='XXXXXX' AND "CP"."CURR_ROW_IND"='A')
    ==++++++++++++++*************************=+++++++++++++----------------=========
    SELECT    ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
                    ped.eft_payee_seq_no, ped.partition_desgntr,
                    ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
                    ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
                    ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
               FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
              WHERE ped.curr_row_ind = 'A'
                AND cp.curr_row_ind = 'A'
                AND cp.clm_payee_no = el.clm_payee_no
                AND cp.mail_zip = '16803'
                AND ped.paye_bnk_rtng_no = '111000614'
                AND ped.paye_bnk_acct_no = '1586266775'
                AND ped.payee_bnk_acct_typ = 'CHK'
                AND ped.eft_payee_seq_no = el.eft_payee_seq_no
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     23.30      22.75          0    1292083          0           0
    total        3     23.30      22.75          0    1292083          0           0
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 117 
    Rows     Row Source Operation
          0  NESTED LOOPS 
    214395   NESTED LOOPS 
    214395    TABLE ACCESS BY GLOBAL INDEX ROWID PAYEE_EFT_DETAIL_T PARTITION: ROW LOCATION ROW LOCATION
    214395     INDEX RANGE SCAN TEST_PAYEE_EFT_DETAIL_T_IE21 (object id 160840)
    214395    TABLE ACCESS BY GLOBAL INDEX ROWID EFT_PAYEE_LNK_T PARTITION: ROW LOCATION ROW LOCATION
    214395     INDEX RANGE SCAN EFT_PAYEE_LNK_PK (object id 75455)
          0   INDEX RANGE SCAN CLM_PAYEE_T_IE10 (object id 71871)Trying to recreate my response to this thread that was posted yesterday...
    The query is performing 1.3 million logical reads, per the "query" column in the TKPROF output. 1.3 million 8KB (or 16KB) logical reads takes a fair amount of time, and is consuming 23.30 CPU seconds of time (execution time is 22.75 seconds). The explain plan and the row source execution plan are identical, although the predicted cardinality numbers are much lower than the actual number of rows returned, per the TKPROF output (12 rows versus 214,395 rows). The CLM_PAYEE table seems to have the greatest number of restrictions placed on it, yet Oracle is joining that table last.
    You found, per my recommendation, that adding the hint /*+ LEADING(CP) */ significantly decreased the execution time to less than one second. You may not have collected statistics on the indexes, even though you collected statistics on the tables. This may also be a sign that one or more histograms are required for the cardinality estimates to be close to accurate.
    Did your GATHER_TABLE_STATS commands look similar to the following:
    DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'PAYEE_EFT_DETAIL',CASCADE=>TRUE);
    DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'EFT_PAYEE_LNK',CASCADE=>TRUE);
    DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'CLM_PAYEE',CASCADE=>TRUE);Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Reg creation of indexes

    Hi All,
    cud anybody pls let me know abt the <b>creation and maintenace of indexes</b>??
    any screenshots or step-by-step procedure.....!!!
    its quite urgent..
    regards,
    abc xyz

    HI,
    1.In SE11 Transaction display your table.
    2.press button index... in tool bar, it will ask you
    to create a new one.
    3.give the index name
    4. give short text description
    5. in bottom table give the field name on which
    you want index.
    6. save and activate.
    check this.
    http://www.oreilly.com/catalog/sapadm/chapter/ch01.html
    To create Secondary Index --> http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
    Also Check the below links.
    http://help.sap.com/saphelp_erp2005/helpdata/en/1c/252640632cec01e10000000a155106/frameset.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/c7/55833c4f3e092de10000000a114027/frameset.htm.
    Regards,
    Sesh

  • Reg Usage of Index

    Hi PPL,
    Can anybody tell me how to use the database table Indexes in the programs?
    Regards,
    Kevin Nick.

    Hi...
    just see these links......
    Re: select statement : Secondary index 
    how to use secondary index
    http://help.sap.com/saphelp_nw04s/helpdata/en/cf/21eb2d446011d189700000e8322d00/content.htm
    http://www.sap-img.com/abap/quick-note-on-design-of-secondary-database-indexes-and-logical-databases.htm
    SELECT QUERY  BASED ON SECONDARY INDEX
    Reward points if useful,,,,,,
    Suresh......

  • 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

  • Reg: Exporting the index file

    Hi,
    Is it possible to export the indexex??

    Hi,
    yes, for example, you can put all indexes in a tablespace and export only this tablespace.
    what do you want to do?
    --sgc                                                                                                                                                                                                                                                                       

  • Reg: Recreation of Indexes

    Hi all,
    We are facing some performance issues. According to SAP suggetion we are planning to recreate some indexes. But i never created an index before...... can anybody help in this......please sugfgest in proper way to recreate indexes....
    thnx in advance
    with regards
    Harish

    Hi
    To create index:
    1. Go to DB02, click on Missing Indexes. Select index in next screen to create and click "Create in DB"
    2. if you know the table name for which you want to create the index, go to SE14 -> table name -> Go to index -> In next screen "select create".
    3. Yo have to use trx SE11 into Dev system, Enter the database table name and press
    Display -> Indexes -> Create Enter index name. Choose Maintain logon language.
    Enter short description and index fields.

  • Alter index rebuild calculates statistics?

    Hi
    Does anyone know if ALTER INDEX REBUILD gathers statistics on the index automatically? Does it do it at a 100% by default?
    Thanks for your help!!!

    On 10g+ the alter index command defaults to compute statistics which to the best o my knowledge is a 100% sample. With lower versions you need to specify that you want statistics: alter index owner.index_name rebuild compute statistics;
    HTH -- Mark D Powell --

Maybe you are looking for