top 10 tips for oracle performance (updated nov 2014)

Top 10 Oracle database tuning tips and techniquesGuy Harrison, Executive Director, Information Management R&D

Dell Software Group2

Introductions

Web: guyharrison.net Email: [email protected] Twitter: @guyharrison

http://www.guyharrison.net/

mailto:[email protected]

http://twitter.com/guyharrison

http://twitter.com/guyharrison


Blue

Yellow

Red

0 10 20 30 40 50 60 70 80

Star trek shirt fatality analysis

Pct


The top 10 Be methodical and empiricalOptimize your database

designIndex WiselyWrite efficient codeOptimize the

optimizerTune SQL and PL/SQLMonitor and Manage

contentionOptimize memory to reduce IOTune IO last, but TUNE it

well

Be methodical and empirical


Hint 1: Methodical and Empirical tuning

Methodical:

• Have a plan • Focus on root causes, not symptoms• Hypothesis and experiment, not trial

and error

Empirical

• Measure performance • Compare before and after• What is your control group?• Beware of “old DBA tales” and “silver

bullets”


Hint 1: Methodical and Empirical tuning

YAPP

• Yet Another Performance Profiling Methodology

• Focus on area of greatest time consumption

• Use the Oracle Wait Interface

System-R• Similar, but focus on business transaction

context• Use Oracle SQL trace

Tuning by layers

• As above, but prioritize higher layers of the stack (which have flow on effects into lower layers)

• Distinguish between symptoms and causes


Basics of a database request

Application

SQL Result setsReturn codes

Database Server

Server Memory

RequestBlocks

Return blocks

RequestBlocks

Return blocks

IO subsystem

1. Application send an SQL request to the database server

2. Server compiles the SQL and prepares for execution

3. Server looks for data in memory first

4. If the data is not in memory, server reads from disk


The 4 layers in database performance

Application

SQL Result setsReturn codes

RDBMS code

Server Memory

RequestBlocks

Return blocks

RequestBlocks

Return blocks

IO subsystem

1. Tune SQL and application code to reduce the logical demand

2. Eliminate contention points and bottlenecks

3. Configure Memory to avoid as much IO as possible

4. Tune disk IO system to reduce waits for IO


What’s wrong with the donkey?


Measurement

• Standard SQL views

• AWR reports

• DB control/Cloud control

• Toad/Spotlight other 3rd party tools

• A single query can tell you a lot

http://165.225.144.123/OPSGSamples/Ch03/timeModelSimple.sql





Database design


Database design

Third Normal form (3NF)

• The key, the whole key and nothing but the key

• OR – Don’t repeat yourself (DRY)

3NF discretion• Datatypes (VARCHARs vs LOBS, etc)• Subtypes• NULLS

Denormalization

• Replicate column values to avoid joins• Summary tables and materialized views • Vertical partitioning


3NF is mostly Don’t Repeat Yourself (DRY)

• We don’t want to repeat the student name every time they take a new test

• We don’t want to repeat the test_name for every student that takes it

• We don’t want the “repeating group” of answers

– Also, we might not know how many questions there will be in future tests


3NF version

• Students take tests

• Tests have questions

• Students taking tests provide answers


Don’t go to far!• In this example the designer pulled address into a separate table and country into

another table.

• It’s correct in theory, but it means that every time we want an employees address we have to join three tables.

• It would have been better to have just one table


Logical to Physical: Subtypes

“Customers are people too”


Subtypes

• It’s usually better to put all the data in one table, or have two tables for each subtype

• Having a “supertype” table and two “subtype” tables means you always have to join tables

Probably don’t want to do this


Denormalization

Index Wisely


Indexes

• Choosing the best set of indexes is crucial• Create the best set of Concatenated (multi-column) indexes

that will support your queries.• Indexes slow down transactions, so don’t create too many

Indexes exist mainly to improve performance

• You use the index when you want to look up one thing or a few things

• You don’t use the index to read the whole book or read a whole chapter

• You do use an index when you want to go to a specific page

Think of indexes on a table like indexes in a book


Concatenated index effectiveness• The more columns in the

index the less IO it takes to resolve a query using all the columns

• The order of the columns affects how the index can be used

• If the index has all the columns, don’t need to touch the table at all

SELECT cust_idFROM sh.customers cWHERE cust_first_name = 'Connor'AND cust_last_name = 'Bishop'AND cust_year_of_birth = 1976;

None

last name

last+first name

last,first,BirthYear

last,first,birthyear,id

0 200 400 600 800 1000 1200 1400 1600

1459

63

6

4

3

Logical IO


Index overhead• Indexes speed up

queries, but make DML (insert, update, Delete) slower

• This chart shows how inserts slow down as more and more indexes are added

• Deleting a row with lot’s of indexes is particularly expensive

1 (PK only)

2

3

4

5

6

7

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

1,191

6,671

8,691

10,719

12,727

14,285

16,316

Logical reads required

Num

ber

of

indexes


0 10 20 30 40 50 60 70 80 90 100

1

10

100

1000

Full Scan no caching

Index sorted data, no caching

Index unsorted, cached data

Full Table scan, cached data

Pct of table accessed

Ela

sp

ed

Tim

e (

s)

Index or FTS?

Break even points

Application code


Database coding guidelines

SQL Execution

• Don’t call the database unless you have to – cache data instead.

• Reduce “hard” parsing by using bind variables

Transaction design

• Minimize lock duration using optimistic and Pessimistic locking strategies

Network overhead

• Array fetch and Insert• Stored procedures


Parse overhead• It’s easy enough in most programming languages to create a new SQL every time

you execute the query:


Better to use the same SQL with different arguments:• Prepare the statement once, then execute many times with

different arguments

• Using bind variables


Reduction in parse (SQL Compile) time

1,000 executions of the code on preceding two slides in Oracle

No Bind variables

Bind Variables

0 200 400 600 800 1000 1200 1400

Parse Time Other


Designing transactions• There are two ways to design transaction locking

• Pessimistic works best if you think someone else is going to “grab” your row before you’re finished

• Optimistic works best if you thing no one else will “grab” the row

Dura

tion of lock

Dura

tion of lock


Reduce Network traffic

• “Round trips” to the database can add a lot of overhead

• Two ways to reduce round trips:– Use the “Array” interface in your program code– Use stored procedures for complex interactions with the database


Array fetch performance

0 20 40 60 80 100 120 1400

5,000

10,000

15,000

20,000

25,000

30,000

35,000

40,000

Logical Reads Network round trips

Array fetch size


Network – stored procedures

• A stored procedure is code stored in the database

• If you have a transaction that goes “back and forth” to the database, consider a stored procedure

• ESPECIALLY if you are working across a slow network

Optimize the optimizer


Object Statistics

Cardinality Estimates

IO and CPUEstimates

DB parametersAnd config

Cost estimateSystem Statistics

Table and indexStructure

Optimizer inputs

• Remember: Garbage In : Garbage Out

• The optimizer can only do a good job if statistics are up to date


Histograms• Indexes are only good for getting

small amounts of the table

• So it might be a good idea to use an index to get “New Zealand” customers, but not “United States”

• A histogram allows the optimizer to understand how the data is distributed and make the best decision

• Create histograms to correct bad plans on skewed tables

Saudi

Arabia

Turke

y

Denm

ark

Singap

ore

Poland

Austra

lia

Canad

a

Franc

eIta

ly

United

Sta

tes

of A

mer

ica0

2,000

4,000

6,000

8,000

10,000

12,000

14,000

16,000

18,000

20,000

Nu

mb

er o

f ro

ws


Without a histogram

Number of rows the estimated

Real number of rows

Optimizer chooses not to use an index


With a histogram

Optimizer estimate is correct

Optimizer chooses to use an index


DBMS_STATS

GATHER_INDEX_STATS , GATHER_SCHEMA_STATS, GATHER_TABLE_STATS

Basic statistics method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO' Histogramsmethod_opt =>

'FOR ALL COLUMNS FOR COLUMNS (col1, col2)'

Multi-column extended statistics

method_opt => 'FOR ALL COLUMNS FOR COLUMNS (function(column)))'

Expression extended statistics

DBMS_STATS.gather_system_stats ( gathering_mode => 'NOWORKLOAD');

Non-workload system statistics

DBMS_STATS.gather_system_stats (gathering_mode => 'INTERVAL', interval => 60);

Workload system statistics

Tune SQL and PL/SQL


Find them and tune them

Find SQL

• Mine V$SQL• ASH, AWR tables• Database control, grid/cloud control • Toad, Spotlight

Tune SQL

• SQL Profiles• SQL Baselines• Rewrites• Hints (be careful)• SQL Optimizer


V$SQL is your friend• Also, V$SQL_PLAN,

V$SQL_PLAN_STATISTICS

• Tkprof, session trace


Now let’s look at the donkey

Monitor and manage contention


Contention – the proverbial bottleneck

Application

Demand for DB

services

Contention for limited or serialized resources causes

waits and or queuing

Apparent demand at lower layers is reduced


Types of contention

Locks

Usually locking problems are due to

application locks (remember optimistic

locking)?

Sometimes internal locks can cause

problems.

Latches and Mutex

Latches are very light weight locks that protect memory instead of tables

Buffer contention

When sessions have to wait for a memory “buffer” to become

available


Database files

Buffers

DatabaseWriter

User Buffer Waits

Write dirty blocks to disk

Write to buffers

Read from disk

Read from buffers

Free buffer waits

• Database buffers improve performance by caching data in memory

• When buffers are modified they are called “dirty” – DBWR writes to disk

• When all the blocks are “dirty” then sessions have to wait for the buffers to be written before new data can be read

• This might mean that your DBWR can’t write to disk fast enough

58 Software GroupConfidential

Latches and mutex contention

• Latches are like locks, but instead of protecting table rows, they protect memory (buffers)

• If two sessions try to access the same area of memory, then one will wait

• Instead of “sleeping” (like a lock) they waiting session will “spin” on the CPU for a very short time

• Latch problems may indicate “hot” blocks

• They might cause CPU drain (because of spinning)

Buffers

Database files

user user user


Specific contention scenarios

Lock/Latch Possible cause

Library cache mutex Hard parsing no bind variables. Try CURSOR_SHARING=SIMILAR

Library cache pin PL/SQL package parsing and invalidations

Shared pool latch Hard parsing and possibly excessive SGA resizing

Cache buffers chains Hot blocks, very high logical read rates

Free Buffer waits DBWR failing to “keep up” with block changes

Flashback buf free Insufficient IO bandwidth for flashback area

Buffer busy Hot blocks – partitioning might help

Optimize memory to reduce IO


Memory is primarily used to avoid IO

• Buffer cache avoids IO to table/index tablespaces

• PGA avoids IO to temporary tablespace

Buffer pools

Program Global Area (PGA)Sort area

Hash Area

Data (USER) tablespace

Temporary tablespace

Oracle Session


Temp tablespace IO can easily overwhelm table/index IO

Table/Index IO CPU Time Temp Segment IO

Available Memory

Tim

e

Less MemoryMore Memory

Memory Sort

Single PassDisk Sort

Multi-pass

Disk Sort


Automatic Memory Management • Introduced in 11g, AMM manages allocations between and

within PGA and SGA


AMM can (rarely?) lead to thrashing or starvation

• ALWAYS set minimum values for key components of the SGA

Tune IO last, but tune it well


IO Tuning

• Disk IO is the slowest part of the database system, so it’s critical to performance

• FIRST:– Tune SQL and application– Remove contention– Allocate memory

• Only when you’ve done that will your IO demand be realistic. Then you can tune your IO


Basics of IO tuning (magnetic disks)

• The amount of IO you can support depends on the number of disks you have

• Provide enough disks to support the amount of IO you need

• even if that means the disks are not filled with data

• Magnetics disks can do between 75-150 IO per second (IOPS) – do the math!

SATA 7,200 rpm

SATA 10,000 rpm

SAS 10,000 rpm

SAS 15,000 rpm

0 20 40 60 80 100 120 140 160 180 200

IO/ps


Disk Drive latency

• Latency is the time taken to perform a single IO

• Most disk drives can return an IO in 5-10 ms– Faster if the disk has a memory cache

• Disk latency increases with:– Throughput (best at 50-75% of maximum)– Disk fill (best at 50% capacity)

• To get best performance disks should be – Sparsely populated– Under only moderate load

• RAID 0+1 is the preferred configuration

0 50 100 150 200 250 300 350 400 4500

10

20

30

40

50

60

70

80

90

100

IO/second

Response T

ime (

ms)


The more that things change....


Disks are not getting faster

Oracle OpenWorld

Cheaper by the IO

Magnetic Disk

SSD SATA Flash

SSD PCI flash

SSD DDR-RAM

0 1,000 2,000 3,000 4,000 5,000

4,000

80

25

15

Seek time (us)

Oracle OpenWorld

But not by the GB

2011 2012 2013 2014 20150

2

4

6

8

10

12

10

7.4

5.3

3.2

2.3

2.9

2.21.7

1.31

0.35 0.28 0.21 0.17 0.13

HDD MLC SDD SLC SSD

$$/G

B

2011 2012 2013 2014 20150.1

1

10

2.3

2.9

2.2

1.7

1.3

1

0.35

0.28

0.21

0.17

0.13

HDD MLC SDD SLC SSD

$$/G

B

Oracle OpenWorld

Tiered storage management

Main Memory

DDR SSD

Flash SSD

Fast Disk (SAS, RAID 0+1)

Slow Disk (SATA, RAID 5)

Tape, Flat Files, Hadoop

$/IOP

$/G

B


Random reads – FusionIO

SAS disk, no flash cache

SAS disk, flash cache

Table on SSD

0 500 1000 1500 2000 2500

2,211

583

121

TotalOtherDB File IOFlash cache IO

Elapsed time (s)


Full table scans

Flash cache doesn’t accelerate Full table scans b/c scans use direct path reads and flash cache only accelerates buffered reads

SAS disk, no flash cache

SAS disk, flash cache

Table on SSD

0 50 100 150 200 250 300 350 400 450

418

398

72

TotalOtherDB File IOFlash Cache IO

Elasped time (s)


Disk Sorts – temp tablespace SSD vs HDD

0501001502002503000

500

1000

1500

2000

2500

3000

3500

4000

SAS based TTS SSD based TTSSort Area Size

Ela

psed t

ime (

s)

Single PassDisk Sort

Multi-passDisk Sort


Concurrent redo workload (x10)

SAS based redo log

Flash based redo log

0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000 4,500

1,605

1,637

397

331

1,944

1,681

CPUOtherLog File IO

Elapsed time (s)

Thank you.

top 10 tips for oracle performance (updated nov 2014)

Technology

name3431 dell software

answers24 dell software

this27 dell software

table25 dell software

dell software groupwhats

control group

repeating group ofanswers

concatenated index