Are you a monkey or an

astronaut?

The Oracle Advisors from

a different perspective.

Karen Morton karen.morton@method-r.com

Your speaker…

• Karen Morton

– Educator, DBA, developer,

consultant, researcher, author, speaker, …

– Director

– Software, education, consulting

• Come see us…

– method-r.com

– karenmorton.blogspot.com

– An Oracle user group near you

Committed to genuinely satisfying software performance

Agenda

• Introduction

• The “Self-Managing” Database

• Before and After

• What do we really want?

• When the Advisors mislead

• It takes human intelligence

• Conclusion

• Q&A

It is impossible to underrate

human intelligence – beginning

with one’s own.

Henry Brooks Adams

Introduction

Do you remember?

What about these guys?

Monkeys were first

Are you a monkey?

Or, are you an astronaut?

The Self-Managing

Database

The Oracle Advisors

Database performance optimization is a “complex, time consuming task and

requires expensive specialist consulting skills” to perform

Performance diagnosis and tuning is mostly about following a logical, methodical approach. Fortunately computers are pretty good at that!

Graham Wood & Kyle Hailey

What role will we choose and

what is the risk?

The system is slow!

Please fix it now!

DBAx

x

How would you diagnose the problem?

1) Check server to determine if adequate resources are available

2) Check database and notice many sessions are waiting on “latch free” waits

3) Drilling down into latches shows most are on “library cache” and “shared pool” latches

4) From knowledge, experience and reference books, you know these latches are associated

with hard parsing issues

5) Double-check the hypothesis that hard parsing is the problem by looking at

the rate at which “parse time elapsed” and “parse time cpu” are increasing

6) Now determine if one or more sessions are responsible for the majority of the hard

parses or check shared pool for existence of many similar statements with the

same SQL plan

7) By looking at the shared pool, you find there are a small number of plans each of which

has many different SQL texts associated with it (they differ only by a literal)

8) Now the problem is identified and you can move on to fixing it

With ADDM, how would the problem have been diagnosed?

SQL statements were not shared due to usage of literals. This resulted in additional hard parses which were consuming significant database time.

ADDM says…

ADDM recommends…

ACTION: Investigate application logic for possible use of bind variables instead of literals. Alternatively, you may set the parameter CURSOR_SHARING to FORCE.

…because…

RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033 were found to be using literals. Look in V$SQL for examples of such SQL statements.

Without ADDM

• Multiple investigative steps must be

completed

• Must have knowledge of what latch

free waits indicate

• Must locate the problem SQL

• Requires executing queries against

database that add overhead to the system

With ADDM

• Consult the latest ADDM report

• No mention of latching at all in the

report

• Exact SQL identified with

PLAN_HASH_VALUE

• No additional overhead needed as

report is based on previously collected snapshot data

Given this example, which method of diagnosis would you prefer?

ADDM did a great job!

Who wouldn’t want to spend less time getting to the root

cause of a problem?

But…

Could you have diagnosed the problem without ADDM?

If you could have diagnosed the problem, would using ADDM

have been quicker (and therefore, better)?

What would you have done if you fixed the problem as described

by ADDM, but the user says “it’s still slow”?

Instead of using the human brain, humans have created another brain to do the job. There is nothing around us that is not built to cater to the needs of the human race and to ease off the duties of what the human brain is supposed to do; for instance, thinking. Is laziness going to be the death of the human race?

Kurt Vonnegut

What do we really want?

A magic formula?

A checklist, a “how-to”, a tool or some secret parameter?

alter system set fast = true;

What most people really want is knowledge and experience

…that allows us to confidently approach a problem and

solve it efficiently

We want training that teaches us how and why things work as they do

…and teaches us how to “know” what to do and how to do it

when problems arise

The part of intuition that involves pattern matching and recognition of familiar and typical cases can be trained. If you want people to size up situations quickly and accurately, you need to expand their experience base. One way is to arrange for a person to receive more difficult cases.

Gary Klein

…or simply have them become an Oracle DBA or developer.

When the advisors

mislead

What would you do if the problem isn’t resolved via the advisors?

The advisors aren’t true artificial intelligence

They can only pattern match, aggregate and assimilate answers based on programmed heuristics

They can only suggest solutions within a realm of known

(i.e. built-in) possibilities

They can’t rewrite code

They can miss something or “get it wrong”

It takes human intelligence

SQL Tuning Advisor vs. Human

Example

So, how did the SQL Advisor do?

Let’s compare using AUTOTRACE

Elapsed: 00:00:01.51 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 160 | 2560 | 191 (78)| 00:00:03 | | 1 | SORT UNIQUE | | 160 | 2560 | 191 (78)| 00:00:03 | | 2 | UNION-ALL | | | | | | |* 3 | FILTER | | | | | | | 4 | HASH GROUP BY | | 10 | 160 | 48 (11)| 00:00:01 | |* 5 | HASH JOIN OUTER | | 12890 | 201K| 44 (3)| 00:00:01 | | 6 | INDEX FAST FULL SCAN| CUST2_PK | 1000 | 5000 | 2 (0)| 00:00:01 | | 7 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 8 | FILTER | | | | | | | 9 | HASH GROUP BY | | 50 | 800 | 48 (15)| 00:00:01 | | 10 | NESTED LOOPS | | 12890 | 201K| 44 (7)| 00:00:01 | | 11 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 12 | INDEX UNIQUE SCAN | CUST2_PK | 1 | 5 | 0 (0)| 00:00:01 | |* 13 | FILTER | | | | | | | 14 | HASH GROUP BY | | 50 | 800 | 48 (15)| 00:00:01 | | 15 | NESTED LOOPS | | 12890 | 201K| 44 (7)| 00:00:01 | | 16 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 17 | INDEX UNIQUE SCAN | CUST2_PK | 1 | 5 | 0 (0)| 00:00:01 | |* 18 | FILTER | | | | | | | 19 | HASH GROUP BY | | 50 | 800 | 48 (15)| 00:00:01 | | 20 | NESTED LOOPS | | 12890 | 201K| 44 (7)| 00:00:01 | | 21 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 22 | INDEX UNIQUE SCAN | CUST2_PK | 1 | 5 | 0 (0)| 00:00:01 | --------------------------------------------------------------------------------------

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

39419 consistent gets

0 physical reads

0 redo size

26289 bytes sent via SQL*Net to client

1107 bytes received via SQL*Net from client

68 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

1000 rows processed

Elapsed: 00:00:01.50 ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 160 | 2560 | 184 (77)| 00:00:03 | | 1 | UNION-ALL | | | | | | |* 2 | FILTER | | | | | | | 3 | HASH GROUP BY | | 10 | 160 | 46 (7)| 00:00:01 | |* 4 | HASH JOIN OUTER | | 12890 | 201K| 44 (3)| 00:00:01 | | 5 | INDEX FAST FULL SCAN| CUST2_PK | 1000 | 5000 | 2 (0)| 00:00:01 | | 6 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 7 | FILTER | | | | | | | 8 | HASH GROUP BY | | 50 | 800 | 46 (11)| 00:00:01 | | 9 | NESTED LOOPS | | 12890 | 201K| 44 (7)| 00:00:01 | | 10 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 11 | INDEX UNIQUE SCAN | CUST2_PK | 1 | 5 | 0 (0)| 00:00:01 | |* 12 | FILTER | | | | | | | 13 | HASH GROUP BY | | 50 | 800 | 46 (11)| 00:00:01 | | 14 | NESTED LOOPS | | 12890 | 201K| 44 (7)| 00:00:01 | | 15 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 16 | INDEX UNIQUE SCAN | CUST2_PK | 1 | 5 | 0 (0)| 00:00:01 | |* 17 | FILTER | | | | | | | 18 | HASH GROUP BY | | 50 | 800 | 46 (11)| 00:00:01 | | 19 | NESTED LOOPS | | 12890 | 201K| 44 (7)| 00:00:01 | | 20 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 | |* 21 | INDEX UNIQUE SCAN | CUST2_PK | 1 | 5 | 0 (0)| 00:00:01 | -------------------------------------------------------------------------------------

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

39419 consistent gets

0 physical reads

0 redo size

24813 bytes sent via SQL*Net to client

1107 bytes received via SQL*Net from client

68 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1000 rows processed

Differences?

• Elapsed time went from 1.51s to 1.50s

• Memory sorts were reduced from 1 to 0

• Query cost reduced from 191 to 184

• Consistent gets stayed the same

I still need better response time and less resource consumption.

Now what?

Let’s give the human a try

I rewrite the query…

SQL> get cust_disc_rewrite.sql

1 select c.cust_no, sum(o.total_order_price) tot_orders,

2 (case when sum(o.total_order_price) = 0 then 0

3 when sum(o.total_order_price) <= 100000 then .10

4 when sum(o.total_order_price) <= 500000 then .15

5 when sum(o.total_order_price) > 500000 then .20

6 else 0 end) as disc_rate

7 from customer2 c, ord2 o

8 where c.cust_no = o.cust_no(+)

9* group by c.cust_no

…and make a huge difference!

Elapsed: 00:00:00.29

-----------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

-----------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1000 | 16000 | 46 (7)| 00:00:01 |

| 1 | HASH GROUP BY | | 1000 | 16000 | 46 (7)| 00:00:01 |

|* 2 | HASH JOIN OUTER | | 12890 | 201K| 44 (3)| 00:00:01 |

| 3 | INDEX FAST FULL SCAN| CUST2_PK | 1000 | 5000 | 2 (0)| 00:00:01 |

| 4 | TABLE ACCESS FULL | ORD2 | 12890 | 138K| 41 (0)| 00:00:01 |

-----------------------------------------------------------------------------------

The query uses 191 vs. 39,419 LIOs and runs in .29 seconds!

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

191 consistent gets

0 physical reads

0 redo size

26279 bytes sent via SQL*Net to client

1107 bytes received via SQL*Net from client

68 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1000 rows processed

The moral of the story

Something else to keep in mind…

Tools on the market today do not use a business-task focused approach to solve a performance problem

The Advisors and Enterprise Manager mainly monitor system-wide metrics

What do you do if your user’s performance problem

isn’t representative of the system-wide issues?

That’s exactly what Method R

is all about

1. Determine the business task that is performing sub-optimally that you want to fix next.

2. Collect detailed statistics about how this task spends its time while it is performing poorly.

3. Execute repairs to reduce the task’s response time and/or resources consumed, or prove that it is already as efficient as it can affordably be made.

4. If problems still exist, then go to step 1.

There is a belief that there is a downside to a business task-focused approach.

Many believe it’s too difficult to get access to the information or people needed.

It seems easier to focus on what the “system” has to tell us in order to find and fix problems.

Remember the monkeys?

Enter the astronaut.

The costs of following the wrong advise can be substantial.

If you are working on the wrong thing, the real problem remains and

the business continues to suffer.

Conclusion

Don’t let the advisors – or any ‘automatic’ feature

become the dictator of your career.

Tools are there to facilitate our knowledge, not replace it.

Use the tools wisely but not as a substitute for your own

lack of knowledge.

The bottom line

The key is about a thirst for knowledge… not just the knowledge itself.

It’s about how we strive to learn, understand, and know how and why

things work that makes the difference.

It is the fulfillment of the desire to know that leads us to the knowledge we need

to evolve from monkey to astronaut and to be able to solve the problems

that seem unsolvable.

It takes effort but the result is that you become a respected,

invaluable resource with the skills and confidence to impact your

business in a positive way.

Thank You!