Performance 101 for DB2 for LUW

Size: px

Start display at page:

Download "Performance 101 for DB2 for LUW"

Domenic Poole
5 years ago
Views:

1 Performance 101 for DB2 for LUW A PDF of these slides can be downloaded from: ibm.com/developerworks/data/events/idmbriefings.html Jeff M. Sullivan DB2 on LUW and DB2 on z/os I.T. Specialist Optim Technical Enablement, IBM Software Group jeffsull@us.ibm.com December 4, 2009

2 Agenda Information Management Performance basics Intelligent monitoring Best practices Follow the symptoms Guideline to basic performance tuning Performance tuning with IBM Performance Expert and Extended Insight Demonstration $$ 2

3 Performance Basics December 4, 2009

4 Intelligent Monitoring means.? From management's perspective: Ability to look at the environment Make projections on the growth Plan for any future projects Motivation: To rein in spending and control costs To an I.T manager perspective: Making a pretty good estimate on how much the overall environment will grow Resolve outstanding issues that would enable postponing upgrades Not being blindsided by an issue not caught by the database administration staff 4

5 Intelligent Monitoring means.? From a database administrator's perspective: Faster mean time to problem resolution Get to the problem faster than having the users complain to his manager Motivation: To not be blindsided by a problem To a DBA this translates to: Monitoring by rules Responding quickly to the problems when they happen Planning for that next instance, application, growth issue 5

Basic Rules for Performance Tuning Be prepared Understand the whole picture Only tune things that can explain the symptoms Change only one thing at a time Best practices for DB2 for

6 Basic Rules for Performance Tuning Be prepared Understand the whole picture Only tune things that can explain the symptoms Change only one thing at a time Best practices for DB2 for Linux, UNIX, and Windows: nce_1008i.pdf 6

7 Performance Bottlenecks Usually do not happen when applications are Unit tested System tested or shakedown tested Integration tested But when they happen, DBAs ask Is this a one-off situation? Or is this a new steady state? New workload Existing work changes DBA misstep 7

8 New Steady State - New Work New SQL worked fine in test and QA subsystems, but not with production database sizes New SQL is fine, but due to inadequate maintenance the tables they go against are not properly tuned (see DBA MISSTEPS) Bad SQL because of: Failure to commit Not knowing or collecting column statistics Scanning tables inadvertently (Boil the ocean technique) Single tasking SQL and not combining operations (Old school thinking) 8

9 New Steady State Changes to Existing Work I/O Mild-mannered SQL turns into raving maniacal SQL with teeth Time for an index" scenario Memory Increase of work in one area eats up buffer space for another application Applicable on DB2 for z/os and DB2 for LUW with single instance/multiple applications CPU Rarely happens unless, due to politics or lack of metrics, a server is overloaded with instances 9

10 New Steady State DBA Misstep Failure to gather statistics Failure to track volatile tables Failure to do regular maintenance Failure to change system settings for new or changed applications 10

11 New Steady State DBA Misstep Contentions Not setting timeout limitations on threads Commit frequency (may cause lock escalations and/or deadlocks) Buffer pool (page cleaners and/or buffer pool size and/or buffer pool isolation on high usage tables) SQL usage and issues (may cause lock escalations) Heap sizes pertaining to the lock pool (unable to obtain a lock - SQL slowdown) Not having a bufferpool strategy (split the work, reduce contention) 11

12 In Summary on Performance Policies and Politics It is possible to performance tune ad infinitum, ad nauseam...don t! Tune to the level of what you, your end-users, and the company can live with Meet your service level agreements and service level objectives Remember these 2 guidelines: The limit of tuning is ultimately a bottleneck by definition Performance management is the art of juggling what you can live with There are no silver bullets in Performance Tuning 12

13 DB2 Performance Expert and DB2 Performance Expert Extended Insight December 4, 2009

Database Performance Affects Your Business Application performance degradation or

Impacts employee productivity Drives up infrastructure costs Performance tuning is

monitoring thresholds are often difficult to relate to SLAs Layered application

require many people Continual business and IT changes mean performance

14 Database Performance Affects Your Business Application performance degradation or lack of consistent performance: Reduces customer satisfaction Risks revenue loss Impacts employee productivity Drives up infrastructure costs Performance tuning is highly complex with many interdependent factors requiring deep skills Database monitoring thresholds are often difficult to relate to SLAs Layered application stacks obscures visibility of problem source Problem isolation can take days and require many people Continual business and IT changes mean performance optimization is never done Constant drive to reduce IT costs demand better infrastructure performance 14

15 Performance Tuning Complexity Many factors to correlate Multiple data sources Interdependent issues External factors Deep skill required Diagnosis Resolution And that s just for a single query Missing index Poor statistics Poor SQL Limited connection pool External resource constraint Too little memory Poor access plan Too much CPU Poor resource allocation Need pre-computed Constrained network Deadlocks Too much I/O Low cache hit Data is skewed Too much data 15

16 Systematic Performance Bottleneck Diagnostic Inadequate disk configuration / subsystem? SQL w/o parameter markers? Too small dyn SQL cache? Apps connecting/disconnecting? Non-parallelize application? Bad plan giving tablescan? Old statistics? Need more indexes? Insufficient prefetchers? Over-aggressive cleaning? LOB reads/writes? Insufficient sortheap? Missing indexes? Anything sharing the disks? High transaction rate Too-frequent commits? Mincommit too low? High data volume Logging too much data? Lock escalation? Lock contention? Deadlocks? Too few prefetchers? Too few cleaners? Append contention? Mincommit too high? Old device drivers Creating/destroying agents Too many connections Bad plan(s) giving excessive index scanning? Need more/different indexes? High User Time High System Time Data Tablespace Index Tablespace Temp Tablespace Log Devices Excessive data flow? LOBs intermediate data Shared n/w conflict Contention Bottleneck CPU Bottleneck Disk Bottleneck Network Bottleneck Bottleneck Type? 16

17 Staff and Time Intensive Gather all the evidence Configuration Data Statement plans Catalog statistics Snapshots Performance Monitor Event Monitor Activity Monitor Application Server Monitor Network Monitor Operating System Metrics Storage System Metrics From how many tools? 17

18 Wouldn t It Be Nice If you could cut down on customer and employee complaints regarding application performance? your call center staff were not making excuses for slow performance? you could put off a system upgrade? you could actually plan for capacity growth? the system page outs to on-call support decreased? the system told you there was an impending problem instead of you trolling for problems? you had one place to go instead of a dozen to diagnose problems 18

critical levels Respond Visualize emergent bottlenecks or end-to-end response time Drill-down into problem detail and related context

19 DB2 Performance Expert and Extended Insight Resolve emergent problems before they can affect your business Monitor Set thresholds that reflect service level objectives Monitor database activity, internal resources, and end-to-end response time Alert warning and critical levels Respond Visualize emergent bottlenecks or end-to-end response time Drill-down into problem detail and related context Identify problem application and SQL Plan Analyze historical trends Optimize for increased capacity Project capacity growth requirements 19

Monitoring Databases Set thresholds to meet service level objectives Defaults

Mixed workload Iterative adjustment Compare to baselines Trending analysis reports

activities, resource consumption, and key performance indicators over time KPIs

20 Monitoring Databases Set thresholds to meet service level objectives Defaults provided OLTP, BI, Content management, Workload Management Customize to suit needs Mixed workload Iterative adjustment Compare to baselines Trending analysis reports and graphs Recognize arising bottlenecks early Graphical views visualize activities, resource consumption, and key performance indicators over time KPIs Dashboard Notification Alert warnings and critical situations Visual, , pager Customized 20

21 Visual Alert and Key Performance Indicators Deadlock exception Double click on KPI to drill down Warning threshold Problem threshold Hover help with description and recommendation 21

Responding to Problems Overview Broad and deep diagnostics

Deadlock analysis Historical analysis Visualize changes

Look back at what happened last week, last month, last year

22 Responding to Problems Overview Broad and deep diagnostics Applications Operating systems Database systems Top SQL Deadlock analysis Historical analysis Visualize changes over time Correlate with configuration changes over time Look back at what happened last week, last month, last year History Detail Ability to respond Force application Other response 22

23 Analyze Using Predefined Queries Details for various performance indicators Impact of configuration changes Common reports SQL activity, e.g. heavy hitter 23

24 Warehouse Queries - Example Query to identify database with low buffer pool hit ratio. Potential signs of insufficient indexes List of databases with low buffer pool hit ratio over time 24

25 Warehouse Queries - Example Query to identify database with low buffer pool hit ratio. Potential signs of insufficient indexes 25

workload increases over time Adapt early to handle workload increases Historical Reports Create reports

26 Planning for Growth Trends Retain historical data Retain long-term performance history in a performance warehouse Analyze trends Select range and scope Visualize data, trend, and trend prediction to see how workload increases over time Adapt early to handle workload increases Historical Reports Create reports Pre-built or customized Detect peak workload times Adjust to potential bottlenecks Respond proactively 26

27 Space Management Tablespace information on allocated and used space History of space used and allocated File system information 27

28 Analyze Trends Analyze trend for package cache size 28

29 Analyze Trends Blue line is historical data. Grey line is trend Historical and trend data available in days, weeks, months, and years Analyze trend for package cache size Dotted grey line is predicted trend 29

DB2 Performance Expert Architecture DB2 Performance Expert Client DB2 Performance Expert Server Platform DB2 Performance Expert Server Performance Database for Monitored Platforms 1,2,3,.

30 DB2 Performance Expert Architecture DB2 Performance Expert Client DB2 Performance Expert Server Platform DB2 Performance Expert Server Performance Database for Monitored Platforms 1,2,3,...x CIM Client Monitored DB2 System 1 Monitored DB2 System x Monitored DB2 System 3 Monitored DB2 System 2 CIMON: Common Information Model Object Manager CIMOM Monitored Platform 1 CIMON CIMON CIMOM Monitored Platform x Monitored Platform 3 Monitored Platform 2 30

warehouse Event monitor data Time Deadlock event Workload manager statistics Application/SQL Instance,

31 DB2 Performance Expert Data: History & PWH Short term history: detailed snapshot data Long term performance warehouse: aggregated data Performance database Rolling snapshot history Performance warehouse Event monitor data Time Deadlock event Workload manager statistics Application/SQL Instance, memory, utility Trash Automatic purge DB/DBM CFG OS system Database Tablespace Table Bufferpool Summarized data 31

32 DB2 Performance Expert Extended Insight Feature Getting an End-to-End View Application Server Database Server Business Logic Connection Pool EJB Query Language Data Access Logic Persistence Layer DB Java Driver Network A A A OS Extended Insight Performance Expert Set performance indicators that better reflect end user experience Visualize time spent in each layer Isolate problems to correct area instantly Get connection pool detail for WebSphere application servers Use with Java workloads now, more coming 32

33 Diagnose Overall Application Response Time In this situation, all applications are equally affected, and the problem seems not to be in the data server. 33 It seems that the first application server has a problem. Double-click to drill-down.

34 Diagnose Application Server Most of the time is spent for WAS connection pool wait time. Double-click to drill-down and display detail information. 34

35 Diagnose Connection Pool 5 second wait time indicates that the maximum number of allowed connections is not sufficient which becomes also evident when comparing the parameters and metrics of this client with other clients. 35

Complementary Capabilities Optim Query Tuner Get expert

creation Omegamon XE for DB2 Visualize DB2 performance

DB2 Workload Manager Allocate DB2 resources by

36 Complementary Capabilities Optim Query Tuner Get expert advice on SQL tuning, statistic collection, and index creation Omegamon XE for DB2 Visualize DB2 performance statistics from a common DB2 Performance Expert console DB2 Workload Manager Allocate DB2 resources by user-defined workload and estimated resource usage Monitor performance by workload 36

37 DB2 Performance Expert & Extended Insight Product at a Glance Single point for monitoring, analysis and control of multiple DB2 instances Real-time and historical data End-to-end database monitoring DB2 engine and application monitoring Multiple partitions Integrated OS monitoring Dashboard for visualization Alerts Visual, (SMTP), user exit Performance history and warehouse WLM Monitoring SQL tracing & analysis SQL heavy hitter identification Monitor resource consumption, SQL activity, transaction, locking conflicts Post-mortem analysis, trend analysis Capacity planning Benefits Monitor performance indicators for emergent problems Respond quickly, pinpointing problems in minutes, not days Plan for business growth Where does it Run? DB2 Performance Expert supports DB2 servers running on Windows, AIX, HP-UX, z/os, Linux, Linux on zseries, and the Sun Solaris Operating Environment DB2 Performance Expert Client runs locally on workstation 37

38 Resources Zen and the Art of Database Performance Best Practices: Tuning and Monitoring Database System Performance formance/ DB2 Performance Expert product page Integrated Data Management Community Space (videos, article, tutorials, blogs, and more) 38

39 Demonstration December 4, 2009

40 Have a great new year! We ll be back next year Don t leave yet. Please fill out the survey! ibm.com/developerworks/data/events/idmbriefings.html 40

41 Questions? December 4, 2009

IBM Tivoli OMEGAMON XE on z/os

IBM Tivoli OMEGAMON XE on z/os Manage and monitor your z/os and OS/390 systems IBM Highlights Proactively manage performance and availability of IBM z/os and IBM OS/390 systems from a single, integrated interface Maximize availability