How to work out how many of the parse count are hard/soft? [ID 34433.1]

How to work out how many of the parse count are hard/soft? [ID 34433.1]

PURPOSE

This article shows how to monitor soft and hard parses using raw SQL_TRACE and TKPROF.

SCOPE

Analysts wanting background information on hard or soft parses.

How to work out how many of the parse count are hard/soft?

When a SQL statement is submitted to oracle, checks occur to see if that statement has already been processed and if the resultant parse information still exists in the library cache. If this is the case then Oracle can utilise this information again and does not have to repeat the parse activity. The reuse of parse information is known as a soft parse. Generating parse information from scratch is know as a hard parse. Hard parses can consume significantly more resource than soft parses and so avoiding them should be beneficial. See Note:32895.1 SQL Parsing Flow Diagram for more information on the parsing process.

The following steps illustrate soft and hard parses. Note that step 5 will force all subsequent SQL statements to hard parse the next time that they are run so testing on a live production system is inadvisable.

1. ALTER SESSION SET sql_trace=true;
2. SELECT * FROM dual WHERE 600=600; -- Expected Hard Parse
3. SELECT /* Dummy */ * FROM dual WHERE 600=600; -- Expected Hard Parse
4. SELECT * FROM dual WHERE 600=600; -- Expected Soft Parse
5. ALTER system FLUSH shared_pool;
6. SELECT * FROM dual WHERE 600=600; -- Expected Hard Parse

NOTE: Note that Step 3 is different from Steps 2,4 and 6. Even though the only difference is a comment (/* Dummy */) that makes no difference to the data set returned or to the chosen access path, the statement is still treated as a different statement by Oracle.

These steps generate SQL_TRACE output as follows:

Raw SQL_TRACE

Raw Trace output is from Oracle9i release 9.2.0 on Solaris.

Step 1: ALTER SESSION SET sql_trace=true;
Sets up the tracing.

Step 2: select * from dual where 600=600

PARSING IN CURSOR #1 len=32 dep=0 uid=109 oct=3 lid=109 tim=328242274096 hv=2021
551448 ad='21cc5d4c'
select * from dual where 600=600
END OF STMT
PARSE #1:c=0,e=2160,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=328242274073
EXEC #1:c=0,e=126,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=328242274741
FETCH #1:c=0,e=208,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=328242275207
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=328242276279
..
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=222 op='TABLE ACCESS FULL DUAL '

From the raw trace above, the 'PARSE #1' line indicates that there has been a parse call for this statement. The 'mis=1' entry on this line indicates that this is a hard parse.

Step 3: select /* Dummy */ * from dual where 600=600;

PARSING IN CURSOR #1 len=44 dep=0 uid=109 oct=3 lid=109 tim=328245863439 hv=4155
56111 ad='21cc07fc'
select /* Dummy */ * from dual where 600=600
END OF STMT
PARSE #1:c=10000,e=1828,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=328245863418
EXEC #1:c=0,e=77,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=328245863867
FETCH #1:c=0,e=167,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=328245864284
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=328245865330
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=222 op='TABLE ACCESS FULL DUAL '

Another 'hard' parse ( mis=1) as expected since this SQL has not been parsed before.

Step 4: select * from dual where 600=600;

 
PARSING IN CURSOR #1 len=32 dep=0 uid=109 oct=3 lid=109 tim=328250975145 hv=2021
551448 ad='21cc5d4c'
select * from dual where 600=600
END OF STMT
PARSE #1:c=0,e=354,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=328250975125
EXEC #1:c=0,e=108,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=328250975561
FETCH #1:c=0,e=184,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=328250976009
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=328250977032
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=222 op='TABLE ACCESS FULL DUAL '

Since this select is a repeat of Step 2 it has already been parsed and, in this case, the parse information is still in the library cache, the query is found in the shared pool and a soft parse occurs. The parse line shows this as mis=0.

Step 5: ALTER system FLUSH shared_pool;
This step 'removes' all the SQL in the shared pool

Step 6: select * from dual where 600=600;

PARSING IN CURSOR #1 len=33 dep=0 uid=109 oct=3 lid=109 tim=328261680757 hv=2409
74811 ad='21fff274'
 select * from dual where 600=600
END OF STMT
PARSE #1:c=60000,e=63411,p=0,cr=57,cu=0,mis=1,r=0,dep=0,og=4,tim=328261680736
EXEC #1:c=0,e=71,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=328261681114
FETCH #1:c=0,e=138,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=328261681504
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=328261682605
XCTEND rlbk=0, rd_only=1
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=222 op='TABLE ACCESS FULL OBJ#(222) ' 

(The trace output above follows large amounts of recursive SQL that has also had to be reparsed due to flushing ALL SQL from the shared pool).
The query in this step is the same as the query in Step 2 and Step 4 Step 2 was a hard parse whereas Step 4 was soft parsed. This time a hard parse is required since the SQL has been flushed from the shared pool and so the parse line shows ' mis=1'.

TKProf Output

If the output is formatted in TKProf then it will look similar to the following:

Steps 2, 4 and 6:

select *
from
 dual where 600=600
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        3      0.03       0.32          0          4          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        6      0.00       0.00          0          9          0           3
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       12      0.03       0.32          0         13          0           3
Misses in library cache during parse: 2
Optimizer goal: CHOOSE
Parsing user id: 109
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL DUAL
******************************************************************************

Note: The Parse count above shows 3 parse calls. This consists of two Hard Parses ( Step 2 and Step 6) and a single soft parse ( Step 4).
'Misses in library cache during parse: 2' records where the SQL was not found (i.e. a library cache miss) in the library cache and indicates that 2 of the parses were hard parses. Step 4 found an existing entry in the library cache for this statement and therefore, only a soft parse was necessary.

Step 3:

select /* Dummy */ *
from
 dual where 600=600
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          3          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0          3          0           1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 109
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL DUAL
  
******************************************************************************

In this case the Query shows a hard parse as the parse count is 1 and the ' Misses in library cache during parse: 1'.