An

Embarcadero Oracle Community Webinar

Diagnosing SQL Performance Problems

Karen Morton Sr. Technical Consultant

karen.morton@enkitec.com karenmorton.blogspot.com karen_morton

July 31 Diagnosing SQL Performance Problems August 29 Making SQL Performance SoluGons SGck September 26 Making ImpacLul Performance Changes
3

When somethings on re, what do you do?

Put. It. Out.

5

Time is a luxury.

Plan of AWack
Evaluate the situaGon
Gather data & determine problem scope

Propose & eliminate (postpone) opGons

Are there any quick xes?

Implement best opGon

Best = quickest alternaGve to achieve correcGon

Validate soluGon

What alerted the issue?

User complaints may or may not be obvious in monitoring tools.

How do you monitor and analyze database acGvity?

10

Do you have licenses for ASH & AWR use? If not, do you use S-ASH or rd party product? Statspack or 3
S-ASH is simulated ASH (homegrown or see www.ashmasters.com).
11

Remember: DiagnosGc & Tuning Packs needed to legally use ASH/AWR.

What is included with various Oracle Management Packs? hWp://docs.oracle.com/cd/E11882_01/license.112/e10594/opGons.htm#CIHIHDDJ

12

Top SQL (by elapsed Gme)

13

Top SQL (ASH)

14

Evaluate the SituaGon

Determine if stress inside or outside the database
OS resources? Network resources? Storage resources?
SAN Admins Net Admins Developers OS Admins Managers Users DBAs

Get an accurate descripGon of the problem

What is the problem scope? What is the expected vs current response Gme(s)? Does the problem occur randomly or repeatedly? What has changed?
15

But

Nothing

has changed!

16

If

nothing changed,

why is something dierent?

17

Ch-ch-ch-ch-changes
homage to David Bowie

StaGsGcs
Data volume Data distribuGon

Cardinality feedback Parameters Outside the database

SQL is not likely the problem if the change is outside the database.
18

SQL Problem?

Same execuGon plan on both nodes.

19

Outside the Database?

21

StaGsGcs?
update set where and t_cust_acct_offr_pndg_trckg! prcss_flg = Y! bat_job_exec_trckg_id = :B1! cust_acct_offr_trckg_id = :B2 ;!

Unique index available on these columns

Process would execute this update over 1.5 million Gmes. Total esGmated Gme to complete ~ 500 hours. Logical IO per second over 111K

22

Aser stats collected, job completed in 40 minutes.

Response Gme for single execuGon dropped from 1.3 to .002 seconds. Logical IO per second dropped from over 111K to 933.
23

Stats collected at 1% using FOR ALL COLUMNS SIZE 254

24

Aser stats re-collected, response Gme dropped from 43 minutes to .01 second.
LIO dropped from 4.6 million to 4

Stats re-collected with auto_sample_size using FOR ALL COLUMNS SIZE AUTO
25

Other staGsGcs issues

Collect too frequently
Even minor change can result in big plan changes

Collect too many histograms (or not enough)

Columns with hundreds of disGnct values

Dynamic sampling disabled

Defaults used

26

Quick StaGsGcs Fixes

Collect on needed objects
!dbms_stats.gather_table_stats!

Revert to previous stats

dbms_stats.restore_table_stats!

27

Cardinality Feedback
Compares cardinality esGmates to actual row counts If enough dierence found, opGmizer applies fudge factor to correct the esGmate
OPT_ESTIMATE hint

SomeGmes esGmates improve but response Gme decreases Controlled by _optimizer_use_feedback!

See hWp://kerryosborne.oracle-guy.com/2011/07/cardinality-feedback/
28

Cardinality Feedback!

Example

29

Unstable Plans (AWR)

30

Quick CF Fixes
Turn o CF (session or instance level)
!_optimizer_use_feedback = FALSE!

Use SQL Prole to replace bad plan with good ! Use hint on single SQL
select /*+ opt_param(_optimizer_use_feedback false) */ !
31

Parameters
opGmizer_index_cost_adj opGmizer_index_caching db_le_mulGblock_read_count pga_aggregate_target cursor_sharing

Watch out for hidden parameters that have been changed!

32

Quick Parameter Fixes

Just say No!
Only change a parameter aser careful and comprehensive tesGng

Set back to default Use SQL Prole to replace bad plan with good ! Use opt_param hint for individual SQL to override eects if possible
33

How SQL is wriWen is not typically the problem when performance degrades without a plan change.

Check AWR or Statspack history to determine if plan changed.

34

Check AWR for ExecuGon Info

35

3 Most Common Rewrite Reasons

Query transformaGon problems Datatype oddiGes or complex expressions Procedural vs set-based approach

37

Query TransformaGon
Developers usually write SQL in style simplest to understand
Not necessarily the most ecient

Oracle rewrites SQL for beWer performance TransformaGons can be seen in the execuGon plan (reverse engineer the plan to the SQL) TransformaGon benets can be prevented or reduced by certain techniques
DISTINCT, GROUP BY, outer joins, etc
38

Datatypes & Expressions

Choosing the wrong datatype for a column
SQL> select '20111231' - '20111201' from dual ; ! SQL> select '20120102' - '20111231' from dual ; ! SQL> select to_date('20120102','yyyymmdd') ! to_date('20111231','yyyymmdd') from dual ; ! 30! 8871!

! 2!

Using complex expressions in predicates with/ without proper indexing (FBI)

WHERE my_func1(my_func2(col)) = col . . .! !
39

Procedural SQL
Access same table twice

List of employees who spent the same number of years in each job they held.
40

Set-based SQL
Single table access

41

Stop thinking row-by-row!

42

Recap
If the problem is outside the database, SQL is rarely the main problem StaGsGcs (plan changes) are the prime culprit if SQL performance goes from good to bad Find what changed! Try to keep instance parameters at defaults
43

Recap
When wriGng SQL
Think like the opGmizer (try to avoid query transformaGon piLalls) Use proper datatypes Watch out for complex expressions Think in sets!

44

Q & A
45

Thank you!