01.09.2016 Views

Beginning Oracle Database 11g Administration From Novice to Professional

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

382<br />

CHAPTER 17 SQL TUNING<br />

Identifying Inefficient SQL Statements<br />

When an application is performing poorly or a batch job takes a long time, we have <strong>to</strong><br />

identify SQL statements that are consuming a lot of resources and are candidates for tuning.<br />

The simplest way <strong>to</strong> do this is <strong>to</strong> watch the operation of the database by using a GUI<br />

<strong>to</strong>ol such as Enterprise Manager or SQL Developer. In Figure 17-1, you can see a query<br />

being run by .<br />

Figure 17-1. Using SQL Developer <strong>to</strong> moni<strong>to</strong>r sessions<br />

A systematic way of identifying tuning candidates in a batch job is <strong>to</strong> trace the job. If<br />

you ask <strong>Oracle</strong> <strong>to</strong> trace a job, it records SQL statements and execution details in a trace<br />

file. The simplest way <strong>to</strong> start tracing a session is <strong>to</strong> use Enterprise Manager or SQL Developer<br />

as in Figure 17-1. You can also use the command as in the<br />

following example:<br />

<br />

You can then use the <strong>to</strong>ol <strong>to</strong> summarize the information in a more readable<br />

form, as in Listing 17-1. You can see that a particular statement was executed 163 times—<br />

execution statistics are also displayed. In this case, the number of logical reads—the<br />

number of buffers gotten for consistent read—is zero because the information is coming<br />

from dynamic performance tables, not from actual database tables.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!