Performance Tuning intro

© Copyright 2015. Apps Associates LLC. 1

Performance Tuning Overview

June 18, 2016


Satyendra Kumar Pasalapudi

Associate Practice Director – IMS, Cloud & Big data Practice @ Apps Associates

Co Founder & President of AIOUG

@pasalapudi

http://www.aioug.org/index.php


Performance Tuning Overview


What is the cost of Oracle License for the below configuration ?

4 CPU( 8 Cores) Intel Processor – Running Database Oracle Enterprise

Edition 11gR2 with Partitioning and Tuning & Diagnostic Pack on Oracle Linux

– Sun Netra X3-2 Servers

Per CPU Cost

Software Updates & Support Total No of CPUs Total $

Oracle Enterprise Edition 47500 10450 57950 4 231800

Partitioning 11500 2530 14030 4 56120

Diagnostic Pack 5000 1100 6100 4 24400

Tuning Pack 12000 2640 14640 4 58560

Total 370880 22252800 INR

RAC 23000 5060 28060 8 224480

4 370880

Total 966240 57974400 INR

Do you know the value of PT ?


Tuning Questions

• Who Tunes?

- Application designers

- Application Developers

- DBAs

• Why Tune?

• How much tuning?


Tuning Goals

• Access the least number of blocks

• Cache blocks in memory

• Share application code

• Read and write data as fast as possible

• Ensure users do not wait for resources

• Perform backups and housekeeping while minimizing impact


• Response Time

• Database availability

•Database hit percentages

•Memory / CPU / Disk utilization


• Tune the design

• Tune the application

• Tune memory

• Tune IO

• Tune contention

• Tune Operating system

Tuning Steps

© Copyright 2015. Apps Associates LLC. 9 9

How to Approach a Performance Issue

DEFINE the problem clearly

GATHER the right data to analyze the issue

Identify the ROOT CAUSE of the problem, possibly gather additional data

Search for a KNOWN SOLUTION or workaround that addresses the root cause of the problem

If it is a product issue, PASS ON the right information to support/dev through the regular channels

Try to identify a TEMPORARY WORKAROUND to alleviate the issue while you get a product fix


Define the problem • Get a clear understanding of the performance issue

What

Where

When

Why

How


Define the problem


Performance Tuning Approach


Oracle tuning methodology

• Tune business rules • Tune data design • Tune application design • Tune logical structure • Tune database operations • Tune access paths • Tune memory allocation • Tune I/O and physical structure • Tune resource contention • Tune platform


How does the database process OLTP Caching

• Cache data in memory from disk to achieve fast query response

• For OLTP/ DSS workloads, memory should be big enough to hold as much as possible

SGA

Buffer Cache

100% cache hit ratio is ideal for

OLTP workloads


How does the database process OLTP?

• CPU time is mainly consumed by I/O wait

Cache miss Cache Hit


OLTP performance issues

2. User Volume is

increasing...

1. Data Size is

increasing...

SGA

1. Huge amounts of data

2. Not possible to cache

all data

3. Many I/O operations

Buffer

Cache


0.00

2.00

4.00

6.00

8.00

10.00

12.00

14.00

16.00

0

100

200

300

400

500

600

700

800

100 200 300 400 500 600 700 800

Response T

ime(N

orm

al-

100T

hre

ad=

>1.0

0)

TP

S(N

orm

al-

100T

hre

ad=

>100)

Thread

TPS RES

Typical Problem of busy systems

I/O bottleneck

Low Throughput and Slow Response

Low CPU usage


It’s all about I/O- Logical I/O


It’s all about I/O- Physical I/O


Typical Storage Bottlenecks


Database I/O Bottlenecks: Wait Events


Commits work

commit;

Newest System Change Number (SCN)

obtained from control files

Data in the database buffer cache marked as

‘updated and ready for saving’

‘commit’ placed into redo buffer

LGWR writes redo buffer contents to redo log

files & removes from redo buffer

Control file updated with latest SCN

Commit complete message returned to user

Later ... DBWR updates emp table in the data

file and updates the header of the data file

with the latest SCN


Database System View


Tools to Identify Database Performance Issues


Performance Methodology


Increasing Memory Hierarchy

Intel Unleashes Haswell-EX Xeon E7 V3 Processors – Up to 18 Cores, 45 MB L3 Cache, 12 TB

DDR4 Memory Support and 5.7 Billion Transistors to deliver big data insights

Memory Hierarchy

2

8

CPU

Registers

L1/L2/L3 CACHE

RAM

SSD

Disk

Huge Pages

Memory Architecture

From a memory management perspective, the entire physical memory is divided into "frames"

and the virtual memory is divided into "pages". The memory management unit performs a

translation of virtual memory address to physical memory address. The information regarding

which virtual memory page maps to which physical frame is kept in a data structure called the

"Page Table".

Page table lookups are costly. In order to avoid performance hits due to this lookup, a fast

lookup cache called Translation Lookaside Buffer(TLB) is maintained by most architectures.

So any virtual memory address which requires translation to the physical memory address is

first compared with the translation lookaside buffer for a valid mapping. When a valid address

translation is not present in the TLB, it is called a "TLB miss". If a TLB miss occurs, the memory

management unit will have to refer to the page tables to get the translation. This brings

additional performance costs, hence it is important that we try to reduce the TLB misses.

What is HugePages Linux Kernel allocates physical memory in unit called pages, the default size of the page is 4KB. Kernel manages allocation of Pages in PageTable, HugePages allows larger page size, the default HugePage size is 2048KB. The larger page size results in performance benefits as system deals with less number of pages, as the PageTable is smaller.

Huge Pages

Huge Pages

Huge Pages

Huge Pages

3

6

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K

4K 4K 4K 4K 4K 4K 4K 4K

4K 4K

4K 4K

2 MB

2 MB

2 MB 2 MB 2 MB

72 GB RAM 24 GB

RAM

48 GB

HugePages

Default

HugePages pool

Huge Pages

Advantages of HugePages HugePages are not swappable, in other words they are always pinned, so no swapping overhead. HugePages can be allocated on-the-fly but must be reserved first by setting the kernel parameters HugePages are reserved at system startup AMM (Automatic Memory Management) and HugePages

are not compatible, AMM should be disabled so that

Database can utilize HugePages. 11gR2 logs HugePages information in alert.log.

Smart Flash Cache

How Smart Cache Works

What happens when a SQL statement is issued?

User

Library Cache

Shared SQL Area

Shared Pool

Cn C1 C2 …

3 Optimizer

Oracle Database

Code Generator

1

Syntax Check

Semantic Check

Shared Pool check

2

Parsing

4

SQL Execution


Adaptive Execution Plans

• A query plan changes during execution because runtime conditions indicate that optimizer estimates are inaccurate

• All adaptive execution plans rely on statistics that are collected during query execution.

• The database uses adaptive execution plans when OPTIMIZER_FEATURE_ENALBE is set to 12.1.01 or later and OPTIMIZER_ADAPTIVE_REPORTING_ONLY parameter set to false.

• The two adaptive plan techniques are

– Dynamic Plans

– Re optimization


Dynamic Plan – Adaptive Execution Plan


Thank You! @pasalapudi

Technology

Performance Tuning intro