Performance Tuning - Expert Panel

Workshop
Oracle Database
Performance
Management Best
Practices
Copyright 2014 Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracles products remains at the sole discretion of Oracle.
Agenda
Introduction
Oracle Database Performance Tuning Fundamentals
Find, Fix and Validate: Methodology and Toolset

Find Fix and Validate: An Example
Real-World Best Practices & Tips
New Features and Enhancements (DB 12.1.0.2)
Top Challenges
Database Management
78%
Downtime resulting from

untested changes
48%
Use SQL tuning to address

performance issues
46%
Data stores growing by

20%+
39%
Handle more than 50 DBs

each
Key Takeaway:
Improve & Ensure Higher Quality of Service
20142013
Oracle and/or
its affiliates.
All rights
reserved. |
Source: From Database Clouds to Copyright
Big Data:
IOUG
Survey
On Database
Manageability
Continuous Innovation
Agenda
Introduction

Database Time (DB Time)

Total time in database calls by foreground sessions
Includes CPU time, IO time and non-idle wait time
DB Time <> response time
New metric for Oracle performance analysis
Database time is total time spent by user processes either actively working or actively
waiting in a database call.
Fundamental Concepts
Active Session =
Session currently spending time in a database call
Database Time (DB Time) =
Total time session spent in all database calls
Average Activity of the Session (% Activity) =

The ratio of time active to total wall-clock time
Browse
Books
Read Reviews
For One Book
Add to Cart
Checkout
TIME
= time spent in database

DB Time Theory to Practice: EM Performance page
Active Sessions by wait class over time

Colored area = Amount of DB time , More the DB time , More the Problem
Click on the big stuff
10
ASH Theory to Practice: EM ASH Analytics Page

Graphical ASH report for advanced
analysis
Select any time period for analysis
Analyze performance across many

dimensions
Provides visual filtering for
recursive drill-downs
Different visualizations: Stacked
chart or Tree Map
Collaborate with others using
Active Reports
11
Agenda
Introduction

12
Past DB Tuning Process

Inefficient, Inaccurate, Manual
Will optimizer_index_cost_adj
improving my sequential reads
Find a
problematic
metric
Did it work?
Implement a
possible Fix
Wait for enduser

feedback
Default value is 100,

so lets set it to 50
Are customers complaining?
The trial and error method can consume more than 50% of the DBA time
13
Future Generation DB Tuning Process

Effective, Accurate, Automated
Built-in, self-diagnostics
Diagnostics
Find
engine:
Automatic Database
Diagnostics Monitor (ADDM)
(Diagnostics Pack)
Tuning
Fix
SQL
Performance
Validate
Analyzer
(SPA)
Automates complex and time

consuming
task of application tuning
(Tuning Pack)
Validates
tuning activities
(Real Application Testing)
14
Find Fix Validate
STEP 1 - Find Issues

Diagnostics
Tuning
STEP 2 - Fix Issues
SQL Performance
Analyzer (SPA)
STEP 3 - Validate Fix

Diagnostics
Find-Fix-Validate Methodology and Toolset

Find:
Gather Data: Performance and workload data capture
AWR
System statistics, wait information, SQL Statistics, etc.
Data Analysis and Problem Identification
What types of operations are consuming most time?

Which resources is the bottleneck?
What is the root cause?
How can problem be remediated?
If multiple problems identified, which is most critical?

Which solution will give me most benefit?
For SQL Related problems, ADDM points recommends running
SQL Tuning Advisor
ADDM
ADDM
Rich feature-set provides comprehensive support for diagnosing problems: System Session, Targeted or Transient, Hung or
slow moving databases, etc. Built into the Oracle kernel and highly optimized (already part of the SGA)
17
Gathering Data Automatic Workload Repository (AWR)
Built-in workload and performance statistics repository in the database
Automatically captures workload data

Every 60 minutes, or manually, saves data for 8 days by default
Resides in SYSAUX tablespace
Space requirements automatically managed

Old data is automatically purged nightly based on retention interval
Stores different classes of data:
BASE STATISTICS e.g., physical reads
SQL STATISTICS e.g., disk reads (per sql stmt)
METRICS e.g., physical reads / sec
SQL Monitor Report Data
ACTIVE SESSION HISTORY (ASH)
Support for Exadata and In-Memory Database statistics

18
Active Session History (ASH)
Samples active sessions every one second into memory (v$active_session_history)
Helps answers questions like has this SQL gotten slower over time?
Direct access to kernel structures
One of ten samples flushed to AWR at every snapshot
Performance
Range
Data captured includes:

SID
SQL ID
Program, Module, Action

Wait event#
Object, File, Block
actual wait time (if captured while waiting)
Time
Enables targeted performance analysis of transient problems

19
Active Session History (ASH)

Query for Khalid
Husaini Novels
Browse and
Read
Reviews
Add
item to cart
Checkout using
one-click
DB Time
Time
SID
Module
SQL ID
State
Event
7:38:26
213
Book by author
qa324jffritcf
WAITING
db file sequential read
7:42:35
213
Get review id
aferv5desfzs5
CPU
7:50:59
213
Add to cart
hk32pekfcbdfr
WAITING
buffer busy wait
7:52:33
213
One click
abngldf95f4de
WAITING
log file sync
20
User Session Performance Dimensions

SQL
PL/SQL
Resources
Identifiers
Attributes
SQL
Session
Attributes
PL/SQL
ASH
Session
Identifiers
SQL ID
PL/SQL
Wait Class
Instance
Consumer
Group
Plan Hash
Top Level
PL/SQL
Wait Event
Services
Module
Operation
Object
User Session
Action
OpCode
Blocking Session
Parallel Process
Client
Program
Trans. ID
Resources
Session Type
21
Case Study 1: Slow Application Response Problem - Correlating

AWR & ASH Data
Application users are complaining of poor performance. How do we diagnose
the issue and resolve it?
Several factors can impact SQL Response time
Increased or unusual load on system

Hardware Issues
Runaway queries consuming system resources
Changes in execution plans
Missing or stale object statistics
Need a mechanism to quickly analyze in-memory performance data
22
Application Response Time Analysis - AWR

AWR top 5 section shows the Wait Class which
contributes most to DB wait time
Wait event enq TX contributes to this DB time
Wait class application constitutes 55% of DB time
Foreground Wait Class section in AWR to see

distribution of DB waits over Waits classes
Identify segments that contribute to this wait
Objects involved in TX row lock contention can

be identified in Segment Statistics section of
AWR
23
Analyze ASH: Correlate the findings from AWR
24
Analyze ASH Report for the period of increase of

applications waits, it shows the same as AWR
Identify the module that suffered from this type of

contention from the top service/module
section
24
Identify the Impacted Sessions and SQLs

3
Identify the top sessions impacted from this type

of contention/wait from the Top sessions
section
Identify the SQLs associated with this type of

contention/wait from the Top SQL section
25
Identify the Blockers and the Objects Causing the Contention

5
Identify the blocking sessions associated with this

wait event from the Top Blocking Sessions
section
Nail down the objects that is subject to this wait

from the Top DB Objects Section
So how do you resolve this issue?

26
Case Study 2: Understanding I/O Bottle Neck with ASH Analytics

Identify SQLs that are subject to User I/O
Understand
Operation
Identify the Object
subject tothe
FullPlan
Table
Scan that causes the I/O
Graphical ASH report for advanced analysis
Different visualizations: Stacked chart or Tree Map
Provides visual filtering for recursive drill-downs
Collaborate with others using Active Reports
Select any time period for analysis

Analyze performance across many dimensions
27
Automatic Performance Diagnostics Monitor (ADDM)

Boost Administrator
Productivity
IO / CPU
Issues
Eliminate Performance
Bottlenecks
High
Load
SQL
Automatic Workload
Repository Snapshots
Self-Diagnostic
Engine
RAC
Issues
Lower IT Management
Costs
Performance &
Management
Advisors
Deliver Higher Quality

of Service
Runs proactively out of the box, reactively when required

Top-down analysis using Automatic Workload Repository snapshots
Real-time performance and historic analysis with Automatic Database Diagnostic Monitor
Resolve performance issues faster with drill-down root-cause analysis
Classification tree based on Oracle performance tuning expertise

Performance expert; now a RAC specialist too in Oracle Database 11g
28
Proactive Performance Management: ADDM
29
Automatic Performance Diagnostics

Continuous Evolution in Database Performance Management
ADDM
Diagnose persistent
performance issues
Uses AWR snapshots

Regular interval
Automatic / Manual
Compare
Period ADDM
Real-Time
ADDM
In-depth performance Hung or extremely

comparison across
slow databases
two periods
Uses a normal and
Relies on AWR data
diagnostic mode
connection
Manual
Manual
Enhanced
Real-Time
ADDM
Proactively detect
& diagnose
transient highimpact problems
Built inside the DB
Automatically runs
every 3 seconds
30
Comparative Performance Analysis with AWR Baselines

and Reports
Automatic creation and management of

reference baselines
Compare Period ADDM: Enables performance

comparison of two periods with AWR Reports
Performance
Makes analysis of workload variations and

performance diagnosis easier
Actual
Moving window baseline created out-of-the-box
Baseline
Enables proactive monitoring with adaptive

thresholds
Baseline is key for performance tuning to
Set alert thresholds
Monitor performance
Compare performance variations
time
31
Compare Period ADDM

SQL Commonality
Regressed SQL
AWR Snapshot
Period 1
I/O Bound
AWR Snapshot
Period 2
Compare
Period ADDM
Analysis Report
Undersized SGA
Full ADDM analysis across two AWR snapshot periods

Detects causes, measure effects, then correlates them
Causes: workload changes, configuration changes
Effects: regressed SQL, reach resource limits (CPU, I/O, memory, interconnect)
Makes actionable recommendations along with quantified impact

32
Compare Period ADDM: Method

STEP 1:
Identify what changed
DB configurations, workload changes
STEP 2:
Did the Buffer cache get smaller?

Quantify performance
differences
Why is there
10% new SQL?
Uses DB Time as basis for measuring performance
STEP 3:
How come Top SQL impact increased by 45%?

Identify root cause
Read I/O are up by 55%, why?
Correlate performance differences with changes
Did a buffer cache reduction cause a read I/O increase?

33
Compare Period: Report
34
Real-Time ADDMArchitecture
EM Agent
Deadlocks
Enhanced
Real-Time
Hangs
ADDM
Diagnostic Connection
JDBC Connection
Latches
Database
ADDM
Analysis
Makes a lightweight connection without acquiring additional locks and resources, bypassing the
SQL layer through the agent
Also attempts to initiate standard JDBC connection

Data returned by either connection is analyzed by ADDM
35
Real-Time ADDM Enhancements

Oracle Database 12c
Automatic real-time problem detection and analysis
Database self-monitors for serious performance issues

Recognize bad performance trends and trigger analysis:
High CPU, I/O spikes, memory, interconnect, hangs, deadlocks
Identify a problem before it threatens application performance
Short duration (5 min spikes) ADDM analysis

Actionable advice for critical issues
Richer data set available for analysis
Reports (analysis and data) stored in AWR for historical analysis

ADDM, SQL Monitoring reports
36
Triggering Conditions
#
Rule
Condition
High Load
Average active sessions greater than 3 times the number of CPU cores
I/O bound
Impact on active sessions based on single block read performance
CPU bound
Active sessions greater than 10% of total load and CPU utilization great
than 50%
Over-allocated
memory
Allocation over 95% of physical memory
Interconnect bound
Single block interconnect transfer time based
Session Limit
Session limit close to 100%
Process Limit
Process limit close to 100%
Hung Session
Significant number of hung sessions. If this number is greater than 10%

of total sessions
Deadlock Detected
Any deadlock detected by hang analyzer
37
Find: Performance Diagnostics Summary

Topics Covered
Database Time
AWR
Enterprise Manager ASH: Transient / Targeted Performance Analysis
ADDM: Proactive Performance Management and Diagnosis
The above toolset helps identify the potential problems and recommends appropriate
solutions
For SQL related issues, ADDM recommends SQL Tuning Advisors
Next Steps: Tune the identified SQL problems
38
Tuning
39
SQL Performance Issues: Broad Categories

Optimizer
Stale/Missing statistics
Upgraded Database: new optimizer
Incomplete statistics
Changing statistics
Improper optimizer configuration
Rapidly changing data
RESOURCES
Resource &
Contention Issues
APPLICATIONS
Hardware resource crunch
Not parallelized (no scaling to large data)
Contention (row lock contention, block contention)
Improperly parallelized (partially parallelized, skews)
Data fragmentation
Rapidly changing data
Missing access structures

Poorly written SQL statements
Application Issues
Bind-sensitive SQL with bind peeking (Cursor Sharing)

Literal usage
40
Automatic SQL Tuning

Gather Missing or Stale Statistics
Create a SQL Profile
SQL Profiling
Add Missing Access Structures
Statistics Analysis
Modify SQL Constructs
Access Path Analysis
Adopt Alternative
Execution Plan
SQL Restructure Analysis

Alternative Plan Analysis
Parallel Query Analysis
Automatic Tuning Optimizer
Create Parallel SQL Profile
Administrator
SQL Tuning
Advisor
Comprehensive
SQL Tuning
Recommendations
SQL Tuning Advisor

Gives suggestions on the various problems identified during the diagnosis phase
Uses the same CBO but has more time budget to perform comprehensive analysis
Identifies alternate execution plans using real-time and historical performance data
Recommends parallel profile if it will improve SQL performance significantly (2x or more)
41
What is SQL Profile?

Contains auxiliary information collected by the ATO for a SQL statement
Customized optimizer settings
Based on past execution history (e.g., first_rows vs. all_rows)
Compensation for missing or stale statistics

Compensation for errors in optimizer estimates
Estimation errors occur due to data skews and correlations, complex filters and joins
Doesnt require any change to the SQL text
Ideal for Packaged Apps
Persistent: Works across shutdowns & upgrades

Transportable across databases (10.2)
Force Matching for Literals: This setting may be useful for queries that use only literal values
SQLTUNE_CATEGORY: Enables you to test a profile in a restricted environment before making it
available to other sessions. Can be enforced at session level or system level, this defaults to system
level
42
SQL Profiling Flow

SQL Profiling
submit
create
Optimizer
(Tuning Mode)
SQL
Profile
SQL Tuning
Advisor
After
output
submit
Optimizer
(Normal Mode)
Database
Users
Well-Tuned
Plan
43
SQL Tuning in Oracle Database 10g

End-to-End Workflow
Evaluate
Recommendations
Implement
Workload
DBA
DBA
Generate
Recommendations
one hour
DBA
ADDM
AWR
Invoke Advisor
SQL Tuning Advisor

SQL Tuning Candidates
A good end-to-end solution,
but manual intervention required
44
Automatic SQL Tuning in Oracle Database 11g/12c

Packaged
Apps
Complete automation of SQL tuning
Custom
Apps
Automatically captures high-load SQL
Auto Capture High-Load SQL

Nightly
Automatic SQL Tuning

SQL Profiles
SQL Analysis
Automatically tunes SQL without

changing application by creating SQL
Profiles
Automatically implements (optional)
greatly improved SQL plans
Automatically reports analysis
Automatic
implement
Report
Well-tuned SQL
Manually
implement
Automatically runs during maintenance

window
45
Automatic SQL Tuning in Oracle 11g/12c

Implement
SQL Profiles
Test SQL Profiles
Workload
Generate
Recommendations
Choose Candidate
SQL
SQL Tuning
Candidates
one week
Its Automatic!
View Reports / Control

Process
AWR
DBA
46
47
Workload Tuning: SQL Access Advisor

Recommendations
Access Path Analysis
Automatic Tuning
Optimizer
B*-tree indexes
SQL Access Advisor
Bit-map indexes
Partitions (11g +)
MV and MV Logs
DBA
Partition Advisor:
Range Partition
Interval Partition
Hash Partition
List Partition
Provides List Partition recommendations for 12c Database

Analyzes already partitioned tables for further optimization
Significant reduction in analysis time for very large workloads (DB12c)

48
SQL Access Advisor: Partition Advisor
Analysis Run Times Oracle Database 11.2 versus 12.1
DB 11.2
10000
40X
Run Time (seconds)
Partition Advisor
analyses large
workloads 40x faster
than before
1000
20X
100
2X
10
1
1
DB 12.1
3
4
5
6
7
8
SQL Workload Size (in thousands)
10
49
SQL Access Advisor Features
Recommends indexes, partitions (hash and interval only) materialized views, and
materialized view logs to create and/or drop for faster performance
Analyzes entire workload and not just independent SQL statements
Takes into account impact of new access structures on DML operations
Considers storage, creation and maintenance costs
Simultaneously considers
index solutions
materialized view solutions
combinations of both
Optimizes materialized views for

maximum query rewrite usage
fast refresh
50
Real-Time SQL Monitoring

Looking Inside SQL Execution
Automatically monitors long running SQL

Enabled out-of-the-box with no performance impact
Monitors each SQL execution
Exposes monitoring statistics
Global execution level
Plan operation level
Parallel Execution level
Guides tuning efforts
Bind values shown
SQL level metrics
CPU, I/O requests, throughput, PGA, temp space
Graphical explain plan

I/O statistics for each operation
51
Real-Time PL/SQL Monitoring
PL/SQL execution no longer a black box

Answers questions like why did my DBMS_STATS job take twice as long this time?
Shows global (PL/SQL) and SQL level statistics
Each SQL called by PL/SQL recursively monitored
Drill-down to slow SQL for diagnosing unexpected PL/SQL behavior

52
Real-Time SQL Monitoring: Case Study 1

My simple query is taking longer than before. What could have gone
wrong?
SQL Performance Problems

Statistics
Resources
Application issues
Parallelism
Initialization parameters
53

SQL with count and Group by
54

SQL with count and Group by
55

PGA Size increased
56
Real-Time SQL Monitoring: Case Study 2

I enabled parallel query, yet this query is taking so long. How do we
approach this problem?
Parallel Downgrades
Uncontrolled parallel execution
Parallel Server availability
Object level settings
Session level settings
57

Parallel Tab
Parallel Coordinator busy for the entire duration !!

58

Enabled Parallel DML
Parallel Slaves busy for the entire duration !!!

59
Real-Time Database Monitoring
Whats Really Happening in the Database
Challenge:
Solution:
SQL & PL/SQL Monitoring only

monitors a single execution
Real-Time Database Operations

Monitoring
How does a DBA monitor a

composite operation such as a
batch job?
Benefit:
Allows DBAs to look into complex
composite DB operations for
analysis and tuning purposes
60
Monitor Complex Database Operations
Oracle Database 11g: Support for simple DB operations

SQL statements (e.g., SQL for DSS, batch/report SQL, runaway SQL)
PL/SQL procedures/functions
Oracle Database 12c: Support for composite operations

Session(s) activity between 2 points of time defined by application code / DBA
For example; SQL*Plus script, batch job, or ETL processing

At most one DBOP per DB session
62
SQL Performance
Analyzer (SPA)
65
SPA Motivation
Businesses need to adapt to changes to stay competitive, compliant and evolve
SQL performance regressions: #1 cause of poor system performance.
DB upgrades, schema, optimizer statistics refresh
Current testing landscape and limitations
Expensive capture, partial workload, non-production optimizer context, binds
Large workloads (100Ks SQL stmts are common)
Manual and time consuming testing and regression tuning
No end-to-end testing solution
Test In Production is not too uncommon
SQL Performance Analyzer (SPA)

Proactively detects ALL SQL regressions, BEFORE actual change is deployed
Integrated comprehensive solution for end-to-end SQL workload testing
66
SPA Overview
Helps users predict the impact of system changes
on SQL workload response time
Low overhead capture of SQL workload to SQL
Tuning Set (STS) on production system
SQL Workload
STS
SQL plans + stats

Pre-change Trial
SQL plans + stats

Post-change Trial
Build different SQL trials (experiments) of SQL

statements performance by test execution
Analyzes performance differences
Offers fine-grained performance analysis on

individual SQL
Compare
SQL Performance
Analysis Report
Integrated with STS, SQL Plan Baselines, & SQL

Tuning Advisor to form an end-to-end solution
67
When to use SPA?

SPA supports testing in Oracle Database Releases 10.2 , 11g and 12c
Optimizer statistics refresh
Validate and Implement of tuning recommendations from ATO

Database parameter changes, schema changes (e.g., add/drop indexes)
I/O subsystem changes (e.g., ASM, Database Machine)
SPA handles trials in a manner that does not change database data
Hence can be used for testing in production/standby environments
For supported releases, test database upgrades and patch-set releases*
SPA Provides Broad Testing

Coverage
Across many releases of Oracle and for upgrades

On test, standby, and production environments
Extended to home-grown scripts, third-party testing tools, etc.
Supports most applications - EBS, SAP, Siebel, home-grown, etc.
*MOS Note: 560977.1

68
SPA: Enterprise Manager Interface
Rich GUI through Enterprise Manager

DBMS_SQLPA package PL/SQL API
69
SPA Report
3
2
1
4
70
SPA Report: Regressed SQL Statements
71
SPA Challenges
Running SPA on:
Test System: Safe but
Test
Database
Production
Database
Production System: Easier but
Requires separate HW
Data in test system should be

same as production
Could be resource intensive and

impact production performance
Changes needs to be manually

scoped to private session
Could take a long time to finish
No resource control by default
Lengthy, error-prone task

DBA
72
SPA Quick Check

Optimized
Optimized for use on prod systems

Optimal Trial or Explain Plan mode
Disable multi-executions, full DML execute disabled
SPA Quick Check
Optimal Trial
Mode, no DML
execute
Controlled
ChangeAware
Per SQL time limits

Testing scoped to private session
Associate with Resource Consumer Group
Optimized
Per SQL Time Limits,

Limits testing scope to
Controlled/S
private session
coped
Change-Aware
Context-aware change testing workflows, such as,

Optimizer gather statistics
Init.ora parameter changes
Pre-selected
STS and
default SPA
settings
Context-aware
change testing
Production
Database
DBA
73
SPA Quick Check

Optimized
Identifies subset
SQL workload with
plan changes first
Test-executes only
SQLs with plan
changes
Minimizes use of
production
resources
dramatically up
to 10x reduction
Multiple executions
disabled
No full DML
(execute Select
part of workload)
74
SPA Quick Check

Controlled
Per-SQL time limit protects from runaway SQL
Resource throttling - Associate with Resource

Consumer Group
Testing scope limited to private session
75
SPA Quick Check

Change-aware
Change-aware: Knows what change is being
tested
In-line with routine DBA tasks such as statistics

gathering, init.ora parameter changes
Intelligently limits impact to private test session
76
SPA Quick Check
77
SPA Quick Check
78
Agenda
Introduction

79

Diagnostics
Tuning
STEP 2 - Fix Issues
SQL Performance
Analyzer (SPA)

80
Diagnostics
Step 1 The Find

ADDM automatically detects performance bottlenecks
Database Home Page gives a quick high level overview of current status
Database found to be running high load (Active Sessions)
ADDM has already detected some performance issues (5 findings)
82
Step 1 The Find
Average Active Sessions
For further investigation, look at the DB Perf. Page and Click on the Big Stuff
DB Perf. Page shows significant resource being utilized on CPU and User I/O
Clicking on the snapshot icon will take us to the ADDM Home Page for that time
83
Step 1 The Find

ADDM Home Page
ADDM Home Page: Database activity gives quick performance overview

Looking at the ADDM performance analysis, SQL statements are impacting the system
significantly
Lets drill down on the Top SQL Findings
84
Step 1 The Find
Automatic Diagnosis and Recommendations
91.2% of the impact is from the SQL statements in the report

Performance diagnostics data provided for SQL causing high DB resource usage
85
Tuning
Step 2 The Fix
SQL Tuning Advisor
Run the problematic performing statements through Tuning Advisor

We will automatically capture the problematic statement
Top SQL statements are automatically captured in AWR
Seamless integration between Diagnostics and Tuning
87
Step 2 The Fix

Comprehensive Recommendations
Comprehensive analysis and multiple alternatives to improve performance

SQL Profiles can be implemented transparently & non-intrusively to tune SQL statements
As an example, lets gather statistics in pending mode

88
Step 2 The Fix

Set Publish to False for Scoped Change Testing
89
Step 2 The Fix

Gather Optimizer Statistics
90
SQL Performance
Analyzer (SPA)
Validate with SPA Quick Check
92
Step 3 Validate
Optimizer Statistics Refresh Validation
DB Home Page -> Performance -> SPA Link

93
Step 3 Validate
Take the Guess Work Out!
94
Find Fix Validate
Tuning

Diagnostics
STEP 2 - Fix Issues
SQL Performance
Analyzer (SPA)

Summary
96
Conclusion: Find-Fix-Validate
Improved Quality Of Service
Manage and Automate
Get
MORE databases
MORE uptime
MORE risk free administration on production
MORE Quality Of Service
MORE effort less testing on production
MORE sleep at night!
MORE applications support: OLTP, DW, COTS
MORE weekends off!
MORE users, larger databases

MORE mission-critical applications
Become
MORE proactive and strategic
MORE important and valuable!
97
98
99
AWR
Use AWR Warehouse for longer retention period:
Allows long term analysis

Zero overhead and impact on production
Global AWR reports:

Use Global AWR reports for RAC
Configured using $OH/rdbms/admin/awrgrpt.sql
Adaptive thresholds:
The significance level thresholds give users a way to specify alerting in terms of "how
unusual" rather than "how much
Performance tuning metrics:
Use DB Time, CPU Time IO time , not just Elapsed time for performance tuning
DB Time encompasses multiple metrics and provides better insight into the performance of
the system
Tips: Configuring EM to display Top N Activity

By default, EM is configured to display Top 10 items in the ASH Analytics Page
More than 10 SQL
More than 10 sessions
We can change the Top N SQL or sessions to display in Top Activity. Here is how to do it
$emctl set property [sysman_pwd <sysman_pwd>] -name oracle.sysman.db.ashPurgeSize -value <value>
restart the OMS

Default value is 10 , you can set this to 20 or 30 depending on the memory available for the OMS server.
Setting to higher values would require higher memory and hence not recommended.
Real-Time ADDM
Diagnostic connection
In this mode, Real-Time ADDM performs a latch-less connection to the database.
This mode is intended for extreme hang situations when a normal JDBC connection is not
possible.
Precise, actionable recommendations
Provides cluster-wide analysis for RAC
SQL Monitoring
Use Real-time SQL Monitoring to Understand SQL Execution
SQL Details Active Report
Shows whats happening inside SQL execution
Automatically monitors long running SQL
Shows the statistics and resources consumed at each step of the plan.
Shows actual cardinality at each step, helps resolve problems with poor cardinality estimates
Exposes monitoring statistics

Plan operation level
Parallel Execution level

I/O, CPU, memory, network
Exadata Smart Scans
SQL Monitoring
Use Active Reports where available: SQL details, SQL Monitor, SPA , ASH, ADDM
Composite Active Report
Single HTML file that embeds a set of correlated active reports
Allows the user to navigate from one active report to another without connecting to the database
Examples: Performance Hub, SQL Details, Session Details and SQL Monitor List
Performance Hub
Provides a new consolidated view of all performance data for a given time range
The Performance Hub can also be saved as a Composite Active Report

Real Time Performance Hub, Historical Performance Hub, Real-time Performance Hub (RAC)
DB 12c update
In addition to the composite active reports -- there is now also an active report for SQL Tuning and Automatic Realtime ADDM
The SPA and SQL Monitor Details active reports, which were introduced in 11g, have also been enhanced
Tips: How to generate Active report without EM

SQL Details Active Report : Use dbms_perf.report_session() function
SQL Monitor Active Report: Use dbms_sqltune.report_sql_monitor_list() function
SQL Performance Analyzer Active Report: Use dbms_sqlpa.report_analysis_task() function

Performance Hub Active Report: Use dbms_perf.report_perfhub () function
For example, the following SQL*Plus script shows you how to generate a Real-time PerfHub Active Report:
SQL>set pages 0
SQL>linesize 32767
SQL>trimspool on
SQL>trim on
SQL>long 1000000
SQL>longchunksize 10000000
SQL>spool perfhub_active.html
SQL>select dbms_perf.report_perfhub(is_realtime=>1,type=>'active') from dual;
The resulting file perfhub_active.html should be edited to remove the header (first line in the file) and the last line (spool off).
SQL Tuning
Use Automatic Tuning Advisor to tune SQL, one of the most underutilized feature by customers
Automatically captures high-load SQL
Automatically tunes SQL without changing application by creating SQL Profiles (If auto
implement is enabled)
Automatically runs during maintenance window
Set task parameters to 1-2 yrs (default 30) for historical tuning information
SPA Quick check for easy validation directly on production

Validate optimizer statistics refresh/gather before publishing
Validate recommendations from the SQL Tuning Advisor (SQL Profiles, Index recommendations )
SQL Profiles Vs SQL Plan Baselines: Use Cases, Pros/Cons

SQL Profiles
Use case: Reactive, SQL performance is suboptimal, invoke SQL Tuning Advisor on high load
or business critical SQL
Pros:
A SQL Profile contains auxiliary information that
corrects the cardinality estimated in a suboptimal Plan.
Flexible and better approach with volatile data,

not locked in by table sizes or existing access
structures
SQL Profiles with Indexes (recommendations)
can significantly improve performance
SQL Plan Baselines
Use case: Proactive, you already know SQL

performance is good and would like to seed the
known plan to the optimizer
Pros:
Preserves the known plans, useful in a very
predictable environment
Cons:
In a volatile environment, hard to know a good
plan.
Application SQL should be executed more than

once to capture the baseline
If access structures change or dropped, may not

be able to use the required plan
SQL Profiles Vs SQL Plan Baselines

SQL Profiles
SQL Plan Baselines
Contains auxiliary information that mitigates the

defects in a sub-optimal plan.
Consists of a set of accepted plans, a set of

existing plans known to be efficient.
Profiles provide additional information to the

optimizer to help select the best plan
Aides the optimizer to select the best plan from

among the accepted plans.
Doesn't constrain the optimizer to any specific

plan, which is why they can be shared.
Constrain the optimizer to only select from a set

of accepted plans.
Are more like extended statistics, better

information for the optimizer to decide about
how many rows will flow out of a step in the
plan.
A preventive mechanism that records and

evaluates the execution plans of SQL statements
over time.
Useful when you want the system to adapt

immediately to changes like new object
statistics.
Useful if you are more conservative and want to

control which plans are used.
10
New Features
AWR Warehouse
EM Express
In Memory Advisor
Adaptive Query Optimization
AWR Warehouse
AWR Warehouse - Business Drivers
Finance
AWR is the de facto performance

repository for Oracle databases since
10g
Default retention period of 8 days

prevents diagnosis of long term
performance problems (Compare
performance during this quarters
books close with last quarters)
Increasing AWR retention period

increases storage overhead and cost
in critical production environments
Supply
Chain
CRM
120%
120%
120%
90%
90%
90%
60%
60%
60%
30%
30%
30%
0%
0%
0%
AWR Warehouse - Architecture
Central warehouse configured for long

term AWR data retention
Historical and ongoing AWR snapshots

collected from databases enabled for
AWR warehouse
ETL jobs moves snapshots from source

databases into AWR warehouse
efficiently using Oracle Data Pump
Retention period configurable for

weeks, months, years or forever
(default)
AWR Warehouse Features
Warehouse dashboard tracking ETL jobs
All AWR features available on long term

AWR data
Performance page
AWR report
ASH analytics
Compare Period ADDM
Compare Period Report
Integrated seamlessly into EM UI
Zero runtime overhead on source

Production databases
EM Express
Oracle Enterprise Manager Database Express 12c

Integrated, GUI Management Tool for Database Administration
Integrated Install
Small Footprint
Comprehensive
Administration
Pre-configured & installed

with the database
Disk: 20 MB
Basic admin support for:
Runtime: zero when idle
Storage management
Runs inside database
Security management
No extra MW components
Minimal CPU, memory

overhead
Leverages XDB server inside

db for web services
100% of UI rendering
performed in browser
Advanced performance
diagnostics and tuning
Supports SI, RAC, SE, EE
DB Server only runs SQL
Configuration management
Enterprise Manager Database Express Menus
10
Database Performance Hub

Unified Performance Monitoring
Single view of DB performance

ADDM, SQL Tuning, Real-Time SQL
Monitoring, ASH Analytics
Switch between ASH analytics, workload view,

ADDM findings and SQL monitoring seamlessly
Supports both real-time & historical mode
Dedicated tab for RAC
Historical view of SQL Monitoring reports
11
Oracle Database In-Memory Central
12
In-Memory Central
Oracle Database In-Memory Advisor
14
Oracle Database In-Memory Advisor: Challenges

Optimizing database In-Memory Column Store configuration for maximum
performance
Actionable recommendations
Workload based cost/benefit analysis
In-memory area population plan
15
Features
Assist with IM Column Store size selection
Recommend tables, partitions and sub-partitions for a given IM Column Store
size
Use workload and performance data to prioritize objects

Take into account differences in disk and memory footprint, as well as
compression ratios
16
Features
Recommendation based on cost/benefit calculations
Cost: Estimated memory size with various compression options
Benefit: Estimated DB time reduction of processing analytic workload
Report
Vary IM Column Store size to receive specific loading plan
Generate DDL script with all the tables/partitions/sub-partitions recommended
Top SQL benefits from given configuration
17
Future
Recommend reconfiguration of existing In-Memory Column Store
Suggest objects to evict
RAC advice
In-Memory Column Store configuration can vary by instance
Column specific recommendations

Recommend specific columns to be loaded in memory instead of the entire object.
Useful for wide tables.
18
19
20
21
Set of capabilities that enable optimizer to
Make run time adjustments execution plans
Discover additional information that can lead to better statistics
22
Adaptive Plan Types
Join : Changes join method from Nested Loops to Hash Join, and vice versa, based on cardinality.
Parallel Distribution : Changes data distribution method among parallel processes from Hybrid Hash to
Broadcast, based on cardinality.
23
Adaptive Statistics Dynamic Statistics
When OPTIMIZER_DYNAMIC_SAMPLING parameter is set to 11, statistics are gathered before

statement execution and cached as dynamic statistics.
Even when enabled, factors like predicate complexity, existing base statistics and
total execution time expected determines whether to gather dynamics statistics or not.
24
Adaptive Statistics Automatic Reoptimization
In contrast to adaptive plans, automatic reoptimization changes a plan on subsequent executions after
the initial execution.
Statistics feedback : When SQL statement is executed (with statistics feedback monitoring enabled) for the first
time, optimizer compares its original cardinality estimates to the actual cardinalities observed during execution
and, if estimates differ significantly from actual cardinalities, it stores the correct estimates for subsequent use.
After the first execution, the optimizer disables monitoring for statistics feedback.
25
Adaptive Statistics Automatic Reoptimization
Performance feedback : The parallel degree chosen by the optimizer is compared to the parallel degree
computed base on the actual performance statistics (e.g. CPU-time) gathered during the
initial execution of the statement. If the two values vary significantly then the statement is marked for
reoptimization and the initial execution performance statistics are stored as feedback to help compute a
more appropriate degree of parallelism for subsequent executions.
26
Adaptive Statistics SQL Plan Directives
SQL plan directives, created automatically as a result of Automatic Reoptimzation, can direct the optimizer to
use dynamic statistics to obtain more accurate cardinality estimate.
Created whenever there is a mismatch between optimizer's cardinality estimates and the actual number of
rows returned after execution.
Created on query expressions, not at statement or object level.
27
Resources
References
2 Day DBA :
http://docs.oracle.com/cd/E16655_01/server.121/e17643/toc.htm
2 Day + Performance Tuning Guide:
http://docs.oracle.com/cd/E16655_01/server.121/e17635/toc.htm
Oracle Database 12c - EM Express Performance Hub:
http://www.oracle.com/technetwork/database/manageability/emx-perfhub-1970118.html
Oracle Database 12c - EM Express Active Reports:
http://www.oracle.com/technetwork/database/manageability/emx-activerep-1970119.html
SQL Performance Analyzer Active Report:
http://www.oracle.com/technetwork/database/manageability/sqlpa-094776.html
Database Manageability and Real Application Testing:
http://www.oracle.com/technetwork/database/manageability/index.html

Performance Tuning - Expert Panel

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Performance Tuning - Expert Panel

Uploaded by

Copyright:

Available Formats

Workshop

Safe Harbor Statement

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Find, Fix and Validate: Methodology and Toolset

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Downtime resulting from

Use SQL tuning to address

Data stores growing by

Handle more than 50 DBs

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Find, Fix and Validate: Methodology and Toolset

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Database Time (DB Time)

New metric for Oracle performance analysis

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Average Activity of the Session (% Activity) =

= time spent in database

DB Time Theory to Practice: EM Performance page

Active Sessions by wait class over time

Click on the big stuff

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

ASH Theory to Practice: EM ASH Analytics Page

Analyze performance across many

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Find, Fix and Validate: Methodology and Toolset

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Past DB Tuning Process

Wait for enduser

Default value is 100,

Are customers complaining?

Future Generation DB Tuning Process

Automates complex and time

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Find Fix Validate

STEP 1 - Find Issues

STEP 2 - Fix Issues

STEP 3 - Validate Fix

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Find-Fix-Validate Methodology and Toolset

System statistics, wait information, SQL Statistics, etc.

Data Analysis and Problem Identification

What types of operations are consuming most time?

If multiple problems identified, which is most critical?

Copyright 2014 Oracle and/or its affiliates. All rights reserved. |

Gathering Data Automatic Workload Repository (AWR)

Built-in workload and performance statistics repository in the database

Automatically captures workload data

Resides in SYSAUX tablespace

Space requirements automatically managed

Stores different classes of data:

BASE STATISTICS e.g., physical reads

SQL STATISTICS e.g., disk reads (per sql stmt)

METRICS e.g., physical reads / sec

SQL Monitor Report Data

ACTIVE SESSION HISTORY (ASH)

Support for Exadata and In-Memory Database statistics

Active Session History (ASH)

Samples active sessions every one second into memory (v$active_session_history)

Direct access to kernel structures

One of ten samples flushed to AWR at every snapshot

Data captured includes:

Program, Module, Action

actual wait time (if captured while waiting)

Enables targeted performance analysis of transient problems