Performance tuning

Performance Tuning
By
Ami Bhatt

What is performance Tuning?
Performance tuning is the improvement of
system performance. This is typically a
computer systems. The motivation for such
activity is called a performance problem, which
can be real or anticipated. Most systems will
respond to increased load with some degree of
decreasing performance.

Scope
●
SQL Tuning – Responsibility of the Developer
● Database Tuning – Responsibility of the
Database Administrator
●
●
System Tuning – Responsibility of the
System Administrator
●
● Network Tuning – Responsibility of the
Network / LAN / WAN Administrator.

SQL Tuning
1. Identifying high load or top SQL statements that
are responsible for a large share of the application
workload and system resources, by reviewing past
SQL execution history available in the system.
2. Verifying that the execution plans produced by the
query optimizer for these statements perform
reasonably.
3. Implementing corrective actions to generate
better execution plans for poorly performing SQL
statements.

Goals For Tuning
● Reduce the Workload
●
This can be achieved by modifying the query and by
generating better execution plan.
●
Balance the Workload
● Systems often tend to have peak usage in the daytime
when real users are connected to the system, and low
usage in the nighttime. If you can schedule noncritical
reports and batch jobs to run in the nighttime and reduce
their concurrency during day time, then the database frees
up resources for the more critical programs in the day.
● Parallelize the Workload
When Oracle runs SQL statements in parallel, multiple
processes work together simultaneously to run a single SQL
statement.

Identifying High-Load SQL
● Is the problem specific to a single program
(or small number of programs)?
● Is the problem generic over the application?

Problem is specific to a single
program
Query for displaying sessions, session state
and events
select sid, decode(state, 'WAITING','Waiting','Working')
state from v$session where username = 'ARUP';
SID STATE
——— ——————
2832 Working
3346 Waiting

Getting the SQL
select sql_id from v$session
where sid = 3089;
SQL_ID
—————————————————
g0uubmuvk4uax
select sql_fulltext
from v$sql
where sql_id = 'g0uubmuvk4uax';
SQL_FULLTEXT
—————————————————
update t1 set col2 = 'y' where col1 = 1

S
Problem is generic over the
application
SQL*Trace/Oracle Trace/Database Trace
Alter session set sql_trace = true
In PL*SQL
execute immediate 'Alter session set sql_trace = true';
●
It will generate TK*Prof

TK*ProfTK*Prof
TK*Prof is an Oracle tool used to display the statistics
generated during a trace. When an Oracle session is traced (by
SQL*Trace, Oracle Trace, or Database Trace), a trace file is
generated. This trace file is barely human-readable; TK*Prof
collates and formats the data into a more meaningful form.
Location of TK*Prof
SELECT value
FROM sys.v_$parameter
WHERE name = 'user_dump_dest'
Running TK*Prof
tkprof trace_file output_file
[ explain=userid/password@database ]
TK*Prof output
-High volume Sql, Low volume Sql,Execution Plan
Show the TK*Prof output to the DBA to see if the database can
be tuned

Quick Tips for Oracle SQL Query WritingQuick Tips for Oracle SQL Query Writing
Use of EXISTS versus IN for Subqueries
Example 1: Using IN - Selective Filters in the
Subquery
SELECT e.employee_id, e.first_name, e.last_name, e.salary
FROM employees e
WHERE EXISTS (SELECT 1
FROM orders o
WHERE e.employee_id = o.sales_rep_id
AND o.customer_id = 144);
Rewritting USING IN:
SELECT /* IN example */
e.employee_id, e.first_name, e.last_name, e.salary
FROM employees e
WHERE e.employee_id IN (SELECT o.sales_rep_id /* Note 4 */
FROM orders o
WHERE o.customer_id = 144); /* Note 3 */

Example 2: Using IN - Selective Predicate in the
Parent
SELECT /* IN example */
e.employee_id, e.first_name, e.last_name, e.department_id,
e.salary
FROM employees e
WHERE e.department_id = 80
AND e.job_id = 'SA_REP'
AND e.employee_id IN (SELECT o.sales_rep_id FROM orders o);
Rewritting USING EXISTS:
SELECT /* EXISTS example */
e.employee_id, e.first_name, e.last_name, e.salary
FROM employees e
WHERE e.department_id = 80
AND e.job_id = 'SA_REP'
AND EXISTS (SELECT 1
FROM orders o
WHERE e.employee_id = o.sales_rep_id);

Do use temp tables to improve cursor performance
●
Cursors not only suffer from speed problems, which in itself can
be an issue with many operations, but they can also cause your
operation to block other operations for a lot longer than is
necessary. This greatly decreases concurrency in your system.
● We may be able to get away from cursor-induced performance
issues by doing the cursor operations against a temp table
instead.For Example,
●
A cursor that goes through a table and updates a couple of
columns based on some comparison results. Instead of doing the
comparison against the live table, you may be able to put that
data into a temp table and do the comparison against that
instead. Then you have a single UPDATE statement against the live
table that’s much smaller and holds locks only for a short time.

Don’t nest views
When you have views that call views that call
views that call views. This is called nesting views
and it can cause severe performance issues,
particularly in two ways. First, you will very likely
have much more data coming back than you need.
Second, the query optimizer will give up and return a
bad query plan.

Don’t do large ops on many tables in the
same batch
●
A delete routine that ran several times a day was deleting
data out of 14 tables in an explicit transaction. Handling
all 14 tables in one transaction meant that the locks were
held on every single table until all of the deletes were
finished. The solution was to break up each table's deletes
into separate transactions so that each delete transaction
held locks on only one table. This freed up the other
tables and reduced the blocking and allowed other
operations to continue working. You always want to split
up large transactions like this into separate smaller ones
to prevent blocking.

Don't use triggers
● Whatever it is you want them to do will be done in
the same transaction as the original operation. If
you write a trigger to insert data into another table
when you update a row in the Orders table, the lock
will be held on both tables until the trigger is done.
If you need to insert data into another table after
the update, then put the update and the insert into
a stored procedure and do them in separate
transactions.

Don’t count all rows if you only need to see
if data exists
To check for the existence of that data:
(SELECT COUNT(*) into v_cnt FROM table_name;
If v_cnt > 0
BEGIN
<Do something>
END
/
It’s completely unnecessary.
If EXISTS (SELECT 1 FROM table_name)
BEGIN
<Do something>
END

Try to use UNION ALL in place of UNION
The UNION ALL statement is faster than UNION, because
UNION ALL statement does not consider duplicate s, and
UNION statement does look for duplicates in a table while
selection of rows, whether or not they exist.
Original query:
SELECT cust_id FROM SH.sales
UNION
SELECT cust_id FROM customers;
Improved query:
SELECT cust_id FROM SH.sales
UNION ALL
SELECT cust_id FROM customers;

Use Column Names Instead of * in a SELECT
Statement
If you are selecting only a few columns from a table there is
no need to use SELECT *. Though this is easier to write, it
will cost more time for the database to complete the query.
By selecting only the columns you need, you are reducing
the size of the result table, reducing the network traffic and
also in turn boosting the overall performance of the query.
Original query:
SELECT * FROM SH.Sales;
Improved query:
SELECT s.prod_id FROM SH.sales s;

Avoid including a HAVING clause in SELECT
statements
The HAVING clause is used to filter the rows after all the
rows are selected and it is used like a filter. It is quite
useless in a SELECT statement. It works by going through
the final result table of the query parsing out the rows that
don’t meet the HAVING condition.
Original query:
SELECT s.cust_id,count(s.cust_id) FROM SH.sales s
GROUP BY s.cust_id
HAVING s.cust_id != '1660' AND s.cust_id != '2';
Improved query:
SELECT s.cust_id,count(cust_id) FROM SH.sales s
WHERE s.cust_id != '1660'
AND s.cust_id !='2'
GROUP BY s.cust_id;

Use EXISTS instead of DISTINCT when using
table joins that involves tables having one-to-
many relationships
The DISTINCT keyword works by selecting all the columns
in the table then parses out any duplicates.Instead, if you
use sub query with the EXISTS keyword, you can avoid
having to return an entire table.
Original query:
SELECT DISTINCT c.country_id, c.country_name
FROM SH.countries c,SH.customers e
WHERE e.country_id = c.country_id;
Improved query:
SELECT c.country_id, c.country_name
FROM SH.countries c
WHERE EXISTS (SELECT 'X' FROM SH.customers e
WHERE e.country_id = c.country_id);

Remove any redundant mathematics
There will be times where you will be performing
mathematics within an SQL statement. They can be a drag
on the performance if written improperly. For each time the
query finds a row it will recalculate the math. So eliminating
any unnecessary math in the statement will make it perform
faster.
Original query:
SELECT *
FROM SH.sales s
WHERE s.cust_id + 10000 < 35000;
Improved query:
SELECT *
FROM SH.sales s
WHERE s.cust_id < 25000;

References:
https://docs.oracle.com/
http://www.dataintegration.ninja
http://www.orafaq.com
http://nikunjthaker.blogspot.in/
http://www.infoworld.com
http://stackoverflow.com/questions/64193
12/

Performance tuning

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Performance tuning (20)

Recently uploaded (20)

Performance tuning