Select Query Takes more time

Hi All,
I have cloned KSB1 tcode to custom one as required by business.
Below query takes more time than excepted.
Here V_DB_TABLE = COVP.
Values in Where clause are as follows
OBNJR in ( KSBB010000001224  BT  KSBB012157221571)
GJAHR in blank
VERSN in '000'
WRTTP in '04' and '11'
all others are blank
VT_VAR_COND = ( CPUDT BETWEEN '20091201' and '20091208' )
SELECT (VT_FIELDS) INTO CORRESPONDING FIELDS OF GS_COVP_EXT      
                    FROM (V_DB_TABLE)                             
                    WHERE LEDNR = '00'                            
                    AND   OBJNR IN LR_OBJNR                       
                    AND   GJAHR IN GR_GJAHR                       
                    AND   VERSN IN GR_VERSN                       
                    AND   WRTTP IN GR_WRTTP                       
                    AND   KSTAR IN LR_KSTAR                       
                    AND   PERIO IN GR_PERIO                       
                    AND   BUDAT IN GR_BUDAT                       
                    AND   PAROB IN GR_PAROB                       
                    AND   (VT_VAR_COND).    
Checked in table for this condition it has only 92 entries.
But when i execute program takes long time as 3 Hrs.
Could any one help me on this

>1.Dont use SELECT/ENDSELECT instead use INTO TABLE addition .
> 2.Avoid using corresponding addition.create a type and reference it.
> If the select is going for dump beacause of storage limitations ,then use Cursors.
you got three large NOs .... all three recommendations are wrong!
The SE16 test is going in the right direction ... but what was filled. Nobody knows!!!!
Select options:
Did you ever try to trace the SE16?  The generic statement has for every field an in-condition!
Without the information what was actually filled, nobody can say something there
are at least 2**n  combinations possible!
Use ST05 for SE16 and check actual statement plus explain!

Similar Messages

  • Count (*)  for select stmt take more time than  execute a that sql stmt

    HI
    count (*) for select stmt take more time than execute a that sql stmt
    executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql  command for faster execute .
    but if i tried to find out total number of rows in that query it takes more time ..
    almost 2.30 hrs still running to find count(col)
    please help me to get count of row faster.
    thanks in advance...

    797525 wrote:
    HI
    count (*) for select stmt take more time than execute a that sql stmt
    executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql  command for faster execute .
    but if i tried to find out total number of rows in that query it takes more time ..
    almost 2.30 hrs still running to find count(col)
    please help me to get count of row faster.
    thanks in advance...That may be because your client is displaying only the first few records when you are running the "SELECT *". But when you run "COUNT(*)", the whole records has to be counted.
    As already mentined please read teh FAQ to post tuning questions.

  • What is the reason for query take more time to execute

    Hi,
    What is the reason for the query take more time inside procedure.
    but if i execute that query alone then it excute within a minutes.
    query includes update and insert.

    I have a insert and update query when I execute
    without Procedure then that query execute faster but
    If I execute inside procedure then It takes 2 hours
    to execute.Put you watch 2 hours back and the problem will disappear.
    do you understand what I want to say?I understood what you wanted to say and I understood you didn't understood what I said.
    What does the procedure, what does the query, how can you say the query does the same as the procedure that takes longer. You didn't say anything useful to have an idea of what you're talking about.
    Everyone knows what means that something is slower than something else, but it means nothing if you don't say what you're talking about.
    To begin with something take a look at this
    When your query takes too long ...
    especially the part regarding the trace.
    Bye Alessandro

  • Query Takes more Time when i execute from the Instant client.

    Hi,
    Currently in our Env we have some Queries takes more time when we run from the Instant Client.
    System Details
    OS=Solaris 10 x86 64bit
    Oracle 10.2.0.4
    Client Side
    $ sqlplus trd_trd_ro/trd_trd_ro@prdba001/TRADE1
    SQL*Plus: Release 10.2.0.2.0 - Production on Mon Aug 9 16:26:25 2010
    Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.
    Connected to:
    Oracle Database 10g Release 10.2.0.4.0 - Production
    SQL> set timing on
    SQL> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
    no rows selected
    Elapsed: 00:01:54.19
    SQL> Disconnected from Oracle Database 10g Release 10.2.0.4.0 - ProductionSame Query running on Server Side
    ^C130-oracle@prdba001 txt: sql
    Database: trd_trd_owner/trd_trd_owner@prdba001/TRADE1
    SQL*Plus: Release 10.2.0.4.0 - Production on Mon Aug 9 17:15:18 2010
    Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
    Connected to:
    Oracle Database 10g Release 10.2.0.4.0 - Production
    trd_trd_owner@TRADE1>  set timing on
    trd_trd_owner@TRADE1> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
    no rows selected
    Elapsed: 00:00:00.12
    trd_trd_owner@TRADE1> exitKindly help me what could be the Issues.

    Hi Charles,
    Thanks for your Quick response.I pulled the info.
    sys@TRADE1> SELECT  * FROM  TABLE(DBMS_XPLAN.DISPLAY_CURSOR('bpxr7axhxaqvy',NULL,'ALLSTATS LAST'));
    PLAN_TABLE_OUTPUT
    SQL_ID  bpxr7axhxaqvy, child number 0
    select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
    tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
    Plan hash value: 1955857846
    | Id  | Operation                       | Name                  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    |   1 |  SORT GROUP BY NOSORT           |                       |      1 |     21 |      0 |00:00:00.06 |    6121 |
    |   2 |   VIEW                          |                       |      1 |     21 |      0 |00:00:00.06 |    6121 |
    |   3 |    UNION-ALL                    |                       |      1 |        |      0 |00:00:00.06 |    6121 |
    |   4 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.05 |    3073 |
    |*  5 |      TABLE ACCESS FULL          | TIBEX_QUOTE           |      1 |  30080 |      0 |00:00:00.05 |    3073 |
    |   6 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER           |      1 |    971 |      0 |00:00:00.01 |       3 |
    |*  8 |       INDEX RANGE SCAN          | TIBEX_ORDER_IDX_OLT   |      1 |    971 |      0 |00:00:00.01 |       3 |
    |   9 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 10 |      TABLE ACCESS FULL          | TIBEX_TSTRADE         |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  11 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 12 |      TABLE ACCESS FULL          | TIBEX_IOIREQUEST      |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  13 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |* 14 |      TABLE ACCESS FULL          | TIBEX_BESTEXREL       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |  15 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |    2862 |
    |* 16 |      INDEX FAST FULL SCAN       | SYS_C0058325          |      1 |    339 |      0 |00:00:00.01 |    2862 |
    |  17 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |      31 |
    |* 18 |      TABLE ACCESS FULL          | TIBEX_EDPPULLORDERS   |      1 |      1 |      0 |00:00:00.01 |      31 |
    |  19 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 20 |      INDEX RANGE SCAN           | SYS_C0058803          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  21 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 22 |      INDEX RANGE SCAN           | SYS_C0057785          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  23 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 24 |      INDEX RANGE SCAN           | SYS_C0057827          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  25 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 26 |      TABLE ACCESS FULL          | TIBEX_DELETEADMIN     |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  27 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 28 |      INDEX RANGE SCAN           | SYS_C0058148          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  29 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 30 |      INDEX RANGE SCAN           | SYS_C0058264          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  31 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 32 |      INDEX RANGE SCAN           | SYS_C0058516          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  33 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 34 |      INDEX RANGE SCAN           | SYS_C0058561          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  35 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 36 |      INDEX RANGE SCAN           | SYS_C0058783          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  37 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 38 |      INDEX RANGE SCAN           | SYS_C0058977          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  39 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 40 |      INDEX RANGE SCAN           | SYS_C0058859          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  41 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 42 |      INDEX RANGE SCAN           | SYS_C0059197          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  43 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 44 |      TABLE ACCESS FULL          | TIBEX_CANCELTRDADMIN  |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  45 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 46 |      TABLE ACCESS FULL          | TIBEX_BULKCANCELADMIN |      1 |      1 |      0 |00:00:00.01 |       3 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
       8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
      10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      16 - filter("USERALIAS"=:SYS_B_1)
      18 - filter("USERALIAS"=:SYS_B_1)
      20 - access("USERALIAS"=:SYS_B_1)
      22 - access("USERALIAS"=:SYS_B_1)
      24 - access("USERALIAS"=:SYS_B_1)
      26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
      28 - access("USERALIAS"=:SYS_B_1)
      30 - access("USERALIAS"=:SYS_B_1)
      32 - access("USERALIAS"=:SYS_B_1)
      34 - access("USERALIAS"=:SYS_B_1)
      36 - access("USERALIAS"=:SYS_B_1)
      38 - access("USERALIAS"=:SYS_B_1)
      40 - access("USERALIAS"=:SYS_B_1)
      42 - access("USERALIAS"=:SYS_B_1)
      44 - filter("USERALIAS"=:SYS_B_1)
      46 - filter("USERALIAS"=:SYS_B_1)
    SQL_ID  bpxr7axhxaqvy, child number 1
    select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
    tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
    Plan hash value: 1955857846
    Plan hash value: 1955857846
    | Id  | Operation                       | Name                  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    |   1 |  SORT GROUP BY NOSORT           |                       |      1 |     21 |      0 |00:00:00.12 |    8545 |
    |   2 |   VIEW                          |                       |      1 |     21 |      0 |00:00:00.12 |    8545 |
    |   3 |    UNION-ALL                    |                       |      1 |        |      0 |00:00:00.12 |    8545 |
    |   4 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.10 |    5496 |
    |*  5 |      TABLE ACCESS FULL          | TIBEX_QUOTE           |      1 |  21056 |      0 |00:00:00.10 |    5496 |
    |   6 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       4 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER           |      1 |    660 |      0 |00:00:00.01 |       4 |
    |*  8 |       INDEX RANGE SCAN          | TIBEX_ORDER_IDX_OLT   |      1 |    660 |      0 |00:00:00.01 |       4 |
    |   9 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 10 |      TABLE ACCESS FULL          | TIBEX_TSTRADE         |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  11 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 12 |      TABLE ACCESS FULL          | TIBEX_IOIREQUEST      |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  13 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |* 14 |      TABLE ACCESS FULL          | TIBEX_BESTEXREL       |      1 |      1 |      0 |00:00:00.01 |     126 |
    |  15 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.02 |    2862 |
    |* 16 |      INDEX FAST FULL SCAN       | SYS_C0058325          |      1 |    339 |      0 |00:00:00.02 |    2862 |
    |  17 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |      31 |
    |* 18 |      TABLE ACCESS FULL          | TIBEX_EDPPULLORDERS   |      1 |      1 |      0 |00:00:00.01 |      31 |
    |  19 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 20 |      INDEX RANGE SCAN           | SYS_C0058803          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  21 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 22 |      INDEX RANGE SCAN           | SYS_C0057785          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  23 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 24 |      INDEX RANGE SCAN           | SYS_C0057827          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  25 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 26 |      TABLE ACCESS FULL          | TIBEX_DELETEADMIN     |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  27 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 28 |      INDEX RANGE SCAN           | SYS_C0058148          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  29 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    PLAN_TABLE_OUTPUT
    |* 30 |      INDEX RANGE SCAN           | SYS_C0058264          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  31 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 32 |      INDEX RANGE SCAN           | SYS_C0058516          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  33 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 34 |      INDEX RANGE SCAN           | SYS_C0058561          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  35 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 36 |      INDEX RANGE SCAN           | SYS_C0058783          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  37 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 38 |      INDEX RANGE SCAN           | SYS_C0058977          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  39 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 40 |      INDEX RANGE SCAN           | SYS_C0058859          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  41 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |
    |* 42 |      INDEX RANGE SCAN           | SYS_C0059197          |      1 |      1 |      0 |00:00:00.01 |       1 |
    |  43 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 44 |      TABLE ACCESS FULL          | TIBEX_CANCELTRDADMIN  |      1 |      1 |      0 |00:00:00.01 |       3 |
    |  45 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |
    |* 46 |      TABLE ACCESS FULL          | TIBEX_BULKCANCELADMIN |      1 |      1 |      0 |00:00:00.01 |       3 |
    Predicate Information (identified by operation id):
       5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
       8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
      10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      16 - filter("USERALIAS"=:SYS_B_1)
      18 - filter("USERALIAS"=:SYS_B_1)
      20 - access("USERALIAS"=:SYS_B_1)
      22 - access("USERALIAS"=:SYS_B_1)
      24 - access("USERALIAS"=:SYS_B_1)
      26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
      28 - access("USERALIAS"=:SYS_B_1)
      30 - access("USERALIAS"=:SYS_B_1)
      32 - access("USERALIAS"=:SYS_B_1)
      34 - access("USERALIAS"=:SYS_B_1)
      36 - access("USERALIAS"=:SYS_B_1)
      38 - access("USERALIAS"=:SYS_B_1)
      40 - access("USERALIAS"=:SYS_B_1)
      42 - access("USERALIAS"=:SYS_B_1)
      44 - filter("USERALIAS"=:SYS_B_1)
      46 - filter("USERALIAS"=:SYS_B_1)
    SQL_ID  bpxr7axhxaqvy, child number 2
    select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
    tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
    Plan hash value: 1955857846
    | Id  | Operation                       | Name                  | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
    |   1 |  SORT GROUP BY NOSORT           |                       |      1 |     21 |      1 |00:00:00.13 |    8476 |      3 |
    |   2 |   VIEW                          |                       |      1 |     21 |      1 |00:00:00.13 |    8476 |      3 |
    |   3 |    UNION-ALL                    |                       |      1 |        |      1 |00:00:00.13 |    8476 |      3 |
    |   4 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.10 |    5283 |      0 |
    |*  5 |      TABLE ACCESS FULL          | TIBEX_QUOTE           |      1 |  21056 |      0 |00:00:00.10 |    5283 |      0 |
    |   6 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      1 |00:00:00.01 |     148 |      3 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER           |      1 |    660 |    150 |00:00:00.01 |     148 |      3 |
    PLAN_TABLE_OUTPUT
    |*  8 |       INDEX RANGE SCAN          | TIBEX_ORDER_IDX_OLT   |      1 |    660 |    150 |00:00:00.01 |       5 |      0 |
    |   9 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 10 |      TABLE ACCESS FULL          | TIBEX_TSTRADE         |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  11 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 12 |      TABLE ACCESS FULL          | TIBEX_IOIREQUEST      |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  13 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |     126 |      0 |
    |* 14 |      TABLE ACCESS FULL          | TIBEX_BESTEXREL       |      1 |      1 |      0 |00:00:00.01 |     126 |      0 |
    |  15 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.02 |    2862 |      0 |
    |* 16 |      INDEX FAST FULL SCAN       | SYS_C0058325          |      1 |    339 |      0 |00:00:00.02 |    2862 |      0 |
    |  17 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |      31 |      0 |
    |* 18 |      TABLE ACCESS FULL          | TIBEX_EDPPULLORDERS   |      1 |      1 |      0 |00:00:00.01 |      31 |      0 |
    |  19 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 20 |      INDEX RANGE SCAN           | SYS_C0058803          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  21 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 22 |      INDEX RANGE SCAN           | SYS_C0057785          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  23 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 24 |      INDEX RANGE SCAN           | SYS_C0057827          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  25 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 26 |      TABLE ACCESS FULL          | TIBEX_DELETEADMIN     |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  27 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 28 |      INDEX RANGE SCAN           | SYS_C0058148          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  29 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 30 |      INDEX RANGE SCAN           | SYS_C0058264          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  31 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 32 |      INDEX RANGE SCAN           | SYS_C0058516          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  33 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 34 |      INDEX RANGE SCAN           | SYS_C0058561          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  35 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 36 |      INDEX RANGE SCAN           | SYS_C0058783          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  37 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 38 |      INDEX RANGE SCAN           | SYS_C0058977          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  39 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 40 |      INDEX RANGE SCAN           | SYS_C0058859          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  41 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |* 42 |      INDEX RANGE SCAN           | SYS_C0059197          |      1 |      1 |      0 |00:00:00.01 |       1 |      0 |
    |  43 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 44 |      TABLE ACCESS FULL          | TIBEX_CANCELTRDADMIN  |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |  45 |     SORT GROUP BY NOSORT        |                       |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    |* 46 |      TABLE ACCESS FULL          | TIBEX_BULKCANCELADMIN |      1 |      1 |      0 |00:00:00.01 |       3 |      0 |
    Predicate Information (identified by operation id):
       5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
       8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
      10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
      16 - filter("USERALIAS"=:SYS_B_1)
      18 - filter("USERALIAS"=:SYS_B_1)
      20 - access("USERALIAS"=:SYS_B_1)
      22 - access("USERALIAS"=:SYS_B_1)
      24 - access("USERALIAS"=:SYS_B_1)
      26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
      28 - access("USERALIAS"=:SYS_B_1)
      30 - access("USERALIAS"=:SYS_B_1)
      32 - access("USERALIAS"=:SYS_B_1)
      34 - access("USERALIAS"=:SYS_B_1)
      36 - access("USERALIAS"=:SYS_B_1)
      38 - access("USERALIAS"=:SYS_B_1)
    PLAN_TABLE_OUTPUT
      40 - access("USERALIAS"=:SYS_B_1)
      42 - access("USERALIAS"=:SYS_B_1)
      44 - filter("USERALIAS"=:SYS_B_1)
      46 - filter("USERALIAS"=:SYS_B_1)
    249 rows selected.

  • Query Take more time on timesten

    Hi
    One query takes lot of time on timesten , while the same query takes less time on oracle
    Query :-
    select *
                    from (SELECT RELD_EM_ENTITY_ID,
                                 RELD_EXM_EXCH_ID,
                                 RELD_SEGMENT_TYPE,
                                NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
                                 ROUND(NVL(sum(RELD_RTO_EXP), -1), 2) RTO_EXP,
                                 ROUND(NVL(sum(RELD_NE_EXP), -1), 2) NET_EXP,
                                 ROUND(NVL(sum(RELD_MAR_UTILIZATION), -1),
                                       2) MAR_EXP,
                                 ROUND(decode(sign(sum(C.reld_m2m_exp)),
                                              -1,
                                              abs(sum(C.reld_m2m_exp)),
                                              0),
                                       2) M2M_EXP,
                                 NVL(OLM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
                                 EM_RP_PROFILE_ID
                            FROM ENTITY_MASTER         A,
                                 ORDER_LMT_MASTER      B,
                                 RMS_ENTITY_LIMIT_DTLS C
                           WHERE A.EM_CONTROLLER_ID = 100100010000
                             AND A.EM_ENTITY_ID = C.RELD_EM_ENTITY_ID
                             AND C.RELD_EM_ENTITY_ID = B.OLM_EPM_EM_ENTITY_ID(+)
                             AND C.RELD_SEGMENT_TYPE = 'E'
                             AND C.RELD_EXM_EXCH_ID = B.OLM_EXCH_ID(+)
                             AND C.RELD_EXM_EXCH_ID <> 'ALL'
                             AND B.OLM_SEM_SMST_SECURITY_ID(+) =
                                 'ALL'
                             AND ((A.EM_ENTITY_TYPE IN ('CL') AND
                                 A.EM_CLIENT_TYPE <> 'CC') OR
                                 A.EM_ENTITY_TYPE <> 'CL')
                             AND B.OLM_PRODUCT_ID(+) = 'M' --Added by Harshit Shah on 4th June 09
                           GROUP BY RELD_EM_ENTITY_ID,
                                    RELD_EXM_EXCH_ID,
                                    RELD_SEGMENT_TYPE,
                                    RELD_ACC_TYPE,
                                    OLM_SUSPNSN_FLG,
                                    EM_RP_PROFILE_ID,
                                    OLM_PRODUCT_ID
                          UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
                          SELECT RELD_EM_ENTITY_ID,
                                 RELD_EXM_EXCH_ID,
                                 RELD_SEGMENT_TYPE SEGMENTID,
                               NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
                                 ROUND(NVL(SUM(RELD_RTO_EXP), -1), 2) RTO_EXP,
                                 ROUND(NVL(SUM(RELD_NE_EXP), -1), 2) NET_EXP,
                                 ROUND(NVL(SUM(RELD_MAR_UTILIZATION), -1),
                                       2) MAR_EXP,
                                 ROUND(decode(sign(SUM(C.reld_m2m_exp)),
                                              -1,
                                              abs(SUM(C.reld_m2m_exp)),
                                              0),
                                       2) M2M_EXP,
                                 NVL(OLM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
                                 EM_RP_PROFILE_ID
                            FROM ENTITY_MASTER         A,
                                 ORDER_LMT_MASTER      B,
                                 RMS_ENTITY_LIMIT_DTLS C
                           WHERE A.EM_CONTROLLER_ID = 100100010000
                             AND A.EM_ENTITY_ID = B.OLM_EPM_EM_ENTITY_ID
                             AND B.OLM_EPM_EM_ENTITY_ID = C.RELD_EM_ENTITY_ID(+)
                             AND C.RELD_SEGMENT_TYPE = 'E'
                             AND B.OLM_EXCH_ID = 'ALL'
                             AND B.OLM_SEM_SMST_SECURITY_ID(+) =
                                 'ALL'
                             AND ((A.EM_ENTITY_TYPE IN ('CL') AND
                                 A.EM_CLIENT_TYPE <> 'CC') OR
                                 A.EM_ENTITY_TYPE <> 'CL')
                             AND B.OLM_PRODUCT_ID(+) = 'M' --Added by Harshit Shah on 4th June 09
                           GROUP BY RELD_EM_ENTITY_ID,
                                    RELD_EXM_EXCH_ID,
                                    RELD_SEGMENT_TYPE,
                                    RELD_ACC_TYPE,
                                    OLM_SUSPNSN_FLG,
                                    EM_RP_PROFILE_ID,
                                    OLM_PRODUCT_ID
                          UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
                          SELECT RELD_EM_ENTITY_ID,
                                 RELD_EXM_EXCH_ID,
                                 RELD_SEGMENT_TYPE,
                                 NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
                                 ROUND(NVL(sum(RELD_RTO_EXP), -1), 2) RTO_EXP,
                                 ROUND(NVL(sum(RELD_NE_EXP), -1), 2) NET_EXP,
                                 ROUND(NVL(sum(RELD_MAR_UTILIZATION), -1),
                                       2) MAR_EXP,
                                 ROUND(decode(sign(sum(C.reld_m2m_exp)),
                                              -1,
                                              abs(sum(C.reld_m2m_exp)),
                                              0),
                                       2) M2M_EXP,
                                 NVL(OLIM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
                                 EM_RP_PROFILE_ID
                            FROM ENTITY_MASTER             A,
                                 DRV_ORDER_INST_LMT_MASTER B,
                                 RMS_ENTITY_LIMIT_DTLS     C
                           WHERE A.EM_CONTROLLER_ID = 100100010000
                             AND A.EM_ENTITY_ID = C.RELD_EM_ENTITY_ID
                             AND C.RELD_EM_ENTITY_ID =
                                 B.OLIM_EPM_EM_ENTITY_ID(+)
                             AND C.RELD_SEGMENT_TYPE = 'D'
                             AND C.RELD_EXM_EXCH_ID = B.OLIM_EXCH_ID(+)
                             AND C.RELD_EXM_EXCH_ID <> 'ALL'
                             AND B.OLIM_INSTRUMENT_ID(+) = 'ALL'
                             AND ((A.EM_ENTITY_TYPE IN ('CL') AND
                                 A.EM_CLIENT_TYPE <> 'CC') OR
                                 A.EM_ENTITY_TYPE <> 'CL')
                           GROUP BY RELD_EM_ENTITY_ID,
                                    RELD_EXM_EXCH_ID,
                                    RELD_SEGMENT_TYPE,
                                    RELD_ACC_TYPE,
                                    OLIM_SUSPNSN_FLG,
                                    EM_RP_PROFILE_ID
                          UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
                          SELECT RELD_EM_ENTITY_ID,
                                 RELD_EXM_EXCH_ID,
                                 RELD_SEGMENT_TYPE SEGMENTID,
                                 NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
                                 ROUND(NVL(SUM(RELD_RTO_EXP), -1), 2) RTO_EXP,
                                 ROUND(NVL(SUM(RELD_NE_EXP), -1), 2) NET_EXP,
                                 ROUND(NVL(SUM(RELD_MAR_UTILIZATION), -1),
                                       2) MAR_EXP,
                                 ROUND(decode(sign(SUM(C.reld_m2m_exp)),
                                              -1,
                                              abs(SUM(C.reld_m2m_exp)),
                                              0),
                                       2) M2M_EXP,
                                 NVL(OLIM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
                                 EM_RP_PROFILE_ID
                            FROM ENTITY_MASTER             A,
                                 DRV_ORDER_INST_LMT_MASTER B,
                                 RMS_ENTITY_LIMIT_DTLS     C
                           WHERE A.EM_CONTROLLER_ID = 100100010000
                             AND A.EM_ENTITY_ID = B.OLIM_EPM_EM_ENTITY_ID
                             AND B.OLIM_EPM_EM_ENTITY_ID =
                                 C.RELD_EM_ENTITY_ID(+)
                             AND C.RELD_SEGMENT_TYPE = 'D'
                             AND B.OLIM_EXCH_ID = 'ALL'
                             AND B.OLIM_INSTRUMENT_ID(+) = 'ALL'
                             AND ((A.EM_ENTITY_TYPE IN ('CL') AND
                                 A.EM_CLIENT_TYPE <> 'CC') OR
                                 A.EM_ENTITY_TYPE <> 'CL')
                           GROUP BY RELD_EM_ENTITY_ID,
                                    RELD_EXM_EXCH_ID,
                                    RELD_SEGMENT_TYPE,
                                    RELD_ACC_TYPE,
                                    OLIM_SUSPNSN_FLG,
                                    EM_RP_PROFILE_ID)
                   ORDER BY RELD_EM_ENTITY_ID,
                            RELD_SEGMENT_TYPE,
                            RELD_EXM_EXCH_ID;
    Please suggest  what should i check for this.

    As always when examining SQL performance, start by checking the query execution plan. If you use ttIsql you can just prepend EXPLAIN to the query and the plan will be displayed. e.g.
    EXPLAIN  select ...........;
    Check the plan is optimal and all necessary indexes are in place. You may need to add indexes depending o what the plan shows.
    Please note that Oracle database can, and usually does, execute many types of query in parallel using multiple CPU cores. TimesTen does not currently support parallelisation of individual queries. Hence in some cases Oracle database may indeed be faster than TimesTen due to the parallel execution that occurs in Oracle.
    Chris

  • Query takes more time from client

    Hi,
    I have a select query (which refers to views and calls a function), which fetches results in 2 secs when executed from database. But takes more than 10 mins from the client.
    The tkprof for the call from the client is given below. Could you please suggest, what is going wrong and how this can be addressed?
    The index IDX_table1_1 is on col3.
    Trace file: trace_file.trc
    Sort options: exeela 
    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 ROUND(SUM(NVL((col1-col2),(SYSDATE - col2)
    FROM
    table1 WHERE col3 = :B1 GROUP BY col3
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute   7402      0.27       7.40          0          0          0           0
    Fetch     7402      1.13      59.37       1663      22535          0        7335
    total    14804      1.40      66.77       1663      22535          0        7335
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 32  (ORADBA)   (recursive depth: 1)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          0   SORT (GROUP BY NOSORT)
          0    TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 'table1'
                   (TABLE)
          0     INDEX   MODE: ANALYZED (RANGE SCAN) OF 'IDX_table1_1'
                    (INDEX)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                      1663        1.37         57.71
    OVERALL TOTALS FOR ALL NON-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
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                     16039        3.09        385.04
      db file scattered read                         34        0.21          1.42
      latch: cache buffers chains                    26        0.34          2.14
      SQL*Net break/reset to client                   2        0.05          0.05
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     2       79.99         79.99
      SQL*Net message to dblink                       1        0.00          0.00
      SQL*Net message from dblink                     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   7402      0.27       7.40          0          0          0           0
    Fetch     7402      1.13      59.37       1663      22535          0        7335
    total    14804      1.40      66.77       1663      22535          0        7335
    Misses in library cache during parse: 0
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                      1663        1.37         57.71
        1  user  SQL statements in session.
        0  internal SQL statements in session.
        1  SQL statements in session.
        1  statement EXPLAINed in this session.
    Trace file: trace_file.trc
    Trace file compatibility: 10.01.00
    Sort options: exeela 
           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.
           1  SQL statements EXPLAINed using schema:
               ORADBA.prof$plan_table
                 Default table was used.
                 Table was created.
                 Table was dropped.
       84792  lines in trace file.
        4152  elapsed seconds in trace file.Edited by: agathya on Feb 26, 2010 8:39 PM

    I have a select query (which refers to views and calls a function), which fetches results in 2 secs when >executed from database. But takes more than 10 mins from the client.You are providing proof for the latter part of your statement above.
    But not for the former part (fetches in 2 secs when exec'd from db).
    It would have been nice if you also provide the sql-trace information for that.
    Without it we cannot help you much. Other than making the observation that you obviously have a query that is I/O bound, and that I/O on your system is rather slow: on average an I/O takes 0.04 seconds (66.77 divided by 1663).

  • Query takes more time

    Hi,
    My emp table contains one milion of records.
      delete from emp;
      commit;
      select count(*)
      from emp;
      I had perform the above three queries parallely. After applying the commit operation, To retrive the no.of records
    in that table it takes some more time after that it display the result zero.
    I have faced this question recently in one of the interview. why it is taking some more time..
    can any one help me?

    Did you read the link provided?
    A high water mark is the set of blocks that have at one point contained data. You
    might have 1000 blocks allocated to a table but only 500 are under the HWM.
    The blocks under the HWM are the blocks that will be read when the table is full scanned. In your sample code, when you insert 1Milion records, the data will reside in some number of blocks - Say 1000. Now the HWM is 1000. When you delete the data, HWM will not get reset..
    And after delete, when you count, a FULL TABLE SCAN will happen. Which will scan all the blocks under HWM. So, here 1000 blocks will get read, even if there is no "data". That way your query will take time..
    Whats the solution? - Do a TRUNCATE or do a SHRINK.
    NOW - Tell us - What is your concern?

  • Oracle SQL Select query takes long time than expected.

    Hi,
    I am facing a problem in SQL select query statement. There is a long time taken in select query from the Database.
    The query is as follows.
    select /*+rule */ f1.id,f1.fdn,p1.attr_name,p1.attr_value from fdnmappingtable f1,parametertable p1 where p1.id = f1.id and ((f1.object_type ='ne_sub_type.780' )) and ( (f1.id in(select id from fdnmappingtable where fdn like '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#%')))order by f1.id asc
    This query is taking more than 4 seconds to get the results in a system where the DB is running for more than 1 month.
    The same query is taking very few milliseconds (50-100ms) in a system where the DB is freshly installed and the data in the tables are same in both the systems.
    Kindly advice what is going wrong??
    Regards,
    Purushotham

    SQL> @/alcatel/omc1/data/query.sql
    2 ;
    9 rows selected.
    Execution Plan
    Plan hash value: 3745571015
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | SORT ORDER BY | |
    | 2 | NESTED LOOPS | |
    | 3 | NESTED LOOPS | |
    | 4 | TABLE ACCESS FULL | PARAMETERTABLE |
    |* 5 | TABLE ACCESS BY INDEX ROWID| FDNMAPPINGTABLE |
    |* 6 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
    |* 7 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE |
    |* 8 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
    Predicate Information (identified by operation id):
    5 - filter("F1"."OBJECT_TYPE"='ne_sub_type.780')
    6 - access("P1"."ID"="F1"."ID")
    7 - filter("FDN" LIKE '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#
    8 - access("F1"."ID"="ID")
    Note
    - rule based optimizer used (consider using cbo)
    Statistics
    0 recursive calls
    0 db block gets
    0 consistent gets
    0 physical reads
    0 redo size
    0 bytes sent via SQL*Net to client
    0 bytes received via SQL*Net from client
    0 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    9 rows processed
    SQL>

  • Select query taking more time..

    Hi friends..
    The below inner join statement is taking more time ,  can any  body sugget me to improve the performance . I tried FOR ALL ENTRIES also but that also taking more time than inner join statement .
    SELECT a~vbeln from vbap as a inner join vakpa as b
          on avbeln = bvbeln
          into corresponding fields of table IT_VAKPA
          where a~WERKS IN S_IWERKS
          and a~pstyv NE 'ZRS'
          and b~vkorg = IVKORG
          and b~audat IN IAUDAT
          and b~vtweg IN IVTWEG.
    Regards
    Chetan

    Hi Chetan ,
    VAKPA is an index table. From the select query , it has been observed that you are not fetching any data from VAKPA. Only you have added some selection paramenters in where clause of select query.
    My suggestion will be instead of using VAKPA in inner join you use VBAK along with VBAP. All the fields that you are using as selection condition from VAKPA are there in VBAK.
    I am sure performance of query will be improved.
    If still duo to business logic you need to use VAKPA, try to create secondary non unique index on fields VKORD,AUDATand VTWEG on table VAKPA.
    However I will recommend you to go for first option only. If this does not work then go for second option.
    Hopfully this will help you.
    Regards,
    Nikhil

  • Select query take long time

    Hi All.
    When i execute select query from View it takes about 00:00:45:12 sec to pull the data , but when i execute same query in some other system(different database with same table structure) it takes about 00:00:02:05 sec.
    1)I have tried by dropped and recreated the index then i tried by exec dbms_stats.gather_table_stats procedure still no luck.
    Please help me to understand the reason difference in response time
    Thanks
    sankar

    did you run the EXPLAIN PLAN?

  • Select query takes long time....

    Hi Experts,
    I am using a select query in which inspection lot is in another table and order no. is in another table. this select query taking very long time, what is the problem in this query ? Pl. guide us.
    select bPRUEFLOS bMBLNR bCPUDT aAUFNR amatnr aLGORT a~bwart
    amenge aummat asgtxt axauto
    into corresponding fields of table itab
    *into table itab
    from mseg as a inner join qamb as b
    on amblnr = bmblnr
    and azeile = bzeile
    where b~PRUEFLOS in insp
    and  b~cpudt in date1
    and b~typ = '3'
    and a~bwart = '321'
    and a~aufnr in aufnr1.
    Yusuf

    hi
    instead of using 'move to corresponding of itab'  fields use  'into table itab'.....
    coz......if u use move to corresponding it will search for all the appropriate fields then it will place u r data........instead of that declare apprpiate internal table and use 'into table itab'.
    and one more thing dont use joins ......coz joins will decrease u r performance .....so instead of that use 'for all entries' ....and mention all the key fields in where condition ........
    ok
    reward points for helpful answers

  • Query take more time to execute

    Hi
    I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performance
    thank's

    [email protected] wrote:
    I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performanceI have a query that is using even more time to execute. Do I win?

  • Delete Query takes more time

    Hi,
    My database in 10g(10.2.0.4), I fire delete query which deletes 5 Lacs records from the table but it is taking more time to delete.
    My table and indexes on that table in Nologging mode, Database in Archive Log Mode.
    Can you please help to minize the time?
    Execution Plan
    0 DELETE STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=62)
    1 0 DELETE OF 'CORP_MESSAGEQUEUE'
    2 1 INDEX (RANGE SCAN) OF 'INDEX_CORP_MESSAGEQUEUE_PROC' (IN
    DEX) (Cost=2 Card=1 Bytes=62)
    Statistics
    754 recursive calls
    635137 db block gets
    4773 consistent gets
    181579 physical reads
    268073944 redo size
    630 bytes sent via SQL*Net to client
    608 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    1 sorts (memory)
    4 sorts (disk)
    483328 rows processed
    Anand

    Even if the table is in nologing mode there will be redo generated for the DML. It is clear from your statistics that redo is being generated for the delete. Loging is only effective for few of the operations as given bellow. I think there is no issue with the query the redo and undo generation is taking time. Just tune your configuration like.
    No redo log files.
    size of redo log.
    Undo tablespace size.
    undo retentation.
    Pga_aggrigate_target.
    temporary tablespace sizing.
    754 recursive calls
    635137 db block gets
    4773 consistent gets
    181579 physical reads
    **268073944 redo size**
    630 bytes sent via SQL*Net to client
    608 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    1 sorts (memory)
    4 sorts (disk)
    483328 rows processed
    NOLOGGING: Oracle will generate a minimal number of redo log entries in order to protect the data dictionary, and the operation will probably run faster. Logging can be disabled at the table level or the tablespace level.
    If it is done at the tablespace level then we create indexes or tables in this tablespace; they will be in NOLOGGING mode.
    A table or an index can be created with NOLOGGING mode or it can be altered using ALTER TABLE/INDEX NOLOGGING.
    NOLOGGING is active in the following situations and while running one of the following commands but not after that.
    - DIRECT LOAD (SQL*Loader)
    - DIRECT LOAD INSERT (using APPEND hint)
    - CREATE TABLE ... AS SELECT
    - CREATE INDEX
    - ALTER TABLE MOVE
    - ALTER TABLE ... MOVE PARTITION
    - ALTER TABLE ... SPLIT PARTITION
    - ALTER TABLE ... ADD PARTITION (if HASH partition)
    - ALTER TABLE ... MERGE PARTITION
    - ALTER TABLE ... MODIFY PARTITION, ADD SUBPARTITON, COALESCE SUBPARTITON, REBUILD UNUSABLE INDEXES
    - ALTER INDEX ... SPLIT PARTITION
    - ALTER INDEX ... REBUILD
    - ALTER INDEX ... REBUILD PARTITION
    Logging is stopped only while one of the commands above is running.
    So if a user runs this:
    ALTER INDEX new_index NOLOGGING.
    The actual rebuild of the index does not generate redo (all data dictionary changes associated with the rebuild will do) but after that any DML on the index will generate redo this includes direct load insert on the table which the index belongs to.
    All the following statements will generate redo despite the fact the table is in NOLOGGING mode:
    - INSERT INTO new_table_nolog_test ...,
    - UPDATE new_table_nolog_test SET ...,
    - DELETE FROM new_table_nolog_test ..
    The following will not generate redo (except from dictionary changes and indexes):
    - INSERT /*APPEND/ ...
    - ALTER TABLE new_table_nolog_test MOVE ...
    - ALTER TABLE new_table_nolog_test MOVE PARTITION ...
    practicle example:
    SQL> select value OLD_VALUE
    from v$mystat, v$statname
    where v$mystat.statistic# = v$statname.statistic#
    and v$statname.name = 'redo size'; 2 3 4
    OLD_VALUE
    0
    SQL> /
    OLD_VALUE
    0
    SQL>
    SQL> create table T_NOLOG nologging as select * from all_objects;
    Table created.
    SQL> select (value - &OLD_VALUE) OLD_VALUE
    from v$mystat, v$statname
    where v$mystat.statistic# = v$statname.statistic#
    and v$statname.name = 'redo size'; 2 3 4
    Enter value for old_value: 0
    old 1: select (value - &OLD_VALUE) OLD_VALUE
    new 1: select (value - 0) OLD_VALUE
    OLD_VALUE
    91848
    SQL> delete from T_NOLOG ;
    106229 rows deleted.
    SQL> select (value - &OLD_VALUE) OLD_VALUE
    from v$mystat, v$statname
    where v$mystat.statistic# = v$statname.statistic#
    and v$statname.name = 'redo size'; 2 3 4
    Enter value for old_value: 91848
    old 1: select (value - &OLD_VALUE) OLD_VALUE
    new 1: select (value - 91848) OLD_VALUE
    OLD_VALUE
    39389988
    SQL>

  • Select Statement takes more time after immediate insert statement..

    Hello,
    I found below scenario
    1. I have table TABLE1 which has index on COL1 field. It has around 40 columns and 100000 rows.
    2. whenever i insert 100000 rows in bulk with changing indexed key column and executing SELECT statement in same session then it takes around 3 mins to complete.
    3. However, if i open new session and execute same select statement then it returns in 2-3 seconds.
    I didnt get anything in XPLAN.. :(
    I felt Buffer Clean is cause to take time. please let me know your opinion.
    Thanks in Advance
    Sach

    sach09 wrote:
    Hello,
    I found below scenario
    1. I have table TABLE1 which has index on COL1 field. It has around 40 columns and 100000 rows.
    2. whenever i insert 100000 rows in bulk with changing indexed key column and executing SELECT statement in same session then it takes around 3 mins to complete.
    3. However, if i open new session and execute same select statement then it returns in 2-3 seconds.
    I didnt get anything in XPLAN.. :(
    I felt Buffer Clean is cause to take time. please let me know your opinion.Are you running the query in the other session after running it from the first?
    Aman....

  • Query take more time

    hi all ,
    can you please advice me in my plans
    i have query run daily as a job it take 3 minute always
    but today it takes 1:10 hours why this happen i see the jobs there is no other job running in the time of this query run
    by the way can you tell me what i need to check ??????
    MANY THANKS

    Hi,
    when query's performance changes like that, the primary suspect is a change in the execution plan. You can use this query to check this:
    select begin_interval_time, plan_hash_value
    from dba_hist_snapshot sn,
            dba_hist_sqlstat st
    where sn.snap_id = st.snap_id
    and sql_id = <sql_id here>
    order by begin_interval_time desc;Once you confirm that this is due to a change in the execution plan (there other scenarios possible, but less likely), you can start looking why the change
    occured.
    Most common causes are change in statistics, appearance or removal of histograms, or bind variables peeking unusual values.
    Best regards,
    Nikolay

Maybe you are looking for