DB2 SQL Tuning Tips for z/OS Developers, Rough Cuts

Description

• Copyright 2013
• Dimensions: 6" x 9"
• Pages: 160
• Edition: 1st

• Rough Cuts
• ISBN-10: 0-13-303849-1
• ISBN-13: 978-0-13-303849-1

This is the Rough Cut version of the printed book.

The Definitive Solutions-Oriented Guide to IBM® DB2® for z/OS®: Now Fully Updated for Both v9 and v10!

The largest database tuning performance gains can often be obtained from tuning application code, and applications that use SQL to retrieve data are the best candidates for tuning. This well-organized, easy-to-understand reference brings together more than 100 SQL-related skills and techniques that any developer can use to build and optimize DB2 applications for consistently superior performance.

DB2 tuning expert Tony Andrews (“Tony the Tuner”) draws on more than 20 years of DB2-related experience, empowering you to take performance into your own hands, whether you’re writing new software or tuning existing systems. Tony shows you exactly how to clear bottlenecks, resolve problems, and improve both speed and reliability.

This book fully reflects the latest SQL programming best practices for DB2 V9 and DB2 V10 on z/OS: techniques that are taught in no other book and are rarely covered in general DB2 SQL courses. Drawing on his extensive consulting experience and highly praised training with Themis Inc., Tony also presents practical checklists and an invaluable 15-step methodology for optimizing virtually any DB2 application.

Coverage includes

• Empowering developers on knowing what to do and where to look in resolving performance problems in queries or programs
• Providing many programming and SQL coding examples
• Establishing standards and guidelines that lead to high-performance SQL
• Implementing time-efficient code walkthroughs to ensure that your standards are followed
• Focusing on the small number of SQL statements that consume the most resources
• Identifying simple solutions that deliver the most sizable benefits
• Optimizing performance by rewriting query predicates more efficiently
• Providing a better understanding of SQL optimization and Runstat statistics
• Recognizing opportunities to tweak your code more effectively than the Optimizer
• Optimizing SQL code with COBOL applications
• Efficiently checking for the existence of data, rows, or tables
• Using Runstats’ newest capabilities to consistently optimize paths to data



Sample Content

Table of Contents

CHAPTER 1  SQL Optimization Top 100+     1
1. Take Out Any/All Scalar Functions Coded on Columns in Predicates     2
2. Take Out Any/All Mathematics Coded on Columns in Predicates     3
3. Code Only the Columns Needed in the Select Portion of the SQL Statement     4
4. Stay Away from Distinct if Possible     4
5. Try Rewriting an In Subquery as an Exists Subquery     5
6. Always Make Sure Host Variables Are Defined to Match the Columns Datatype     6
7. Because Or Logic Can Be Problematic to the Optimizer, Try a Different Rewrite     6
8. Make Sure the Data Distribution and Other Statistics Are Good and Current in the Tables Being Processed     8
9. Use UNION ALL in Place of UNION Where Possible     9
10. Consider Hardcoding Versus Using a Host Variable     9
11. Minimize DB2’s SQL Requests     11
12. Try Rewriting Range Predicates as Between Predicates     12
13. Consider Using Global Temporary Tables     13
14. Give Prominence to Stage 1 over Stage 2 Predicates     14
15. Remember That the Order of (Some) Predicates Does Matter     15
16. Streamline Multiple Subqueries     16
17. Index Correlated Subqueries     17
18. Get to Know the DB2 Explain Tool     17
19. Use Tools for Monitoring     18
20. Employ Commit and Restart Strategies     19
21. Implement Good Index Design     19
22. Avoid Discrepancies with Non-Column Expressions     20
23. Begin with All Filtering Logic Outside Application Code     21
24. Ensure That Subquery Predicates Involving Min and Max Have the Possibility of Nulls Being Returned Handled     21
25. Always Code For Fetch Only or For Read Only with Cursor Processing When a Query Is Only Selecting Data     22
26. Avoid Selecting a Row from a Table to Help Decide Whether the Logic in the Code Should Execute an
Update or an Insert     23
27. Avoid Selecting a Row from a Table in Order to Get Values for an Update     23
28. Make Use of Dynamic SQL Statement Caching     23
29. Avoid Using Select *     24
30. Watch Out for Nullable Columns or Times When SQL Statements Could Have Nulls Returned from the Database Manager     25
31. Minimize the Number of Times Open and Close Cursors Are Executed     25
32. Avoid Not Logic in SQL     26
33. Use Correlation IDs for Better Readability     26
34. Keep Table and Index Files Healthy and Organized     27
35. Take Advantage of Update Where Current of Cursor and Delete Where Current of Cursor     27
36. When Using Cursors, Use ROWSET Positioning and Fetching Using Multiple-Row Fetch, Multiple-Row Update, and Multiple-Row Insert     28
37. Know the Locking Isolation Levels     28
38. Know Null Processing     30
39. Always Program with Performance in Mind     31
40. Let SQL Do the Work     32
41. Code with Lock Table     32
42. Consider OLTP Front-End Processing     33
43. Consider Using Dynamic Scrollable Cursors     34
44. Take Advantage of Materialized Query Tables to Improve Response Time (Dynamic SQL Only)     35
45. Insert with Select&nbs



Updates

Submit Errata

