Application sql issues_and_tuning

Application SQL Issues and Tuning
Dan Hotka
Director of Database Field Operations
Quest Software, Inc
This paper and presentation are based SQL, the various tools available for gathering information
and understanding various parts of the SQL Explain Plan, or the path that Oracle8/8i will use to
find the data.
Dan Hotka is a Director of Database Field Operations for Quest Software.
He has over 21 years in the computer industry, including over 15 years experience
with Oracle products. He is an acknowledged Oracle expert where his Oracle experience
dates back to the Oracle V4.0 days. He has co-authored the popular books
Oracle Unleashed, Oracle8 Server Unleashed, Oracle Developer Unleashed, and Special Edition
Using Oracle8/8i from SAMS Publishing and frequently speaks at Oracle conferences and user
groups around the world.
BIBLIOGRAPHY: Chapter 24, Oracle8 Server Unleashed, SAMS Publishing
isbn:0-672-31207-7
July 1999 Oracle Professional, Pinnacle Publications. Reproduced with permission from
Pinnacle Publishing. All rights reserved.
SQL Level Tuning should be the final phase of tuning. All too often, the other parts discussed in
the previous parts of this series are overlooked. People sometimes view SQL tuning as the only
area that requires tuning. The 80/20 rule applies to SQL level tuning as well. Twenty percent of
the SQL statements will utilize over 80 percent of the resources. It is this 20 percent where we
need to concentrate our efforts.
There are a variety of explain-plan tools available from Oracle Corporation and various 3rd party
vendors. Oracle Enterprise Manager has a SQL-monitor tool available. Oracle has always
provided a variety of ways of capturing performance information in the form of TRACE files.
These trace files are interpreted by TKPROF, a tool not for the novice. This final tuning
installment will discuss various features of tuning at the SQL level, the Oracle optimizer choices,
existing and new indexing features, and the SQL statements themselves. Resource-intensive and
long running SQL queries will have the biggest impact on application performance. These SQL
statements need to be identified and tuned first.
There are many features previously discussed in this series aid in the performance of applications,
namely procedures, functions, and triggers; the use of unrecoverable transactions (understanding
the application needs); and pinning application code in the shared pool. This article will discuss
the need to use better SQL coding techniques.
Oracle has supported the compilation of functions, procedures, and triggers (procedural objects)
since Oracle7. The resulting intermediate code does not need to be parsed or prepared for

execution, saving considerable time at run-time. The compiler is automatically invoked when the
procedural object is created or altered. Changes to the table structures can invalidate procedural
objects, requiring them to be compiled again at run-time. The procedural objects can be
manually re-compiled when they become invalidated. Listings 1 and 2 show the SQL syntax for
manually invoking the compiler.
alter procedure <PROCEDURE NAME> compile
alter function <FUNCTION NAME> compile
alter trigger <TRIGGER NAME> compile
Procedure, Function, and Trigger Compile SQL
Listing 1
If the procedure or function is part of a package, the whole package can be compiled or just the
body.
alter package <PACKAGE NAME> compile package
alter package <PACKAGE NAME> compile body
Package Compile Options
Listing 2
SQL statements with nested subqueries can create an enormous amount of i/o traffic. Listing 3 is
a correlated subquery where the outer query is executed one time for each row returned by the
inner query. Listing 4 produces the same result but at a fraction of the i/o as it queries the look up
table (the subquery of Listing 3) once, not once per each row.
update EMP
set sal = sal * 10
where exists
(select ‘x’ from DEPT
where DEPT.deptno = EMP.deptno)
Correlated SQL statement
Listing 3
DECLARE
cursor c1 is select deptno from dept;
work_deptno number;
BEGIN
open c1;
loop
fetch c1 into work_deptno;

EXIT when c1%NOTFOUND
update emp
set sal = sal * 10
where deptno = work_deptno;
end loop;
END;
PL/SQL Loop Example
Listing 4
Using indexes greatly enhances the response time of most SQL statements. The rule of thumb
here is if more than 20% of the rows of a table are going to be returned from the database then
consideration on to use an index or not should be given. This is very dependent on the size of the
table object. It is important to understand the various available indexing options so that the
optimal indexing method is being utilized for a given SQL statement.
Oracle7 introduced several new indexing options that improve on the traditional B*tree indexes.
Oracle7 introduced bitmap indexes, star queries, histograms, and hash joins. Oracle8 introduced
index-organized tables and reverse key indexes. Each of these new indexing options is only
available to the cost-based optimizer.
The first new indexing option available in Oracle7 is bitmap indexes. This indexing option is
intended for columns with low cardinality of data such as color, sex, etc. A bitmap index stores
all the values of a particular column in a series of bits. Each bit is related to a rowid in the table
object. Oracle can quickly find rows in the index by simply searching for nonzero values. Figure
1 illustrates how the EMP table object might look in a bitmap index.
Rows
10
20
30
40
1 2 3 4 5 6 7 8 9 . .
1
0
0
0
0
0
1
0
0 1 0 1 0 0 0 1 1 0 0 0
1 0 0 0 1 0 0 0 0 0 1 0
0 0 1 0 0 1 0 0 0 0 0 1
0 0 0 0 0 0 1 0 0 1 0 0
EMP Bitmap Index
Figure 1

Listing 5 is a SQL query that will help identify table columns for possible bitmap index
consideration.
select owner "Owner", index_name "Index Name", distinct_keys "Distinct Keys"
from DBA_INDEXES
where distinct_keys < 15
Bitmap Index Candidates
Listing 5
A star query involves a single table object being joined with several smaller table objects, where
the driving table object has a concatenated index key and each of the smaller table objects is
referenced by part of that concatenated key. The Oracle cost-based optimizer recognizes this
arrangement and builds a memory-based cluster of the smaller tables.
A histogram might be useful when there is not an even distribution of data throughout a table
object. Prior to histograms, the Oracle optimizer assumed even distribution of values throughout
the object.
Figure 2 illustrates a histogram as a series of buckets. There are two kinds of histograms, width-balanced
and height-balanced. Width-balance is where the values are divided up into an even
number of buckets and the optimizer can easily determine as to which buckets have a higher
count. In height-balanced histograms, each bucket has the same number of column values, but a
column value may span more than one bucket. Figure 2 illustrates what the EMP table might
look like in either of the types of histograms.
Width-balanced Height-balanced
10 20 30 40 10 10 20 30
EMP Histogram
Figure 2

Histograms are implemented via the analyze command by specifying ‘column’ parameter.
Histograms defaults to 75 buckets with a maximum of 255 defined buckets. Histograms can be
created for indexes, tables, or clusters.
Hash joins can dramatically increate performance of two joined tables, where one table is
significantly larger than the other. This index option replaces the existing ‘sort-merge’ join
algorithm. The hash join works by splitting two tables into partitions and creating a memory
based hash table. This hash table is then used to map join columns from the other table,
eliminating the need for a sort-merge. In the hash join method, both tables are scanned only once.
In sort-merge, the smaller table can actually be read many times. Hash joins are implemented by
the init.ora parameters HASH_JOIN_ENABLED, HASH_MULTIBLOCK_IO_COUNT, and
HASH_AREA_SIZE.
The reverse-key index introduced in Oracle8 reverses the order of the bytes of a numeric key.
Reverse-key indexes are really useful in keeping the index balanced with sequence-number or
incrementing type keys. The syntax in Listing 6 shows how easy it is to make regular indexes
reversed and/or change the reverse key back to a regular key.
create index <INDEX NAME> on <TABLE NAME> (<COLUMN NAME(S)>) reverse
alter index <INDEX NAME> rebuild noreverse/reverse
Reverse Key Index Syntax
Listing 6
As far back as Oracle5, if Oracle could resolve a query from information in the index, it would
not retrieve any rows from the actual table. This trick was utilized widely for group by functions
or additions on an amount field. A DBA would simply add the common data to the end of the
concatenated index key. Index-organized tables gives this same end result as there is no
associated table object. Index-organized tables have an overflow option is where the nonindexed
part of the row will be stored if the row size is over the percentage given. This will create a
similar effect to that of row chaining. Index-organized tables may not be replicated or have
additional index columns. Partitioning will be available in Oracle8.1. Listing 7 illustrates the
syntax to create an index-organized table. The smaller tables of a star query are an excellent use
for this index option. To help prevent fragmentation of the index, it is best to avoid tables with
lots of update activity.
create table <TABLE NAME>
(field descriptions
.
.
<FIELD NAME>
primary key (<KEY FIELDS>))
organization index tablespace <TABLESPACE NAME>
pctthreshold 20
overflow tablespace <TABLESPACE NAME>

Index-organized Table Syntax
Listing 7
When a SQL statement is presented to the Oracle kernel, it is parsed for proper syntax and an
execution plan is developed. Think of this execution plan as a road map to the actual data. This
execution plan can be visualized with the explain-plan query discussed later in this article.
Oracle8 supports both the rule-based optimizer and the cost-based optimizer. The optimizers tell
Oracle the best execution path for a particular SQL statement.
The rule-based optimizer, the original optimizer, uses a series of nineteen rules to decide this
path, see Listing 8. The optimizer gives the more preference the lower the rank. The rule-based
optimizer is controlled by the order of the tables in the FROM clause, how the WHERE clause is
coded, and what indexes are available. In a join table situation, the driving table will be the last
table named in the FROM clause.
Rank Where clause predicates
1 ROWID = constant
2 unique indexed column = constant
3 entire unique concatenated index = constant
4 entire cluster key = cluster key of object in same cluster
5 entire cluster key = constant
6 entire nonunique concatenated index = constant
7 nonunique index = constant
8 entire noncompressed concatenated index >= constant
9 entire compressed concatenated index >= constant
10 partial but leading columns of noncompressed concatenated index
11 partial but leading columns of compressed concatenated index
12 unique indexed column using the SQL statement BETWEEN or LIKE options
13 nonunique indexed column using the SQL statement BETWEEN or LIKE options
14 unique indexed column < or > constant
15 nonunique indexed column < or > constant
16 sort/merge
17 MAX or MIN SQL statement functions on indexed column
18 ORDER BY entire index
19 full table scans
Rules for Rule-Based Optimizer

Listing 8
The cost-based optimizer, introduced first in Oracle6, makes its explain-plan decisions based on
statistics gathered by the ANALYZE command and stored in the data dictionary. Oracle will use
the cost based optimizer if there are statistics collected. The init.ora parameter,
OPTIMZER_MODE must be set to CHOOSE or COST to utilize the cost-based optimizer.
It is important to keep these statistics current when inserting and updating table objects.
Analyzing large table objects can take a considerable amount of CPU and sort resources. Oracle
does offer an ‘ESTIMATE’ clause, however, the percentage given with this estimate option only
applies from the beginning of the table object, not a random selection from the entire object.
Listing 9 illustrates the analyze syntax.
analyze table <TABLE NAME> estimate
Analyze Command
Listing 9
Hints are used to make recommendations to the cost-based optimizer. Please note that Oracle can
decide to ignore hints. Hints can be used to control the optimizer’s goal, access methods, join
conditions, parallel, and partitioning options. Hints are specified as part of the SQL statement
syntax. Listing 10 shows an ALL_ROWS hint in the EMP table object.
select /*+ ALL_ROWS */ ename, sal from EMP where SAL > 1000
Hint in EMP SQL statement
Listing 10
The optimizer goal hint controls one of three cost-based optimizer modes: RULE will force the
rule-based optimizer, FIRST_ROWS (best response) and ALL_ROWS (best throughput) will use
the cost-based optimizer and force the optimizer to the desired goal. Most of the access-method-controlling
hints are listed in Listing 11.
Hint Description
AND_EQUAL Use the AND_EQUAL hint when more than one equality criterion exists on a
single table.
CACHE Use the CACHE hint to place the entire table in the buffer cache. The table is
placed at the most recently used end of the buffer cache. This hint is good for
small tables that are accessed often.
CLUSTER Use the CLUSTER hint to access a table in a cluster without the use of an index.
FULL Use the FULL hint to perform a full table scan on a table.

HASH Use the HASH hint to access a table in a hashed cluster without the use of an
index.
INDEX Use an INDEX hint to instruct ORACLE to use one of the indexes specified as a
parameter.
INDEX_COMBINE The INDEX_COMBINE forces the use of bitmap indexes.
NOCACHE Use the NOCACHE hint to place the blocks of the table at the beginning of the
buffer cache so as not to age any blocks out.
NOPARALLEL Use the NOPARALLEL hint to not use multiple-server processes to
service the operations on the specified table.
ORDERED Use the ORDERED hint to access the tables in the FROM clause in the order
they appear.
PARALLEL Use the PARALLEL hint to request multiple server processes to simultaneously
service the operations on the specified table.
PUSH_SUBQ The PUSH_SUBQ evaluates subqueries earlier, rather than as a filter operation.
ROWID Use the ROWID hint to access the table by ROWID.
STAR STAR hint invokes the STAR query feature.
USE_CONCAT USE_CONCAT is used when a SQL statement has multiple criteria ORed
together.
USE_HASH Use the USE_HASH hint to perform a hash join rather than a merge join or a
nested loop join.
USE_MERE Use the USE_MERGE hint to perform a merge join rather than a nested loop join
or a hash join.
Access Method Hints
Listing 11
SQL statement tuning requires an understanding of explan plans. Listing 12 displays the contents
from a collection in the Oracle supplied plan_table. Oracle tools include Oracle Enterprise
Manager Top Session, TKPROF (examines TRACE files), and the EXPLAIN command
combined with a SQL statement to display the results. There are many third party tools such as
Quest Software’s SQLab that assists the DBA with SQL explain plan tuning, among other
features.
The explain plan is a necessity for tuning SQL statements for both the rule-based and cost-based
optimizers. Listing 12 shows how to load the plan table and query the results. This plan table
can be set up for any user by running the $ORACLE_HOME/rdbms/admin/utlxplan.sql script
from SQL*Plus.
EXPLAIN PLAN INTO PLAN _TABLE FOR
select * from emp;
select COST, OPERATION, OPTIONS, OBJECT_NAME
from PLAN_TABLE;
COST OPERATION OPTIONS OBJECT_NAME

------- ----------------------------- ------------- ------------0 SELECT
STATEMENT
3 TABLE ACCESS FULL EMP
joined over the join columns and then merging the results via the join columns. Explain Plan
Table and Results
Listing 12
Explain plans can be difficult to interpret. Listing 13 describes the more common explain plan
steps.
Access Rule Description
AND-EQUAL Index values will be used to join rows.
CONCATENATION SQL statement UNION command.
FILTER FILTERs apply ‘other criteria’ in the query to further qualify the matching rows.
The ‘other criteria’ include correlated subqueries, and HAVING clause.
FIRST ROW SQL statement will be processed via a cursor.
FOR UPDATE SQL statement clause ‘for update of’ placed row level locks on affected rows.
INDEX (UNIQUE) SQL statement utilized a unique index to search for a specific value.
INDEX (RANGE SCAN) SQL statement contains a nonequality or BETWEEN condition.
HASH JOIN SQL statement initiated a hash-join operation.
MERGE JOIN SQL statement references two or more tables, sorting the two result sets being
NESTED LOOPS This operation is one form of joining tables, as opposed to a merge join. One
row is retrieved from the row source identified by the first child operation, and
then joined to all matching rows in the other table, identified in the second child
operation.
NONUNIQUE INDEX (RANGE SCAN) The RANGE SCAN option indicates that ORACLE
expects to return multiple matches (ROWIDs) from the index search

PARTITION (CONCATTENATED) SQL statement will access a partitioned object and merge
the retrieved rows from the accessed partitions.
PARTITION (SINGLE) SQL statement will access a single partition.
PARTITION (EMPTY) The SQL statement makes reference to an empty partition.
SORT (ORDER BY) SQL statement contains an ORDER BY SQL command.
SORT (AGREGATE) SQL statement initiated a sort to resolve a MIN or MAX type function.
SORT (GROUP BY) SQL statement contains a GROUP BY SQL command.
TABLE ACCESS (FULL) All rows are retrieved from the table without using an index.
TABLE ACCESS (BY ROWID) A row was retrieved from a table based on the ROWID of the
row.
TABLE ACCESS (CLUSTER) A row is retrieved from a table that is part of an indexed cluster.
UNION SQL statement contains a DISTINCT SQL command.
Explain Plan Steps
Listing 13
Oracle8 has introduced three new columns: partition_start, partition_stop, and partition_id. These
three new fields will aid in the tuning of SQL statements that access partitioned objects. The
partition_start and partition_stop show the range of partitions that is affected by this explain step.
The partition_id is identification number for that particular explain step.
Finally, there are both good and poor ways to code SQL statements. Here are some guidelines for
SQL statement coding that will help both the rule-based and the cost-based optimizers.
DON’T use calculations in the where clause on indexed columns. Unless the intended behavior is
to disable the index use, any function on indexed columns will ignore the index.
DO use the IN operator instead of NOT. Try to avoid using the NOT command by using >=, <=,
etc.
DON’T use an index if more than 20 percent of the rows will be returned by the query.
DO use array processing whenever possible (Export, and Pro*C applications).
DON’T use subqueries if other solutions exist (PL/SQL loop for example).
DO use hints to insure the desired execution-plan results.
DON’T write applications that use SQL execution-plan defaults. Oracle Corp makes no
guarantees that default behavior will be maintained in future releases, or even between different
hardware platforms

Application sql issues_and_tuning

Related slideshows

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Application sql issues_and_tuning

Similar to Application sql issues_and_tuning (20)

More from Anil Pandey

More from Anil Pandey (20)

Recently uploaded

Recently uploaded (20)

Application sql issues_and_tuning