0
The above snapshot says it all. Hence it is said, 'Picture says it all'.
Basically, there are 4-5 steps. There are two possible ways of query being executed.
1. Soft Parse- Improves performance. This is also called as 'Library Cache Hit'.
2. Hard Parse- Degrades performance. This is also called as 'Library Cache Miss'.
Let us understand the steps one by one briefly.
There is a parser inside Oracle, which parses the SQL Query for further processing.
The first 3 steps of SQL Query Execution are taken care of by the parser.
Step 1: Syntax check
This checks only for syntax errors. A pure syntax check and nothing else.
Examples: 1. Are the keywords correct?
Like, 'seelect', 'form', 'groupby', 'orderby' are few common spelling mistakes.
2. Does SQL Query end with a semicolon (;)?
3. Are column names in the 'Select' Clause are separated by commas (,)?
4. Does 'Select' clause include only the colmuns which are present in the 'Group by' clause?
5. Does 'Group by' clause appear after 'Where clause'?
6. Is 'Order by' clause the last clause in the query?
etc. etc....
In each of these cases, if the answer is 'No', oracles throws an error stating the same.
Step 2: Sematic chck
Once the query passes the Syntax check, next step is Semantic check.
Here, the references of all objects present in the query are checked along with user privileges. The check happens against metadata maintained in the Oracle.
Examples: 1. Is table name valid or such a table exists?
2. Are columns names correct?
3. Does user have select/update/delete/insert/create privilege?
etc. etc. etc.
So during Syntax check, it doesn't check for the validity of table names, column names, privileges etc.
Let's say, I am running this... "select * from epm;"
This passes Syntax check, though I am writing a wrong table name. Instead of "emp", I have written "epm". But, this query is fine syntax-wise and hence passes the Syntax check. But it fails in the next step of Semantic check where the object names are verified.
But we will not be able to notice whether a query failed at Syntax check or at Semantic check when we run a query from SQL*Plus or any other GUI. Because, everything is handled in one go from user point of view and the errors are sent if the Query fails at any step. Otherwise, we get the final output.
Step 3: Shared pool check
This is an important check. I am planning to write a separte lesson on this. Let us understand briefly here.
Basically, once the query passed both Syntax check and Semantic check, it goes for third check called 'Shared pool check'.
Just to put it briefly, 'Shared pool' is a memory segment present inside every Oracle instance, which retains the recently executed SQL and PLSQL code inside its 'Library Cache' based on LRU algorithm.
So, if parser finds that the query is present inside 'Library Cache' or 'Shared pool', then it is called 'Soft Parse'. It goes to step 5, executes the query and sends the output to whoever requested it.
As simple as that. But, if parser finds that such a query is not present inside 'Shared pool' or 'Library Cache', then it is called 'Hard Parse'. So, Oracle must carry out step 4 first to prepare the query and then go to step 5 finally to execute the query and then send the output to the requestor.
So, the first three steps are always carried out for every SQL Query and they are less expensive.
Step 4:
The step 4 is very expensive or costly. Meaning, it consumes lot of resources to complete this, like CPU, I/O reads, physical reads, extra algorithms to generate mutliple queries and select the best one etc.
Hence, 'Hard Parse' degrades performance. We should keep this in mind always before writing any query. To put it simply for now, avoid hard coding and use bind variables to take the advantage of 'Soft Parse'.
Step 4 happens only in case of 'Hard parse', which is decided in step 3 as we discussed above.
We can split this into two sub-steps.
a. Optimization: The Optimizer generates mutliple plans using various combinations of joins (Nested loop/Sort Merge/Hash), access paths (full table scan/index range scan/index skip scan etc) and join orders.
Finally selects the best plan based on cost. The lower the cost, the better the performance.
b. Row source generation: Query execution plan is generated for the best query
selected in the above step. This is what we see in Explain plan.
We can further make modifications to the query, force the Optimizer to select an even lower cost query by changing access paths, joins, join orders or using Hints. And we can verify if the execution plan got changed by again looking at its Explain plan.
This is called 'Performance tuning' or 'Query Tuning'. Let's not go deep into it now.
None of this happens in case of 'Soft Parse' and hence improves performance.
Step 5: Query Execution
Step 5 is again common for each query irresepctive of whether it is 'Soft Parse' or 'Hard Parse'.
As we already discussed, it executes the SQL Query and sends the output
to the requested program or user.
So this is about it. To wrap up, there are two ways of execution or parsing namely- 'Hard parse' and 'Soft Parse'. And there are 5 steps totally. Steps 1 to 3 are common for every query or for each type of execution/parsing. Step 4 happens only for 'Hard Parse' way of execution and not for 'Soft Parse' way. Step 5 is the final and common step, which finally executes the SQL Query. Use Explain plan to check the execution plan selected by Optimizer and tune the query. Use Bind variables to enable 'Soft Parse'.
