Download - Click here for a copy of this presentation
DB2 UDB Application Tuning 101: The Nuts and Bolts – Draft Version Brad Clevinger of EDSIBM Certified Solutions Expert -DB2 UDB V7.1 Database Administration for OS/390Oracle 9i & 8i Certified Database AdministratorColorado DB2 Users Group For Z/OS Technical Session D:March 17, 2005
Platform: DB2 UDB for z/OS
2
AGENDA• Application Tuning Basics • Access Path Basics• Problematic SQL• DB2 UDB Traces• Benchmarking
3
Abstract Restatement
Application Tuning is a critical activity for the DBAs and Developers. This presentation reviews the how to, the stepsinvolved and the key items the DBA/Developer should lookfor during Application Tuning process.
4
Application Tuning Basics
To know that we know what we know, and to know that we do not know what we do not know, that is true knowledge.
-----Copernicus
5
DB2 Optimizer Basics
• A C Program that calculates the most efficient access plan for a piece of SQL.
• Parses, Rewrites, Optimizes SQL• Inputs:
• SQL• Machine Configuration – No. CPUs & Memory • DB2 Catalog Tables
• Outputs• Access Plan for Plan/Package or Dynamic SQL
6
Basic DB2 SQL Processing
Data Pages
Index PagesBuffer Pool
Buffer Manager
SQL
DB2Optimizer
Best AccessPath
SQLPlan
7
Access Path Basics
All men by nature desire to know. ---- Aristotle
8
EXPLAIN PLAN Access Path Basics
• METHOD for JOINs• 0 First outer table access or not used• 1 Nested Loop Join• 2 Merge Scan• 3 SORTs to support ORDER BY, GROUP BY,
DISTINCT & UNION• 4 Hybrid Join
9
EXPLAIN PLAN Access Path Basics - Continue
• ACCESSTYPE• I Matching Index Scan • I1 One-fetch Index scan• N Matching Index Scan for each IN-list value • R Table space Scan• M Multiple index scan • MX Matching Index Scan RID List• MI Intersection of RID Lists due to ANDed predicates• MU Union of RID lists, due to ORed predicates• Blank not used or clustering index for INSERTs or no index for
UPDATEs or • DELETEs WHERE CURRENT OF; or not applicable.
• MATCHCOLS – Indicates number of key columns matched for I, I1, N, & MX.
10
Problematic SQL
Light tomorrow with today!
-----Elizabeth Barrett Browning
11
Problematic SQL
• Inefficient SQL• Long Run Times• User Complaints• Production Support & Developer Staff Complaints/Concerns• High CPU• High IN DB2 Time
12
Bottlenecks – Summary Level
What/Where Performance-related Variables that might cause Bottlenecks?
• Machine Configuration• Network• Application• SQL Itself• Design
13
Potential Bottleneck Performance Concerns (Your Martha Stewart Worry List)
• Architecture• CPU• I/O• Network• Concurrency
• Application• Query• Logical Design• Physical Design
• Server(s)• Configuration• Optimizer• Lock Management
• Concurrency• Maintenance – Reorgs• Load/Unload• Index Creation• Batch Activity• TSO Users
14
Performance Concerns - Continued
• SQL Query• Appropriate Joins Path – NL vs. MS vs. HJ• Predicate Filtering • Parallelism
• Logical Design • De-normalize from third to second normal form• Vertical/horizontal segmentation of infrequently referenced data
• Physical Design• Too many/few indexes• Summary Data • Redundant Data• Partitioning
15
Performance Concerns - Continued
• Application Issues• Poorly written SQL• Repeatedly issues the same SQL• Cursor Use/Misuse• Batch Issues• Division of work between client and server
• Server Configuration• Memory• Sort Pool• EDM• Optimizer
16
Where to Look for It in Existing Programs
• AUTHID or SECONDARY AUTHID .PLAN_TABLE• JES2 Logs• CA7 Reports• DB2 monitoring tools
• OMEGAMON• CA INSIGHT• IBM TOOLS
• DB2 Log for Errors
17
Identifying the Usual Suspects• Starting Point• Find Plans/Packages with Full Tablespace Scans• SELECT PROGNAME, QUERYNO, QBLOCKNO,
METHOD, ACCESSTYPE,MATCHCOLS,ACCESSNAME, INDEXONLY, PREFETCHFROM AUTHID.PLAN_TABLE
WHERE ACCESSTYPE = ‘R’;• Cross-check PROGRAM to list of Long Running Jobs Lists
18
CSI – Detective questions (Who Do I Vote off the Island or adjust their personalities (tune the SQL)) • DNA of SQL • What tables is SQL accessing?• Why & What Business Condition(s)?• Frequency?• For Cursors, how many rows are being FETCHed?• SORTing needs?• Locking considerations?• Does this SQL Play Nice to its Neighbors?• CPU Bound? • I/O Bound?
21
Myth vs. Reality
Myth: “Small Tables Don’t Need Indexes”Reality: Though a tablespace scan may seem better, it still
requires the CPU cycle through the pages. An index has an absolute pointer to the row(s) needed. Let the RID Pool be your friend.
Reality: Explain Plan quantifies cost of SQL. It does not measure frequency.
23
SORT Notes
• AGREGATE FUNCTIONs• DB2 Optimizer will use SORT Avoidance is possible to
prevent sorting of result set if index used because data is already sorted.
• Sorts use CPU. • Small SORTs are no innocent• Is SORT Pool sized enough• Explain Plan don’t consider number of executions• Cluster Indexes are already SORTed.
26
DB2 UDB Traces
All truths are easy to understand once they are discovered; the point is to discover them.
-----Galileo Galilei
27
DB2 Traces
• DB2 Produces internal SMF Records• SMF 100 Type Records are Accounting• SMF 102 Type Records are Performance• DB2PM is Performance Analysis Tool• Batch Reports DB2 Subsystem• Online Monitor GUI with snapshot live DB2 Subsystem
29
SMF 102 Records
• Class 1 (Elapsed time)Class 2 (In-DB2 time)Class 3 (Wait times)Class 7 (Package level In-DB2)Class 8 (Package level Wait)
31
Trace Commands
• START TRACE – starts one or more type of traces• DISPLAY TRACE – displays trace options in effect • STOP TRACE – Stops any trace• MODIFY TRACE – Change the IFCIDs on active trace
32
DB2PM Reports
• DB2PM Short Report• DB2 Response Time• Resources Used – Processor and CPU• Lock Suspensions• Application Code Changes• Wait Times – Processor, I/O Wait or
Lock Wait
33
• DB2PM Long Report• Class 1 Elapse Time
• Time before the first SQL statement. • DB2 create thread time. • Time after the DB2 terminate thread.
• Not-in-DB2 Time – This is the calculated difference between Class 1 and Class 2 elapse time. If time spent outside DB2 (but within the DB2 accounting interval) is lengthy, the problem will be found in the application, CICS, IMS, or the overall system, and not within DB2.
• Lock/Latch Suspension Time – This value shows contention for DB2 resources. Check the "Locking Summary" section of this report for additional information, then proceed to the Locking Reports for help.
34
• Synchronous I/O Suspension Time – This is total application wait time for DB2 synchronous I/Os. If the number of I/Os is high, check for: • A change in access path. • Application code changes. • System-wide DB2 bufferpool problems. • RID pool failures. • System-wide EDM pool problems.
• Asynchronous Read Suspensions – This is the accumulated time for read I/O done under a thread other than this thread. It includes time for Sequential prefetch, List prefetch, Sequential detection or Synchronous read performed by another thread. The Rule-of-Thumb for Sequential prefetch or Sequential detection (asynchronous I/O) is 1 to 2 milliseconds per page. The Rule-of-Thumb for List prefetch is 3-4 milliseconds per page. Check "Other Read I/O" to locate value.
35
• Not-Accounted-For DB2 Time – This is accounting class 2 time that is not part of class 2 CPU or class 3 suspensions, and is normally due to MVS paging, processor wait time or time spent waiting for parallel tasks to complete. Check the "Not Account" field for this value.
36
Benchmarking
There art two cardinal sins from which all others spring: Impatience and Laziness.
----- Kafka (1883-1924)
37
Application Benchmarking• What are the Organization Goals?• Why, Who, What & How Measured• Proof that Application Executing Efficiently
• 1,000,000 Customer Accounts Updated Nightly • 20,000,000 Calls Processed Nightly
• Nightly Batch Jobs• Online Screens Response Time
38
Tuning Solutions • Normalization is good but causes many JOINs
• Review Cardinality of Data Values• For all ACCESSTYPE ‘R’s, create index if possible if amount
of rows is < 25 % being retrieved in Result Set• Small Tables with ACCESSTYPE ‘R’s is not always good.• Index-able Predicates reduce i/o• Use Clustering Indexes to reduce Sort and CPU Costs• Nested Loops for JOINs are not always innocent• Indexes, Indexes, Indexes
39
Session Title: DB2 UDB Application Tuning 101: The Nuts and Bolts Session: D
Brad Clevinger [email protected]