Mainframe

Performance Tuning
WORKSHOP

THIRDWARE TECHNOLOGY SOLUTIONS 1

Agenda (Day 2)

 General Tuning Approach in Mainframe Applications

 DB2 Optimization

 DB2 - SQL Tuning

 Q &A

 Brainstorming Session

THIRDWARE TECHNOLOGY SOLUTIONS 2

General Tuning Approach in Mainframe Applications

 Jobs/Job flow Revisit

 COBOL Program/Logic Tuning

 Subsystem Optimization
- DB2/
- IMS
- CICS

THIRDWARE TECHNOLOGY SOLUTIONS 3

DB2 Optimization

 Access Paths and Access Strategies – Performance Data Collection – Review Statistics
 3 R’s - RUNSTATS/REBIND/REORG

• When data volume changes

• When new data structures added
• When statistics have changed significantly enough to change access paths
• On tables identified in the longer Running Queries

 Data Archival Mechanisms / Data Purging

 Use NULL Sparingly while designing; Use appropriate Data Types; Avoid Defaults

 Revisit Indexes

THIRDWARE TECHNOLOGY SOLUTIONS 4

The DB2
Optimizer

THIRDWARE TECHNOLOGY SOLUTIONS 5

Database Services

Results
SQL Relational Data System

Apply stage 2
predicates and sort
data

Optimized
Data Manager
SQL
Apply stage 1
predicates

Read Buffer or Buffer Manager

Data
Request Data

THIRDWARE TECHNOLOGY SOLUTIONS 6

Relation Data System

 Checks authorization

 Resolves data element names into internal identifiers

 Checks the syntax of SQL statement

 Optimizes SQL statement and generates access path

THIRDWARE TECHNOLOGY SOLUTIONS 7

The Optimizer
Heart and Soul of DB2
Analyzes the SQL statement
Determines the most efficient access path
Parsing the SQL statement
Queries statistics from Catalogue tables
o Tables
o Indexes
o Columns
o Tablespaces

Physical Data Independence

THIRDWARE TECHNOLOGY SOLUTIONS 8

The Optimizer
DB2 subsystem
SQL Statements

DB2
Optimizer
Other System
Information

Query Cost
Formulas
Optimized Access
Path(s)
DB2
Catalogue

DBAS
Optimization Hint

OPTHINT In
PLAN_TABLE

THIRDWARE TECHNOLOGY SOLUTIONS 9

How Optimizer Works
Receive and verify the SQL statement
Analyze the environment
Optimize the method of satisfying the statement
Create machine readable instructions
Execute the instructions
Store them for the future use
Optimizer is cost based

THIRDWARE TECHNOLOGY SOLUTIONS 10

 How Optimizer Works
Four factors to evaluate
o CPU cost
o I/O cost
o DB2 Catalogue statistics
o The SQL statement

Filter Factor
o Ratio between 0 and 1
o Lower the FF > Lower the cost > More efficient query

THIRDWARE TECHNOLOGY SOLUTIONS 11

Application Performance
Do you have an estimate of how many rows will be retrieved by a query - typical, worst case

◦ impact on user performance (sees too much worthless data)

◦ impact on network performance - too much data being passed
◦ application performance - too much time spent retrieving unwanted data
◦ Getting a list of all Trades - not a good idea

THIRDWARE TECHNOLOGY SOLUTIONS 12

Application Performance (..contd.)
 Do you know how much time (at least qualitatively) it could take to run a query - typical, worst case

◦ can result in unacceptable response, throughput

◦ can result in unacceptable throughput, response for other users
◦ Need to analyse performance characteristics of query
◦ Need to see if indexing can improve performance (and not degrade for other transactions)

THIRDWARE TECHNOLOGY SOLUTIONS 13

Query evaluation
 All DBMS’ use an optimizer to determine the algorithm for query evaluation

Many times it is not possible to predict what algorithm the optimizer will choose

An “explain” facility is provided that shows what steps the DBMS will take to evaluate a particular
query

Finally, application performance must be measured and benchmarked

THIRDWARE TECHNOLOGY SOLUTIONS 14

Final Word on Performance
 The application designer and programmer have to worry about performance all the time.

 While SQL is a great mechanism that makes life easy for programming, the programmer and designer
have to take care when it comes to performance

THIRDWARE TECHNOLOGY SOLUTIONS 15

Challenges of SQL tuning
SQL tuning is best done in development
o Developers usually don’t understand tuning

If I only knew how the database is accessed…

o Database applications are dynamic

What should I tune?

o The needle in the haystack “worst SQL”
o One heavy SQL or multiple executions of “light” SQL?

Mostly reactive

THIRDWARE TECHNOLOGY SOLUTIONS 16

Basic Tuning Concepts
SQL statement is submitted to the database
SELECT NAME, PHONE_NUMBER FROM RESTAURANTS
WHERE CITY = ‘IRVINE’ AND
FOOD_TYPE = ‘PIZZA’ AND
SERVICE = ‘DELIVERY’
ORDER BY NAME

DB engine creates a “plan” to process the SQL

The plan is generated by the DB engine optimizer, considering many variables
There are ways to make the optimizer make smarter decisions and … the SQL run faster

THIRDWARE TECHNOLOGY SOLUTIONS 17

 … more Tuning Concepts
Understand the plan—not a trivial task

Change the plan to make things faster. How?

◦ Indexing: an index is like a table of contents, using one you can get quicker to the correct page
◦ Write the same SQL in a different way (re-write)
◦ Give the optimizer hints

THIRDWARE TECHNOLOGY SOLUTIONS 18

Database Application Lifecycle and solution
for tuning

Development Test Production

 Tune SQL while building Profile the way the  Identify slowdowns fast
the application application accesses the DB and fix them
(proactively) Analyze application  Analyze performance
 Development and tuning performance while proactively to identify
work hand-in-hand. simulating the production problems ahead of time
env.  Monitoring, diagnosis
Tuning, impact analysis and resolution
and profiling solutions.

THIRDWARE TECHNOLOGY SOLUTIONS 19

Optimization Process

2.
2.Rewrite
RewriteSQL
SQL

1.
1.Identify
Identify
Problematic 3. Benchmark SQL
ProblematicSQL
SQL
alternatives

Best SQL

THIRDWARE TECHNOLOGY SOLUTIONS 20

 Tuning the Application
How does the application access the database?

Identify the statements at the heart of your application

◦ Executed 10,000 per second--have the top expert tune those!

Check for potential SQL problems across the whole application

◦ rules of thumb, inefficient optimization plans, miscellaneous errors

Analyze access patterns to the data

◦ Look for repetitive WHERE clauses indexing candidates
◦ Look for repetitive aggregations potential summary tables.

THIRDWARE TECHNOLOGY SOLUTIONS 21

 Tuning the Application
Analyze index usage
◦ Identify frequently used indexes  keep in good shape, map to separate mount points, fine-tune storage
allocations
◦ Identify unused indexes  drop them

Look for similar access patterns or identical statements

◦ Consolidate functionality--on the client or by server-side code (leverage benefits of cached statements and
data)
Analyze joins used in the application
◦ Valid joins?
◦ Can additional indexes on join columns speed up the join?

Look for unused tables or columns within tables

◦ If a column is not used in any program, question its existence

THIRDWARE TECHNOLOGY SOLUTIONS 22

EXPLAIN
AN AID FOR OPTIMIZATION

THIRDWARE TECHNOLOGY SOLUTIONS 23

What EXPLAIN Does
 SQL statements are passed through the DB2 optimizer and the access paths are externalized.
 The chosen access paths are recorded in PLAN_TABLE
 Preferably qualify the PLAN_TABLE with the ownerid.

THIRDWARE TECHNOLOGY SOLUTIONS 24

PLAN TABLE COLUMNS
QUERYNO
QBLOCKNO
APPLNAME
PROGNAME
METHOD
CREATOR
TNAME
TABNO
ACCESSTYPE
MATCHCOLS

THIRDWARE TECHNOLOGY SOLUTIONS 25

PLAN TABLE COLUMNS
ACCESSCREATOR
ACCESSNAME
INDEXONLY
SORTN_UNIQ
SORTN_JOIN
SORTN_ORDERBY
SORTN_GROUPBY

THIRDWARE TECHNOLOGY SOLUTIONS 26

PLAN TABLE COLUMNS
SORTC_UNIQ
SORTC_JOIN
SORTC_ORDERBY
SORTC_GROUPBY
TSLOCKMODE
TIMESTAMP
PREFETCH
MIXOPSEQ

THIRDWARE TECHNOLOGY SOLUTIONS 27

QUERYNO & QBLOCKNO
A number identifying statement being EXPLAINED.
DB2 assigned in case of PLAN/PACKAGE
USER Assigned SET QUERYNO
QBLOCKNO : Position of the query in the statement being EXPLAINED

THIRDWARE TECHNOLOGY SOLUTIONS 28

APPLNAME & PROGNAME
APPLNAME : Plan Name
PROGNAME : Program/Package name

THIRDWARE TECHNOLOGY SOLUTIONS 29

METHOD
0 Table Access
1 Nested Loop Join
2 Merge Scan Join
3 Sorts needed by ORDER BY, GROUP BY, SELECT, DISTINCT or UNION
4 Hybrid Join

THIRDWARE TECHNOLOGY SOLUTIONS 30

TNAME, TABNO & ACCESSTYPE
Table Name and position from the FROM clause
ACCESSTYPE :
I By an Index
N : Index scan when predicate is IN
R : Table Space Scan
M : Multiple Index scan
MX : Index scan
MI : Intersection of multiple Indexes
MU : Union of multiple Indexes

THIRDWARE TECHNOLOGY SOLUTIONS 31

MATCHCOLS, ACCESSCREATOR,
ACCESSNAME & INDEXONLY
 MATCHCOLS : Number of index keys used in index scan
 ACCESSCREATOR : Creator of the Index
 ACCESSNAME : Name of the index
 INDEXONLY : Y/N (Whether Index is sufficient to locate the data)

THIRDWARE TECHNOLOGY SOLUTIONS 32

SORTN_*, SORTC_*
_UNIQ : Y/N Whether sort is performed to remove duplicates
_JOIN : Whether sort is performed on table when METHOD is 2 or 4
_ORDERBY : If order by results in a sort
_GROUPBY : If group by results in a sort
SORTC_* : Same as SORTN but for composite table

THIRDWARE TECHNOLOGY SOLUTIONS 33

TSLOCKMODE, TIMESTAMP, PREFETCH
Lock Mode of table or tablespace
IS, IX, S, U, X
TIMESTAMP at which EXPLAIN STATEMENT is BOUND
PREFETCH : List Prefetch or Sequential Prefetch

THIRDWARE TECHNOLOGY SOLUTIONS 34

Explain Query
EXPLAIN SET QUERYNO = 10 FOR SELECT
C1, C2, C3 from T1
WHERE C1 = 5 and C2 = ?
ORDER BY C3
Select * From Plan_table where queryno = 10

THIRDWARE TECHNOLOGY SOLUTIONS 35

SQL Query Tuning – Some Check Points

 Avoid SELECT *, List (only) the columns to be selected

 FETCH FIRST x ROWS ONLY, whenever possible, especially QMF in Test

 Be Careful in using Wild Characters (LIKE, %)

 Avoid DISTINCT and UNION if really not necessary; Use UNION ALL instead of UNION

 Code Efficient WHERE Clauses with maximum possible filters, Index Keyed Columns in WHERE

 Use Constants and Literals if the values will not change for the next 3 years (for static queries)

THIRDWARE TECHNOLOGY SOLUTIONS 36

SQL Query Tuning – Some Check Points

 List Columns for insert

 Update only Changed Columns

 Use BETWEEN instead of <= and >=

 Use IN instead of LIKE

 Avoid using NOT (Except with EXISTS)

 Use NOT EXISTS instead of NOT IN

 Code Predicates on Indexed Columns

THIRDWARE TECHNOLOGY SOLUTIONS 37

SQL Query Tuning – Some Check Points

 Do not use Arithmetic Expressions in a Predicate (Remove Calculations in Join and Where Clause)

 SELECT COLA, COLB, COLC ORDER BY COLC

 Consider using DELETE / INSERT instead of FOR UPDATE OF

 Use ORDER BY when sequence is important

 Drop Unused Indexes

 Better to create Indexes on columns that have integer values instead of characters. Integer values use less
overhead than character values

 Use Joins instead of Subqueries or combining multiple Single SQLs

THIRDWARE TECHNOLOGY SOLUTIONS 38

SQL Query Tuning – Some Check Points
 JOINS

o Minimize number of tables in a Join

o Join using SQL instead of Program Logic

o Inner Joins preferred over Outer Joins, as applicable

o Avoid Cartesian products / Cross Joins

o JOINs on common indexed column or columns shared the Joined tables is preferred.

o Make sure to use the most restrictive JOIN table first; and provide as many indexed and restrictive
WHERE clauses as possible to limit the amount of data that needs to be Joined to the second or
subsequent tables.

THIRDWARE TECHNOLOGY SOLUTIONS 39

Conclusion

Brainstorming and Q&A Session

THIRDWARE TECHNOLOGY SOLUTIONS 40

Thank You

THIRDWARE TECHNOLOGY SOLUTIONS 41