SANGAM17 Top Tips Database Performance FINAL

Top Tips for Improving
Database Performance
GP (Gongloor Prabhaker)
Senior Director of Product Management
Oracle Management Cloud, Oracle Corporation
SANGAM17
Dec 9, 2017
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 1
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 Oracle’s products remains at the sole discretion of Oracle.
Program Agenda
1 Introduction
2 Oracle Database Performance Tuning Fundamentals
3 Performance Tuning Tips
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 3
Program Agenda
1 Introduction
Top Challenges: Database Management
52% Rapid diagnoses of database

performance problems
45%
?
Identifying application (SQL)
issues
37 % Validating and applying SQL

tuning solutions
Key Takeaway: Improve & Ensure Higher Quality of Service

Source: THE RAPIDLY ACCELERATING CLOUD-ENABLED ENTERPRISE: 2015 IOUG Survey On Database Manageability
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |

What can cause database performance
to change?
Environment Changes That Affect Performance
• Data growth
• User population growth
• Infrastructure changes
– Server upgrades
– Changes in size or type of disk storage
– Migration to new platforms including migration to
Cloud
• Database Consolidation
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 7
DBA Actions That Affect Performance
• Adding or dropping indexes, partitioning tables,
adding materialized views
• Gathering optimizer statistics
• Modifying init.ora parameters
• Implementing new features such as Compression,
Database In-Memory
• Applying patches – one offs, patch bundles
• Version upgrades or patchsets
Program Agenda
1 Introduction
DB Time
• Total time in database calls by foreground DB Time
sessions
• Includes
– CPU time Wait
– IO time
– Active wait (non-idle wait) time I/O
• Basic unit for Oracle performance analysis
CPU
• Active waits component broken into wait
categories (Application, CPU, IO…)
• Average Active Sessions = Total DB Time/Elapsed
Time
Quiz
True or False:
The maximum DB Time a four CPU system can accumulate in one hour
is four hours of DB Time.
Answer: FALSE
In addition to using CPU, and doing I/O, one or many database

sessions could be in non-idle wait for that one hour. Each of those
sessions would be accumulating DB Time. The database could
accumulate much more than four hours of DB Time in one hour.
Colored Areas in EM = DB Time
• Active Sessions by wait class over time, total area under curve is DB Time
• DB Time distribution should be considered when tuning
• More DB time, more tuning opportunities
• DB time increases as system load increases or system performance degrades
DB Time in AWR Report
• Top 10 events in AWR report are reported in order of DB Time, descending

• TIP: To improve database performance, focus on:
• Reducing the highest DB Time events which can be done with the least effort
Program Agenda
1 Introduction
Tips on Reading an AWR Report
Tips On Reading An AWR Report
• Tip:
– Check operating system level first – verify not maxed out on CPU
– DB Time is inflated when CPU bound
Recorded wait time Recorded wait time

User 1
Run-queue Run-queue
Db file sequential read On CPU Db file sequential read On CPU
Actual wait time Actual wait time
Quiz: Which regions / page has above information for maxed out CPU?
• For a basic understanding of the database and environment – check the top
of the report:
– DB Time vs elapsed time
– Number of CPUs and cores
– Amount of memory
– Number of database sessions
• Read the ADDM findings at the top of the report – ADDM report
automatically included starting with database 12
• Look at the full ADDM report at the end of the AWR report
• Identifies top DB Time targets for tuning
• Tip: ADDM specifies subsystems that are not a problem, e.g. network, interconnect
• Look at 10 top timed events section, focus on highest DB Time that can be
reduced with least effort
• Review top SQL sections based on top 10 events. Identify top SQL
candidates for tuning:
– If CPU is a top event, look at top SQL by CPU section
– If I/O is a top event, look at top SQL by I/O section
– If wait events are top events, look at SQL by elapsed time section
– Frequently the same SQL will show up in one or more of these sections
• Review the database parameters section

• Tip: Best practice is to have as few non-default database parameters set
as possible
– Minimizing non-default parameters means will execute most common code path –
most optimized, fewest potential issues
– Underscore parameters particularly suspect
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
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 23

Tip: How to Generate Performance Hub Report
• Performance Hub report generated from

SQL*Plus:
– @$ORACLE_HOME/rdbms/admin/perfhubrpt.sql
OR calling dbms_perf.report_perfhub(….)
function
• Performance Hub appended to AWR
report:
– @$ORACLE_HOME/rdbms/admin/awrrpt.sql
– Choose ‘active-html’ report
• Tip: Use this next generation AWR report!

Generating Perfhub Report command line
• @?/rdbms/admin/perfh
ubrpt.sql
– Prompted for type of
report (typical, basic, all,
…), DB ID, Instance
number, etc.
– Time range (not snapshots)
Demo
Perfhub Report
Tips on Assuring Performance During
Routine System Changes
Proactive Performance Management: SPA Quick Check
• Helps users predict the impact of routine
system changes on production SQL
workload SQL Plans + Statistics SQL Plans + Statistics
• Low overhead capture of SQL workload to

SQL Tuning Set (STS)
Pre-change Trial Post-change Trial
• Build different SQL trials (experiments) of
SQL statements performance by test Compare SQL
Performance
execution or explain plan
• Day to day use cases integrated with SPA
Quick Check, SQL Plan Baselines, & SQL
Tuning Advisor to form an end-to-end
solution Analysis Report
Proactive Performance Management
Predict the impact of routine system changes on SQL workload response time
• Optimized
– Optimized for use on prod systems SPA Quick Check
– Optimal Trial or Explain Plan mode
– Disable multi-executions, full DML execute disabled
Per SQL Time Limits,
Optimal Trial
• Controlled
Limits testing scope to
Mode, no DML Controlled/Sc
private session
execute Optimized oped
– Per SQL time limits

– Testing scoped to private session Change-Aware Context-aware
change testing
– Associate with Resource Consumer Group
• Change-Aware Production
Database
Pre-selected
– Context-aware change testing workflows, such as, STS and
default SPA
– Optimizer gather statistics settings
DBA
– Init.ora parameter changes
Proactive Performance Management
Predict the impact of system changes on SQL workload response time
3
2
5
1
4
Demo
SQL Performance Analyzer
New in
SPA - Concurrent SQL Execution 18.1
• SPA trials are currently executed serially one statement at a time
– This can lead to long tests when SQL Tuning Sets contain a large number of
statements. For example, EBS suite may have 1 million unique SQL statements
• Concurrent SQL execution within a SPA trial reduces duration to complete
the trial, therefore reduces testing time
– User specifies degree of parallelism with SPA parameter TEST_EXECUTE_DOP
– For example, a SQL Tuning Set with 125,000 statements reduced testing from
12.5 hours to 2 hours with a degree of parallelism of 8
• Tip: Use SPA concurrent SQL execution in test environment for STS with a
large number (thousands or higher) of SQL statements
New in
SPA – Result Set Validation 18.1
• Result set validation required for certain environments – e.g. government
drug research trials, pharma industries, etc. An additional assurance SQL
produces correct results with new environment / software
• SPA report can be generated for before and after change trials comparing
whether identical result sets were produced
• SPA result set validation uses generated hash key to compare result sets in
two trials
– Enabled with SPA parameter COMPARE_RESULTSET
• Tip: Run before and after trials with exact same dataset for result set
validation
• If result sets differ with same input dataset – contact Oracle Support
Tips on SQL Tuning and Exadata
Reactive Performance Management
How to go about tuning the sub-optimal SQL?
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
SQL Restructure Analysis Execution Plan
Alternative Plan Analysis Create Parallel SQL Profile

SQL Tuning Administrator
Parallel Query Analysis Advisor
Comprehensive SQL Tuning Recommendations

Automatic Tuning Optimizer
• Gives recommendations on various problems found during analysis phase

• Uses the same CBO but has more time budget for comprehensive analysis
• Identifies alternate execution plans using real time and historical performance data
• Recommends SQL profile to compensate for incorrect statistics and transparently improve
performance
Tip: SQL Tuning Advisor – Choose Highest DB Time, Most Targeted
Improvement Recommendation
• SQL Tuning Advisor provides DB Time improvement benefits for its recommendations
• Choose the highest DB Time, most targeted recommendation
• SQL Profile affects single statement
• Index could affect entire workload – requires additional validation (SQL Access Advisor)
NEW IN
SQL Tuning Advisor Exadata Enhancement 18.1
• SQL Tuning Advisor detects if SQL is executing on

Exadata
• SQL Tuning Advisor gathers system statistics in a private
session and does analysis with and without these
statistics
• If a better execution plan is found with these system
statistics, an Exadata aware SQL Profile will be
recommended
• Can result in 10x or better performance improvement
for SQLs which can benefit from Exadata hardware - e.g.
cell smart scans
NEW IN
SQL Tuning Advisor Exadata Enhancement 18.1
Without Exadata aware SQL Profile – 1.9 minutes:
With Exadata aware SQL Profile – 13 seconds:
Tips on Tuning Multitenant Databases
AWR and Multitenant: Pre-DB 11.2 Architecture and
Limitations
• Single AWR repository per database AWR Architecture (pre-DB12.2)
– For non-CDB resides in SYSAUX
Internal Clients
– For CDB resides in Root’s SYSAUX (12.1)
Self Tuning
ADDM
• AWR does not have notion of AWR
Components
data for a PDB (no Top N per PDB) Foreground

In Memory Processes
• Partial AWR statistics Automatic Workload

MMON Process Statistics
Repository (AWR)
SGA
– Missing Time-Wait model, sysmetrics statistics Background
Processes
DBA_HIST Views V$ Views
per PDB
– No break down per PDB level at root
OEM SQL*Plus
• AWR data not transportable along
External Clients
with PDB
Solution: New AWR Architecture for Multitenant (DB 12.2)
Per-PDB AWR Support
AWR AWR
AWR
AWR AWR AWR PDBs

CDB
Root
AWR
Multitenant Container Database
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |

AWR Enhancements for Multitenant (DB12.2)
• CDB Level Snapshot Support • PDB Level Snapshot Support
• Same functionality as in Oracle Database 12.1 • Per PDB AWR with autonomous retention and
– CDB snapshots will be taken at the Root and stored snapshot settings
at the Root’s SYSAUX • Performance data for PDB stored in local SYSAUX
– Same default settings – automatic snapshots at – Snapshots contains data from PDB level v$ views
every hour, retention period of 8 days
– Automatic snapshots ON by default • Both manual and automatic snapshots supported
– Automatic snapshots disabled by default, enable
• Enhanced content selectively
– More PDB-specific stats are collected and exposed
via v$con_sysstats, v$con_sysmetric, • Tips:
v$con_sys_time_model – Enable AWR at PDB level for diagnosing
performance for key databases
– For large #PDBs exercise caution
Tips on Tuning Active Data Guard
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
• 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
Remote Snapshot Configuration for ADG Database
ADG Reader Farm
Primary Active Data Guard 3. Define the source databases
Local AWR Data
Source databases
Remote AWR Data
4. Define the target database
Catalog database
5. Create the topology
6. Register the source databases
7. Register the source databases for AWR service
SQL Tuning Advisor Support for Active Data Guard
• Problem
– ADG databases are widely used to offload reporting or ad hoc query-only jobs from
primary
– Reporting workload profile is different from primary and often requires tuning
• Solution
• Oracle Database 12.2 introduces the ability to tune SQLs workloads running on ADG database
• All SQL Tuning Advisor tasks issued at the standby
– Create tuning task, execute tuning task and implement SQL Profile recommendations can be run on standby
– Test execution (heavy lifting) happens on standby, only minimal write related activity on primary
• The required data for the above tasks are fetched from primary over a database link from standby
• Task details and tuning results are stored at primary and the essential data required to construct the
report is accessed remotely from primary
• The report is constructed locally at the standby, with no CPU overhead in primary
SQL Tuning Advisor Support for Active Data Guard
Primary Standby
create tuning task
execute tuning task
report tuning task
dblink_to_primary 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

Tips on Troubleshooting a Hung Database
Diagnose persistent performance issues
Compare Real-Time Enhanced

ADDM Period ADDM ADDM Real-Time
ADDM
• Diagnose persistent • In-depth • Hung or extremely • Proactively detect
performance issues performance slow databases & diagnose
comparison across transient high-
• Analyzes AWR two periods • Uses a normal and impact problems
snapshots diagnostic mode
• Relies on AWR data connection • Built inside the DB
• Regular interval
• Manual • Manual • Automatically runs
• Automatic / Manual every 3 seconds
• 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
Tip: 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
Tip: 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
Summary
• To improve database performance, reduce DB Time
• Use automated tools such as SQL Performance Analyzer and SQL Tuning
Advisor to maximize productivity
• Use Real-Time ADDM to troubleshoot hung databases
• Use AWR and Perfhub for in-depth performance analysis

SANGAM17 Top Tips Database Performance FINAL

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SANGAM17 Top Tips Database Performance FINAL

Caricato da

Copyright:

Formati disponibili

Top Tips for Improving

52% Rapid diagnoses of database

37 % Validating and applying SQL

Key Takeaway: Improve & Ensure Higher Quality of Service

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

In addition to using CPU, and doing I/O, one or many database

• Top 10 events in AWR report are reported in order of DB Time, descending

Recorded wait time Recorded wait time

Actual wait time Actual wait time

• Review the database parameters section

• Single view of DB performance

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 23

• Performance Hub report generated from

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 24

• Low overhead capture of SQL workload to

– Per SQL time limits

Alternative Plan Analysis Create Parallel SQL Profile

Comprehensive SQL Tuning Recommendations

• Gives recommendations on various problems found during analysis phase

• SQL Tuning Advisor detects if SQL is executing on

With Exadata aware SQL Profile – 13 seconds:

data for a PDB (no Top N per PDB) Foreground

• Partial AWR statistics Automatic Workload

AWR AWR AWR PDBs

Multitenant Container Database

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

Primary Active Data Guard 3. Define the source databases

Local AWR Data

7. Register the source databases for AWR service

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 47

Compare Real-Time Enhanced

• Identify the problem area

Potrebbero piacerti anche