Database Reference
In-Depth Information
Step 7: Execute the Statement
This step executes the SQL statement and retrieves rows from disk or memory and places the values into the bind
variables. If the statement is a query or an INSERT statement, no rows need to be locked because no data is being
changed. If the statement is an UPDATE or DELETE statement, however, all rows that the statement affects are locked
from use by other users of the database until the next COMMIT , ROLLBACK , or SAVEPOINT for the transaction. This
protects the data from being changed by other sessions while it is being modified. This ensures data integrity.
When data is modified, before and after images describing the changes are written to the redo log buffer and the
undo segments.
Step 8: Fetch Rows
From the bind variables defined in Step 5, the values that are obtained as a result of the statement execution, and
the placement of values in the bind variables rows, are selected and ordered (if requested by the query), and each
successive fetch retrieves another row of the result until the last row has been fetched. These results are returned into
a table format to the calling interface.
Step 9: Close the Cursor
Once the data is returned to the calling interface, the cursor is closed.
Iteration of Steps 1 thru 6 will help generate the execution plan for the statement. The execution plan is then
stored in the library cache and reused when another session executes the same statement.
When tuning an SQL statement, it's this process that we are trying to improve so response time to get the data
back to the user is improved.
Capturing Execution Times
One of the first steps in looking at the performance of a query is to determine its execution time. During this analysis,
it is important to understand where most of the time was spent by the session. What step in the query plan took
the most time? An important parameter that drives keeping the time is the TIMED_STATISTICS and a few other
parameters:
TIMED_STATISTICS
TIMED_OS_STATISTICS
STATISTICS_LEVEL
OPTIMIZER_USE_PENDING_STATISTICS (New in Oracle Database 12c, Version 1)
TIMED_STATISTICS
This is a very important parameter; turning this off will disable most of the time-based statistics gathering useful
information for a scientific analysis. For example, when generating a 10046 trace, disabling this parameter will not
show time statistics in the report. Check if the parameter has been enabled. If not, this needs to be turned on. Setting
the STATISTICS_LEVEL parameter to TYPICAL , for example, automatically enables TIMED_STATISTICS to TRUE .
 
Search WWH ::




Custom Search