Crating a Robust Performance Strategy
1 like1,631 views
This document profiles an Oracle DBA with over 18 years of experience. It lists their work experience including being Vice President of an Oracle user group in Guatemala since 2014 and a member of various Oracle communities. It also references a blog they co-wrote with an Oracle Ace from Argentina. The rest of the document discusses performance tuning concepts and strategies including analyzing response times, throughput indicators, and using metrics like average, variance, and dispersion to understand predictability. It provides examples of using Oracle tools to collect job and query timings and demonstrates analyzing backups and elapsed times. The goal is to identify the slowest or least predictable processes or queries for further optimization.
![FIND SLOWEST AND NOT PREDICTABLE
QUERIES
Column ct (Count times executed) = Bucket 1 + Bucket2 + Bucket3 + Bucket4 + Bucket5
Example
SQL_ID=1kahr9dw1rqbu ,executed = 3942 times, Avg = 7 Segs
Bucket1 = [0..98 Segs ] 3862 times 97% , Bucket5 [396-490 Segs] 20 times
Less predictable of SQL_ID 06amz8tcpwtuz and the VMR show this.](https://image.slidesharecdn.com/otn2015strategyrobustperformance1-150823132353-lva1-app6891/85/Crating-a-Robust-Performance-Strategy-17-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (10)
Ad
Similar to Crating a Robust Performance Strategy (20)
Ad
More from Guatemala User Group (20)
Recently uploaded (20)
Crating a Robust Performance Strategy
- 2. Over 18 years of experience in Oracle , started in 1996. Vice-President Oracle User group in Guatemala since 2014 Member of LAOUC ( Latin America Oracle User Community) Since 2012 Distinguished Member of Oracle Hispanic community Latin America (http://comunidadoraclehispana.ning.com) Wrote Co-Blog Partner Fernando Garcia –Argentina Oracle Ace (https://oracleconprecision.wordpress.com/about) …..In summary a self study Person like you
- 3. PROPERTIES OF PERFORMANCE P O I N T O F V I E W ( E N D U S E R ) • They expected some benefit in business perspective. • They always will confirm in their system the result of our work. • Measurement is based on a perception of historical performance. P O I N T O F V I E W ( T E C H N I C A L U S E R ) • Optimize system resources according to the request of user. • Need to be logged and compared with a SLA • Measurement is based on a Response Time.
- 4. THROUGHPUT INDICATORS Improve Throughput means optimizing the components and create load balancing of resources to relieve the containment . A strategy include indicators for both and a method to focus your work across different components in order to achieve a better Performance (decrease response time)
- 5. TUNING EVERYTHING ? The challenge of it is achieve the expectations of performance that users define as acceptable, the lack of a consistent result in the operation, despite the introduction of new system components or growth of customer requests, result a demand user to tune the system.
- 6. THE GOLD PIECE (AVG RESPONSE TIME) The tests of scalability and performance monitoring shows in detail each component of the system pointing to the average response time. The goal is to achieve average response time acceptable complying with the user (SLA) and have the least variation so it is predictable Now , you need to use Average, variance, deviation , index of variation (VMR) to observe how much predictable is a process.
- 7. Average ( or Mean) 24 Variance 313.1111 Dev Standard 17.69495 Variance to mean ration (VMR) 13.0463 The mean is similar in this case , but the dispersion of data is very different Example 2 Example 1 > 1 skewed far away of the mean.
- 8. HOW PRECISELY IS THIS TOOL ? The change on mean do not dramatically change, but the index of dispersion give us an idea something happen You can inspect the detail around 2PM
- 9. WHERE DO YOU NEED TUNING ?
- 10. ANALYZE THE CASES ? AVG RESPONSE TIME FOR THE SAME QUERY Easy to see what is Max Limit , (Tolerance) More than 50% is below of mean, candidate to review why sometimes take to long to finish. More than 50% is over of Mean, candidate to review the execution plan
- 11. DEMO 1 ( JOBS) ORACLE COLLECTED ALL THE TIMES create table job_timings_test1 as select job_name, count(job_name) executions, round(avg(elapsed_time),3) average, round(median(elapsed_time),3) median, round(variance(elapsed_time),3) variance, round(variance(elapsed_time)/avg(elapsed_time),3) vmr from job_history where start_dat_time > '20013-12-31 23:59:59' and start_dat_time < '2014-01-01 00:00:01' and elapsed_time != 0 group by job_name order by job_name ;
- 12. ROBUST PERFORMANCE Taguchi Methods for Robust Design by Yuin Wu and Alan Wu (ASME Press, 2000) defines robustness as follows: … the condition used to describe a product or process design that functions with limited variability in spite of diverse and changing environmental conditions, wear, or component-tocomponent variation. A product or process is robust when it has limited or reduced functional variation even in the presence of noise. https://en.wikipedia.org/wiki/Taguchi_methods
- 13. ROBUST PERFORMANCE Uncontrollable variables are referred to as noise factors. There are three types of noise factors, and they are usually explained in manufacturing or product design terms. However, these types can be easily associated to the “uncontrollable” variables that affect database systems: • External causes: Users or operators, any system issue external to the database • Internal causes: Data growth or changes to code within the database • Component-to-component factors: System resource contention or systemwide changes that affect more than the intended process
- 14. USUAL APPROACH TO SEE PERFORMANCE
- 15. CREATE YOUR OWN VERSION TO REVIEW PERFORMANCE (LOGGED THE ELAPSED TIME) Go time: DBMS_UTILITY.get_time (at start) Stop time: DBMS_UTILITY.get_time (at stop) Elapsed time: Stop time–go time CPU go time: DBMS_UTILITY.get_cputime (at start) CPU stop time: DBMS_UTILITY.get_cputime (at stop) CPU elapsed time: CPU stop time–CPU go time
- 16. UNDERSTANDING THE METRIC IN ORACLE
- 17. FIND SLOWEST AND NOT PREDICTABLE QUERIES Column ct (Count times executed) = Bucket 1 + Bucket2 + Bucket3 + Bucket4 + Bucket5 Example SQL_ID=1kahr9dw1rqbu ,executed = 3942 times, Avg = 7 Segs Bucket1 = [0..98 Segs ] 3862 times 97% , Bucket5 [396-490 Segs] 20 times Less predictable of SQL_ID 06amz8tcpwtuz and the VMR show this.
- 18. DEMO 2 ( BACKUPS) Select sid,start_time,end_time From V$RMAN_STATUS where OPERATION='BACKUP' select ss.snap_id, ss.instance_number node, begin_interval_time, sql_id, plan_hash_value, nvl(executions_delta,0) execs, (elapsed_time_delta/decode(nvl(executions_delta,0),0,1,executions_delta))/10 00000 avg_etime, from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS where sql_id = ccyax0n7jfa7j' and ss.snap_id = S.snap_id and ss.instance_number = S.instance_number and executions_delta > 0 order by 1, 2, 3 DEMO 3 ( QUERY ELAPSED TIME)
- 19. SUMMARY WHY WE NEED CREATE THIS METRICS? working on the measuring the system, we also gain more knowledge how works everything. We get the opportunity to test our hypothesis and deny the speculations of other groups with a precarious position ( The application not change / is almost the same size of data / not a large variation of users …etc) A good DBA do not work with assumptions , analyze the processes using the evidence in the metrics.
- 20. QUESTIONS [email protected] #AgarciaDBA You want more Demos ? • Network Activity • Spike of Connections • Balance workload in Rac • Bottleneck in Memory/CPU • …. etc