Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, subrahmanyam.

Asked: March 31, 2009 - 4:04 am UTC

Last updated: February 13, 2018 - 1:41 am UTC

Version: 9.2.0

Viewed 10K+ times! This question is

You Asked

Hi Tom,

I have very big confusion regarding execute to parse ratio in statspack.
i have observed this ratio in my statspack as 12.02. is it really bad?
we are suggesting the parameter change (cusor_sharing=similar) to improve this ratio. is it correct ?

please can you explain what this ratio actually meant ?


Thanks

subrahmanyam

and Tom said...

the only way to influence that number is to either change

a) the number of times you parse.
b) the number of times you execute.

The formula used:

,' Execute to Parse %:' dscr
, round(100*(1-:prse/:exe),2) pctval


If the number of parse calls is near the number of execute calls, then this ratio drifts towards zero (as yours is). As the number of execute calls increases (while holding parse calls constant), this number drifts towards 100%. That means you have parsed a statement ONCE and executed it MANY TIMES (that is good, that is best)

cursor sharing = similar MIGHT change a hard parse into a soft parse (take a very very very bad thing and make it simply very very bad). cursor sharing similar CANNOT change the number of times parse is invoked however.

There is precisely, exactly and only ONE person that can do that. That is the application developer.


When they say "parse this", we parse it - it matters not what the value of cursor sharing is (if you have a hard parse problem, if your soft parse percent is below 99%, you need to have the coders FIX that, you have (in addition to performance, memory, scalability issues) a HUGE security risk if you are not using binds).

The developers must cache open cursors they know will be used over and over. The easiest way (to me) to accomplish this is to move all SQL into plsql, plsql automagically caches statements for us, it is the most efficient method to interface with the database.

Alternatively, they can program it, or they can see if the API they are using can do it magically for them (search for jdbc statement caching on google for example if you are using jdbc)


But it will have to be done in the application, there is nothing we can do outside of the application to influence how often it parses.

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

subrahmanyam k, April 01, 2009 - 1:35 am UTC

good explanation. very very useful for me to proceed with the tuning.

Atul Gupta, April 01, 2009 - 2:56 am UTC

Hello,
I believe you always state to use SQL instead of PL/SQL and you promote writing SQL always not PL SQL now you say **The easiest way (to me) to accomplish this is to move all SQL into plsql, plsql automagically caches statements for us, it is the most efficient method to interface with the database. ***

Can you pls clarify ?
Tom Kyte
April 01, 2009 - 9:22 am UTC

I say:

I have a pretty simple mantra when it comes to developing database software:

o You should do it in a single SQL statement if at all possible.
o If you cannot do it in a single SQL Statement, then do it in PL/SQL.
o If you cannot do it in PL/SQL, try a Java Stored Procedure.
o If you cannot do it in Java, do it in a C external procedure.
o If you cannot do it in a C external routine, you might want to seriously
think about why it is you need to do itÂ…




which means

DO NOT:
for x in ( select * from t )
loop
   insert into t2 values X;
end loop;


DO INSTEAD:

insert into t2 select * from t;



which means

DO NOT:
for x in (select * from t) 
loop
   for y in (select * from t2 where t2.c = x.C)
   loop
         .....

DO INSTEAD:

for x in ( select * from t, t2 where t.C = t2.c )
loop




You have to use code sometime - to process the result of a query for example, you have transactions that take MULTIPLE sql statements. For example, to transfer $50 from checking to savings probably takes AT LEAST two sql statements (an update to the account table, an insert to a transaction table - and probably most people would use two updates to account to debit and then credit - although they could do it in one)


So, take the multiple sql statements OUT OF YOUR CODE in the client, put them in a stored procedure and use that.





Muhammet, April 01, 2009 - 3:20 am UTC

I think the point which I understand
from tom, is try to solve problems in sql (set) logic,
not procedural logic. If you solve in sql, oracle kernel
do the most of work.

From my point of view what tom says is not "don't write sql in plsql".
Sql can be in plsql, but try to solve problems in a single sql. It is not important whether it is in plsql. But it has
advantages for your application if sql located in pl/sql.

Please correct me,
if I am wrong.
Tom Kyte
April 01, 2009 - 9:24 am UTC

you got it.

non-sharable sql

Kevin, April 02, 2009 - 12:50 pm UTC

Our execute to parse ration seems very low to me about 20%, and the number of shared sql also seems very low. A count of v$sql_shared_cursor shows about 27k statements. But, when I look in that view for the reason I don't really see one. We use bind variables throughout the application adn the view shows 'N' for all the reasons. This issue is causing us problems because the number of open cursors continues to grow, statements don't get shared, and the cpu's get swamped with parse requests. I know this is application specific but I need your advice about getting the right information for my developers.
Tom Kyte
April 02, 2009 - 1:08 pm UTC

what is the output of this

select count(distinct sql_id), count(*) from v$sql_shared_cursor;





and you know, you cannot decrease the number of parses unless and until you.......

fix the application code. The application calls prepare statement - and we do it. We can only stop doing it if the application stops telling us to do it.

please re-read the original answer, I tried to be very unambiguous regarding that fact in there.

Execute to Parse percentage low

Yogesh Chaudhari, February 12, 2018 - 8:20 pm UTC

We have RAC database which has Execute to Parse percentage low (around 30%). But I don't see any SQL without bind in AWR top SQLs.

How can I find the SQLs which are causing low Execute to Parse percentage?

Please advise.

Best regards, Yogesh