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

Similar Messages

Query with different parameter take different time to execute.

Hi,
I am a C/C++ programmer and newbie to database. I find weird case to my company database. oracle 10g.
I have a query (below). When I set GENRE_ID value to 20, query execution time only take *5* seconds. But when I change to 10, it take *54* seconds! The same query but different values GENRE_ID (20 or 10) -- it also happen to other GENRE_ID values.
on below query
WHERE substr(GENRE_ID,0,2) = 10 and GENRE_ID != 10) take 54 seconds
WHERE substr(GENRE_ID,0,2) = 20 and GENRE_ID != 20) take 5 seconds
The explain plan give exact same result for both queries.
I have follow Re: 3. How to improve the performance of my query? / My query is running slow. for optimizer but the problem still there.
And we have rebuilt all indexes.
Anyone can help me? I need any advises for this problem.
Note:
Song table only have 570K records and Song_vod table 1100 records.
Query:
select *
from(
select rownum rowno, a.*
from(
select a.SONG_VOD_ID, a.SONG_ID, a.VOD_TITLE, a.ALBUM_ID, a.ARTIST_ID, a.VOD_ISSUE_DATE, a.VOD_ORDER_ISSUE_DATE, a.VOD_ADULT_YN, a.VOD_L_IMG_PATH, a.VOD_M_IMG_PATH, a.VOD_S_IMG_PATH, a.RECOMMEND_CNT, a.OPPOSE_CNT, get_song_name(a.SONG_ID) SONG_NAME, get_album_name(a.ALBUM_ID) ALBUM_NAME, get_artist_name(a.ARTIST_ID) ARTIST_NAME, VOD_ISSUE_DATE vodIssueDate
from SONG_VOD a inner join SONG b on a.SONG_ID = b.SONG_ID
where a.LC_STATUS_CD = 'CS0006'
AND (b.GENRE_ID
in (
select GENRE_ID
from MD_GENRE
WHERE substr(GENRE_ID,0,2) = 10
and GENRE_ID != 10)
OR b.GENRE_ID
in (
select GENRE_ID
from MD_GENRE
WHERE substr(GENRE_ID,0,2) = '40'
and GENRE_ID != '40'
) order by a.REG_DATE desc, a.SONG_VOD_ID desc
) a WHERE rownum <= 0 + 30
Thank you,
Regards
-=Rika Chaniago=-

907814 wrote:
I am a C/C++ programmer and newbie to database. I find weird case to my company database. oracle 10g.
I have a query (below). When I set GENRE_ID value to 20, query execution time only take *5* seconds. But when I change to 10, it take *54* seconds! The same query but different values GENRE_ID (20 or 10) -- it also happen to other GENRE_ID values.This is to be expected. Even an IDENTICAL query can (and often will) have DIFFERENT execution times.
The typical reason is how fast the query process can get to the data block(s) containing the relevant row(s). Is that data block still on disk and require expensive and slow physical I/O to move it into the buffer cache for use? Is that data block already cached for much faster logical I/O access? If in memory, is there any contention in getting a latch for the chain the data block hangs off from (how hot is that block)? Etc.
The run-time environment is not static. Thus execution times of queries (called cursors in Oracle) is not static. Execution times are expected to vary.
Some basics. SQL code is source code. SQL code needs to be parsed and converted into a set of instructions that the server can execute. So it is similar to C/C++. SQL source code needs to be compiled. This executable code in Oracle is called a cursor.
Like your code, the cursor can be executed with different input variables (bind variables). However, that code would have been compiled using certain assumptions about the data. And that executable code may work fine for some input data, and work not so okay for other input data. As the input parameter values are not not equal. E.g. there are a 1000 rows to process when employee type parameter is "employee" and only 10 rows when it is "manager". The code could have been compiled with the assumption that 10 rows would be the average for all input parameters - the Cost Based Optimiser needs to base its decision on the best execution path for that SQL source code on certain assumptions about the data. These may not always be correct. (usually due incorrect or stale stats about the data)
Thus you also need to look at what the execution plan is (the URL for which has already been supplied).
The Oracle® Database Performance Tuning Guide is at http://www.oracle.com/pls/db112/portal.all_books

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!

Significant difference in response times for same query running on Windows client vs database server

I have a query which is taking a long time to return the results using the Oracle client.
When I run this query on our database server (Unix/Solaris) it completes in 80 seconds.
When I run the same query on a Windows client it completes in 47 minutes.
Ideally I would like to get a response time equivalent on the Windows client to what I get when running this on the database server.
In both cases the query plans are the same.
The query and plan is shown below :
{code}
SQL> explain plan
2 set statement_id = 'SLOW'
3 for
4 SELECT DISTINCT /*+ FIRST_ROWS(503) */ objecttype.id_object
5 FROM documents objecttype WHERE objecttype.id_type_definition = 'duotA9'
6 ;
Explained.
SQL> select * from table(dbms_xplan.display('PLAN_TABLE','SLOW','TYPICAL'));
PLAN_TABLE_OUTPUT
| Id | Operation          | Name      | Rows | Bytes |TempSpc| Cost (%CPU)|
|   0 | SELECT STATEMENT   |           | 2852K|    46M|       | 69851   (1)|
|   1 | HASH UNIQUE       |           | 2852K|    46M|   153M| 69851   (1)|
|* 2 |   TABLE ACCESS FULL| DOCUMENTS | 2852K|    46M|       | 54063   (1)|
{code}
Are there are configuration changes that can be done on the Oracle client or database to improve the response times for the query when it is running from the client?
The version on the database server is 10.2.0.1.0
The version of the oracle client is also 10.2.0.1.0
I am happy to provide any further information if required.
Thank you in advance.

I have a query which is taking a long time to return the results using the Oracle client.
When I run this query on our database server (Unix/Solaris) it completes in 80 seconds.
When I run the same query on a Windows client it completes in 47 minutes.
There are NO queries that 'run' on a client. Queries ALWAYS run within the database server.
A client can choose when to FETCH query results. In sql developer (or toad) I can choose to get 10 rows at a time. Until I choose to get the next set of 10 rows NO rows will be returned from the server to the client; That query might NEVER complete.
You may get the same results depending on the client you are using. Post your question in a forum for whatever client you are using.

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

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

Execution time of same program makes big difference

Hello all,
The execution time of same program in PRD system and QAS system makes big difference.
The difference of data is not much(as system copy was run on a regular time schedule. And the system enviroments are exactly the same. However, while the program only cost 2-3 seconds in QAS, it cost 7-8 minutes in PRD.
It only happens when trying to join some tables together.
I've checked the execution plans of same search, they are different:
QAS:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT ,   T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX ,   T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP ,   T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '350' AND   T_00.BUKRS = 'MC51' AND   T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND   T_01.MANDT = '350' AND   T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND   T_01.PARTNER = T_00.REPKE AND   T_02.MANDT = '350' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 666 , Estimated #Rows = 72 )
---   12 HASH JOIN
( Estim. Costs = 666 , Estim. #Rows = 72 )
Estim. CPU-Costs = 37,505,220 Estim. IO-Costs = 663
Access Predicates
--   9 HASH JOIN
( Estim. Costs = 268 , Estim. #Rows = 51 )
Estim. CPU-Costs = 18,679,663 Estim. IO-Costs = 267
Access Predicates
--   6 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 38 )
Estim. CPU-Costs = 264,164 Estim. IO-Costs = 25
--   4 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 27 )
Estim. CPU-Costs = 258,494 Estim. IO-Costs = 25
--   2 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
( Estim. Costs = 25 , Estim. #Rows = 24 )
Estim. CPU-Costs = 253,454 Estim. IO-Costs = 25
Filter Predicates
1 INDEX RANGE SCAN DIFT_POS_IDENT~SA
( Estim. Costs = 1 , Estim. #Rows = 554 )
Search Columns: 1
Estim. CPU-Costs = 29,801 Estim. IO-Costs = 1
Access Predicates
3 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX UNIQUE SCAN TZPA~0
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 242 , Estim. #Rows = 2,540 )
Estim. CPU-Costs = 10,811,361 Estim. IO-Costs = 241
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 207 , Estim. #Rows = 2,540 )
Search Columns: 3
Estim. CPU-Costs = 9,790,330 Estim. IO-Costs = 207
Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 397 , Estim. #Rows = 2,380 )
Estim. CPU-Costs = 11,235,469 Estim. IO-Costs = 396
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 323 , Estim. #Rows = 2,380 )
                   Search Columns: 3
                   Estim. CPU-Costs = 10,288,477 Estim. IO-Costs = 323
                   Access Predicates Filter Predicates
PRD:
Execution Plan
SELECT STATEMENT ( Estimated Costs = 209 , Estimated #Rows = 1 )
---   12 NESTED LOOPS
( Estim. Costs = 208 , Estim. #Rows = 1 )
Estim. CPU-Costs = 18.996.864 Estim. IO-Costs = 207
--   9 NESTED LOOPS
( Estim. Costs = 120 , Estim. #Rows = 1 )
Estim. CPU-Costs = 10.171.528 Estim. IO-Costs = 119
--   6 NESTED LOOPS
Estim. CPU-Costs = 27.634 Estim. IO-Costs = 0
--   4 NESTED LOOPS
Estim. CPU-Costs = 27.424 Estim. IO-Costs = 0
1 INDEX RANGE SCAN TZPA~0
Search Columns: 1
Estim. CPU-Costs = 5.584 Estim. IO-Costs = 0
Access Predicates
---   3 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Filter Predicates
2 INDEX RANGE SCAN DIFT_POS_IDENT~PT
Search Columns: 1
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 120 , Estim. #Rows = 1 )
Estim. CPU-Costs = 10.143.893 Estim. IO-Costs = 119
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 119 , Estim. #Rows = 1 )
Search Columns: 4
Estim. CPU-Costs = 10.142.167 Estim. IO-Costs = 119
Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 89 , Estim. #Rows = 1 )
Estim. CPU-Costs = 8.825.337 Estim. IO-Costs = 88
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 88 , Estim. #Rows = 1 )
                   Search Columns: 4
                   Estim. CPU-Costs = 8.823.742 Estim. IO-Costs = 88
                   Access Predicates Filter Predicates
Could anyone tell me the reason? I've found note 724545 but not sure.
And, how to read the execution plan?(1 first or 12 first?)
Best Regards,
Robin

Hello Michael.
Thank you.
However, the sql statement is same:
QAS:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT ,   T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX ,   T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP ,   T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '350' AND   T_00.BUKRS = 'MC51' AND   T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND   T_01.MANDT = '350' AND   T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND   T_01.PARTNER = T_00.REPKE AND   T_02.MANDT = '350' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 666 , Estimated #Rows = 72 )
---   12 HASH JOIN
( Estim. Costs = 666 , Estim. #Rows = 72 )
Estim. CPU-Costs = 37,505,220 Estim. IO-Costs = 663
Access Predicates
--   9 HASH JOIN
( Estim. Costs = 268 , Estim. #Rows = 51 )
Estim. CPU-Costs = 18,679,663 Estim. IO-Costs = 267
Access Predicates
--   6 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 38 )
Estim. CPU-Costs = 264,164 Estim. IO-Costs = 25
--   4 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 27 )
Estim. CPU-Costs = 258,494 Estim. IO-Costs = 25
--   2 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
( Estim. Costs = 25 , Estim. #Rows = 24 )
Estim. CPU-Costs = 253,454 Estim. IO-Costs = 25
Filter Predicates
1 INDEX RANGE SCAN DIFT_POS_IDENT~SA
( Estim. Costs = 1 , Estim. #Rows = 554 )
Search Columns: 1
Estim. CPU-Costs = 29,801 Estim. IO-Costs = 1
Access Predicates
3 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX UNIQUE SCAN TZPA~0
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 242 , Estim. #Rows = 2,540 )
Estim. CPU-Costs = 10,811,361 Estim. IO-Costs = 241
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 207 , Estim. #Rows = 2,540 )
Search Columns: 3
Estim. CPU-Costs = 9,790,330 Estim. IO-Costs = 207
Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 397 , Estim. #Rows = 2,380 )
Estim. CPU-Costs = 11,235,469 Estim. IO-Costs = 396
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 323 , Estim. #Rows = 2,380 )
                   Search Columns: 3
                   Estim. CPU-Costs = 10,288,477 Estim. IO-Costs = 323
                   Access Predicates Filter Predicates
PRD:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT ,   T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX ,   T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP ,   T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '500' AND   T_00.BUKRS = 'MC51' AND   T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND   T_01.MANDT = '500' AND   T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND   T_01.PARTNER = T_00.REPKE AND   T_02.MANDT = '500' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 209 , Estimated #Rows = 1 )
---   12 NESTED LOOPS
      |    ( Estim. Costs = 208 , Estim. #Rows = 1 )
      |    Estim. CPU-Costs = 18.996.864 Estim. IO-Costs = 207
      |--   9 NESTED LOOPS
      |   |   ( Estim. Costs = 120 , Estim. #Rows = 1 )
      |   |   Estim. CPU-Costs = 10.171.528 Estim. IO-Costs = 119
      |   |--   6 NESTED LOOPS
      |   |   |   Estim. CPU-Costs = 27.634 Estim. IO-Costs = 0
      |   |   |--   4 NESTED LOOPS
      |   |   |   |   Estim. CPU-Costs = 27.424 Estim. IO-Costs = 0
      |   |   |   |-----1 INDEX RANGE SCAN TZPA~0
      |   |   |   |       Search Columns: 1
      |   |   |   |       Estim. CPU-Costs = 5.584 Estim. IO-Costs = 0
      |   |   |   |       Access Predicates
      |   |   |   ---   3 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
      |   |   |       |   Estim. CPU-Costs = 210 Estim. IO-Costs = 0
      |   |   |       |   Filter Predicates
      |   |   |       -
2 INDEX RANGE SCAN DIFT_POS_IDENT~PT
      |   |   |               Search Columns: 1
      |   |   |               Estim. CPU-Costs = 210 Estim. IO-Costs = 0
      |   |   |               Access Predicates
      |   |   -
5 INDEX RANGE SCAN TRACT_POSCONTEXTID
      |   |           Search Columns: 2
      |   |           Estim. CPU-Costs = 210 Estim. IO-Costs = 0
      |   |           Access Predicates
      |   ---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
      |       |   ( Estim. Costs = 120 , Estim. #Rows = 1 )
      |       |   Estim. CPU-Costs = 10.143.893 Estim. IO-Costs = 119
      |       -
7 INDEX RANGE SCAN ZTM0108~0
      |               ( Estim. Costs = 119 , Estim. #Rows = 1 )
      |               Search Columns: 4
      |               Estim. CPU-Costs = 10.142.167 Estim. IO-Costs = 119
      |               Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
          |    ( Estim. Costs = 89 , Estim. #Rows = 1 )
          |    Estim. CPU-Costs = 8.825.337 Estim. IO-Costs = 88
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 88 , Estim. #Rows = 1 )
                   Search Columns: 4
                   Estim. CPU-Costs = 8.823.742 Estim. IO-Costs = 88
                   Access Predicates Filter Predicates
Only difference is the client.
I see that QAS use index SA on table DIFT_POS_IDENT first, while PRD deal with table TZPA first...Is it the reason?
Best Regards,
Robin

What is the difference in execution time between a program written in C language and the same program made with LabView?

what is the difference in execution time between a program written in C language and the same program made with LabView?

Hi Pepe
You cannot say which is faster, the LV or the C programm. The only way to be sure is to program in both environments and to check than. Check this for some benchmark examples:
http://zone.ni.com/devzone/conceptd.nsf/webmain/DC9B6DD177D91D6286256C9400733D7F?OpenDocument&node=200059
Luca
Regards,
Luca

Same sqlID with different execution plan and Elapsed Time (s), Executions time

Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74

The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade

Execution time of sql query differing a lot between two computer

hi
execution time of a query in my computer and more than 30 different computer is less than one second but on one of our
customers' computers, execution time is more than ten minute. databases and data and queries are same. i re-install sql but problem remains. my sql is ms sql 2008 r2.
any one has idea for this problem?

Hi mahdi,
Obviously, we can't get enough information to help you troubleshoot this issue. So, please elaborate your issue with more detail so that the community members can help you in more effecient manner.
In addition, here is a good article regarding checklist for analyzing Slow-Running queries. Please see:
http://technet.microsoft.com/en-us/library/ms177500(v=sql.105).aspx
And SQL Server Profiler and Performance Monitor are good tools to troubleshoot performance issue, please see:
Correlating SQL Server Profiler with Performance Monitor:
https://www.simple-talk.com/sql/database-administration/correlating-sql-server-profiler-with-performance-monitor/
Regards,
Elvis Long
TechNet Community Support

Need a Query to Get Execution time of each query in Proc if its running

I am looking for query which give total execution time of individual query running currently ?
we have queries but it will give cumulative time from the start date,
for example - if stored proc has 10 queries , if each query taking 10 seconds it should show me 10 secoond if its running, not from when stored proc execution started , if you have any query please let me know
only for running queries ,

Is this the logic you're after?
DECLARE @timeStamp DATETIME2 = CURRENT_TIMESTAMP, @lapTimeStamp DATETIME2, @x INT = 0
SET @lapTimeStamp = CURRENT_TIMESTAMP
WHILE @x < 10000
BEGIN
SET @x = @x + 1
END
PRINT CAST(DATEDIFF(MS,@TIMESTAMP,CURRENT_TIMESTAMP) AS VARCHAR) + ' milliseconds have elapsed since the begining of the proc. ' + CAST(DATEDIFF(MS,@lapTimeStamp,CURRENT_TIMESTAMP) AS VARCHAR) + ' have elapsed since the last batch'
SET @lapTimeStamp = CURRENT_TIMESTAMP
SET @x = 0
WHILE @x < 10000
BEGIN
SET @x = @x + 1
END
PRINT CAST(DATEDIFF(MS,@TIMESTAMP,CURRENT_TIMESTAMP) AS VARCHAR) + ' milliseconds have elapsed since the begining of the proc. ' + CAST(DATEDIFF(MS,@lapTimeStamp,CURRENT_TIMESTAMP) AS VARCHAR) + ' have elapsed since the last batch'
SET @lapTimeStamp = CURRENT_TIMESTAMP
SET @x = 0
WHILE @x < 10000
BEGIN
SET @x = @x + 1
END
PRINT CAST(DATEDIFF(MS,@TIMESTAMP,CURRENT_TIMESTAMP) AS VARCHAR) + ' milliseconds have elapsed since the begining of the proc. ' + CAST(DATEDIFF(MS,@lapTimeStamp,CURRENT_TIMESTAMP) AS VARCHAR) + ' have elapsed since the last batch'

Different execution plan for same query but for different condition value

Hi All,
I'm facing a strange situation where same query for different condition not working.
1--
Select top 10 * from revenuefact(nolock)
where feecode ='OW4'
2--
Select top 10 * from revenuefact(nolock)
where feecode ='BTE'
1st query is returning result easily but 2nd query is taking too long. Column
feecode has already Non-clustered index and Clustered index is also available for another col RevenueSID.
I was surprised when checked the query execution plan for both the above queries which is quite different (as per attached below). Can anyone suggest me the reason behind it.
And solution for the same. One more thing that data for feecode BTE is inserting through different source instead of others feecode and table contains more than 300 million rows.

When I speak with people inside Microsoft who work with the optimizer, the refuse to accept the work "bug" when a query produces the correct result, but with a suboptimal plan. They prefer to use the word "limitation".
The limitation here is that when the optimizer compares two plans, it only looks at the estimated cost. As far as I know, it does not perform any analysis from the perspective "what if the statistics are wrong"? They do provide the hint OPTIMIZE
FOR UNKNOWN, but that does not work then there is a constant as in this case.
The optimizer will surely distinguish between TOP 10 and TOP 10000000. With the latter, you have all reason to expect a Clustered Index Scan no matter which value you search for - unless you pick a value for which the histogram indicates that there are no
rows.
Interesting enough, I was able to reproduce the situation in my Northgale database, which is an inflated version of Northwind, and where statistics should be accurate.
SELECT TOP 10 * FROM Orders WHERE EmployeeID = 8
results in a CI scan, and so does also EmployeeID = 7, and even 5. There are only 2292 rows out of a total of 344305 rows. If I try EmployeeID 808 for which there are 1797, the optimizer goes for the index seek.
Erland Sommarskog, SQL Server MVP, [email protected]

How to find the execution time of a query?

hi guys,
i need to find the execution time of a query.
i tried finding it in rsrt but couldn find the execution time.
pleasse let me know the way to do it..
regards
sagar

Hi sagar,
If you want to know the frontend time, first of all you need to maitain the BW Statistics. To maintain you have to go the respective target and click on it. Go to the tools, select BW Statistics of infoprovider. It pop ups a window there you find two check boxes 1) WHM and 2) Front end time. Check both.
Now Exe query and close the analyzer. Then go to SE11 table RSDDSTAT. There is one field which displays Frentend time.
OR
Go to STO3 here also you can analys the frontend time.
If you feel useful Assign Pts.
Regards,
Vishal

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.

Why can't two different users use Itunes on the same computer with different log ins

Why can't two different users use Itunes on the same computer with different log ins

Pmorgan5672 wrote:
Why can't two different users use Itunes on the same computer with different log ins
They can, but not at the same time.
If one user left iTunes running, and another user tries to use iTunes from a different Windows user ID, that second user will get an error message. If they really want to use iTunes, they either have to beg the first user to log in and close iTunes, or else they have to restart the computer.
If you are asking the technical reason why, it is something about context switching.

Huge difference in Execution time in same Query with different Parameter

Similar Messages

Maybe you are looking for