Maximizing DB Performance - v2

Maximizing Database
Performance
A Practical Approach to Diagnostics and Tuning
Prabhaker Gongloor (GP)

Senior Director of Product Management
Systems & DB Manageability Development
Oracle Corporation
Copyright 2016, Oracle and/or its affiliates. All rights reserved. | Confidential Oracle Internal/Restricted/Highly Restricted
Safe Harbor Statement

The preceding 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.
Program Agenda
1
Introduction
Oracle Database Performance Tuning Fundamentals
Performance Tuning Methodology
New Features
Copyright 2016, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential Internal/Restricted/Highly Restricted
Program Agenda
1
Introduction
New Features
Top Database Management Challenges
%
52
Rapid diagnoses of database

performance problems
%
45
Identifying application (SQL)

issues
%
37
Validating and applying SQL

tuning solutions
Source: THE RAPIDLY ACCELERATING CLOUD-ENABLED ENTERPRISE: 2015 IOUG Survey On Database Manageability
Program Agenda
1
Introduction
New Features
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 or elapsed 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
For a single session
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 spent in database

TIME
9
How Does DB Time Work?

DB Time = Sum of DB Time Over All Sessions
Avg. Active Sessions = Sum of Avg. Activity Over All Sessions
= Sum(DB Time) / Elapsed Time
Time t= 2 Active Sessions
10
What Approach To Use To Identifying Issues?

DB Time theory in practice!
Active Sessions by wait class over time

Colored area = Amount of DB time, More the DB time, More the Problem
Focus on the BIG problems first!
DB time increases as system performance degrades
11
Program Agenda
1
Introduction
New Features
12
Performance Tuning Methodology What Approach to Use?
Proactive Performance Management
Reactive Performance Management
13
Proactive Performance Management

Be in charge of your environments
Use Oracle Enterprise Manager to avoid production issues
Understand what changes you are introducing into production (stats gathering, patch
sets, upgrades, hardware, platform, new features)
Test changes before they are introduced into production
Try out every single changeto ensure it will not have an negative effect
14
SQL Performance Analyzer (SPA)

SQL Workload (STS)
Helps users predict the impact of system

changes on SQL workload
Low overhead capture of SQL workload to

SQL Tuning Set (STS) on production system
Build different SQL trials (experiments) of
SQL statements performance by test
execution or explain plan
SQL Plans + Stats
SQL Plans + Stats
Pre-change Trial
Post-change Trial
Compare SQL
Performance
Integrated with STS, SQL Plan Baselines,

and SQL Tuning Advisor to form an end-toend solution
Copyright 2016, Oracle and/or its affiliates. All rights reserved. |
Analysis Report
15
Predict the Impact of Routine System Changes in Production

SQL workload response time
Optimized
Optimized for use on prod systems
Optimal Trial or Explain Plan mode
Disable multi-executions, full DML execute disabled
Controlled
Per SQL time limits
Testing scoped to private session

Associate with Resource Consumer Group
Change-Aware
Context-aware change testing workflows, such as,
Optimizer gather statistics & Init.ora parameter changes
16
Database Replay, Concurrent Replay

Database load and performance testing with real
production workloads
Production
Clients
Test
Replay Driver
Production workload characteristics such as

timing, transaction dependency, think time, etc., fully
maintained
Test and measure transaction throughput

improvements
Identify application scalability and concurrency
deployment problems on test system before
production
Storage
Storage
Capture
Process
Replay
Analysis &
Reporting
Perform capacity planning with consolidated

replay with Multitenant or schema consolidation
17

Unfortunately we are not always in control
Use Oracle Enterprise Manager to deal with production issues not
introduced in a controlled way
Issue
Analyzing transient performance problems
Diagnose persistent performance issues
In-depth SQL performance analysis
Optimizing top SQLs with sub-optimal plans
EM solution
ASH Analytics
ADDM
Real-Time SQL Monitoring
SQL Tuning Advisor
18
Identify performance issues using ASH Analytics

Graphical ASH report for advanced analysis
Provides visual filtering for recursive drill-downs
Select any time period for analysis
Analyze performance across many dimensions
19

I am a CDBA and asked to investigate
transient performance issues reported by
one application owner. I need to diagnose
the cause of these issues and address
them
AWR report indicates some unusual
issues on the system
But I dont get a PDB specific report
What to do next?
20
Demo
Using ASH Analytics for identifying
performance issues (4 min)
Copyright 2016, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential Internal
21
Analyzing transient performance issues using ASH Analytics
22
ASH Analytics identifies User I/O as the problem

Identify SQLs that are subject to User I/O
23
Diagnose Persistent Performance Issues

ADDM
Diagnose persistent
performance issues
Analyzes AWR
snapshots
Regular interval
Automatic / Manual
Compare
Period ADDM
In-depth
performance
comparison across
two periods
Real-Time
ADDM
Hung or extremely
slow databases
Relies on AWR data
Uses a normal and

diagnostic mode
connection
Manual
Manual
Enhanced
Real-Time
ADDM
Proactively detect
& diagnose
transient highimpact problems
Built inside the DB
Automatically runs
every 3 seconds
24

My database is unresponsive and end-users
are complaining of performance issues.
Should I bounce the database or wait for
some time for problem to go away?
Database Hung state
- Blocking Sessions
- Memory allocation issues
- Library cache issues
- Unresponsive Storage (ASM)
- Interconnect problems
25
Real-Time ADDM
Automatic real-time problem detection and analysis
Database self-monitors for serious performance issues
Recognizes bad performance trends and triggers 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

Reports (analysis and data) stored in AWR for historical analysis
ADDM, SQL Monitoring reports
26
Diagnose Hung Database Issues Using Real-Time ADDM

Identify the problem area
Turns out to be a SQL that consumes significant amount of DB Time
Review SQL Monitor report of the problem SQL for in-depth analysis
27
Diagnose SQL Performance using Real-Time SQL Monitoring

The SQL ran for a period of 5 minutes and created the spike
28
Diagnose SQL Performance using SQL Details Active Report

Multiple sessions trying to read the same block over and over
29
Diagnose Hung Database Issues Using Real-Time ADDM

Refer back to Real-Time ADDM to nail this down as login storm issue,
understand more about this query
30
How To Go About Tuning the Sub-optimal SQL?

Gives recommendations on various problems found during analysis phase
Uses the same CBO but has more time budget for comprehensive analysis
31
Identifies alternate execution plans using real time and historical performance data
Automatic Tuning Optimizer
Recommends SQL profile to compensate for incorrect statistics and transparently

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

Alternative Plan Analysis
Parallel Query Analysis
SQL Tuning
Advisor
Create Parallel SQL Profile
Administrator
31
Which Database Performance Diagnostics Tool to Use?

Automatic Workload Repository AWR Reports
Reports about performance and workload data from AWR
Active Session History ASH

Gathers fine-grain data about every active database session
every second
Automatic Database Diagnostics Monitor - ADDM

Data Analysis and Problem Identification
Findings and Advise on how best to resolve bottlenecks
Real-time SQL and Database Operations Monitoring

Provides in-depth diagnostics about SQL execution at row
source level
Database Performance Hub provides holistic performance management

32
Database Performance Hub

Holistic Performance Management
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
Historical view of SQL Monitoring
reports
33
Performance Hub Report

New interactive report for analyzing AWR data
Performance Hub report generated from SQL*Plus
@$ORACLE_HOME/rdbms/admin/perfhubrpt.sql
OR calling dbms_perf.report_perfhub(.)
function
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
Historical view of SQL Monitoring reports
34
Demo
Generating Perfhub Report
35
Program Agenda
1
Introduction
New Features
37
AWR and Multitenant: Background and Challenges

Single AWR repository per database
For non-CDB resides in SYSAUX
For CDB resides in Roots SYSAUX (12.1)
AWR Architecture (pre-DB12.2)

Internal Clients
Self Tuning
Components
ADDM
AWR does not have notion of AWR

data for a PDB (no Top N SQL per PDB)
Partial AWR statistics
Automatic Workload
Repository (AWR)
MMON Process
AWR data not transportable along with PDB
Foreground
Processes
SGA
DBA_HIST Views
Missing Time-Wait model, sysmetrics statistics per PDB

No break down per PDB level at root
In Memory
Statistics
OEM
V$ Views
Background
Processes
SQL*Plus
External Clients
38
AWR for Multitenant (CDB/PDB)

PDB Level AWR Support
AWR
AWR
AWR
AWR
AWR
AWR
PDBs
AWR
CDB
Root
Multitenant Container Database
AWR Enhancements for Multitenant

CDB Level Snapshot Support
PDB Level Snapshot Support
Same functionality as in Oracle Database 12.1
Per PDB AWR with autonomous retention and

snapshot settings
CDB snapshots will be taken at the Root and stored

at the Roots SYSAUX
Same default settings automatic snapshots at

every hour, retention period of 8 days
Performance data for PDB stored in local SYSAUX

Snapshots contains data from PDB level v$ views
Automatic snapshots ON by default
Enhanced content
More PDB-specific stats are collected and exposed
via v$con_sysstats, v$con_sysmetric,
v$con_sys_time_model
Both manual and automatic snapshots supported

Automatic snapshots disabled by default, enable
selectively
40
AWR Support for Remote Snapshots and ADG

Problem
AWR snapshots cannot be taken in a read-only standby environment
Performance monitoring and analysis is limited to basic STATSPACK functionality
Standby workload tuning is not possible as a result
Solution
In Oracle Database 12.2, AWR framework enhanced to support capture of remote
snapshots from any generic database including Active Data Guard (ADG) databases.
A target catalog database collects snapshots from the remote databases (sources)
Snapshots can be collected automatically or manually
AWR tables on the catalog database accumulate snapshot data from all sources via database links
Source databases must be registered on the catalog via new
DBMS_WORKLOAD_REPOSITORY.REGISTER_REMOTE_DATABASE API
41
SQL Tuning Advisor Support for Active Data Guard

Primary
Standby
dblink_to_primary
create tuning task

execute tuning task
report tuning task
implement recommendations
All changes are done on primary and propagated from primary to standby by redo apply
Support for PDB level tuning
The tuning task is executed at the standby, with no CPU overhead in primary
Copyright 2015, Oracle and/or its affiliates. All rights reserved. | 42
Keep Learning with Oracle University
Classroom Training
Cloud
Learning Subscription
Technology
Live Virtual Class
Applications
Training On Demand
Industries
education.oracle.com
43

Maximizing DB Performance - v2

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Maximizing DB Performance - v2

Diunggah oleh

Hak Cipta:

Format Tersedia

Maximizing Database

Prabhaker Gongloor (GP)

Safe Harbor Statement

Oracle Database Performance Tuning Fundamentals

Performance Tuning Methodology

Oracle Database Performance Tuning Fundamentals

Performance Tuning Methodology

Top Database Management Challenges

Rapid diagnoses of database

Identifying application (SQL)

Validating and applying SQL

Oracle Database Performance Tuning Fundamentals

Performance Tuning Methodology

Database Time (DB Time)

DB Time <> response time or elapsed time

Active Session = Session currently spending time in a database call

Average Activity of the Session (% Activity) = The ratio of time active to

= time spent in database

How Does DB Time Work?

= Sum(DB Time) / Elapsed Time

Time t= 2 Active Sessions

What Approach To Use To Identifying Issues?

Active Sessions by wait class over time

DB time increases as system performance degrades

Oracle Database Performance Tuning Fundamentals

Performance Tuning Methodology

Performance Tuning Methodology What Approach to Use?

Proactive Performance Management

Reactive Performance Management

Proactive Performance Management

SQL Performance Analyzer (SPA)

Helps users predict the impact of system

Low overhead capture of SQL workload to

SQL Plans + Stats

SQL Plans + Stats

Integrated with STS, SQL Plan Baselines,

Predict the Impact of Routine System Changes in Production

Testing scoped to private session

Database Replay, Concurrent Replay

Production workload characteristics such as

Test and measure transaction throughput

Perform capacity planning with consolidated

Reactive Performance Management

Identify performance issues using ASH Analytics

Reactive Performance Management

Analyzing transient performance issues using ASH Analytics

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

ASH Analytics identifies User I/O as the problem

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

Diagnose Persistent Performance Issues

Relies on AWR data

Uses a normal and

Reactive Performance Management

Recognizes bad performance trends and triggers analysis

Short duration (5 min spikes) ADDM analysis

Diagnose Hung Database Issues Using Real-Time ADDM

Diagnose SQL Performance using Real-Time SQL Monitoring

Diagnose SQL Performance using SQL Details Active Report

Diagnose Hung Database Issues Using Real-Time ADDM

How To Go About Tuning the Sub-optimal SQL?

Automatic Tuning Optimizer

Recommends SQL profile to compensate for incorrect statistics and transparently

Add Missing Access Structures