Same query on different RAC instance huge execution time difference

we have 3 nodes oracle 10gR2 RAC based on ASM. The 3rd node is the latest one we added into the cluster. All instances on 3 nodes using the same system parameters and same OS and same hardware
i found a weird problem, a same query i executed on node1 is way more faster than on node3 (1.5mins VS. 18mins). Then i did trace, surprising found the fetch time for node3 is longer than node1. Both nodes are at very low load. here is part of tracing for both nodes:
node1:
call count cpu elapsed disk query current rows
Parse 1 3.40 3.47 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 19.13 97.04 69938 269374 0 7
total 4 22.54 100.51 69938 269374 0 7
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 132 0.00 0.03
library cache lock 13 0.00 0.00
library cache pin 9 0.00 0.00
rdbms ipc reply 6 0.00 0.00
latch: shared pool 1 0.00 0.00
SQL*Net message to client 2 0.00 0.00
gc current block 2-way 2061 0.00 0.67
gc cr multi block request 76610 0.18 7.71
gc current block 3-way 801 0.00 0.33
gc cr block 3-way 3 0.00 0.00
gc cr block 2-way 30 0.00 0.01
db file scattered read 1167 0.02 3.66
gc cr grant 2-way 24739 0.00 4.81
db file sequential read 37363 0.12 57.35
latch: KCL gc element parent latch 7 0.00 0.00
db file parallel read 1465 0.05 5.86
latch: cache buffers lru chain 1 0.00 0.00
gc current grant 2-way 1 0.00 0.00
gc cr block busy 10 0.17 0.37
gc cr disk read 1 0.00 0.00
SQL*Net more data to client 5 0.00 0.00
SQL*Net message from client 2 436.40 436.40
node3
call count cpu elapsed disk query current rows
Parse 1 2.58 2.64 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 11.35 299.22 37084 269364 0 7
total 4 13.94 301.86 37084 269364 0 7
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 3 0.00 0.00
row cache lock 10 0.00 0.00
SQL*Net message to client 2 0.00 0.00
gc cr grant 2-way 23126 0.01 5.01
db file sequential read 37080 1.30 277.16
gc cr multi block request 1 0.00 0.00
db file scattered read 1 0.31 0.31
read by other session 721 0.03 2.12
gc buffer busy 1248 0.03 4.78
latch: cache buffers chains 5 0.00 0.00
gc current block 3-way 332 0.00 0.17
gc current block 2-way 834 0.00 0.30
latch: KCL gc element parent latch 1 0.00 0.00
gc current grant 2-way 1 0.00 0.00
SQL*Net more data to client 5 0.00 0.00
SQL*Net message from client 2 76.12 76.12
And all the execution plan are the same.
Could anybody please tell me why this happens?
Thanks!

To me, it looks like node3 is not accessing storage as fast as node 1 is. Look at this:
db file sequential read 37363 0.12 57.35
db file sequential read 37080 1.30 277.16
both cases have roughly the same amount of reads/waits but the time waited is 5 times more in the second case. So this could indicate a problem, maybe something with the HBA or SAN path or something like that.
Bjoern

Similar Messages

  • Same query giving different results

    Hi
    I m surprised to see the behaviour of oracle. I have two different sessions for same scheema on same server. In both sessions same query returns different results. The query involves some calculations like sum and divisions on number field.
    I have imported this data from another server using export / import utility available with 9i server. Before export every thing was going fine. Is there some problem with this utility.
    I m using Developer 6i as the front end for my client server application. The behaviour of my application is very surprizing as once it shows the correct data and if I close the screen and reopen, it shows wrong data.
    I m really stucked with the abnormal behaviour. Please tell me the possiblities and corrective action for these conditions.
    Regards
    Asad.

    There is nothing uncommitted in both the sessions. But still different results are returned.
    I m sending u the exact query and result returned in both sessions.
    Session 1:
    SQL> rollback;
    Rollback complete.
    SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
    2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
    3 WHERE G.COURSE_CDE=CC.COURSE_CDE
    4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
    5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
    6 /
    CREDIT_HRS GRADE_PTS
    3 4
    4 3.33
    4 3.33
    3 4
    3 4
    3 4
    3 4
    7 rows selected.
    SQL>
    SESSION 2:
    SQL> rollback;
    Rollback complete.
    SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
    2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
    3 WHERE G.COURSE_CDE=CC.COURSE_CDE
    4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
    5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
    6 /
    CREDIT_HRS GRADE_PTS
    3 4
    4 3.33
    3 4
    3 4
    3 4
    3 4
    6 rows selected.
    SQL>
    U can see in session 1, seven rows are returned while in session 2 six rows are returned. I have issued a rollback before query to be sure that data in both sessions is same.

  • Execution time difference between SELECT & UPDATE statement in JDBC Sender.

    Hi Experts,
    In my scenario, I have used the JDBC Sender Adapter with the SELECT and UPDATE statement.
    Now the problem is in between the execution of Select and update statement, few more entries are coming in the same DB Table.
    So result of this is updation take place for those entries which are not even picked up by the select statement.
    Can we avoid this execution time difference between the SELECT & UPDATE statemet on JDBC Sender side???
    Thanks & Regards
    Jagesh

    Hi
    Use serializable option in additional parameters, now all new entries would also be updated.

  • Huge difference in Execution time in same Query with different Parameter

    Hi Experts,
    We are facing an unique problem once we are executing the query in HANA SQL prompt. This Query was generated from BObj and executing in HANA system. Once this query running with following condition, it is taking almost 7-00 minute to execute and returning around 924 rows.
    << WHERE
    Table__1."LOGSYS"  IN  ('RKGCLNT102')
    AND
    Table__1."CompanyCode"  IN  ('7240','7245')
    AND
    Table__1."Plant"  IN ……………… >
    However if we run the same query with some different plant, It is taking only 2 second. Please find the Query here.
    << WHERE
    Table__1."LOGSYS"  IN  ('RKGCLNT102')
    AND
    Table__1."CompanyCode"  IN  ('7245','7600')
    AND
    Table__1."Plant"  IN ……………… >
    This is really an unexpected behavior and we are not able to get the actual reason why it is behaving like this.
    Could anyone please help to analyze this issue to fine the root cause.
    Thanks in Advance.
    Regards
    Satrajit.

    Hi there
    Unfortunately you provided too few information to analyze the issue.
    Maybe the underlying tables have very skew data and the first select has to read a larger share of the base tables.
    Maybe the columns had been unloaded before and the first query had to load them into memory first.
    Is the runtime always bad with the one and always good with the other set of parameters?
    Have you checked the PlanViz for both versions? How do these differ?
    - Lars

  • Same Query returning different result (Different execution plan)

    Hi all,
    To day i have discovered a strange thing: a query that return a different result when using a different execution plan.
    The query :
    SELECT  *
      FROM schema.table@database a
    WHERE     column1 IN ('3')
           AND column2 = '101'
           AND EXISTS
                  (SELECT null
                     FROM schema.table2 c
                    WHERE a.column3 = SUBSTR (c.column1, 2, 12));where schema.table@database is a remote table.
    when executed with the hint /*+ ordered use_nl(a c) */ these query return no result and its execution plan is :
    Rows     Row Source Operation
          0  NESTED LOOPS  (cr=31 r=0 w=0 time=4894659 us)
       4323   SORT UNIQUE (cr=31 r=0 w=0 time=50835 us)
       4336    TABLE ACCESS FULL TABLE2 (cr=31 r=0 w=0 time=7607 us)
          0   REMOTE  (cr=0 r=0 w=0 time=130536 us)When i changed the execution plan with the hint /*+ use_hash(c a) */
    Rows     Row Source Operation
       3702  HASH JOIN SEMI (cr=35 r=0 w=0 time=497839 us)
      22556   REMOTE  (cr=0 r=0 w=0 time=401176 us)
       4336   TABLE ACCESS FULL TABLE2 (cr=35 r=0 w=0 time=7709 us)It seem that when the execution plan have changed the remote query return no result.
    It'is a bug or i have missed somthing ?
    PS: The two table are no subject to insert or update statement.
    Oracle version : 9.2.0.2.0
    System version : HP-UX v1
    Thanks.

    H.Mahmoud wrote:
    Oracle version : 9.2.0.2.0
    System version : HP-UX v1Hard to say. You're using a very old and deprecated version of the database, and one that was known to contain bugs.
    9.2.0.7 was really the lowest version of 9i that was considered to be 'stable', but even so, it's old and lacking in many ways.
    Consider upgrading to the latest database version at your earliest opportunity. (or at least apply patches up to the latest 9i version before querying if there is bugs in your really low buggy version)

  • Same query with different explain plans

    Hi All,
    I have one of the select query with different explain plans on two separate env, the query fetches the correct index on test env whereas on prod it's not fetching the same index.
    The structure, indices, no. of rows are similar in CRMINFO table with up-to-date statistics.
    Env Details :
    OS - Sun Solaris 5.10
    DB - 10.2.0.4
    Init param:
    Optimizer_mode = ALL_ROWS
    optimizer_dynamic_sampling integer 5
    optimizer_features_enable string 10.2.0.4
    optimizer_index_caching integer 90
    optimizer_index_cost_adj integer 30
    Query :*
    SELECT COUNT (*)
    FROM CRMINFO
    WHERE RETAILER = :1
    AND STATUS = 20
    AND EXC = :1
    AND SUBNO IS NULL
    Expain Plan (TST):
    SELECT STATEMENT ALL_ROWSCost: 916 Bytes: 19 Cardinality: 1                
    3 SORT AGGREGATE Bytes: 19 Cardinality: 1           
    2 TABLE ACCESS BY INDEX ROWID TABLE TST.CRMINFO Cost: 916 Bytes: 16,663 Cardinality: 877      
    1 INDEX RANGE SCAN INDEX TST.CRMINFO_X1 Cost: 42 Cardinality: 12,549
    Index (TST):
    CRMINFO_X1(EXC, RETAILER, STATUS)
    Explain Plan (PROD):
    SELECT STATEMENT ALL_ROWSCost: 1,832 Bytes: 19 Cardinality: 1                
    3 SORT AGGREGATE Bytes: 19 Cardinality: 1           
    2 TABLE ACCESS BY INDEX ROWID TABLE PROD.CRMINFO Cost: 1,832 Bytes: 2,052 Cardinality: 108      
    1 INDEX RANGE SCAN INDEX PROD.CRMINFO_X2 Cost: 117 Cardinality: 42,519
    Index (PROD):
    CRMINFO_X2 (RETAILER)
    How does Oracle calculates the cost and decides which index it should fetch ? Why it didn't choose the same index as of test env? How should i approach and which domains i need to dig-in to find the cause?
    I did try playing with the above mentioned init parameters but it didn't help at all.
    Thanks.
    Regards,
    ~Pointer

    Pointer wrote:
    Hmm, my worry is how do i force oracle to grap the proper index on prod i.e (CRMINFO_X1). I certainly believe it's a bad approach on adding a hint in the select statement and to force oralce to fetch that index.Why do you believe that, the index you mention is the "proper" index versus what Oracle is choosing? Can you prove with hinting that the "proper" index results in a faster and more efficient execution plan? If it does, then the next place I would look at is the statistics for the tables and columns of interest. From here you could try and estimate why Oracle thinks the other index is better. Another option is to run a 10053 (CBO) trace and see why Oracle thinks it is better.
    I would not support a hint in a production environment, except in the most extreme cases. Usually the CBO makes the right choice, but it only can if the statistics match the distribution of data.
    Refreshing the data may help me simulating the issue on TST but it wouldn't help me to understand why on prod it uses CRMINFO_X2 instead of CRMINFO_X1 which has all the three columns in the Where clause of the query.It would help because it's a test environment and you wouldn't have to do any queries directly on your production system to achieve the same results.
    >
    A bad thought here :( , if i create a new index by changing the column positioning say like ( RETAILER, STATUS , EXC) instead of (EXC, RETAILER, STATUS) will oracle fetch it ? or would it help in reducing the cost and cardinatlity of the select query.It's not that easy. There is a lot that goes into the cost calculation, some of that is known (through the great work by Jonathan Lewis and Richard Foote), and some of that is purely internal to Oracle. If you are more interested in the internals Cost-Based Oracle Fundamentals by Jonathan Lewis is a great book.
    HTH!

  • Same query takes different time to fetch result from Database

    Hi all,
    I am having a scenario in which a query is taking different time keeping other environmental variables constant.
    When that query runs for 1 user it takes just 2 minutes to fetch result and the DB connection becomes inactive after fetching the result.
    But if I run the same query after some time in similar environment it takes 25 minutes. sometimes 40 minutes to execute and give the result to the app server from the same database.
    I am not able to understand this behavior from DB. Can anybody try to explain this behavior?
    The details of the DB are,
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    PL/SQL Release 11.2.0.1.0 - Production
    CORE 11.2.0.1.0 Production
    TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    OS Details:
    Windows 2008 server Enterprise Edition.
    I tried analyzing that query in oracle, it recommended there are lots of hard parsing in that query.
    Regards,

    user10915512 wrote:
    Hi all,
    I am having a scenario in which a query is taking different time keeping other environmental variables constant.
    When that query runs for 1 user it takes just 2 minutes to fetch result and the DB connection becomes inactive after fetching the result.
    But if I run the same query after some time in similar environmentBut not exactly the same environment. So what is different that it is only "similar"?
    it takes 25 minutes. sometimes 40 minutes to execute and give the result to the app server from the same database.
    I am not able to understand this behavior from DB. Can anybody try to explain this behavior?Run a statspack on the 'well behaved' query and on the 'not well behaved' query. Compare and contrast the results.
    >
    The details of the DB are,
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    PL/SQL Release 11.2.0.1.0 - Production
    CORE 11.2.0.1.0 Production
    TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    OS Details:
    Windows 2008 server Enterprise Edition. To paraphrase Forest Gump, "My momma always said Windows was like a box of chocolates ...."
    >
    >
    I tried analyzing that query in oracle, it recommended there are lots of hard parsing in that query.
    Regards,

  • Dashboard having same query with different selection screen values

    Hi,
    I want to create a dashboard by including different versions (different selection screen values, like yesterday, last week, last month) of same query. Is it possible to achieve it by without creating separate queries? We are in BI 7.
    Thanks in advance
    Nisha

    Hi,
    I want to create a dashboard by including different versions (different selection screen values, like yesterday, last week, last month) of same query. Is it possible to achieve it by without creating separate queries? We are in BI 7.
    Thanks in advance
    Nisha

  • The same query but different plan?

    Hi all
    I don't understand why the same query but Oracle use different plan
    explain plan for select far.id,fab.id
    from agent_body fab
    INNER JOIN agent_ref far ON (far.bodyid = fab.id)
    WHERE fab.id=72449;
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
    | 0 | SELECT STATEMENT | | 1 | 18 | 2 (0)| 00:00:01 | | |
    | 1 | NESTED LOOPS | | 1 | 18 | 2 (0)| 00:00:01 | | |
    | 2 | PARTITION HASH SINGLE | | 1 | 6 | 1 (0)| 00:00:01 | 4 | 4 |
    |* 3 | INDEX UNIQUE SCAN | PK_AGENT_BODY | 1 | 6 | 1 (0)| 00:00:01 | 4 | 4 |
    | 4 | PARTITION HASH ALL | | 1 | 12 | 1 (0)| 00:00:01 | 1 | 4 |
    | 5 | TABLE ACCESS BY LOCAL INDEX ROWID| AGENT_REF | 1 | 12 | 1 (0)| 00:00:01 | 1 | 4 |
    |* 6 | INDEX RANGE SCAN | IXAGRAD | 1 | | 1 (0)| 00:00:01 | 1 | 4 |
    Predicate Information (identified by operation id):
    3 - access("FAB"."ID"=72449)
    6 - access("FAR"."BODYID"=72449)
    AND
    explain plan for select far.id,fab.id
    from agent_ref far,agent_body fab
    where fab.id=far.bodyid and far.id=2219306;
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
    | 0 | SELECT STATEMENT | | 1 | 18 | 2 (0)| 00:00:01 | | |
    | 1 | NESTED LOOPS | | 1 | 18 | 2 (0)| 00:00:01 | | |
    | 2 | PARTITION HASH SINGLE | | 1 | 12 | 1 (0)| 00:00:01 | 3 | 3 |
    | 3 | TABLE ACCESS BY LOCAL INDEX ROWID| AGENT_REF | 1 | 12 | 1 (0)| 00:00:01 | 3 | 3 |
    |* 4 | INDEX UNIQUE SCAN | PK_AGENT_REF | 1 | | 1 (0)| 00:00:01 | 3 | 3 |
    | 5 | PARTITION HASH ITERATOR | | 3348K| 19M| 1 (0)| 00:00:01 | KEY | KEY |
    |* 6 | INDEX UNIQUE SCAN | PK_AGENT_BODY | 3348K| 19M| 1 (0)| 00:00:01 | KEY | KEY |
    Predicate Information (identified by operation id):
    4 - access("FAR"."ID"=2219306)
    6 - access("FAB"."ID"="FAR"."BODYID")
    Can anyone explain to me?
    Thanks

    user554265 wrote:
    Hi all
    I don't understand why the same query but Oracle use different plan
    explain plan for select far.id,fab.id
    from agent_body fab
    INNER JOIN agent_ref far ON (far.bodyid = fab.id)
    WHERE fab.id=72449;
    AND
    explain plan for select far.id,fab.id
    from agent_ref far,agent_body fab
    where fab.id=far.bodyid and far.id=2219306;
    Can anyone explain to me?Perhaps this makes a difference...
    WHERE fab.id=72449; and
    and far.id=2219306; Essentially the two queries ARE different.

  • Procedure execution time difference in Oacle 9i and Oracle 10g

    Hi,
    My procedure is taking time on
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 is 14 min.
    same procedure is taking time on oracle Release 9.2.0.1.0 is 1 min.
    1) Data is same in both environment.
    2) Number of records are same 485 rows for cursor select statement.
    3)Please guide me how to reduce the time in oracle 10g for procedure?
    i have checked the explain plan for that cursor query it is different in both enviroment.
    so i have analysis that procedure is taking time on cursor fetch into statement in oracle 10g.
    example:-
    create or replace procedure myproc
    CURSOR cur_list
    IS select num
    from tbl
    where exist(select.......
    EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE = TRUE';
    EXECUTE IMMEDIATE 'ALTER SESSION SET TIMED_STATISTICS = TRUE';
    OPEN cur_list;
    LOOP
    FETCH cur_list INTO cur_list; -----My procedure is taking time in this statement only for some list number. there are 485 list number.
    end loop;
    TRACE file for oracle 10g is look like this:-
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.37 0.46 0 2 0 0
    Fetch 486 747.07 730.14 1340 56500700 0 485
    total 488 747.45 730.60 1340 56500702 0 485
    ORACLE 9i EXPLAIN PLAN FOR cursor query:-
    Plan
    SELECT STATEMENT CHOOSECost: 2 Bytes: 144 Cardinality: 12                                         
         18 INDEX RANGE SCAN UNIQUE LISL.LISL_LIST_PK Cost: 2 Bytes: 144 Cardinality: 12                                    
              17 UNION-ALL                               
                   2 FILTER                          
                        1 TABLE ACCESS FULL SLD.P Cost: 12 Bytes: 36 Cardinality: 1                     
                   16 NESTED LOOPS Cost: 171 Bytes: 141 Cardinality: 1                          
                        11 NESTED LOOPS Cost: 169 Bytes: 94 Cardinality: 1                     
                             8 NESTED LOOPS Cost: 168 Bytes: 78 Cardinality: 1                
                                  6 NESTED LOOPS Cost: 168 Bytes: 62 Cardinality: 1           
                                       4 TABLE ACCESS BY INDEX ROWID SLD.L Cost: 168 Bytes: 49 Cardinality: 1      
                                            3 INDEX RANGE SCAN UNIQUE SLD.PK_L Cost: 162 Cardinality: 9
                                       5 INDEX UNIQUE SCAN UNIQUE SLD.SYS_C0025717 Bytes: 45,760 Cardinality: 3,520      
                                  7 INDEX UNIQUE SCAN UNIQUE SLD.PRP Bytes: 63,904 Cardinality: 3,994           
                             10 TABLE ACCESS BY INDEX ROWID SLD.P Cost: 1 Bytes: 10,480 Cardinality: 655                
                                  9 INDEX UNIQUE SCAN UNIQUE SLD.PK_P Cardinality: 9           
                        15 TABLE ACCESS BY INDEX ROWID SLD.GRP_E Cost: 2 Bytes: 9,447 Cardinality: 201                     
                             14 INDEX UNIQUE SCAN UNIQUE SLD.PRP_E Cost: 1 Cardinality: 29                
                                  13 TABLE ACCESS BY INDEX ROWID SLD.E Cost: 2 Bytes: 16 Cardinality: 1           
                                       12 INDEX UNIQUE SCAN UNIQUE SLD.SYS_C0025717 Cost: 1 Cardinality: 14,078      
    ORACLE 10G EXPLAIN PLAN FOR cursor query:-                                   
         SELECT STATEMENT ALL_ROWSCost: 206,103 Bytes: 12 Cardinality: 1                                         
         18 FILTER                                    
              1 INDEX FAST FULL SCAN INDEX (UNIQUE) LISL.LISL_LIST_PK Cost: 2 Bytes: 8,232 Cardinality: 686                               
              17 UNION-ALL                               
                   3 FILTER                          
                        2 TABLE ACCESS FULL TABLE SLD.P Cost: 26 Bytes: 72 Cardinality: 2                     
                   16 NESTED LOOPS Cost: 574 Bytes: 157 Cardinality: 1                          
                        14 NESTED LOOPS Cost: 574 Bytes: 141 Cardinality: 1                     
                             12 NESTED LOOPS Cost: 574 Bytes: 128 Cardinality: 1                
                                  9 NESTED LOOPS Cost: 573 Bytes: 112 Cardinality: 1           
                                       6 HASH JOIN RIGHT SEMI Cost: 563 Bytes: 315 Cardinality: 5      
                                            4 TABLE ACCESS FULL TABLE SLD.E Cost: 80 Bytes: 223,120 Cardinality: 13,945
                                            5 TABLE ACCESS FULL TABLE SLD.GRP_E Cost: 481 Bytes: 3,238,582 Cardinality: 68,906
                                       8 TABLE ACCESS BY INDEX ROWID TABLE SLD.L Cost: 2 Bytes: 49 Cardinality: 1      
                                            7 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.PK_L Cost: 1 Cardinality: 1
                                  11 TABLE ACCESS BY INDEX ROWID TABLE SLD.P Cost: 1 Bytes: 16 Cardinality: 1           
                                       10 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.PK_P Cost: 0 Cardinality: 1      
                             13 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.SYS_C0011870 Cost: 0 Bytes: 13 Cardinality: 1                
                        15 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.PRP Cost: 0 Bytes: 16 Cardinality: 1      
    so Please guide me how to reduce the time in oracle 10g for procedure?
    1) Is this envrionment setting parameter?
    2) I have to tune the query? but which is executing fine on oracle 9i?
    so how to decrease the execution time?
    Thanks in advance.

    SELECT l_nr
    FROM x.ls b
    WHERE b.cd = '01'
    AND b.co_code = '001'
    AND EXISTS (
    SELECT T_L
    FROM g.C
    WHERE C_cd = '01'
    AND C_co_code = '001'
    AND C_flg = 'A'
    AND C_eff_dt <= sysdate
    AND C_end_dt >=
    sysdate
    AND C_type_code <> 1
    AND C_type_code <> 1
    AND targt_ls_type = 'C'
    AND T_L <> 9999
    AND T_L = b.l_nr
    UNION ALL
    SELECT l.T_L
    FROM g.C C,
    g.ep_e B,
    g.ep ep,
    g.e A,
    g.lk_in l
    WHERE l.cd = '01'
    AND l.co_code = '001'
    AND l.cd = C.C_cd
    AND l.co_code = C.C_co_code
    AND l.C_nbr = C.C_nbr
    AND l.targt_ls_type = 'C'
    AND lk_in_eff_dt <=
    sysdate
    AND lk_in_end_dt >=
    ( sysdate
    + 1
    AND ( (logic_delte_flg = '0')
    OR ( logic_delte_flg IN ('1', '3')
    AND lk_in_eff_dt <> lk_in_end_dt
    AND l.cd = ep.C_cd
    AND l.co_code = ep.C_co_code
    AND l.C_nbr = ep.C_nbr
    AND l.ep_nbr = ep.ep_nbr
    AND l.cd = A.e_cd
    AND l.co_code = A.e_co_code
    AND l.e_nbr = A.e_nbr
    AND l.cd = B.cd
    AND l.co_code = B.co_code
    AND l.C_nbr = B.C_nbr
    AND l.ep_nbr = B.ep_nbr
    AND l.e_nbr = B.e_nbr
    AND l.ep_e_rev_nbr = B.ep_e_rev_nbr
    AND B.flg = 'A'
    AND EXISTS (
    SELECT A.e_nbr
    FROM g.e A
    WHERE A.e_cd = B.cd
    AND A.e_co_code = B.co_code
    AND A.e_nbr = B.e_nbr
    AND A.e_type_code ^= 8)
    AND C_type_code <> 10
    AND C.C_type_code <> 13
    AND l.T_L = b.l_nr)
    --yes index is same                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Execution time difference between Statspack and DBM_Monitor trace

    Hi Everyone,
    We noticed that output of query execution time is quite differ between statspack and session tracing (DBMS_MONITOR) report. The query execution time in Statspack was 1402 sec and in session trace file was 312.25 Sec. FYI database version is 11.2.0.3 which is installed on platform OL 5.8
    Both of the following reports (Staspack/tracing) was executed on same system and at the same time. Could you suggest why execution time is differ in staspack and session tracing?
    Staspack execution time :-
    Elapsed Elap per CPU Old
    Time (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value
    1402.50 1 1402.50 9.1 53.92 256,142 3247794574
    select * from ( select * from ( select resourcecontentslocati
    on,isprotocolname,ismimecontenttype,indexedmetatext,objectid,met
    atext,valueaddxml,resourcetype,resourceviewedtime,iscmaresultid,
    resourcelastviewedbyuser,issequencenumber,nvl(length(contents),0
    Session tracing time:-
    call count cpu elapsed disk query current rows
    Parse 1 10.58 256.44 43364 153091 0 0
    Execute 1 0.01 0.08 0 0 0 0
    Fetch 143 2.09 55.72 25440 32978 0 1000
    total 145 12.69 312.25 68804 186069 0 1000
    Thanks
    Rajdeep

    Hi,
    First of all, please read the [url https://wikis.oracle.com/display/Forums/Forums+FAQ]FAQ page and find out how to use the code tags to format your output properly so that it's readable.
    I don't want to work out the stats formatting but I'd guess that if you ran the query first time and the data was not cached, it would be slower than the 2nd query when it was cached. The stats should confirm this so please format them so we can see it properly.
    Rob

  • INDEX Execution Time Difference

    Hi,
    I applied index in 3 columns of the table..... when i 1st executed the query it takes 345 secs but next time execution takes 45 secs,then again 17 secs and 8 secs.... I want to know why the execution time gets reduced here? please help me to understand this concept.........
    Thanks in Advance.

    when you run a query for the first time then oracle creates its hash value and execution plan and stores it in data dictionary cache and then it fetches the data from the datafile using I/O and that data is placed in the buffer cache so it takes more time. But when you run the query for second time it already has the hash value and execution plan and data in buffer cache so it takes less time.
    Edited by: saurabh on Aug 23, 2012 12:29 PM

  • Why same query takes different execution time in sql 2008

    Hi!
    With below query in SQL Server 2008 R2 when I change Book_ID  to another value like '99000349'  it takes very long time to execute while both result sets have same number of records!?
    select Card_Serial,Asset_ID, Field_Name,Field_Value,Asset_Number,Field_ID,Book_ID from dbo.vw_InspectionReport where Book_ID='99000347'
    I've test it more and more,A time I ran quickest one, or longest one first, restart Windows, but for some specific Book_ID values (although with same number of result set rows) it take multiple time slower than rest of Book_IDs.
    Also showing state of the result set is different for these diffrent Book_IDs:
    for fast ones it looks like below picture:
    for slow ones it looks like below picture:
    if you note, order of returned records are different!?
    I'm waiting for your kindly reply!...

    Do you see any changes if you add a hint to the query?
    select Card_Serial,Asset_ID, Field_Name,Field_Value,Asset_Number,Field_ID,Book_ID from dbo.vw_InspectionReport where Book_ID='99000347OPTION(RECOMPILE)
    Best Regards,Uri Dimant SQL Server MVP,
    http://sqlblog.com/blogs/uri_dimant/
    MS SQL optimization: MS SQL Development and Optimization
    MS SQL Consulting:
    Large scale of database and data cleansing
    Remote DBA Services:
    Improves MS SQL Database Performance
    SQL Server Integration Services:
    Business Intelligence

  • Same query with different execution plan

    Hello All,
    I wonder why does sql server create different execution plan for these below queries ?
    Thanks.

    You can look at the expected query plan. Either visually in SSMS, or alternatively, you can run the query after the instruction SET SHOWPLAN_TEXT ON.
    The Optimizer is the component of SQL Server that determines how the query is executed. It is cost based. It will assess different execution plans, estimate the cost of each of them and then select the cheapest. In this context, cheapest means the one with
    the shortest runtime.
    In your particular case, the estimation for the second query is, that scanning just a small part of the nonclustered index and then looking up the table data of the qualifying rows is the cheapest approach, because the estimated number of qualifying rows
    is low.
    In the first query, it estimated that looking up the many qualifying rows there would be too expensive, and that it would be cheaper to simply scan the entire clustered index, and simply filter out all unwanted rows. Note that the clustered index includes
    the actual table data.
    Gert-Jan

  • Same query takes different time for two different users with same privileges

    Hi,
    Just wanted to know if it is possible for an INSERT query to take different amount of time for two different users for the same volume of data. If so, what could be the reason? I would like to add that we are not executing the query simultaneously. But it is always faster for user1(within 10-20 seconds) and slower for user2(takes around 8-10 minutes).

    Show execution plan for each user. I think there is other reasons which you didn't not tell

Maybe you are looking for