The document provides an overview of performance tuning for Oracle databases. It discusses tuning goals such as accessing the least number of blocks and caching blocks in memory. It outlines the tuning process which includes tuning the design, application, memory, I/O, contention and operating system. Common performance issues for OLTP systems like I/O bottlenecks are also covered. Various tools for identifying performance problems are listed.

1. © Copyright 2015. Apps Associates LLC. 1
Performance Tuning Overview
May 30, 2015

2. © Copyright 2015. Apps Associates LLC. 2
Satyendra Kumar Pasalapudi
Associate Practice Director – IMS, Cloud & Big data Practice
@ Apps Associates
Co Founder & President of AIOUG
@pasalapudi

3. © Copyright 2015. Apps Associates LLC. 3
Performance Tuning Overview

4. © Copyright 2015. Apps Associates LLC. 4
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 ?

5. © Copyright 2015. Apps Associates LLC. 5
Tuning Questions
• Who Tunes?
- Application designers
- Application Developers
- DBAs
• Why Tune?
• How much tuning?

6. © Copyright 2015. Apps Associates LLC. 6
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

7. © Copyright 2015. Apps Associates LLC. 7
• Response Time
• Database availability
•Database hit percentages
•Memory / CPU / Disk utilization

8. © Copyright 2015. Apps Associates LLC. 8
• Tune the design
• Tune the application
• Tune memory
• Tune IO
• Tune contention
• Tune Operating system
Tuning Steps

9. © Copyright 2015. Apps Associates LLC. 99
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

10. © Copyright 2015. Apps Associates LLC. 1010
Define the problem
• Get a clear understanding of the performance issue
What
Where
When
Why
How

11. © Copyright 2015. Apps Associates LLC. 1111
Define the problem

12. © Copyright 2015. Apps Associates LLC. 12
Performance Tuning Approach

13. © Copyright 2015. Apps Associates LLC. 14
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

14. © Copyright 2015. Apps Associates LLC. 15
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

15. © Copyright 2015. Apps Associates LLC. 16
How does the database process OLTP?
• CPU time is mainly consumed by I/O wait
Cache miss Cache Hit

16. © Copyright 2015. Apps Associates LLC. 17
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

17. © Copyright 2015. Apps Associates LLC. 18
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
ResponseTime(Normal-
100Thread=>1.00)
TPS(Normal-100Thread=>100)
Thread
TPS RES
Typical Problem of busy systems
I/O bottleneck
Low Throughput and Slow Response
Low CPU usage

18. © Copyright 2015. Apps Associates LLC. 19
It’s all about I/O- Logical I/O

19. © Copyright 2015. Apps Associates LLC. 20
It’s all about I/O- Physical I/O

20. © Copyright 2015. Apps Associates LLC. 21
Typical Storage Bottlenecks

21. © Copyright 2015. Apps Associates LLC. 22
Database I/O Bottlenecks: Wait Events

22. © Copyright 2015. Apps Associates LLC. 23
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

23. © Copyright 2015. Apps Associates LLC. 25
Tools to Identify Database Performance Issues

24. © Copyright 2015. Apps Associates LLC. 26
Performance Methodology

25. © Copyright 2015. Apps Associates LLC. 27
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

26. Memory Hierarchy
2
CPU
Registers
L1/L2/L3 CACHE
RAM
SSD
Disk

27. Huge Pages

28. 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.

29. 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.

30. Huge Pages

31. Huge Pages

32. Huge Pages

34. Huge Pages
3
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 MB2 MB
72 GB RAM
24 GB
RAM
48 GB
HugePages
Default HugePages pool

35. 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.

36. Smart Flash Cache

37. How Smart Cache Works

38. What happens when a SQL statement is issued?
User
Library Cache
Shared SQL Area
Shared Pool
CnC1 C2 …
3
Optimizer
Oracle Database
Code Generator
1
Syntax Check
Semantic Check
Shared Pool check
2
Parsing
4
SQL Execution

39. © Copyright 2015. Apps Associates LLC. 41
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

40. © Copyright 2015. Apps Associates LLC. 42
Dynamic Plan – Adaptive Execution Plan

41. © Copyright 2015. Apps Associates LLC. 43

42. Thank You!@pasalapudi