Tuning based on Wall Clock Time instead of Elapsed Time

Transcription

1 Tuning based on Wall Clock Time instead of Elapsed Time Wall Clock Time Tuning in Databases Gerwin Hendriksen Principal Consultant Version June 2017

2 Agenda: Tuning with AWR: What about parallel? What about WCT? How to get WCT data? What can we do more? Q/A

3 WhataboutParallel

4 TuningwithAWR 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

5 AWR Reports AWR Snapshot: AWR Snapshot: AWR Snapshot: AWR Snapshot: AWR Snapshot:

6 Soletsseethedetails: and what is different for the different statements

7 Yes! We didsometuning 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???

8 SowhatabouttheEnd-User? AWR doesn t give us the information!! Oracle made SQL- Monitoring Lets checkout Oracle SQL-Monitoring

9 Wall ClockTime YEAH!!! P1-ccacskfsnz2y4_ P2-5tm2zdkuyb3vk_ P4-8qzbnban8mdsm_ P8-dv0jap9p5vfr5_ P16-gmfh78v3n2f55_ P32-b23ua8kyvnq5d_ P64-8dn43389f4qvk_ P128-cc05cd0hz4brx_

10 QuestionsRising 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?

11 Data forsql-monitoring: The data for SQL-Monitoring comes from the columns: tm_delta_time tm_delta_cpu_time tm_delta_db_time delta_time Out of views: Blog Dominic Brooks! ASH: v$active_session_history AWR: dba_hist_active_sess_history

12 Active SessionHistory

13 AWR andash:

14 WCT vselapsedtime Session WCT for Non Parallel = Elapsed Time WCT for Parallel WCT Improvement T Session H Parallel 1 R Parallel 2 E Parallel 3 A Parallel 4 D S Elapsed Time in Parallel = Sum of all used system time of involved threads

15 How toget Wall ClockTime 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!!

16 Next toget Wall ClockTime 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!!!

17 CalculateWall ClockTime 1 Specific statement in ASH (v$active_session_history): WCT in seconds = <ASH Samples containing one of related sessions> x 1 second ELA (DB-Time) in seconds = <ASH Sampl. sum of occurrence of each related session> x 1 second

18 CalculateWall ClockTime 2 Specific stat. in AWR (dba_hist_active_sess_history): Cumalative WCT in seconds = <AWR Samples contain at least one of related sessions> x 10 seconds Cumalative ELA (DB-Time) in seconds = <AWR Sampl. sum of occurrence of each related session> x 10 seconds

19 CalculateWall ClockTime 3 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

20

21 Data gathered See the Excel:

22 WCT Calculated:

23 WCT SQL Monitoring:

24 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.

25 Gerwin Hendriksen