Tuningbasedon Wall ClockTime insteadof ElapsedTime · PDF fileTuningbasedon Wall ClockTime...

transcript

Tuning based on Wall Clock Time instead of Elapsed Time

Wall Clock Time Tuning in Databases

Gerwin Hendriksen

Principal Consultant

gerwin.hendriksen@axisinto.nl

Version 2.0

13 June 2017

Agenda:

• Tuning with AWR:

• What about parallel?

• What about WCT?

• How to get WCT data?

• What can we do more?

• Q/A

What about Parallel…

Tuning with AWR…

The normal way of database performance tuning is the

usage of AWR data.

Problems occur with this way of tuning when introducing

parallel.

So lets first checkout an AWR report…

AWR Reports…

• AWR Snapshot: 166-167

So lets see the details:

…and what is different for the different statements…

163264128

Yes! We did some tuning…

Based on AWR we did some tuning, we saw that the

system had still some resources available, so increasing

parallel processes looked to be very smart…

BUT…. IS IT REALLY SMART???

So what about the End-User?

• AWR doesn’t give us

the information!!

• Oracle made SQL-

Monitoring…

Lets checkout

Oracle SQL-Monitoring…

Wall Clock Time YEAH !!!

• P1-ccacskfsnz2y4_10041456

• P2-5tm2zdkuyb3vk_10041458

• P4-8qzbnban8mdsm_10041535

• P8-dv0jap9p5vfr5_10041506

• P16-gmfh78v3n2f55_10041509

• P32-b23ua8kyvnq5d_10041515

• P64-8dn43389f4qvk_10041523

• P128-cc05cd0hz4brx_10041528

Questions Rising…

• How can we checkout a change in performance from an

end-user perspective when changing the number of

parallel threads used for a query?

• The same thing applies for checking out overall database

performance from an end-user perspective. What did the

change do for the end-user performance?

The data for SQL-Monitoring comes from the columns:

• tm_delta_time

• tm_delta_cpu_time

• tm_delta_db_time

• delta_time

Data for SQL-Monitoring:

Out of views:

• ASH: v$active_session_history

• AWR: dba_hist_active_sess_history

Blog Dominic Brooks !

Active Session History…

AWR and ASH:

WCT vs Elapsed Time…

Session

Parallel 1

Parallel 2

Parallel 3

Parallel 4

WCT for Non Parallel = Elapsed Time

WCT for Parallel WCT Improvement

Elapsed Time in Parallel = Sum of all used system time of involved threads

THREADS

How to get Wall Clock Time…

• ASH samples every second. If we find an entry for a

session in ASH, we can say that it was running for one

second.

• AWR takes one out of ten ASH samples. If we find an

entry for session in AWR, we can say that it was running

for 10 seconds.

• In both above claims is some error, but with lots of

samples and longer running queries it works fine!!

Next to get Wall Clock Time…

Parallel Server processes run under different sessions, but

have the same coordinator process (qc_session_id) and so

can be counted as elapse time for one and the same query.

Lets Dive into ASH and AWR…

DEMO TIME!!!

Calculate Wall Clock Time…1

Specific statement in ASH (v$active_session_history):

WCT in seconds =

x 1 second

ELA (DB-Time) in seconds =

x 1 second

Specific stat. in AWR (dba_hist_active_sess_history):

Cumalative WCT in seconds =

x 10 seconds

Cumalative ELA (DB-Time) in seconds =

x 10 seconds

For one execution in AWR (dba_hist_sqlstat):

Estimation Parallel =

Cum. ELA / Cum. WCT

Estimation WCT per exection =

ELA from AWR Report / Est. Parallel / Number of Exec

Data gathered…

See the Excel:

WCT Calculated:

WCT SQL Monitoring:

Conclusion…

• ASH and AWR can be used to calculate Wall Clock Time

for statements running more than 30 seconds quite

reliable.

• So extra data should be gathered from AWR to be able to

make good tuning decissions when parallel is used. In

EXADATA systems this is really important.

Gerwin Hendriksengerwin.hendriksen@axisinto.nl

Tuningbasedon Wall ClockTime insteadof ElapsedTime · PDF fileTuningbasedon Wall ClockTime...

Documents