Oracle Database Performance

Tuning
Presented By -
Rahul Gaikwad
What is Database Tuning?
yDatabase tuning is a group of activities used to
optimize the performance of a database.
y Goal Of Database Tuning?
 To maximize use of system resources
 To perform task as efficiently
 To work rapidly as possible

www.yogijicreations.com
Why and when should one tune?
y Slow Physical I/O
-caused by poorly-configured disks
-caused by unnecessary physical I/O
-caused by poorly-tuned SQL.
y Excessive CPU usage
-It means that there is little idle CPU on the system
-caused by an inadequately-sized system,
-caused by untuned SQLstatements
-caused inefficient application programs.
y Latch Contention
Rarely is latch contention tunable by reconfiguring
the instance. Rather, latch contention usually is
resolved through application changes.

www.yogijicreations.com
 Causes for low Performance
yBad Connection Management
y Bad Use of Cursors and the Shared Pool
y Bad SQL
y Use of Nonstandard Initialization Parameters
y Getting Database I/O Wrong
y Redo Log Setup Problems
y Long Full Table Scans
y High Amounts of Recursive (SYS) SQL

www.yogijicreations.com
 Where should we do the tuning?
yDatabase Design
 Poor system performance usually results from a poor databa se design.
 One should generally normalize to the 3NF.
 Selective denormalization can provide valuable performance
improvements..
y Application Tuning:
 Approximately 80% of all Oracle system performance problems are
resolved by coding optimal SQL.
yMemory Tuning:
 By Properly size your database buffers (shared pool, buffer cache, log
buffer, etc)
 By looking at your wait events, buffer hit ratios, system swapping and
paging, etc.
y Disk I/O Tuning:
 Database files needs to be properly sized.
 Also look for frequent disk sorts, full table scans, data fragmentation, etc.
y Eliminate Database Contention:
 Study database locks, latches and wait events carefully and eliminate
where possible.
y Tune the Operating System:
w w w .y o gi jic re atio n s. co m
 M o n it o r a n d t u n e o peratingsystem CPU, I/O and memory utilization.
 Optimizing the optimizer
Optimizer inputs

Table and index Cardinality

Structure Estimates

DB parameters IO and CPU

Object Statistics
And config Estimates

System Statistics Cost estimate

www.yogijicreations.com
 Database Statistics

 Database statistics provide information on

the type of load on the database, as well as
the internal and external resources used
by the database.
Performance Data Statistics
Time Model

SQL
Wait
Metrics

Stats
Sessions
 Wait Events
 Wait events are statistics that indicate that it
have to wait for an event to complete before
being able to continue the processing.
 common examples of the waits-
 Application: locks waits caused by row level locking
 Commit: waits for redo log write confirmation after a
commit
 Idle: signify the session is inactive
 Network: waits for data to be sent over the network
 User I/O: wait for blocks to be read off a disk
 Time Model Statistics

 The V$SESS_TIME_MODEL and V$SYS_TIME_MODEL

views provide time model statistics
 The most important of the time model statistics is DB time.
 This statistics represents the total time spent in
database calls and is a indicator of the total instance
workload.
 It is calculated by aggregating the CPU and wait times
of all sessions
 DB time is measured cumulatively from the time that the
instance was started.
 For example, a instance that has been running for 30
minutes could have four active user sessions whose
cumulative DB time is approximately 120 minutes.
 Active Session History (ASH)

 The V$ACTIVE_SESSION_HISTORY view provides

sampled session activity in the instance.

 Active sessions are sampled every second and are

stored in a circular buffer in SGA.

 Active Session includes any session that was on the

CPU at the time of sampling.
 System and Session Statistics
 A large number of cumulative database statistics are
available on a system and session level through the
V$SYSSTAT and V$SESSTAT views.
 Operating System Statistics
 Operating system statistics provide information on the usage
and performance of the main hardware components of the
system, as well as the performance of the operating system
itself.
 It is always best to consider operating system statistics as a
diagnostic tool, similar to the way many doctors use body
temperature, pulse rate, and patient pain when making a
diagnosis..
 Operating system statistics include the following:
3 CPU Statistics
3 Virtual Memory Statistics
3 Disk Statistics
3 Network Statistics
 Automatic Workload Repository
 The Automatic Workload Repository (AWR) collects, processes, and
maintains performance statistics for problem detection and self-tuning
purposes.

 This data is stored both in memory and in the database.

 AWR include:
– Time model statistics i.e. V$SYS_TIME_MODEL and
V$SESS_TIME_MODEL views
– Some of the system and session statistics collected in the V$SYSSTAT and
V$SESSTAT views
– Active Session History (ASH) statistics, representing the history of recent
sessions activity

 AWR automatically generates snapshots of the performance data

once every hour
and collects the statistics in the workload repository.
 Metric
 A metric is defined as the rate of change in
some cumulative statistic.

 That rate can be measured against time,

transactions, or database calls.

 For example, the number database calls per second is

a metric.

 A history of recent metric values is available through

V$ views.
 Tools or Utilities for PT

yV$SQL_PLAN
◦ Find SQLs with high resource costs

y EXPLAIN PLAN & DBMS_STAT

◦ Determine the execution plan

y SQLTrace/Tkprof
◦ Best drilldown at the session leve
l
 V$SQL_PLAN
yUsed todisplay the execution plan of a SQL
statement:

y Afterthe statement has executed, you can

display the plan by querying the
V$SQL_PLAN view.

y The V$SQL_PLAN_STATISTICS view

provides the actual execution statistics for
every operation in the plan, such as the
number of output rows and elapsed time.

www.yogijicreations.com
 EXPLAIN PLAN
y The EXPLAIN PLAN statement displays execution plans for
SELECT, UPDATE, INSERT, and DELETE statements.

y A statement's execution plan is the sequence of operations Oracle

performs to run the statement.

y The row source tree is the core of the execution plan. It shows :
 ordering of the tables
 access method for each table
 join method for tables
 Data operations like filter, sort, or aggregation

y The plan table Also contains information :

 Optimization, such as the cost and cardinality of each operation
 Partitioning, such as the set of accessed partitions
 Parallel execution, such as the distribution method of join inputs

www.yogijicreations.com
 PLAN_TABLE Output Table
yThe PLAN_TABLE is automatically created to
hold the output of an EXPLAIN PLAN statement
for all users.

y PLAN_TABLE is the default sample output table

into which the EXPLAIN PLAN statement
inserts rows describing execution plans.

y While a PLAN_TABLE table is automatically set

up for each user, you can use the SQL script
utlxplan.sql to manually create a local
PLAN_TABLE in your schema.

www.yogijicreations.com
 uses EXPLAIN PLAN
y To examinea SQL statement that
Select employee_id, job_title, salary, and
department_name for the employees
whose IDs are less than 103.
y Example Using EXPLAIN PLAN
SELECTe.employee_id, j.job_title,e.salary,
d.department_name
FROM employees e,jobs j, d e
p
a
rtm
e
n
tsd WHERE
e.employee_id <
AND e.job_id= j.job_id
AND e.department_id = d.department_id;
www.yogijicreations.com
 EXPLAIN PLAN Output
-----------------------------------------------------------------------------------
| Id | Operation | Name |Rows |Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |3 | 189 | 10 (10)|
| 1 | NESTED LOOPS | |3 | 189 | 10
(10)|
| 2 | NESTED LOOPS | |3 | 141 | 7 (15)|
|* 3 | TABLE ACCESS FULL | EMPLOYEES | 3 | 60 | 4 (25)|
| 4 | TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50)|
|* 5 | INDEX UNIQUE SCAN | JOB_ID_PK | 1 | | |
| 6 | TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50)|
|* 7 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | | |
-----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("E"."EMPLOYEE_ID"<103)
5 - access("E"."JOB_ID"="J"."JOB_ID")
7 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

www.yogijicreations.com
 Steps of Execution Plan
y Step 3 reads all rows of the employees table.
y Step 5 looks up each job_id in JOB_ID_PK index and finds the
rowids of the associated rows in the jobs table.
y Step 4 retrieves the rows with rowids that were returned by Step
5 from the jobs table.
y Step 7 looks up each department_id in DEPT_ID_PK index and
finds the rowids of the associated rows in the departments table.
y Step 6 retrieves the rows with rowids that were returned by Step
7 from the departments table.
y The following steps in Example operate on rows returned by the
previous row source:
y Step 2 performs the nested loop operation on job_id in the jobs
and employees tables, accepting row sources from Steps 3 and
4, joining each row from Step 3 source to its corresponding row
in Step 4, and returning the resulting rows to Step 2.
y Step 1 performs the nested loop operation, accepting row
sources from Step2 and Step6, joining each row from Step 2
source to its corresponding row in Step 6, and returning the
resulting rows to Step 1.
www.yogijicreations.com
www.yogijicreations.com
 Full Table Scans
yThis type of scan reads all rows from a table
and filters out those that do not meet the
selection criteria.
y During a full table scan, all blocks in the table
that are under the high water mark are
scanned.
y The high water mark indicates the amount of
used space, or space that had been formatted
to receive data.
y Each row is examined to determine whether it
satisfies the statement's WHERE clause.

www.yogijicreations.com
 Rowid Scans
yThe rowid of a row specifies the data files and
data block containing the row and the location of
the row in that block.
y Locating a row by specifying its rowid is the
fastest way to retrieve a single row, because the
exact location of the row in the database is
specified.
y To access a table by rowid, Oracle first obtains
the rowids of the selected rows, either from the
statement's WHERE clause or through an index
scan of one or more of the table's indexes.
y Oracle then locates each selected row in the table
based on its rowid.
www.yogijicreations.com
 Index Scans
y In this method, a row is retrieved by traversing the index, using the indexed column
values specified by the statement.
y An index scan retrieves data from an index based on the value of one or more columns
in the index.
y To perform an index scan, Oracle searches the index for the indexed column values
accessed by the statement.
y If the statement accesses only columns of the index, then Oracle reads the indexed
column values directly from the index, rather than from the table.
y The index contains not only the indexed value, but also the rowids of rows in the table
having that value.
y Therefore, if the statement accesses other columns in addition to the indexed columns,
then Oracle can find the rows in the table by using either a table access by rowid or a
cluster scan.
y An index scan types:
 Assessing I/O for Blocks, not Rows
 Index Unique Scans
 Index Range Scans
 Index Range Scans Descending
 Index Skip Scans
 Full Scans
 Fast Full Index Scans
 Index Joins
 Bitmap Indexes

www.yogijicreations.com
 SINGLE TABLE LOOKUP

 Index or table scan?

 Avoid accidental table scans

 Optimize indexes
y best combination of concatenated indexes
 Optimize necessary table scans
y Vertical/Horizontal partitioning
 1000

Full Scan no caching

Index sorted data, no caching

Index unsorted, cached data

Full Table scan, cached data

100
Elasped Time (s)

10

Break even points for index vs table scan

1
0 10 20 30 40 50 60 70 80 90 100

Pct of table accessed

 Concatenated Index Effectiveness

last,first,birthyear,id 3
SELECT cust_id FROM
sh.customers c
WHEREcust_first_name = ’Connor’
AND cust_last_name = ’Bishop’
last,first,BirthYear 4
AND cust_year_of_birth = 1976;

last+first name 6

last name 63

None 1459

0 200 400 600 800 1000 1200 1400 1600

Logical IO
BITMAP INDEXES
 BITMAP INDEXES

10
Elapsed Time (s)

0.1

0.01
1 10 100 1000 10000 100000 1000000
Distinct values in table

Bitmap index B*-Tree index Full table scan

VERTICAL PARTITIONING
 Joins
OPTIMIZING JOINS
 Best join order
y Eliminate rows as early as possible
 Join Type:
y Nested loops
 Optimize the join index

y Sort merge
 Avoid, esp. if memory scarce

y Hash join
 Avoid multi-pass executions
 NESTED LOOPS JOIN

prod_id,channel_id,cust_id,time_id,promo_id 2.2

time_id 3.14
Indexing

prod_id,channel_id 23.43

prod_id 48.36

546.55

No Index

0 100 200 300 400 500 600

Elapsed time (s)

 SORT-MERGE AND HASH JOIN
250

200
Elapsed Time (s)

150

Disk Sort

100

In Memory
50 Multi pass disk sort Single pass disk sort

0 In Memory
1 10 100 1000
Workarea Memory (MB)

Hash Join Sort Merge Join

BITMAP JOIN INDEX
 BITMAP JOIN PERFORMANCE

Full table scan

13,480
Access Path

Bitmap index 1,524

Bitmap Join index 68

0 2000 4000 6000 8000 10000 12000 14000

Logical IO

SELECT SUM ( amount_sold )

FROM customers JOIN sales s USING ( cust_id )WHERE
cust_email ='flint.jeffreyscompany2.com';
 SORTING – WHAT WE EXPECT

Multi-pass
Disk Sort

Single Pass
Disk Sort

Memory Sort

PGA Memory available (MB)

Table/Index IO CPU Time Temp Segment IO

 DML

DML TUNING - INDEXES

7 16,316

6 14,285

5 12,727
Number of indexes

4 10,719

3 8,691

2 6,671

1 (PK only) 1,191

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000

Logical reads required
 MULTI-TABLE INSERT

Multi-table insert

Insert US
Insert EMEA
Insert both

Two Inserts

0 1 2 3 4 5 6
Elapsed time (s)
 MERGE 3.32

Update
Insert
Merge

INSERT + UPDATE 3.89 3.71

0 1 2 3 4 5 6 7 8
Elapsed Time (s)
Top 10 Oracle SQL tuning
tips
1. Design and develop with performance in mind
2. Establish a tuning environment
3. Index wisely
4. Reduce parsing
5. Take advantage of Cost Based Optimizer
6. Avoid accidental table scans
7. Optimize necessary table scans
8. Optimize joins
9. Use array processing
10. Consider PL/SQL for “tricky” SQL

www.yogijicreations.com
www.yogijicreations.com For queries: info@yogijicreations.com