Sie sind auf Seite 1von 38

1

Novices
SQL Tuning for Smarties, Dummies and Everyone in Between
Jagan Athreya
Director, Database Manageability, Oracle

Arup Nanda
Senior Director, Database Architecture, Starwood Hotels and Resorts

2
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,
development release
release, and timing of any
features or functionality described for Oracle’s
products remains at the sole discretion of Oracle.

3
Outline

• SQL Tuning
g Challenges
g

• SQL Tuning Solutions – New Feature Overview

• Problem Root Causes and their Solutions

• Preventing SQL Problems

• Q&A

4
SQL Tuning Challenges
Real-world DBA and Development Teams

• DBA team
– Mostly average, some superstars
– Superstars take most of the burden – over-stretched

• Development staff
– Mostlyy non-Oracle skills – Java,, C++
– Usually considers the DB as a “black box”
– Writing efficient queries, troubleshooting performance issues
is delegated to DBAs

5
SQL Tuning Challenges
Production Performance

• Situation:
– Query from hell pops up
– Brings the database to its knees
– DBA is blamed for the failure
• Response
– DBA: “Developer should be taking care of this.”
– Developer: “Why is the DBA not aware of this problem?”
– Manager: “DBA will review all queries and approve them.”
• Challenge
– What is the most efficient way to manage this process?

6
SQL Tuning Challenges
Change Causing Problems

• Situation
– New SQL statements added as part of application patch
deployment
– Database upgrades
– Database patching
• Response
– Users: “How will the application perform after the changes?”
– DBA: “How do I ensure that our SLA remains intact after the
changes are rolled out?”
• Challenge
– How to reduce business risk while absorbing new
technologies?

7
SQL Tuning Challenges
Optimizer Statistics Management

• Situation
– Data in Production has evolved over time. Have the optimizer
statistics stayed current?
• Response
DBA:
– Will statistics refresh break something?
– What will happen if we don’t collect?
– How often should I collect the statistics ?
– What happens
pp when yyou collect a new set?
• Challenge
– What is the recommended strategy for managing optimizer
statistics to ensure the best performance?

8
SQL Tuning Challenges
Bad Plans – Diagnosis and Resolution

• No time to find the root cause. How to prevent this


from recurring?
• Bind variables: How do you prevent bad plans based
on choice of bind variables?
• How to diagnose a bad plan
– 10053 trace,, endless pouring
p g over traces
– Wrongly constructed predicates
• How to fix a bad plan
– Hi
Hints?
t ? change
h off code?
d ?
– Baselines vs. SQL Profiles
– Pick out a single SQL or a bunch from the shared pool

9
Outline

• SQL Tuning
g Challenges
g

• SQL Tuning Solutions – New Feature Overview

• Problem Root Causes and their Solutions

• Preventing SQL Problems

• Q&A

10
Real-Time SQL Monitoring
Lookingg Inside SQL Execution
• Automatically monitors long
running SQL

• Enabled out-of-the-box with no


performance overhead

• Monitors each SQL execution

p
• Exposes monitoringg statistics
– Global execution level
– Plan operation level
– Parallel Execution level

• Guides tuning efforts

11
New capabilities in SQL Monitoring
New in Oracle Database 11gg Release 2

• PL/SQL monitoring including associated high load SQL monitored recursively


• Exadata aware I/O p performance monitoring g and associated metric data
• Capture rich metadata such as bind values, session details e.g. user,
program, client_id and error codes and error messages
• Save as Active Report for rich interactive offline analysis

12
DEMO

13
Application Tuning
Automatic SQL Tuning Well-Tuned SQL

Packaged Apps +
SQL Profile
High-Load
Customizable
C t i bl Apps
A +
SQL Advice

Customizable Apps +
Indexes & MVs +
Partitions
Applications

Automatic Tuning Optimizer

• Automatic SQL Tuning


• Identifies high-load SQL from AWR
• Tunes SQL using g SQL Profiles
• Implements greatly improved SQL plans (optional)
• Performance benefit of advice provided
• SQL Profiling tunes execution plan without changing SQL text
• Enables transparent tuning for packaged applications

14
Automatic SQL Tuning
New in Oracle Database 11g Release 2
Gather Missing or Stale
Statistics
C
Create
t a SQL Profile
P fil
SQL Profiling
Add Missing Access
Statistics Analysis
Structures
Access Path Analysis
Modify SQL Constructs
SQL Restructure Analysis
Adopt Alternati
Alternative
e
Alternative Plan Analysis Execution Plan
SQL Tuning Administrator
Parallel Query Analysis Advisor Create Parallel SQL
Profile
Comprehensive
Automatic Tuning
SQL Tuning
Optimizer
Recommendations

• SQL Tuning Advisor


• NEW: Identifies alternate execution plans using real-time
real time and historical
performance data
• NEW: Recommends parallel profile if it will improve SQL performance
significantly (2x or more)

15
SQL Tuning for Developers
Integration with Visual Studio
• Introduced in Oracle Developer Tools for Visual Studio Release 11.1.0.7.20
• Oracle Performance Analyzer
– Tune running applications with the help of ADDM
• Query Window
– Tune individual SQL statements with STA
• Server Explorer
– Manage AWR snapshots and ADDM tasks

16
Agenda

• SQL Tuning
g Challenges
g

• SQL Tuning Solutions – New Feature Overview

• Problem Root Causes and their Solutions

• Preventing SQL Problems

• Q&A

17
What makes SQL go bad?
Root Causes of Poor SQL Performance
1. Optimizer statistics issues
a. Stale/Missing statistics
b. Incomplete statistics
c. Improper optimizer configuration
d. pg
Upgraded database: new optimizer
p
e. Changing statistics
f. Rapidly changing data
2. Application Issues
a. Missing
Mi i access structures
t t
b. Poorly written SQL statements
3. Cursor sharing issues
a. Bind-sensitive SQL with bind peeking
p g
b. Literal usage
4. Resource and contention issues
a. Hardware resource crunch
b
b. C t ti ((row llock
Contention k contention,
t ti bl
block
k update
d t contention)
t ti )
c. Data fragmentation
5. Parallelism issues
a. Not p
parallelized ((no scaling
g to large
g data))
b. Improperly parallelized (partially parallelized, skews)

18
What makes SQL go bad?
Root Causes of Poor SQL Performance

1. Optimizer statistics issues


a. Stale/Missing statistics
b. Incomplete statistics
c. Improper optimizer configuration
d. Upgraded database: new optimizer
e. Changing
g g statistics
f. Rapidly changing data
2. Application Issues
3. Cursor sharing issues
4. Resource and contention issues
5. Parallelism issues

19
Oracle Optimizer Statistics

Inaccurate statistics Suboptimal Plans

Optimizer Statistics
• Table Statistics
CBO
• Column Statistics

• I d Statistics
Index S i i

• Partition Statistics

• System Statistics

20
Oracle Optimizer Statistics Novice
Preventing SQL Regressions Mode

• Automatic Statistics Collection Job (stale or


g)
missing)
• Out-of-the box, runs in maintenance window
• Configuration can be changed (at table
level)
• Gathers
G th statistics
t ti ti on user andd dictionary
di ti
objects
• Uses new collection algorithm with Nightly
accuracy of compute and speed faster than
sampling of 10%
• Incrementally maintains statistics for
partitioned tables – very efficient
• Set DBMS_STATS.SET_GLOBAL_PREFS

21
Oracle Optimizer Statistics Expert
Mode
Preventing SQL Regressions

• Extended Statistics
• Extended Optimizer Statistics provides a mechanism
to collect statistics on a group of related columns:
• Function-Based Statistics
• Multi-Column Statistics
• Full integration into existing statistics framework
• Automatically maintained with column statistics
DBMS_STATS.CREATE_EXTENDED_STATS
• Pending Statistics
• Allows validation of statistics before publishing
• Disabled by default
• To enable,, set table/schema PUBLISH setting g to FALSE
DBMS_STATS.SET_TABLE_PREFS('SH','CUSTOMERS','PUBLISH','false')
• To use for validation
ALTER SESSION SET optimizer_pending_statistics = TRUE;
• Publish after successful verification

22
What makes SQL go bad?
Root Causes of Poor SQL Performance

1. Optimizer statistics issues


2. Application Issues
a. Missing access structures
a
b. Poorly written SQL statements
3. Cursor sharing issues
4
4. Resource and contention issues
5. Parallelism issues

23
Identify performance problems using ADDM
Automatic Database Diagnostic Monitor
Novice
M d
Mode

• Provides database and


cluster-wide performance
diagnostic
• Throughput centric - Focus
on reducing g time ‘DB time’
• Identifies top SQL:
• Shows SQL impact
• Frequency of
occurrence
• Pinpoints root cause:
– SQL stmts waiting for
Row Lock waits
– SQL stmts not shared

24
Identify High Load SQL Using Top Activity
Novice
Performance Page M d
Mode
• Identify Top SQL by DB Time:
• CPU
• I/O
• Non-idle waits
• Different Levels of Analysis
y
Top Activity • Historical analysis
• AWR data
• Performance Page g
• Real-time analysis
• ASH data
• More g granular analysis
y
• Enables identification of
transient problem SQL
• Top Activity Page
• Tune using SQL Tuning Advisor

25
Advanced SQL Tuning Novice+
Universe of Access Structures Mode

• Indexes: B-tree indexes, B-tree cluster indexes, Hash cluster indexes, Global
and local indexes, Reverse key indexes, Bitmap indexes, Function-based
indexes, Domain indexes

• Materialized Views:
Primary Key materialized views,
Object materialized views
ROWID materialized views
Complex materialized views

• Partitioned Tables:
Range partitioning, Hash partitioning,
List partitioning, Composite partitioning,
Interval Partitioning
Partitioning, REF partitioning
partitioning,
Virtual Column Based partitioning
B-tree index

26
Novice+
SQL Access Advisor: Partition Advisor Mode

Indexes

Materialized
Representative SQL Access
Workload Advisor views

Automatic Tuning
Optimizer
Materialized
views logs
Access Path
Analysis

Partitioned
objects

27
SQL Access Advisor Expert
Advanced Options Mode

• Workload filtering
• Limited vs. advanced mode
• Tablespaces for access structures
• Hypothetical workload tuning
• Factoring in the cost of creation
• Space limitations for indexes and MVs

28
What makes SQL go bad?
Root Causes of Poor SQL Performance
1.
1 Optimizer
O ti i statistics
t ti ti issues
i
2. Application Issues
3. Cursor sharing issues
a. Literal usage
a
b. Bind-sensitive SQL with bind peeking
4. Resource and contention issues
5. Parallelism issues

29
What makes SQL go bad? Expert
a. Literal Usage Issue Mode

SELECT * FROM jobs WHERE min_salary > 12000;


SELECT * FROM jobs WHERE min_salary > 15000;
SELECT * FROM jobs WHERE min_salary > 10000;

SELECT * FROM …
SELECT * FROM …
cursor_sharing ={exact, force, similar}
SELECT * FROM …

Sharing
Sh i
Cursors
is good!
Library Cache

30
What makes SQL go bad? N
b. Bind Peeking Issue Mode
Processed_Flag
Y
Y Full Table Scan
Y FTS

Y CBO10g

Two different optimal plans


for different bind values
99

Index Range Scan


IRS

1 N
Problem: Binds will affect optimality in any subsequent uses of the stored plan

31
Fixing problems with Adaptive Cursor Sharing
Adaptive Cursor Sharing Expert
Mode
SELECT * FROM emp WHERE wage := wage_value

Selectivity Ranges:

1
20 25
Same
2 Plan

22 24
3 Different
Plan

30 35
Same
4 Plan,
Expand
Interval
34 43

32
Agenda

• SQL Tuning
g Challenges
g

• SQL Tuning Solutions – New Feature Overview

• Problem Root Causes and their Solutions

• Preventing SQL Problems

• Q&A

33
Preventing problems with SQL Plan Management

• Problem: changes in the GB

environment cause plans to change Parse


NL

NL

• Plan baseline is established

Statement log
• SQL statement is parsed again and
a different plan is generated Plan history
GB Plan baseline
NL
GB
NL

• New plan is not executed but HJ

marked
k d ffor verification
ifi ti HJ

34
SQL Plan Management
Migration of Stored Outlines to Plan Baselines

Oracle Database 11g


Plan History OH Schema
GB 5. Migrate Stored Outlines
GB
HJ into SPM GB
HJ
HJ HJ
HJ
HJ

No plan
regressions
Oracle Database 11g
4. Upgrade
to 11g

1 B
1. Begini CREATE_STORED_OUTLINES=true
with OH Schema

2. Run all SQL in the GB


Application and auto HJ
create
t a St
Stored
d Outline
O tli HJ
for each one
3. After Store
Outlines are CREATE_STORED_OUTLINES=false
captured Oracle Database 9 or 10g

35
SQL Performance Analyzer (SPA)
Validate statistics refresh with SPA

• Steps: Validating upgrade with SPA


SQL Workload

1. Capture SQL workload in STS


using automatic cursor cache
capture capability
2. Execute SPA pre-change trial SQL plans + stats SQL plans + stats
3. Refresh statistics using
Pre change Trial
Pre-change Post change Trial
Post-change
PENDING optioni
4. Execute SPA post-change trial
5. Run SPA report comparing SQL
Compare
execution statistics
SQL Performance

• Before PUBLISHing stats:


• Remediate individual few SQL Q Analysis Report
for plan regressions: SPM, STA
• Revert to old statistics if too
many regressions observed

36
Conclusion
Identify, Resolve, Prevent
1. Production Performance Prevent
2. Change Causing Problems SPA

3. Optimizer Statistics Management SPM

4
4. B d plans
Bad l – Diagnosis
Di i and
dRResolution
l ti

Resolve
ADDM, Top Activity, SQL Monitoring

Tuning Advisor
Advisor,

Top Activity, Access Advisor,


Identify ADDM, Auto Stat Collection

SQL Monitoring

37
38

Das könnte Ihnen auch gefallen