Front cover

DB2 for z/OS and OS/390 Version 7
Performance Topics
Description of performance and availability related functions Performance measurements of new or enhanced functions Usage considerations based on performance

Paolo Bruni Leif Pedersen Mike Turner Jan Vandensande

ibm.com/redbooks

International Technical Support Organization DB2 for z/OS and OS/390 Version 7 Performance Topics July 2001

SG24-6129-00

Take Note! Before using this information and the product it supports, be sure to read the general information in “Special notices” on page 235.

First Edition (July 2001) This edition applies to Version 7 of IBM DATABASE 2 Universal Database Server for z/OS and OS/390 (DB2 for z/OS and OS/390 Version 7), Program Number 5675-DB2 and the DB2 Version 7 Utilities Suite, Program Number 5697-E98. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California 95120-6099 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 2001. All rights reserved. Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xv Special notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii IBM trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Key performance enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Performance highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Query performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Transaction performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Utility performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Subsystem and host platform synergy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2. Overview of DB2 Version 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 DB2 at a glance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Application enablement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Network computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Performance and availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Data sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.6 New features and tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 DB2 V7 packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Net Search Extender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Migration to DB2 Version 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Planning for migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Reasons to migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Functions requiring no effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Functions requiring a small effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Functions requiring some planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3. SQL performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Changes to Explain tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 PLAN_TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 DSN_STATEMNT_TABLE changed columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Explain headings used in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Parallelism for IN-List index access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 5 5 6 7 9 9

11 12 12 14 15 16 16 17 18 20 20 20 20 22 22 22 23 25 26 26 27 27 28 28 30 33 33

© Copyright IBM Corp. 2001

iii

. . . . . . . . . . . 3. . . . . . . . . . . . . . . .2 Performance . . . . . . . . . . . . . . . .11 Joining on columns of different data types . . . . . . . .5. . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Restrictions . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . . . . . . 3. . . . .1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . .4 Recommendations . . . . . .6 UNION everywhere . . 3. . . . . 3. . . . . . . . . . . . . . . . . . .10 Fewer sorts with ORDER BY . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Restrictions on usage . . . . . . . . . . . . . . . . . . . .4 Subqueries that will still not be transformed in DB2 V7 . . . .7 Conclusions . . .4. . . . . . . . . . . . . . . . .7. . . . .7. . . . . . . . . . . . . . . . . . . . . . . . . .7 Recommendations . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . 3. . . . . . . . . . . . . . . . . 3. .3 Requirements for subquery pruning . . . . . . . . . . . . . . . . . . . . . . .4. 3. . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Recommendations . . . . . . . . . . . . . .5. . . . . . . . . . . . 3. . . . . . . . . . . . . .4 UNION ALL materialization . . . . . . . . . . . . . . . . . . . . .3. . . . . .3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Description . . .6. . . . . . . . . . . . . . . 3. . . . . . . .4 Conclusions . . . . . . . .3. .10. . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . .1 Executing the self-referencing UPDATE/DELETE . . . . . . 3. . . . . .1 Description . . . . . . . . . . . . . . . . .1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . 3. . .4 Correlated subquery to join transformation . . . . . . . . . 3. . . . . . . . . . . . . .5 Recommendations . . . . 3. . . . . . . . . . . . . . . . . . . .5 Performance . . . . . . . . . . . . . . . . . .2 Performance .5 UPDATE/DELETE with self-referencing subselect . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . . . .6 Conclusions . . . . 3. . . . . . . . . . .6. . . . . . . .6 Conclusions . . . . . .3 IN predicate with subquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Support for EXISTS predicate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Quantified predicates . .7. . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Performance . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Searched UPDATE and DELETE support . .9. . . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . 3. . . . . . . . 3. . . . . . . .4. . . 3. . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . .2 Performance . . . . . . . . . . . . . . .3 Performance . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10. . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . .5. . 3. . . . . . . . . . . . . . . . . .3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . .3 Conclusions . .9. . . .3 Row value expressions . . . . . . . . . . . . . . . . . . . . . . . . . .10. . . . . . . . . . . . . . . . . .6. 3. . . . . . . . . . . . . . . . . . iv 34 34 34 35 36 36 38 38 38 39 41 41 42 43 44 45 45 45 46 47 47 48 48 49 49 53 57 59 59 60 60 60 61 64 69 69 70 70 71 72 72 72 72 74 74 74 74 75 76 77 77 77 77 DB2 for z/OS and OS/390 Version 7 Performance Topics . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.1 UNION syntax changes . . . . . . . . . . . . . . . .1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . .5. . . . . . . . . . . . . .1 Equal and not equal predicates .6. . . . . 3. .9. 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Fetch first n rows . . . . . . . . . . . .3 Conclusions . . . . .4 Recommendations . . . . .8.6 Restrictions and potential problems . . . . . . . . . . . 3. . . . 3. . . . . . . . . . . . . . . . . . .4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . .4. . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . 3. . . .7 Recommendations . . . . .8. . . . . . . . . . . . . . . . . . . . 3. . . . . . . . 3. . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . .11. . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . .2 Optimization . . . . . . . . . . . . .3. . . . .6. . . . . . . . . . . . . . . . . .5 Performance . . . . . . 3. . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Recommendations . . . . . . . . . . . . .9 MIN/MAX enhancement . . 3. . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Removal of uniqueness constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Scrollable cursors . . . . . . . . . .3. . . . . 3. . . . . . . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . . .8 DDL concurrency improvement. . . . . . . . . . . . . . . . . . . . . . . . . . .1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . 4. . .12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . . . . . . . . .13. . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Recommendations .2 TEMPLATE . . . . . . . .3. . . . . . . . . . . . . 5. . . . . . . . .13. . . . . . . . .3 Conclusions . . . Chapter 6. . . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11. . . . . . . . . . . . 3. . . . . . . 5. . . . . . . . . . . . .4 Adding workfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Recommendations . . . . . . . . . . . .1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12. . Availability and capacity enhancements . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 VARCHAR index-only access . . . . 6. . . . . . . . . . . . . . . . .2 Displaying the current settings . . . . . . . . . . .1 Description . . . . . . . . . . . . . . . . . . . . 4. . 3. . . . . . . . . . . . . . . . . . . .1 Recent star join enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . 5. . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . .13. . . . . . . .1 SET SYSPARM command . .2 Performance . . . . . . . . . . . . .11. . . . . . . . . . . .5 Evaluate uncommitted. . . . . . . .2 Recommendation . .2. 4. .12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Long running UR warning message . . . . . . . . . . . . . .2 Subsecond deadlock detection . . . . . . . 4. . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . 4. . 5. . .14. . . . . . . . . . . . . . . . . . . . . . . .3 Parameter behavior with online change . . . .3 Virtual storage constraint relief . . . . . . . . . . . . . . . . . . . .4. . . . . . 4. .1. . . . . . . . . . . . . . . . 5. . . . . . . . Contents 79 79 79 79 80 81 81 81 81 81 82 82 82 82 83 87 88 89 90 91 91 92 92 93 94 98 98 98 98 99 99 101 102 102 102 102 105 107 107 107 107 108 109 110 111 111 112 113 114 114 115 v . . .1 CATMAINT utility performance .6 IRLM enhancements . . . . . . . .2 Time controlled checkpoint interval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 LISTDEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . .1 Asynchronous preformat . . 3. 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . DB2 subsystem performance . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . .3 Retry of log read request . . . . . . . . . . . . 5. . . . . 4. . . . . . .4 CATMAINT utility. . . . . . . . .3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . .4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13. . .1. . . . . . . . . . . . 4. . . . . . . . .3 CANCEL THREAD NOBACKOUT . . .5. .3 Conclusions . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . .2 Performance . . .1 Instrumentation enhancements. . . . . . .14 Star join . . . . . 5. . . . . . . . . .2 Performance . . . . . . . . . . . .1 Dynamic change of IRLM timeout value . . . . . . . . . . . . . . . . . . . . . . . . Utility performance . 5. . .1 Dynamic utility jobs . 5. . . . . . . . . . . . Chapter 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Bind improvements . . . . . . . . . . . . . . . Chapter 5. . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . .1 Log suspend and resume . . . . . . . . . . . . . . . .2 Consistent restart enhancements . . . . . . . . . . . . . . . . . . . . . . . . .1 Online DSNZPARM. . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . .1 Asynchronous preformat performance . . . . . . . . . . . .5 Log Manager enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . .7 Reduced logging for variable-length rows . . . . . 3. . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . . . .2 Parallel data set open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . .1. . . . . . . . . . . . . .1 Performance .2 Database address space — virtual storage consumption. . . . . . . . . . . . . . 4. 4. . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Log-only recovery improvement . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. .8 Cross Loader. . . . . . . . .5 Performance considerations . . . . . . . 8. . . . . . . . . . . .1 Performance measurements. . . . . . . . . . . . .2 Unloading partitions in parallel . . . . . . . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 8. .5. . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Stored procedures with COMMIT/ROLLBACK . .3 Online LOAD RESUME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Statistics history . . . 6. . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . 116 117 117 117 118 121 122 124 125 127 127 127 128 129 131 131 132 134 138 138 139 139 141 141 147 148 148 149 150 151 152 153 153 155 157 157 158 159 161 162 162 165 166 167 167 167 168 168 169 170 170 vi DB2 for z/OS and OS/390 Version 7 Performance Topics . .1 Bypass group attach processing on local connect — groupoverride . . . . . . . . . . . . . . . . . . . 8. . . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . .3 group attach support for DL/I batch jobs . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . .1. . . . . . . . . . 7. . . . . . .3. . . . .5 Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . .5 IMS group attach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 BUILD2 parallelism for NPIs . .2 Building indexes in parallel . . .2. . . . . . . . . . . . . . . . 7. . . 7. . . . . . 6. . . . . . . . . . . . . . . . . .5 Online REORG enhancements . . . . 8. . . . . . . . . . . . . . . . . . . . .2. . . . . .1 OPTIMIZE FOR m ROWS . . . 6. . . . .4 UNLOAD utility . . . . .7. . . 8. . . . . 6. . . . . . . . . . . . . . . . . . . .3 OPTIONS . . . . . . . . .6. 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 FETCH FIRST n ROWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . . .4 Performance considerations using new statistics columns . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Performance measurements. . . . . . . . . . .7 COPYTOCOPY utility . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . .6 RUNSTATS enhancements . . . . . . . . . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . .2 LOAD partition parallelism . . . . . 8. . . . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . .1 Fast switch . . . . . . . . . 6. . . .2 Performance considerations . . . . . . . . . . Data sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . 6. . . . . . . . .1. . . . . . 6. . . . . . . . . . .3. . . . . . . . . . . 6. . . 7. .4 RESTART processing . . . . . . . . . . . . . . . . . . .5. . . . . .1 Performance measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . .5. . . . . . Chapter 7. . . . . . . . . . . . . . . . . . . . . .1 Performance considerations .1. . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Singleton select. . . . . . . . . . . . . . . . . . . . . . . .1 IMMEDWRITE bind option before DB2 V7 . . . . . . . . . . . . . . . . . . . . .2 DB2 catalog changes . . . . . . . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . 6. .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1 LOAD partitions in parallel . . . . . . . . . . . . . . . . 7. . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . 8. . . . 6. . . . . . . . . . . . .3. . . . . . .9 MODIFY RECOVERY enhancement . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. . .8. . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. . . . . . . . . . . .3 Java stored procedures with JVM . . . 7. . . . . . . . . . . . . . . . . . . . . . . . . . .1 The EXEC SQL statement . . . .4. . . . . . . . . . . . . . 7. . . . .2 Group attach enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Performance measurements. . . . . . . . . . . .3 Force update of aggregate statistics . . . . .1 Coupling Facility Name Class Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . . . . . . . . . . . . . . . . . .3 IMMEDWRITE bind option . . . . Network computing performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . .4 CICS group attach . .1 Performance considerations . . . . . . . . . 7. . . . . . . . . . . . . .3 Performance recommendations . . . . . . . . . . . . . . . . . . . 6. . . . . .3 Unload from copy data sets . . . . . . . . .3 DRAIN and RETRY. .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . . . .4 SQLJ and JDBC performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . .6. . . . . .2 Support for local connect using STARTECB parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . . . 6. . . . 6. .6 DRDA server elapsed time reporting . . . . . . . . . . . . . .3 Performance measurements. . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . . . . . . . . . . . . . . . . .

.4. . .6 Purge retained locks . . . . . . . . . . .3. . . . . . . 9. . . . 10. . . . . . . . . . . . . . . .3 FlashCopy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Command syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Hardware versus software striping . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Performance measurements. . . . . .3.6 Miscellaneous items . . . .2. . . . . . . . . . . . . . . . . . . . . . . . 8. . Enabling VSAM I/O striping in OS/390 V2R10 . . . . . . . . . . . . . . . . . . . . . . . . . 10. . . . . . .6. . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 DSNZPARM to synchronize IFI records . . . . . . . . . . . . . . . . . . . .3. . . . .1 Index Advisor process for DB2 for z/OS and OS/390 . . . . . . . . . . 10. . .2 DB2 PM changes and new functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . . 219 Contents vii . . . . . . . . . .4. . . . . Chapter 9. . . . . . . . . . .1 Statistics Report Long . . . .2 More efficient message handling for CF/structure failure . . . . . . . 10. . . . . . . . . 8. . . . . . . .1 Notifying incomplete units of recovery during shutdown . .3 Automatic Alter for CF structures (Auto Alter). . . . . . . . . . . . . . 10. . . . . . . . . . . . . . .4 DB2 Estimator . . . . . 219 Statistics report information .2 VSAM Data Striping . 10. . . . . . . . . . . . . . . . . . . . . . . . . . . .6. .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. . . .1. . . . . . 8. . . . . . . . . . . . .2. . . . Chapter 10. . . . . . . . . . . . . . . . . . . . 9. . . . .4 Measurements .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . 10. . . .3 Index Advisor . . . . . . . . . . . 9. . . .6. . . . . . . . . . . . . . . . . . . . . . . . 9. . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . .1. . . . . .1 DB2 and zSeries overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Considerations . . . . . . . . . . . . . .4 CF lock structure duplexing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . .3. . . . . . . . 9. . . . . . . . . . .4 DB2 Restart Light . . . . . .2 VSAM I/O striping versus PAV . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . . . . . . . . . . . . . . . . . . .2 Description of VSAM striping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 zSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 IMMEDWRITE bind option performance. . . . . . . . . . . . . . . . . . . . . . . . 10. . . . . . . . . . . . . . . 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. . 170 171 171 172 173 173 173 175 176 176 176 176 176 176 177 177 179 180 180 182 185 185 185 189 192 193 194 194 195 195 195 196 197 198 198 199 204 204 204 204 205 206 206 208 209 Appendix A. . . . . 10. . . . . . . .5 CF lock structure size . . . .3. . . . . . . . . . . . . . . . . . . . . . . . Synergy with host platform . . . . . . .2 Accounting Report . . . . . . . . . . . . .1 New IFCIDs. . .3 Performance measurement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updatable DB2 subsystem parameters. . . . . 9. 8.5 Persistent Coupling Facility Structure sizes .1. . . . . . . . . .4 Running the Index Advisor . . . . . . . . . . . . . . . . . . 8. . . . 8. . . . . . . . . . . . . . . . . . . . .1 Description . . . . . . . . . . . . . .2. Performance tools . .1. 10. . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . 211 Appendix B. 10. . . . . . . . . . . . . . .1 IFI enhancements . . . . . .3 VSAM Data Striping and DB2 . . . . . . . . . . . . . . . . . . . . . .7 CURRENT MEMBER register. . . . . . . 9. . . . . . . . . . . . . .4 IMMEDWRITE bind option performance measurement . . . . . . . . . . 9. . . . . . . . . . . . . . . . . . . . 9. .6 Availability . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . 215 Appendix C. . . . . . . . . .1 Parallel Access Volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. . . . . . . . . . . . . . . .2 Modeling DB2 for z/OS and OS/390 . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . . . . . 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. .2. . . . . . . . . . 8. . . . . . . .2. . . A method to assess the size of the buffer pools . . . . . . . . .4. . . .6. . . . . . . . . . . . . . . . . . . . . . .3 ESS enhancements . .3. . .2 Changed IFCIDs . . . . . . . . . . . .2 IMMEDWRITE bind option in DB2 V7. . . 9. . . . . . . . .3 Collecting the SQL workload. . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . . .

. Job output of UNLOAD utility . . . . . . . . . . . . . .. . . .. . . . . . .. . . . . . . . . . . . ... .. . . . . . . . . .. . . . . . . . . . ... . . . . . . . . . . . . . .. . . . . . . .. . . . . .. . .. . . . . . . . ... . . . . . . . . .. . . . . . . . .. . . . . . .. . . . . . .. . . . . . . . . . . . . .. . . COPY output with LISTDEF and TEMPLATE . .. .. .. . . . . . . . . . . . ... . ... . 239 Index . . . . . . . . . . . . . . . .. . . Job output of LOAD partition in parallel . . .. .. . . . .. . .. . ... . . .. .. . . . . 223 Appendix E. .. . . . .. . .Concepts . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . .. . . . . .... . . . . . . . .. . . . .. . . . . . . .. . Sample utilities output .. ... . . . . . . . . . . . . ... . . . . . . . . . . . .. .. . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . ... . . . . . . . . . . . .. Other resources . . .. . . . .. . . . . . . . . . . 241 viii DB2 for z/OS and OS/390 Version 7 Performance Topics . .. .. . 237 237 237 238 238 238 Abbreviations and acronyms . . . . . . . . 220 Spreadsheet example . . . . .. . . . . . . . . ... . . . . . .. . . 235 Related publications . . . . . . ... . .. . . . . . . . . . . . . . IBM Redbooks collections. . .. . .. . .. . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .. .. . . . .. . . . . . . . . . . . .. . . . .. . . . . . .. . . .. . .. . . . . . ... . . . . .. . . . . . . . . . . . .. Sample PL/1 program . . . . . . . . Referenced Web sites . . . . . . . . . . . . . .. . . . . . . How to get IBM Redbooks .. . . . . . .. . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . .. .. . . .. . . . . . 220 Evaluation . . . . . . . . . . . . . .. . . . . .. . Job output of Online REORG . . . . . .. . . . IBM Redbooks . . .... . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . .. . . . . . . . . . . . .. . ... . . . .. . . . .. . . . . . .. . . . . . . . .. . . . . . . . . . 227 227 229 231 232 Special notices . . . .. .. . . . . . . . . 221 Appendix D. . . . . . . . . . . . . .. .. . . . . . . . . . . . . . .. . .. ... .. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Table expression syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Subquery transformation performance test for update . . . . . . . . . 34 Row value expression in quantified predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Distribution of joins and aggregations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 © Copyright IBM Corp. . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Quantified predicate syntax . . . . 52 EXISTS predicate syntax . . . . . . . . . . . . . . . . . 32 Row value expression in basic predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Subquery transformation — example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 DB2 Version 7 plan table . . . . . . . . . 61 Fetch syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2001 ix . . . . . . . . . 37 Row value expression and Explain example 2 . . . . . . . . . . . . . 56 Possible query rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 IN-List parallelism for single table access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Subquery transformation for DELETE . . . . . . . . . . . . . . . . . . .Figures 1-1 1-2 1-3 1-4 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 3-12 3-13 3-14 3-15 3-16 3-17 3-18 3-19 3-20 3-21 3-22 3-23 3-24 3-25 3-26 3-27 3-28 3-29 3-30 3-31 3-32 3-33 3-34 3-35 3-36 3-37 3-38 3-39 3-40 3-41 3-42 3-43 3-44 Improvements in maximum log rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 UNION without pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Subquery transformation — example 1 . . . . . . . . . . . . . . . . . . . . . . . 37 Rewritten query and Explain example 2 . . 31 IN-List performance test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Multiple ORDER tables. . . . . . . . . . . 30 IN-List performance test for single table access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 UNION in a table expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Table and index definitions for correlated subquery examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 IN predicate syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . one per month. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Row value expressions Explain example 1 . . . . . . . . . . . . . 8 Online LOAD RESUME and INSERT . . . . . . . . . . . . . . . . . 41 Subquery transformation for UPDATE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 UNION optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 UNION in a predicate example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Table and index definitions for IN-List parallelism example. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Elapsed time in renaming a data set by device type . . . . . . . 42 Subquery transformation performance test for select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 IN predicate syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Basic predicate syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 IN-List parallelism for outer table of join. . . . . . . . . . . . . . . . . . . 44 UPDATE with self-referencing subquery in WHERE clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 UPDATE with self-referencing subquery in SET clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 DECLARE GLOBAL TEMPORARY TABLE syntax . . . . . . . . . . 47 Self-referencing UPDATE performance test . . 49 UNION in a view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Two-step processing for an UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Row value expression for IN subquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Explain output for UNION optimization . . . . . . . 46 Positioned update with self-referencing subquery not supported . . . . . . . . 58 DECLARE CURSOR syntax . . . . . . . . . 40 Subquery transformation — example 2 . . . . . . . . . . . . . . . 8 CATMAINT executions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 CREATE VIEW syntax. . . . . .

. . . . . . . . . . . . . . . 83 Synchronous and asynchronous preformat . . . . . . . . . . . . . . . . . . . . . . . . 80 Index-only access when VARCHAR in WHERE clause only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 MAX function access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Partition parallel LOAD without building indexes in parallel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Sample JCL from DB2 V6 and DB2 V7 using TEMPLATE . . . . . . . . . . . . . . . 121 UNLOAD enhanced functionality . . . . . . . . 143 Fragmented LOB table space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Fetch positioning options . . . . . 145 Physical view before reorganization. . . . . . . . . . . . . . . . . . . 90 Parallel data set open performance . . . . . . . . . . . . . . . 73 ORDER BY sort avoidance . . . . . . . . . . . . . . . 146 COPYTOCOPY utility . . . . . . 91 STORAGE STATISTICS report layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Existing MIN function access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 DISPLAY UTILITY output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 DSN1LOGP SUMMARY OF COMPLETED EVENTS report. . . . . . . . . . 68 Existence checking SQL . . . . . . . . . 115 Output from PREVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 DSN1LOGP example . . . . . . . . . . . 71 FETCH FIRST SQL traces. . . . . . . . . . . . . . 107 Sample JCL from DB2 V6 and DB2 V7 using LISTDEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Clustering sequence . . . . . . 131 Data unavailability when running REORG SHRLEVEL CHANGE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Sort avoidance in a join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Physical view after reorganization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Comparison of migration performance — data sharing case. . . . . . . . . . . . . .3-45 3-46 3-47 3-48 3-49 3-50 3-51 3-52 3-53 3-54 3-55 3-56 3-57 3-58 3-59 3-60 3-61 4-1 4-2 4-3 4-4 4-5 4-6 4-7 5-1 5-2 5-3 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 6-13 6-14 6-15 6-16 6-17 6-18 6-19 6-20 6-21 6-22 7-1 7-2 7-3 7-4 x Open scrollable cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Non-fragmented LOB table space . . . 66 Repositioning without scrollable cursor . . . . . . . . . . . . . . 88 CPU bound test case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Effect of the RETVLCFK parameter. . . . . 154 Elapsed time outside of DB2 per transaction. . . . . . . . . . . . . 80 Star join example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 New UNLOAD utility versus REORG EXTERNAL UNLOAD. . . . . . . 97 RECOVER POSTPONED CANCEL command response . 152 Throughput per SQL statement . . . . . . . . . . . . . . . . . . . . 130 UNLOAD utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Using a DTT instead of a scrollable cursor . . 155 DB2 for z/OS and OS/390 Version 7 Performance Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .START DATABASE FORCE log record . . . . . . . . . 89 I/O bound test case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Cursor definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Join column mismatch Explains. . . . . . . . . . . . . . . . . 114 DISPLAY UTILITY output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Comparison of migration performance — non-data-sharing case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Cross Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Repositioning with scrollable cursor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Unloading partition table in parallelism . . . . . . 149 Output from Cross Loader using DRDA and 3-part names . . . . . . . . . . . . 116 Parallel LOAD jobs per partition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Indirect row reference . . . . . . . . . . . . 70 FETCH FIRST effect on access path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Fetching n rows . . . . . . 120 Partition parallel LOAD with indexes built in parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 CPU time per transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . Data space versus hiperpool update performance . . . . . . . . . . DSNTIPN panel . Accounting report Class 3 changes . . . . . . . . . . . DB2 PM Accounting Class 3 . . . . . . . . . . . . . . . . . . . . Sample data class definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single thread table scan performance — compressed data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IFCID 199 record trace . . . . . . . . . . . . . . . Statistics report P-lock detail . . . . . . . . . . . . . . . . . . . Insert performance with and without compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accounting GBP information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java runtime environment in DB2 V7 . . . . . . Parallel query performance with and without PAV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DB2 PM Statistics Report Long with data set statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extract from LISTCAT command response . . . DEVSERV QDASD command response . . . . . . . Statistics report GBP information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output of D CF command . . . . . . . . . . . . . . . . . . . . Sample spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accounting global contention detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 7-6 7-7 8-1 9-1 9-2 9-3 9-4 9-5 9-6 9-7 9-8 9-9 9-10 9-11 9-12 9-13 10-1 10-2 10-3 10-4 10-5 10-6 B-1 B-2 B-3 B-4 B-5 C-1 Non-singleton SELECT versus singleton SELECT . . . . . . . . . Effect of PAV on I/O response time in msec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample DEFINE CLUSTER command . . . . . . Index Advisor process for DB2 for z/OS and OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IFCID 0217 description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Buffer pool in data spaces performance 64-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interpreted Java stored procedures . . . . . . . . . . . . . . . . . DB2 PM Statistics Report data set statistics . . . . . . . . . . . . . . 156 157 158 167 181 182 184 185 186 187 188 188 189 190 191 192 193 200 201 202 203 207 208 215 216 216 217 217 221 Figures xi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample storage class definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IFCID 0225 description . . . . . . . . . . . . . . . . . . . . . .

xii DB2 for z/OS and OS/390 Version 7 Performance Topics .

. . . . . . . . . . . . . . . . . . . . . . . . . . 69 MAX test results. . . . 44 Self-referencing UPDATE test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2001 xiii . . . . . . . . . . . . . . . . . . . . . 134 BUILD2 — example 1 . . . . 68 Class 2 and Class 3 times for repositioning test . . . 84 Star join access plan: case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Optimal performance for LOAD with SORTKEYS . . . . . . . . . . . . . . . . . . . 85 Catalog tables . . . . . . . . . . . . . . . . . . . . . 135 BUILD2 — example 2 . . 95 CATMAINT performance measurement results. . . . . . . . . . . . . . . . . . . . . . . . . . 126 Online REOG using FASTSWITCH . . . 122 LOAD in parallel with SORTKEYS. . 33 IN-List performance test results for join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Locking with scroll cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Scroll versus normal cursor . . . . . . . . . . . . . . . . . . . 112 LOAD in parallel without SORTKEYS . . . . . . . . . . . . 126 10 parallel jobs inserting 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Buffer pool activity for insensitive versus sensitive cursor . . .000. . . . . . . . . . . . . . 31 Columns in the PART table . . . . . . 65 Scrollable cursor versus DTT bufferpool data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Join column mismatch test results . 95 Subsecond deadlock detection impact . . . . . . . . . . . . . . . . . . . . 66 Scrollable cursor versus DTT locking comparison . . . . . . . . . . . . . . 136 BUILD2 — example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Columns in the CUSTOMER table. . . . . . . . . . . . . . . . . . 48 Select 10 million rows . . . . . . . . . . . . . . . 123 Optimal performance for LOAD without SORTKEYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Running Online LOAD RESUME in parallel with different buffer pool definitions . . . . . . . . 32 Columns in the LINEITEM table. . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Subquery transformation and parallelism . . . . . . . . . . . . . 27 Explain headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Star join access plan: case 1 . . . . . . . . . . . . . . . . . . . . . 31 IN-List performance test results for single table access . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Inserting 2000000 rows . . . . . . . . . . . . . . . . . . . . . 69 Class 2 and 3 times for insensitive versus sensitive cursor. . . . . 48 Self-referencing UPDATE versus INSERT and non-self-referencing update . 33 Subquery transformation select performance . 137 © Copyright IBM Corp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Select one row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 VARCHAR index-only test results . . . . . . . . . . . 65 Accounting Class 2 and Class 3 times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 ORDER BY test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Star join access plan: case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Tables 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 3-12 3-13 3-14 3-15 3-16 3-17 3-18 3-19 3-20 3-21 3-22 3-23 3-24 3-25 3-26 3-27 3-28 3-29 3-30 3-31 3-32 4-1 4-2 5-1 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 6-13 New PLAN_TABLE columns . . . . . . . . . . . . . . . . . . 60 Select 200 thousand rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 BUILD2 — example 5 . . . . . . . . . . . . . . . . . . . 66 Buffer pool activity for repositioning tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .000 rows with different buffer pool definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Subquery transformation update performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 BUILD2 — example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Scrollable cursor versus DTT Class 2 and 3 times . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Immediate write hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restart Light — restart time measurements . RESTART LIGHT storage measurement. . . . . . . . . . . . . . . . . . . Index Advisor workload collection jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modify recovery enhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . New IFCIDs . . . . . . . Utility CPU time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using COPYTOCOPY utility to make additional full image copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping DB2 data types to Java data types . . . . . . . . . . . DB2 log throughput and CPU times. . . . . . IMMEDWRITE(PH1) vs. . . . . . 137 137 138 148 150 160 161 171 172 172 174 175 180 182 194 203 206 207 xiv DB2 for z/OS and OS/390 Version 7 Performance Topics . . . . . . . BUILD2 — example 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BUILD2 — example 8 . . . . . . . . . . . . . . . . . . . . . . . .6-14 6-15 6-16 6-17 6-18 7-1 7-2 8-1 8-2 8-3 8-4 8-5 9-1 9-2 9-3 10-1 10-2 10-3 BUILD2 — example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommendations and responsibilities . . . . IMMEDWRITE(PH1) vs. . . . . . . . . . . . . . . . . . Define-Extent Domain in DB2 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMMEDWRITE(NO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMMEDWRITE(YES) . . . . . . . . . . . . . . . . . . . . Changed IFCIDs . . . . . . . . . . . . .

and the new Restart Light option for data sharing environments. in development and in the field. Before joining the ITSO in 1998. 2001 . or just DB2 V7 throughout this book) is the eleventh release of DB2 for MVS. Leif first designed and developed business applications running against DB2. San Jose Center. His areas of expertise include backup and recovery. These enhancements include performance and availability delivered through new and enhanced utilities. Thanks to the following people for their contributions to this project: Emma Jacobs Yvonne Lyon IBM International Technical Support Organization. It provides considerations and recommendations for the implementation of the new functions and for evaluating their performance and their applicability to your DB2 environments. the option to eliminate the DB2 precompile step in program preparation. He has 30 years of experience in the mainframe database management field. This IBM Redbook describes the performance implications of several enhancements made available with DB2 V7. and. Mike Turner is an independent consultant based in the United Kingdom. His areas of expertise include DB2 performance. where he conducts projects on all areas of DB2 for OS/390. scalability. Jan Vandensande is an IT consultant and teacher at Jeeves Consulting in Belgium. support for UNICODE encoded data. and the definition of view with the operators UNION or UNION ALL. and SQL language enhancements for e-business while building upon the traditional capabilities of availability. dynamic changes to the value of many of the system parameters without stopping DB2. in the last 8 years. support for COMMIT and ROLLBACK within a stored procedure. such as scrollable cursors. The team that wrote this redbook This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization San Jose Center. Paolo Bruni is on assignment as a Data Management Specialist for DB2 for OS/390 at the International Technical Support Organization. This book will help you understand why migrating to Version 7 of DB2 can be beneficial for your applications and your DB2 subsystems. Before joining Jeeves Consulting in 1995. He has 20 years of experience in the database management field. application development. He has taught extensively on these topics. and performance. Jan worked as an IMS and DB2 system administrator in the financial sector. There are many improvements to usability. His areas of expertise include DB2 performance and database design. and data sharing. Paolo worked as a Consultant IT Architect in IBM Italy. Paolo’s work has been mostly related to database systems. It brings to this platform many new data support. he assumed the role of DB2 system administrator. recovery. Leif Pedersen is an Advisory IT specialist in IBM Denmark with 12 years of experience with DB2. San Jose Center xv © Copyright IBM Corp. During his 31 years with IBM. data sharing. During this period. and performance.Preface IBM DATABASE 2 Universal Database Server for z/OS and OS/390 Version 7 (DB2 Universal Database Server for z/OS and OS/390 Version 7.

IBM Germany Bart Steegmans IBM Belgium xvi DB2 for z/OS and OS/390 Version 7 Performance Topics .Jeff Berger Chuck Bonner Ben Budiman John Campbell Hsiuying Cheng Roy Cornford Dan Courter Kathy Devine Graig Friske Gene Fu James Guo Robert Gilles Akiko Hoshikawa Eva Hu Jeff Josten Gopal Krishnan Ching Lee Lee Liu Bruce McAlister Roger Miller Mary Mui Chris Munson Mai Nguyen Jim Pickel Jim Pizor Dave Raiman Jim Ruddy Akira Shibamyia Kalpana Shyam Joe Sinnott Jr Jim Teng Annie Tsang Yoichi Tsuji Steve Turnbough Frank Vitro Jane Wang Yung Wang Maryela Weihrauch Manfred Werner David Witkowski Chung Wu Casey Young Jon Youngberg IBM Silicon Valley Laboratory Ying Chang IBM San Jose Laboratory Vasilis Karras IBM International Technical Support Organization. Poughkeepsie Center Norbert Jenninger DB2 PM Development.

Preface xvii .com/redbooks Send your comments in an Internet note to: redbook@us.com Mail your comments to the address on page ii.ibm.Special notice This publication is intended to help managers and professionals understand and evaluate the performance and applicability to their environment of the new functions introduced by IBM DATABASE2 Universal Database Server for z/OS and OS/390 Version 7 and DB2 Version 7 Utilities Suite. Please send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm. The information in this publication is not intended as the specification of any programming interfaces that are provided by IBM DB2 UDB Server for z/OS and OS/390 Version 7 and the DB2 Version 7 Utilities Suite. IBM trademarks The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries: e (logo)® IBM ® OS/390 DB2 Redbooks Redbooks Logo S/390 DATABASE 2 Comments welcome Your comments are important to us! We want our IBM Redbooks to be as helpful as possible. See the PUBLICATIONS section of the IBM Programming Announcement for IBM DB2 UDB Server for z/OS and OS/390 Version 7 and DB2 Version 7 Utilities Suite for more information about what publications are considered to be product documentation.

xviii DB2 for z/OS and OS/390 Version 7 Performance Topics .

data sharing. “Overview of DB2 Version 7” on page 11 contains a more general but brief description of most the functions available with DB2 V7. The DB2 V7 environment is available for the z/OS and OS/390 platforms either for new installations of DB2 or for migrations from DB2 UDB for OS/390 Version 6. by means of analyzing the path length for single-thread and multi-thread measurements. Similar measurements take place also for the performance assessment of the new DB2 V7 functions. Introduction IBM DB2 Universal Database Server for z/OS and OS/390 Version 7 (DB2 V7 throughout this redbook) is the eleventh release of DB2 for MVS and brings to this platform the data support. DB2 and the MVS platform continue to evolve. from DB2 for OS/390 Version 5. SG24-6121.1 Chapter 1. describes the measured environments. scalability. As for each new version of DB2. network computing. This redbook is not exhaustive and does not include all descriptions and measurements related to the new V7 features. This is an on-going process during the whole development cycle that involves a minimum of two very active releases of the product. at the different stages of DB2 product development. application development and SQL language enhancements for e-business while building upon the traditional capabilities of availability. and performance. In this chapter we briefly introduce the major DB2 V7 enhancements specifically related to performance in the areas of SQL. is also useful and is referenced frequently throughout this publication. subsystem function. A skip-level migration. Detailed information is provided in the documents and Web sites listed in “Related publications” on page 237. and provide some general considerations on the utilization and expectation of the performance related functions. is also supported for the first time. and draws conclusions and recommendations based on the measurements. the related performance measurements are a work in progress. the goal of DB2 V7 is to provide performance as good as or better than the DB2 V6 equivalent functions. This performance goal is verified by the DB2 product development staff at IBM’s Silicon Valley Laboratory in an iterative process. This document outlines the performance-related functions of DB2 V7. utilities. More information is planned to be provided before the end of the year and will be included in other redbooks and redpapers. 2001 1 . © Copyright IBM Corp. Chapter 2. The redbook DB2 UDB Server for OS/390 and z/OS Version 7 Presentation Guide. capacity and availability. and performance tools.

– Correlated subquery to join transformation: There are some additional situations when transformation can take place for correlated subqueries only. and both the PLAN_TABLE and the DSN_STATEMENT_TABLE have some new values in the existing columns. – Joining on columns of different data types: A join predicate can be Stage 1 and potentially Indexable when there is a data type or length mismatch for numeric columns. – Row value expressions: A predicate can compare a list of columns to a list of expressions. – MIN/MAX enhancement: A more efficient use of indexes for evaluation MIN and MAX functions is now provided. – Parallel data set open: Data set open/close processing for partitions in the same partitioned table space/index is no longer a serial process. – Parallelism for IN-list index access: Parallelism for an IN-list predicate is now allowed whenever it is supported by an index and the prerequisites for parallelism are met (read-only SQL.1 Key performance enhancements This section lists the major performance and availability enhancements provided by DB2 V7. in your SQL. cast one column to the data type of the other. – Scrollable cursors: Scrolling backwards as well as forwards is now allowed. – UPDATE/DELETE with self-referencing subselect: DB2 now allows searched UPDATE and DELETE statements to use the target tables within subqueries in the WHERE or SET clauses. For convenience of presentation. – Star join: Externalized parameter to allow star join at subsystem level and other maintenance in this rapidly evolving area. – Bind improvements: Improvements to the DB2 Optimizer processing will result in significantly reduced storage requirements and reduced CPU use during the BIND command execution for joins involving more than 9 tables. In order for this to be true you must. SQL These enhancements affect SQL performance: – Plan table changes: The V7 PLAN_TABLE has two new columns. – Fewer sorts with order by: A better use of indexes now provides ordering of result sets. CURRENT DEGREE = ‘ANY’). A scrollable cursor can be sensitive or insensitive to updates made outside the cursor. by the same user or by different users. – VARCHAR index-only access: It is no longer necessary to set RETVLCFK=YES to get index-only access in this special case. – Union everywhere: The use of unions is expanded to anywhere that a subselect clause was valid in previous versions of DB2. they are grouped into the same areas of the product that are detailed in the following chapters of this redbook. This enhancement also provides the ability to place the cursor at a specific row within the result set. 2 DB2 for z/OS and OS/390 Version 7 Performance Topics .1. DB2 subsystem These enhancements affect DB2 subsystem performance: – Asynchronous preformat: Asynchronous preformat improves insert performance.

This option allows for a dynamic change of a major part of the subsystem startup parameters. Utilities These are the enhancements to various DB2 utilities and functions: – Dynamic utility jobs: It is now possible to specify a pattern of DB2 objects to run utilities against and dynamically allocate unload data sets. – Consistent restart: RECOVER and LOAD REPLACE are now allowed against objects associated with postponed units of recovery. and so on. Critical log read access errors do not force DB2 down. – CATMAINT utility: Performance of the CATMAINT utility is improved. Cancel of postponed recovery is now an option. – Evaluate uncommitted: A new DSNZPARM. A new warning message for long running units of recovery is introduced. – Reduced logging for variable-length rows: Under certain conditions the amount of logging done for updates of variable-length rows can be reduced. – UNLOAD: This is a new utility to unload data from tables without any influence on business applications. sort data sets. – DDL concurrency improvement: Row level locking on catalog table spaces with no links defined can improve DDL concurrency. Introduction 3 . specifies whether predicate evaluation can occur on uncommitted data. – Log-only recovery improvement: Frequent update of HPGRBRBA improves log-only recovery. EVALUNC. work data sets. Availability and capacity These enhancements provide new and enhanced functionality in this area: – Online DSNZPARMs: You can now activate a new set of DB2 subsystem parameters without having to recycle DB2. – CANCEL THREAD NOBACKOUT: A NOBACKOUT option is added to the CANCEL THREAD command. – Adding workfiles: You can now CREATE and DROP a workfile table space without having to stop the workfile database. Chapter 1. Checkpoint frequency can be controlled by a time interval. new traces help you in monitoring virtual storage usage. but can be retried. – Online LOAD RESUME: It is now possible to load data into tables with a utility that acts like a normal insert program. A new drain specification statement has been added to overriding the utility locking time-out value specified at subsystem level. – Log manager: Suspend/resume log activity allows for snapshot copy of the DB2 environment. – Online REORG enhancements: The FAST SWITCH phase has been improved and BUILD2 phase is now supporting parallelism for building NPIs. – Dynamic change of time-out value: A new option on the modify IRLM command allows the DBMS time-out value as known to IRLM to be dynamically modified. – LOAD partition parallelism: It is now possible to load partitioned table spaces in parallel with only one job instead of running multiple jobs per partitions.– Virtual Storage Constraint Relief and new traces: VSCR is a permanent concern.

DB2 V7 keeps track of their size across DB2 executions and structure allocations. Data sharing These enhancements improve availability. Considerations on SQLJ and JDBC performance: These recommendations. DRDA server elapsed time reporting: This makes it easier to monitor bottlenecks in client/server applications. DB2 now notifies you of any unresolved units of work (indoubt or postponed abort UOWs) that will hold retained locks after the DB2 member has shut down. Java stored procedures with JVM: This implements support for Java stored procedures as interpreted Java executing in a Java Virtual Machine (JVM) as well as support for user-defined external (non-SQL) functions written in Java. introduced by APAR in DB2 V5 and V6. and usability of DB2 data sharing: Coupling Facility Name Class Queues: Name Class Queues allows the Coupling Facility Control Code (CFCC) to organize the GBP directory entries in queues based on DBID. Stored procedures with COMMIT/ROLLBACK: This makes it possible to implement more complex stored procedures that are invoked by Windows and UNIX clients.– Statistics history: It is now possible to store all generations of statistics information and not only the current information from RUNSTATS. – COPYTOCOPY: This new utility provides the opportunity to make additional full or incremental image copies. DB2 V7 reduces the MVS to DB2 communication that occurs during a coupling facility/structure failure. • 4 DB2 for z/OS and OS/390 Version 7 Performance Topics . Persistent Coupling Facility structure sizes: After altering the size of DB2 structures. can request to be notified when a member of the data sharing group becomes active on the executing OS/390 image. Network computing These are enhancements to network computing in DB2 V7: FETCH FRIST n ROWS ONLY: This allows a limit on the number of rows returned to a result set. Group attach enhancements: An application can now connect to a specific DB2 member even if the DB2 member name and the DB2 group name are identical. Miscellaneous items: • During normal shutdown processing. is fully implemented in DB2 V7. even across multiple platforms. can have a dramatic effect on the performance of your SQLJ applications. PSID and partition number. using the group attach name.This enhancement reduces the performance impact of purging group buffer pool (GBP) entries for GBP dependent page sets. UNICODE: This provides full support for a third encoding scheme. With DB2 V7 you can specify the group attach name for DL/I batch applications. Applications. if they are implemented. DB2 Restart Light: The “light” restart option allows you to restart a failed DB2 member on the same or another OS/390 image with a minimum storage footprint in order to release any retained locks. performance. – Cross Loader: This new functionality makes it possible to move data across multiple databases. IMMEDWRITE bind option: The IMMEDWRITE bind/rebind option. This enhancement will decrease recovery time in such a failure situation.

Introduction 5 . Performance tools These enhancements are related to performance tools in DB2 V7: IFI enhancements for V7: Several new IFCIDs have been added. DB2 PM changes and new functions: Statistics and accounting records have been improved to help in identifying the event involved.1 Query performance As for the previous releases. DB2 V7 continues to further enhance the exploitation of available indexes for performance advantage and widen the applicability of stage 1 predicates. more parallel LOAD of partitions. Here we list the performance enhancements which we considered most important based on current measurement results and value.2. and the DSNZPARM has a new parameter to help in synchronizing the writing of IFCID records. but still impact DB2 performance: DB2 and zSeries: DB2 will benefit from large real memory support. and better hardware compression VSAM striping: Striping becomes available for VSAM data sets with DFSMS in OS/390 V2R10 ESS enhancements: The IBM Enterprise Storage Server (ESS) exploits the Parallel Access Volume and Multiple Allegiance features of OS/390. for automatic tuning of CF structures. UNICODE encoding scheme. and scrollable cursors. DB2 Estimator: Several new DB2 for OS/390 V7 functions have been added to DB2 Estimator. new built-in functions. others have changed. including: the new UNLOAD utility. FlashCopy is the ESS feature to use for DB2 backup in combination with log suspend/resume. APAR PQ45407 allows the user to enable coupling facility duplexing for the IRLM lock structure. the FETCH FIRST n ROWS ONLY clause. faster processors.• • OS/390 Version 2 Release 10 introduces a new function. We have arbitrarily grouped them in the areas of: Query performance Transaction performance Utility performance Subsystem and host platform synergy Migration 1. and the SQL workload. database administrators. the existing indexes. Index Advisor: This is an extension of the DB2 for UNIX and Windows optimizer that provides recommendations for indexes based on the tables and views defined in the database. 1. Auto Alter. Other enhancements These improvements are not strictly internal to DB2. More efficient access paths are now chosen for: Chapter 1. and operators. It also offers tremendous improvements in availability. system programmers.2 Performance highlights DB2 V7 offers new capabilities and possible performance improvements for most areas of the product to all types of users: application programmers.

A3 This is equivalent to: SELECT FROM TABA WHERE A2=5 ORDER BY A1.TABB WHERE A1=B1 AND B2=A2. Duplicate rows must be removed from TABB. like the ERP systems. or a costly index scan: SELECT MAX(A1) FROM TABA WHERE A1<n SELECT MIN(A1) FROM TABA WHERE A1>m Query parallelism is also improved. VSAM I/O striping for DB2 Log (see Figure 1-1) The introduction of the ESS disks has more than doubled the maximum write rate when comparing to RAMAC technology. EXISTS predicates can be transformed to join for SELECT. UPDATE. This is transformed into: SELECT A1 FROM TABA.A2. Sorting can be avoided for the = predicate on ORDER BY key: SELECT FROM TABA WHERE A2=5 ORDER BY A1. and the highly variable workloads typical of e-business. CURRENT DEGREE = ‘ANY’. With DB2 V7. 6 DB2 for z/OS and OS/390 Version 7 Performance Topics . With V7.2 Transaction performance For applications with a massive number of inserts.. the insert and the related logging can become a bottleneck.. The transformation improves performance by allowing a reduction in CPU time and up to 10 times faster elapsed time.2. the more the benefits.. +SOME. restrictions have been removed and parallelism on a IN-List predicate is allowed whenever it is supported by an index and the prerequisites for parallelism are met (read-only SQL. +ANY.) Parallelism for IN-list access show improvements in elapsed time up to 5 times. one ascending. several enhancements can contribute to eliminate the contention caused by such peak activity.A3 The presence of an index on A1. avoiding the need for 2 indexes. The IN. one descending. The larger the outer table in comparison with the result table. The support for VSAM striping applied to Log data sets shows almost three times improvement.. when comparing to the ESS F20 without striping. and DELETE.Correlated subquery transformation to join: SELECT A1 FROM TABA WHERE A1 IN (SELECT B1 FROM TABB WHERE B2=A2). 1.A3 may now avoid a sort if the optimizer evaluates it as convenient. The same index can now be used to have a direct access to both MAX and MIN values. Additional information is now provided by DB2 statistics when monitoring the log activity. in the case of 4 stripes.

preformatting takes place at CREATE or REORG time.0 ESS F20 .Maximum rates 30 27 25 20 MB/sec 18. Prior to V7 most of the time in this phase is spent renaming data sets. Chapter 1.5 15 11. The BUILD2 phase of online REORG is dedicated to rebuilding the non partitioning indexes.5 ESS F20 . with a consequent 10 times improvement in availability. The improvement is consistent with the Data Set Extend Wait Time Class 3 accounting reduction and can avoid delays of up to one second to the deferred writes when multiple I/O is present.2 4.2 seconds. With one NPI the improvement is about 30% in CPU and elapsed time. Faster and more available online REORG The SWITCH phase is critical for online REORG since it precludes accesses.Writing to active Logs . Prior to V7. This was a synchronous operation which could impact performance.5 3. FASTSWITCH is now the default.7 to 2 seconds per data set is reduced to 0. 1.2 2. an internal threshold triggers the formatting asynchronously before the end of the formatted area is reached. The 0. With V7.2. and then when the limit of the highest allocated RBA is reached during INSERT. The FASTSWITCH option avoids the data set rename time and provides a 10 times faster SWITCH phase.05 to 0.2 4. With five NPIs built by parallel tasks the improvement in elapsed time reaches 80%.3 Utility performance The utilities have seen major changes with DB2 V7. Introduction 7 .4 10 5 0 3390-3 RVA T82 Ramac3 RVA X82 ESS E20 10.1 ESS F20 .5 8.2 Figure 1-1 Improvements in maximum log rates Asynchronous preformatting Disk space needs to be preformatted before a row/key can be inserted. With V7 this phase has been revised and parallelism has been added.4 ESS F20 . Figure 1-2 shows the improvement per data set on three device types.

Corresponding elapsed time reduction is also possible. but it is managed just like any other utility. Since it interfaces the INSERT at a lower level than the standard API. Seconds per data set O n lin e LO AD RESUM E CPU time Elapsed time Time in seconds 300 200 100 0 281 230 214 171 INSERT Online LOAD RESUME Figure 1-3 Online LOAD RESUME and INSERT 8 DB2 for z/OS and OS/390 Version 7 Performance Topics . it reduces the CPU overhead by 37% when compared to a standard SQL program while allowing concurrent accesses (see Figure 1-3).5 1 0.S W IT C H a n d F A S T S W IT C H tim e s 2 V6 1.5 0 3390 RVA2 ESS V7 Figure 1-2 Elapsed time in renaming a data set by device type Online LOAD RESUME This new utility operates functionally like SQL INSERT.

The zSeries shows the following performance benefits for DB2: 15 to 30% faster on single engine. but it provides more functions and a 15 to 18% reduction in CPU time. the hiperpool provides less storage. This execution shows a 30% improvement when comparing with loading the whole table. DB2 exploits processors. functions and instructions. no direct I/O support. the actual migration. but when multiple indexes are present.2. introduced with DB2 V6. has been largely improved (see Figure 1-4). A dataspace buffer pool with sufficient real storage allows up to 8 million buffers (32 GB with 4 KB pages) with potential for more direct I/O support and more concurrent parallel prefetch. and it cannot contain updated pages.10 has enabled the exploitation of real storage exceeding the already theoretical 2 GB limit.2. The execution of step1 of the utility. If only one index is present. 1. the Catalog migration utility. The dataspace buffer pool support. and the number of engines in a complex is increased to 16.5 Migration CATMAINT. and takes advantage of the enhancements in storage controllers and disks. Introduction 9 . the best option is to use this new parallel partition LOAD with the SORTKEYS option. DB2 will activate as many tasks as many are the partitions as long as the same number of input data sets have been prepared. Larger buffer pools can reduce disk I/O rate. can now be utilized to provide virtual storage constraint relief to the DBM1 address space. By contrast.4 Subsystem and host platform synergy A traditional strong point of DB2 has always been the tight integration and synergy with the host platform. 8 GB total. Chapter 1. The new UNLOAD utility is similar to REORG UNLOAD EXTERNAL. it could still be convenient to execute the jobs in parallel by partition.Parallel partition LOAD DB2 V7 can now execute the LOAD of a partitioned table space in parallel by partition within the same job execution. DB2 can promote an almost linear performance scalability taking full advantage of the bigger and faster processors. shows more than 10 times reduction in elapsed time and 40 times reduction in CPU time when comparing a V5->V6 migration with V6->V7. and 30 to 75% more throughput than the G6 turbo 3 to 4 times more efficient hardware compression than G6 turbo 30 to 60% faster on compressed data 1. introduced with DB2 V6 uses up to 9 times less CPU than DSNTIAUL. REORG UNLOAD EXTERNAL. Catalog getpages are reduced 7 times and the internal sorts have been almost completely eliminated. The introduction of the new zSeries processor and OS/390 2. fully utilizes the parallel sysplex for data sharing. The new z900 servers have increased the single processor speed by 20%. The maximum configurable real storage is 64 GB. The Workload Manager is a key element in making sure that even at maximum utilization the business importance honored in mixed workloads with very low concurrency overhead. With virtual storage and I/O relieved.

C a t a lo g M ig r a tio n U t ility (C A T M A IN T ) 1000 900 800 Time in seconds 700 600 500 400 300 200 100 0 V5->V6 V5->V6 V5->V7 944 CPU time 834 Elapsed time 768 250 192 194 82 6 V6->V7 Figure 1-4 CATMAINT executions 10 DB2 for z/OS and OS/390 Version 7 Performance Topics .

and we provide some considerations on migration. Overview of DB2 Version 7 With DB2 V7. we summarize the main enhancements of DB2 V7. we look at the changes in the packaging of the product. you can leverage your existing applications while developing and expanding your electronic commerce for the future. In this chapter. Using the powerful environment provided by S/390 and OS/390. © Copyright IBM Corp. and the new zSeries and z/OS. the DB2 Family delivers more scalability and availability for your e-business and business intelligence applications.2 Chapter 2. 2001 11 .

You can specify that the data in the result table remain static. The syntax can replace cumbersome logic techniques and coding techniques and improve performance.1 Application enablement Numerous SQL enhancements in this area provide greater flexibility and family compatibility. 12 DB2 for z/OS and OS/390 Version 7 Performance Topics . You can use the FETCH FIRST ’n’ ROWS clause to limit the number of rows that are prefetched and returned by the SELECT statement. while an airline reservation system application must display the latest flight availability information. an accounting application can require that data remain constant. You can also specify that the data in the result table remain insensitive or sensitive to concurrent changes in the database. A new SQL clause and a fast close improve performance of applications in a distributed environment. If you choose to be sensitive to changes. Support for scrollable cursors enables applications to use a powerful new set of SQL to fetch data using a cursor at random.1 DB2 at a glance In this section. and you want DB2 to ignore the other rows. This tells DB2 that you are only interested in the first row. Limited fetch This function consists of a FETCH FIRST ’n’ ROWS SQL clause and a fast implicit close. UNION everywhere This enhancement satisfies a long-standing requirement. You can specify the FETCH FIRST ROW ONLY clause on a SELECT INTO statement when the query can return more than one row in the answer set. Scrollable cursors are especially useful for screen-based applications.1. It provides the ability to define a view based upon the UNION of subselects: Users can reference the view as if it were a single table while keeping the amount of data manageable at the table level. associating them with the areas of: Application enablement Utilities Network computing Performance and availability Data sharing Features and tools 2.2. It is useful for multiple column key comparisons and needed for some key applications. you can update the database. or do the data updates dynamically. Row expression in IN predicate This function allows the ability to define a subselect whose resultant data is multiple columns. This frees your application from the need to cache the resultant data or to reinvoke the query in order to reposition within the resultant data. we briefly introduce the main enhancements introduced by DB2 V7. For example. along with the ability to use those multiple columns as a single unit in comparison operations of the outer level select. Scrollable cursors Scrollable cursors give your application logic ease of movement through the result table using simple SQL and program logic. both in the forward and backward direction.

This API can be called by the COBOL compiler. XML Extender DB2 V7 provides more flexibility for your enterprise applications and makes it easier to call applications. making it easier to import applications from other database management systems and from other operating environments. DB2 V7 accepts COMMIT and ROLLBACK statements issued from within a stored procedure. the WHERE clause cannot refer to the object being modified by the statement. SQL — enhanced stored procedures Stored procedures.0 standard and. in a searched UPDATE and DELETE statement. This function is activated at installation time. In previous releases of DB2. as well as support for user-defined external (non-SQL) functions written in Java.JOBCODE = Y. V7 removes the restriction for the searched UPDATE and DELETE statements. Use of the host language compiler enhances DB2 family compatibility. Precompiler services With DB2 V7.10 WHERE SALARY < (SELECT AVG(SALARY) FROM EMP Y WHERE X.Enhanced management of constraints You can specify a constraint name at the time you create primary or unique keys. introduced with DB2 V5. Allow DBADM to create views and aliases for others DBADM authority is expanded to include creating aliases and views for others. DB2 evaluates the complete subquery before performing the update. have increased program flexibility and portability among relational databases. you can take advantage of precompiler services to perform the tasks currently executed by the DB2 precompiler. The search condition in the WHERE clause can include a subquery in which the base object of both the subquery and the searched UPDATE or DELETE statement are the same. The base object for both the UPDATE statement and the WHERE clause is the EMP table. you can have a self-referencing subselect.JOBCODE). or in several columns containing the fields from the document structure. Java support DB2 V7 implements support for the JDBC 2. This extender allows you to store an XML object either in an XML column for the entire document. Also. By using this option. DB2 V7 also allows you to implement Java stored procedures as both compiled Java using the OS/390 High Performance Java Compiler (HPJ) and interpreted Java executing in a Java Virtual Machine (JVM). in addition. DB2 introduces the restriction of dropping an index required to enforce a constraint. you can eliminate the DB2 precompile step in program preparation and take advantage of language capabilities that had been restricted by the precompiler. support for userid/password usage on SQL CONNECT via URL. you can use a subselect to determine the values used in the SET clause of an UPDATE statement. Self-referencing subselect on UPDATE or DELETE Now. The following code sample is for an application which gives a 10% increase to each employee whose salary is below the average salary for the job code: UPDATE EMP X SET SALARY = SALARY * 1. Chapter 2. This enhancement will prove especially useful for applications in which the stored procedure has been invoked from a remote client. and the JDBC Driver execution under IMS. The family adds DB2 XML Extender support for the XML data type. but not for the positioned UPDATE and DELETE statements. Overview of DB2 Version 7 13 .

More parallelism with LOAD with multiple inputs Using DB2 V7. The sort tasks pass the sorted keys to their corresponding build task. and database administrators who are new to DB2 will learn to perform these tasks more quickly. each of which builds one index. The utility then extracts index keys and passes them in parallel to the sort task that is responsible for sorting the keys for that index. Online LOAD RESUME Earlier releases of DB2 restrict access to data during LOAD processing. you can standardize object lists and the utility control statements that refer to them. UNLOAD. which provides faster data unloading than was available with the DSNTIAUL program. rather than in different jobs. If there is too much data to perform the sort in memory. Now you can: Dynamically create object lists from a pattern-matching expression Dynamically allocate the data sets required to process those objects Using a LISTDEF facility. UNLOAD With DB2 V7 you can take advantage of a new utility. DB2 writes error and error mapping information to the error and map data sets. The use of TEMPLATE utility control statements simplifies your JCL by eliminating most data set DD cards. Cross Loader The enhancement allows EXEC SQL statements results as input to the Load utility. DB2 V7 gives you the choice of allowing user read and write access to the data during LOAD processing. Now you can provide data set templates. Both local DB2s and remote DRDA compliant databases can be accessed. The utility loads each partition from a separate data set so one job can load partitions in parallel.1. Standardization reduces the need to customize and change utility job streams over time. you can easily load large amounts of data into partitioned table spaces for use in data warehouse or business intelligence applications. 14 DB2 for z/OS and OS/390 Version 7 Performance Topics . Using load parallelism is much easier than creating multiple LOAD jobs for individual parts. Each load task takes input from a sequential data set and loads the data into a corresponding partition. database administrators can submit utility jobs more quickly and easily. so you can load data concurrently with user transactions. the sort product writes the keys to the sort work data sets. If the utility encounters errors during the load. The SORTKEYS keyword enables the parallel index build of indexes.2 Utilities In this section we describe enhancements to several DB2 utilities. The UNLOAD utility combines the unload functions of REORG UNLOAD EXTERNAL with the ability to unload data from an image copy. Parallel load with multiple inputs runs in a single step. Parallel LOAD reduces the elapsed time for loading the data when compared to loading the same data with a single job in earlier releases. Database administrators require less time to maintain utilities jobs. Dynamic utility jobs With DB2 V7.2. and the DB2 product dynamically allocates the data sets that are required based on your allocation information.

CopyToCopy This feature provides the capability to produce additional image copies recorded in the DB2 catalog. The utility can delete records that were written to the catalog history tables before a specific date or that are recorded as a specific age.1. Uses the Resource Access Control Facility (RACF) product to perform much of the Kerberos configuration. With historical statistics available. You specify a new keyword. Enables single-logon capability for DRDA clients by using the Kerberos principle name as the global identity for the end user. 2. Security enhancements You can more easily manage your workstation clients who seek access to data and services from heterogeneous environments with DB2 support for Windows Kerberos authentication. RACF is a familiar environment to administrations of OS/390. Also. additional parallel processing improves the elapsed time of the BUILD2 phase of REORG SHRLEVEL(CHANGE) or SHRLEVEL(REFERENCE). Eliminates the need to manage authentication in two places. Online REORG enhancements improve the availability of data in two ways: Online REORG no longer renames data sets. FASTSWITCH. DB2 Visual Explain utilizes statistics history for comparison with new variations that you enter so you can improve your access paths. Simplifies security administration by using the Kerberos principle name for connection processing and by automatically mapping the name to the local user ID. To maintain optimum performance of processes that access the tables. DB2 can predict the future space requirements for table spaces and indexes more accurately and run utilities to improve performance. you may require changes to the physical design of DB2 objects. Chapter 2.3 Network computing Network computing includes the following enhancements: Global transactions Privileged application can use multiple DB2 agents or threads to perform processing that requires coordinated commit processing across all the threads. Statistics history As the volume and diversity of your business activities grow. Overview of DB2 Version 7 15 . the RACF database. greatly reducing the time that data is unavailable during the SWITCH phase. and a separate Kerberos registry. treats these separate DB2 threads as a single “global transaction” and commits all or none. which keeps the data set name unchanged and updates the catalog to reference the newly reorganized data set. via a transaction processor. DB2 stores statistics in catalog history tables. V7 of DB2 collects statistic history to track your changes. This enhancement: Eliminates the flow of unencrypted user IDs and passwords across the network. use the MODIFY STATISTICS utility.Online REORG enhancements Online REORG makes your data more available. DB2 V7 (and V6 RML). The time savings can be quite significant when DB2 is reorganizing hundreds of table spaces and index objects.

The server elapsed time allows remote clients to quickly determine the amount of time it takes for DB2 to process a request. without having to STOP the workfile database. which is used to process a request in reply from the DB2 subsystem. and DB2.1. Network monitoring DB2 V7 introduces reporting server elapsed time at the workstation. Online subsystem parameters One of the causes of a planned outage for DB2 is the need to alter one or more of the system parameters. 2. to determine performance bottlenecks among the client.1. This new code set is an encoding scheme that is able to represent the characters (code points) of many different geographies and languages. Coupling Facility Name Class Queues DB2 V7 exploits the OS/390 and z/OS support for the Coupling Facility Name Class Queues. Previous releases of DB2 have offered support for numerous code sets of data in either ASCII or EBCDIC format. there was a limitation of only one code set per system.UNICODE support In the increasingly global world of business and e-commerce. A new feature to prevent backout of data and log is added to DB2’s -CANCEL THREAD command.4 Performance and availability Several new enhancements are provided to improve performance and availability. which allows workstation clients. there is a growing need for data arising from geographically disparate users to be stored in a central server. However. in real-time. Adding space to the workfiles DB2 V7 allows you to CREATE and DROP workfile table space. Log manager enhancements Log manager updates help you with DB2 operations by providing: Suspend update activity Retry critical log read access Time interval system checkpoint frequency Long running UR information Consistent restart enhancements DB2 V7 provides more control of the availability of the user objects associated with the failing or cancelled transaction without restarting DB2. 2.5 Data sharing Data sharing customers can benefit from several new enhancements. This enhancement reduces the performance impact of purging group buffer pool (GBP) entries for GBP-dependent page sets. Consistent restart enhancements remove some of the restrictions imposed by the current consistent restart function. 16 DB2 for z/OS and OS/390 Version 7 Performance Topics . The server elapsed time does not include any network delay time. DB2 V7 supports UNICODE encoded data. the network. DB2 V7 enables you to change the value of many of these system parameters without stopping DB2. known as ZPARMS. Workstations accessing DB2 data can now request that DB2 return the elapsed time of the server.

1. Some of the new tools are: DB2 Bind Manager. some completely new to the server. which have been the subject of specific announcements in September 2000 and March 2001. You have the opportunity of a trial period to discover and verify the benefits of these tools. With V7. makes it easy to design and deploy a data warehouse on your S/390: you can extract operational data from your DB2 for OS/390 and import it into an S/390 warehouse without transferring your data to an intermediate platform. and help your users access data and understand information.ALTER command might be lost when you rebuild a structure and recycle DB2. to avoid unnecessary binds DB2 Log Analysis Tool. You can specify the group attach name for your DL/I batch applications. and then to terminate normally after DB2 frees retained locks. Net Search Extender adds the power of fast full-text retrieval to Net. The reduced storage requirement can make a restart for recovery possible on a system that might not have enough resources to start and stop DB2 in normal mode. Prototyping the applications is quicker.6 New features and tools A new feature. or DB2 CLI applications. any changes you make to structure sizes using the SETXCF START. IMMEDWRITE bind option A V6 enhancement offers you the choice to immediately write updated group-buffer-pool dependent buffers. to assist in using the log information DB2 SQL Performance Analyzer. to simplify recovery of data from DB2 and IMS Chapter 2. Now you can allow changes in structure size to persist when you rebuild or reallocate a structure. You should consider using DB2 Restart Light with restart automation software. Persistent structure size changes In earlier releases of DB2. to evaluate the cost of a query before it runs DB2 Change Accumulation. In V7. Restart Light allows a DB2 data sharing member to restart with a minimal storage footprint. DB2 delivers even more tools. 2. If you experience a system failure in a Parallel Sysplex.Group Attach enhancements A number of enhancements are made to Group Attach processing in DBV7: An application can now connect to a specific DB2 member of a data sharing group. The new DB2 Warehouse Manager feature gives you a full set of tools for building and using a data warehouse based on DB2 for OS/390. Overview of DB2 Version 7 17 . together with several IMS tools. Restart Light A new feature of the START DB2 command allows you to choose Restart Light for a DB2 member. Java. DB2 Warehouse Manager. you can query and analyze data.Data. It also offers application programmers a variety of search functions. to consolidate copies and logging offline DB2 Recovery Manager. You can now connect to a DB2 data sharing group by using the group attach name. the option is reflected in the DB2 catalog and externalized on the installation panels. the automated restart in “light” mode removes retained locks with minimum disruption. such as OS/390 Automatic Restart Manager. others being new versions of tools already available with DB2 V6.

please refer to the redbook DB2 UDB for OS/390 Version 6 Management Tools Package.Data Net. database management and tuning. Net. The corresponding product licences must be obtained to activate the specific functions of the utilities. DB2 Extenders: – – – – – Text Image Audio Video XML Optional no-charge features The optional no-charge features are the same as with DB2 V6: Net. Internet data connectivity. most utilities have been grouped in separate independent products. This is a separately orderable no-charge feature of DB2 V7. ODBC data sources. Oracle. replication. DRDA-enabled data sources. Net.2. SG24-5759. When ordering the DB2 base product. takes advantage of the S/390 capabilities as a premier platform for electronic commerce and Internet technology. installation.Data is a full-featured and easy to learn scripting language allowing you to create powerful Web applications.Data. and high performance. 18 DB2 for z/OS and OS/390 Version 7 Performance Topics . DB2 Management Clients Package The DB2 Management Clients Package is the new name for DB2 V7 for the previous DB2 Management Tools Package. All the utilities are shipped deactivated with the Base Engine. Documentation is still accessible from the Web. It is a collection of workstation-based client tools that you can use to work with and manage your DB2 for OS/390 and z/OS environments. It currently consists of the packaging and shipping of: – – – – – – DB2 Installer Visual Explain DB2 Estimator DB2 Connect Personal Edition (special license) Control Center Stored Procedure Builder For functional details on the DB2 Management Clients Package products.Data Web applications provide continuous application availability.2 DB2 V7 packaging DB2 V7 incorporates several features which include tools for data warehouse management. These features and tools work directly with DB2 applications to help you use the full potential of your DB2 system.Data can access data from the most prevalent databases in the industry: DB2. all utilities are always available for execution on DB2 Catalog and Directory and for the Sample Database. You need to specify the feature and the media when ordering DB2. The DB2 installation job DSNTIJRX binds the REXX language support to DB2 and makes it available for use. scalability. With DB2 V7. you can select the free and chargeable features to be included in the package. security. REXX language support REXX language and REXX language stored procedure support are shipped as a part of the DB2 V7 base code. a no-charge feature of DB2 V7. Net. as well as flat file and web registry data. However. and capacity planning.

govern. DB2 Warehouse Manager is a new.Charge features Two new charge features are shipped with DB2 V7: The DB2 Warehouse Manager The DB2 Net Search Extender The Query Management Facility product is part of the DB2 Warehouse Manager feature. Rebuild. Modify Statistics. program number 5697-E98. DB2 Utilities Suite. powerful. Copy. priced feature of DB2 V7. Runstats. which include Copy. Rebuild. and access DB2 for OS/390-based data warehouses. Check LOB. which include Check Data. Mergecopy. Stospace. With DB2 V7. Recover. and the optional associated agreements for Acquisition of Support. Load (with the DB2 family Cross Loader function). QMF currently consists of the packaging and shipping of: Query Management Facility for OS/390 QMF High Performance Option Query Management Facility (QMF) for Windows Chapter 2. and reliable tool for query and reporting within IBM’s DB2 family. DB2 Diagnostic and Recovery Utilities. Check Index. CopyToCopy. but it is also still available as a separate feature on its own. and Recover. The DB2 Utilities are grouped in these categories: DB2 Operational Utilities. which combines the functions of both DB2 Operational Utilities and DB2 Diagnostic and Recovery Utilities in the most cost effective option. Modify Recovery. program number 5655-E63. DB2 Warehouse Manager The DB2 Warehouse Manager feature brings together the tools to build. program number 5655-E62. Overview of DB2 Version 7 19 . manage. priced feature of DB2 V7. separately orderable. the DB2 Utilities have been separated from the base product and they are now offered as separate products licensed under the IBM Program License Agreement (IPLA). and the new utilities Unload and Exec SQL. Reorg. The DB2 Warehouse Manager currently consists of DB2 Warehouse Center 390 Warehouse Agent DB2 UDB EEE Query Management Facility for OS/390 Query Management Facility High Performance Option Query Management Facility for Windows Query Management Facility The Query Management Facility (QMF) is the tightly integrated. QMF for OS/390 is also a separately orderable.

and section search. Customers using Java will need to move to Java 2. They can migrate to Version 5 if needed.3. especially if you migrate to the new release much earlier than you intended. and these changes are also mentioned in the DB2 for OS/390 Version 7 Presentation Guide. and if you need them. SG24-6121. and a large number of users will start considering a migration before year-end. before migrating to DB2 V7. prerequisite software must be installed.Data. The introduction program of DB2 has provided good quality feedback from the customers. but with some extra testing. 2. Your choice will depend upon whether you need some specific functions of Version 6 or Version 7 this year. You should ensure that you are fully operational on DB2 V5. you should understand the changes in their packaging. The interest in DB2 V7 is growing. stemming. there are some important quality improvements in Version 7 that may allow some customers to save time by skipping over Version 6. with a significantly higher availability under stress conditions. then it is time to find the needed resources and migrate. Boolean operators. Finally. This is the prerequisite level for WebSphere 4.2. If you are running Version 5 today and considering moving to Version 6 or waiting for Version 7. and then skip over Version 6 directly to Version 7 next year. 2. you must get the right level of education and make sure that all of the incompatible changes are found. If so. you must plan for testing for the applications and settings that are unique to your installation. you should consider that the customer base for Version 6 is now covering most workloads.1 Net Search Extender DB2 Net Search Extender contains a DB2 stored procedure that adds the power of fast full-text retrieval to Net. J2EE. Java.3 Migration to DB2 Version 7 Migration with full fallback protection is available when you have either DB2 V5 or DB2 V6. It offers application programmers a variety of search functions. 20 DB2 for z/OS and OS/390 Version 7 Performance Topics .1 Planning for migration If you were using the DB2 Utilities.com/ibmlink provides details.2 Reasons to migrate Everyone who is building on Java requires V7. and third parties must have their support in place. and weigh that against saving a cycle but running some risks on going to Version 7. The current standard documentation starting from the announcements at ibm. you may want to get there quickly.3. As time goes by. Of course there are functions that are only in Version 7.0. or have just migrated to Version 5. 2. Keep in mind that moving from Version 5 to Version 7 is more than half of the work of migrating to Version 6 and then to Version 7. or DB2 CLI applications.2. While we expect the majority of our customers to be migrated to Version 6 in the next few months. PQ34667 must be applied. If you are planning to skip Version 6. release skipping to V7 is expected to become more typical. The result of extra work in testing the DB2 V7 at the lab is a more solid product. They will also need the performance improvements that are only found in V7. The ability to skip from Version 5 to Version 7 will be a big help for customers who are running Version 3 or 4 today. such as fuzzy search. You need to plan for adequate time. or later.

Update from a self-referencing subselect Order by expression SQL scalar functions XML extenders Unicode support Windows Kerberos security DBAs and system programmers will appreciate the warehouse integration utilities: – New UNLOAD utility – LOAD enhancements: • LOAD from cursor. patterns.. in views.Most of the customers and key vendors need the performance and availability enhancements described of V7. For instance ERP and CRM products such as SAP. such as PeopleSoft. PeopleSoft. There are some useful functions for users and vendors. and Siebel can benefit from the following functions: Online change of most system parameters Cancel thread without rollback Improved utility and SQL parallelism and performance Several of these changes are also crucial for warehouse type of solutions. Overview of DB2 Version 7 21 . The improvement provided by correlated subqueries is huge for applications that make use of them. SELECT statement (Cross Loader) • LOAD partition parallelism within the same job execution • Online or sharelevel change LOAD – Pattern matching and dynamic allocation – Faster switch and BUILD2 for online REORG – New CopyToCopy utility – Statistics history – Data sharing: Restart Light – CANCEL THREAD NOBACKOUT Chapter 2. such as: CURRENT MEMBER special register Self-referencing update and delete Fetch limited number of rows Improved DRDA performance DRDA server elapsed time reporting Utility lists.. and dynamic allocation Better handling of DEFER DEFINE data sets Application developers will greatly benefit from: UNION and UNION ALL in a view Row expressions But query users will also make use of: Performance enhancements in: – IN-list index access parallelism – Correlated subquery performance – Fewer sorts for ORDER BY and some predicates New functionalities such as: – – – – – – – – Scrollable cursors UNION everywhere..

new messages for long running UR. operations.1 Functions requiring no effort The following performance benefits are immediately available after migration.4.2 Functions requiring a small effort The following performance benefits can be obtained with some system programming. when specified for a member of a data sharing group. including: – – – – – – MIN. 2. or database administration effort: In the area of utilities: – Online REORG FASTSWITCH (DB2 default) needs some caution to allow for the new data set names. In order to help in evaluating the enhancements in terms of their applicability and return on investment. – Restart Light. RETRY for critical read) need coordination with operational procedure. In the area of availability and capacity: – Online ZPARMs need proper administrative set up (authorization and impact evaluation). – Parallel partition LOAD only needs some input data set preparation by partition. without any change to the DB2 subsystem or the applications: In the area of subsystem function: – – – – – Asynchronous preformatting to improve INSERT intensive workloads Parallel data set open for partitions CATMAINT much faster execution time Less logging for VARCHAR New instrumentation records for additional information on virtual storage usage and Log statistics In the area of utilities: – BUILD2 enhancements In the area of SQL usage there are several enhancements (bind required). time driven checkpoints. it is important to know which new functions will be activated by "default" and which ones need special attention. – Several Log management enhancements (suspend resume. MAX using the same index Order BY reducing sort need Varchar index only access Large SQL Bind enhancements for very complex queries Parallel IN list performance Correlated subquery performance 2. – Dynamic allocation of workfiles now does not need to issue STOP DSNDB07.2. 22 DB2 for z/OS and OS/390 Version 7 Performance Topics . relating them to their implementation effort. allows smaller storage blueprint under critical restart conditions to release pending locks. in the following sections we list the most important enhancements. – Online REORG has new parameters to RETRY to complete the execution.4. – Consistent restart enhancements require modification of the operational procedures.4 Implementation considerations When considering the migration of a full DB2 production environment.

– Name Class queue for data sharing (just check for the right level of CFCC) provides better performance. there are several enhancements that can be obtained with minor application modifications: – – – – Fetch first n rows Joining columns of different numeric data types via casting Commit and Rollback within stored procedures Current Member register can be used to identify the member of the data sharing group 2.4.3 Functions requiring some planning The following new functions need to be activated gradually. They also require interactions with application developers and/or operations. In the area of SQL usage. after you have completely and successfully migrated and consolidated your DB2 V7 environment. Overview of DB2 Version 7 23 . – Group attach enhancements are provided. In the area of SQL usage: – – – – UNION everywhere Scrollable cursors Java enhancements Unicode support In the area of utilities: – – – – – – – – Cross Loader with EXEC SQL CopyToCopy Online Load Resume Unload LISTDEF and Templates RUNSTATS history Data spaces with Series VSAM striping for log data sets For Data Sharing – Lock structure duplexing increases the availability of your data sharing group and depends upon a z/OS V1R2 feature Chapter 2.

24 DB2 for z/OS and OS/390 Version 7 Performance Topics .

Star join: An externalized parameter allows star join at the subsystem level and other maintenance in this rapidly evolving area. Both PLAN_TABLE and DSN_STATEMNT_TABLE have some new values in the existing columns. Bind improvements: Improvements to the DB2 Optimizer processing will result in significantly reduced storage requirements and reduced CPU use during the BIND command execution for joins involving more than 9 tables. providing the ability to place the cursor at a specific row within the result set. CURRENT DEGREE = ‘ANY’). UPDATE/DELETE with self-referencing subselect: DB2 now lets searched UPDATE and DELETE statements use target tables within subqueries in WHERE or SET clauses. Parallelism for IN-list index access: Parallelism for an IN-list predicate is now allowed whenever it is supported by an index and the prerequisites for parallelism are met (read-only SQL. Fewer sorts with order by: Indexes can be better used to provide ordering of result sets. 2001 25 . MIN/MAX enhancement: A more efficient use of indexes for evaluation MIN and MAX functions is now provided. Joining on columns of different data types: A join predicate can be Stage 1 and potentially Indexable when there is a data type or length mismatch for numeric columns. VARCHAR index-only access: It is no longer needed to set RETVLCFK=YES to get index-only access in this special case. Row value expressions: A predicate can compare list of columns to list of expressions. by the same user or different users. Scrollable cursors: Scrolling backwards as well as forwards is now allowed. SQL performance In this chapter. Correlated subquery to join transformation: There are some additional situations when transformation can take place for correlated subqueries only. A scrollable cursor can be sensitive or insensitive to updates made outside it. © Copyright IBM Corp. in your SQL you must cast one column to the data type of the other. For this to be true. we discuss performance enhancements that affect SQL performance: Plan table changes: The V7 PLAN_TABLE has two new columns.3 Chapter 3. Union everywhere: The use of unions is expanded to anywhere that a subselect clause was valid in previous versions of DB2.

25 column format --------- New columns PREFETCH CHAR(1) NOT NULL WITH DEFAULT COLUMN_FN_EVAL CHAR(1) NOT NULL WITH DEFAULT MIXOPSEQ SMALLINT NOT NULL WITH DEFAULT --------. The complete PLAN_TABLE definition is shown in Figure 3-1. QUERYNO INTEGER NOT NULL QBLOCKNO SMALLINT NOT NULL APPLNAME CHAR(8) NOT NULL PROGNAME CHAR(8) NOT NULL PLANNO SMALLINT NOT NULL METHOD SMALLINT NOT NULL CREATOR CHAR(8) NOT NULL TNAME CHAR(18) NOT NULL TABNO SMALLINT NOT NULL ACCESSTYPE CHAR(2) NOT NULL MATCHCOLS SMALLINT NOT NULL ACCESSCREATOR CHAR(8) NOT NULL ACCESSNAME CHAR(18) NOT NULL INDEXONLY CHAR(1) NOT NULL SORTN_UNIQ CHAR(1) NOT NULL SORTN_JOIN CHAR(1) NOT NULL SORTN_ORDERBY CHAR(1) NOT NULL SORTN_GROUPBY CHAR(1) NOT NULL SORTC_UNIQ CHAR(1) NOT NULL SORTC_JOIN CHAR(1) NOT NULL SORTC_ORDERBY CHAR(1) NOT NULL SORTC_GROUPBY CHAR(1) NOT NULL TSLOCKMODE CHAR(3) NOT NULL TIMESTAMP CHAR(16) NOT NULL REMARKS VARCHAR(254) NOT NULL --------. the DSN_STATEMNT_TABLE.1 Changes to Explain tables Explain provides information in three tables: PLAN_TABLE.28 column format --------VERSION VARCHAR(64) NOT NULL WITH DEFAULT COLLID CHAR(18) NOT NULL WITH DEFAULT ---------30 column format --------ACCESS_DEGREE SMALLINT ACCESS_PGROUP_ID SMALLINT JOIN_DEGREE SMALLINT JOIN_PGROUP_ID SMALLINT ---------34 column format --------SORTC_PGROUP_ID SMALLINT SORTN_PGROUP_ID SMALLINT PARALLELISM_MODE CHAR(1) MERGE_JOIN_COLS SMALLINT CORRELATION_NAME CHAR(18) PAGE_RANGE CHAR(1) NOT NULL WITH DEFAULT JOIN_TYPE CHAR(1) NOT NULL WITH DEFAULT GROUP_MEMBER CHAR(8) NOT NULL WITH DEFAULT IBM_SERVICE_DATA VARCHAR(254) NOT NULL WITH DEFAULT --------43 column format ---------WHEN_OPTIMIZE CHAR(1) NOT NULL WITH DEFAULT QBLOCK_TYPE CHAR(6) NOT NULL WITH DEFAULT BIND_TIME TIMESTAMP NOT NULL WITH DEFAULT ------46 column format -----------OPTHINT CHAR(8) NOT NULL WITH DEFAULT HINT_USED CHAR(8) NOT NULL WITH DEFAULT PRIMARY_ACCESSTYPE CHAR(1) NOT NULL WITH DEFAULT -------49 column format-----------PARENT_QBLOCKNO SMALLINT NOT NULL WITH DEFAULT TABLE_TYPE CHAR(1) -------51 column format----------- Figure 3-1 DB2 Version 7 plan table 26 DB2 for z/OS and OS/390 Version 7 Performance Topics .3.1. giving it a total of 51 columns and some new values. for the estimated cost of executing an SQL statement. for the output of binding a plan or a package. and the DSN_FUNCTION_TABLE for user-defined functions referred to in a statement. Here we see the changes in V7 that impacted some of these tables.1 PLAN_TABLE The V7 PLAN_TABLE has two new columns. 3.

6. Changed PLAN_TABLE columns The column QBLOCK_TYPE can contain three new values: TABLEX — table expression UNION — UNION UNIONA — UNION ALL 3.1. 3. SQL performance 27 . The type of the new table. They are described in Table 3-1.3 Explain headings used in this chapter The Explain headings that are used in figures in the following sections of this chapter are listed in Table 3-2 for reference. in the case where a subquery includes a HAVING clause. This is represented in the column REASON by the text ‘HAVING CLAUSE’. Table 3-1 New PLAN_TABLE columns Column name PARENT_QBLOCKNO TABLE_TYPE Description Contains the QBLOCKNO of the parent query block. Possible values are: F — table function Q — temporary intermediate result table (queued — not materialized) T — table W — temporary intermediate result table (using a Logical Work File — materialized) The TABLE_TYPE values W and Q are mainly used where UNION or UNION ALL have been included in a view or table expression (see Section 3.1. Table 3-2 Explain headings Heading QB PN MT TABLE AT MC INDEX PF IXO PLAN_TABLE column QBLOCKNO PLANNO METHOD TNAME ACCESSTYPE MATCHCOLS ACCESSNAME PREFETCH INDEXONLY Chapter 3. It shows the hierarchy of dependencies between query blocks.New PLAN_TABLE columns The two new columns are PARENT_QBLOCKNO and TABLE_TYPE. “UNION everywhere” on page 49).2 DSN_STATEMNT_TABLE changed columns In V7 there is a new reason for a query having COST_CATEGORY = ‘B’.

SORTC_JOIN. but also for access to a single table.2. and SORTN_GROUPBY Concatenation of SORTC_UNIQ. SG24-5351 for details. CURRENT DEGREE = ‘ANY’.1 Description IN-List parallelism is now fully supported in DB2 V7. SORTC_ORDERBY. DB2 could only use parallelisms when a table was joined which had an IN-List coded in the predicate and DB2 had decided that the table was to be the inner table. This enhancement has the potential of improving elapsed times significantly over the non-parallel performance. SORTN_ORDERBY. SORTN_JOIN. In general the maximum degree of parallelism that can be chosen is determined as follows: For I/O intensive queries: the smaller of the number of values in the IN-list and the number of partitions For CPU intensive queries: the smaller of the number of values in the IN-list and the number of CPU engines. 28 DB2 for z/OS and OS/390 Version 7 Performance Topics .Heading PQ TT SORTN SORTC JT CFE PM AD AG JD JG SCG SNG QBT PLAN_TABLE column PARENT_QBLOCKNO TABLE_TYPE Concatenation of SORTN_UNIQ. depending on the number of parallel processes available. DB2 V7 has removed this restriction and now allows parallelism on a IN-List predicate whenever it is supported by an index and the prerequisites for parallelism are met (read-only SQL. DB2 V7 adds parallelism support not only for the outer table. The examples below were Explained in both V6 and V7 via SPUFI after issuing a SET CURRENT DEGREE = ‘ANY’.2 Parallelism for IN-List index access DB2 V6 introduced the parallelism for IN-List access for the inner table of a parallel group (ACCESSTYPE=N). and SORTC_GROUPBY JOIN_TYPE COLUMN_FN_EVAL PARALLELISM_MODE ACCESS_DEGREE ACCESS_PGROUP_ID JOIN_DEGREE JOIN_PGROUP_ID SORTC_PGROUP_ID SORTN_PGROUP_ID QBLOCK_TYPE 3.) 3. The definition of the tables and indexes used in the examples are shown in Figure 3-2. See DB2 UDB for OS/390 Version 6 Performance Topics.

CRED_LIM DEC(7. CUST_NO INTEGER. In both V6 and V7 the Optimizer has chosen the special index access for IN-list predicates (ACCESS_TYPE = ‘N’). PRIMARY KEY (CUST_NO) 640 rows Table ORD_PART: ORD_NO INTEGER NOT NULL.. The table ORD_PART is partitioned into four partitions using the index X2CNO. CPU parallelism has all the benefits of I/O parallelism (multiple I/O streams) plus more. PART 4 VALUES (99999)) . 4001. 2001.. except in a few cases where CPU parallelism is not supported. CPU parallelism is used for both I/O-bound and CPU-bound queries. PART 2 VALUES (4000). FOREIGN KEY ORD_CUST (CUST_NO) REFERENCES CUST ON DELETE RESTRICT 800 rows Note: CUST_PART is partitioned into 4 partitions by CUST_NO values: CREATE UNIQUE INDEX XCUSTNOP ON TABLE CUST_PART(CUST_NO) CLUSTER (PART 1 VALUES (2000). 6001) Version 6 Explain QB 1 PN 1 MT 0 TABLE ORD_PART AT N MC 1 INDEX X2CNO PF IXO N SORTN NNNN SORTC NNNN PM -AD -AG -JD -JG -SCG --SNG --- Version 7 Explain QB 1 PN 1 MT 0 TABLE ORD_PART AT N MC 1 INDEX X2CNO PF S IXO N SORTN NNNN SORTC NNNN PM C AD 2 AG 1 JD -JG -SCG --SNG --- Figure 3-3 IN-List parallelism for single table access Chapter 3. PART 3 VALUES (6000). PRIMARY KEY (ORD_NO). SELECT * FROM ORD_PART WHERE CUST_NO IN (1. The Optimizer considered the access path to be CPU-bound. Note: ORD_PART is partitioned into 4 partitions by CUST_NO values: CREATE INDEX X2CNO ON TABLE ORD_PART(CUST_NO) CLUSTER (PART 1 VALUES (2000). TOWN CHAR(20). CPU parallelism is always chosen by the Optimizer in preference to I/O parallelism.. PART 3 VALUES (6000). but I/O parallelism is.. The V6 Explain shows no parallelism. PART 2 VALUES (4000). The Explain was performed on an LPAR with two CPUs assigned. ORD_DATE DATE. CUST_NAME CHAR(20). SQL performance 29 .2).2). PART 4 VALUES (99999)) .Table CUST_PART: CUST_NO INTEGER NOT NULL. Figure 3-2 Table and index definitions for IN-List parallelism example Single table example Figure 3-3 shows a single table query with an IN-list predicate. and therefore the parallel degree was limited by the number of CPUs. AMOUNT DECIMAL(7. but the DB2 V7 Explain shows query CPU parallelism with degree two (PARALLELISM_MODE = ‘C’ and ACCESS_DEGREE = 2).

In this test the query was I/O bound and therefore the Optimizer has chosen to use parallelism with degree seven. A single table performance test was run. 2001.5 million rows. The performance results in Table 3-4 show the normal pattern for successful use of parallelism: a large reduction in elapsed time in return for a small increase in CPU time. The access to the outer table is via the index X2CNO using the special index access for IN-list predicates (ACCESS_TYPE = ‘N’). 4001. the Optimizer has chosen a Hybrid join (METHOD = 4) with ORD_PART as the outer table of the join. The results of the test are shown in Table 3-4.Join outer table example Figure 3-4 shows a two-table inner join of the ORD_PART table used in the previous example with a CUST_PART table that is partitioned on the CUST_NO column with the same ranges as the ORD_PART table. The SQL and Explain output are shown in Figure 3-5. SELECT * FROM ORD_PART O INNER JOIN CUST_PART C ON O.CUST_NO IN (1. In both V6 and V7. RAMAC 3 DASD. and OS/390 2.CUST_NO = C. 30 DB2 for z/OS and OS/390 Version 7 Performance Topics . The index XNKEY is an index on the column C_NATIONKEY.CUST_NO WHERE O. The CUSTOMER table used in the test is taken from the TPC-H benchmark definition. this IN-list access prevents the use of parallelism.2.8. which is the number of values in the IN-list predicate. The column definitions of the CUSTOMER table are shown Table 3-3. the Optimizer chooses CPU parallelism with degree three for both the table accesses (ACCESS_DEGREE = 3) and for the join (JOIN_DEGREE = 3). In V7. There is an IN-list predicate on the ORD_PART table CUST_NO column. In V6.2 Performance The performance tests were performed on a 9672-ZZ7 LPAR with four processors. 6001) Version 6 Explain QB 1 1 PN 1 2 MT 0 4 TABLE ORD_PART CUST_PART AT N I MC 1 1 INDEX X2CNO XCUSTNOP PF L IXO N N SORTN NNNN NNNN SORTC NNNN NNNN PM --AD --AG --JD --JG --SCG ----SNG ----- Version 7 Explain QB 1 1 PN 1 2 MT 0 4 TABLE ORD_PART CUST_PART AT N I MC 1 1 INDEX X2CNO XCUSTNOP PF S L IXO N N SORTN NNNN NNNN SORTC NNNN NNNN PM C C AD 3 3 AG 1 1 JD -3 JG -1 SCG ----SNG ----- Figure 3-4 IN-List parallelism for outer table of join 3. The table contained 4.

The PART table contained 6 million rows and the LINEITEM table contained 180 million rows.16 21. The column definitions of the PART table are shown Table 3-5.32 -78.63 +7. The SQL and Explain outputs are shown in Figure 3-6. Chapter 3. The index XPSTPM is an index on the PART table columns P_SIZE.3% A second test was run.SELECT C_NATIONKEY. using a join. P_PARTKEY.000 Table 3-4 IN-List performance test results for single table access Test V6 V7 Delta Elapsed secs 1032. 21. SUM(C_ACCTBAL) FROM CUSTOMER WHERE C_MKTSEGMENT = 'BUILDING' AND C_NATIONKEY IN (12. 16. CUSTOMER CARDF = 4500000 C_NATIONKEY COLCARDF = 25 XNKEY is an index on CUSTOMER(C_NATIONKEY) Version 6 Explain QB 1 PN 1 MT 0 TABLE CUSTOMER AT N MC 1 INDEX XNKEY PF S IXO N SORTN NNNN SORTC NNNN PM -AD -AG -JD -JG -SCG --SNG --- Version 7 Explain QB 1 PN 1 MT 0 TABLE CUSTOMER AT N MC 1 INDEX XNKEY PF S IXO N SORTN NNNN SORTC NNNN PM C AD 7 AG 1 JD -JG -SCG --SNG --- Figure 3-5 IN-List performance test for single table access Table 3-3 Columns in the CUSTOMER table Column name C_CUSTKEY C_NAME C_ADDRESS C_NATIONKEY C_PHONE C_ACCTBAL C_MKTSEGMENT C_COMMENT Definition INTEGER VARCHAR(25) VARCHAR(40) INTEGER CHAR(15) DECIMAL CHAR(10) VARCHAR(117) COLCARDF = 25 Notes Primary Key. COLCARDF = 4. 18. The index XLPART is an index on the LINEITEM table column L_PARTKEY. 23) GROUP BY C_NATIONKEY. The column definitions of the LINEITEM table are shown Table 3-6. P_TYPE. 14. SQL performance 31 . 22. and P_MFGR. The PART and LINEITEM tables used in the test are also taken from the TPC-H benchmark.500.13 223.4% CPU secs 20.

--- Figure 3-6 IN-List performance test 2 Table 3-5 Columns in the PART table Column name P_PARTKEY P_NAME P_MFGR P_BRAND P_TYPE P_SIZE P_CONTAINER P_RETAILPRICE P_COMMENT Definition INTEGER VARCHAR(55) CHAR(25) CHAR(10) VARCHAR(25) INTEGER CHAR(10) DECIMAL VARCHAR(23) Notes Primary Key COLCARDF = 6. 4.-.--N NNNN NNNN C 10 1 10 1 --. 28.000 32 DB2 for z/OS and OS/390 Version 7 Performance Topics .000.The results of the test are shown in Table 3-7.--. 31. 38.-. 32. 46. 27. 50) AND P_TYPE LIKE 'SMALL%' XPSTPM is an index on AND P_MFGR = Manufacturer#3' PART(P_SIZE.--. XLPART is an index on LINEITEM(L_PARTKEY) Version 6 Explain QB PN MT TABLE 1 1 0 PART 1 2 1 LINEITEM AT MC INDEX N 2 XPSTPM I 1 XLPART PF IXO SORTN SORTC PM AD AG JD JG SCG SNG N NNNN NNNN -. Once again we see the normal result of the successful use of parallelism: a large reduction in elapsed time at the cost of a small increase in CPU time. LINEITEM WHERE P_SIZE IN (3.-.--- Version 7 Explain QB PN MT TABLE 1 1 0 PART 1 2 1 LINEITEM AT MC INDEX N 2 XPSTPM I 1 XLPART PF IXO SORTN SORTC PM AD AG JD JG SCG SNG N NNNN NNNN C 10 1 -.P_PARTKEY.-. while the small CPU increase is due to the management of the extra tasks.P_MFGR) AND P_PARTKEY = L_PARTKEY AND L_QUANTITY < 5. 45. SUM(L_TAX). SELECT COUNT(*).-.-.--.-.P_TYPE.-.-. AVG(L_TAX) FROM PART. The reduction in elapsed time is in line with the parallelism degree of 10.--N NNNN NNNN -.

7% 3.Table 3-6 Columns in the LINEITEM table Column name L_ORDERKEY L_PARTKEY L_SUPPKEY L_LINENUMBER L_QUANTITY L_EXTENDEDPRICE L_DISCOUNT L_TAX L_RETURNFLAG L_LINESTATUS L_SHIPDATE L_COMMITDATE L_RECEIPTDATE L_SHIPINSTRUCT L_SHIPMODE L_COMMENT Definition INTEGER INTEGER INTEGER INTEGER DECIMAL DECIMAL DECIMAL DECIMAL CHAR(1) CHAR(1) DATE DATE DATE CHAR(25) CHAR(10) VARCHAR(44) Primary key column 2 of 2 Notes Primary key column 1 of 2 Table 3-7 IN-List performance test results for join Test V6 V7 Delta Elapsed secs 2611.7 +6. 3.3 Conclusions Significant improvements in elapsed time can be achieved by exploiting query parallelism for queries containing IN-list predicates.4 Recommendations Consider rebinding with DEGREE(ANY) those packages containing large queries for which Explain shows an access type of ‘N’.2. Chapter 3.22 23.2.3% CPU secs 22.92 278.46 -89. SQL performance 33 .

exp.) expression = <> > < >= <= = > < expression (fullselect) . The new operators are: (exp.3..3.CREATOR.2 Quantified predicates Quantified predicates also support row value expressions... T1. 3.) = SOME (fullselect) (exp..... exp.) = (exp..3 Row value expressions Prior to DB2 DB2 V7. Figure 3-7 Row value expression in basic predicates 3.TBNAME) = ('PAOLOR2'.. The new operators are: (exp...3. a predicate could compare a single column to a single expression. 'ACCOUNT') ORDER BY T1.. ( .. exp.TBCREATOR.SYSINDEXES T1 WHERE (T1.exp. expression2 ) = <> = ( expression2 ) New in V7 Basic predicates Show all indexes for table PAOLOR2.) <> ALL (fullselect) 34 DB2 for z/OS and OS/390 Version 7 Performance Topics ..) (exp.1 Equal and not equal predicates The equal and not equal operators now support multiple expressions on each side of the predicate as shown in Figure 3-7.. DB2 V7 supports row value expressions..ACCOUNT SELECT * FROM SYSIBM.. exp. refer to Figure 3-8. This is possible for the following predicates: = and <> quantified predicates IN and NOT IN with a subquery The use of each of these predicates is described below. exp.. and so a predicate can compare a list of columns to a list of expressions. exp.NAME. T1.) = ANY (fullselect) (exp.....) <> (exp.

T1. ( IN (fullselect) . then they must be enclosed in parentheses.CREATOR. Multiple expressions must appear on the left-hand side when a subquery that returns multiple columns is specified on the right-hand side. ( expression2 ) <> = ALL (fullselect2) Quantified predicate Show all DB2 indexes that support a unique constraint created in DB2 V7. SELECT T1.3. expression NOT .SYSINDEXES T1 WHERE (T1. ( expression2 ) = SOME ANY (fullselect2 ) New in V7 .IXOWNER.SYSTABCONST T2 WHERE T2. Figure 3-8 Row value expression in quantified predicates 3.expression1 = <> > < >= <= = > < SOME ANY ALL (fullselect1 ) . expression ( IN (fullselect) NOT ) New in V7 expression ) IN predicate Figure 3-9 IN predicate syntax Chapter 3.NAME) = SOME (SELECT T2.3 IN predicate with subquery DB2 V7 extends the syntax of the IN and NOT IN subquery predicate to allow multiple columns to be returned by the subquery. If multiple expressions are coded.CREATOR. See Figure 3-10 for an example. T1. SQL performance 35 .NAME FROM SYSIBM. It is important that the number and data type of the expressions on the left-hand side of the predicate match the number and data type of the columns in the subquery result set. T2. See Figure 3-9 for the IN predicate syntax. 2.IXNAME FROM SYSIBM.TYPE = 'U') ORDER BY 1.

TBCREATOR. T1.NAME FROM SYSIBM.CREATOR NOT IN (SELECT T2. For example.SYSINDEXES T2).CREATOR AND T2.’SYSINDEXES’)) 3. T2.TBNAME = T1.TBCREATOR. T1.3. T1.NAME. PREDICATE OPERATOR IS op.NAME) OR T1. only a subquery that returns multiple rows.TBNAME FROM SYSIBM. then SQLCODE -216 will be returned: -216 THE NUMBER OF ELEMENTS ON EACH SIDE OF A PREDICATE OPERATOR DOES NOT MATCH. T1. this predicate is not valid: WHERE (T1. the predicate is true if at least one expression does not match its equivalent column for each row in the subquery result.SYSTABLES T1 WHERE (T1.SYSINDEXES T2 WHERE T2. All versions of DB2 SELECT T1.SYSINDEXES T2) However.’SYSTABLES’).CREATOR) IN ((‘SYSIBM’. For an IN predicate.NAME. the predicate is true only if all expressions match their respective columns for at least one row in the subquery result. Multiple expressions are not valid in an IN-list.4 Restrictions If the number of expressions or columns returned on the right hand side do not match the number of expressions on the left hand side. DB2 V7 The same result set is returned by both these queries Figure 3-10 Row value expression for IN subquery 3.CREATOR) IN (SELECT T2.NAME FROM SYSIBM.5 Performance This is primarily a usability enhancement.SYSINDEXES T2 WHERE T2.CREATOR AND T2.NAME). T2.TBNAME = T1.TBCREATOR FROM SYSIBM.NAME NOT IN (SELECT T2. Rewriting a query to use row expressions may significantly change the access path for that query. 36 DB2 for z/OS and OS/390 Version 7 Performance Topics .SYSTABLES T1 WHERE T1. but it can impact performance.TBNAME FROM SYSIBM.TBCREATOR = T1.TBNAME FROM SYSIBM. (‘SYSIBM’.The predicate is evaluated by matching the first expression value against the first column value from the subquery result set.TBCREATOR = T1. Row expression for IN subquery View all tables in the that do not have any indexes defined SELECT T1. For a NOT IN predicate.CREATOR. T1.CREATOR. this predicate is valid: WHERE (T1.CREATOR.3.NAME) NOT IN (SELECT T2. The change may improve or worsen performance depending on the new access path. the second expression value against the second column value until all expression and column values are compared.

Since the access path is the same. as shown here in Figure 3-11. T1.NAME. If the number of qualified rows from the subquery is large. TBNAME. as shown in Figure 3-13. Chapter 3. SQL performance 37 . It is a matching index scan on two columns of the index DSNDXX03. CREATOR. Row expressions: SELECT L_DISCOUNT. AVG(L_QUANTITY*L_EXTENDEDPRICE) FROM LINEITEM WHERE L_ORDERKEY BETWEEN 10220001 and 1030000 AND L_QUANTITY>10 AND(L_SUPPLY.TBCREATOR = 'PAOLOR2' AND T1.CREATOR. Version 7 Explain: QB 1 1 PN 1 2 MT 0 3 TABLE SYSINDEXES AT I MC 2 0 INDEX DSNDXX03 PF L IXO N N SORTN NNNN NNNN SORTC NNNN NNYN JT QBT SELECT SELECT Figure 3-11 Row value expressions Explain example 1 Let us look at another example.CREATOR.Let us look at the example shown in Figure 3-7 on page 34 and the equivalent V6 query. the row expression generally tends to have worse performance. or using a join. Without row expressions: SELECT * FROM SYSIBM.PS_PARTKEY FROM PARTSUPP PS_SUPPLYCOST BETWEEN 115 AND 116) GROUP BY DISCOUNT. Here the rewrite can significantly alter the access path.TBNAME = 'ACCOUNT' ORDER BY T1. The column headings of the Explain output are described in Table 3-2 on page 27.TBCREATOR. and NAME. With row expressions: SELECT * FROM SYSIBM. T1. there is no performance impact of using a row expression in this case.TBNAME) = ('PAOLOR2'. Row QB 1 1 2 2 expressions MT 0 3 0 3 TABLE LINEITEM PARTSUPP Explain: AT N I MC 3 0 IXO Y Y Figure 3-12 Row value expression and Explain example 2 This query can be rewritten using EXISTS. the row expression shown in Figure 3-12. which contains key columns TBCREATOR. Performance in these queries depends on the number of rows that are qualified from the PARTSUPP table.SYSINDEXES T1 WHERE (T1.SUM(L_QUANTITY). 'ACCOUNT') ORDER BY T1.SYSINDEXES T1 WHERE T1. as shown in Figure 3-12.NAME. Both queries result in the same access path. T1.LPARTKEY)IN (SELECT PS_SUPPKEY.

DB2 V7 adds some additional situations when transformation can take place.Rewritten to correlated EXISTS: Rewritten to JOIN: SELECT L_DISCOUNT. 3. or column functions. or = SOME. for correlated subqueries only (for non-correlated subqueries. A subquery in a WHERE clause can be transformed. AVG(L_QUANTITY*L_EXTENDEDPRICE) FROM LINEITEM WHERE L_ORDERKEY BETWEEN 10220001 and 1030000 AND L_QUANTITY>10 AND EXISTS(SELECT * FROM PARTSUPP WHERE L_SUPPKEY=PS_SUPPKEY AND L_PARTKEY=PS_PARTKEY AND PS_SUPPLYCOST BETWEEN 115 AND 116) GROUP BY DISCOUNT. 38 DB2 for z/OS and OS/390 Version 7 Performance Topics .3.SUM(L_QUANTITY). = ANY. The transformation will not result in more than 15 tables in the join. but also when it is a searched UPDATE or DELETE statement.SUM(L_QUANTITY).3. AVG(L_QUANTITY*L_EXTENDEDPRICE) FROM LINEITEM. The subquery appears in the WHERE clause of a SELECT statement. 3.6 Conclusions Row expressions can make a query easier to read and understand. DB2 can transform a subquery (either correlated or non-correlated) into a join if a number of conditions are met: The subquery select list contains a single column guaranteed (by a unique index) to be unique. all conditions continue to apply): The requirement for the single column returned by the subquery to be unique is removed.PARTSUPP WHERE L_ORDERKEY BETWEEN 10220001 and 1030000 AND L_QUANTITY>10 AND L_SUPPKEY=PS_SUPPKEY AND L_PARTKEY=PS_PARTKEY AND PS_SUPPLYCOST BETWEEN 115 AND 116 GROUP BY DISCOUNT.4 Correlated subquery to join transformation Prior to DB2 V7. Row QB 1 1 2 expressions MT 0 3 0 TABLE LINEITEM PARTSUPP Explain: AT I I MC 1 3 IXO N Y SELECT L_DISCOUNT. The comparison operator of the predicate containing the subquery is IN. The subquery has only one table in the FROM clause. HAVING. Row expressions Explain: QB 1 1 1 MT 0 1 3 TABLE LINEITEM PARTSUPP AT I I MC 1 3 IXO N Y Figure 3-13 Rewritten query and Explain example 2 3. Performance can vary. The subquery does not contain GROUP BY. For a non-correlated subquery. not only when the outer statement is a SELECT.7 Recommendations Always compare the access paths with and without row expressions so that you are aware of any performance implications. the left side of the predicate is a single column with the same data type and length as the single column returned by the subquery (for a correlated subquery the left side can be any expression). The EXISTS predicate is supported.

1 Removal of uniqueness constraint Let us look first at the removal of the uniqueness requirement. The join gives DB2 the opportunity to process the smaller table first. CUST_NO INTEGER.4.C1 = T2. FOREIGN KEY ORD_CUST (CUST_NO) REFERENCES CUST ON DELETE RESTRICT 160 rows Index XOCNO: Non-unique index on ORD(CUST_NO) Index XODATE: Non-unique index on ORD(ORD_DATE) Figure 3-14 Table and index definitions for correlated subquery examples 3. PRIMARY KEY (ORD_NO). PRIMARY KEY (CUST_NO) 400 rows Index XCUSTNO: Unique index on CUST(CUST_NO) Table ORD: ORD_NO INTEGER NOT NULL. The table CUST is a Customer table. CUST_NAME CHAR(20). Chapter 3. The transformation is most likely to provide performance benefits when the result table in the subquery is much smaller than the outer table. In DB2 V7.2). If the correlation predicate uses other operators. TOWN CHAR(20). in order to avoid incorrect results. duplicates must be eliminated when accessing the ORD table. Figure 3-14 shows the definition of the tables used in the following examples. In DB2 V6 the correlated subquery is not transformed into a join. The table ORD is an Order table connected to the CUST table by RI. such as > and <. Table CUST: CUST_NO INTEGER NOT NULL. ORD_DATE DATE. Example 1 in Figure 3-15 shows a query in which the uniqueness of the subquery column is not guaranteed by a unique index. The CUST_NO column in the ORD table is not unique.Transformation for correlated subqueries in these new cases can only happen if the correlation predicate is an equal predicate (of the form T1. In Example 1 DB2 does this by retrieving only the first qualifying row when using the matching index scan on the index XOCNO (an index on the column CUST_NO).C2). CRED_LIM DEC(7. In DB2 V7 the correlated subquery is transformed into a nested loop join with the ORD table as the inner table of the join.2). SQL performance 39 . There is no transformation for a subquery in the SET clause of an UPDATE statement. AMOUNT DECIMAL(7. then the subquery will not be transformed.

Example 1: SELECT * FROM CUST C WHERE CUST_NO IN (SELECT CUST_NO FROM ORD O WHERE O. E x a mp l e 2: S E LE C T * F R O M C U ST C W H E R E C US T _ NO I N ( S EL E CT C US T _ N O F R OM O RD O W H ER E O .0 1 ') . This shows one of the advantages of the transformation. V e rs i on 6 Ex p l ai n : QB 1 2 PN 1 1 MT 0 0 T A BL E C U ST ORD AT R I MC 0 1 I N D EX X O D AT E PF S I XO N N SORTN NNNN NNNN S OR T C N NN N N NN N JT QBT S E LE C T C O RS U B V e rs i o n 7 Ex p l a in : QB 1 1 PN 1 2 MT 0 1 T A B LE ORD CUST AT I I MC 1 1 I N D EX X O D AT E X C U ST N O PF IXO N N S OR T N N NN N N NN N S O RT C N N NN Y Y NN JT QBT S E L EC T S E L EC T Figure 3-16 Subquery transformation — example 2 40 DB2 for z/OS and OS/390 Version 7 Performance Topics .AMOUNT = C. but with a restrictive predicate in the subquery (ORD_DATE < ‘1999-01-01’) which reduces the size of the subquery result set. In Example 2 this is done by sorting to eliminate the duplicate CUST_NO values. In DB2 V7 the query is again transformed into a nested loop join. Once again.CRED_LIM ).01 . This is shown in the Explain by SORTC_UNIQ = SORTC_JOIN = ‘Y’ in the join row. Version 6 Explain: QB 1 2 PN 1 1 MT 0 0 TABLE CUST ORD AT R R MC 0 0 INDEX PF S S IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT SELECT CORSUB Version 7 Explain: QB 1 1 PN 1 2 MT 0 1 TABLE CUST ORD AT R I MC 0 1 INDEX XOCNO PF S IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT SELECT SELECT Figure 3-15 Subquery transformation — example 1 Example 2 in Figure 3-16 shows the same query as before. O R D_ D AT E < ' 1 9 99 . It is accessed using the index XODATE which is an index on the ORD_DATE column. A M OU N T = C . It gives DB2 flexibility to decide in which order to process the tables. but this time the ORD table is the outer table.C R E D_ L IM AN D O . duplicate CUST_NO values must be eliminated from the ORD table to avoid incorrect results.

1 WHERE CUST_NO IN (SELECT CUST_NO FROM ORD O WHERE O.CRED_LIM).3. Example 3: SELECT * FROM CUST C WHERE EXISTS (SELECT 1 FROM ORD O WHERE O.4. Version 6 Explain: QB 1 2 PN 1 1 MT 0 0 TABLE CUST ORD AT R I MC 0 1 INDEX XOCNO PF S IXO N Y SORTN NNNN NNNN SORTC NNNN NNNN JT QBT SELECT CORSUB Version 7 Explain: QB 1 1 PN 1 2 MT 0 1 TABLE CUST ORD AT R I MC 0 1 INDEX XOCNO PF S IXO N Y SORTN NNNN NNNN SORTC NNNN NNNN JT QBT SELECT SELECT Figure 3-17 Subquery transformation — example 3 3.AMOUNT = C.3 Searched UPDATE and DELETE support Now let us look at subquery transformations for searched UPDATE and DELETE statements.CUST_NO = C. Once again.4. Figure 3-18 shows an UPDATE statement with a correlated subquery in the WHERE clause.2 Support for EXISTS predicate Example 3 in Figure 3-17 shows the transformation of a correlated subquery using an EXISTS predicate. DB2 eliminates duplicates by retrieving only the first qualifying row when using the matching index scan on the index XOCNO.CUST_NO). UPDATE CUST C SET CRED_LIM = CRED_LIM * 1. In DB2 V7 it is transformed into a nested loop join. SQL performance 41 . Version 6 Explain: QB 1 2 PN 1 1 MT 0 0 TABLE CUST ORD AT R R MC 0 0 INDEX PF S S IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT UPDATE CORSUB Version 7 Explain: QB 1 1 PN 1 2 MT 0 1 TABLE CUST ORD AT R I MC 0 1 INDEX XOCNO PF S IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT UPDATE UPDATE Figure 3-18 Subquery transformation for UPDATE Chapter 3.

Figure 3-19 shows a similar transformation for a DELETE statement.

DELETE FROM CUST C WHERE CUST_NO IN (SELECT CUST_NO FROM ORD O WHERE O.AMOUNT = C.CRED_LIM);

Version 6 Explain: QB 1 2 PN 1 1 MT 0 0 TABLE CUST ORD AT R R MC 0 0 INDEX PF S S IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT DELETE CORSUB

Version 7 Explain: QB 1 1 PN 1 2 MT 0 1 TABLE CUST ORD AT R I MC 0 1 INDEX XOCNO PF S IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT DELETE DELETE

Figure 3-19 Subquery transformation for DELETE

3.4.4 Subqueries that will still not be transformed in DB2 V7
The following subqueries will not be transformed into joins, for the reasons given. This query is not transformed because of the column function in the subquery select list:
SELECT * FROM ORD O WHERE CUST_NO IN (SELECT MAX(CUST_NO) FROM CUST C WHERE TOWN = 'MANCHESTER')

The uniqueness requirement has only been removed for correlated subqueries. Therefore the following query is not transformed because the subquery is not a correlated subquery and the CUST_NO column in the ORD table is not unique:
SELECT * FROM CUST C WHERE CUST_NO IN (SELECT CUST_NO FROM ORD O WHERE ORD_NO = 10 )

The following query is not transformed because the correlation predicate is not an equal predicate, but a greater than predicate:
SELECT * FROM CUST C WHERE CUST_NO IN (SELECT CUST_NO FROM ORD O WHERE O.AMOUNT > C.CRED_LIM )

42

DB2 for z/OS and OS/390 Version 7 Performance Topics

The following update is not transformed because the subquery is not in the WHERE clause (and also because of the use of the MAX function in the subquery):
UPDATE CUST C SET CRED_LIM = (SELECT MAX(AMOUNT) FROM ORD O WHERE O.CUST_NO = C.CUST_NO )

3.4.5 Performance
A performance test was run using the SQL shown in Figure 3-20. In DB2 V6 the access path was a table space scan for the outer table T1 and a matching index scan on the correlation column C1 of table T2 for the subquery. In DB2 V7 this was transformed to a nested loop join with T2 as the outer table accessed via a matching index scan on the column C3. Table T1 was joined via a matching index scan on the correlation column C1.

SELECT C1, C2, C3 FROM T1 X WHERE EXISTS (SELECT C1 FROM T2 WHERE T2.C3 = 'A' AND T2.C1 = X.C1)

T1 has 624473 rows. T2 has 1654700 rows of which 23 have C3 = 'A' after duplicate C1 values are removed Version 6 Explain: QB 1 2 PN 1 1 MT 0 0 TABLE T1 T2 AT R I MC 0 1

X1C1 is an index on table T1 column C1 X2C1 is an index on table T2 column C1 X2C3 is an index on table T2 column C3

INDEX X2C1

PF S

IXO N N

SORTN NNNN NNNN

SORTC NNNN NNNN

JT

QBT SELECT CORSUB

Version 7 Explain: QB 1 1 PN 1 2 MT 0 1 TABLE T2 T1 AT I I MC 1 1 INDEX X2C3 X1C1 PF IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT SELECT SELECT

Figure 3-20 Subquery transformation performance test for select

The test was repeated a number of times. The total measurements are shown in Table 3-8.
Table 3-8 Subquery transformation select performance
Elapsed (sec) V6 V7 Delta 227 2.8 -98.8% CPU (sec) 15.6 0.04 -99.7% Data getpage 216046 146 -99.9% Index getpage 18608 85 -99.5%

Chapter 3. SQL performance

43

An update test was also run as shown in Figure 3-21. The results are shown in Table 3-9.

UPDATE T1 X SET C2 = C2 + 1 WHERE C3 IN (SELECT C2 FROM T2 WHERE T2.C3 = 'A' AND T2.C1 = X.C1)

T1 has 624473 rows. T2 has 1654700 rows of which 23 have C3 = 'A' after duplicate C1 values are removed Version 6 Explain: QB 1 2 PN 1 1 MT 0 0 TABLE T1 T2 AT R I MC 0 1

X1C1 is an index on table T1 column C1 X2C1 is an index on table T2 column C1 X2C3 is an index on table T2 column C3

INDEX X2C1

PF S

IXO N N

SORTN NNNN NNNN

SORTC NNNN NNNN

JT

QBT UPDATE CORSUB

Version 7 Explain: QB 1 1 PN 1 2 MT 0 1 TABLE T2 T1 AT I I MC 1 1 INDEX X2C3 X1C1 PF IXO N N SORTN NNNN NNNN SORTC NNNN YYNN JT QBT UPDATE UPDATE

Figure 3-21 Subquery transformation performance test for update Table 3-9 Subquery transformation update performance
Elapsed (sec) V6 V7 Delta 225 0.4 -99.8% CPU (sec) 17.24 0.02 -99.9% Data getpage 216020 142 -99.9% Index getpage 18591 76 -99.6%

3.4.6 Restrictions and potential problems
There is no parallelism support for a correlated subquery that has been transformed into a join. Let us look at the Select performance measurements again, and include a V6 case with parallelism of degree 7. The results are shown in Table 3-10. We can see that transformation has reduced the elapsed time more than parallelism did, but has also reduced CPU cost (which increased with parallelism).
Table 3-10 Subquery transformation and parallelism
Elapsed (sec) V6 seq. V6 parallel, degree 7 V7 227 72.6 CPU (sec) 15.6 16.72 Data getpage 216046 Index getpage 18608

2.8

0.04

146

85

44

DB2 for z/OS and OS/390 Version 7 Performance Topics

It is possible that, in some cases, this new feature will degrade performance, primarily for dynamic SQL. That is most likely to happen when the outer query returns a small number of rows and the subquery returns a large number of rows. In such a case, transformation provides no performance benefit, but there is additional overhead to Prepare the statement with transformation activated. If this is a problem, you can implement APAR PQ45052. This APAR provides the possibility of disabling correlated subquery transformation when so advised by IBM support.

3.4.7 Conclusions
Significant performance benefits can result for SQL statements that contain correlated subqueries. The benefit is most apparent for subqueries which return small result sets while the outer statement processes a large number of rows. The bigger the outer table result relative to the subquery result, the better the performance improvement.

3.4.8 Recommendations
Consider rebinding packages containing SQL statements which might benefit from transformation. These SQL statements will contain correlated subqueries that return small result sets.

3.5 UPDATE/DELETE with self-referencing subselect
DB2 V7 allows searched UPDATE and DELETE statements to use the target tables within subqueries in the WHERE or SET clauses. This enhancement does not support UPDATE and DELETE WHERE CURRENT OF when the cursor definition contains a self referencing subquery. For example, the UPDATE statement in Figure 3-22 targets the table CUST. The WHERE clause in this statement uses a subquery to get the maximum credit limit for all accounts in the CUST table. Figure 3-23 shows an UPDATE with a self-referencing subquery in the SET clause.

UPDATE CUST SET CRED_LIM = CRED_LIM * 1.1 WHERE CRED_LIM < (SELECT MAX(CRED_LIM) FROM CUST )
Figure 3-22 UPDATE with self-referencing subquery in WHERE clause

UPDATE CUST C1 SET CRED_LIM = (SELECT MAX(CRED_LIM) FROM CUST C2 WHERE C2.TOWN = C1.TOWN)

Figure 3-23 UPDATE with self-referencing subquery in SET clause

Chapter 3. SQL performance

45

In previous versions of DB2, this self-referencing would not be allowed. The following -118 SQLCODE would be returned, and the statement would fail:
-118 THE OBJECT TABLE OR VIEW OF THE DELETE OR UPDATE STATEMENT IS ALSO IDENTIFIED IN A FROM CLAUSE

DB2 now will accept the syntax of this statement, and the SQLCODE -118 will not be returned.

3.5.1 Executing the self-referencing UPDATE/DELETE
In order to maintain data integrity, this enhancement requires that the subquery is evaluated completely before any updates or deletes take place. For a non-correlated subquery, the subquery will be evaluated once and the result produced, the WHERE clauses will be tested and any valid rows will be updated or deleted. Two-step processing of the outer statement may be required for correlated subqueries. The first step creates a work file and inserts the RID for a delete or RID and column value for an update. After all rows of the outer statement have been processed, the second step reads the work file. For each row in the work file, DB2 repositions on the record in the base table pointed to by the RID, and then either updates or deletes the row as required. This two-step processing is not shown in the Explain output. Two-step processing will be used for an UPDATE whenever a column that is being updated is also referenced in the WHERE clause of the UPDATE or is used in the correlation predicate of the subquery. This is shown in the examples in Figure 3-24. For a DELETE statement, two-step processing will always be used for a correlated subquery.

UPDATE CUST C1 SET CRED_LIM = CRED_LIM *1.1 WHERE CRED_LIM < (SELECT MAX(CRED_LIM) FROM CUST C2 WHERE C2.TOWN = C1.TOWN);

Two-step processing will occur because the updated column appears in the WHERE clause of the UPDATE.

UPDATE ORD O1 Two-step processing will occur because the SET CUST_NO = CUST_NO + 1000 updated column appears in the correlation WHERE AMOUNT < (SELECT MAX(AMOUNT) predicate of the subquery. FROM ORD O2 WHERE O2.CUST_NO = O1.CUST_NO);

UPDATE CUST C1 Two-step processing will NOT occur because the SET CRED_LIM = CRED_LIM *1.1 updated column does not appear either in the WHERE EXISTS (SELECT 1 WHERE clause of the UPDATE or the correlation FROM CUST C2 WHERE TOWN = 'MANCHESTER' predicate of the subquery. AND C2.CUST_NO = C1.CUST_NO);

Figure 3-24 Two-step processing for an UPDATE

46

DB2 for z/OS and OS/390 Version 7 Performance Topics

EXEC SQL DECLARE CURSOR C1 CURSOR FOR SELECT T1. Query 1 .TOWN = C1. . The two update statements and their Explain outputs are shown in Figure 3-26.TOWN) .not self-referencing UPDATE CUST C1 SET CRED_LIM = CRED_LIM *1. A simple test was run. Query 2 .CRED_LIM) FROM CUST T2) FOR UPDATE OF T1.CRED_LIM.2 Restrictions on usage DB2 positioned updates and deletes will still return the SQLCODE -118 if a subquery in the WHERE clause references the table being updated or deleted from.CUST_NO.1 WHERE CRED_LIM < (SELECT MAX(CRED_LIM) FROM CUST C2 WHERE C2. The table CUST2 is identical in every way to the table CUST. . EXEC SQL OPEN C1.5.TOWN = C1. .TOWN) .CRED_LIM FROM CUST T1 WHERE T1. T1. EXEC SQL FETCH C1 INTO :HV-CNO. . S Q L C O D E -1 1 8 a t B in d tim e Figure 3-25 Positioned update with self-referencing subquery not supported 3. . :HV-CNAME. These figures are not from measurements in a fully controlled environment (DB2 was dedicated. SQL performance 47 .3 Performance The only performance issues relate to the two-step processing of a correlated subquery. QB 1 2 PN 1 1 MT 0 0 TABLE CUST CUST2 AT R R MC 0 0 INDEX PF S S IXO N N PQ 0 1 TT T T SORTN NNNN NNNN SORTC NNNN NNNN JT CFE R QBT UPDATE CORSUB QB 1 2 PN 1 1 MT 0 0 TABLE CUST CUST AT R R MC 0 0 INDEX PF S S IXO N N PQ 0 1 TT T T SORTN NNNN NNNN SORTC NNNN NNNN JT CFE QBT UPDATE CORSUB Figure 3-26 Self-referencing UPDATE performance test Chapter 3. The test compared an update using a correlated subquery accessing a different table to a similar update where the correlated subquery referenced the same table as the update. T1.CREDIT_LIMIT < (SELECT AVG(T2.self-referencing UPDATE CUST C1 SET CRED_LIM = CRED_LIM *1. EXEC SQL UPDATE CUST SET CRED_LIM = CRED_LIM * 1. See Figure 3-25 for an example.CUST_NAME.1 WHERE CURRENT OF C1.3.1 WHERE CRED_LIM < (SELECT MAX(CRED_LIM) FROM CUST2 C2 WHERE C2. :HV-CRDLMT. .5. not the hardware). but they are indicative of relative cost.

48 DB2 for z/OS and OS/390 Version 7 Performance Topics . BP1 contained both tables and BP7 contained the work table spaces in DSNDB07. There were 16 rows for each of the 10 different values of the column TOWN. That work file is then read to apply the updates. The actual increase in BP1 getpages is 76. 3. Be aware of the cost of two-step processing when using a correlated subquery. if randomly distributed. Table 3-12 Self-referencing UPDATE versus INSERT and non-self-referencing update Test Insert + nonself-reference Self-reference Delta BP1 getpage 1080 1063 -17 BP1 update 552 224 -328 BP7 getpage 0 4 +4 BP7 update 0 4 +4 3. although this will probably still perform better than the equivalent solution without a self-referencing update.5.5 Recommendations Use this feature where it is needed.4 Conclusions This enhancement is primarily functional. we get the results shown in Table 3-12.5. of which 15 had less than the maximum value of CRED_LIM for that TOWN value. The rows in the CUST table are mapped two per page (MAXROWS 2). There may be some performance penalty for using a self-referencing correlated subquery because of the two-step processing.Each table (CUST and CUST2) contained 160 rows. would be held on 75 pages. Table 3-11 Self-referencing UPDATE test results Test Non-selfreference Self-reference Delta BP1 getpage 987 1063 +76 BP1 update 224 224 0 BP7 getpage 0 4 +4 BP7 update 0 4 +4 The extra activity in BP7 for the self-referencing test is caused by creating a work file containing the RIDs and new column values for the 150 rows to be updated. The self-referencing update performs better overall in this case. The performance figures related to the getpage and update counts from the Accounting trace are shown in Table 3-11. Perhaps a more realistic comparison is to replace the non-self-referencing case with one that copies the rows into the CUST2 table before doing the update using that CUST2 table in the subquery. Therefore 150 rows. Let us measure the following INSERT: INSERT INTO CUST2 SELECT * FROM CUST If we do this immediately followed by the update shown as Query 1 in Figure 3-26 on page 47. The extra getpages to BP1 are caused by this second updating step.

c o lu m n . in predicates. c o lu m n -n a m e ) CASCADED W IT H LO CAL CHECK O P T IO N C R E A T E V IE W AS v ie w . This enhancement extends compatibility with other members of the DB2 UDB family and complies with the SQL99 standard.1 UNION syntax changes The syntax of the CREATE VIEW is shown in Figure 3-27. DB2 V7 has expanded the use of unions to anywhere that a subselect clause was valid in previous versions of DB2. SQL performance 49 . This meant that UNIONs were basically limited to the SELECT statement.n a m e ( .3. it can be replaced by a fullselect in DB2 V7. UNIONs could not be used to create a VIEW. or in INSERT and UPDATE statements.6 UNION everywhere Prior to DB2 V7.6.n a m e ( .n a m e ) f u lls e le c t W IT H CASCADED LO CAL C H E C K O P T IO N Figure 3-27 CREATE VIEW syntax Chapter 3. Wherever a subselect was supported in DB2 V6. the use of UNIONs was limited to only those places which accepted a fullselect clause. V6 CREATE V IE W S y n ta x V7 CREATE V IE W S y n ta x CREATE V IE W A S s u b s e le c t v ie w . It is now possible to code a UNION or UNION ALL in: A view A table expression A predicate An INSERT statement The SET clause of an UPDATE statement A declared temporary table 3. in table expressions.

r e f e r e n c e subs ( TABLE c o r r e la t i o n .c la u s e fu lls e le c t ) c o r r e la tio n .An example is shown in Figure 3-28. CRED_LIM FROM CUST WHERE CUST_NAME LIKE 'S%' . TOWN.s p e c ta b le -s p e c ta b le . CRED_LIM FROM CUST WHERE CRED_LIM > 1000 UNION ALL SELECT CUST_NO.lo c a t o r .f u n c t i o n .c la u s e t a b l e . V7: OK V6: DSNT408I SQLCODE = -154.ta b le ta b le -s p e c ta b le . TOWN.lo c a t o r . CUST_NAME.c l a u s e V 7 ta b le . CREATE VIEW CUST_X AS SELECT CUST_NO. ERROR: THE STATEMENT IS INVALID BECAUSE THE VIEW OR TABLE DEFINITION CONTAINS A UNION.n a m e v ie w -n a m e t a b l e .f u n c t i o n .ta b le Figure 3-29 Table expression syntax 50 DB2 for z/OS and OS/390 Version 7 Performance Topics .s p e c t a b l e .r e f e r e n c e ( T A B LE c o r r e la tio n .r e fe r e n c e jo in e d . TOWN. CRED_LIM FROM CUST WHERE TOWN = 'MANCHESTER' UNION ALL SELECT CUST_NO. V 6 ta b le . OR A REMOTE OBJECT Figure 3-28 UNION in a view The syntax of a table expression is shown in Figure 3-29. A UNION ALL.n a m e v ie w -n a m e t a b l e . CUST_NAME.r e fe r e n c e jo in e d .c l a u s e e le c t ) c o r r e la t i o n . CUST_NAME.

An example is shown in Figure 3-30. ( . e x p re s s io n 1 = <> > < >= <= = > < SOME ANY ALL (fu lls e le c t1 ) c h a n g e d f ro m s u b s e le c t . ( e x p re s s io n 2 ) = SOME ANY (f u lls e le c t2 ) . ( e x p re s s io n 2 ) <> = ALL (fu lls e le c t2 ) Q u a n tifie d p re d ic a te Figure 3-32 Quantified predicate syntax Chapter 3. SQL performance 51 . SELECT * FROM (SELECT * FROM CUST WHERE TOWN = 'MANCHESTER' UNION ALL SELECT * FROM CUST WHERE CRED_LIM > 1000 ) AS T WHERE CUST_NO < 1000 ORDER BY CUST_NO V7: OK V6: DSNT408I SQLCODE = -199. TOKEN ) WAS Figure 3-30 UNION in a table expression The syntax for a basic predicate is shown in Figure 3-31. e xpre ssio n = <> > < >= <= = > < exp re ssio n (fullse le c t) c ha nge d fro m su bs e lec t . ERROR: EXPECTED ILLEGAL USE OF KEYWORD UNION. e xpression 2 ) = <> < ( e xpre ssio n 2 ) B a s ic pre d ic a te s Figure 3-31 Basic predicate syntax The syntax for a quantified predicate is shown in Figure 3-32.

SE LE CT * FR OM O RD O WH ER E CU S T_ NO I N ( SE L EC T CU ST _N O F RO M CU ST W HE RE T OW N = ' MA NC HE ST ER ' UN I ON A LL SE L EC T CU ST _N O F RO M CU ST W HE RE C RE D_ LI M > 1 00 0 ) OR DE R BY CU ST _N O. O RD _ NO V7 : OK V6 SPU F I: D SN T 40 8I S QL CO DE = .0 84 . ER RO R : U N AC CE PT A BL E SQ L ST AT E ME NT Figure 3-35 UNION in a predicate example 52 DB2 for z/OS and OS/390 Version 7 Performance Topics .The syntax for an IN predicate is shown in Figure 3-33. ch an g ed fro m s u b s ele ct E X IS T S (fu lls e le ct) E X IS T S p re d ica te Figure 3-34 EXISTS predicate syntax An SQL example of a UNION in a predicate is shown in Figure 3-35. changed from subselect expression NOT . ( expression IN (fullselect) NOT ) expression ) IN predicate Figure 3-33 IN predicate syntax The syntax for an EXISTS predicate is shown in Figure 3-34. ( IN (fullselect) .

Here is the precise order in which these operations are done: 1. after predicate distribution. Prune the subselects. The predicates from the query WHERE clause are distributed to the WHERE clauses of the individual subqueries. Any subselect where the predicates. extended to support a fullselect. 'LEEDS') This is so. SQL performance 53 . Chapter 3. is shown in Figure 3-36. ( column-spec LIKE table-name ) table-name view-name INCLUDING IDENTITY COLUMN ATTRIBUTES AS-(-fullselect-)-DEFINITION ONLY AS-attribute changed from subselect DECLARE GLOBAL TEMPORARY TABLE Figure 3-36 DECLARE GLOBAL TEMPORARY TABLE syntax 3. DECLARE GLOBAL TEMPORARY TABLE . Then pruning removes the subquery with the predicate: WHERE TOWN = 'MANCHESTER' AND TOWN IN ('LONDON'. 4.The syntax for the DECLARE TEMPORARY TABLE. Pruning of subqueries.6. joins. Distribute the aggregations. 3.2 Optimization DB2 uses two techniques to optimize access paths containing UNIONs. Distribute the joins. These are: Distribution of predicates. and aggregation. always evaluate to False will be removed by pruning. because the predicate will always evaluate to False. An example of using the first two of these operations is shown in Figure 3-37. 2. Distribute the predicates. and therefore a UNION.

You must use the PARENT_QBLOCK (PQ) values to identify dependencies between query blocks. CUST_NAME. It is easier to see what is happening if we re-sequence the rows as shown in the second Explain example. in ascending query block number. For a description of the headings used in the Explain output. CUST_NAME. so that the parent query block comes before its dependent query blocks. 'LEEDS'). TOWN. CRED_LIM FROM CUST WHERE TOWN = 'MANCHESTER' AND TOWN IN ('LONDON'. In our example. CRED_LIM FROM CUST WHERE TOWN = 'MANCHESTER' UNION ALL SELECT CUST_NO. CRED_LIM FROM CUST WHERE CRED_LIM > 1000 AND TOWN IN ('LONDON'. see Table 3-2 on page 27. TOWN. Subquery pruning SELECT CUST_NO. 'LEEDS') UNION ALL SELECT CUST_NO. CUST_NAME. CUST_NAME. 'LEEDS'). TOWN. TOWN. The first Explain example has the rows ordered in the normal way. TOWN. CUST_NAME. CRED_LIM FROM CUST WHERE CUST_NAME LIKE 'S%' AND TOWN IN ('LONDON'. 54 DB2 for z/OS and OS/390 Version 7 Performance Topics . Figure 3-37 UNION optimization The Explain output is shown in Figure 3-38. 'LEEDS') UNION ALL SELECT CUST_NO. 'LEEDS'). TOWN. UNION ALL SELECT CUST_NO. SELECT * FROM CUST_X WHERE TOWN IN ('LONDON'. TOWN. CRED_LIM FROM CUST WHERE CUST_NAME LIKE 'S%' AND TOWN IN ('LONDON'. CUST_NAME. both query block 1 and query block 5 are children of query block 2. CRED_LIM FROM CUST WHERE CUST_NAME LIKE 'S%'. CRED_LIM FROM CUST WHERE CRED_LIM > 1000 AND TOWN IN ('LONDON'. CRED_LIM FROM CUST WHERE CRED_LIM > 1000 UNION ALL SELECT CUST_NO. CUST_NAME. 'LEEDS'). TOWN.CREATE VIEW CUST_X AS SELECT CUST_NO. CUST_NAME. the QBLOCKNO values are not indicative of dependencies between the query blocks. Predicate distribution SELECT CUST_NO. When UNION optimization takes place.

Q = Temporary intermediate result table (not materialized). W = Workfile) Figure 3-38 Explain output for UNION optimization In this example. It depends on the fact that both the predicates in the view (or table expression) and the predicates in the main SELECT are specified as literal constants. The Explain row with QBLOCK_TYPE (QBT) set to ‘SELECT’ does not represent any actual work when the query executes. This will not show in the Explain output. T = Table. the pruning shown here is performed at Bind time. shown in Figure 3-39. If host variables are used. we can see the effect of pruning. It is merely documentation showing that the two component queries are combined with a UNION ALL. SELECT * FROM CUST_X ORDER BY CUST_NO QB 1 1 2 3 4 5 PN 1 2 1 1 1 1 MT 0 3 0 0 0 0 TABLE CUST_X CUST CUST CUST AT MC INDEX R 0 0 0 R 0 R 0 R 0 PF IXO PQ S N 0 N 0 1 S N 2 S N 2 S N 2 TT W -W T T T SORTN NNNN NNNN NNNN NNNN NNNN NNNN SORTC JT QBT NNNN SELECT NNYN SELECT NNNN UNIONA NNNN NCOSUB NNNN NCOSUB NNNN NCOSUB Figure 3-39 UNION without pruning Chapter 3. For static SQL. There are only two component subqueries. 'LEEDS'). Some pruning can be deferred until execution time if host variables are used. Now let us look at a simpler example. The pruning takes place once the contents of the host variables are known. where no pruning takes place.SELECT * FROM CUST_X WHERE TOWN IN ('LONDON'. SQL performance 55 . QB 1 2 5 PN 1 1 1 MT 0 0 0 TABLE CUST CUST AT R R MC 0 0 0 INDEX PF S S IXO N N PQ 2 0 2 TT T W T SORTN NNNN NNNN NNNN SORTC NNNN NNNN NNNN JT QBT NCOSUB SELECT NCOSUB Resequence rows into parent/child order QB 2 1 5 PN 1 1 1 MT 0 0 0 TABLE CUST CUST AT R R MC 0 0 0 INDEX PF S S IXO N N PQ 0 2 2 TT W T T SORTN NNNN NNNN NNNN SORTC NNNN NNNN NNNN JT QBT SELECT NCOSUB NCOSUB Note new V7 PLAN_TABLE columns: PQ = PARENT_QBLOCK (QBLOCKNO of parent query block) TT = TABLE_TYPE (F = Table Function. then DB2 cannot determine at Bind time that the combination of predicates will always evaluate to False.

CUST_NO QB 1 1 2 6 6 7 7 8 8 PN 1 2 1 1 2 1 2 1 2 MT 0 4 0 0 3 0 4 0 4 TABLE ORD CUST DSNWFQB(02) ORD CUST ORD CUST AT I I R I I I I MC 0 1 0 0 0 0 1 0 1 INDEX XOCNO XCUSTNO PF S L S IXO N N N N N N N N XOCNO XCUSTNO XOCNO XCUSTNO S L S L PQ 2 2 6 0 0 2 2 2 2 TT T T W W -T T T T SORTN NNNN NNNN NNNN NNNN NNNN NNNN NNNN NNNN NNNN SORTC NNNN NNNN NNNN NNNN NNNY NNNN NNNN NNNN NNNN CFE S QBT NCOSUB NCOSUB UNIONA SELECT SELECT NCOSUB NCOSUB NCOSUB NCOSUB Resequence rows into parent/child order QB 6 6 2 1 1 7 7 8 8 PN 1 2 1 1 2 1 2 1 2 MT 0 3 0 0 4 0 4 0 4 TABLE DSNWFQB(02) AT R MC 0 0 0 0 1 0 1 0 1 INDEX PF S IXO N N N N N N N N PQ 0 0 6 2 2 2 2 2 2 TT W -W T T T T T T SORTN NNNN NNNN NNNN NNNN NNNN NNNN NNNN NNNN NNNN SORTC NNNN NNNY NNNN NNNN NNNN NNNN NNNN NNNN NNNN CFE S QBT SELECT SELECT UNIONA NCOSUB NCOSUB NCOSUB NCOSUB NCOSUB NCOSUB ORD CUST ORD CUST ORD CUST I I I I I I XOCNO XCUSTNO XOCNO XCUSTNO XOCNO XCUSTNO S L S L S L Figure 3-40 Distribution of joins and aggregations We cannot see how the AVG function is processed from the Explain. Figure 3-40 shows a join using the AVG function against the view containing UNIONs.AMOUNT) FROM CUST_X X INNER JOIN ORD O ON X.CUST_NO = O. are the three component subqueries.We do not need to resequence the Explain rows this time.CUST_NO GROUP BY X. These are then written to a workfile and sorted for the GROUP BY. Query block 1 shows that the rows are read from that workfile and sorted into ORDER BY sequence. Query block 2 documents that they are combined using UNION ALL and written to a work file. SELECT X. The value ‘Q’ indicates that the result of the UNION or UNION ALL is fed directly to the parent Query Block without materialization. AVG(O. Now let us look at the distribution of joins and aggregations.CUST_NO ORDER BY X. 56 DB2 for z/OS and OS/390 Version 7 Performance Topics . but the result of the internal rewrite will be similar to that shown in Figure 3-41. The value ‘W’ indicates that the result of a UNION or UNION ALL is materialized into a Logical Work File (LWF) and subsequently read from that LWF. and 5. 4. Query blocks 3. The TABLE_TYPE (TT) column can contain either ‘W’ or ‘Q’ when a temporary result table is processed. we can see that the join has been distributed to the individual component subqueries. When the Explain rows are reordered.CUST_NO. The CASE expression and the use of SUM and COUNT values from the component selects are required to ensure correct handling of null values when calculating the average.

SELECT X. SQL performance 57 . it may be necessary to code redundant predicates in the view definition or nested table expression. COUNT(O3.CUST_NO.3 Requirements for subquery pruning When defining a view or a nested table expression that incorporates UNION or UNION ALL connectors.CUST_NO.CUST_NO = O2.TOWN = 'MANCHESTER' GROUP BY C1. AMOUNT) AS SELECT * FROM MONTH1 UNION ALL SELECT * FROM MONTH2 UNION ALL SELECT * FROM MONTH3 UNION ALL SELECT * FROM MONTH4 .CUST_NO = O. SUM(O1.CUST_NO Figure 3-41 Possible query rewrite 3. We can define a view on these tables as follows: CREATE VIEW ALL_ORD (ORD_NO.AMOUNT) FROM CUST C2 INNER JOIN ORD O2 ON C2.. SUM(O3. where a logical order table is stored in multiple DB2 tables..CUST_NO.AMOUNT) FROM CUST_X X INNER JOIN ORD O ON X. SUM(O2. CUST_NO.CUST_NO.CUST_NAME LIKE 'S%' GROUP BY C3.CUST_NO SELECT CUST_NO.AMOUNT) FROM CUST C3 INNER JOIN ORD O3 ON C3.CRED_LIM > 1000 GROUP BY C2.CUST_NO = O3.CUST_NO ORDER BY X.CUST_NO = O1. CASE WHEN SUM(CNT_X) = 0 THEN NULL ELSE SUM(SUM_X)/SUM(CNT_X) END FROM ( SELECT C1. AVG(O. SUM_X.AMOUNT) FROM CUST C1 INNER JOIN ORD O1 ON C1.AMOUNT). We can then execute a SELECT against this view which restricts the rows retrieved by ORD_DATE value: SELECT * FROM ALL_ORD WHERE ORD_DATE BETWEEN ‘2001-03-01’ AND ‘2001-03-31’.CUST_NO ORDER BY X. COUNT(O2. Consider the example shown in Figure 3-42.AMOUNT). ORD_DATE. COUNT(O1. Each table definition looks like the ORD table shown in Figure 3-14 on page 39.CUST_NO GROUP BY X. CNT_X) GROUP BY X.CUST_NO UNION ALL SELECT C3.CUST_NO ) AS X (CUST_NO.CUST_NO WHERE C3.AMOUNT).6.CUST_NO UNION ALL SELECT C2. with each table holding one month of data. Chapter 3.CUST_NO WHERE C2.CUST_NO WHERE C1.

thus significantly improving performance. The subqueries that access each of the other tables can be pruned. then the SELECT statement can benefit from subquery pruning: CREATE VIEW ALL_ORD (ORD_NO. we will not get subquery pruning in this case. Figure 3-42 Multiple ORDER tables. CUST_NO. SELECT * FROM MONTH1 WHERE ORD_DATE BETWEEN UNION ALL SELECT * FROM MONTH2 WHERE ORD_DATE BETWEEN UNION ALL SELECT * FROM MONTH3 WHERE ORD_DATE BETWEEN UNION ALL SELECT * FROM MONTH4 WHERE ORD_DATE BETWEEN . we must code redundant predicates in the view definition to tell the Optimizer that the ORD_DATE values are limited for each table. ORD_DATE. 58 DB2 for z/OS and OS/390 Version 7 Performance Topics .. but the DB2 Optimizer does not know this.. In order to get subquery pruning. We know that the range of ORD_DATE values in each table is limited. one per month However. If we change the view definition as follows. the Optimizer can recognize that our SELECT statement only needs to access the MONTH3 table. AMOUNT) AS ‘2001-01-01’ AND ‘2001-01-31’ ‘2001-02-01’ AND ‘2001-02-28’ ‘2001-03-01’ AND ‘2001-03-31’ ‘2001-04-01’ AND ‘2001-04-30’ With this revised view definition.Order data in multiple tables by month Stores ORD_DATE values between 2001-01-01 and 2001-01-31 MONTH1 MONTH2 Stores ORD_DATE values between 2001-02-01 and 2001-02-28 MONTH3 Stores ORD_DATE values between 2001-03-01 and 2001-03-31 MONTH4 Stores ORD_DATE values between 2001-04-01 and 2001-04-30 and so on ...

for example. any joins must be distributed by the Optimizer. There are no predicates to be applied to the UNION ALL result table. the APAR should improve performance. In other words. It had a partitioning index and one non-partitioning index. The PTF for APAR PQ47178 solves this problem. because of a GROUP BY or ORDER BY. The 10 small tables each contained 1 million rows and had two indexes. This is not always necessary and may cause some performance impact.ORD_DATE BETWEEN ‘2001-03-01’ AND ‘2001-03-31’. In other words.6. 3. If all these conditions are met for a query. Only simple columns (not arithmetics or scalar functions) and simple column functions (containing simple columns and no expressions) appear in the select list of the parent QB.The same is true if we had used a nested table expression in the SELECT instead of a view. The parent QB references no other tables in the FROM clause after join distribution has taken place. The DB2 Optimizer may materialize the result of the UNION ALL into a work file.. SQL performance 59 . The APAR should improve performance for queries in which all the following conditions are true: The UNION ALL result table is referenced in the parent Query Block (QB) FROM clause as a table expression or view. The partitioned table had 10 partitions and contained 10 million rows.5 Performance A number of tests were performed to compare the effect of accessing one large partitioned table versus a UNION of 10 smaller non-partitioned tables. 3. ) AS ALL_ORD WHERE ALL_ORD. We still need to code the redundant predicates to get subquery pruning: SELECT * FROM ( SELECT * FROM MONTH1 WHERE ORD_DATE BETWEEN ‘2001-01-01’ AND ‘2001-01-31’ UNION ALL SELECT * FROM MONTH2 WHERE ORD_DATE BETWEEN ‘2001-02-01’ AND ‘2001-02-28’ UNION ALL SELECT * FROM MONTH3 WHERE ORD_DATE BETWEEN ‘2001-03-01’ AND ‘2001-03-31’ UNION ALL SELECT * FROM MONTH4 WHERE ORD_DATE BETWEEN ‘2001-04-01’ AND ‘2001-04-30’ . Table 3-14.6. Chapter 3. 200000 rows and one row respectively from the large table and from a view which is a UNION ALL of the ten small tables. This APAR is intended to avoid or reduce materialization of the result set in cases where this is not necessary. The tests selected 10 million rows.. The parent QB needs to perform a DB2 sort on the UNION ALL result table.4 UNION ALL materialization At the time of writing. The Class 2 elapsed and CPU times in seconds for each test are shown in Table 3-13. The query shown in Figure 3-40 on page 56 would meet the criteria for improvement by the APAR. and Table 3-15. all predicates must have been distributed. In the Explain output you will see the TABLE_TYPE change from ‘W’ (workfile materialization) to ‘Q’ (queue without materialization). there is a restriction when UNION ALL is used in a view or in a nested table expression.

Table 3-13 Select 10 million rows
Target Class 2 Elapsed Class 2 CPU

View of 10 tables Large table

751 777

206 204

Table 3-14 Select 200 thousand rows
Target Class 2 Elapsed Class 2 CPU

View of 10 tables Large table
Table 3-15 Select one row
Target

19.1 18

4.9 4.9

Class 2 Elapsed

Class 2 CPU

View of 10 tables Large table

0.018 0.017

0.006 0.005

It can be seen that the performance of the view with UNION ALL is comparable to the single large table in these tests.

3.6.6 Conclusions
This is primarily a usability enhancement. Our tests showed no significant performance degradation.

3.6.7 Recommendations
Always check the performance impact of using UNION or UNION ALL by Explaining sample queries. Make sure that PTFs for APAR PQ47178 and PQ48588 are applied in order to achieve the best possible performance.

3.7 Scrollable cursors
With the previous versions of DB2, you could only scroll cursors in a forward direction. When a cursor was opened, it would be positioned before the first row of the result set. When a FETCH was executed, the cursor would move forward one row. If you wanted to move backwards in a result set, there were a number of options. One option was to CLOSE the current cursor and to re-OPEN it with a new starting value. The cursor would be something like this:
SELECT ORD_NO, CUST_NO, ORD_DATE, AMOUNT FROM ORD WHERE ORD_NO >= :START-ORD ORDER BY ORD_NO;

If you remember the ORD_NO value that you wish to re-position to, you can close the cursor, move the re-positioning value to the host variable START-ORD and then open the cursor again. If the access path involves a DB2 sort for the ORDER BY, then this can be an expensive process as each open re-sorts a subset of the rows.

60

DB2 for z/OS and OS/390 Version 7 Performance Topics

A second alternative was to build arrays in the program’s memory. The result set would be opened and all the rows would be read into the array. The program would, then move backwards and forwards within this array. This option needed to be carefully planned, as it could waste memory through low utilization of the space, or it could restrict the number of rows returned to the user to some arbitrary number. It was also hampered by the break between the actual data in the table and the data in the array. If other users were changing data, the program would not be aware of this, as there was no fixed relationship between the array data and the table data once read. If you needed to detect updates made by other users after the array was populated, the normal procedure was to re-select the row to see if the data had changed. DB2 V7 introduces scrollable cursors, which allow scrolling backwards as well as forwards. They also provide the ability to place the cursor at a specific row within the result set. A scrollable cursor can be sensitive or insensitive to updates made outside the cursor, by the same user or by different users. Scrollable cursors will be of most use for client/server applications and conversational transactions. CICS and IMS transactions are normally written using a pseudo-conversational structure, in which the transaction is terminated at each screen I/O. This termination at screen I/O will prevent the effective use of scrollable cursors because all cursors are closed by transaction termination.

3.7.1 Functional description
New keywords have been added to both the DECLARE CURSOR and FETCH statements to support scrollable cursors. The new syntax for DECLARE CURSOR is shown in Figure 3-43, and for FETCH in Figure 3-44.

DECLARE cursor-name

New in V7
CURSOR

INSENSITIVE SENSITIVE STATIC FOR

SCROLL

WITH HOLD WITH RETURN

select-statement statement-name
DECLARE CURSOR

Figure 3-43 DECLARE CURSOR syntax

The DECLARE CURSOR statement specifies that the cursor is scrollable by including the SCROLL keyword. If SCROLL is specified, then either INSENSITIVE or SENSITIVE STATIC must also be specified. In DB2 V7, SENSITIVE cursors are always STATIC. SENSITIVE DYNAMIC scrollable cursors will be supported in a later release of DB2 for z/OS and OS/390. INSENSITIVE cursors are strictly read-only. You cannot specify FOR UPDATE OF. They will not be aware of updates made by others. SENSITIVE STATIC cursors are updatable and may also be made sensitive to updates made by others.

Chapter 3. SQL performance

61

FETCH INSENSITIVE SENSITIVE NEXT PRIOR FIRST LAST CURRENT BEFORE AFTER ABSOLUTE RELATIVE

New in V7
host-variable integer-constant host-variable integer-constant

FROM

cursor-name single-fetch-clause
single-fetch-clause , host-variable INTO descriptor-name USING DESCRIPTOR FETCH

Figure 3-44 Fetch syntax

The FETCH statement can be either INSENSITIVE or SENSITIVE. If the cursor is defined as INSENSITIVE SCROLL, then only FETCH INSENSITIVE is supported. If the cursor is defined as SENSITIVE STATIC SCROLL, then a FETCH for the cursor can be either INSENSITIVE or SENSITIVE. It is the mode of the FETCH that determines whether or not updates made by others are seen by the cursor. A SENSITIVE cursor always sees its own updates but, when a specific row is FETCHed, it is the SENSITIVE or INSENSITIVE specification on the FETCH that determines whether or not updates to the row made by others will be seen by the FETCH. Scrollable cursors make use of the Declared Temporary Tables (DTTs) introduced in DB2 V6. When the cursor is opened, the result set is always copied to an internally defined DTT as shown in Figure 3-45. In order to use scrollable cursors on a DB2 subsystem, a TEMP database must be defined containing one or more segmented table spaces. During opening of the cursor, locks are taken as normal on the base table while rows are read and copied to the DTT. Once the open cursor processing is completed, there will be no page or row locks left on the base table unless you run with isolation RR or RS. After the open, the cursor is positioned just before the first row in the result set, the same as for a non-scrollable cursor. A FETCH INSENSITIVE will return the appropriate row from the DTT. A FETCH SENSITIVE will first refresh the row in the DTT from the base table in order to pick up any committed updates. In the future, SENSITIVE DYNAMIC scrollable cursors will not use a DTT, but will process the base table directly.

62

DB2 for z/OS and OS/390 Version 7 Performance Topics

DECLARE C1 INSENSITIVE SCROLL CURSOR FOR SELECT CUST_NO, CUST_NAME, CRED_LIM FROM CUST WHERE TOWN = 'LONDON'; ... OPEN C1; ... FETCH C1 INTO :WK-CNO, :WK-CNM, :WK-CRED;

Base Table DB2 Table

Result Table DB2 Declared Temp Table

SCROLL

Exclusive access by agent Fixed number of rows Accessed by many
Figure 3-45 Open scrollable cursor

Goes away at Close Cursor

Once the scrollable cursor is open, you can use the various positioning options of the FETCH statement to retrieve rows. The effect of the various FETCH options are summarized in Figure 3-46. A full description of the positioning options can be found in the DB2 UDB Server for OS/390 and z/OS Version 7 Presentation Guide, SG24-6121.

Chapter 3. SQL performance

63

...BEFORE... ...FIRST...

...ABSOLUTE 0... ...ABSOLUTE 1...

...ABSOLUTE 4... ...RELATIVE -3... ...PRIOR... ...RELATIVE -1... ...RELATIVE 0... ...RELATIVE 1...

FETCH...

CURRENT CURSOR POSITION

...CURRENT... ...NEXT...

...RELATIVE 3...

Result set

...LAST... ...AFTER...

...ABSOLUTE -1...

Figure 3-46 Fetch positioning options

3.7.2 Performance
Some limited tests were performed using the ORD table described previously in Figure 3-14, “Table and index definitions for correlated subquery examples” on page 39. The table contained 160 rows, two rows per page (MAXROWS 2 was specified) so that 80 pages contained rows. All tests were performed using V7 GA code and COBOL application programs. These figures are not from measurements in a fully controlled environment (DB2 was dedicated, not the hardware), but they are indicative of relative cost.

Non-scrollable versus scrollable cursor
First, a normal cursor and an INSENSITIVE SCROLL cursor were used as defined in Figure 3-47.

Non-scrollable cursor: EXEC SQL DECLARE C1 CURSOR FOR SELECT ORD_NO, VALUE(CUST_NO,0), ORD_DATE, VALUE(AMOUNT,0) FROM ORD ORDER BY ORD_NO END-EXEC.

Scrollable cursor: EXEC SQL DECLARE C1 INSENSITIVE SCROLL CURSOR FOR SELECT ORD_NO, VALUE(CUST_NO,0), ORD_DATE, VALUE(AMOUNT,0) FROM ORD ORDER BY ORD_NO END-EXEC.

Figure 3-47 Cursor definitions

64

DB2 for z/OS and OS/390 Version 7 Performance Topics

there were just two synchronous write I/Os and no read I/Os in the TEMP buffer pool. and the TEMP table spaces in the TEMP database were assigned to BP8.The access path chosen for both cursors was a table space scan followed by a sort for the ORDER BY. Table 3-17 Accounting Class 2 and Class 3 times Cursor type C2 elapsed C2 CPU C3 waits Normal Scroll 0. In the normal cursor case. there were six additional lock requests. These are DBD locks. The commit processing is necessary because Undo log records are created for DTTs to support rollback to a commit or a savepoint. and in the scroll cursor test. and so lock avoidance occurred on all data pages in both the normal and scroll cursor cases. the 4-KB work table spaces in DSNDB07 were assigned to BP7. With the non-scroll cursor. The Class 2 and Class 3 times (in seconds) are shown in Table 3-17. an S-Lock on the work table space used by the sort. There had been no recent updates to the ORD table. The BP8 getpages and updates reflect the activity on the temporary tables. The buffer pool for the TEMP database was also large enough to avoid read I/O. pageset locks and mass delete locks on the TEMP database and its table spaces. not the hardware) but they are indicative of relative cost. The table space containing the ORD table was assigned to BP1. SQL performance 65 . Table 3-18 Locking with scroll cursors Cursor type Lock requests Normal Scroll 4 10 With the scroll cursor. there were these locks: an S-Lock on the SKPT. and therefore there was no I/O to the table during any of the tests. A test was run using each cursor in which the cursor was opened and all rows were fetched in a forward direction. All packages were bound with ISOLATION(CS). there was no read or write I/O from any buffer pool.011378 0. These figures are not from measurements in a fully controlled environment (DB2 was dedicated.027238 0. and an S-Lock on the DBD for DSNDB07. The getpage and update counts for each bufferpool as shown by the accounting trace are shown in Table 3-16. Chapter 3.013660 0.012494 The Class 3 wait times shown for the Scroll cursor were made up of two waits for Write I/O and one wait service task at commit. The locking impact is shown in Table 3-18.010248 0. The buffer pool for the DSNDB07 table spaces was also large enough to avoid any I/O. an IS-Lock on the table space containing the ORD table.000000 0. Table 3-16 Scroll versus normal cursor Cursor type BP1 getpage BP7 getpage BP7 update BP8 getpage BP8 update Normal Scroll 83 83 8 8 6 6 0 7 0 165 The tests were run when the ORD table was entirely resident in the buffer pool.

The buffer pool activity is compared in Table 3-19 and the Accounting Class 2 and Class 3 times (in seconds) in Table 3-20.. VALUE(AMOUNT. EXEC SQL INSERT INTO SESSION.ORD_TEMP LIKE ORD ON COMMIT DELETE ROWS END-EXEC.0). The SQL statements to declare and populate the DTT are shown in Figure 3-48. Equivalent using a DTT: EXEC SQL DECLARE C1 CURSOR FOR SELECT ORD_NO. Figure 3-48 Using a DTT instead of a scrollable cursor Table 3-19 Scrollable cursor versus DTT bufferpool data Test BP0 getpage BP1 getpage BP7 getpage BP7 update BP8 getpage BP8 update Scroll DTT 0 54 83 83 8 8 6 6 7 295 165 415 Table 3-20 Scrollable cursor versus DTT Class 2 and 3 times Test C2 elapsed C2 CPU C3 waits Scroll DTT 0. ORD_DATE. Scrollable cursor: EXEC SQL DECLARE C1 INSENSITIVE SCROLL CURSOR FOR SELECT ORD_NO. This allows the V6 result set to be insensitive to later updates.013660 0..012494 0. EXEC SQL DECLARE GLOBAL TEMPORARY TABLE SESSION..Scrollable cursor versus Declared Temporary Table In order to compare the scrollable cursor to an equivalent capability in DB2 V6. VALUE(CUST_NO.ORD_TEMP SELECT * FROM ORD END-EXEC.160060 Table 3-21 Scrollable cursor versus DTT locking comparison Test Lock requests Scroll DTT 10 63 66 DB2 for z/OS and OS/390 Version 7 Performance Topics . the scrollable cursor test described above was compared to using a Declared Temporary Table (DTT) in the program and inserting rows by SQL before retrieving them. ISOLATION(CS) was used for all packages. VALUE(AMOUNT..ORD_TEMP ORDER BY ORD_NO END-EXEC.0) FROM ORD ORDER BY ORD_NO END-EXEC. .027238 0. The locking differences are shown in Table 3-21. ORD_DATE.196631 0.0) FROM SESSION. Again. . VALUE(CUST_NO.0). as is the case with an insensitive scrollable cursor.034427 0.

EXEC SQL DECLARE C1 CURSOR FOR SELECT ORD_NO. The idea was to simulate paging backwards in an on-line browser transaction. and extra processing in the DTT itself (BP8 getpages and updates). ORD_DATE.NNNN NNYN SELECT XOR2NO is an index on the ORD_NO column with CLUSTRRATIOF = 69. SQL performance 67 . It closed the cursor and reopened it with a new starting value. which contained 800 rows in 400 data pages in four partitions. VALUE(AMOUNT. and then resumed reading forwards again. by any measure.It can be seen that. VALUE(CUST_NO. The first version of the program used Version 6 techniques to back up. For this test the ORD_PART table was used. it backed up 10 rows. Cursor Stability was used in both cases. The cursor and its Explain output are shown in Figure 3-49. Explain QB PN MT TABLE 1 1 0 ORD_PART 1 2 3 AT MC INDEX I 1 XOR2NO 0 PF IXO PQ TT SORTN SORTC JT QBT L N 0 T NNNN NNNN SELECT N 0 -. On five occasions.0) FROM PAOLOR7.0% Figure 3-49 Repositioning without scrollable cursor The second version of the program used an insensitive scrollable cursor and repositioned using FETCH RELATIVE as shown in Figure 3-50. The extra costs of the DTT solution are in two areas: catalog accesses (BP0 getpages). Repositioning: close/reopen versus scrollable cursor Another test was performed to measure performance when repositioning.ORD_PART WHERE ORD_NO >= :START-ORD ORDER BY ORD_NO END-EXEC.0). the scrollable cursor performs better than the DTT equivalent code. Chapter 3. The batch test program read forward through the table in ascending ORD_NO order. The increased Class 3 wait times for the DTT tests were attributable mainly to an increase in the number of synchronous write I/Os for BP8 (from two to eleven) and the resulting increase in database I/O wait time and service task wait time.

The Class 2 and 3 times are in seconds.053857 -15% 0...033327 It can be seen that in our test the scrollable cursor performed significantly better than the close and re-open approach.096643 -37% 0. The benefits will be most apparent where a DB2 sort is invoked for the close and re-open. :AMOUNT END-EXEC Explain QB 1 1 PN 1 2 MT 0 3 TABLE ORD_PART AT R MC 0 0 INDEX PF S IXO N N PQ TT 0 T 0 -SORTN SORTC JT QBT NNNN NNNN SELECT NNNN NNYN SELECT Figure 3-50 Repositioning with scrollable cursor The figures from the two tests are shown in Table 3-22 and Table 3-23. The performance benefits of a scrollable cursor over repositioning with a non-scrollable cursor are likely to increase with the size of the cursor result set and with the number of repositioning operations performed. ORD_DATE.ORD_PART ORDER BY ORD_NO END-EXEC. Repositioning: EXEC SQL FETCH RELATIVE -11 C1 INTO :ORD-NO. Table 3-22 Buffer pool activity for repositioning tests Test BP1 getpage BP2 getpage BP7 getpage BP7 update BP8 getpage BP8 update Close/open Scroll relative 1124 404 15 0 49 18 50 16 0 27 0 819 Table 3-23 Class 2 and Class 3 times for repositioning test Test C2 elapsed C2 CPU C3 waits Close/open Scroll relative Delta 0. :CUST-NO. The index XOR2NO was in BP2.EXEC SQL DECLARE C1 INSENSITIVE SCROLL CURSOR FOR SELECT ORD_NO.152763 0.063726 0.0) FROM PAOLOR7. . VALUE(AMOUNT. VALUE(CUST_NO. :ORD-DATE :DATE-I.0).000006 0. 68 DB2 for z/OS and OS/390 Version 7 Performance Topics .

023866 0. There are 160 rows in the result set and therefore the test programs issued 160 FETCH statements to read them. The cost overheads are very reasonable for the additional functionality. 3. It also costs more to use a sensitive cursor than an insensitive cursor. The getpage and update counts for each bufferpool from the accounting trace are shown in Table 3-24. at least if you use FETCH SENSITIVE. You wish to freeze the result set so that it is not changed by any updates made outside the cursor. so only use them when you need the extra functionality.010623 0. You might choose to use an insensitive scrollable cursor for any of the following reasons: You need to position in the result set other than to the next row in a forward direction. Table 3-25 Class 2 and 3 times for insensitive versus sensitive cursor Cursor type C2 elapsed C2 CPU C3 waits Insensitive Cursor Sensitive cursor and insensitive fetch Sensitive cursor and sensitive fetch 0.Insensitive versus sensitive cursor A third test was run to compare an insensitive to a sensitive static cursor. SQL performance 69 . The number of lock requests in all three cases was 10. as full lock avoidance took place both on the initial access to the base table and on the re-references for the sensitive fetch. In each case the cursor was opened and all rows were fetched in a forward direction.3 Conclusions In general. resulting in 160 extra getpages.027238 0.013660 0.012189 0. This extra work was reflected in the Class 2 and 3 times as shown in Table 3-25.012494 0. Chapter 3.7. it costs more to use a scrollable cursor than a non-scrollable cursor. Table 3-24 Buffer pool activity for insensitive versus sensitive cursor Cursor type BP1 getpage BP7 getpage BP7 update BP8 getpage BP8 update Insensitive cursor Sensitive cursor and insensitive fetch Sensitive cursor and sensitive fetch 83 83 8 8 6 6 7 9 165 167 243 8 6 9 167 The increase in BP1 getpages when a FETCH SENSITIVE is used is due to the need to re-reference the row in the base table for each fetch in order to pick up any updates.4 Recommendations There are costs associated with using scrollable cursors.7.014327 0. trying to draw conclusions from small differences.026508 0.011523 3.

OPEN the cursor. Figure 3-51 Existence checking SQL If we coded this existence check as static SQL in a COBOL program. we would have to DECLARE a cursor. Both use a tablespace scan to access the table. 70 DB2 for z/OS and OS/390 Version 7 Performance Topics .3. For dynamic SQL. “FETCH FIRST n ROWS” on page 152 for a full description. See 7. when no supporting programming language. As we have seen. An insensitive scrollable cursor always guarantees that the result set is frozen at cursor open time. DB2 no longer chooses sequential prefetch. If we code it as a singleton SELECT. there is significant cost resynchronizing with the base table at each FETCH.1 Description There are many possible solutions to the problem of existence checking (checking whether any row satisfies a specified condition). The FETCHes then retrieve the rows from the Logical Work File (in a work table space in DSNDB07). 3. However.1. the access path can change to one that does not include a sort if a new index is created or if another access path is chosen on rebind. Figure 3-52 shows the effect of adding FETCH FIRST 1 ROW ONLY on the access path.1. The problem with this SQL is that it may return more than one row and we only need one row to tell us whether or not there are any rows that meet the criteria AMOUNT > 1000. “Singleton select” on page 155 for more details on the comparison. Existence checking: Are there any ORD rows with AMOUNT > 1000? SELECT 1 FROM ORD WHERE AMOUNT > 1000. such as COBOL.8 Fetch first n rows This enhancement is primarily a network computing enhancement. is available. to satisfy an ORDER BY.8. Handling the possible existence of multiple rows in the result set creates unnecessary performance overhead. Both statements were Explained under V7. then we will get an SQLCODE -811 at execution time if more than one row satisfies the predicate. one approach that is used is to use a SELECT statement like that shown in Figure 3-51. In DB2 V7 you can use FETCH FIRST 1 ROW ONLY both to avoid the performance overhead for dynamic SQL and to avoid the -811 SQLCODE for static SQL. See also 7. and FETCH the first row. but when the FETCH FIRST 1 ROW ONLY is added. In this section we describe a special case in which the use of the FETCH FIRST n ROWS ONLY clause can improve performance for local SQL. for example. 3. Only use a sensitive scrollable cursor if you really need to pick up updates and deletes made outside the cursor.The second objective can be met by a non-scrollable cursor if the DB2 access path for a cursor invokes the DB2 Sort.

returning a single row if there are any matching rows and returning SQLCODE +100 if there are no matching rows.2 Performance The SELECT statements shown in Figure 3-52 were executed through SPUFI and an SQL Trace used to see how many rows were processed by the tablespace scan in each case. 32 to return the rows and the last receiving SQLCODE +100. 3. only one row was processed and two FETCHes were executed. Without the FETCH FIRST.8. the second receiving SQLCODE +100. With FETCH FIRST 1 ROW ONLY added to the SELECT. Figure 3-53 shows extracts from the SQL traces for both statements. QB 1 PN 1 MT 0 TABLE ORD AT R MC 0 INDEX PF S IXO N PQ 0 TT T SORTN NNNN SORTC NNNN SELECT 1 FROM ORD WHERE AMOUNT > 1000 FETCH FIRST 1 ROW ONLY. 32 rows were returned and 33 FETCHes executed. SQL performance 71 .SELECT 1 FROM ORD WHERE AMOUNT > 1000. In these tests the getpage count for the tablespace was reduced from 83 to 2 by adding the FETCH FIRST 1 ROW ONLY clause. Chapter 3. QB 1 PN 1 MT 0 TABLE ORD AT R MC 0 INDEX PF IXO N PQ 0 TT T SORTN NNNN SORTC NNNN Figure 3-52 FETCH FIRST effect on access path If we code a singleton SELECT as follows: SELECT 1 INTO :WK-NUM FROM ORD WHERE AMOUNT > 1000 FETCH FIRST 1 ROW ONLY Then the statement will execute without error.

000100 STMT# 0.000102 0.---------RI-------DATABASE PAGESET SCANS PROCESS EXAMINE STAGE 1 STAGE 2 INSERTS UPDATES DELETES DELETES SCANNED SCANS DELETES MEMBER TYPE DB246129 TS612902 1 4 4 1 1 0 0 0 1 2 0 0 N/P SEQD 16:39:57. 3.WORKLOAD HILITE ---------------------------------------------------------------------------------------------------------SCANS : 1 RECS/SORT: N/P I/O REQS: N/P SUSPENDS : N/P EXITS : N/P AMS : N/P ROWSPROC: 160 WORK/SORT: N/P AET/I/O : N/P AET/SUSP : N/P AET/EXIT : N/P AET/AMS : N/P PAGESCAN: 83 PASS/SORT: N/P DATACAPT: N/P RIDS UNUSED: N/P CHECKCON : N/P DEGREE REDUCTION : N/P LOB_PAGSCAN: 0 LOB_UPD_PAGE : 0 --. then DB2 performs a non-matching index scan (ACCESSTYPE = I. 3.000136 STMT# 183 CURSOR: C1 SQLSTATE: 00000 SQLCODE: 0 --.54 16:39:57.54 0.SQL Trace without FETCH FIRST OPEN 16:31:24.000045 0.8. On the other hand.000045 STMT# 0. if a SELECT MAX(col) is coded in DB2 V6.----------ROWS----------.4 Recommendations Use for existence checking where appropriate to improve performance or to simplify code in an application program. 3.65 0.66 0.000012 STMT# 190 CURSOR: C1 ISO(CS) SQLSTATE: 00000 SQLCODE: REOPTIMIZED(NO) KEEP UPDATE LOCKS: NO 0 FETCH 16:39:57.----------ROWS----------.000012 0. 72 DB2 for z/OS and OS/390 Version 7 Performance Topics .SCAN ACTIVITY -----------------------------------------------------------------------------------------------------------------ROWS-----.000054 STMT# 183 CURSOR: C1 183 CURSOR: C1 SQLSTATE: 00000 SQLCODE: SQLSTATE: 00000 SQLCODE: 0 0 FETCH FETCH . MATCHCOLS = 0) to locate the MAX value.. it can be used as an efficient existence check by avoiding the limitation of a singleton select and reducing the overhead of handling cursors with multiple rows.SCAN ACTIVITY -----------------------------------------------------------------------------------------------------------------ROWS-----.000012 0.000056 0.--QUALIFIED AT-.9 MIN/MAX enhancement DB2 V7 provides more efficient use of indexes for evaluation MIN and MAX functions.53 0. The index XCUSTNO is an ascending index on the column CUST_NO.--PAGES.65 0. only an ascending index.--PAGES.3 Conclusions In a non-client/server environment. and if there is no descending index on col. However.000138 0.000012 STMT# 190 CURSOR: C1 ISO(CS) SQLSTATE: 00000 SQLCODE: REOPTIMIZED(NO) KEEP UPDATE LOCKS: NO 0 FETCH 16:31:24. then DB2 can use a one-fetch index access (ACCESSTYPE = I1) to retrieve the MIN value.000139 0.WORKLOAD HILITE ---------------------------------------------------------------------------------------------------------SCANS : 1 RECS/SORT: N/P I/O REQS: N/P SUSPENDS : N/P EXITS : N/P AMS : N/P ROWSPROC: 4 WORK/SORT: N/P AET/I/O : N/P AET/SUSP : N/P AET/EXIT : N/P AET/AMS : N/P PAGESCAN: 2 PASS/SORT: N/P DATACAPT: N/P RIDS UNUSED: N/P CHECKCON : N/P DEGREE REDUCTION : N/P LOB_PAGSCAN: 0 LOB_UPD_PAGE : 0 --.8.--MASS.1 Description When a SELECT MIN(col) is coded and there is an ascending index on col.54 0.000012 STMT# 183 CURSOR: C1 197 CURSOR: C1 SQLSTATE: 02000 SQLCODE: SQLSTATE: 00000 SQLCODE: 100 0 FETCH CLOSE Figure 3-53 FETCH FIRST SQL traces 3.--MASS.. SQL Trace with FETCH FIRST OPEN 16:39:57.66 16:31:24. the use of FETCH FIRST n ROWS is probably limited.9.---------RI-------DATABASE PAGESET SCANS PROCESS EXAMINE STAGE 1 STAGE 2 INSERTS UPDATES DELETES DELETES SCANNED SCANS DELETES MEMBER TYPE DB246129 TS612902 1 160 160 32 32 0 0 0 1 83 0 0 N/P SEQD 16:31:24.--QUALIFIED AT-.000138 STMT# 183 CURSOR: C1 SQLSTATE: 00000 SQLCODE: 0 --.000012 0. Two examples of this are shown in Figure 3-54.

Version 6 and Version 7 Explain: QB 1 PN 1 MT 0 TABLE CUST AT I1 MC 1 INDEX XCUSTNO PF IXO Y SORTN NNNN SORTC NNNN JT QBT SELECT Figure 3-54 Existing MIN function access In V7.SELECT MIN(CUST_NO) FROM CUST. SQL performance 73 . Similarly. as shown in Figure 3-55. DB2 can use a new facility to read an index backwards. Version 6 Explain: QB 1 PN 1 MT 0 TABLE CUST AT I MC 0 INDEX XCUSTNO PF IXO Y SORTN NNNN SORTC NNNN JT QBT SELECT Version 7 Explain: QB 1 PN 1 MT 0 TABLE CUST AT I1 MC 0 INDEX XCUSTNO PF IXO Y SORTN NNNN SORTC NNNN JT QBT SELECT SELECT MAX(CUST_NO) FROM CUST WHERE CUST_NO < 1000. Version 6 and Version 7 Explain: QB 1 PN 1 MT 0 TABLE CUST AT I1 MC 0 INDEX XCUSTNO PF IXO Y SORTN NNNN SORTC NNNN JT QBT SELECT XCUSTNO is an ascending index on the column CUST_NO SELECT MIN(CUST_NO) FROM CUST WHERE CUST_NO > 10. DB2 can use a one-fetch index access on a descending index to evaluate a MIN function. SELECT MAX(CUST_NO) FROM CUST. Version 6 Explain: QB 1 PN 1 MT 0 TABLE CUST AT I MC 1 INDEX XCUSTNO PF IXO Y SORTN NNNN SORTC NNNN JT QBT SELECT Version 7 Explain: QB 1 PN 1 MT 0 TABLE CUST AT I1 MC 1 INDEX XCUSTNO PF IXO Y SORTN NNNN SORTC NNNN JT QBT SELECT Figure 3-55 MAX function access Chapter 3. It can now use a one-fetch index access on an ascending index to evaluate a MAX function.

2 Performance The first MAX function shown in Figure 3-55 was tested. DESC will not use an ascending index to avoid the sort.001387 -86.006577 -82. 3.037438 0. The test probably represent the least performance benefit in percentage terms that is likely to be achieved by the improved access path. or SELECT MIN(col) statements if there is an descending index on col. but the OS/390 LPAR was not dedicated. They may benefit from the improved access path. Review whether any indexes created to support MAX or MIN processing can be dropped.. The Class 2 times are in seconds. The Explain output was as shown.3 Conclusions It is no longer necessary to create a descending index to support a MAX function where an ascending index already exists.9. The results of the test on V6 and V7 are shown in Table 3-26. It may be possible to drop some indexes that were created explicitly for the purpose of supporting the MAX (or MIN) function. As a result.010332 0. 74 DB2 for z/OS and OS/390 Version 7 Performance Topics .This ability to read an index backwards is limited.4% 0.6% 3 2 -33. 3.10 Fewer sorts with ORDER BY In V7. With a larger index the performance improvements should be greater. For example. for the present. The ascending index XCUSTNO was assigned to BP2 and was very small: 2 leaf pages and one root page. A SELECT statement with an ORDER BY.9. the following statement results in a table space scan followed by a sort when only an ascending index on CUST_NO is defined on the CUST table: SELECT * FROM CUST ORDER BY CUST_NO DESC. to this special case of evaluating a MAX (or MIN) function. DB2 can make better use of indexes to provide ordering of result sets. This can result in fewer sorts for queries that contain an ORDER BY clause.. The tests were run in an environment where the DB2 subsystem was dedicated to the tests.9. Table 3-26 MAX test results Class 2 elapsed Class 2 CPU BP2 getpages V6 V7 Delta 0. elapsed and CPU times produced by the tests could are only indicative of comparison.3% The test was run with all index pages in the buffer pool (BP2) and there was no Class 3 wait time. 3. 3.4 Recommendations Consider rebinding packages containing SELECT MAX(col) statements if there is an ascending index on col.

CREATE INDEX XCNTC ON CUST (CUST_NAME. DB2 can still avoid the sort. SQL performance 75 . It therefore recognizes that the index can satisfy the ORDER BY clause and no sort is required. It does not matter where in the ORDER BY column list or the index column order the predicate column comes. SELECT * FROM CUST WHERE TOWN = 'MANCHESTER' ORDER BY TOWN. CUST_NAME.3.10. In our example. An example is shown in Figure 3-56. CRED_LIM). DB2 treats the query as though it specified ORDER BY CUST_NAME.1 Description When the WHERE clause contains an equal predicate on a column. CRED_LIM. CRED_LIM Chapter 3. the column TOWN can be ignored in both the ORDER BY clause and the index definition. TOWN ORDER BY CUST_NAME. CUST_NAME. CRED_LIM . then that same column in the index can also be ignored. CRED_LIM. We have created an extra index on the CUST table. and that predicate is a Boolean term (the entire WHERE clause is false if the predicate is false). CRED_LIM) USING STOGROUP SG246129 PRIQTY 120 SECQTY 12 BUFFERPOOL BP2 . TOWN. It is. CRED_LIM . It also treats the index XCNTC as though it were defined on the columns (CUST_NAME. When DB2 evaluates the capability of an index to provide ordering. of course. with key columns CUST_NAME. TOWN. necessary that the remaining columns in the ORDER BY are in the same order as the remaining columns in the index definition. all the following ORDER BY clauses could also be satisfied by the index XCNTC: ORDER BY CUST_NAME. Because of the predicate TOWN = value in each of the queries shown. Version 6 Explain: QB 1 1 PN 1 2 MT TABLE 0 CUST 3 AT MC I 1 0 INDEX XCTOWN PF L IXO N N SORTN NNNN NNNN SORTC JT NNNN NNYN QBT SELECT SELECT Version 7 Explain: QB 1 PN 1 MT TABLE 0 CUST AT MC I 0 INDEX XCNTC PF IXO N SORTN NNNN SORTC JT NNNN QBT SELECT Figure 3-56 ORDER BY sort avoidance DB2 V6 uses a matching index scan on the index XCTOWN (an index on the column TOWN) and then sorts the result to get the correct sequence for the ORDER BY. and CRED_LIM. CRED_LIM ORDER BY CUST_NAME. then that column can be ignored in the ORDER BY clause because it will have no effect on the ordering of the result set. TOWN. DB2 V7 uses a non-matching index scan on the index XCNTC to both evaluate the WHERE clause (by index screening) and to ensure the correct sequence for the ORDER BY. or SELECT * FROM CUST WHERE TOWN = :WK-TOWN ORDER BY TOWN.

017487 0. SELECT * FROM CUST C INNER JOIN ORD O ON C. This time it is a join of two tables and once again a sort for the ORDER BY is avoided.4% 0.10. It will only eliminate a sort if that produces a lower cost access path. The ORD column AMOUNT is in the ORDER BY.2 Performance These figures are not from measurements in a fully controlled environment (DB2 was dedicated. but not in the index. 3.8% 9 3 4 0 4 2 76 DB2 for z/OS and OS/390 Version 7 Performance Topics . A sort is still required if the ORDER BY applies to the result of a UNION.001658 -92. It can also be ignored because of the equal predicate on AMOUNT. The CUST column TOWN is in the index XCNTC but not in the ORDER BY. the CUST index XCNTC is used to establish the correct order for the result rows via a non-matching index scan. not the hardware) but they are indicative of relative cost. Version 6 Explain: QB 1 1 1 PN 1 2 3 MT 0 4 3 TABLE ORD CUST AT R I MC 0 1 0 INDEX XCUSTNO PF S L IXO N N N SORTN NNNN NNNN NNNN SORTC NNNN NYNN NNYN JT QBT SELECT SELECT SELECT Version 7 Explain: QB 1 1 PN 1 2 MT 0 1 TABLE CUST ORD AT I I MC 0 1 INDEX XCNTC XOCNO PF IXO N N SORTN NNNN NNNN SORTC NNNN NNNN JT QBT SELECT SELECT Figure 3-57 Sort avoidance in a join DB2 will not always eliminate sorts for ORDER BY in the situations discussed above. updates and lock requests shown for V6 are due to the use of a work table space in DSNDB07 by the DB2 sort. The results are shown in Table 3-27. It can be ignored because of the equal predicate on TOWN. The query shown in Figure 3-56 on page 75 was run against a CUST table containing 10 rows.018109 0. just as it does in the index.TOWN = 'MANCHESTER' ORDER BY AMOUNT.001330 -90. CRED_LIM.The only constraint is that CUST_NAME must come before CRED_LIM in the ORDER BY.CUST_NO WHERE O.CUST_NO = O. Figure 3-57 shows another example. The extra getpages.AMOUNT = 1000 AND C. The ORD rows are then joined using a nested loop join. Table 3-27 ORDER BY test results C2 elapsed C2 CPU Total getpages Total BP updates Lock requests V6 V7 Delta 0. Therefore. in V7. CUST_NAME.

CUST_NO = O. We have created a copy of the ORD table. 3. Elapsed and CPU times will be reduced for queries that benefit from this enhancement.2). TOWN CHAR(20).0) = O. CUST_NAME CHAR(20). XCUSTNO is an index on CUST(CUST_NO). 3.10.0).3.11 Joining on columns of different data types DB2 V6 (and V5 with APARs PQ22046 and PQ24933) allowed a join predicate to be Stage 1 and potentially Indexable even if there was a mismatch on data type or length.CUST_NO) SELECT * FROM CUST C INNER JOIN ORD_DEC O ON DECIMAL(C. ORD_DATE DATE. They will contain SQL with ORDER BY clauses that could be satisfied by composite indexes in the way described above. In order for this to be true you must. DB2 V7 allows a join predicate to be Stage 1 and potentially Indexable when there is a data type or length mismatch for numeric columns. The CUST table is the same definition as we have seen before. SQL performance 77 . CRED_LIM DEC(7. PRIMARY KEY (ORD_NO)) SELECT * FROM CUST C INNER JOIN ORD_DEC O ON C. 3.1 Description In Figure 3-58 we look at some examples.11.4 Recommendations Consider rebinding packages that might benefit from this enhancement. SELECT * FROM CUST C INNER JOIN ORD_DEC O ON C.CUST_NO. CUST_NO DECIMAL(15.CUST_NO Table CUST: CUST_NO INTEGER NOT NULL.0) instead of INTEGER. called ORD_DEC.2).10. Index XOCND is an index on ORD_DEC(CUST_NO).15. AMOUNT DECIMAL(7. in your SQL. in which the only difference is the definition of the CUST_NO column which is DECIMAL(15. cast one column to the data type of the other.3 Conclusions Avoiding a sort is always good news. This enhancement was limited to string data types only. PRIMARY KEY (CUST_NO) Table ORD_DEC: CREATE TABLE ORD_DEC (ORD_NO INTEGER NOT NULL.CUST_NO QB 1 1 PN 1 2 MT 0 1 TABLE CUST ORD_DEC AT R R MC 0 0 INDEX PF S S IXO N N PQ 0 0 TT T T SORTN NNNN NNNN SORTC NNNN NNNN JT CFE QBT SELECT SELECT QB 1 1 PN 1 2 MT 0 1 TABLE ORD_DEC CUST AT R I MC 0 1 INDEX XCUSTNO PF S IXO N N PQ 0 0 TT T T SORTN NNNN NNNN SORTC NNNN NNNN JT CFE QBT SELECT SELECT QB 1 1 PN 1 2 MT 0 1 TABLE CUST ORD_DEC AT R I MC 0 1 INDEX XOCND PF S L IXO N N PQ 0 0 TT T T SORTN NNNN NNNN SORTC NNNN NNNN JT CFE QBT SELECT SELECT Figure 3-58 Join column mismatch Explains Chapter 3.CUST_NO = INTEGER(O.

This predicate is Stage 2: ON C.15. If we create a table ORD_SMINT.1) = O. The following join predicate. we still see the same effect. DB2 has changed the order of table access. The first example does not use a cast function and therefore the data type mismatch makes the join predicate Stage 2. When we cast the CUST column to the ORD_DEC column data type DB2 can use the index on the ORD_DEC column but not the index on the CUST column. then we see the following.CUST_NO = INTEGER(O. with a different scale. In our example. In all three examples a nested loop join is performed for the inner join of the CUST and ORD_DEC tables.CUST_NO) = O.12. In the second example we have cast the ORD_DEC column CUST_NO in the join predicate to match the data type (INTEGER) of the CUST table CUST_NO column. When we cast the ORD_DEC column to the CUST column data type DB2 can use the index on the CUST column but not the index on the ORD_DEC column.CUST_NO = CAST(O. In the third example we have cast the CUST column CUST_NO in the join predicate to match the data type (DECIMAL(15. the same as ORD except that the CUST_NO column is defined as SMALLINT instead of INTEGER. DB2 uses a tablespace scan for the inner table (ORD_DEC) access despite the existence of an index on the ORD_DEC join column.0)) of the ORD_DEC table CUST_NO column.CUST_NO This predicate is Stage 1 and Indexable: ON C. Now the CUST table is the inner table of the join and the index XCUSTNO on CUST(CUST_NO) is used to access the CUST table. will use the index on ORD_DEC(CUST_NO): ON DECIMAL(C. but if we make the scale different then the predicate remains Stage 2.CUST_NO = O.CUST_NO. the next example. So. If we use the alternative syntax to cast a column to the data type of the other column.0)) = O. we can make the precision different from the matching column without loosing the Stage 1 benefit.Let us look at Figure 3-58 and see what it tells us.CUST_NO 78 DB2 for z/OS and OS/390 Version 7 Performance Topics . uses a tablespace scan: ON DECIMAL(C.CUST_NO However.0).CUST_NO AS DECIMAL(15. with a different precision in the cast.CUST_NO AS INTEGER) In the third example we get the same Explain output if we specify the join predicate as: ON CAST(C. in the second example we get the same Explain output as shown in Figure 3-58 if we specify the join predicate as: ON C. DB2 has made ORD_DEC the inner table and used the index XOCND on ORD_DEC(CUST_NO) to access the ORD_DEC table.0) = O. if O is the correlation name of the ORD_SMINT table.CUST_NO If we cast to a decimal data type. We can see from these examples that it makes a difference which side of the join predicate we apply the cast function to.CUST_NO The same need to cast exists if the join columns are INTEGER and SMALLINT respectively.CUST_NO) This predicate is Stage 1 and Indexable: ON SMALLINT(C.CUST_NO. the CUST_NO column in ORD_DEC is defined as DECIMAL(15.

CUST_NAME VARCHAR(20).2 Performance The three joins shown in Figure 3-58 on page 77 were tested. Let us also create an index on those columns and one other: CREATE TABLE CUST_VAR (CUST_NO INTEGER NOT NULL. It is more likely that joins with column mismatches will be found in Data Warehousing systems and similar systems where data is gathered from diverse sources. Table 3-28 Join column mismatch test results Test C2 elapsed C2 CPU BP1 getpages BP2 getpages No cast Cast Dec to Int Cast Int to Dec 0. Both of the queries which cast one join column to the data type of the other performed much better than the query without the cast. not the hardware) but they are indicative of relative cost. called CUST_VAR. you need to decide which index will give the best performance in the join.293461 0.2)) CREATE INDEX XVTNC ON PAOLOR7. These figures are not from measurements in a fully controlled environment (DB2 was dedicated. It will be necessary to recode joins to include the casting function in order to get the performance benefits. It is less likely that joins with mismatched columns will be found in systems where the database has been designed from scratch to meet the requirements of specific applications. In V6 it is necessary to set RETVLCFK=YES in order for it to be possible to get index-only access when a VARCHAR column that is an index key column is referenced either in the select list or in the WHERE clause.018263 13.CUST_VAR (TOWN.014593 0. SQL performance 79 .12 VARCHAR index-only access DB2 V6 (and V5 via APAR PQ10465) introduced the DSNZPARM RETVLCFK. showing reductions of more than 90% in elapsed and CPU time. Chapter 3. You need to know what indexes are available on each of the columns and.363 107 163 0 2 161 3.249546 0. It is important to choose the correct join column to cast to the data type of the other.3. CUST_NAME. if both columns are indexed.4 Recommendations It will be worth identifying joins that can take advantage of this enhancement and recoding them. 3. CRED_LIM) . This parameter controls the ability of the Optimizer to use of Index-Only access when processing VARCHAR columns that are part of an index.015480 0..11.11. CRED_LIM DEC(7. TOWN VARCHAR(20). Let us use a variant of our CUST table. 3.. in which the two CHAR columns are defined as VARCHAR.3 Conclusions This enhancement solves most of the problems of joining on columns with different declarations.021187 0. The results are shown in Table 3-28.11.

CUST_N AME FROM CUST_VAR WHERE TOWN = 'MAN CHESTER'. as before. SELECT CUST_NAME FROM CUST_VAR WHERE TOWN = 'MANCHESTER'. a VARCHAR column from the index XVTNC is specified in the WHERE clause and another VARCHAR column from the same index is specified in the select list. V6 and V7 Explain with RETVLCFK=YES QB 1 PN 1 MT 0 TABLE CUST_VAR AT I MC 1 INDEX XVTNC PF L IXO Y SORTN NNNN SORTC NNNN V6 Explain with RETVLCFK=NO QB 1 PN 1 MT 0 TABLE CUST_VAR AT I MC 1 INDEX XVTNC PF L IXO N SORTN NNNN SORTC NNNN V7 Explain with RETVLCFK=NO QB 1 PN 1 MT 0 TABLE CUST_VAR AT I MC 1 INDEX XVTNC PF IXO Y SORTN NNNN SORTC NNNN Figure 3-60 Index-only access when VARCHAR in WHERE clause only 80 DB2 for z/OS and OS/390 Version 7 Performance Topics . The RETVLCFK parameter still works the same way in V7. In both cases. The VARCHAR column TOWN is specified in the WHERE clause. but the only column in the select list is the DECIMAL column CRED_LIM.If we look at Figure 3-59 we can see the effect of the RETVLCFK parameter.1 Description The enhancement in V7 concerns the case when a VARCHAR index key column is specified in the WHERE clause. Because there is no data access. to an index-only access. In each of the two SQL statements shown in the figure. SELECT TOWN. but only non-VARCHAR columns from the index are specified in the select list. We can see such a case in Figure 3-60.12. V 6 a n d V 7 E x p la in w it h R E T V L C F K = N O QB 1 PN 1 MT 0 TABLE CUST_VAR AT I MC 1 INDEX XVTNC PF L IXO N SORTN NNNN SORTC NNNN V 6 a n d V 7 E x p la in w it h R E T V L C F K = Y E S QB 1 PN 1 MT 0 TABLE CUST_VAR AT I MC 1 INDEX XVTNC PF IXO Y SORTN NNNN SORTC NNNN Figure 3-59 Effect of the RETVLCFK parameter 3. the List Prefetch also disappears from the Explain output. which is also part of the index XVTNC. SELECT CRED_LIM FROM CUST_VAR WHERE TOWN = 'MANCHESTER'. changing the parameter from NO to YES has allowed the Optimizer to change from a matching index scan with data access.

there is now slightly less reason for doing so. The two-pass approach consumes much less RDS subpool storage than V6 for these multi-table joins. 3. These figures are not from measurements in a fully controlled environment (DB2 was dedicated. Chapter 3. you could only get an index-only access in this case by specifying RETVLCFK=YES. not the hardware) but they are indicative of relative cost.13. In V7.1 Description The DB2 V7 Optimizer uses a new two-pass approach for analyzing possible access paths whenever inner joins of more than 9 tables are processed without any outer joins. If you have VARCHAR columns in indexes consider rebinding those packages that may be able to exploit the index-only access. The tablespace was allocated to BP1 and the index to BP2. Many sites do not want to set the parameter to YES because it impacts every application program that includes in its select list a VARCHAR column that is an index key column. CPU cost is also reduced in V7 by using a more efficient search to locate cost entries.2 Performance The SQL shown in Figure 3-60 on page 80 was tested in V6 and V7 with RETVLCFK=NO. you do not need to set RETVLCFK=YES to get index-only access in this special case.12.3 Conclusions This enhancement can be of benefit for installations that have VARCHAR columns in indexes. The resulting getpage counts for the two tests are shown in Table 3-29. 3. V7 provides index-only access for VARCHARs in the WHERE clause but not in the select list regardless of the setting of the parameter. 3. Table 3-29 VARCHAR index-only test results Test BP1 getpages BP2 getpages V6 V7 16 0 2 2 3.In DB2 V6.13 Bind improvements Improvements to the DB2 V7 Optimizer processing result in significantly reduced storage requirements in the DBM1 address space and also reduced CPU use during the BIND command execution when performing access path selection for an SQL statement that joins more than 9 tables. Not all programs can handle this access path dependent variation in how data is returned from a SELECT. 3.12.4 Recommendations For those installations that avoid the use of VARCHAR columns in indexes. If an index-only access is chosen by DB2.12. In V7 we have avoided the 16 data getpages that were required in V6. SQL performance 81 . It also reduces CPU cost. This enhancement is also extended to outer joins by APAR PQ48306. then the VARCHAR values are returned to the application program padded with blanks and with the column length set to the maximum. As can be seen in the example. When the VARCHAR is returned from the data row it is returned as a true variable length value without padding.

When you want to specify a value deviating from default. with two different BI and CRM workloads. the default value for the parameter is DISABLE. the parameter that enables or disables this feature is changed from a hidden to an externalized keyword.2 Performance Measurements were performed on inner joins first without PQ48306.3.13. 3.4 Recommendations If you expect to benefit from this enhancement. make sure that APAR 48306 is applied to extend the benefits to outer joins as well as inner joins. 82 DB2 for z/OS and OS/390 Version 7 Performance Topics . In DB2 DB2 V7. after applying the fix for PQ48306. For larger number of tables. SG24-6108.13. Star join support for DB2 V6 was delivered by the fixes to APARs PQ28813 and PQ36206. These showed comparable storage use for V7 and V6 for joins of up to 9 tables. These sites tend to use dynamic SQL and perform joins of large numbers of tables. you must manually add the keyword STARJOIN to the invocation of the DSN6SPRM macro in the job DSNTIJUZ which assembles and link edits the DSNZPARM subsystem parameter load module. 3. A star join consists of several (dimension) tables being joined to a single central (fact) table using the table design pattern known as a star schema. Acceptable values are ENABLE. This is known as the star join performance enhancement because it is oriented to improve star join performance. CPU reduction is only applicable for complex joins of 10 or more tables. See Figure 3-61 for a description. simple queries showed a reduction of up to 20% in storage use and very complex queries showed a reduction of 69% for a 15-table join and 73% for a 19-table join. has shown large virtual storage reductions for outer joins (up to 25 times) as well as further reductions (up to 2 times) with the inner joins. For a more detailed description of star join see DB2 UDB Server for OS/390 Version 6 Technical Update. The parameter cannot be set through the install panels. For such sites. The tests showed a CPU reduction of 19% for a 15-table join and 70% for a 19-table join. The improvement also applies to joins of tables using the snowflake schema design which involves one or more extra levels of dimension tables around the first level of dimension tables.3 Conclusions This enhancement and the follow-up APAR are of great interest for DB2 environments running complex BI and CRM type applications. whereas it was ENABLE in V6.13.14 Star join A new way of processing multiple-table joins was added as an option to DB2 V6. it is now possible to avoid failures on PREPARE caused by insufficient storage and reach large performance improvements in CPU time for inner and outer joins. 3. Tests of more than 15 tables were conducted by setting the hidden parameter &SPRMMXT=’20’. Also. Another set of measurements. DISABLE or 1-32768.

using the next key feedback feature With this implementation. Star join enhancement in V6 and V7 The enhancement to the star join in DB2 V6 and V7 through APARs PQ43846 and PQ47833 respectively is intended: To improve the average performance of star joins. potential performance degradation can be prevented for relatively small OLTP type queries that are qualified as the star schema. 2-32 76 8 = Thi s i s t he sta r j oin fa ct tab le to lar ges t d ime nsi on tab le rat io. if possible. (1. Figure 3-61 Star join example 3. Chapter 3. 2001.14. No fac t/d ime nsi on rat io che cki ng is don e. Star join was introduced in DB2 V6 in order to process queries qualified as the star schema Bind the queries using a greedy algorithm based on heuristics to generate the join sequence Skip scanning the dimension tables. SQL performance 83 . The new enhancement is designed to compensate this situation and consists of the following features: Queries with star schema are optimized despite the number of tables in the query block.1 Recent star join enhancement A star join enhancement has been introduced by the recent APAR PQ43846 for V6. The execution time has also been largely cut for some queries with star schema. The V7 forward fit is PQ47833 and its PTF will be available around the end of June.STAR JOIN Acceptable values: DISABLE. a star schema query that contains large number of dimension tables is able to be bound without SQL code -101 or -129. However. With this new threshold. ENABLE. 2-32768) Default : DISABLE DSNZPxxx : DSN6SPRM STARJOIN DISA BL E = No sta r j oin ENAB LE = Ena ble st ar joi n . Star join is disabled for a query block having less than 10 tables (see the note below) even if star join is enabled by the ZPARM.DB 2 w ill op tim ize fo r s tar jo in 1 = The fa ct tab le wil l b e t he lar ges t t abl e i n s tar jo in quer y. To minimize the possibility of performance degradation of queries involving star schema when star join is enabled. An additional APAR will add a new ZPARM to change the new threshold to enable star join based on the number of tables in a query block. queries could run faster using the optimal access plan generated by the regular access path selection algorithm and users have had difficulties to selectively apply the star join method only to certain queries.

some dimension tables and the fact tables are "star joined" (a partial star join case). For the same star join access paths. If Explain is run for the query. The rest of the dimension tables are joined after the fact table using regular join methods (the order is determined by heuristic rules). The residual dimension tables are joined after the fact table using the regular join methods. When a "non-star-join" access plan is evaluated. all dimension tables and the fact tables are "star joined". The join order of the residual dimension tables are determined by heuristic rules. The best access plan is selected based on the comparison of the costs. A partial star join plan (not all the dimension tables are "star joined"). depending on the value of the CURRENT DEGREE special register. the following tables show some of the possible access plans generated for a star schema query involving the fact table F and the dimension tables D1. the second column is the join_type. the optimal access plan for a query with star schema can be any of these: A full star join plan (all the dimension tables and the fact tables are "star joined").actually star join will not be enabled in this case because the number of tables in the query block is less than 10): Possible case 1: In Table 3-30. perturbations might be applied to the join sequence to exploit the parallelism. Table 3-31 Star join access plan: case 2 D1 D2 F D4 D3 ‘S’ ‘S’ ‘’ ‘’ ‘’ 84 DB2 for z/OS and OS/390 Version 7 Performance Topics . the join_type column of the plan_table will not contain 'S' in such a case. the costs of "non-star-join" plans are also evaluated. Consequently.Multiple possible star join access paths are explored and their costs are evaluated. if SET CURRENT DEGREE = 'ANY' is specified. D4 (this example is for illustration purpose only -. D3. Table 3-30 Star join access plan: case 1 D1 D2 D3 D4 F ‘S’ ‘S’ ‘S’ ‘S’ ‘S’ Possible case 2: In Table 3-31. With this feature. For example. The first column represents the tables in the join order. Not a star join plan at all. D2. Users should note that the new implementation could generate different access plans. partial star join plans will be considered to maximize the efficiency of the star join method.

A new ZPARM will be defined through an APAR so that the users can change the value (the default is 10). unless they are extremely small.Possible case 3: In Table 3-32. The index should match these queries very closely. This occurs when the estimated cost of this plan is lower than the corresponding star join cost. which provide good filtering of the fact table. and ideally the dimension tables as well. This ZPARM is in effect only when the star join is enabled by the already existing ZPARM STARJOIN. this reduces the number of probes needed. There is a small number of column values in workfiles. If there are many combinations of column values which qualify from dimension tables but do not appear in the fact table. SQL performance 85 . – The number of qualifying values needs to be low in absolute terms. these need to be combinations that. and so on. not just in proportion to the number of possible values. when ordered in the sequence of the fact table index. – Each probe into the index incurs significant overhead. – You want to get the most benefit from the least number of probes. Chapter 3. none of the tables are "star joined". with all queries matching the index. If there are combinations of qualifying column values that do not actually occur in the fact table index and data. There is no missing predicate for index columns: – This is to avoid the impact due to stage 2 predicates. The best environment for star join The theory behind the design of DB2 V6 star join support and practical experience gained through the performance measurements has shown that the best environment for star join includes these features: There is a good selectivity on the first column of the chosen index: – The set of qualifying column value combinations needs to be highly selective. all fit within a small number of gaps in the index. it is best if these combinations are clustered together: – Again. It is important to have all of the following conditions met: Suitable queries should be used. Table 3-32 Star join access plan: case 3 D1 D2 F D4 D3 ‘’ ‘’ ‘’ ‘’ ‘’ Note: The star join activation is based on a threshold represented by the number of tables in a query block. – The next most frequent filtering is on the second index column. – AND most of the filtering has to happen on the first index column. There is a high cluster ratio on the chosen index.

86 DB2 for z/OS and OS/390 Version 7 Performance Topics .

Log-only recovery improvement: Frequent update of HPGRBRBA improves log-only recovery Reduced logging for variable-length rows: Under certain conditions the amount of logging done for updates of variable-length rows can be reduced. new traces help you in monitoring virtual storage usage. Parallel data set open: Data set open/close processing for partitions in the same partitioned table space/index is no longer a serial process. Virtual Storage Constraint relief and new traces: VSCR is a permanent concern. EVALUNC.4 Chapter 4. 2001 87 . Evaluate uncommitted: A new DSNZPARM. we discuss the following topics and related performance enhancements that affect DB2 subsystem performance: Asynchronous preformat: Asynchronous preformat improves insert performance. DDL concurrency improvement: Row level locking on catalog table spaces with no links defined can improve DDL concurrency. specifies whether predicate evaluation can occur on uncommitted data. CATMAINT utility: Performance of the CATMAINT utility is improved. DB2 subsystem performance In this chapter. © Copyright IBM Corp.

and during this time period. DB2 V7 brings relief for this issue with the asynchronous preformat functionality. After preformatting. Insert activity will use the formatted space in a table space/index/partition pageset until a threshold is reached. performance is impacted when insert processing is touching the limit of the preformatted area and synchronous preformatting need to be done. DB2 supports up to 20 preformat/extend service tasks to perform preformat/extend processing in parallel. Preformat will format 2 cylinders at a time on a 3390 device unless the allocated space is smaller then a cylinder. First. then only 2 tracks will be formatted. When the space in a table space is not preformatted by LOAD or REORG. the PREFORMAT option on the LOAD and REORG utility command statement directs the utilities to format all the unused pages. P r i o r t o V e r s io n 7 N ew in V e r s io n 7 ASYNCHR ONOU S T h re s h o ld P re fo r m a tte d P r e fo rm a tt e d A llo c a t e d A llo c a te d T r i g g e r n e w p r e f o r m a t a n d w a it E a r l y t r i g g e r n e w p r e f o r m a t a n d N O w a it Figure 4-1 Synchronous and asynchronous preformat Disk space needs to be preformatted before a row/key can be inserted. This typically takes 0. 88 DB2 for z/OS and OS/390 Version 7 Performance Topics . insert processing is held up.2 to 1 second. See Figure 4-1. starting with the high-used relative byte address (RBA) plus 1 (first unused page) up to the high-allocated RBA. Hitting this threshold triggers a preformat service task.4. preformatting is done at table space/index/partition create time. Only one preformat/extend service task can be active on a given table space/index/partition pageset at one time. After the data has been loaded and the indexes built.1 Asynchronous preformat Before DB2 V7 you could only preformat unused space in a table space/index during LOAD or REORG. the high-used RBA and the high-allocated RBA are equal.

1. DB2 subsystem performance 89 .1 Asynchronous preformat performance A test was executed to evaluate the performance impact of asynchronous preformat. 38% less than the time with DB2 V6 synchronous preformat. 200 bytes per row I/O bound test case — sequential insert of 2 million rows. Measurement environment Two test scenarios were executed: CPU bound test case — sequential insert of 8 million rows. 800 bytes per row For this measurement. CPU bound test case Figure 4-2 shows how DB2 V7 asynchronous preformat reduced the elapsed time to only 5% above the class 1 measured CPU time. CPU bound test case 600 500 Elapsed time in seconds 400 -38% 300 200 100 0 V7 V6 Unaccounted EXT/FMT/DEL TS or log writes lock/latch suspension CPU time Figure 4-2 CPU bound test case Chapter 4. the following hardware and software was used: Hardware – IBM 9672-ZZ7 processor – ESS model E20 Software levels – OS/390 V2R7 – DB2 V7 and DB2 V6 Asynchronous preformat measurement results The measurements included CPU bound and I/O bound situations.4.

there was only a single task to perform open/close processing of DB2 database data sets. 4. represent the optimal performance attainable if asynchronous preformat was 100% concurrent with other processes. I/O bound test case 350 Elapsed time in seconds 300 250 200 150 100 50 0 V7 after reorg preformat V7 V6 -19% -8% Unaccounted EXT/FMT/DEL TS or log writes lock/latch suspension CPU Figure 4-3 I/O bound test case The test results. the preformat service task is then triggered.2 Parallel data set open Parallel data set open has improved again in DB2 V7. data buffers are filled and deferred writes are scheduled once the VDWQ threshold is reached. the insert job could concurrently insert into the available already formatted storage. In the meantime.I/O bound test case See Figure 4-3 for the results of this measurement. Before DB2 V5. After some time.. the deferred write task catches up with the asynchronous preformat service task. This shows up in the measurement by lock/latch suspension for an end-of-extend lock.. and preformat I/Os are done. In this situation. DB2 V5 10 parallel tasks for open/close processing and this number was increased to 20 in DB2 V6. “Synergy with host platform” on page 197. DB2 may then schedule a deferred write I/O concurrently with a preformat service task for the same table space/index. The ESS Parallel Access Volumes feature can bring some relief for this situation. for a description of ESS from a DB2 point of view. 90 DB2 for z/OS and OS/390 Version 7 Performance Topics . In this test case. if possible. after a Reorg with preformat was executed on the table space. task(s) will compete for the same I/O resources (UCB. it is better to use LOAD/REORG preformat prior to execution of the sequential inserts.) as the preformat service task. On top of this deferred write. See Chapter 10.. insert reaches the preformat threshold. In this case. Parallel data set open during restart was introduced in DB2 V6 and parallel open/close of partitions within the same partitioned table space/index comes with DB2 V7.

Measurement environment For this measurement. the following hardware and software was used: Hardware: – IBM 9672-ZZ7 processor – Three controllers with 8 disk volumes each Software levels: – OS/390 V2R7 – DB2 V7 and DB2 V6 Ten parallel jobs were each accessing 20 separate partitions of a partitioned table space with 200 partitions.4.3 Virtual storage constraint relief In this section we describe the instrumentation facility enhancements that will help you monitoring the virtual storage usage in the DBM1 address space. DB2 subsystem performance 91 .04 Elapsed time in seconds 3 1. The same test was run on DB2 V6 and DB2 V7 in order to observe the elapsed time reduction in DB2 V7 due to the concurrent open of the partitions in a partitioned table space.1 Performance A set of measurements were executed in order to evaluate the performance benefit of the parallel data set open feature.2.2 times reduction in elapsed time for DB2 V7 compared to DB2 V6 Parallel data set open Performance summary 5 4 4.For this test case we achieved a 2. Chapter 4. Performance measurement results See Figure 4-4 for the measurement results.85 V6 V7 2 1 0 Figure 4-4 Parallel data set open performance 4.

See 9. This IFCID is contained in Global Class 10 and will be recorded at the DB2 statistics interval. Storage manager pool summary statistics IFCID 225 provides you with summary information on the virtual storage usage in the DBM1 address space.1. “New IFCIDs” on page 180 for a description of this IFCID.3.1.3.2 Database address space — virtual storage consumption The components that are responsible for the major part of the virtual memory consumption in the DBM1 address space are now reported in section STORAGE STATISTICS of the DB2 PM statistics long report. 4. “New IFCIDs” on page 180 for a description of this IFCID. See 9.This IFCID is contained in Statistics Class 6 and will be recorded at the DB2 statistics interval. Figure 4-5 STORAGE STATISTICS report layout 92 DB2 for z/OS and OS/390 Version 7 Performance Topics . The storage statistics report layout (not yet available) will look similar to the example in Figure 4-5.1.4.1. Storage manager pool statistics IFCID 217 provide you with detailed information on the storage usage in the DBM1 address space.1 Instrumentation enhancements Two new IFCIDs are added to record DBM1 storage usage statistics.

CATMAINT is invoked by the installation procedure DSNTIJTC. All IBM-supplied indexes are created or updated sequentially during the execution of DSNTIJTC. Spring 2000. Mandatory catalog processing: – – – – – – – – – – – Authorization check Ensure catalog is at correct level DDL processing Additional processing and tailoring Directory header page and BSDS/SCA updates Single commit scope.Database address space — virtual storage budget In the article DB2 UDB for OS/390 Storage Management. The third step does the stored procedure migration processing and is only for migration from V5. GC26-9936. IDUG Solutions Journal. adds columns to existing catalog tables and creates and updates indexes on the catalog tables to accommodate new Version 7 objects. the authors explain a methodology on how to estimate your virtual storage budget and provide relief to virtual storage constraints inside the DBM1 address space. Looking for unsupported objects in the DB2 catalog: The migration will not fail if any of these unsupported objects are found. You must consult the current standard documentation for details. You can now use the Storage Statistics report to identify the storage consumption of each component. specifically the two chapters on migration from V6 and V5. The first step of DSNTIJTC creates new catalog and directory objects. It migrates your Version 6 or Version 5 catalog to the Version 7 catalog. available from: http://www. 4.org.4 CATMAINT utility The CATMAINT utility updates the catalog. The second step of DSNTIJTC searches for the unsupported objects to display the warning messages. The DB2 V7 catalog migration process is as follows: 1. DSNTIJTC contains three steps. A starting point for your evaluation is the DB2 UDB for OS/390 and z/OS Version 7 Installation Guide. You must also check with the IBM support organization regarding the correct maintenance levels on both starting and target systems. A message will be issued for each unsupported object found. it is all or nothing No table space scan Type 1 indexes Data set passwords Shared read-only data Syscolumns zero records 2. before you start migrating you must be aware of changes that might affect your migration. it is run during migration or when instructed to do so by the IBM service. Chapter 4. Even though you are not planning to use new DB2 V7 functions.idug. There is a SYSDBASE table space scan in this step 2. DB2 subsystem performance 93 .

CATMAINT performance measurement — description A customer provide catalog was restored.4. In this section we describe the CATMAINT performance measurements. Stored procedure migration processing from DB2 V5: – Catalog table SYSIBM. DSNU777I. – When migrating from V5.SYSPROCEDURES. then message DSNU776I is issued. 12-way ESS 2105-E20 94 DB2 for z/OS and OS/390 Version 7 Performance Topics .SYSROUTINES and SYSIBM.SYSPROCEDURES into SYSIBM. the catalog and directory are in Version 6 format.SYSPROCEDURE is no longer used to define stored procedures to DB2. All of these messages are written to the SYSPRINT data set. If non-supported functions such as type 1 indexes are encountered. Altered indexes are not rolled back and need to be verified with the CHECK INDEX utility. New diagnostic error messages are issued when CATMAINT processing fails. V6 and V7 IBM 9672 (G6). All rows in SYSIBM. Rows in SYSIBM. then message DSNU778I is issued.SYSROUTINES and SYSIBM.SYSPARMS.SYSPROCEDURE are migrated to SYSIBM. CATMAINT was executed on this catalog in both non-data-sharing and data-sharing environments.SYSPROCEDURES that contain non-blank values for columns AUTHID or LUNAME are not used to generate the CREATE PROCEDURE statements.3. and the execution of the first step of the migration is extremely fast. A new status message. If a problem is found during the SQL processing phase of migration.SYSPARMS. is issued at several points during the migration process to indicate migration progress. For this measurement we used: – – – – OS/390 V2R7 DB2 V5. If job DSNTIJTC fails.SYSPARMS and propagates information from the PARMLIST column of SYSIBM. 4. DB2 also copies rows in SYSIBM. DB2 generates CREATE PROCEDURE statements which populate SYSIBM. because CATMAINT failures roll back all Version 7 changes.1 CATMAINT utility performance The CATMAINT utility has been greatly improved with DB2 V7.

080 Chapter 4. Table 4-1 Catalog tables TABLE SYSCOPY SYSCOLUMN SYSFIELDS SYSFOREIGNKEYS SYSINDEXES SYSINDEXPART SYSKEYS SYSRELS SYSSYNONYMS SYSTABAUTH SYSTABLEPART SYSTABLES SYSTABLESPACE SYSDATABASE SYSDBAUTH IPNAMES NUMBER OF ROWS 975341 2107861 0 180 70268 74717 263148 93 723 2365287 14493 261262 10003 9081 55023 0 TABLE LOCATIONS LULIST LUMODES LUNAMES MODESELECT USERNAMES SYSRESAUTH SYSSTOGROUP SYSVOLUMES SYSPACKAGE SYSPACKAUTH SYSPACKDEP SYSPROCEDURES SYSPACKLIST SYSPACKSTMT SYSPLSYSTEM NUMBER OF ROWS 0 0 0 1 0 0 4169 6 7 690411 799455 2479336 1 4085 13448719 0 TABLE SYSDBRM SYSPLAN SYSPLANAUTH SYSPLANDEP SYSSTMT SYSCOLDIST SYSCOLDISTSTATS SYSCOLSTATS SYSINDEXSTATS SYSTABSTATS SYSSTRINGS SYSCHECKS SYSCHECKDEP SYSUSERAUTH SYSVIEWDEP SYSVIEWS NUMBER OF ROWS 15920 1637 6735 4217 216743 28502 4363 19364 574 744 403 46 48 59 162 266 CATMAINT performance measurement — results Table 4-2 lists the results of the performance measurements. BP0 was used for the catalog and directory. They are divided into two groups.Table 4-1 lists the number of rows of all the relevant catalog tables.607. BP4 was used for the workfiles. and V5 to V7.090 V5 -> V6 V6 -> V7 V5 -> V7 812 74 754 191 6 195 1.643.523 76.571 1.284 24 516.292 32 516. V6 to V7. one without.601 516.913 516. DB2 subsystem performance 95 . Table 4-2 CATMAINT performance measurement results Elapsed time (sec) Non-data-sharing group CPU time (sec) BP0 #getpages BP4 #getpages V5 -> V6 V6 -> V7 V5 -> V7 Data-sharing group 834 82 768 192 6 194 1. and show the results of the first CATMAINT step when migrating from V5 to V6. one with data sharing.644.889 1.607.902 76.

non-data sharing 10 times elapsed time improvement migrating from V6 ->V7 compared to V5 ->V6 1200 1000 834 16% elapsed time improvement migrating from V5 -> V7 compared to V5 -> V6 -> V7 1200 V5 -> V7 V6 -> V7 V5 . – 16% elapsed time improvement migrating from DB2 V5 to DB2 V7 catalog. compared to migration from DB2 V5 to DB2 V7 catalog via DB2 V6 catalog.CATMAINT performance measurement — conclusions The following conclusions on the improvements for step 1 of the migration process were drawn from this measurement for the non-data-sharing case and the data-sharing case. Non-data-sharing case (see Figure 4-6): – 10 times elapsed time improvement migrating from DB2 V6 to DB2 V7 catalog.> V6 V6 -> V7 1000 800 600 Seconds 600 400 200 82 Seconds 800 834 768 400 200 0 0 Figure 4-6 Comparison of migration performance — non-data-sharing case 96 DB2 for z/OS and OS/390 Version 7 Performance Topics . compared to migration from DB2 V5 to DB2 V6 catalog. respectively. step 1 elapsed time is now comparable with step 2. Migration performance .> V6 916 82 V5 . With DB2 V7.

Data-sharing case (see Figure 4-7): – 11 times elapsed time improvement migrating from DB2 V6 to DB2 V7 catalog.> V6 886 74 812 V5 . and also 10. Note: Make sure that APARs PQ38035 and PQ44985 are applied to your system.> V6 V6 -> V7 1000 800 600 Seconds Seconds 754 400 200 0 0 Figure 4-7 Comparison of migration performance — data sharing case Chapter 4. PQ44985 solves a performance problem with CREATE/DROP/ALTER of table spaces. tables and indexes related to declared temporary tables. With PQ38035 CATMAINT no longer fails when an unsupported object is found. compared to migration from DB2 V5 to DB2 V7 catalog via DB2 V6 catalog. – 15% elapsed time improvement migrating from DB2 V6 to DB2 V7 catalog.000 buffers for BP0.000 buffers for the workfile buffer pool. The best performance for migration from DB2 V5 to DB2 V6 is achieved with a buffer pool size of 10. compared to migration from DB2 V5 to DB2 V6 catalog. Migration from DB2 V6 to DB2 V7 rarely uses the workfile buffer pool.data sharing 11 times elapsed time improvement migrating from V6 ->V7 compared to V5 ->V6 1200 1000 800 600 400 200 74 812 15% elapsed time improvement migrating from V5 -> V7 compared to V5 -> V6 -> V7 1200 V5 -> V7 V6 -> V7 V5 . Migration performance . DB2 subsystem performance 97 .

6 Log-only recovery improvement Prior to DB2 V7 the field HPGRBRBA. and the predicate is re-evaluated as needed before the data is returned to the application. data can be excluded from the answer set. Queries with isolation level RS or CS will return only committed data.4. if your applications can tolerate returned data. LOAD utility run against an object.They will never return the uncommitted data of other transactions. to falsely exclude any data that would be included as the result of undo processing (ROLLBACK or statement failure).5. and RID list processing) for queries with isolation level RS or CS. was updated when: A pseudo close or close happened for an object.5 Evaluate uncommitted A new DSNZPARM parameter. A stop command was issued for the object. Although the option influences whether predicate evaluation can occur on uncommitted data. 4. NO ensures that all qualifying data is always included in the answer set. because of undo processing (ROLLBACK or statement failure). index-to-data access. If you specify NO.2 Recommendation Specify YES to improve concurrency. even if predicate evaluation occurs on such. A QUIESCE. has been introduced. With YES. it does not influence whether uncommitted data is returned to an application.5. the recover base RBA field on the pageset header page. predicate evaluation can occur on uncommitted data of other transactions. Data that does not satisfy the predicate during evaluation — but then. the default. predicate evaluation occurs only on committed data (or on the application’s own uncommitted changes). If you specify YES. The option applies only to stage 1 predicate processing that uses table access (table space scan. In DB2 V7 the HPGRBRBA value is updated every nth checkpoint. reverts to a state that does satisfy the predicate — is excluded from the answer set.1 Description Specify whether predicate evaluation can occur on uncommitted data of other transactions. The number of locks avoided depends on: – The query’s access path – The number of evaluated rows that do not satisfy the predicate – The number of those rows that are on overflow pages This parameter can be set as part of the installation procedure on panel DSNTIP4 4. 98 DB2 for z/OS and OS/390 Version 7 Performance Topics . If data satisfies the predicate during evaluation. where n is controlled by the value of the DSNZPARM parameter DLDFREQ. this new subsystem parameter enables DB2 to take fewer locks during query processing 4. A value of YES enables DB2 to take fewer locks during query processing. EVALUNC. the data is locked as needed. representing the starting log RBA value for a log-only recovery.

will benefit from this enhancement. restored from copies made during a log suspend/resume interval. No hardware compression is done.8 DDL concurrency improvement Row level locking for catalog table spaces is now allowed for those catalog table spaces that do not contain links. 4. Restrictions The update does not change the row length.Log-only recovery will benefit from limiting the amount of log records to be scanned by the recover utility. Especially.7 Reduced logging for variable-length rows Before DB2 V7. and no editprocs are used. This enhancement should further improve parallel DDL. In DB2 V7. an update to a variable length row resulted in the logging of the data from the first changed byte of the variable column until the end of the row. 4. the data logged starts at the first byte of the first changed column to the last byte of the last changed column. Chapter 4. DB2 subsystem performance 99 . log-only recoveries with data.

100 DB2 for z/OS and OS/390 Version 7 Performance Topics .

This option allows for a dynamic change of a major part of the subsystem startup parameters. and new subsecond detection values can now be specified for the DEADLOCK parameter.5 Chapter 5. Cancel Thread NOBACKOUT: A NOBACKOUT option is added to the CANCEL THREAD command. but can be retried. Consistent restart: Recover and Load Replace are now allowed against objects associated with postponed units of recovery. Log manager: Suspend/resume log activity allows for snapshot copy of the DB2 environment. Checkpoint frequency can be controlled by a time interval. Online DSNZPARMs: You can now activate a new set of DB2 subsystem parameters without having to recycle DB2. Cancel of postponed recovery is now an option. Critical log read access errors do not force DB2 down. These enhancements are introduced by APARs. Adding workfiles: You can now CREATE and DROP a workfile table space without having to stop the workfile database. DB2 Version 7 introduces new and enhanced functionality in this area. The new releases of DB2 have kept on introducing enhancements to meet this need. 2001 101 . Availability and capacity enhancements Continuous availability has become a major business requirement today. IRLM enhancements: A new option of the modify IRLM command allows the DBMS timeout value as known to IRLM to be dynamically modified. © Copyright IBM Corp. A new warning message for long running units of recovery is introduced.

because of the type of functions that they impact. 102 DB2 for z/OS and OS/390 Version 7 Performance Topics .5. -------. refer to Appendix A.1. the online change is transparent. 5. “Updatable DB2 subsystem parameters” on page 211.3 Parameter behavior with online change For most parameters.---DSNTIPN 1 DSNTIPE 4 DSNTIPE 2 DSNTIPL 14 Description/ Install Field Name -----------------------------------AUDIT TRACE MAX REMOTE CONNECTED MAX USERS LEVELID UPDATE FREQUENCY For a complete listing of the updatable parameters.1 SET SYSPARM command -SET SYSPARM LOAD (load module name) – Loads the specified module – Loads DSNZPARM if load module name not specified -SET SYSPARM RELOAD – Reloads the last named subsystem parameter load module -SET SYSPARM STARTUP – Resets loaded parameters to their startup values 5. DSN8ED7: Sample DB2 for OS/390 Configuration Setting Report Generator Macro Name -------DSN6SYSP DSN6SYSP DSN6SYSP DSN6SYSP Parameter Name ---------------AUDITST CONDBAT CTHREAD DLDFREQ Current Setting --------------------------------------00000000000000000000000000000000 0000000064 00070 00005 Install Fld Panel ID No. DB2 V7 introduces a new command -SET SYSPARM which allows you to dynamically load the DSNZPARM load module. with the change taking effect immediately.1. 5.1. There are several parameters for which this is not the case. The behavior exhibited by the system upon changes to these parameters is discussed here: AUTHCACH Changing the plan authorization cache only takes effect for new BIND PLAN actions without the CACHESIZE specification.1 Online DSNZPARM Prior to DB2 V7 you had to recycle DB2 in order to load a new DSNZPARM module.2 Displaying the current settings Sample program DSN8ED7 returns the currently active subsystem parameters in a formatted report.

LOBVALA Changing the user LOB value storage does not affect any currently running agents that have already acquired storage from data spaces for LOBs. a message is issued indicating how much storage was released and how much is pending. At the time the EDM pool is contracted. “Examples” on page 105. Chapter 5. The pending storage is released when it is no longer accessed. as a result. an attempt is made to contract the storage pool (which can only be contracted if there are empty segments).4. An informational message (DSNG002I) indicates the amount of the allocated size. Note that a contiguous EDM pool is the most efficient. the new MAXRBLK value does not take effect until a user attempts to allocate another RID block.1. some storage may be in use. If so. the current number of RID blocks allocated is greater than the newly specified value. a resource-not-available SQLCODE is not issued until the next attempt by an agent to acquire storage. NUMLKTS The number of locks per table space does not change immediately for agents that have already been allocated when the parameter is changed. and therefore the results may not be instantaneous. DB2 issues a warning message (DSNG003I) and increases the pool as large as available space allows. and using the SET SYSPARM command to increase the EDM pool size may not result in a contiguous pool. Using the SET SYSPARM command to decrease the size of the EDM pool may involve a wait for system activity to quiesce. Using dynamic parameters. EDMBFIT The large EDM pool better-fit parameter is used to determine the algorithm to search the free chain for large EDM pools (greater than 40 M). If the parameter change decrements the value of LOBVALS such that the current amount of storage allocated for the system is greater than the new LOBVALS value. This change only affects new free chain requests. The changes in the EDM pool can be monitored using the EDM statistics or the 106 trace record. EDMPOOL The EDM pool storage parameter can be used to increase or decrease the size of the EDM pool. See also 5. LOBVALS The system LOB value storage is examined whenever an agent attempts to allocate storage from a data space pool for LOBs. MAXRBLK If the RID pool size is decremented and. It only affects new agents. rounding up to the next 5M boundary. Availability and capacity enhancements 103 . Any attempt to reduce the EDM pool size below the initial value is rejected and indicated by message DSNG001I. The initial allocation works as it did prior to online change — getting a single block of storage the size of the request. The changes in the EDM pool size is done in 5M increments. If insufficient virtual storage is detected when expanding the EDM pool. the user can increase the EDM pool from the initial size or reduce the EDM pool back to the initial size. When the value is decremented. The allocated agents keep the old value in accordance with their RELEASE bind parameter (COMMIT or DEALLOC).

The change is not seen for dynamic DML statements issued before the RLF is refreshed with the -START RLIMIT command. it overrides the last -SET LOG value. IDBACK. this parameter behaves the same as the EDMPOOL parameter. Changing the parameter online overrides the last -SET ARCHIVE value. PTASKROL This value. BMPTOUT. Also. The current value can be displayed with the -DISPLAY LOG command. and DELETE. which overrides the value in the subsystem parameter load module. IDFORE. the offload continues with the original parameter values. If a new parameter is activated through the online change. If the initial value was zero when DB2 was started. CHKFREQ (LOGLOAD before DB2 V7) The checkpoint frequency parameter can be modified by the -SET LOG COMMAND. the change takes effect after the resource limit facility is restarted using the -START RLIMIT command. 104 DB2 for z/OS and OS/390 Version 7 Performance Topics . current agents that were queued prior to the increase do not become active until existing active agents terminate or become inactive (see the "DDF THREADS" INACTIVE specification in the DSNTIPR installation panel where inactive thread support is enabled). RLFTBL.EDMDSPAC The EDM pool data space parameter can be used to increase or decrease the size of the Data Space storage used for dynamic statements. The new archive log parameter values does not take effect until the next offload sequence. is read from the updated control block when the first child record is summed up for the child task accounting data roll up. RLFERR After a change to the resource limit facility parameters. The value is saved in the parent accounting block so that the behavior for any parent and all its child tasks is consistent. indicating whether to roll up query parallel task accounting trace records into the originating task accounting trace or not. Archive log parameters If an offload (archiving an active log data set) is active at the time of a related parameter change. Other than those restrictions. The data space storage can only be increased up to the maximum size specified at DB2 start time. IMS BMP and DLI batch timeout) do not take effect until the next create thread request. So the existing interval for each must expire before the new value can be set. UPDATE. this parameter cannot be changed. MAXDBAT When the maximum remote active value is increased. These values can be modified with the -SET ARCHIVE command. DEALLCT. The current values can be displayed with the -DISPLAY ARCHIVE command. STATIME The data set statistics and the statistics interval time parameters are read from the updated control block when it is available when the intervals are being set for the next timer pop for the statistics. RLFAUTH. any threads currently executing are not updated with the new values. DLITOUT Any changes to these parameters (max batch and max TSO connect. MAXRTU The behavior for the archive deallocation period and the maximum allocated tape units parameters is similar to check point frequency (CHKFREQ). DSSTIME. RLFERRD. for the dynamic statements SELECT. INSERT.

1. LPL was added. In order to resolve this status. Impacted page sets/partitions are marked Refresh Pending (REFP) and LPL. PARAMETER CHANGE IGNORED.5. then it is increased to 15M: DSNZ006I =DB2A DSNZCMD1 SUBSYS DB2A SYSTEM PARAMETERS LOAD MODULE NAME DSNZPAR2 IS BEING LOADED DSNG002I =DB2A EDM POOL HAS AN INITIAL SIZE 10485760 REQUESTED SIZE 12582912 AND AN ALLOCATED SIZE 15605760 DSNZ007I =DB2A DSNZCMD1 SUBSYS DB2A SYSTEM PARAMETERS LOAD MODULE NAME DSNZPAR2 LOAD COMPLETE -SET SYSPARM STARTUP Changing the DSNZPARM parameters back to their start-up value also set the EDM pool back to its initial value: DSNZ007I =DB2A DSNZCMD1 SUBSYS DB2A SYSTEM PARAMETERS LOAD MODULE NAME DSNZPAR2 LOAD COMPLETE DSNG002I =DB2A EDM POOL HAS AN INITIAL SIZE 15605760 REQUESTED SIZE 10485760 AND AN ALLOCATED SIZE 10485760 DSNZ011I =DB2A DSNZCMD1 SUBSYS DB2A SYSTEM PARAMETERS SET TO STARTUP 5. DSNZCMD1 SUBSYS DB2A SYSTEM MODULE NAME DSNZPAR1 LOAD COMPLETE -SET SYSPARM LOAD(DSNZPAR2) If the EDM pool is 10M and the request is to increase it to 12M. The postponed units of recovery left some objects in RESTP (non data sharing) or ARESTP (data sharing) status. backout processing during DB2 restart could be postponed in order to make DB2 available faster after an outage.4 Examples The SET SSPARM command is used as shown in the following examples: -SET SYSPARM LOAD(DSNZPAR1) Message DSNZ014I is generated if the value for an unchangeable parameter differs from the startup value: DSNZ006I =DB2A PARAMETERS LOAD DSNZ014I =DB2A DSN6SYSP CANNOT DSNZ007I =DB2A PARAMETERS LOAD DSNZCMD1 SUBSYS DB2A SYSTEM MODULE NAME DSNZPAR1 IS BEING LOADED DSNZOVTB PARAMETER BACKODUR IN CSECT BE CHANGED ONLINE. The -RECOVER POSTPONED CANCEL command allows you to cancel postponed units of recovery. DB2 V7 introduces further enhancements on this issue. Chapter 5. you had to issue the -RECOVER POSTPONED command or you had to set LBACKOUT to AUTO in ZPARM. Availability and capacity enhancements 105 .2 Consistent restart enhancements In DB2 V6. In order to make the units of recovery aware of the REFP status.

TOCOPY) It is your responsibility to specify a valid logpoint. RECOVER TO (LOGPOINT. as well as the database and page set name. See Figure 5-3.The REFP. The log record will be of type DIAGNOSTIC subtype name START DATABASE FORCE. 106 DB2 for z/OS and OS/390 Version 7 Performance Topics . See Figure 5-1 for an example. LOGRBA. Figure 5-1 RECOVER POSTPONED CANCEL command response The DISP field in the SUMMARY OF COMPLETED EVENTS report of DSN1LOGP for a unit of recovery whose recovery was cancelled is set to CANCELLED. are introduced. See Figure 5-2. associated with the -RECOVER POSTPONED CANCEL command. START DB() SPACE() ACCESS(FORCE) Several new messages. Figure 5-2 DSN1LOGP SUMMARY OF COMPLETED EVENTS report A new diagnostic log record is added that can log successful START DATABASE ACCESS(FORCE) commands. The DBID/OBID/PART is logged.LPL status can be resolved in one of the following ways: LOAD REPLACE This is done on the impacted page sets/partitions.

1 Log suspend and resume The LOG SUSPEND command suspends update activity and logging while you make an external copy of your production system. a U lock is taken on the workfile database DBD only if the DB2 member executing the DDL is the “owning” DB2 member for that workfile database. in a data sharing environment. particularly large sites where significant space needs to be allocated for large workdays.4 Adding workfiles DB2 V7 provides a less disruptive addition of workfile table spaces. This enhancement reduces performance problems and improves availability in a 24x7 environment. These copies can be used for remote site recovery or point-in-time recovery. other DB2 agents are able to continue to use other table spaces in the workfile database. to make a copy.5 Log Manager enhancements In this section we describe the Log Manager enhancements. During the brief suspension. such as Enterprise Storage Server FlashCopy or RAMAC Virtual Array Snapshot. The LOG RESUME command restarts update activity and logging. However. by changing the workfile allocations more frequently. DB2 will not allow concurrent access to the other workfile table spaces in the database being modified.LPL. which possibly leaves affected objects in an inconsistent state. In a non-data sharing environment. and/or large query sorting. Otherwise. optionally you can add the parameter NOBACKOUT to this command. This enhancement was also introduced in DB2 V6 by APAR PQ31492. a U lock is taken on the workfile DBD. 5. Therefore.LPL status. Therefore while you are creating or dropping a workfile table space. an X lock is taken on the DBD. and/or 24x7 applications.5. 5. Chapter 5. 5.00000028C000 URID(00000028BE15) LRSN(B4E94FB29BE0) TYPE( REDO ) SUBTYPE(START DATABASE ACCESS FORCE) PROCNAME(DSNIZLDL) Figure 5-3 DSN1LOGP example . Availability and capacity enhancements 107 . Otherwise. because changing workfile space allocation is much less disruptive. DB2 will allow other DB2 agents to have concurrent use of other workfile table spaces in the database only if you execute the DDL on the “owning” DB2 member. You will also be able to better manage your workfile space. These objects are also marked REFP. It allows you to CREATE and DROP workfile table space without having to STOP the workfile database All customers will benefit from this enhancement.3 CANCEL THREAD NOBACKOUT The -CANCEL THREAD command was enhanced in a similar way to the -RECOVER POSTPONED command. you can use a fast-disk copy facility. The same actions as with the recover postponed cancel command can be taken to resolve the REFP.START DATABASE FORCE log record 5.

In addition to holding up normal activity. The BSDS is updated with the highest written RBA. LRSN 00000031CB60.2 Time controlled checkpoint interval Prior to DB2 V7 you could implement a time controlled checkpoint frequency by using the -SET LOG LOGLOAD(0) command every n minutes. PRIOR CHECKPOINT RBA 000000317B3A DSN9022I =DB2A DSNJC001 '-SET LOG' NORMAL COMPLETION Effects of SET LOG RESUME command The SET LOG RESUME command has the following effects: The log write latch is released. A log write latch is obtained. 108 DB2 for z/OS and OS/390 Version 7 Performance Topics . The log buffers are flushed. You can compare the restart process following a restore of the copy with the restart process after a system crash. DSNJ373I =DB2A DSNJC09A UPDATE ACTIVITY HAS BEEN RESUMED FOR DB2A DSN9022I =DB2A DSNJC001 '-SET LOG' NORMAL COMPLETION Notes: Avoid the use of LOG SUSPEND/RESUME during heavy update activity.5. 5. Depending on the activity. the RVA/ESS will require more space until the copy offload process completes. is issued to the console which identifies the subsystem and the log point at which log activity is suspended. there can be other issues when using the SnapShot/FlashCopy process during heavy update activity: Restart processing after restoring the copy will take longer while all pending writes have to be applied from the log and unresolved units of recovery have to be rolled back or forward recovered. A highlighted message. DSNJ372I. In DB2 V7 the checkpoint frequency can be time-driven or logload-driven. The log resumed message is issued. DSNJ372I =DB2A DSNJC09A UPDATE ACTIVITY HAS BEEN SUSPENDED FOR DB2A AT RBA 00000031CB60. in data sharing a system checkpoint could cause a system hang due to the log suspend of the other members). The highlighted log suspend message is deleted.Effects of SET LOG SUSPEND command The SET LOG SUSPEND command has the following effects: A system checkpoint is taken (non data sharing only.

With DB2 V7. Avoid using the time interval controlled checkpoint frequency while it can influence a DB2 consistent restart time. CHKTIME (20) DSN9022I =DB2A DSNJC001 '-SET LOG' NORMAL COMPLETION You can display the current CHKTIME value as well as current log information using the -DISPLAY LOG command.DS01 IS 52% FULL CURRENT COPY2 LOG = DB2V710B. 2000 RESTART RBA 000000825000 CHECKPOINT FREQUENCY 20 MINUTES LAST SYSTEM CHECKPOINT TAKEN 18:31:36 NOV 10. Availability and capacity enhancements 109 .3 Retry of log read request Using earlier versions of DB2 for OS/390.LOGCOPY2. it again picks up the value for the LOGLOAD parameter from your DSNZPARM start up module. DB2 then will wait for the reply to message DSNJ154I before retrying the log-read access. =DB2A SET LOG CHKTIME(20) DSNJ339I =DB2A DSNJC009 SET LOG COMMAND COMPLETED. As you know. CHKTIME. A value of 0 forces DB2 to take a checkpoint without changing the checkpoint frequency. or before abending. Chapter 5.LOGCOPY1. such as a temporary HSM or tape subsystem problem. 2000 DSN9022I =DB2A DSNJC001 '-DIS LOG' NORMAL COMPLETION Note: Remember.5. of the -SET LOG command allows you to specify a time interval from 0 to 60 minutes. 5.DS01 IS 52% FULL H/W RBA = 00000117F4A2 H/O RBA = 000000000000 FULL LOGS TO OFFLOAD = 0 OF 6 OFFLOAD TASK IS (AVAILABLE) DSNJ371I =DB2A DB2 RESTARTED 11:50:06 NOV 10. Sometimes the condition causing the log-read failure is correctable.Description A new parameter. When DB2 is restarted. such as rollback. the DB2 subsystem terminates whenever a log-read request fails during a “must-complete” operation. messages DSNJ153E and DSNJ154I (WTOR) will be issued to show and identify the critical log-read error failure. the longer it takes for DB2 to restart. =DB2A DIS LOG DSNJ370I =DB2A DSNJC00A LOG DISPLAY CURRENT COPY1 LOG = DB2V710B. DB2 restart time is dependent on the number of log records to be processed since the last checkpoint and with a time interval controlled checkpoint frequency the number of log records will be different in each checkpoint interval. the higher the values for LOGLOAD or CHKTIME.

UNCOMMITTED UR HAS WRITTEN 1000 LOG RECORDS CORRELATION NAME = PAOLOR6E CONNECTION ID = BATCH LUWID = DB2A.DSNJR206 RECEIVED ERROR STATUS 00000004 FROM DSNPCLOC FOR DSNAME=DSNC710.DSNJHR126 REPLY Y TO RETRY LOG READ REQUEST. The value of this threshold is specified in the parameter URLGWTH (UR log record written threshold) of the DSNZPARM. Every time the threshold is reached. N TO ABEND 5. The value of this parameter can be modified using the -SET SYSPARM command DSNJ031I =DB2A DSNJW001 WARNING .DSNJ104I . The specific purpose of this message is to warn you about ongoing work in DB2 which can impact restart time in case of a subsystem failure.A0000049 DSNJ104I .DSNJR006 CRITICAL LOG READ ERROR CONNECTION-ID=TEST0001 CORRELATIOND-ID=CTHDCORID001 LUWID = V71A-SYEC1DB2.B343707629D=10 REASON-CODE=00D10345 *26 DSNJ154I .B4ECE117BB5C = 91 PLAN NAME = DSNTEP71 AUTHID = PAOLOR6 END USER ID = * TRANSACTION NAME = * WORKSTATION NAME = * 110 DB2 for z/OS and OS/390 Version 7 Performance Topics . this message could be misleading because it is depending on the overall DB2 workload.4 Long running UR warning message Prior to DB2 V7.5. DB2 issues warning message DSNR035I for a long running unit of recovery (UR) based on a number of system checkpoints taken since the beginning of the UR.DSNJR206 RECEIVED ERROR STATUS 00000004 FROM DSNPCLOC FOR DSNAME=DSNC710. A new warning message is issued when a unit of recovery has written a predefined number of log records without committing. message DSNJ031I is generated.ARCHLOG2.ARCHLOG1. Although useful.SCPDB2A.A0000049 *DSNJ153E .

for DB2. IRLM will increase the timeout value to the next highest multiple. the value for IRLMRWT altered in the DSNZPARM.SET. The TIMEOUT value must be a multiple of the local deadlock parameter. This new value is used until the IRLM or identified subsystem is terminated.STATUS command.subsystem-name nnnn must be a number from 1 through 3600. Example Enter the command on an MVS console: /F DB2GIRLM. Syntax errors include TIMEOUT value out-of-range or invalid identified subsystem name. IRLMRWT cannot be changed via the SET SYSPARM command. A syntax error message will also be given if the DXR177I message has not been received for the prior command completion. APAR PQ38455 introduces a new MODIFY command option to dynamically change the timeout value. subsystem-name is the DB2 subsystem name.5. Up to now.TIMEOUT=65.6 IRLM enhancements In this section we describe two new enhancements for IRLM: A new option of the modify IRLM command allows the DBMS timeout value as known to IRLM to be dynamically modified. MODIFY command description The following MODIFY command requests that IRLM dynamically set the timeout value for the specified subsystem: MODIFY irlmproc.6. If the value entered is not an even multiple of the deadlock parameter. Availability and capacity enhancements 111 . The value specified on the command does NOT affect the timeout value in the DB2ZPARM.TIMEOUT=nnnn. as displayed by the MODIFY irlmproc.DB2G This is the response on the MVS console: DXR177I IRLG001 THE VALUE FOR TIMEOUT IS SET TO 65 FOR DB2G Chapter 5. this means that the subsystem must be shut down. New subsecond detection values can now be specified for the DEADLOCK parameter. and DB2 restarted. The value used by IRLM for timeout will be displayed in the DXR177I message which is issued during deadlock processing. 5. or the timeout is change again by the operator.SET. Any syntax error in issuing the command will receive DXR106E. users would like the ability to alter the timeout value that was given to IRLM by the DBMS at start up.1 Dynamic change of IRLM timeout value Sometimes.

5. Measurements The IRWW workload was used to evaluate the impact of the subsecond value for DEADLOK.001072 343. the current minimum time for a global deadlock to be detected is approximately 2 seconds when DEADLOK(1.2 Subsecond deadlock detection Both the speed of processors and the number of transactions per second is increasing.1) is specified. This enhancement provides the ability to specify a value in milliseconds for the IRLMPROC DEADLOK parameter for the local deadlock frequency. the install panel for IRLM. while the window of opportunity is becoming shorter — hence the need to be able to detect deadlocks before queueing takes place. one with DEADLOK=1000 (the current lower limit). Currently the DEADLOK parameter in your IRLM startup procedure is 1 second.001086 -0. DSNTIPJ.42 +0.753 0.6.62 2. An IRLM enhancement introduced by the PTF for APAR PQ44791 introduces the possibility to specify values lower than 1 second down to the current new limit of 100 milliseconds. Table 5-1 Subsecond deadlock detection impact Measurement value DEADLOK=1000 DEADLOK=100 Delta % ITR (commit/sec) C2 CPU (msec)% Total locks/latches per Commit 345. the value for nnnn ranges from 100 to 5000 msec.07 2.756 0.DEADLOCK=nnnn In this command. Two measurements were collected.30 112 DB2 for z/OS and OS/390 Version 7 Performance Topics .11 +1. and one with DEADLOK=100 (the new lower limit after applying the fix). You can also dynamically change the deadlock frequency with the new command: MODIFY irlmproc.SET. The results are summarized in Table 5-1 and show no appreciable impact. and in a sysplex environment. is modified in accordance with the new allowed values.

Modify Recovery: This is a performance enhancement provided through maintenance in DB2 V5.6 Chapter 6. UNLOAD: This is a new utility to unload data from tables without any influence on business applications. Cross Loader: This provides a new functionality to move data across multiple databases. work data sets. and BUILD2 phase is now supporting parallelism for building NPIs. A new drain specification statement has been added to overriding the utility locking time-out value specified at subsystem level. 2001 113 . sort data sets. Online LOAD RESUME: This allows you to load data into tables with a utility that act like a normal INSERT program. and so on. SG24-6289. and even across multiple platforms. Statistics history: It is now possible to store all generations of statistics information and not only the current information from RUNSTATS. Utility performance In this chapter we describe the DB2 V7 performance related enhancements to the following DB2 utilities and functions: Dynamic utility jobs: You can specify a pattern of DB2 objects to run utilities against and to dynamically allocate unload data sets. LOAD partition parallelism: This makes it possible to load partitioned table spaces in parallel with only one job instead of running multiple jobs per partitions. V6. Online REORG enhancements: The FAST SWITCH phase has been improved. © Copyright IBM Corp. planned to be available by 3Q2001. For more information on DB2 utilities. and V7. COPYTOCOPY: This new utility gives you the opportunity to make additional full or incremental image copies. you can refer to the upcoming redbook DB2 for z/OS and OS/390 Version 7 Using the Utilities Suite.

index spaces or their partitions. namely table spaces. See DB2 UDB for OS/390 and z/OS Utility Guide and Reference.6.TS2 DBY. It is even possible to specifies that all objects that are referentially related to the object expression (PRIMARY KEY <--> FOREIGN KEY) are to be included in the list. the total cost of operations can be minimized. As new objects are constantly created.1.PTS1 DBX. Within each DD statement. 3.TS3 DBY. less user activity is required.1 LISTDEF LISTDEF is used to define dynamic list of DB2 objects. disposition. DD statements must be provided for all data sets. Users primarily face three challenges: 1. Development and maintenance of jobs has become easier. and these objects must be named accurately. it is particularly difficult to keep up with the changes. DB2 V7 addresses these three challenges by introducing the following three new utility control statements: LISTDEF TEMPLATE OPTIONS The benefits of these new statements are evident. Figure 6-1 shows the differences in JCL using LISTDEFs. SC26-9945. and since the sizes of most objects vary over time. The defined list can be used in one or more utilities in the job step. as changes are reflected automatically. 2. Also. 6.T* RI RECLIST X'xxxxxxxxxxxx' TOLOGPOINT Figure 6-1 Sample JCL from DB2 V6 and DB2 V7 using LISTDEF 114 DB2 for z/OS and OS/390 Version 7 Performance Topics .TS4 X'xxxxxxxxxxxx' /* V7 //SYSIN LISTDEF RECOVER /* INCLUDE TABLESPACE DBY. name patterns and even other lists. others are deleted. space. The defined list can be any combination of including or excluding specific names. and other parameters must reflect the current situation. D a ta b a s e D B X TS0 RI PTS1 TS2 RI D a ta b a s e D B Y RI TS3 TS4 V6 //SYSIN RECOVER DD * TABLESPACE TABLESPACE TABLESPACE TABLESPACE TOLOGPOINT DD * RECLIST LIST DBX. For more information about LISTDEF.1 Dynamic utility jobs Development and maintenance of utility jobs can be very time consuming and error prone. Utility statements must explicitly list all DB2 objects to be processed. and thus the possibility for errors is reduced. As a consequence.

.P00003..SPACE=..D2000166.TCOPYSEC ) COPY TABLESPACE DBX. SC26-9945... You can create a skeleton or a pattern for the names of the data sets to allocate.COPYSEC3) /* V7 //* none of the DD statements above //SYSIN DD * TEMPLATE TCOPYPRI DSN ( &DB...... This list is generated each time the template is used by an executing utility.P&PART. // DISP=.... V6 //COPYPRI1 DD DSN=DBX.PTS1 DSNUM 3 COPYDDN ( TCOPYPRI.PTS1. Utility performance 115 ..P00001.PTS1 DSNUM 2 COPYDDN ( TCOPYPRI..PTS1..UNIT=.PTS1 DSNUM 3 COPYDDN (COPYPRI3.&TS..D&JDATE... // DISP=...PTS1 DSNUM 1 COPYDDN ( TCOPYPRI.COPYSEC2) COPY TABLESPACE DBX.D2000166.UNIT=.SPACE=. //COPYPRI2 DD DSN=DBX..... DSNU105I =DB2A DSNUGDIS .. // DISP=...UNIT=.&SECBAC.. //COPYSEC2 DD DSN=DBX.SPACE=.P&PART.1. //COPYSEC3 DD DSN=DBX..P00002. // DISP=..D2000166... See Figure 6-2..SPACE=.D2000166. //SYSIN DD * COPY TABLESPACE DBX.P00001.&PRIBAC..P00003... ) COPY TABLESPACE DBX..TCOPYSEC ) COPY TABLESPACE DBX.. 6..TCOPYSEC ) /* Figure 6-3 Sample JCL from DB2 V6 and DB2 V7 using TEMPLATE Chapter 6.. // DISP=..D&JDATE. Figure 6-3 shows the differences in JCL using templates.PTS1. Therefore a template automatically reflects the data set allocations currently needed..PTS1.UNIT=..SPACE=..D2000166.P. ) TEMPLATE TCOPYSEC DSN ( &DB.. See DB2 UDB for OS/390 and z/OS Utility Guide and Reference. //COPYPRI3 DD DSN=DBX..2 TEMPLATE With TEMPLATE you can define a dynamic list of data set allocations.PTS1 DSNUM 2 COPYDDN (COPYPRI2..&TS.B.P.USERID = PAOLOR5 MEMBER = UTILID = DSNTEX PROCESSING UTILITY STATEMENT 1 UTILITY = RUNSTATS PHASE = UTILINIT COUNT = 0 NUMBER OF OBJECTS IN LIST = 40 LAST OBJECT STARTED = 11 STATUS = ACTIVE DSN9022I =DB2A DSNUGCCC '-DIS UTIL' NORMAL COMPLETION *** Figure 6-2 DISPLAY UTILITY output You can see the number of objects included in a list and the number of the current active objects. //COPYSEC1 DD DSN=DBX..B. For more information.P.Enhanced DISPLAY UTILITY() command output DSNU100I for stopped utilities and DSNU105I for active utilities include additional information.B..UNIT=.D2000166..SPACE=.PTS1.UNIT=. The list of these data sets to allocate is dynamic. // DISP=.....P00002.PTS1..COPYSEC1) COPY TABLESPACE DBX.PTS1 DSNUM 1 COPYDDN (COPYPRI1.

DATE/TIME VALUES MAY CHANGE BEFORE EXECUTION DSNU1009I DSNUGPVV .LISTDEF COPYLST EXPANDS TO THE FOLLOWING OBJECTS: LISTDEF COPYLST -.DBLP0002.DATE/TIME VALUES MAY CHANGE BEFORE EXECUTION DSNU1009I DSNUGPVV .FIC.OPTIONS PREVIEW EVENT(ITEMERROR.* DSNU1035I DSNUILDR .HALT) DSNU1000I DSNUGUTC .TSLP2005 INCLUDE TABLESPACE DBLP0002.TEMPLATE COPYTMP DSN=PAOLOR5.CATLG.TSLP2002.FIC.EXPANDING LISTDEF COPYLST DSNU1021I -DB2G DSNUILSA PROCESSING INCLUDE CLAUSE TABLESPACE DBLP0002. we recommend that you use the PREVIEW option before running utilities.TSLP2004.TEMPLATE COPYTMP DSN=PAOLOR5. 116 DB2 for z/OS and OS/390 Version 7 Performance Topics .TEMPLATE COPYTMP DSN &USERID.OPTIONS STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .TEMPLATE COPYTMP DSN=PAOLOR5.CATLG) SPACE(50. See Figure 6-4.3 OPTIONS OPTIONS gives you the opportunity to validate and control your LISTDEF and TEMPLATE statements.DBLP0002. For more information about OPTIONS.TEMPLATE COPYTMP DSN=PAOLOR5.&TS.00000006 OBJECTS INCLUDE TABLESPACE DBLP0002. UTILID = COPYTS DSNU050I DSNUGUTC .* DSNU1022I -DB2G DSNUILSA .DBLP0002.TSLP2003 INCLUDE TABLESPACE DBLP0002.UTILITY EXECUTION COMPLETE.FIC.D0427 DSNU1007I DSNUGPVV . and you can control return codes and error events..PROCESSING CONTROL STATEMENTS IN PREVIEW MODE DSNU1035I DSNUILDR .TSLP2004 INCLUDE TABLESPACE DBLP0002.&DAY.TSLP2003.D0427 DSNU1007I DSNUGPVV .DATE/TIME VALUES MAY CHANGE BEFORE EXECUTION DSNU1009I DSNUGPVV .TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .D0427 DSNU1007I DSNUGPVV .TSLP2006.FIC.COPY LIST COPYLST SHRLEVEL REFERENCE FULL YES COPYDDN(COPYTMP) DSNU1020I -DB2G DSNUILSA .6.TSLP2006 DSNU1009I DSNUGPVV .D0427 DSNU1007I DSNUGPVV .25) CYL DSNU1035I DSNUJTDR .TSLP2005.&DB. The PREVIEW option will parse all utility control statements for syntax errors but normal utility execution will not take place.FIC. UNIT SYSDA DISP(NEW.DATE/TIME VALUES MAY CHANGE BEFORE EXECUTION DSNU1009I DSNUGPVV . It allows you to specify a library for your LISTDEF and TEMPLATE definitions.TSLP2002 INCLUDE TABLESPACE DBLP0002. DSNU000I DSNUGUTC .FIC.TEMPLATE COPYTMP DSN=PAOLOR5.TSLP2001.LISTDEF COPYLST INCLUDE TABLESPACE DBLP0002.LISTDEF STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .TSLP2001 INCLUDE TABLESPACE DBLP0002. HIGHEST RETURN CODE=4 Figure 6-4 Output from PREVIEW If you have added or changed your LISTDEF or TEMPLATE statements. all LISTDEF lists and TEMPLATE DSNAMEs which appear in SYSIN will be expanded. If syntax is valid.CLAUSE IDENTIFIES 6 OBJECTS DSNU1023I -DB2G DSNUILSA .D0427 DSNU1007I DSNUGPVV .OUTPUT START FOR UTILITY. See DB2 UDB for OS/390 and z/OS Utility Guide and Reference.DATE/TIME VALUES MAY CHANGE BEFORE EXECUTION DSNU010I DSNUGBAC .DATE/TIME VALUES MAY CHANGE BEFORE EXECUTION DSNU1009I DSNUGPVV ..D&MONTH..DBLP0002.TEMPLATE COPYTMP DSN=PAOLOR5.DBLP0002.DBLP0002.FIC.LISTDEF COPYLST CONTAINS 6 OBJECTS DSNU1010I DSNUGPVV .D0427 DSNU1007I DSNUGPVV .1. SC26-9945.

Should the utility fail and be restarted. so the performance overhead must be considered negligible when compared with the benefit you get out of using TEMPLATE. Verify that the PTF for APAR PQ45268 (open at the time of writing) is applied. The performance degradation of using TEMPLATE on simple table spaces is less than 7% in elapsed time. Restart from the last commit point (RESTART or RESTART(CURRENT)) and restart from the beginning of the current phase (RESTART(PHASE)) are supported. so the pattern you have specified for your DB2 objects will cover future new objects too. the checkpointed list is used from the in-process utility. the COPY utility cannot be restarted with RESTART(PHASE).4 RESTART processing Utility processing checkpoints two new categories of information for the purposes of restart: LIST information The enumerated list is saved during the UTILINIT phase of each utility. as well as the time that you save to maintain utility jobs.6. 6. The symbolic variable values that are saved are: the job variables. To get most benefit out of using LISTDEF.5 Performance considerations Verify that the PTF for APAR PQ46577 is applied to prevent having unnecessary overhead at initialization time when using LISTDEF.1. and the data and time variables. However. because a single task will be building each NPI. will be used. but you could experience problems with contention impact on non-partitioning indexes (NPI).2 LOAD partition parallelism Prior to DB2 V7. Chapter 6. If symbolic variables were specified for the DSNMAE option of the TEMPLATE statement. However. not re-expanded from the LISTDEF control statement. Subsequent utilities in the same job step will re-expand the list from the LISTDEF definition. not the original job. Subsequent utilities in the same job step will not use the saved variable values. You no longer need to change space allocation of data sets used for utilities. the execution time values are saved for the duration of the utility statement and will be used during restart. it is necessary that you have a good naming convention for your DB2 objects. you must ensure that you have enough free space available to allocate the data sets needed for the execution of the utilities. 6.1. It is recommended that you use LISTDEF for specifying the DB2 objects that you want to include in your utility jobs. There are obvious benefits obtained from using LISTDEF to ensure that utilities run against all old and future new DB2 objects. For example. Thus the problems with contention impact on NPIs are eliminated. TEMPLATE information Data sets will continue to be checkpointed for restart processing. you have to run dedicated LOAD jobs per partition. DB2 V7 addresses this issue and allows you to load partitions in parallel within the same LOAD job. current utility specific restart restrictions apply. Values that represent the restart job. Utility performance 117 . and the problems with running out of space (abend D37) during utilities are eliminated.

SYS R EC 1 Error/M ap R ELO AD Part 1 key/R ID pairs SYS U T1 SO RT SO R TW K nn S O RT B UILD O UT PI Part 1 B U IL D PI Part 2 Error/Map ke y/RID pa irs R ELOAD SYS R EC 2 SYS U T1 SO R T S O R TW K nn Part 2 SO R T BUILD OUT BU ILD N P I1 IL D BU S YS REC3 Error/M ap N P I2 R ELO AD Part 3 key/R ID pairs SYS UT 1 SO R T S O RT W K nn S O RT BUILD O UT B U I PI Part 3 LD ke y/RID pa irs Error/Map SYS R EC 4 SYS U T1 SO RT SO R TW K nn S O RT B UILD O UT PI Part 4 R ELO AD Part 4 Figure 6-5 Parallel LOAD jobs per partition To avoid the contention problem. you have to recreate and REBUILD all the NPIs again. See Figure 6-6. but you could have contention problems on the NPIs. the contention problem on the NPIs is eliminated. 6.1 LOAD partitions in parallel When partitions can be loaded in parallel within a single job.In DB2 V5 or V6 you have to run LOAD jobs per partition in parallel to minimize the elapsed time. Because a single task will be building each NPI. 118 DB2 for z/OS and OS/390 Version 7 Performance Topics . You can now LOAD data into a partition table in parallel without building indexes in parallel. you no longer need to drop and recreate any of the NPIs. you have to drop all the NPIs. See Figure 6-5.2. and after running the LOAD utility.

Enhanced DISPLAY UTILITY() command output When the DISPLAY UTILITY() command is issued during the RELOAD phase. the keyword SORTKEYS is specified with an estimated value of 0. so you can start the necessary number of subtasks. it will display the total number of records that have been loaded into all partitions at the time the command is issued. or insufficient processors (CPUs) to handle more tasks. the keyword SORTKEYS is not specified. We recommend that you check the value of IDBACK and CTHREAD in ZPARM. The default estimated value for SORTKEYS is 0. it might not be possible to start the optimal number of subtasks. Chapter 6. the optimal approach would be to start one subtask for each partition to be loaded. In the LOAD job. The count will be 0 from the time the RELOAD phase starts until the first load subtask begins to load records into its first partition. if any one of the following conditions is true: There is only one index to be built. Utility performance 119 . However. DB2 will start the next available partition. if there are any partitions not yet being loaded. If fewer subtasks are started than there are partitions to be loaded.Erro r/Ma p S YS R EC 1 R ELOAD P art 1 PI BUILD S YS R EC 2 BU R E LOAD P art 2 IL D key/RID pairs S YS R E C3 R ELOAD S YS UT1 SOR T SORT O UT N PI1 BUILD Part 3 S OR T W K n n N PI2 S YS RE C4 R E LOAD P art 4 Figure 6-6 Partition parallel LOAD without building indexes in parallel Indexes will not be built in parallel when loading data into a partition table. one or more subtasks will load more than one partition. In the LOAD job. This constraint could arise from lack of sufficient virtual memory. When a subtask finishes with loading a partition. For loading partitions in parallel. insufficient available DB2 threads.

the status represents the status of the utility at its last checkpoint. the DSNU111I messages will not be issued. In addition.SUBPHASE = RELOAD COUNT = 18202 DSNU111I =DB2A DSNUGDIS . You can find information about how many subtasks the utility has started by looking at the SYSPRINT output from the LOAD utility. 120 DB2 for z/OS and OS/390 Version 7 Performance Topics . DSNU105I =DB2A DSNUGDIS . where you will find the following messages: DSNU364I DSNU397I DSNURPPL .SUBPHASE = RELOAD COUNT = 18202 DSNU111I =DB2A DSNUGDIS .SUBPHASE = RELOAD COUNT = 18202 DSN9022I =DB2A DSNUGCCC '-DIS UTIL' NORMAL COMPLETION *** Figure 6-7 DISPLAY UTILITY output Restriction: In a data sharing group. one DSNU111I message will be issued for each subtask.USERID = PAOLOR5 MEMBER = UTILID = LOADTS PROCESSING UTILITY STATEMENT 1 UTILITY = LOAD PHASE = RELOAD COUNT = 147456 NUMBER OF OBJECTS IN LIST = 1 LAST OBJECT STARTED = 1 STATUS = ACTIVE DSNU111I =DB2A DSNUGDIS .SUBPHASE = RELOAD COUNT = 18202 DSNU111I =DB2A DSNUGDIS . and you only have to run and maintain one job.SUBPHASE = RELOAD COUNT = 18202 DSNU111I =DB2A DSNUGDIS . you can benefit from running the LOAD utility in parallel.SUBPHASE = RELOAD COUNT = 24576 DSNU111I =DB2A DSNUGDIS . if the utility is running on a member other than the one to which the DISPLAY UTILITY() command is directed. instead of running and maintaining multiple jobs. NUMBER OF TASKS = 9 DSNURPPL .SUBPHASE = RELOAD COUNT = 24576 DSNU111I =DB2A DSNUGDIS .NUMBER OF TASKS CONSTRAINED BY CPUS When loading data into a partition table.SUBPHASE = RELOAD COUNT = 18202 DSNU111I =DB2A DSNUGDIS .Following a DSNU105I response to the DISPLAY UTILITY() command (see Figure 6-7). The message will give the activity that the subtask is performing at the time the DISPLAY UTILITY() command is issued and a count of the number of records processed in that activity.SUBPHASE = RELOAD COUNT = 18202 DSNU111I =DB2A DSNUGDIS .PARTITIONS WILL BE LOADED IN PARALLEL.

In the LOAD job. If fewer subtasks are started than there are partitions to be loaded. it might not be possible to start the optimal number of subtasks. or provide the necessary data sets yourself. if all of the following conditions are true: There is more than one index to be built. one or more subtasks will load more than one partition. with a non-zero estimate of the number of keys. However. DB2 will start the next available partition. or insufficient processors (CPUs) to handle more tasks. insufficient available DB2 threads. E rro r/M a p SYS REC1 R EL O AD P art 1 SORT B U IL D SW 01W Knn S W 0 1 W K xx S ORTBLD PI SYS REC2 R E L O AD Pa rt 2 SO RT B U IL D SOR TBLD SW 02W Knn S W 0 2 W K xx N P I1 S YS REC3 R EL O AD P a rt 3 SORT B UIL D SW 03W Knn S W 0 3 W K xx S ORTBLD N P I2 SYS REC4 R E L O AD P art 4 Figure 6-8 Partition parallel LOAD with indexes built in parallel The LOAD utility builds indexes in parallel. When a subtask finishes with loading a partition.2 Building indexes in parallel You can LOAD data into a partition table in parallel with indexes built in parallel. so you can start the necessary number of subtasks. too. the optimal approach would be to start one subtask for each partition to be loaded and two for each index to built.2.6. We recommend that you check the value of IDBACK and CTHREAD in ZPARM. one subtask to sort extracted keys while the other subtask builds the index. if there are any partitions not yet being loaded. You either allow the utility to dynamically allocate the data sets needed by SORT. See Figure 6-8. Chapter 6. Utility performance 121 . the keyword SORTKEYS is specified. This constraint could arise from lack of sufficient virtual memory. For loading partition in parallel.

the CPU time degrades up to 22.7% and the elapsed time improves up to 32. the CPU overhead is lower.7% +5. NUMBER OF TASKS DSNURPPL . this means that the keyword SORTKEYS was not specified or SORTKEYS was specified with an estimated value of zero. because SORTKEYS was not specified.2.7% Note: All times are in seconds. LOAD without SORTKEYS Table 6-1 summarizes the comparison of running the LOAD utility for the whole table with the LOAD utility running in parallel for all partitions.6% -32.1% -20. You only have to run and maintain one job.9% -4. by looking at the SYSPRINT output from the LOAD utility. NUMBER OF TASKS = 4 DSNURPPL . of indexes CPU time Elapsed time Parallel LOAD partition CPU time Elapsed time Delta % CPU time Elapsed time 1 index 2 indexes 3 indexes 6 indexes 599 1052 1411 2459 1087 1785 2187 3650 735 1106 1472 2573 734 1247 1730 3480 +22. When there are more than one index on a partition table.5 million rows Note: Without SORTKEYS.5% -30.3% +4.NUMBER OF TASKS CONSTRAINED BY CPUS When loading data into a partition table. even though managing the parallel subtasks for loading partitions in parallel contributes to an increase in CPU time.PARTITIONS WILL BE LOADED IN PARALLEL.1% +4. The following table is used: 26 columns with a total record length of 119 bytes 50 million rows 20 partitions. When loading partitions in parallel without building NPIs in parallel (without specifying SORTKEYS).3 Performance measurements All measurements were performed using an IBM G6 12-way processor and ESS disks. 122 DB2 for z/OS and OS/390 Version 7 Performance Topics . but without building NPIs in parallel. instead of running and maintaining multiple jobs and you do not have to drop and recreate NPIs to avoid contention problems.5%. and whether the indexes will be built in parallel. you can benefit from running the LOAD utility in parallel and by building the indexes in parallel. Table 6-1 LOAD in parallel without SORTKEYS LOAD whole table No.INDEXES WILL BE BUILT IN PARALLEL. With SORTKEYS. this means that the keyword SORTKEYS was specified with an estimated value greater than zero.You can find information about how many subtasks the utility has started. if there is only one index. 6. each partition has 2. Here you will find the following messages: DSNU395I DSNU364I = 7 DSNU397I DSNURPIB .

LOAD with SORTKEYS
Table 6-2 summarizes the comparison of running the LOAD utility for the whole table. The LOAD utility is running in parallel for all partitions and building NPIs in parallel by specifying SORTKEYS with an estimated value greater than 0.
Table 6-2 LOAD in parallel with SORTKEYS
LOAD whole table with SORTKEYS No. of indexes CPU time Elapsed time Parallel LOAD partition with SORTKEYS CPU time Elapsed time Delta % CPU time Elapsed time

1 index 2 indexes 3 indexes 6 indexes

656 1036 1398 2536

1393 1404 1737 2417

716 1175 1573 2835

722 982 998 1385

+9.1% +13.4% +12.5% +11.8%

-48.2% -30.1% -42.5% -42.7%

Note: All times are in seconds.

For tables without NPIs, the parallel partition LOAD with SORTKEYS improves up to 48.2% in elapsed time, compared to loading the whole table with SORTKEYS and with only 9.1% CPU time degradation. Managing the parallel subtasks to load partitions in parallel contributes to an increase in CPU time. When loading partitions in parallel and building NPIs in parallel (with SORTKEYS specified), the CPU time degrade up to 13.4% and the elapsed time improves up to 42.7%. Managing the parallel subtasks to load partitions in parallel and build NPIs in parallel contributes to an increase in CPU time.

Performance considerations
Table 6-3 summarizes the comparison of optimal performance for LOAD of a 20-partition table with only one index and 2.5 million rows per partition without SORTKEYS.
Table 6-3 Optimal performance for LOAD without SORTKEYS
LOAD whole table No. of indexes CPU time Elapsed time LOAD table with 20 jobs in parallel CPU time Elapsed time Parallel LOAD partition CPU time Elapsed time

1 index

599

1087

570

272

735

734

Note: All times are in seconds.

When loading partitions in parallel without specifying SORTKEYS, then the CPU and elapsed time will increase. The CPU time will increase due to managing the parallel subtasks per partition. The elapsed time will increase due to indexes being built in serial, and therefore, this takes a longer time. The elapsed time will also increase depending on the number of indexes to be built in serial. In this situation you cannot benefit from building NPIs in parallel, because there are no NPIs, only a partition index.

Chapter 6. Utility performance

123

Table 6-4 summarizes the comparison of optimal performance for LOAD of a 20-partition table with only one index and 2.5 million rows per partition with SORTKEYS specified.
Table 6-4 Optimal performance for LOAD with SORTKEYS
LOAD whole table with SORTKEYS No. of indexes CPU time Elapsed time LOAD table with 20 jobs in parallel with SORTKEYS CPU time Elapsed time Parallel LOAD parallel with SORTKEYS CPU time Elapsed Time

1 index

656

1393

661

256

716

722

Note: All times are in seconds.

The optimal performance for loading a 20-partition table with only one index is still obtained by running 20 LOAD jobs in parallel without SORTKEYS. It is the number of NPIs that are important. If there is only one index (partition index), then there are no NPIs, and you cannot benefit from building NPIs in parallel. However, if you are loading a table with more than one NPI, then always use SORTKEYS to improve performance of the LOAD utility and to benefit from building NPIs in parallel.

6.3 Online LOAD RESUME
The new online LOAD RESUME capability allows loading of data concurrently with user transactions with minimal impact, by introducing a new LOAD option: SHRLEVEL NONE or SHRLEVEL CHANGE. SHRLEVEL NONE specifies that LOAD operates as in previous releases with no user access to the data during the LOAD. SHRLEVEL CHANGE allows users to have read and write access to the data during LOAD. SHRLEVEL CHANGE is valid only in conjunction with LOAD RESUME YES and will functionally operate like SQL inserts. The index building, duplicate key, and referential constraint checking will be handled by SQL insert processing. The execution records which fail the insert will be written to the DDNAME specified by the DISCARDDN option. SHRLEVEL CHANGE is incompatible with: LOG NO ENFORCE NO KEEPDICTIONARY SORTKEYS STATISTICS COPYDDN RECOVERYDDN PREFORMAT REUSE PART REPLACE Online LOAD RESUME does not put the table space in CHECK pending or COPY pending status.

124

DB2 for z/OS and OS/390 Version 7 Performance Topics

Online LOAD RESUME cannot run concurrently on the same target object with online REORG SHRLEVEL CHANGE. But it can run concurrently on the same target object with the following utilities: COPY SHRLEVEL CHANGE MERGECOPY RECOVER ERROR RANGE CONCURRENT COPY SHRLEVEL REFERENCE after copy is logically completed RUNSTATS SHRLEVEL CHANGE Online LOAD RESUME YES cannot run against a table space that is in COPY pending, CHECK pending or RECOVER pending status. Likewise, it cannot run against an index space that is in CHECK pending or RECOVER pending status.

Consequences of INSERT processing
These are the consequences of INSERT processing: Triggers are activated. Referential integrity (RI) will be checked.

Data Manager rather than RDS INSERT
The difference here is that the Data Manager will not generate the full range of INSERT statements: The SQL overhead is omitted.

Lock contention is avoided
DB2 manages the commit scope, dynamically monitoring the current locking situation.

Clustering
Whereas the classic LOAD RESUME stores the new records (in the sequence of the input) at the end of the already existing records; the new online LOAD RESUME tries to insert the records in available free pages as close to clustering order as possible; additional free pages are not created. As you probably insert a lot of rows, these are likely to be stored out of the clustering order (OFFPOS records). REORG may be needed after the classic LOAD, as the clustering may not be preserved, but also after the new online LOAD RESUME, as OFFPOS records may exist. A RUNSTATS with SHRLEVEL CHANGE UPDATE SPACE followed by a conditional REORG is recommended.

Free space
Furthermore the free space, obtained either by PCTFREE or by FREEPAGE, is used by these INSERTs of the Online LOAD RESUME - in contrast to the classical LOAD, which loads the pages thereby providing these types of free space. As a consequence, a REORG may be needed after an Online LOAD RESUME.

6.3.1 Performance measurements
All measurements were performed using an IBM G6 3-way processor and ESS disks. The following table was used: 10-partition table 1 partition index 1 NPI

Chapter 6. Utility performance

125

Table 6-5 summarizes the comparison of a user application program inserting rows in random with Online LOAD RESUME. See Appendix D, “Sample PL/1 program” on page 223 for more information about the user application used for this test.
Table 6-5 Inserting 2000000 rows
Inserting 2,000,000 rows via program Online LOAD RESUME 2,000,000 rows Delta %

CPU time Elapsed time Note: All times are in seconds.

241 326

171 256

-29.0% -21.5%

Using Online LOAD RESUME to insert rows in a table can be up to 21,5% faster in elapsed time than using a user application and even the CPU time is improved up to 29%. When using the Online LOAD RESUME instead of a user application, you avoid the cost of developing and maintaining a user application. Another advantage is that Online LOAD RESUME automatically monitors the lock situation and changes the commit interval dynamically. Table 6-6 summarizes the comparison of running 10 parallel jobs inserting 2,000,000 rows with different buffer pool definitions for the buffer pool containing the NPI.
Table 6-6 10 parallel jobs inserting 2,000,000 rows with different buffer pool definitions
10 jobs inserting 2,000,000 rows in parallel BP3=5,000 pages 10 jobs inserting 2,000,000 rows in parallel BP3=40,000 pages

Delta %

CPU time Elapsed time Note: All times are in seconds.

268 548

261 225

-2.6 % -58.9 %

The effect of tuning the buffer pool used for NPIs, shows that the elapsed time can be reduced with up to 58.9% and the CPU time reduced up to 2.6%. Table 6-7 summarizes the comparison of running Online LOAD RESUME in parallel with different buffer pool definitions for the buffer pool containing the NPIs.
Table 6-7 Running Online LOAD RESUME in parallel with different buffer pool definitions
Parallel partition Online LOAD RESUME into 10 partitions BP3=5,000 pages Parallel partition Online LOAD RESUME into 10 partitions BP3=40,000 pages

Delta %

CPU time Elapsed time Note: All times are in seconds.

196 916

217 229

+10.7 % -75.0 %

Running Online LOAD RESUME in parallel can benefit from tuning the buffer pool used for NPIs. This test shows that the elapsed time can be reduced with up to 75.0%, and in this situation, the CPU time increased up to 10.7%.

126

DB2 for z/OS and OS/390 Version 7 Performance Topics

6.3.2 Performance considerations
As the new online LOAD RESUME internally works like SQL INSERTs, this kind of LOAD is slower than the classic LOAD. In some situations you may be willing to trade off performance for availability, especially for data warehouse applications, where queries may run for several hours. The new online LOAD RESUME can take advantage of running in parallel, when loading partitions. The classic LOAD utility drains the table space, so no one can access the table space while loading. The LOAD RESUME uses claim instead, and that allows others to access the table space while loading. Online LOAD RESUME SHRLEVEL CHANGE will place the new data in available free pages as close to clustering order as possible; additional free pages are not created. It is recommended to run RUNSTATS with SHRLEVEL CHANGE UPDATE SPACE followed by conditional REORG after online LOAD RESUME YES.

6.3.3 Performance recommendations
Parallel Online LOAD RESUME and parallel insert have similar performance characteristics in terms of I/O and elapsed time. Parallel Online LOAD RESUME or parallel insert compared to sequential operation may be impacted by I/O for a non-partitioning index data set. In order to benefit from parallel operation, both in Online LOAD RESUME and in insert, the following performance tuning recommendations to minimize non-partitioning index I/O bottlenecks are suggested: Bigger buffer pool for NPIs to improve buffer pool hit ratio Higher deferred write threshold to reduce the number of pages written Bigger checkpoint interval to reduce the number of pages written ESS PAV (Parallel Access Volume) to support multiple concurrent I/O to the same volume containing non-partitioning index data set(s) Non-partitioning index pieces to support multiple concurrent non-partitioning index I/Os

6.4 UNLOAD utility
DB2 V6 introduced the option to unload data in external format in the REORG utility. DB2 V7 introduces a new UNLOAD utility with a better performance and functionality than REORG UNLOAD EXTERNAL. The new UNLOAD utility gives you more options when unloading data, and allows you to unload data from COPY data sets, including inline image copy from LOAD and REORG TABLESPACE, MERGECOPY and DSN1COPY. See Figure 6-9.

Chapter 6. Utility performance

127

128 DB2 for z/OS and OS/390 Version 7 Performance Topics . each defined as INTEGER Note: All measurements were performed using an IBM G5 3-way processor and with 4 channels on ESS. The following tables are used during the tests: 1 million row table with 50 columns. limitation of rows General conversion options: encoding scheme. formatting single data set Partition parallelism data set for part1 data set for part2 Figure 6-9 UNLOAD enhanced functionality Support for exits Delimited output and user exits are not supported. Unload does support EDITPROC and FIELDPROC definitions. each defined as CHAR(4) 1 million row table with 50 columns. positioning.UNLOAD REORG UNLOAD EXTERNAL created by: COPY MERGECOPY DSN1COPY table space FROM TABLE selection Row selection External format numeric date / time copy data set SHRLEVEL REFERENCE / CHANGE Sampling. ordering.4. format Formatting NOPAD for VARCHAR length.1 Performance measurements Figure 6-10 shows the performance improvements of the new UNLOAD utility compared to REOG UNLOAD EXTERNAL. null field Field list: selecting. each defined as DECIMAL 1 million row table with 50 columns. 6.

03 GB when unloaded The difference between the size of the partition and the unloaded data set is due to VARCHAR columns.82 GB per partition and 1. and this requires at least 2 channels per CPU to avoid channel contention.4. Chapter 6.G5 CPU time (sec) 1 million rows 25 20 15 10 5 0 CHAR DEC INT Reorg Unload Figure 6-10 New UNLOAD utility versus REORG EXTERNAL UNLOAD The improvement shows a 15% to 18% reduction of the CPU time.2 Unloading partitions in parallel When unloading a partitioned table space into individual data sets (1 per partition). The following table is used during the tests: 6 million rows per partitions Table with 16 columns per row 0. there was no reduction of the elapsed time. Utility performance 129 . Note: All measurements are performed using an IBM 7-way G6 processor. the UNLOAD utility automatically activates multiple subtasks and runs in partition/parallel unload mode. 6. Performance measurements Figure 6-11 shows the performance measurements of unloading partitions in parallelism. Because the UNLOAD utility is I/O bound.

The increase in elapsed time is due to handling more subtasks and partitions. because the UNLOAD utility could only start 7 subtasks. Note: The maximum number of subtasks will be determined by the number of CPU available on which the UNLOAD job runs and depends on how many threads DB2 allows you to start.NUMBER OF TASKS CONSTRAINED BY CPUS When you UNLOAD data from a partitioned table.Elapsed time (sec) 250 200 191 150 100 86 86 89 50 0 1 4 7 14 Number of partitions Figure 6-11 Unloading partition table in parallelism The elapsed time for unloading 1 to 4 partitions is the same. We recommend that you check the value of IDBACK and CTHREAD in ZPARM. The elapsed time for unloading 1 or 7 partitions in parallel is almost the same. when unloading 7 partitions in parallel. There is no extra cost in elapsed time for unloading the 3 extra partitions. instead of running and maintaining many jobs. 130 DB2 for z/OS and OS/390 Version 7 Performance Topics . You can find information about how many subtasks the utility has started by looking at the SYSPRINT output from the UNLOAD utility. The elapsed time only increase a little bit. Thus you only have to run and maintain one job. which have to unload more than one partition each and the overhead to handle more partitions than subtasks increased too. where you will find the following messages: DSNU1201I DSNU397I DSNUUNLD . you can benefit from running the UNLOAD utility in parallel. NUMBER OF TASKS = 3 DSNUUNLD .PARTITIONS WILL BE UNLOADED IN PARALLEL. The elapsed time for unloading 14 partitions in parallel shows that the elapsed time is more than double.

DATA.5 Online REORG enhancements The DB2 V7 enhancements to online REORG for improving performance and high availability. You can unload the data even if the table space is stopped. DSNU050I DSNUGUTC .OR2 DSNU252I DSNUUNLD .T2036 DSNU1038I DSNUGDYN . Utility performance 131 . 6. you can see that parallelism is not activated when you unload data from an image copy data set.DATASET ALLOCATED. See Figure 6-12.UNLOAD TABLESPACE DB246129. data is unavailable from the last part of the LOG phase and during the SWITCH and BUILD2 phases. HIGHEST RETURN CODE=4 Figure 6-12 UNLOAD utility In the output from the UNLOAD utility. the latter way is more secure. that is. supports copy data sets as a source for unloading data.P00000. if columns are added to the source table.D1110.TS612903 DSNU1252I =DB2A DSNUULIA . See Figure 6-13.4.UNLOAD PHASE COMPLETE. some use DSN1COPY to refresh a table space in the target DB2 subsystem from a copy of the source DB2 subsystem.NUMBER OF RECORDS UNLOADED=800 FOR TABLE PAOLOR7. as the DSN1COPY procedure has to be maintained with care.UNLOAD PHASE STATISTICS .TS612903 DSNU250I DSNUUNLD .UNLOAD PHASE STATISTICS .D1110.PUNCH.DATASET ALLOCATED.3 Unload from copy data sets These are the advantages when unloading from copy data sets: You do not touch the user data in the table space. TEMPLATE=OR2DATA DDNAME=SYS00002 DSN=PAOLOR5.PARTITION PARALLELISM IS NOT ACTIVATED AND THE PARTITION VARIABLE IN THE TEMPLATE DSN WAS REPLACED BY '00000' FOR TABLESPACE DB246129. When running the Online REORG TABLESPACE utility. Prerequisite: Existence of table space The UNLOAD utility.UTILITY EXECUTION COMPLETE.6.DB246129.TS612903. For regularly transferring data into another DB2 subsystem. introduce a faster SWITCH phase. This specified table space must still exist when the UNLOAD utility is running. a new BUILD2 phase for building NPI in parallel and new DRAIN and RETRY parameters.TS612903.NUMBER OF RECORDS UNLOADED=800 FOR TABLESPACE DB246129. Chapter 6. for example. TEMPLATE=OR2PUNCH DDNAME=SYS00003 DSN=PAOLOR5. you can transfer exactly these rows and columns you need.T2036 DSNU253I DSNUUNLD . therefore you do not degrade the performance of the SQL applications. Using UNLOAD and LOAD instead. in one UNLOAD statement.IC013 UNLDDN OR2DATA PUNCHDDN OR2PUNCH DSNU1038I DSNUGDYN . the table space has not been dropped since the copy was taken. The table space must be specified in the TABLESPACE option.TS612903.P00000. ELAPSED TIME=00:00:00 DSNU010I DSNUGBAC .TS612903 DSNU650I =DB2A DSNUUGMS FROMCOPY PAOLOR5. Moreover.

the data sets with ‘T0001’ are deleted. Others use partitioned table spaces with some hundred partitions. ‘I0001’ is renamed to a temporary one. During the last log iteration and during the BUILD2 phase. In the UTILTERM phase. and whether the rename was successful. Notes: This description applies to DB2-managed table spaces. one for each data set of the original objects (or their partitions). the instance node of the original data sets. as these shadow objects are not reflected in the catalog. ‘T0001’. for checking whether the new name exists already. also referred to as the instance node. concentrating on the data sets. afterwards. In the UTILINIT phase. DB2 renames the original data sets and the shadow data sets. For the renaming. several hundred data sets (both cluster and data component of the VSAM data set) must be renamed in the SWITCH phase. is S0001’ rather than ‘I0001’. Some applications design DB2 tables with several hundred indexes. AMS invokes MVS supervisor calls (SVCs) which result in further cascading SVCs.R E A D /W R IT E A C C E S S TO LER ATED D A TA U N A V A IL A B IL IT Y U n lo a d R e lo a d S o rt B u ild U n lo g d L a S w itc h B u ild 2 Figure 6-13 Data unavailability when running REORG SHRLEVEL CHANGE With a faster SWITCH phase and a new BUILD2 phase for building NPI in parallel. In turn. the fifth qualifier of the shadow data set. SQL accesses are also limited. the time when data is unavailable during Online REORG TABLESPACE utility has been minimized. Strictly speaking. shadow objects of the table space (or its partitions) and for the index spaces (or their partitions) are created. What it means is. is renamed to ‘I0001’.5. In the SWITCH phase. The data set names of these shadow data sets differ from the original data set names insofar as their fifth qualifier. 132 DB2 for z/OS and OS/390 Version 7 Performance Topics . ‘S0001’. 6. so applications may time out. this is not true. as they are not needed any more. DB2 invokes Access Method Services (AMS). Let us look at how online REORG works prior to DB2 V7. that new shadow data sets are created. for example.1 Fast switch The SWITCH phase prior to DB2 V7 could take a long time. In both cases. More specifically.

d. DB2 queries the OBD of the object being reorganized in the UTILINT phase in order to check. Utility performance 133 . whether or not they want Fast SWITCH as your default processing option for online REORGs. DB2 deletes the obsolete original data sets with the instance node ‘I0001’. Thus the default is to exploit the Fast SWITCH feature. is ‘1’ when DB2 V7 is installed. In the SWITCH phase. In the UTILTERM phase. As a result. b.Therefore. An optional process. During that time. thus making the phase less intrusive to data access by others: Invocation of AMS to rename the data sets is eliminated. the applications are less likely to time out. they may time out because of the online REORG. As the data set names of a table space now vary. the FASTSWITCH. The default value for the new ZPARM parameter. the applications can resume their processing. now on the new ‘J0001’ data sets. If the data sets are SMS controlled you need to change the ACS routines to accommodate the new DB2 naming standard and take advantage of the enhancement. the elapsed time for the SWITCH phase can become too long. the SWITCH phase is much shorter. The fifth qualifier of these data sets is now ‘J0001’. You can always override the ZPARM default at the utility level by using the new keyword for the REORG SHRLEVEL REFERENCE/CHANGE utility FASTSWITCH NO/YES. In the UTILINIT phase. If the current data base object has a ‘J0001’ instance node then DB2 will create a shadow object with an ‘I0001’ instance node. Thus. ‘&SPRMURNM’ in the Macro DSN6SPRC. you can reset this ZPARM to ‘0’. whether the current instance node is ‘I0001’ or ‘J0001’. which is exactly what you are trying to avoid. The UTILTERM phase then deletes the data base objects with the ‘J0001’ instance node. Notes: You can only use FASTSWITCH NO for DB2 catalog and directory. indicating that the AMS rename is the default processing for online REORGs. therefore. Specifying whether Fast SWITCH is the default You can choose at installation level. takes place: a. Performance measurements All measurements were performed using an IBM G6 3-way processor and ESS disks. As the applications cannot access the table space during that time. Notes: This description applies to DB2-managed table spaces. the old originals. applications cannot access the table space. c. The following table space is used: 254 partitions table space STOGROUP defined 1 partition index Chapter 6. At installation time. DB2 creates shadow data sets. during the SWITCH phase. the OBD and the DB2 catalog are updated registering the ‘I0001’ object as the active data base object. After the SWITCH phase. DB2 updates the catalog and the object descriptor (OBD) from ‘I’ to ‘J’ to indicate that the shadow object has become the active or valid data base object. DB2 V7 gives an alternative to speed up the SWITCH phase.

If the table space being reorganized has five NPIs.05 seconds. one subtask will perform updates for all logical partitions on the same NPI. The elapsed time for switching a data set is very constant. one or more subtasks will update more than one NPI. When a subtask finishes with a NPI. In this test case. There is a 92% reduction in elapsed time and no change in the CPU time by using the new FASTSWITCH functionality. insufficient available DB2 threads. We recommend that you use the new FASTSWITCH functionality. so you can benefit from using the faster switch phase and that without you have to change your existent Online REORG jobs. If fewer subtasks are started than there are NPIs to update. The updates of NPIs are now done using parallelism. This constraint could arise from lack of sufficient virtual memory. one or more subtasks are dispatched to perform the updates. It might not be possible to start the optimal number of subtasks. That gives you availability improvement and better performance in reducing elapsed time. The subtasks will update the original logical partition.5.2 BUILD2 parallelism for NPIs DB2 V7 improves the elapsed time of the BUILD2 phase of the REORG SHRLEVEL(CHANGE) or SHRLEVEL(REFERENCE) utility when reorganizing a single partition or a range of partitions. The number of parallel subtasks is governed by: Number of CPUs Number of available DB2 threads Number of NPIs Optimally. the total number of data sets switched was 508 (254 table space partitions and 254 index partitions). it will start the next available NPI. 134 DB2 for z/OS and OS/390 Version 7 Performance Topics . With parallelism. When the REORG utility executes to operate on a range of partitions. then possibly five subtasks will be started. Each subtask will be assigned an original NPI and the shadow copy of logical partition. if you have one subtask for each NPI. and that was done in 28 seconds. and it is about 0.Table 6-8 summarizes the comparison of running the Online REORG utility using FASTSWITCH NO with the Online REORG utility using FASTSWITCH YES. more specifically. on one partition only or on a range of partitions only The BUILD2 phase has been improved by updating of NPIs using parallel subtasks. The BUILD2 phase applies when you do a REORG: With SHRLEVEL CHANGE or SHRLEVEL REFERENCE Only on a subset of the partitions of a partitioned table space. 6. if there are any NPIs not yet being updated. the elapsed time of the BUILD2 phase could be the time it takes to process the NPI with the most RIDs. Table 6-8 Online REOG using FASTSWITCH REORG FASTSWITCH NO SHRLEVEL CHANGE CPU time Switch Elapsed time REORG FASTSWITCH YES SHRLEVEL CHANGE CPU time Elapsed time Delta % CPU time Elapsed time 1 349 1 28 0% -92% Note: All times are in seconds. or insufficient processors (CPUs) to handle more tasks.

inline COPY Running REORG against one partition of a partition table space with only one NPI shows the improvement of the BUILD2 phase in a worst case scenario. This improvement. which is always conditioned by the concurrent activity. Utility performance 135 . Measurements with one partition index and one NPI All measurements were performed using an IBM G6 3-way processor and ESS disks.Performance measurements The BUILD2 phase is only activated when running Online REORG with SHRLEVEL REFERENCE or CHANGE and when running REORG against one partition or a range of partitions and non-partitioning indexes. In this worst case scenario. each partition has 1 million rows 1 partition index 1 NPI Measurements of reorganization of one partition Table 6-9 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL REFERENCE. NOSYSREC and inline COPY with the DB2 V7 REORG utility. The following table is used: 26 columns with a total record length of 119 bytes 20 millions rows 20 partitions. obtained when there is no multitasking of NPIs. During the measurements there are no updates going on. NOSYSREC. NOSYSREC. SORTKEYS. the intent being to show the best possible availability enhancement provided by the change in this phase of the utility. is due to other internal enhancements in the handling of log writes. Chapter 6. Table 6-10 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL CHANGE. SORTKEYS. the BUILD2 phase shows an improvement in elapsed time of 35% in elapsed time with an improvement in CPU time of 29%. REORG witH SHRLEVEL CHANGE. REORG with SHRLEVEL REFERENCE. It is also not meaningful to show the statistics for the overall online REORG execution. Table 6-9 BUILD2 — example 1 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 62 69 44 45 -29% -35% Note: All times are in seconds. SORTKEYS. inline COPY. NOSYSREC and inline COPY with the DB2 V7 REORG utility. therefore there are no measurements of running REORG with SHRLEVEL NONE and running REORG on all partitions of a partition table space. Table 6-10 BUILD2 — example 2 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 63 69 44 45 -30% -35% Note: All times are in seconds. SORTKEYS.

Table 6-11 BUILD2 — example 3 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 166 176 111 112 -33% -36% Note: All times are in seconds. and CPU time of 30%. the BUILD2 phase shows an improvement in elapsed time of 37%. inline COPY. Running REORG against a range of partitions (three in this case) of a partition table space with only one NPI shows the improvement of the BUILD2 phase in a worst-case scenario. Table 6-12 BUILD2 — example 4 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 168 177 110 111 -34% -37% Note: All times are in seconds. shows the improvement of the BUILD2 phase in a worst case scenario. 20 partitions. the BUILD2 phase shows an improvement in elapsed time of 35. and the CPU time is improved by 33%. Measurements with one partition index and five NPIs All measurements were performed using an IBM G6 3-way processor and ESS disks. SORTKEYS. SORTKEYS. Measurements of reorganizations of three partitions Table 6-11 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL REFERENCE. The following table is used: – – – – – 26 columns with a total record length of 119 bytes. In this worst case scenario. Running REORG against a range of partitions (in this case. 1 partition index 5 NPI 136 DB2 for z/OS and OS/390 Version 7 Performance Topics . NOSYSREC. SORTKEYS. and inline COPY with the DB2 V7 REORG utility. NOSYSREC. REORG 3 partitions with SHRLEVEL REFERENCE. when reorganizing the first 3 partitions. NOSYSREC. In this worst-case scenario. when reorganizing the first 3 partitions. SORTKEYS. the BUILD2 phase shows an improvement in elapsed time of 36%. 20 millions rows. Table 6-12 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL CHANGE.Running REORG against one partition of a partition table space with only one NPI. NOSYSREC. REORG 3 partitions with SHRLEVEL CHANGE. inline COPY. In this worst case scenario. shows the improvement of the BUILD2 phase in a worst case scenario. three partitions) of a partition table space with only one NPI. and inline COPY with the DB2 V7 REORG utility. each partition has 1 million row. and in CPU time of 34%.

NOSYSREC. Chapter 6. The BUILD2 phase in DB2 V7 improves the elapsed time by 82% and the CPU time by 25%. inline COPY. SORTKEYS. and inline COPY with the DB2 V7 REORG utility. The BUILD2 phase in DB2 V7 improves the elapsed time by 83% and the CPU time by 29%. inline COPY. NOSYSREC.Table 6-13 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL REFERENCE. Table 6-16 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL CHANGE. NOSYSREC. inline COPY. NOSYSREC. Table 6-14 BUILD2 — example 6 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 307 333 237 62 -23% -81% Note: All times are in seconds. SORTKEYS. and inline COPY with the DB2 V7 REORG utility. NOSYSREC. when reorganizing the first three partitions. and inline COPY with the DB2 V7 REORG utility. The BUILD2 phase in DB2 V7 improves the elapsed time by 81% and the CPU time by 23%. SORTKEYS. REORG with SHRLEVEL CHANGE. REORG with SHRLEVEL REFERENCE. NOSYSREC. Table 6-15 BUILD2 — example 7 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 822 872 581 150 -29% -83% Note: All times are in seconds. Measurements of reorganizations of three partitions Table 6-15 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL REFERENCE. Table 6-13 BUILD2 — example 5 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 310 335 233 60 -25% -82% Note: All times are in seconds. REORG with SHRLEVEL REFERENCE. and inline COPY with the DB2 V7 REORG utility. Utility performance 137 . SORTKEYS. when reorganizing the first three partitions. SORTKEYS. SORTKEYS. Table 6-14 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility using SHRLEVEL CHANGE. NOSYSREC. SORTKEYS. Managing the parallel subtasks for building the five NPIs has reduced the improvement in CPU time.

to enable RUNSTATS to update more information about space.5. and with up to 29% in CPU time in the case of five NPIs. so you can use them for analysis. These measurements show that the BUILD2 phase has been improved with up to 83% in elapsed time.3 DRAIN and RETRY When executing an Online REORG utility. allows you to force the roll up of statistics to aggregate tables. tools support and input for optimizer hints. a new drain specification statement can be added. 138 DB2 for z/OS and OS/390 Version 7 Performance Topics . the larger the improvement of the BUILD2 phase will be. Managing the parallel subtasks to building the five NPIs in parallel. inline COPY.6 RUNSTATS enhancements DB2 V7 has a new parameter for the RUNSTATS utility that allows you to gather RUNSTATS information into history catalog tables. A new keyword FORCEROLLUP. has contributed to an increase in CPU time. IRLMRWT. This new specification offers granularity at REORG invocation level rather than at DB2 subsystem level. both for REORG INDEX and REORG TABLESPACE. DRAIN_WAIT – Specifies the maximum number of seconds that the utility will wait when draining. and the multiplier Utility Time-out. The improvements of the BUILD2 phase depend on the number of NPIs on the partitioned table space that the Online RORG utility runs against. The higher the number of NPIs are. you can still expect an improvement in the BUILD2 phase up to 37% in elapsed time. UTIMOUT. REORG with SHRLEVEL CHANGE. NOSYSREC. Some DB2 catalog tables has been changed. 6. SORTKEYS. and up to 34% in CPU time. RETRY_DELAY – Works in conjunction with RETRY and specifies the minimum duration in seconds between retries. 6. overriding the utility locking time-out value specified at subsystem level in the DSNTIPI installations panel with the values for Resource Time-out. even if any partitions are empty.Table 6-16 BUILD2 — example 8 DB2 V6 CPU time BUILD2 Elapsed time DB2 V7 CPU time Elapsed time Delta % CPU time Elapsed time 825 874 587 152 -29% -83% Note: All times are in seconds. If you only have one NPIs on a partitioned table space. The BUILD2 phase in DB2 V7 improves the elapsed time by 83% and CPU time by 29%. RETRY Specifies the maximum number of times that the drain will be attempted. A shorter wait reduces the impact on applications and can be combined with retries to increase the chances of completing the REORG execution.

SYSTABSTATS_HIST Note: If you are dropping an object. ACCESSPATH. This is the default for the STATHIST parameter. – NPAGESF is the number of pages in the table space or index at the time of INLINE COPY.SYSCOLUMNS_HIST SYSIBM.SYSTABLES_HIST SYSIBM. all the information in the history tables will be deleted too. 139 Chapter 6.2 DB2 catalog changes In the DB2 catalog.6. You should run MODIFY STATISTICS regularly to clear outdated information from the statistics history catalog tables.6. you can help improve performance for processes that access data from these tables. or NONE. new columns have been added to the following tables: SYSCOPY: – COPYPAGESF is the number of pages written to the copy data set.SYSLOBSTATS_HIST SYSIBM.SYSINDEXSTATS_HIST SYSIBM.SYSCOLDIST_HIST SYSIBM.SYSINDEXES_HIST SYSIBM. – CPAGESF is the number of changed pages.6. You can overwrite the default value for STATISTIC HISTORY at RUNSTATS level by specifying the keyword HISTORY and the level you want: ALL. Utility performance . ACCESSPATH specifies that all inserts/updates made by DB2 to ACCESSPATH related catalog statistics are recorded in catalog history tables. ALL specifies that all inserts/updates made by DB2 in the catalog are recorded in catalog history tables. Performance measurements The cost of collecting history information depends on the type of information you are collecting and how the object are defined (for example. number of indexes and columns).SYSINDEXPART_HIST SYSIBM. The STATISTICS HISTORY will save the data in the following new DB2 catalog tables: SYSIBM. NONE specifies that changes made in the catalog by DB2 are not recorded in catalog history tables.1 Statistics history You can set up a default value for STATISTIC HISTORY by setting the value of STATHIST in ZPARM. SPACE. This statistic is needed by RECOVER utility to know the number of pages in the image data set (full/incremental). 6. The value of STATHIST can be: SPACE specifies that all inserts/updates made by DB2 to space related catalog statistics are recorded in catalog history tables. However. Delete history statistics The MODIFY STATISTICS online utility deletes unwanted statistics history records from the corresponding catalog tables. By deleting outdated information from these tables.SYSTABLEPART_HIST SYSIBM. the increase of elapsed time and CPU time will be less than 5%.

The value is -1 if statistics have not been gathered. The value is -1 if statistics have not been gathered. The value is -1 if statistics have not been gathered.The value is -1 if statistics have not been gathered. SYSTABLES: – NPAGESF is the number of pages used by the table. – DSNUM is the number of data sets. 140 DB2 for z/OS and OS/390 Version 7 Performance Topics . The value is -1 if statistics have not been gathered. If the table space is not compressed. The value is -1 if statistics have not been gathered. SYSTABLEPART: – SPACEF is the number of kilobyte disk allocated to the table space partition. – DSNUM is the number of data sets. The value is -1 if statistics have not been gathered. If the table space is compressed. SYSINDEXPART: – SPACEF is the number of kilobytes of disk allocated to the index partition.– JOBNAME is the value in this column indicates the job name of the utility. The value is -1 if statistics have not been gathered. – LEAFFAR is the number of leaf pages located physically far away from previous leaf pages for successive (active leaf) pages accessed in an index scan. the value is the uncompressed row length. the value is the compressed row length. – SPACEF is the number of kilobytes of disk allocated to the table. – EXTENTS is the number of data set extents. For an unique index the value is the number of both keys and RIDs that are pseudo deleted. The value is -1 if statistics have not been gathered. – LEAFNEAR is the number of leaf pages physically near previous leaf page for successive active leaf pages. – PSEUDO_DEL_ENTRIES is the number of pseudo deleted entries in the index. – EXTENTS is the number of data set extents. The value is -1 if statistics have not been gathered. For a non-unique index. The value is -1 if statistics have not been gathered. These entries are marked as “logically” deleted but still physically remain in the index. the value is the number of RIDs that are pseudo deleted. SYSINDEXES: – SPACEF is the number of kilobytes of disk allocated to the index. – AVGROWLEN is the average length of rows for the tables in the table space. – AUTHID is the value in this column indicates the authorization ID of the utility.The value is -1 if statistics have not been gathered. The value is -1 if statistics have not been gathered.

is was 119. We recommend.6. Recalculate space allocation The maximum number of extents are now 251 with DFP 1. even if some partitions are empty. Determine when to gather statistics again. there are access path or optimizer statistics. Prior to DB2 V7 aggregation took place only if statistics were available for all the partitions. Determine when to reorganize. In DB2 V7 you have the option to force the roll up of statistics to aggregate tables. When the number of EXTENTS in SYSTABLEPART or SYSINDEXPART is greater than 50. and help tune the setting of PCTFREE and FREEPAGE. Second. This is a major area using different statistics to decide for different types of objects. Chapter 6. however newer devices mitigate performance penalties seen on older devices. where some of the partitions are empty. These are used by the optimizer to select the best access path to the data. as RUNSTATS does prior to DB2 V7.Then you do not have to change any of your RUNSTATS job to take advantage of forcing statistics roll up to aggregate tables. First. there are space statistics.This will help the optimizer to choose a better access path. 6. The statistics that are collected at the partition level are aggregated into the aggregate tables.6. NO specifies no statistic roll up for partitions tables and indexes where some of the partitions are empty. the RUNSTATS issued a DSNU623I message to indicate that aggregation were not successful. Space statistics are used to: Determine the optimum primary and secondary allocations used for table spaces and indexes. You can set up a default value for FORCEROLLUP by setting the value of STATROLL in ZPARM. This is the default for the STATROLL parameter. Utility performance 141 . If statistics were not available for any partition. The value of STATROLL can be overridden at RUNSTATS level. by specify the keyword FORCEROLLUP and YES or NO.6. the statistics that are collected at the individual part level for an index is stored in SYSINDEXPART and these statistics are rolled up to the aggregate table SYSINDEXES. For example. It is still a performance consideration during open and close. that the value for STATROLL in ZPARM is set to YES especially if some of the partitions are empty.4 Performance considerations using new statistics columns Statistics collected by RUNSTATS can be divided into two major categories. but should be kept below 50 extents. Multiple extents are not a big performance concern. The value of STATROLL can be: YES forces statistic roll up for partitions tables and indexes. for DB2 systems that have large partitioned table spaces and indexes.3 Force update of aggregate statistics RUNSTATS gathers statistics for all partitions specified for table space or index space. we recommend that you alter the PQTY and/or SQTY to reduce the number of extents and run REOG without the REUSE keyword to ensure the new space allocation are used. Before.4.

so an I/O can be avoided when fetching the data row. but both values indicate disorganization of the data. Rows outside the range probably required a synchronous I/O to get the row. The more I/O needed.Maintain the clustering sequence The statistics measuring clustering are CLUSTERATIO. See Figure 6-14. After reorganization. and FAROFFPOS in SYSINDEXPART. then REORG is performed. We recommend that you run REORG TABLESPACE. You can calculate the percentage of rows that are off-position based on the values of FAROFFPOS and CARDF in SYSINDEXPART: (FAROFFPOS)/CARDF)*100 You can then determine if you should run REORG TABLESPACE to maintain the clustering sequence. TS R3 C lust er ing IX TS R1 R2 R3 R4 K1 K2 deleted K3 K4 R2 R4 d eleted R1 d eleted p re fe tc h fa c to r Figure 6-14 Clustering sequence NEAROFFPOS is the number of rows in a non-optimal position. the CLUSTERATIO approaches 100%. the REOG utility will calculate: ((NEAROFFPOS+FAROFFPOS)/CARDF)*100 The result of this calculation will be compared with the value specified for the OFFPOSLIMIT keyword. FAROFFPOS is 0 and NEAROFFPOS is 0 or a relatively low value. FAROFFPOS is the number of rows outside this range. The FAROFFPOS value is more significant and likely to affect performance than the NEAROFFPOS value. CLUSTERATIO is 50%. the slower the scan. 142 DB2 for z/OS and OS/390 Version 7 Performance Topics . that can lead to performance degradation. If the calculated value exceeds the specified value of OFFPOSLIMIT. With random data ordering. The number of a data rows being near versus far off in position relates to the number of pages included in the prefetch quantity within DB2. but within the range of 16 pages. When using the OFFPOSLIMIT keyword for REORG TABLESPACE. NEAROFFPOS. then an optimal row (or near optimal) is probably already in a buffer. If 32 or 64 pages are read in during prefetch. if the percent of off-position rows is greater than 10%. With ideal clustering after reorganization. and that is measured by off-position rows.

For instance. the REOG utility will calculate: ((NEARINDREF+FARINDREF)/CARDF)*100 The result of this calculation will be compared with the value specified for the INDREFLIMIT keyword. and the page is full. FARINDREF and CARDF in SYSTABLEPART: ((NEARINDREF+FARINDREF)/CARDF)*100 You can then determine if you should run REORG TABLESPACE to remove indirect row references. so DB2 has to take a lock. especially in a data sharing environment. FARINDREF is the number of indirect references to overflow rows outside this range. and for a data-sharing environment if the percent of indirect row references is greater than 5%. then REORG is performed. That can lead to performance degradation. so that the data row can no longer fit on the page.Removing indirect row references An indirect row reference is a pointer to an overflow row on a different page. When using the INDREFLIMIT keyword for REORG TABLESPACE. This can occur when an update is made to increase the length of a varying length column. P age H eader page 2 p tr-ro w 1 P age H eader page 3 Row 1 R ow 2 Row 3 R ow 4 ID M a p ID M a p Figure 6-15 Indirect row reference Reorganizing the table space eliminates all indirect references to overflow pages. When accessing the row in page 2. You can calculate the percentage of indirect row references based on the values of NEARINDREF. See Figure 6-15. We recommend that you run REORG TABLESPACE. When considering the statistics. If the calculated value exceeds the specified value of INDREFLIMIT. When rows are placed in another page than their home page. The RID is used to locate rows. both values indicate disorganization of the data. There could be an extra I/O involved to read in the extra page. Chapter 6. When the key is found. NEARINDREF is the number of indirect references to overflow rows on another page within the 16 pages. an index entry contains a key and RID. if the percent of indirect row references is greater than 10% for non-data-sharing environment. we only found a pointer over to page 3. Utility performance 143 . lock avoidances cannot be used. the RID identifies a particular row on a particular page.

deleted keys are marked as pseudo deleted. For LOB table spaces. it is important to remove pseudo deleted entries. Removing pseudo deleted entries Indexes can accumulate dead space that is reclaimed during reorganization. it may result in acquiring more extents than needed to add additional keys. Every time an SQL statement makes a scan of an index. When FREESPACE approaches zero for a LOB table space. it may result in acquiring more extents than needed to add additional LOBs. it may result in acquiring more extents than needed to add additional data rows. it is a good time to reclaim the space. We recommend that you run REORG INDEX. an updated LOB will be written without reclaiming the old version of the LOB immediately. You can calculate the percentage of RIDs that are pseudo deleted based on the values of PSEUDO_DEL_ENTRIES and CARDF in SYSINDEXPART: (PSEUDO_DEL_ENTRIES/CARDF)*100 You can then determine if you should run REORG INDEX to physically remove the pseudo deleted entries from the index. 144 DB2 for z/OS and OS/390 Version 7 Performance Topics . We recommend that you run REORG TABLESPACE. The amount of dead space for a simple table space can be tracked directly with PERCDROP in SYSTABLEPART. that have not yet been removed. Actual cleaning up will not occur except during certain processes. if the value of PERCDROP in SYSTABLEPART is greater than 10%. Reclaim space for LOB table spaces LOB table spaces can accumulate dead space that is reclaimed during reorganization. You can calculate the percentage of free space for LOB table spaces based on the values of FREESPACE in SYSLOBSTATS and SPACEF in SYSTABLEPART: (FREESPACE/SPACEF)*100 We recommend that you reorganize LOB table spaces. but there are no direct statistics indicating how much will be reclaimed. For simple table spaces. including pseudo deleted entries.Dropping tables in a simple table space Simple table spaces can accumulate dead space that is reclaimed during reorganization. such as before a page split. it has to scan all entries in the index. If this dead space is not regularly reclaimed. If this dead space is not regularly reclaimed. dropping a table results in that table’s data rows remaining. if the percent of pseudo deleted entries is greater than 10%. If this dead space is not regularly reclaimed. To minimize the CPU cost of an index scan. The FREESPACE gives an indication of how many more LOBs can be added into the existing extents already allocated. if the percent of free space is less than 10%. For an index.

A chunk is 16 contiguous pages of a LOB. Utility performance 145 . then it is optimized to fit into the minimum number of chunks. A value of 1. Chapter 6.0. and ORGRATIO in SYSLOBSTATS will increase. However. If the size of a LOB is smaller than a chunk. A u x ilia r y in d e x r o w id 1 r o w id 2 r o w id 3 r o w id 4 chunk 1 chunk 2 chunk 3 chunk 4 chunk 5 A u x ilia r y ta b le ( L O B t a b le s p a c e ) Figure 6-16 Fragmented LOB table space DB2 allocates space for LOBs in chunks. then it is expected to fit in 1 chunk. performance can be affected if LOBs are scattered into more physical pieces than necessary.0 is optimal for ORGRATIO. LOBs are split up to store in more chunks than would be optimal. The fragmentation or non-optimal organization of a LOB table space is measured in the value of ORGRATIO in SYSLOBSTATS. See Figure 6-16.A LOB column always has an auxiliary index which locates the LOB within the LOB table space. if the value of ORGRATIO in SYSLOBSTATS is greater than 2. See Figure 6-17. A u x ilia r y in d e x r o w id 1 r o w id 2 ro w id 3 ro w id 4 chunk 1 chunk 2 chunk 3 chunk 4 chunk 5 A u x ilia r y ta b le ( L O B t a b le s p a c e ) Figure 6-17 Non-fragmented LOB table space We recommend that you reorganize LOB table spaces. Access path is not an issue. If the size is greater than a chunk. thus involving more I/O to materialize. Due to fragmentation within chunks. because LOB access is always via a probe using the auxiliary index.

For DB2 V7. LEAFNEAR and LEAFFAR will be 0 after reorganization. When using DB2 V7. we recommend the use of LEARNEAR and LEAFFAR instead of LEAFDIST. L e a f P a g e 1 3 L e a f P a g e 1 4 L e a f P a g e 7 8 L e a f P a g e 7 9 H O T J A K F R I G R U 0 -3 2 p re fe tc h q u a n t it y 6 5 -9 6 Figure 6-18 Physical view before reorganization. but both values indicate disorganization of the leaf pages. For small indexes. 146 DB2 for z/OS and OS/390 Version 7 Performance Topics .Removing physical leaf disorganization LEAFNEAR is the number of leaf pages located within a range of 16 pages. For large indexes. This is because space map pages are periodically placed throughout the pages set. You can calculate the percentage of leaf pages in disorganization based on the values of LEAFFAR in SYSINDEXPART and NLEAF in SYSINDEXES: (LEAFFAR)/NLEAF)*100 You can then determine if you should run REORG INDEX to remove physical leaf disorganization. instead of using the LEAFDISTLIMIT keyword for REORG INDEX utility. and the jump over space map pages shows up as a count in LEAFNEAR. LEAFFAR is the number of leaf pages located outside the range of 16 pages. the LEAFFAR value is more significant and likely to affect performance than the LEAFNEAR value. the leaf pages are in the optimal physical position. but it is not as good a measurement as using LEAFNEAR and LEAFFAR. LEAFDIST also measures index leaf pages disorganization. LEAFNEAR may not be 0 after reorganization. See Figure 6-19. We recommend that you run REORG INDEX. if the percent of physical leaf disorganization is greater than 10%. After reorganizing the index. L e a f P a g e 8 L e a f P a g e 9 L e a f P a g e 1 0 L e a f P a g e 1 1 F R I G R U H O T J A K 0 -3 2 p r e fe tc h q u a n t it y 6 5 -9 6 Figure 6-19 Physical view after reorganization. When considering the statistics. See Figure 6-18. which can lead to performance degradation. we recommend that you use the above formula to determine when to run the REORG INDEX utility.

and its indexes The SYSCOPY columns. or utilities with SYSCOPY as the target object. these are local primary. RECOVER. START_RBA will be those of original entries in SYSCOPY row when the COPY utility recorded them. and that allows other utilities and SQL statements to run concurrently with the same target objects. QUIESCE. S egm en te d ta ble s pa ce S im ple ta ble sp ac e P a rtitione d tab le sp ac e 1) Im age C opies C O P Y TO C O P Y TAB LE S P AC E D B1 .7 COPYTOCOPY utility DB2 V7 provides you with the opportunity to make additional full or incremental image copies from a full or incremental image copy that was taken by the COPY utility.6.SYSCOPY. local backup. namely COPY.DBD01. Utility performance 147 . You are allowed to make a maximum of three copies. While columns DSNMAE. COPYTOCOPY will leave the target object in read-write access (UTRW). and REORG utilities.SYSUTILX. except for utilities that insert or delete records in SYSCOPY. to make up to the allowable total of four copies. Chapter 6. and its indexes DSNDB01. recovery site primary. and its indexes DSNDB06. MODIFY.TS 1 FR O M L AS TF U LLC O P Y R E C O V E R Y D D N (rem pri) 2) C o py the c opy R e cord in ca talog Figure 6-20 COPYTOCOPY utility The COPYTOCOPY utility does not support the following catalog and directory objects: DSNDB01. ICDATE. and recovery site backup. LOAD. MERGECOPY. JOBNAME and AUTHID will be those of the COPYTOCOPY job. ICTIME. GROUP_MEMBER.

at the time of our installation we also needed PQ43771.9% in elapsed time per copy by using the COPYTOCOPY utility instead of the COPY utility. This new utility statement. The measurements show that you can save up to 4. Table 6-17 summarizes the comparison of using the COPY utility with the COPYTOCOPY utility to make additional full image copies.0% -4.3% Note: All times are in seconds. The enhancement is provided by the PTFs for APARs PQ46759 and PQ45268.1 Performance measurements The measurements were performed using a full image copy of a 10-partition table with 517. This enables the output of any SQL SELECT statement to be directly loaded into a table on DB2 V7. combines the efficiency of the LOAD utility with the power of the SQL language.7.6. This enhancement. Table 6-17 Using COPYTOCOPY utility to make additional full image copies COPY utility CPU time Elapsed time COPYTOCOPY utility CPU time Elapsed time Delta in % CPU time Elapsed time Single COPY COPY LIST 11 10 182 177 10 10 173 173 -9. to create another full image copy.1% 0. PQ46245.338 pages. EXEC SQL. PQ51501.8 Cross Loader A new utility statement. Another advantage is that COPYTOCOPY leaves the target object in read-write access (UTRW). Check their prerequisites. which is called Cross Loader. enhances the functionality of the LOAD utility to move data across multiple databases and platforms. and that allows other utilities and SQL statements to run concurrently with the same target object. 6. 148 DB2 for z/OS and OS/390 Version 7 Performance Topics . You can benefit from using COPYTOCOPY to making additional copies asynchronously from the normal batch stream and it is mostly beneficial for remote copies on slow devices. If you need to minimize the time that some critical objects are unavailable due to making additional copies to a remote site.9% -2. has been added and it can be used before or after any utilities. or jointly with the LOAD utility. and PQ52120. PQ45015. The measurement for the COPY LIST. PQ47035. the LISTDEF includes all 10 partitions of the same table. the new COPYTOCOPY utility is the right way to make additional copies of these objects. PQ45776.

6. No host variables are allowed in the statement.1 The EXEC SQL statement Basically. Utility performance 149 . you can directly load the output of a dynamic SQL statement into a table on DB2 V7. Using Cross Loader is much simpler and easier than unloading the data. Errors encountered during the checking of the statement or the execution will stop the utility and an error message will be issued. transferring the output file to the target site. you can declare a cursor or specify any SQL statement that can be dynamically prepared. Also. or D a ta J o in e r D B 2 fa m i ly O ra c le S yb as e I n fo r m i x IM S V S AM S Q L S erver N C R Te ra d a ta D B 2 fo r O S /3 9 0 a n d Z /O S Figure 6-21 Cross Loader Since the SQL SELECT statement can access any DRDA server. DRDA.8. Figure 6-22 shows the output from Cross Loader. Data Joiner. no self referencing loads are allowed. the data source may be any member of the DB2 Family. and then running the LOAD utility. The Load utility performs an EXECUTE IMMEDIATE on the SQL statement. or any other vendor who has implemented DRDA server capabilities. when loading data from a table on remote DB server into a DB2 table on a local DB2 for OS/390 using DRDA protocol over TCP/IP and 3-part names.LO AD S EL EC T D a ta c o n v e r s io n Local D B 2. The ENDEXEC indicates the end of the statement. Chapter 6. Within the new EXEC SQL utility statement.

193142 DSNU304I -DB2G DSNURWT .341 rows. 150 DB2 for z/OS and OS/390 Version 7 Performance Topics .22. the improvements are over 90% in both CPU and elapsed time. The same enhancement has been made available to DB2 V5 and V6.NUMBER OF INPUT RECORDS PROCESSED=35 DSNU300I DSNURILD . that is.9 MODIFY RECOVERY enhancement DB2 V7 has introduced some maintenance provided by the PTF for APAR PQ45184 that has massively improved the way the MODIFY RECOVERY utility performs when dealing with complex situations. COPY.DSNU000I DSNUGUTC . to avoid problems when converting data from one code page to another.LOAD DATA INCURSOR(C1) REPLACE DSNU650I -DB2G DSNURWI . The measurements were performed under DB2 V7 with and without this enhancement. The new utility statement EXEC SQL can be used before and/or after any of the utilities.TSLP2002 SUCCESSFUL DSNU610I -DB2G DSNUSUTB SYSTABLES CATALOG UPDATE FOR PAOLOR5. RUNSTATS.OUTPUT START FOR UTILITY.(RE)LOAD PHASE STATISTICS .7 5.INTO TABLE PAOLOR5. Table 6-18 Modify recovery enhancement MODIFY RECOVERY DELETE AGE(*) Without fix for PQ45184 With fix for PQ45184 CPU time (sec) Elapsed time (sec) 119 123 1.STAFF ENDEXEC DSNU050I DSNUGUTC .DK37990.EXEC SQL DECLARE C1 CURSOR FOR SELECT * FROM SAMPLE.58.TSLP2002 SUCCESSFUL DSNU620I -DB2G DSNURDRT . with 7.476 entry records for the specific tablespace. for a customer SYSCOPY table with 975.STAFF SUCCESSFUL DSNU610I -DB2G DSNUSUTS SYSTABLESPACE CATALOG UPDATE FOR DBLP0002. 6.STAFF DSNU302I DSNURILD . ELAPSED TIME=00:00:01 DSNU010I DSNUGBAC .(RE)LOAD PHASE STATISTICS . UTILID = LOADTS DSNU050I DSNUGUTC .STAFF STATISTICS DSNU350I -DB2G DSNURRST . HIGHEST RETURN CODE=0 Figure 6-22 Output from Cross Loader using DRDA and 3-part names It is important that the CCSID on the local and remote DB server is defined correctly.UTILITY EXECUTION COMPLETE.NUMBER OF RECORDS=35 FOR TABLE PAOLOR5. The results are listed in Table 6-18.EXISTING RECORDS DELETED FROM TABLESPACE DSNU610I -DB2G DSNUSUTP SYSTABLEPART CATALOG UPDATE FOR DBLP0002.(RE)LOAD PHASE COMPLETE.1 With this enhancement. and so on.RUNSTATS CATALOG TIMESTAMP = 2001-04-27-18.

© Copyright IBM Corp. Considerations on SQLJ and JDBC performance: These recommendations. 2001 151 . Java stored procedures with JVM: This implements support for Java stored procedures as interpreted Java executing in a Java Virtual Machine (JVM) as well as support for user-defined external (non-SQL) functions written in Java. Network computing performance This chapter provides a functional description of the performance related enhancements to network computing in DB2 V7.7 Chapter 7. if implemented. can have a dramatic effect on the performance of your SQLJ applications. Unicode: Full support is provided for a third encoding scheme. DRDA server elapsed time reporting: This makes it easier to monitor bottlenecks in client/server applications. Stored procedures with COMMIT/ROLLBACK: This makes it possible to implement more complex stored procedures that are invoked by Windows and UNIX clients. FETCH FIRST n ROWS ONLY: This enhancement allows you to set a limit on the number of rows returned to a result set.

T1. Prior to V7. SQLSTATE 02000). most of the performance improvement comes in the form of elapsed time savings. An attempt to fetch more rows than specified is handled the same way as normal end of data (SQLCODE +100.NAME LIKE 'SYS%' ORDER BY T1.NAME FROM SYSIBM. See Figure 7-1. and at the same time. This is because in an environment of short running SQL transactions. and only the specified number of rows is returned in the result set. If DB2 knows that only one row. This new clause FETCH FIRST n ROWS ONLY.CREATOR = 'SYSIBM' AND T1. SELECT T1. does not allow the application to fetch more rows than the specified number n. SQLCODE IS 100 Figure 7-1 Fetching n rows FETCH FIRST n ROWS ONLY (with fast implicit close of the cursor) is basically a performance option for applications that only wish the first n fetched rows to be returned from a query result set that might be much larger.1 FETCH FIRST n ROWS DB2 V7 introduces the statement FETCH FIRST n ROWS ONLY.SYSTABLES T1 WHERE T1. This statement clause allows a limit on the number of rows returned to the result set to be specified. a fast implicit close of the cursor.CREATOR. are required. the network latency adds a higher level of magnitude to the overall transaction time. CREATOR NAME ---------+---------+---------+---------+---------+--------SYSIBM SYSAUXRELS SYSIBM SYSCHECKDEP SYSIBM SYSCHECKS SYSIBM SYSCHECKS2 SYSIBM SYSCOLAUTH DSNE610I NUMBER OF ROWS DISPLAYED IS 5 DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL.CREATOR. The blocks might contain more rows than the application needed and this could have a negative impact on the performance of such statements. This saves line flow in the network by not requiring the client to explicitly close the cursor with extra communications. Although there is a performance improvement in CPU savings in DB2. the block prefetching does not take place. as opposed to the actual processing of the SQL statement. The processing also results in an implicit close of the cursor at the server when reaching the value of n. 152 DB2 for z/OS and OS/390 Version 7 Performance Topics .NAME FETCH FIRST 5 ROWS ONLY. T1. DB2 would prefetch blocks.7. or few rows.

Each row is 20 bytes. it is compared to the same SELECT statement with FETCH FIRST n ROWS ONLY adding an OPTIMIZE FOR 1 ROW clause. If the OPTIMIZE FOR clause is not specified. 200. Chapter 7. this is no longer the case with the change implemented by the PTF for APAR PQ49458 (still open at the time of writing. 200. If both the FETCH FIRST n ROWS and OPTIMIZE FOR m ROWS clauses are specified with DB2 V7. a statement SELECT * FROM Y that would return a full result set with a fixed number of rows 50. with DB2 V7.1 OPTIMIZE FOR m ROWS OPTIMIZE FOR m ROWS exists in versions prior to V7 and is used to control network blocking and access path selection. which is an even greater performance degradation. DB2 will honor the specified values and keep the two options independent. and 400 is compared to the same SELECT statement adding a FETCH FIRST n ROWS ONLY clause. 200. and all n rows will be returned in a single block. Currently. the value of m still influences the network blocking. Network computing performance 153 . where m is equal to the value of n in the FETCH FIRST n ROWS ONLY clause. and 400. there will be "n divided by m rounded up" blocks sent to return n rows. The effect of performance degradation is obvious in Figure 7-2. The semantics of OPTIMIZE FOR 1 (or 2 or 3) ROW clause results in a query block of 16 rows. the lower value between n and m is also assumed by DB2 optimizer for access path selection of the query.1. OPTIMIZE FOR m ROWS would cause line turnarounds at the value of m. This has the performance implications discussed below. Finally. and 400. For example. there is no effect.1. This forces a network turnaround when the result set is greater than 16 rows.7. if m is less than n. where n limits the result set to a fixed number of rows 50. which shows the overall transaction rate for the three versions of the SQL statements for the three result set row counts of 50. 7. When m is greater than n.) If both clauses are explicitly specified. since the result set is truncated to the value of n. A larger row size would create even larger differences in the comparisons.2 Performance measurements In these measurements. a default of OPTIMIZE FOR m ROWS is assumed.

Figure 7-3 shows the CPU time per transaction for the three versions of SQL statements for the three result set row counts of 50.01 0.007 Seconds 0.200 150 Transactions per Second SELECT * FROM Y 100 SELECT * FROM Y FETCH FIRST 50 ROWS ONLY SELECT * FROM Y FETCH FIRST 50 ROWS ONLY OPTIMIZE FOR 1 ROW 50 0 50 200 400 Number of Rows Figure 7-2 Throughput per SQL statement Notice that for a result set of 50 rows. the transaction rate is roughly equivalent between the SELECT with and without the FETCH FIRST 50 ROWS ONLY clause. 0.001 0 50 200 400 Number of Rows Figure 7-3 CPU time per transaction SELECT * FROM Y SELECT * FROM Y FETCH FIRST 50 ROWS ONLY SELECT * FROM Y FETCH FIRST 50 ROWS ONLY OPTIMIZE FOR 1 ROW 154 DB2 for z/OS and OS/390 Version 7 Performance Topics .005 0. This is because they return the same number of rows.002 0.004 0.006 0. and 400.008 CPU time per transaction 0.003 0. The SELECT statement with the OPTIMIZE FOR 1 ROW clause is degraded due to requiring four network flows to return the entire 50 rows (16 rows + 16 rows + 16 rows + 2 rows).009 0. 200.

04 Seconds 0.1. the SQL statement fails.3 Singleton select Singleton select statements have performance benefits as described below.SYSTABLES WHERE NAME = ‘TABLENAME’ AND CREATOR = ‘TBCRE01’ END-EXEC. Chapter 7.06 0. Unfortunately. 7. It is recommended that you use FETCH FIRST n ROWS ONLY. but can minimize the numbers of rows in the result set. Network computing performance 155 . you can use a singleton SELECT statement: EXEC SQL SELECT NAME.05 0. if the answer set is greater than one row. CREATOR INTO :HV_NAME. :HV_CREATOR FROM SYSIBM. This support now allows applications to use singleton select statements with the resultant performance benefits when the result set is greater than one row.Notice that the CPU time increases for the SELECT statement without the FETCH FIRST n ROWS ONLY clauses as the number of rows increases. the statement is successful. This is an example of the high cost of network turnarounds. Notice also that the elapsed time for the SELECT with the OPTIMIZE FOR 1 ROW clause is much larger than the other two. you can benefit from using FETCH FIRST n ROWS ONLY. Figure 7-4 shows the elapsed time outside of DB2 and the host to perform the transactions.01 0 50 200 400 Number of Rows Figure 7-4 Elapsed time outside of DB2 per transaction Elapsed time per transaction SELECT * FROM Y SELECT * FROM Y FETCH FIRST 50 ROWS ONLY SELECT * FROM Y FETCH FIRST 50 ROWS ONLY OPTIMIZE FOR 1 ROW The performance measurements shows that if you do not need to fetch all the rows in a result set.02 0. Notice that the elapsed time slowly increases for the SELECT statement without the FETCH FIRST n ROWS ONLY clauses. If FETCH 1 ROW ONLY is added to the singleton select statement. To retrieve only one qualified row from a table into an application program. This is the result of the increased number of bytes as the result set increases. 0. every time you do not need a full result set. The CPU time remain flat for the SQL statements that include the FETCH FIRST 50 ROWS ONLY clause.03 0.

you have to open it: EXEC SQL OPEN C1 END-EXEC. After you have declared the cursor. The performance impact of using a non-singleton SELECT statement to retrieve only one qualified row from a table into an application.Or you can use a non-singleton SELECT statement. Time spent in DDF 60 59 CPU time per transaction in micro seconds 58 57 56 55 54 53 52 51 50 No singleton SELECT Singleton SELECT Figure 7-5 Non-singleton SELECT versus singleton SELECT The extra CPU cost can be up to 30% in other environments such as CICS. 156 DB2 for z/OS and OS/390 Version 7 Performance Topics . And then.SYSTABLES WHERE NAME = ‘TABLENAME’ AND CREATOR = ‘TBCRE01’ FETCH 1 ROW ONLY END-EXEC. you have to close the cursor: EXEC SQL CLOSE C1 END-EXEC. And then you have to read the data into the application program: EXEC SQL FETCH C1 INTO :HV_NAME. :HV_CREATOR END-EXEC. CREATOR FROM SYSIBM. where you have to declare a cursor: EXEC SQL DELCARE C1 CURSOR FOR SELECT NAME. See Figure 7-5. has an extra CPU cost in the DDF address space of 4%. The extra cost of CPU time for using non-singleton SELECT statement is used to OPEN and CLOSE the cursor.

the whole unit of work. See Figure 7-6. including uncommitted changes made from the client before the stored procedure was called. 7.2 Stored procedures with COMMIT/ROLLBACK DB2 V7 allows you to use COMMIT/ROLLBACK in stored procedure. Unlike compiled Java stored procedures which are executed in a WLM stored procedure address space. but is executed in a JVM under OS/390 UNIX System Services (USS). JDBC/SQLJ Driver packages Reusable Java VM Java method JDBC/SQLJ Driver Figure 7-6 Interpreted Java stored procedures Chapter 7. will be committed or rolled back.When coding an SQL statement to retrieve only one qualified row from a table in an application program. if the client is using 2-phase commit No COMMIT/ROLLBACK for nested stored procedures 7. It makes it possible to implement more complex stored procedures that are invoked by Windows and UNIX clients. COMMIT/ROLLBACK is not allowed in the following situations: No COMMIT/ROLLBACK for User Defined Functions No COMMIT/ROLLBACK. the interpreted Java is invoked by the WLM stored procedure address space. you will gain the best performance of using a singleton SELECT statement instead of a non-singleton SELECT statement. Network computing performance 157 . When COMMIT/ROLLBACK is used in a stored procedure.3 Java stored procedures with JVM DB V7 implements support for Java stored procedures as interpreted Java executing in a Java Virtual Machine (JVM) as well as support for user-defined external (non-SQL) functions written in Java. OS/390 System DRDA or Java or Native Client Stored Procedures Address Space PROCLIB SPAS JCL DB2 EXEC SQL CALL PROGX Catalog Entry Sched Driver Identify C1 Identify C2 Return parms C1 rows C2 rows LE Enclave Driver: Find Java package Load and execute Java method USS File system Java package.

which indicates the stored procedure or functions written in Java and the Java Byte code will be executed in the OS/390 JVM. by executing different CREATE PROCEDURE FUNCTION SQL statements. under USS... DB2 executes Interpreted Java stored procedures and functions using the OS/390 JDK 1.INSTALL_JAR built-in stored procedure. is also extended.8. Using the JDK 1.. Figure 7-7 Java runtime environment in DB2 V7 Although there are no syntax changes.1.. The Java method for interpreted Java exists in a JAR file which is installed into DB2 by the SQLJ. If LANGUAGE is JAVA then the EXTERNAL NAME clause defines a string of one or more external Java routine name(s). The OS/390 JDK 1. 7.. See Figure 7-7. which specifies the program that runs when the procedure name is specified in a CALL statement. two parameters are enhanced.) ..class ADD_CUSTOMER 2 JAVAENV dataset NAME JARSCHEMA MY SP WLM Address Space SYSROUTINES JAR_ID JAR EXTERNAL_NAME 4 .. SQLJ Source DB2 Packages ACEMSOS/ Add_customer.1 Performance considerations Java stored procedures implemented as compiled Java will perform better. 158 DB2 for z/OS and OS/390 Version 7 Performance Topics .sqlj Program Preparation Process ACMESOS1 2 USS Add_customer. the JVM is created and destroyed each time the Java stored procedure is invoked. A JAR file can contain any number of Java classes which can be invoked as DB2 stored procedures or functions... CALL ADD_CUSTOMER (FIRSTNAME.3 should overcome this problem. You can also reference the same Java class by more than one stored procedure name. Compiled Java stored procedures execute in the WLM stored procedure address space. 1 ADD_CUSTOMER 3 SYSJAROBJECTS JARSCHEMA MY JAR_ID JAR JAVA_DATA . The EXTERNAL parameter.. enclosed in single quotes. if they are implemented as interpreted Java executing in a JVM.1. The LANGUAGE parameter now accepts JAVA.8 and above. referencing the same Java class.3.The CREATE PROCEDURE/FUNCTION SQL statement allows you to specify an SQL name for a Java method. client . while interpreted Java stored procedures execute in a JVM running in a USS environment..

A good source of general considerations on Java performance is Systems Journal Vol. Java stored procedures also require large amounts of memory to execute efficiently. Chapter 7. you should specify the following environment variable: IBM_MIXED_MODE_THRESHOLD=1 Use the correct level of the JDK Make sure your JDK level is at least 1. Ensure JIT compilation for every Java method To ensure that JIT compilation is performed for every Java method. The points we make here are not necessarily listed in order of importance.3 you can exploit the hardware support for floating point calculations provided by the G5. The primary reason for this is to provide for efficient predicate processing: indexable and stage 1. For best performance. No. Network computing performance 159 . Recent performance studies have highlighted the fact that these recommendations should not be regarded as implementation options. BIND options Specify DYNAMICRULES(BIND) for dynamic SQL to make sure that the table access privileges of the binder are implicitly used during execution of the package.environment variable You must define the environment variable _cee_runopts to include the following specification: _cee_runopts=”heappools(on)” This defines the way in which dynamic memory is used by SQLJ and JDBC applications.39. but as actions you must take in order to get good SQLJ application performance.1. If you do not specify heappools(on). G321-0137. can have a dramatic effect on the performance of your SQLJ applications. G6. Dynamic SQL includes JDBC and cursor controlled updates and deletes in SQLJ.4 SQLJ and JDBC performance considerations Here we draw together some of the points made above about the coding and preparation of SQLJ and JDBC programs with some extra information. Otherwise. The WLM environment does not have to be destroyed and a new runtime environment built when a different stored procedure needs to be executed. you will have to grant authorization over the underlying DB2 objects to the authorization id executing the plan. and zSeries processing complexes. Mapping Java data types to DB2 data types For optimal performance it is recommended to map the Java data types used to the SQL column data types. They should be implemented as a whole. then you incur the very considerable overhead of memory being repeatedly freed and allocated as objects are instantiated.3. The other reason is to minimize data conversion cost. we recommend that you separate interpreted Java stored procedures from Compiled Java stored procedures. 7. This includes separating stored procedures by language. With JDK 1. 2000. We focus in particular on SQLJ programs and make a series of recommendations which.We recommend that you configure different stored procedure workloads into different WLM stored procedure environments. Java Performance. Use the QUALIFIER keyword of the BIND command to provide qualification for unqualified table or view names referenced in JDBC and SQLJ. Memory usage . if implemented.

The weight of this recommendation is even stronger for Java applications.Table 7-1 below provides the recommended mapping between Java data types and SQL column data types.Date String String java.BigDecimal Online checking with db2profc For String data types in Java there is no concept of length. Java is running in Unicode: retrieving string columns requires the conversion from EBCDIC/ASCII to Unicode. The associated SQL column data types are CHAR and VARCHAR. In order to have the predicates used for index matching.Timestamp java..sql. To dramatically reduce the processing overhead and get reasonable close to the performance of static SQL. -online=<db2_location_name> . Dynamic statement caching avoids the full cost of preparing an SQL request.sql.. and the output customized profile must be available and accessible in the runtime PATH. FLOAT DATE CHAR VARCHAR TIME TIMESTAMP DECIMAL or NUMERIC Java data type short. the definition in the DBRM for SQLJ (static SQL) must match the definition in the DB2 catalog in terms of data type and length. boolean int float (single precision) double (double precision) java.math. Activate dynamic SQL statement caching For relatively simple SQL requests. Use the correct serialized profile In order to achieve true static SQL execution for SQLJ applications you must customize the SQLJ serialized profile using db2profc. 160 DB2 for z/OS and OS/390 Version 7 Performance Topics . In order to achieve this you must customize the SQLJ serialized profile using db2profc and specify the online checker option -online = <DB2 location name>: db2profc .Time java.sql. This is because of the emphasis on individual column processing within the Java programming model where a Java object is created for every single column. DB2 provides for dynamic SQL statement caching. Table 7-1 Mapping DB2 data types to Java data types DB2 data type SMALLINT INTEGER REAL DOUBLE... the processing cost of preparing dynamic SQL statements can be very significant. Only select and update columns as necessary For optimal performance it has always been recommended that DB2 applications should only select and update the columns actually required by your application.

When using JDBC or controlled updates or deletes in SQLJ.Dynamic statement caching is enabled by specifying CACHEDYN=YES on the DSN6SPRM macro in DSNZPARM. we have collected it in Table 7-2. For optimal performance it is strongly recommended to use SQLJ for database access. To bring all this information together.environment variable Ensure JIT compilation for every Java method Use the correct level of the JDK BIND options Mapping Java data types to DB2 data types Online checking with db2profc Use the correct serialized profile Only select and update columns as necessary Activate dynamic SQL statement caching Cursor-controlled SELECT Memory management essentials Servicing JDBC and SQLJ performance problems Responsibility Systems Programmer/Application Integrator Systems Programmer/Application Integrator Systems Programmer DBA/Systems Programmer Application Developer DBA/Application Developer DBA/Systems Programmer/Application Integrator Application Developer Systems Programmer Application Developer Application Developer Systems Programmer/DBA 7. it is recommended to turn on dynamic statement caching. listing for each header which job function we believe should be responsible for implementing each recommendation: Table 7-2 Recommendations and responsibilities Recommendation Memory usage . it is possible to make significant savings. Performance recommendation responsibilities The responsibility for improving the performance of your Java application is shared across multiple functions within your organization.5 Unicode DB2 V7 introduces full support for a third encoding scheme besides EBCDIC and ASCII. Use positioned iterators For optimal performance it is recommended to use positioned iterators rather than named iterators to reduce the processing cost. When the prepared statement is found in the prepared statement cache. Releasing resources For JDBC it is important to close prepared statements before reusing the statement handle to prepare a different SQL statement within the same connection. Unicode. A typical hit ratio is between 70% and 90%. Network computing performance 161 . Chapter 7. The Unicode encoding standard is an encoding scheme that can include characters for almost all the languages in the world.

The planes are numbered form 0.5.With this enhancement. UCS-2 UCS-2 is a fixed-width 16-bit encoding standard. UCS-4 UCS-4 is a fixed-width 32-bit encoding standard.1 Performance considerations There is a large CPU cost to translate between EBCDIC and Unicode. UTF-8 UTF-8 is a transformation format in 8 bits and uses a sequence of 8-bit values to encode UCS code points. Its best to avoid translation as much as possible. Even without translation. the results of SQL may be unpredictable. with a range of 2*31 code points. then the same changes should be made to all other members of the data sharing group. or LOAD/UNLOAD or anytime that an SQL predicate uses a data type which does not match the table contents. and generate the reply. by helping to easily identify where the bottleneck is. there is still a small CPU cost to handling Unicode data types. each consisting of 2*16 code points. In the future. by allowing data form more than one country/language to be stored in the same DB2 subsystem. Plan2 0. It does not include any of the network time used to receive the request or send the reply. 7. the rest of the members of the data sharing group should also be converted to the same release as soon as possible. Server elapsed time allows remote clients to determine the actual amount of time it takes for DB2 to parse a remote request. Note that translation occurs on inserts. new processors will assist in the translation and bring down the cost. UTF-16 UTF-16 is a transformation format in 16 bits and uses a sequence of 16-bit values to encode UCS code points. A timestamp is recorded when DDF first receives a remote request. corresponds to UCS-2. This translation is currently being done by software without any hardware assist. Data sharing considerations We recommend that all members of a data sharing group adhere to these recommendations: Once one member of the data sharing group converts to a DB2 release that support Unicode. DB2 V7 can truly support multinational and e-commerce applications. If the CCSIDs are changed on one system. Applications accessing a DB2 for OS/390 server using DB2 Connect V7 can now monitor the server’s elapsed time using the System Monitor Facility. The 2*31 code points are grouped into 2*15 planes. 162 DB2 for z/OS and OS/390 Version 7 Performance Topics . process any SQL statements required to satisfy the request. with a range of 2*16 code points. This enhancement makes it easier to monitor bottlenecks in client/server applications. the Basic Multilingual Plane (BMP). 7. If these recommendations are not followed.6 DRDA server elapsed time reporting The network monitoring has been improved in DB2 V7.

Chapter 7.2 with Fix pack 1 and is activated on DB2 Connect Monitor by setting up the variables for unit of work and statement.A second timestamp is recorded after the DB2 server has processed any SQL statements and generated the reply. See Connecting WebSphere to DB2 UDB Server. The difference in values is the elapsed time that is returned to the client. This function is supported starting with DB2 Connect Version 7. SG24-62119 for details. Network computing performance 163 .

164 DB2 for z/OS and OS/390 Version 7 Performance Topics .

User enables Coupling Facility duplexing for IRLM lock structure. Applications. 2001 165 . IMMEDWRITE bind option: The IMMEDWRITE bind/rebind option. Data sharing DB2 Version 7 delivers a number of enhancements to improve availability. This enhancement reduces the performance impact of purging group buffer pool (GBP) entries for GBP dependent page sets. can request to be notified when a member of the data sharing group becomes active on the executing OS/390 image.User can specify how many lock hash entries they want in the Coupling Facility lock structure when the first IRLM connects to the group.8 Chapter 8. Miscellaneous items: – During normal shutdown processing. – A new special register. Group attach enhancements: An application can now connect to a specific DB2 member even if the DB2 member name and the DB2 group name are identical. – APAR PQ44114 . – APAR PQ45407 . is fully implemented in DB2 V7. introduced by APAR in DB2 V5 and V6. for automatic tuning of CF structures. Auto Alter. performance and usability of DB2 data sharing: Coupling Facility Name Class Queues: Name Class Queues allows the Coupling Facility Control Code (CFCC) to organize the GBP directory entries in queues based on DBID. – OS/390 Version 2 Release 10 introduces a new function. DB2 notifies you of unresolved UOWs (indoubt or postponed abort) that will hold retained locks after the DB2 member has shut down. With DB2 V7 you can specify the group attach name for DL/I batch applications. which will decrease recovery time in such a failure situation. Persistent Coupling Facility structure sizes: After altering the size of DB2 structures. returns the DB2 member name. PSID and partition number. – DB2 V7 reduces the MVS to DB2 communication that occurs during a Coupling Facility/structure failure. using the group attach name. © Copyright IBM Corp. DB2 V7 keeps track of their size across DB2 executions and structure allocations. DB2 Restart Light: The “Light“restart option allows you to restart a failed DB2 member on the same or another OS/390 image with a minimum storage footprint in order to release any retained locks. – A new option on the MODIFY irlmproc command allows user to purge retained locks. CURRENT MEMBER.

06 CFCC level 8 at service level 1. Name Class Queues allows the CFCC to organize the GBP directory entries into queues based on DBID. DB2 V7 requests to use Name Class Queues at group buffer pool connect. DB2 had to scan the whole GBP directory looking for the entries for a particular page set. DSNB797I -DBG2 OTHER INTERACTIONS REGISTER PAGE UNREGISTER PAGE DELETE NAME READ STORAGE STATISTICS EXPLICIT CROSS INVALIDATIONS ASYNCHRONOUS GBP REQUESTS =0 =0 = 0 = 12 =0 =0 The required levels and service levels for the CFCC are: CFCC level 7 at service level 1. To externalize the level of the CFCC. See Figure 8-1.8.8 the level of the CFCC was not externalized. DB2 can use the Name Class Queues to reduce the problem of Coupling Facility utilization spikes and delays when deleting GBP entries for a page set/partition.1 Coupling Facility Name Class Queues The CFCC Level 7 introduced a new function called Name Class Queues.03 CFCC level 9 Prior to OS/390 Version 2. The only way to safely determine what level the CFCC was running at was to ask the system administrator. PSID and partition number. Without this enhancement. In a DB2 data sharing environment. OS/390 Version 2. Locating and purging these entries will now happen more efficiently. 166 DB2 for z/OS and OS/390 Version 7 Performance Topics . This occurs during: Read-only switching (pseudo close) DB2 shutdown and this member was the last updater of the page set/partition. The number of requests to the Coupling Facility to delete the directory entries associated with a set of pages is reported in message DSNB797I in response to a -DISPLAY GBPOOL() MDETAIL command: .8 enhances the D CF command output.

Data sharing 167 . to be notified when any member of the Data Sharing group becomes active on this OS/390 image.2. 01 BUI LT ON 12/ 08/ 200 0 AT 09: 05 : 00 0 0 2048 2048 0 256 K K K K K Figure 8-1 Output of D CF command 8. The groupoverride parameter on CONNECT (CAF) and IDENTIFY (RRSAF) is available to applications using CAF and RRSAF to attach to DB2.2. 00000 0010ECB . Chapter 8. This string indicates that the subsystem name that is specified is to be used as a DB2 member subsystem name. it posts any startup ECBs that might exist to notify the waiting applications that DB2 is now available for work.2 Support for local connect using STARTECB parameter You can now specify the startecb parameter on a local CONNECT (CAF) and IDENTIFY (RRSAF) call to DB2 using the group attach name. 8. If this parameter is provided. where there are two or more members of the Data Sharing group active on the same OS/390 image and the subsystem id of one of the members is the same as the group attach name. 8.D CF I XL150I 14. I BM 02. monitoring applications). 00 . 38. This is important for some applications that need to connect to specific members of the Data Sharing group. rather than generically connecting to any member of a given Data Sharing group (for example.2 Group attach enhancements DB2 V7 introduces a number of enhancements to DB2 group attach processing. Applications using TSO attach to DB2 can use the parameter GROUP(NO) on the DSN command. 15 DI SPLAY CF 805 COUPLI NG FACI LI TY 002064. it contains the string GROUP(N). This parameter is optional on the CONNECT or IDENTIFY call. SERVI CE LEVEL 02. PARTI TI ON: E CPCI D: 00 CONTROL UNI T I D: FFF9 NAM ED CF01 COUPLI NG FACI LI TY SPACE UTI LI ZATI ON ALLO CATED SPACE DUM SPACE UTI LI ZATI ON P STRUCTURES: 169728 K STRUCTURE DUM TABLES: P DUM SPACE: P 2048 K TABLE COUNT: FREE SPACE: 844800 K FREE DUM SPACE: P TOTAL SPACE: 10165 76 K TOTAL DUM SPACE: P M AX REQUESTED DUM SPACE: P VOLATI LE: YES STO RAGE I NCREMENT SI ZE: CFLEVEL: 9 CFCC RELEASE 09. The startecb parameter of the CONNECT call to DB2 is used by applications who want to wait for the target DB2 subsystem to become available if it is currently not started. When the target DB2 comes up.1 Bypass group attach processing on local connect — groupoverride An application can now connect to a specific member of a Data Sharing group.

the incompatibility is removed and therefore group attach support can now be safely added for DL/I Batch without any incompatible behavior being introduced. In this case it means that no group attach is required. CICS group attach description A new DB2GROUPID parameter is added to the DB2CONN definition. when the group attach name is coded. Specifying a DB2ID means that attach to a specific DB2 is required. depending on if you specify the Data Sharing group name or DB2 subsystem name with the STARTECB parameter. This information is returned to CICS by DB2 when connection is established. CPSM needs to change to pick up the new DB2GROUPID on EXEC CICS CREATE DB2CONN and EXEC CICS INQ/SET DB2CONN. EXEC CICS CREATE DB2CONNl supports DB2GROUPID. this is the name of the DB2 connected to. It is mutually exclusive to the existing DB2ID parameter. Although announced together with the CICS TS 2. DB2 therefore behaves differently. Limited support for using the group attach for DL/I batch is available in DB2 for MVS Version 4.2. there is no change. 8. 168 DB2 for z/OS and OS/390 Version 7 Performance Topics . that is. when CICS is not connected to DB2 this field contains the specific DB2 subsystem the user has specified or set in the db2conn definition (if any. then whichever of the subsystems starts first will post the startup ECBs. and vice versa. When connected to DB2.4 CICS group attach Now that RDO for RCT has been implemented. it could be blank). CEMT/EXEC CICS SET DB2CONN is enhanced to support DB2GROUPID. DB2 UDB for OS/390 Versions 5 and 6 by arrangement with IBM Support.For example. and a specific DB2ID is used from INITPARM if specified. 8. If both are specified on a CEDA panel then DB2ID wins. if the application tries to connect to DB0G and DB0G is the group attach name for DB2 subsystems DB1G and DB2G. This support has restrictions.2. However when CICS is connected to DB2. it is only be possible to set a DB2GROUPID when the CICS-DB2 attachment facility is not active. CEMT/EXEC CICS INQUIRE DB2CONN is enhanced to support DB2GROUPID The semantics of CEMT/EXEC CICS INQUIRE DB2CONN DB2ID() change slightly.1. it contains the member of the DB2 data sharing group that was chosen.2. It fails with an INVREQ if both DB2GROUPID and DB2ID are specified. DB2GROUPID is blanked out and a warning message is produced. CICS group attach comes with CICS TS 2. group attach is the most asked for enhancement to the CICS-DB2 interface. Specifying a DB2GROUPID causes the DB2ID to be blanked out. DB2 ignores the STARTECB parameter on the CONNECT call. via APAR only. As with DB2ID. Specifying a DB2GROUPID means group attach is required. When not using group attach. Now that STARTECB is supported for group attach.3 group attach support for DL/I batch jobs Prior versions of DB2 UDB for OS/390 do not allow DL/I batch jobs to specify the group attach name when connecting to DB2. For group attach this field will be blank if CICS is not connected to DB2. It is possible to leave both DB2ID and DB2GROUPID blank.

RESYNCMEMBER would only take affect if DB2GROUPID was being used: RESYNCMEMBER(YES) would be the default. it would under the covers try the specific member first. Data sharing 169 . IMS selects a member of the DB2 group that is connected to the IMS control region and connect that DB2 to the dependent region. the DB2GROUPID is blanked and CICS connects to DB2 subsystem JOHN. This means that the DB2GROUPID is blanked out. 8. it would ignore group attach and wait to reconnect to the specific member last used. however. If group attach is required then users should remove their INITPARM setting. A subsystem with the name specified in the SSM member parameter SSN was not found to be connected to the IMS control region. as it overrides group attach. RESYNCMEMBER(NO) would mean that the user does not require resynchronization with the previous member. If however the user specifies INITPARM=(DFHD2INI='JOHN') as a SIT parameter. Today users can leave the DB2ID in the DB2CONN definition blank and use the value from INITPARM. There is no DB2 peer recovery. It means the user wants to connect to a specific DB2. that DB2GROUPID has to be reset explicitly should group attach be wanted later. The subsystem name specified in the dependent region SSM member is then interpreted as a DB2 group name and IMS calls MVS Name Services. It results in a EXEC CICS SET DB2CONN DB2ID(xxxx) CONNECTED command being issued. Whether it be via DSNC STRT xxxx or INITPARM. and only if this fails would it resort to group attach. Chapter 8.5 IMS group attach With APAR PQ42180 IMS supports the use of the DB2 data sharing group name for DB2 V5 and later versions. This gives the user the override capability if it is required. Indoubt resolution The DB2 V7 enhancements to group attach do not include solving the problem of unresolved indoubts. SSM= was specified when the dependent region was started. or EXEC CICS SET DB2ID().2. a request to connect to a specific DB2 always overrides group attach. It should be noted. For example setting a DB2GROUPID of FRED in the DB2CONN causes the DB2ID to be blanked. All DB2s IMS and any of its dependent regions can connect to must still be specifically named in the IMS control region SSM member. and would mean that if CICS detected that it had UOWs outstanding. if CICS detects that UOW resolutions are outstanding. IMS looks for a DB2 group name if the following conditions for the dependent region SSM member are met: SST=DB2 was specified. The DB2 group name may be used in all online regions. Indoubt resolution depends on which action. because the DB2ID is blank in the DB2CONN then INITPARM is picked up. However. If MVS returns a positive response to the group inquiry. It does not support overriding a DB2GROUPID. you specify for the keyword RESYNCMEMBER on the DB2CONN definition. The INITPARM=(DFHD2INI='xxxx') command continues to be supported as an override to connect to a specific DB2.The DSNC STRT xxxx command (where xxxx is a DB2ID) is still be supported. YES or NO.

There is a high concern for the performance impact of specifying IMMEDWRITE(YES). 8.8. runs on member DB2G. and the updated page was once in use by DB2G. 170 DB2 for z/OS and OS/390 Version 7 Performance Topics . IMMEDWRITE(YES) allows the user to specify that DB2 should immediately write updated GBP dependent buffers to the Coupling Facility instead of waiting until commit or rollback. spawned by T1 and dependent on the updates made by T1. DB2 V6 and its evolution with DB2 V7. running on member DB1G. is added to DSN6GRP to allow the user to specify at the DB2 member level whether immediate writes or phase 1 writes should be done.SYSPACKAGE.3. IMMEDWRITE(PH1) allows the user to specify that a given plan or package should write updated group buffer pool dependent pages to the Coupling Facility at or before Phase 1 of commit. DB2 V6 APAR PQ25337 delivers the functionality introduced by APAR PQ22895 in DB2 V5 with the addition of a third value for IMMEDWRITE and a new DSNZPARM parameter. Transaction T2. makes an update to a page.SYSPLAN and SYSIBM. that T2 uses an old copy of the same page in the virtual buffer pool of DB2G if T1 still has not committed the update. there is a chance. IMMEDWRITE. We have a two way data sharing group DB0G with members DB1G and DB2G. The default for REBIND PLAN/PACKAGE is the IMMEDWRITE option used the last time the plan/package was bound. If the transaction subsequently rolls back.3. The bind/rebind panels of DB2I now support the IMMEDWRITE parameter. 8. If transaction T2 is not bound with isolation repeatable read (RR). IMMEDWRI(NO/PH1/YES). However. A new DSNZPARM parameter. This option is only useful if the dependent transaction is spawned during syncpoint processing of the originating transaction.2 IMMEDWRITE bind option in DB2 V7 The DB2 catalog now supports the IMMEDWRITE bind/rebind option by adding a new column.3 IMMEDWRITE bind option In this section we describe the IMMEDWRITE bind/rebind option. to the catalog tables SYSIBM. IMMEDWRITE(YES) is not the optimum solution when: The exact plans/packages which need IMMEDWRITE(YES) can not be identified and rebinding all plans/packages is not a feasible alternative. due to lock avoidance. A page can be written several times to the CF within the same UOW. the pages will be updated again during the rollback process and will be written again to the CF at the end of abort. Possible workarounds for this problem are: Execute the two transactions on the same member Bind transaction T2 with ISOLATION(RR) Make T1 commit before spawning T2 DB2 V5 APAR PQ22895 introduces a new bind/rebind option that can be considered when none of the above actions are desirable. its introduction with DB2 V5. This parameter affects all plans and packages that are bound on this member except if they were bound with the IMMEDWRITE option.1 IMMEDWRITE bind option before DB2 V7 Consider the following scenario. Transaction T1.

Data sharing 171 .3 IMMEDWRITE bind option performance IMMEDWRITE(YES) should be used with caution due to its potential performance impact. However. instead of being done at commit Phase 2.3. Table 8-1 illustrates the effect of the IMMEDWRI subsystem parameter and the IMMEDWRITE bind option on the value at run time. when IMMEDWRITE(PH1). Also.3. which is executed under the allied agent’s TCB. This is because the group buffer pool writes are done at commit Phase 1. IMMEDWRITE(PH1) should have little or no impact on overall performance. is used. there will be typically about twice the amount of group buffer pool writes for IMMEDWRITE(PH1) as compared to IMMEDWRITE(NO). the higher the performance impact of this bind option will be. which is executed under SRBs in the MSTR address space. if a transaction aborts after commit Phase 1 has completed. some of the CPU consumption will shift from being charged to the MSTR address space to being charged to the allied agent’s TCB. 8. Table 8-1 Immediate write hierarchy IMMEDWRITE bind option NO NO NO PH1 PH1 PH1 YES YES YES IMMEDWRI subsystem parameter NO PH1 YES NO PH1 YES NO PH1 YES value at run time NO PH1 YES PH1 PH1 YES YES YES YES 8.4 IMMEDWRITE bind option performance measurement A performance measurement was executed in order to compare the effect of the different IMMEDWRITE options. because each group buffer pool dependent page will be written out once during Phase 1 and once at the end of abort.DB2 V7 also externalizes the IMMEDWRI DSNZPARM parameter to the installation panels. Performance measurement description The measurements were executed using the IRWW workload on a 2-way data sharing group Chapter 8. The more updates a plan or package does on the same page. A value of YES takes precedence whether it is the subsystem parameter or the bind option.

Performance measurement results
The first measurement compares the internal throughput rate in case we use IMMEDWRITE(PH1) and IMMEDWRITE(YES). See Table 8-2 for the results of this measurement. A degradation of the internal throughput rate with 11.6% is noticed when using IMMEDWRITE(YES)
Table 8-2 IMMEDWRITE(PH1) vs. IMMEDWRITE(YES)
IMMEDWRITE(PH1) Member DG1G External throughput (commits/sec.) Member DG1G CPU utilization (%) Member DG1G Internal throughput Member DG2G External throughput (commits/sec.) Member DG2G CPU utilization (%) Member DG2G Internal throughput Internal throughput of data sharing group 63.0 IMMEDWRITE(YES) 52.2

65.40 96.41 63.3

61.60 84.74 52.6

64.88 97.56 193.97

60.91 86.36 171.10

The second measurement evaluates the impact of IMMEDWRITE(PH1) vs. IMMEDWRITE(NO). See Table 8-3 for the results of this measurement.
Table 8-3 IMMEDWRITE(PH1) vs. IMMEDWRITE(NO)
IMMEDWRITE(PH1) Internal throughput of data sharing group MSTR SRB time (millisecond/commit) DB2 Class 2 CPU time (millisecond/commit) 339.39 0.32 6.37 IMMEDWRITE(NO) 338.95 1.21 5.44

The internal throughput rates are very close to each other; meaning IMMEDWRITE(PH1) has little or no performance impact from our observation. We do observe CPU time shifting from the DB2 MSTR address space to the allied agent's TCB, as was expected.

8.4 DB2 Restart Light
If a MVS image in an OS/390 parallel sysplex became unavailable and had to be IPLed, there was not an acceptable option to resolve possible retained locks. Up to now, you had two alternatives to resolve the retained locks: Wait until the failed image was IPLed and then restart DB2.

172

DB2 for z/OS and OS/390 Version 7 Performance Topics

Restart the DB2 member on another image and bring it back down once the retained locks are resolved. The first alternative can be unacceptable from an availability point of view. The problem with the second alternative is that the DB2 restart asks for a lot of resources that impact overall performance of the image on which the restart is initiated.

8.4.1 Description
The Restart Light capability brings DB2 up with a minimal memory footprint. Retained locks are freed as part of the forward recovery and backward recovery processes and once this is done DB2 terminates.No new work is allowed. All retained locks are freed except for: Locks that are held by indoubt units of recovery. Locks that are held by postponed abort units of recovery. IX mode page set P-locks. These locks do not block access from other DB2 member; however, they do block drainers, such as utilities. The light restart mode uses: No EDM/RID pool, LOB manager, RDS or RLF Reduced number of service tasks Only primary buffer pools with VPSIZE= min(vpsize,2000) VDWQT = 0. CASTOUT(NO) for shutdown PC=YES for IRLM if autostarted by DB2

8.4.2 Command syntax
The LIGHT(YES) option on the START DB2 command tells DB2 to perform a light restart.

Message DSNY009I accompanies a light restart:
DSNY009I SUBSYSTEM STARTING IN LIGHT MODE, NORMAL TERMINATION TO FOLLOW RELEASE OF RETAINED LOCKS

In a non data sharing environment the LIGHT(YES) parameter is ignored. If you start DB2 with this option, you receive the following message:
DSNY015I LIGHT(YES) ON START DB2 COMMAND WAS IGNORED, SYSTEM IS NOT ENABLED FOR DATA SHARING.

8.4.3 Performance measurement
A set of performance measurements were done to compare a normal restart with a light restart.

Chapter 8. Data sharing

173

Performance measurement description
The measurement was executed using the IRWW workload on a 3-way data sharing group. All three members were driven to a commit rate of about 66 commits/sec. in order to obtain a data sharing group commit rate of 200 commits/sec. Once a steady state was observed the second member was crashed. The number of retained locks was about 750. DB2 was restarted on the first member by ARM. This scenario was executed once for the light restart and once for a normal restart. For this measurement the following hardware and software was used: Hardware – – – – – – – – 9672-ZZ7 — 12 CPUs Three LPARS — 12 logical CPUs per LPAR and 25% capping 2 9674 C05 CFs — 6 CPUs each Enterprise storage server OS/390 V2R8, CF micro code level 8 DB2 V7 IMS V6 DCCTL — 78 IMS regions — 750 terminals per member TPNS

Software

Performance measurement results
Here we compare the memory usage, the restart time, and the shutdown time for a light restart and a normal restart. Table 8-4 shows the virtual storage allocation for the EDM pool and the buffer pools used in this measurement for the normal restart and the light restart. The virtual storage used by DB2 was reduced by 373.5 MB. IRLM was started with parameter PC=YES, which reduces the impact on ECSA impact of the hosting system.
Table 8-4 RESTART LIGHT storage measurement
LIGHT(NO) #pages EDM BP0 BP1 BP2 BP3 BP4 BP5 BP6 BP7 BP8 TOTAL TOTAL(MB) 5,000 1,000 5,500 31,250 18,750 3,125 6,250 12,500 1,000 25,000 109,375 437.5 LIGHT(YES) #pages 0 1,000 2,000 2,000 2,000 2,000 2,000 2,000 1,000 2,000 16,000 64.0 Reduction #pages 5,000 0 3,500 29,250 16,750 1,125 4,250 10,500 0 23,000 93,375 373.5

174

DB2 for z/OS and OS/390 Version 7 Performance Topics

Table 8-5 summarizes the restart and shutdown times for the normal and light restart. The gain in restart time is not as substantial as the gain in memory footprint. For the light restart case, DB2 was stopped with CASTOUT(NO), which explains the faster shutdown.
Table 8-5 Restart Light — restart time measurements
LIGHT(NO) - in seconds ARM delay DB2 restart DB2 shutdown 7 67 16 LIGHT(YES) - in seconds 6 55 9

We noticed a longer restart time for the cross system restart than for a restart in place; this is due to XCF signalling activity which takes place in order to allow the restarting DB2 to join the data sharing group on another MVS image. Further enhancements will concentrate on a reduction of light restart time. The goal is that, after a crash of a MVS image, a DB2 cross system light restart will be fast enough in order to avoid transaction time-outs on the other members of the group due to the retained locks. Parameter RETLWAIT of DSNZPARM should be set to YES in this scenario.

8.5 Persistent Coupling Facility Structure sizes
You can change the size of a Coupling Facility structure dynamically using the SETXCF START,ALTER command. Prior to DB2 Version 7, this change in size was lost for subsequent allocations of the structure: When rebuilding the structure, the value of INITSIZE in the CFRM policy was used. When starting group buffer pool (GBP) duplexing after a change was made to the size of the structure, the secondary structure was allocated using the INITSIZE value in the CFRM policy rather then using the current size of the primary structure. DB2 V7 uses the currently allocated size of the SCA, Lock and GBP structures: When allocating a new Coupling Facility structure instance in response to a structure rebuild When allocating a secondary structure to support duplexing When allocating a new Coupling Facility structure, after the size was changed by a SETXCF START,ALTER command and the structure was subsequently deallocated. DB2 now stores the currently allocated size of the SCA and GBP structures in the BSDS and these sizes will be used when DB2 needs to allocate the structures. DB2 will use the INITSIZE, if no SETXCF START,ALTER,STRNM=strname,SIZE=size command was issued against the structure. Starting a new CFRM policy with a new INITSIZE will override the saved size of the structure. The lock and SCA structures already have a form of size persistence, since the structures remain allocated while all members of the Data Sharing group are stopped. Group buffer pools (GBP) on the other hand are not. If the entire data sharing group comes down, and all the Coupling Facility structures have been deallocated, when the group comes back up, the lock structure will go back to its INITSIZE and SCA and GBPs will be initialized to the last saved size.
175

Chapter 8. Data sharing

8.6 Miscellaneous items
In this section we describe some miscellaneous enhancements.

8.6.1 Notifying incomplete units of recovery during shutdown
DB2 V7 produces message DSNR046I during normal DB2 member shutdown, if indoubt or postponed abort units of recovery exists; there will be retained locks remaining due to the incomplete units of recovery. These retained locks will continue to block access to the affected DB2 data from other members. If this message is issued, then you may choose to immediately restart the DB2 member in order to resolve the incomplete units of recovery and remove the retained locks. This warning is given in addition to the existing DSNR036I message that notifies DB2 you at each DB2 checkpoint of any unresolved indoubt units of recovery.

8.6.2 More efficient message handling for CF/structure failure
DB2 V7 reduces the MVS to DB2 communication that occurs during a Coupling Facility/structure failure. Messages not needed by DB2 are no longer exchanged with MVS. This enhancement should improve CF/structure recovery time.

8.6.3 Automatic Alter for CF structures (Auto Alter)
This new function of OS/390 Version 2 Release 10 supports the automatic tuning of CF structure size and ratios of structure objects in response to changing structure object usage. You can define a structure's minimum and maximum sizes, and Auto Alter is then at liberty to expand or contract the structure only within those customer-specified boundaries. You also have control over the threshold percent full against which a structure is to be managed by Auto Alter, and if desired, the installation has the ability to turn off the Auto Alter function for a structure. Changes made by Auto Alter are passed to and saved by DB2; see section 8.5, “Persistent Coupling Facility Structure sizes” on page 175.

8.6.4 CF lock structure duplexing
With APAR PQ45407 IRLM 2.1 will connect to the IRLM lock structure with attributes allowing duplexing if properly defined in the CF Policy by the user. This duplexing is dependent on the System-Managed CF Structure Duplexing feature of z/OS V1R2.

8.6.5 CF lock structure size
The Coupling Facility lock structure contains two parts. The first part is a lock hash table used to determine if there is inter-DB2 read/write interest on a particular hash class. The second part is a list of the update locks that are currently held (sometimes called a modify lock list or record list table). With APAR PQ44144 the division of the lock structure storage between these two components can be controlled by the user through the value of the new parameter HASH in the irlmproc or IRLM MODIFY command

176

DB2 for z/OS and OS/390 Version 7 Performance Topics

SET. HASH can have a value of blank.Description The value of HASH represents the number of hash entries required in the lock hash table of the CF Lock structure in units of 1048576. thereby making them available for update. it should be used only after understanding what the resources are and the consequence to data integrity if they are deleted. The command causes all retained locks for the specified DB2 to be deleted from the system. 8.0. Data sharing 177 .PURGE command releases IRLM locks retained due to a DB2. padded if necessary. or EXEC VALUES (CURRENT MEMBER) INTO :MEMB. Chapter 8.6. If you plan to change the value for the parameter HASH. The value from the HASH parameter in the IRLMPROC if > 0.6. validate the lock structure sizing with IBM support. Both of these are dictated by the first IRLM to connect to the group during initial structure allocation or during a REBUILD: The value specified on the MODIFY irlmproc.6 Purge retained locks The MODIFY irlmproc. Recommendation Choose a value for the INITSIZE of the CF Lock structure that is a power of 2. which determines the nearest power of 2 after dividing the XES structure size returned on the IXCQUERY call by 2 * hash width based on MAXUSRS. In non data sharing environments the returned value is a string of blanks. or system failure. This new register can be useful in several cases: For applications that need to know if the DB2 they are connected to is a member of a data sharing group or not When merging DB2 subsystems with applications that have logic pointing to the initial location name When assigning partitions of data to separate members in order to avoid insert hot spots This function is provided by PTF UQ51114 for APAR PQ44671. or any exact power of 2 up to a maximum of 1024.7 CURRENT MEMBER register A new special register is now provided to return the DB2 member name of the subsystem on which the statement is executing. The existing logic. IRLM.HASH= command if > 0. This enables IRLM to allocate the Coupling Facility storage so that half will be used for lock hash table entries and the remainder for the record table entries. a value of HASH=32 would result in a hash table size of 64MB assuming the width of each hash entry to be 2 bytes. To set a host variable MEMB to the current DB2 member name: EXEC SQL SET:MEMB = CURRENT MEMBER. The value of this register is a string of eight characters. 8. Since retained locks protect updated resources. For example. The number of HASH entries for the group is used in the following order and the width is controlled by the MAXUSRS value.

178 DB2 for z/OS and OS/390 Version 7 Performance Topics .

including: the new UNLOAD utility. Performance tools This chapter provides a functional description of the performance related enhancements to performance tools in DB2 V7: IFI enhancements for V7: Several new IFCIDs have been added. and scrollable cursors. DB2 Estimator: Several new DB2 for OS/390 V7 functions have been added to DB2 Estimator. others have changed. the existing indexes. Index Advisor: This is an extension of the DB2 for UNIX and Windows optimizer that provides recommendations for indexes based on the tables and views defined in the database. Unicode encoding scheme. more parallel LOAD of partitions. 2001 179 . © Copyright IBM Corp. the FETCH FIRST n ROWS ONLY clause. and the SQL workload. DB2 PM changes and new functions: Statistics and accounting records have been improved to help in identifying the event involved. new built-in functions. and the DSNZPARM has a new parameter to help in synchronizing the writing of IFCID records.9 Chapter 9.

The record contains the list name and size in bytes as well as the list type. The list type is T for a table space list. See 4. they will overflow to another IFCID 217 record. IFCID 0219 Each time a LISTDEF is used by a utility it is recorded by this IFCID.1 IFI enhancements This section details changes to the Instrumentation Facility Interface (IFI). and the template name. writes. The description of this IFCID is shown in Figure 9-1. and the number of times an end of volume condition occurred during writing. This is followed by information on each DBM1 storage pool and each agent storage pool. 9. the total Getmained stack storage and the total Getmained storage.1 New IFCIDs A number of new IFCIDs are added in Version 7.3. Records use of LISTDEFs by utilities. Records information about dynamically allocated utility output datasets. Summary of storage usage in DBM1 address space.9.2. It also contains the number of reads. It contains the DD name. “Database address space — virtual storage consumption” on page 92 for some more information.1. Records Kerebos security translation of user IDs. 180 DB2 for z/OS and OS/390 Version 7 Performance Topics . I for an index space list. Correlation ID. the amount of storage for MVS use. the device type (disk or tape) and the I/O wait time in milliseconds for the data set are also recorded. IFCID 0225 This record summarizes the information from IFCID 0217. IFCID 0217 This record details the amount of available storage in the DBM1 address space. the total storage used is recorded. For agent pools. The description of this IFCID is shown in Figure 9-2. the thread is identified by Authorization ID. and Plan Name. If there are more than 250 such pool entries. and check macro invocations. or M for a mixed list. Connection Name. These are summarized in Table 9-1. Table 9-1 New IFCIDs IFCID 0217 0219 0220 0225 0319 Trace Type Global Audit Performance Audit Performance Statistics Audit Class 10 8 10 8 10 6 8 Description Records detailed information about storage usage in the DBM1 address space. IFCID 0220 This record is written whenever a dynamically allocated utility data set is closed. the data set name. For each pool. The timestamp of the first open for the data set.

/* THE END USER'S TRANSACTION NAME*/ * 3 QW0217QW CHAR(18). /* CONNECTION NAME */ * 3 QW0217QP CHAR(8). /* # OF DEFERRED WRITE ENGINES */ Figure 9-1 IFCID 0217 description Chapter 9. /* THE END USER'S WORKSTATION NAME*/ * 3 * FIXED(16). /* 1=MORE QW02172 DATA WILL FOLLOW*/ * /* 0=THIS IS THE LAST QW02172 DATA*/ * 3 * FIXED(8). /* 1=CHILD TASK FOR PARALLELISM */ * 3 * FIXED(8). /* (S) */ * 3 QW0217QC CHAR(8). /* # OF CASTOUT ENGINES */ * 3 QW02174E FIXED(32). /* STORAGE CLASS */ * 3 QW02173P FIXED(8). It records the SNA or TCP/IP address from which the request originated and the User ID assigned. /* IFCID(QWHS0217) HEADER */ * 3 QW0217AV FIXED(32). /* STORAGE CLASS */ * 3 QW0217BP FIXED(8). /* MVS SUBPOOL */ * 3 QW0217FL BIT(8). /* (S) */ * 3 QW0217ST FIXED(32). /* Reserved */ * DCL 1 QW02174 BASED BDY(WORD). /* STORAGE POOL DESCRIPTION */ * 3 * CHAR(8). /* AMOUNT OF AVAIL STORAGE */ * 3 QW0217MV FIXED(32). /* AUTHORIZATION ID */ * 3 QW0217QR CHAR(12). /* THE END USER'S USERID AT THE * USER'S WORKSTATION */ * 3 QW0217QX CHAR(32). /* POINTED TO BY QWT02R30 */ * 3 QW02173H FIXED(32). /* (S) */ * 3 QW02173T FIXED(32). /* TOTAL GETMAINED STACK STORAGE */ * 3 QW0217GM FIXED(32). At present this mapping only takes place when Kerberos security is used. /* FLAGS */ * 5 QW0217FX BIT(1). Performance tools 181 . /* # OF GBP WRITE ENGINES */ * 3 QW02174W FIXED(32). /* TOTAL GETMAINED STORAGE */ * 3 * CHAR(8). */ */********************************************************************/ * DCL 1 QW0217HE BASED BDY(WORD). /* Not used */ * 3 QW0217DE CHAR(24). */********************************************************************/ */* IFCID 0217 for storage manager pool statistics. /* STG RSRVD ONLY FOR MUST CMPLT */ * 3 QW0217SO FIXED(32). /* # OF ACTIVE ALLIED THREADS */ * 3 QW02174C FIXED(32). /* # OF PREFETCH ENGINES */ * 3 QW02174G FIXED(32). /* Not used */ * 3 * CHAR(8). /* POINTED TO BY QWT02R40 */ * 3 QW02174D FIXED(32). /* PLAN NAME */ * 3 QW0217QD CHAR(16). /* POINTED TO BY QWT02R20 */ * 3 QW0217PH FIXED(32). /* TOTAL DICTIONARY STORAGE */ * 3 QW02174T FIXED(32).IFCID 0319 When DB2 receives a non-RACF identity that represents a remote user. /* Not used */ * 3 QW02173C FIXED(32). /* TOTAL STORAGE IN THE POOL */ * 3 QW0217CL FIXED(8). /* Reserved */ * DCL 1 QW02173 BASED BDY(WORD). /* TOTAL STORAGE IN THE POOL */ * 3 QW02173L FIXED(8). /* AMOUNT OF STG FOR MVS USAGE */ * 3 QW0217CR FIXED(32). /* MVS SUBPOOL */ * 3 QW02173F BIT(8). /* # OF P-LOCK/NOTIFY EXIT ENGINES*/ * 3 QW02174F FIXED(32). /* 1=PARENT TASK FOR PARALLELISM */ * 5 QW02173I BIT(1). /* TOTAL STORAGE IN THE AGENT LOCAL * POOLS */ * 3 QW02174A FIXED(32). /* 1=VARIABLE-STORAGE POOL */ * 5 QW0217LS BIT(1). it maps that identity to a local User ID for use in connection processing. /* 1=VARIABLE-STORAGE POOL */ * 5 QW02173S BIT(1). /* 1=FIXED-STORAGE POOL */ * 5 QW02173R BIT(1). /* STG CUSHION WARNING TO CONTRACT*/ * 3 QW0217AL FIXED(32). /* 1=FIXED-STORAGE POOL */ * 5 QW0217VR BIT(1). /* FLAGS */ * 5 QW02173X BIT(1). /* CORRELATION ID */ * 3 QW0217QN CHAR(8). This IFCID records that mapping. /* Reserved */ * DCL 1 QW02172 BASED BDY(WORD). /* 1=MORE QW02172 DATA WILL FOLLOW*/ * /* 0=THIS IS THE LAST QW02173 DATA*/ * 5 QW02173A BIT(1).

These record are now written for each subtask of a utility that uses multiple subtasks (REORG and LOAD). Page P-lock counters recorded at the Group Bufferpool level. /* TOTAL BM/DM INTERNAL TRACE * TABLE STORAGE */ * 3 QW0225VR FIXED(32). /* TOTAL RID POOL STORAGE */ * 3 QW0225SB FIXED(32). 0024. Page P-lock counters recorded at the Group Bufferpool level. /* TOTAL STATEMENT CACHE BLK STG */ * 3 QW0225SC FIXED(32). 0025 0106 0147 0148 0150 Changes Field added to record number of -SET SYSPARM commands executed. /* TOTAL RDS OP POOL STORAGE */ * 3 QW0225RP FIXED(32). /* # OF CASTOUT ENGINES */ * 3 QW0225DW FIXED(32). /* AMOUNT OF AVAIL STORAGE */ * 3 QW0225CD FIXED(32). /* IFCID(QWHS0225) */ * 3 QW0225AL FIXED(32). An on-line monitor can restrict the records returned to either only locks with waiters or only locks in which multiple agents have an interest. MODIFY HISTORY. */ */********************************************************************/ * DCL 1 QW0225 BASED BDY(WORD). More granular information on wait times for global locks.2 Changed IFCIDs Table 9-2 summarizes the changes to existing IFCIDs. /* TOTAL FIXED STORAGE */ * 3 QW0225GM FIXED(32). /* # OF PREFETCH ENGINES */ * 3 QW0225PL FIXED(32).*/********************************************************************/ */* IFCID 0225 for storage manager pool statistics. SYNCVAL parameter value added. /* TOTAL GETMAINED STACK STORAGE */ * 3 QW0225MV FIXED(32). /* TOTAL COMP DICTIONARY STORAGE */ * 3 QW0225CR FIXED(32). More granular information on wait times for global locks.1. 182 DB2 for z/OS and OS/390 Version 7 Performance Topics . /* # OF DEFERRED WRITE ENGINES */ * 3 QW0225GW FIXED(32). /* TOTAL AGENT SYSTEM STORAGE */ * 3 QW0225AV FIXED(32). More granular information on wait times for global locks. Fields added to track DDF block fetch. /* TOTAL PIPE MANAGER SUBPOOL STG */ * 3 QW0225RO FIXED(32). Page P-lock counters recorded at the Group Bufferpool level. /* TOTAL STORAGE FOR THREAD COPIES * OF CACHED SQL STATEMENTS */ * 3 QW0225SO FIXED(32). /* STG RSRVD ONLY FOR MUST CMPLT */ * 3 QW0225FX FIXED(32). /* AMOUNT OF STG FOR MVS USAGE */ * 3 QW0225PM FIXED(32). and COPY2COPY). /* Reserved */ Figure 9-2 IFCID 0225 description 9. /* # OF GBP WRITE ENGINES */ * 3 QW0225PF FIXED(32). /* TOTAL AGENT LOCAL POOL STORAGE */ * 3 QW0225AS FIXED(32). They are also written for the new utilities (UNLOAD. Add flags to track keywords used in utility invocation. Table 9-2 Changed IFCIDs IFCID 0001 0002 0003 0022 0023 0023. Field added to record number of times pages were added to LPL. Fields added corresponding to new PLAN_TABLE columns. /* TOTAL GETMAINED STORAGE */ * 3 QW0225GS FIXED(32). /* TOTAL VARIABLE STORAGE */ * 3 QW0225AT FIXED(32). /* # OF P-LOCK/NOTIFY EXIT ENGINES*/ * 3 * CHAR(8). /* STG CUSHION WARNING TO CONTRACT*/ * 3 QW0225TT FIXED(32). /* # OF ACTIVE ALLIED THREADS */ * 3 QW0225CE FIXED(32).

See Figure 9-3. 0148: global contention The Class 3 wait time for global contention (data sharing only) was reported as a single value in Version 6. These counters record the following: Number of page P-lock requests for space map pages Number of page P-lock requests for data pages Number of page P-lock requests for index leaf pages Number of page P-lock unlock requests Number of page P-lock suspensions for space map pages Number of page P-lock suspensions for data pages Number of page P-lock suspensions for index leaf pages The Statistics Trace also includes the following additional counters: Number of page P-lock negotiations for space map pages Number of page P-lock negotiations for data pages Number of page P-lock negotiations for index leaf pages This information will be reported by DB2 PM V7 when APAR PQ46636 is applied. 0003. Performance tools 183 . Chapter 9.IFCID 0254 0312 0313 0314 Changes This IFCID. 0147. IFCIDs 0003. Field added to indicate if long running UR was detected by number of checkpoints (parameter URCHKTH) or number of log records written (parameter URLGWTH). IFCIDs 0002. Field added to record DBADM authority on database. which records statistics for a CF cache structure (Group Buffer Pool) is now written at the Statistics Interval. 0148: page P-lock counters New counters are used for both Statistics and Accounting traces to record detail on page P-lock requests in a data sharing environment. It is added to Statistics Class 5. This record is no longer written.

000000 0.00 0.LOG(QUIES) ARC.004165 0.000000 0.00 0.000000 0.00 0.003100 0.00 2.000000 0.000000 0.00 0.000000 0.00 1.000000 0.00 0.004165 0.00 1.00 0.000000 0. or row) Waits for other L-locks Waits for pageset and partition P-locks Waits for page P-locks Waits for other P-locks This information will be reported by DB2 PM V7 when APAR PQ46636 is applied.000000 0.000000 0. I/O DATABASE I/O LOG WRITE I/O OTHER READ I/O OTHER WRTE I/O SER.00 3. or partition) Waits for child L-locks (page.00 0.000000 0.00 0.00 0.00 0.000000 0.000000 0.000000 0.007265 AV.000000 0. table space.EVENT -------0.000000 0.00 Figure 9-3 DB2 PM Accounting Class 3 In Version 7 this is now broken down into a number of pairs of elapsed time and event counters as follows: Waits for parent L-locks (database.00 0. 184 DB2 for z/OS and OS/390 Version 7 Performance Topics .LOG READ STOR. FORCE-AT-COMMIT ASYNCH IXL REQUESTS TOTAL CLASS 3 AVERAGE TIME -----------0.00 0.003100 0.00 0.000000 0.00 0.CLASS 3 SUSPENSIONS -------------------LOCK/LATCH(DB2+IRLM) SYNCHRON.00 0.00 0.00 0.PRC SCHED UDF SCHEDULE DRAIN LOCK CLAIM RELEASE PAGE LATCH NOTIFY MSGS GLOBAL CONT.00 0.TASK SWTCH UPDATE COMMIT OPEN/CLOSE SYSLGRNG REC EXT/DEL/DEF OTHER SERVICE ARC.000000 0.00 2.000000 0. table.

as shown in Figure 9-4. NO. YES. NO. DSNTIPN INSTALL DB2 ===> _ Enter data below: 1 AUDIT TRACE ===> 2 TRACE AUTO START ===> 3 TRACE SIZE ===> 4 SMF ACCOUNTING ===> 5 SMF STATISTICS ===> 6 STATISTICS TIME ===> 7 STATISTICS SYNC ===> 8 DATASET STATS TIME ===> 9 MONITOR TRACE ===> 10 MONITOR SIZE ===> PRESS: ENTER to continue .1 Statistics Report Long DB2 PM Version 7 can report the data set I/O statistics gathered by IFCID 199. 20. 1-1440 Monitor classes to start.list Statistics classes to start.list Time interval in minutes.0-59 Time interval in minutes. NO. then Statistics records will be written at 5. It is set on the install panel DSNTIPN. NO.YES.YES. Acceptable values are NO and 0 to 59. 9. NO means no synchronization.YES. Performance tools 185 . and is the default. 4K-396K Accounting classes to start. A numeric value is the number of minutes past the hour at which Statistics records should be written. They can be printed using the Statistics Report Long using the keyword DSETSTAT. The new parameter SYNCVAL in the DSN6SYSP macro controls this option.list Global classes to start.3 DSNZPARM to synchronize IFI records The writing of Statistics Trace IFCIDs can be synchronized with the clock.YES.2 DB2 PM changes and new functions There are enhancements to both the Statistics and Accounting Reports of DB2 PM.1.2. 9. The parameter has no effect if the STATIME parameter is greater than 60.list Trace table size in bytes.TRACING PARAMETERS NO NO 64K 1 YES 30 NO 5 NO 8K Audit classes to start. and 50 minutes past each hour. It can also be used to synchronize between the DB2 statistics trace and RMF. 1-1440 Synchronization within the hour. 8K-1M HELP for more information RETURN to exit New SYNCVAL parameter Figure 9-4 DSNTIPN panel If STATIME=15 and SYNCVAL=5. 35. as shown in Figure 9-5. NO.9. Chapter 9. This parameter can be used to synchronize all members of a data sharing group so that they write their statistics trace records at the same times.list Default monitor buffer size.NO.

For each buffer pool. ASY I/O PGS AVG is the average number of pages read or written per asynchronous I/O. TYPE/GBP identifies the pageset as a table space (TSP) or an index space (IDX) and whether or not it is GBP-dependent (only relevant for DB2 data sharing). SYNCH I/O AVERAGE is the average number of synchronous I/Os per second.D I SP = S H R / / D P ML O G DD SY S O U T= A / / J O BS U M DD DD SY S O U T= A / / S Y SO U T DD SY S O U T= A / / S Y SI N DD * S T A T IS T I CS R E P OR T D SE T S T AT L AY O U T (L O N G) EXEC Figure 9-5 DB2 PM Statistics Report Long with data set statistics The data set statistics are reported after the buffer pool information. The DSETSTAT keyword was added to DB2PM V6 by APAR PQ37807.R E G IO N =0 M / / P M V5 1 0 E XE C PG M = D B2 PM / / S T EP L I B DD DS N = D B2 PM V 7 . SG 2 4 61 2 9. The restriction to the 10 most active data sets per buffer pool only applies to the DB2PM Statistics Report Long. NT ). 186 DB2 for z/OS and OS/390 Version 7 Performance Topics . SD G O LO A D. M S GC L AS S = T . D I SP = S HR / / I N PU T D D DD DS N = P AO LO R 7 . The equivalent asynchronous figures are per page. / / N OT I F Y= & SY S U ID . Trace records are generated for all data sets and the FILE and SAVE options will process all IFCID 199 trace records.C L AS S = A. T I ME =1 4 4 0 . The column DATABASE/SPACENAM/PART reports the pageset name and partition (or data set) number. Finally. SYN I/O AVERAGE DELAY/SYN I/O MAX DELAY are the average and maximum I/O time in milliseconds for synchronous I/Os. The output looks as shown in Figure 9-6. the current number of pages resident in the Virtual Buffer Pool and the Hiperpool are reported together with the number of updated and not yet written pages in the VBP./ / P A OL O R 7M JO B (9 9 9 . ASYNCH I/O AVERAGE is the average number of asynchronous I/Os per second. T R AC E A . only the 10 most active data sets by I/O are reported. ' D B 2P M ' .

00 0.00 0.32 SAMPLING END : 12/01/00 17:56:34.00 0.00 0.00 4.00 0.00 N/C 0.00 0.00 0.00 0.00 N/C 0.00 0.00 0.00 0.00 0.00 0.32 TOTAL COMMITS : 2188.00 7.00 0.00 0.00 0.00 0.00 1.00 N/C 0.HIGHLIGHTS ---------------------------------------------------------------------------------------------------INTERVAL START : 12/01/00 17:37:33.34 0.00 0.00 N/C 0.00 7.00 2.000000 DATA SHARING MEMBER: N/A BPOOL DATABASE SPACENAM PART -------DSNDB01 DBD01 1 DSNDB06 DSNATX02 1 DSNDB06 DSNDSX01 1 DSNDB06 DSNDTX01 1 DSNDB06 DSNDXX01 1 DSNDB06 DSNTTX01 1 DSNDB01 DSNSPT01 1 DSNDB01 SCT02 1 DSNDB01 SPT01 1 DSNDB01 SYSLGRNX 1 DB246129 TS612903 4 DB246129 TS612903 3 DB246129 TS612903 2 DB246129 TS612903 1 DSNDB07 DSN4K01 1 DSNDB07 DSN4K02 1 TYPE GBP ---TSP N IDX N IDX N IDX N IDX N IDX N IDX N TSP N TSP N TSP N TSP N TSP N TSP N TSP N TSP N TSP N SYNCH I/O AVG ASYNC I/O AVG ASY I/O PGS AVG --------------0.00 N/C SYN I/O AVG DELAY SYN I/O MAX DELAY ----------------14.35 TOTAL THREADS : 2189.00 0.00 0.00 21.00 0.00 0.11 0.00 0.00 0.00 INTERVAL ELAPSED: 19:00.00 0.00 ASYN I/O AVG DELAY ASYN I/O MAX DELAY -----------------0.00 0.00 1.00 21.00 46.00 0.31 0.00 0. Chapter 9.00 0.00 0.00 0.00 2.00 0.00 60.00 0.00 0.00 9.00 0.00 5.00 11.00 0.00 81.00 7.00 0.00 4.00 3.83 0.00 0.00 1.00 0.00 N/C 0.---.00 0.00 7.00 0.00 0.00 N/C 0.00 0.00 16.00 0.00 INTERVAL END : 12/01/00 17:56:34.00 0.00 0.00 4.00 2.00 14.00 0.00 0.00 0.00 0.00 0.00 18.00 0. as shown in Figure 9-7.00 81.00 65.00 N/C 8.00 N/C 0.00 0.00 N/C 0.00 5.00 18.00 0.00 0.00 0.00 1.00 28.00 4.00 0.00 N/C 0.00 N/C 8.00 N/C 0.00 4.35 SAMPLING START: 12/01/00 17:37:33.00 0.00 1.00 0.00 1.00 78.00 0.00 0. Performance tools 187 .00 0.00 2.00 0.00 N/C 18.00 16.00 0.00 0.00 0.00 N/C 7.00 0.00 1.00 1.00 0.00 ----BP0 BP0 BP0 BP0 BP0 BP0 BP0 BP0 BP0 BP0 BP1 BP1 BP1 BP1 BP7 BP7 Figure 9-6 DB2 PM Statistics Report data set statistics The IFCID 199 records can also be printed using a record trace.00 1.00 N/C 0.00 14.00 0.00 89.00 0.00 CURRENT PAGES (VP) CHANGED PAGES (VP) CURRENT PAGES (HP) -----------------40.00 0.00 0.00 0.00 0.00 0.00 0.00 0.977262 OUTAGE ELAPSED: 0.00 8.

DELAY I/O (MS) 3 AVG.00 0.00 0. DELAY I/O (MS) 4 AVG.PG LIST (RPL) RQ CLEAN PGS READ RPL CHANGED PGS READ RPL PGS READ FRM DASD AFTER RPL ASYN.16 |-------------------------------------------------------------------------------------------------------------------|DBID: 262 DBNAME: DBLP0001 GBP DEPENDEND: NO |OBID: 2 OBNAME: TSLP0001 TYPE OF DATASET: DATA |BPID: BP1 | |SYNC.I/O FOR WRITE.TSDD 'BLANK' 22:33:57.00 0.READ(NF)-NO DATA RETURN CLEAN PAGES SYN.00 0. then some additional information is reported in the Statistics Report and Trace for a data sharing environment as shown in Figure 9-8.00 0.00 0.00 0.SHORT REQUESTED FROM: NOT SPECIFIED MEMBER: N/P TO: NOT SPECIFIED SUBSYSTEM: DB2A ACTUAL FROM: 11/29/00 22:3 DB2 VERSION: V7 PAGE DATE: 11/29/00 0PRIMAUTH CONNECT INSTANCE END_USER WS_NAME TRANSACT ORIGAUTH CORRNAME CONNTYPE RECORD TIME DESTNO ACE IFC DESCRIPTION DATA PLANNAME CORRNMBR TCB CPU TIME ID -------.00 0. READ.READ-DATA RETURNED PAGES CASTOUT EXPLICIT X-INVALIDATIONS CASTOUT CLASS THRESH GROUP BP CAST.READ(XI)-DATA RETURNED SYN.-------------. CASTOUT BUFFER POOL CACHED PAGES |AVG. DELAY I/O (MS) 3 VPOOL CACHE CURR.-------. The new item is titled GBP-DEPENDENT GETPAGES and is reported for each Group Buffer Pool.THRESH CASTOUT ENG.--. DELAY I/O (MS) 2 VPOOL CACHE CURR.00 0.RECTRACE TRACE LEVEL(SHORT) INCLUDE (IFCID(199) SUBSYSTEMID(DB2A)) EXEC LOCATION: DB2A DB2 PERFORMANCE MONITOR (V7) PAGE: 1-1 GROUP: N/P RECORD TRACE . 0 | TOTAL I/O COUNT 34 |--------------------------------------------------------------------------------------------------------------------|DBID: 262 DBNAME: DBLP0001 GBP DEPENDEND: NO |OBID: 2 OBNAME: TSLP0001 TYPE OF DATASET: DATA |BPID: BP1 | |SYNC.00 0.-----------------------------------------------SYSOPR DB2A B504F3F391C9 'BLANK' 'BLANK' 'BLANK' SYSOPR 010. DELAY I/O (MS) 15 VPOOL CACHE CHANGED 55 |TOTAL I/O PAGES 201 TOTAL I/O PAGES 786 HPOOL CACHE CURR.WRTN CHANGED PGS SYN.00 0.-----.00 0. GROUP BP0 --------------------------GROUP BP HIT RATIO (%) GBP-DEPENDENT GETPAGES SYN.00 0.I/O FOR WRITE.WRT REG.READ(XI)-NO DATA RETURN SYN. DELAY I/O (MS) 96 MAX.UNAVAIL.00 Figure 9-8 Statistics report GBP information 188 DB2 for z/OS and OS/390 Version 7 Performance Topics .--.00 0.00 0.WRT CHANGED PGS ASYN. CASTOUT BUFFER POOL CACHED PAGES |AVG.I/O FOR WRITE AND READ ASYNC. DELAY I/O (MS) 15 VPOOL CACHE CHANGED 0 |TOTAL I/O PAGES 216 TOTAL I/O PAGES 857 HPOOL CACHE CURR.00 0. DELAY I/O (MS) 136 MAX.READ(NF)-DATA RETURNED SYN.I/O FOR WRITE AND READ ASYNC. READ FAILED-NO STOR.WRTN CLEAN PAGES ASYN. WRITE ENG.00 0. It is used to indicate the degree of data sharing.00 0. 82 |MAX.16386089 53 1 199 ACT.UNAVAIL. 100 |MAX. READ.00 0.00 0. DATASETS NETWORKID: DB2A LUNAME: SCPDB2A LUWSEQ: 'BLANK' BP01 N/P |-------------------------------------------------------------------------------------------------------------------|TIME LSTATS STARTED 11/29/00 22:33:57. 0 | TOTAL I/O COUNT 32 Figure 9-7 IFCID 199 record trace If APAR PQ43357 is applied to DB2 PM. It records the number of getpages performed for GBP-dependent objects.----------.00 0. WRITE FAILED-NO STOR QUANTITY -------N/C 0.----------------.

00 7.00 0.00 0. DATA PAGES: The number of page P-lock lock suspensions for data pages. Performance tools 189 .01 /THREAD ------0.DB2 PM V7 also has a new section containing page P-lock detail.13 0.00 0.30 0. INDEX LEAF PAGES: The number of page P-lock lock negotiations for index leaf pages.02 0.00 0. as shown in Figure 9-10.00 /SECOND ------0.01 0.33 /COMMIT ------0. PAGE P-LOCK LOCK SUSP: The sum of all page P-lock lock suspensions.01 Figure 9-9 Statistics report P-lock detail Here are the definitions of the items on the P-lock detail: PAGE P-LOCK LOCK REQ: The sum of all page P-lock lock requests.01 0. which can be broken down further as follows: SPACE MAP PAGES: The number of page P-lock lock requests for space map pages.00 0. DATA PAGES: The number of page P-lock lock requests for data pages.23 0.01 0. These are the new items in the Class 3 times.00 27. The Statistics Report Long will also.00 9. The new Storage Statistics section of the report will look something like Figure 4-5 on page 92.2 Accounting Report The Accounting Report shows more detail for the Class 3 times and highlights.01 0.00 1. DATA PAGES: The number of page P-lock lock negotiations for data pages. by Group Buffer Pool. INDEX LEAF PAGES: The number of page P-lock lock requests for index leaf pages.00 0.2.00 4. GROUP BP0 CONTINUED ---------------------PAGE P-LOCK LOCK REQ SPACE MAP PAGES DATA PAGES INDEX LEAF PAGES PAGE P-LOCK UNLOCK REQ PAGE P-LOCK LOCK SUSP SPACE MAP PAGES DATA PAGES INDEX LEAF PAGES PAGE P-LOCK LOCK NEG SPACE MAP PAGES DATA PAGES INDEX LEAF PAGES QUANTITY -------6. which can be broken down further as follows: SPACE MAP PAGES: The number of page P-lock lock negotiations for space map pages.01 0.20 0.00 5.00 0.00 8.27 0. INDEX LEAF PAGES: The number of page P-lock lock suspensions for index leaf pages.00 0.00 18.00 2.00 0.00 10.01 0.04 0. which can be broken down further as follows: SPACE MAP PAGES: The number of page P-lock lock suspensions for space map pages.10 0. include the DBM1 storage information from IFCID 225.00 3.17 0.01 0.01 0. in the near future.03 0.01 0.20 0. as shown in Figure 9-9.60 0.00 0. PAGE P-LOCK UNLOCK REQ: The number of page P-lock unlock requests. introduced by DB2 in Version 6: Chapter 9. 9.90 0.01 0.07 0. PAGE P-LOCK LOCK NEG: The sum of all page P-lock lock negotiations.02 0.00 6.01 0.

00 0.00 0.LOG READ STOR.004165 0.000000 0.003100 0.000000 0. I/O is the time spent waiting for log write during Phase 1 of a Two-Phase Commit. #SVPT RELEASE: The number of RELEASE SAVEPOINT requests executed.00 0.000000 0.000000 0.00 0.FORCE-AT-COMMIT: The time spent waiting for LOB values to be written to the LOB table space at commit. FORCE-AT-COMMIT ASYNCH IXL REQUESTS TOTAL CLASS 3 AVERAGE TIME -----------0.00 0.000000 0.This includes any wait for log write.00 SYNCH I/O AVG.00 0.00 0.00 0. : 0.000000 0.00 0. : 0 #NO PROGRAM DATA: 0 #NORMAL TERMINAT: 1 #ABNORMAL TERMIN: 0 #CP/X PARALLEL. The new items in the Highlights section are: #SVPT REQUESTS: The number of SAVEPOINT requests executed. 190 DB2 for z/OS and OS/390 Version 7 Performance Topics .000000 0.00 0. TASK SWTCH is the time spent during Phase 2 of a Two-Phase Commit or during a One-Phase Commit (Synchronization Commit).000000 0.007265 AV.00 0.00 0. I/O DATABASE I/O LOG WRITE I/O OTHER READ I/O OTHER WRTE I/O SER.000000 0.00 1.000000 0.00 HIGHLIGHTS -------------------------#OCCURRENCES : 1 #ALLIEDS : 1 #ALLIEDS DISTRIB: 0 #DBATS : 0 #DBATS DISTRIB.000000 0.000000 0.TASK SWTCH UPDATE COMMIT OPEN/CLOSE SYSLGRNG REC EXT/DEL/DEF OTHER SERVICE ARC.00 0.00 0.00 0. The FORCE-AT-COMMIT figure is the time spent writing LOB values back to the LOB table space at Commit.00 2.000000 0. The UPDATE COMMIT figure under SER. : 0 #IO PARALLELISM : 0 #INCREMENT. #SVPT ROLLBACK: The number of ROLLBACK TO SAVEPOINT requests executed.LOG(QUIES) ARC.00 3.EVENT -------0.000000 0.000000 0.000000 0.004165 0.000000 0.00 0.000000 0. Note that FORCE-AT-COMMIT does not include time spent writing pages to the Group Buffer Pools at Commit in a data sharing environment.PRC SCHED UDF SCHEDULE DRAIN LOCK CLAIM RELEASE PAGE LATCH NOTIFY MSGS GLOBAL CONT.00 2.00 0.001550 Figure 9-10 Accounting report Class 3 changes Waits for Commit are now reported in three places in the Class 3 times: The LOG WRITE I/O figure under SYNCHRON.00 0.000000 0. BIND: 0 #COMMITS : 1 #ROLLBACKS : 0 #SVPT REQUESTS : 0 #SVPT RELEASE : 0 #SVPT ROLLBACK : 0 MAX SQL CASC LVL: 0 UPDATE/COMMIT : 0. CLASS 3 SUSPENSIONS -------------------LOCK/LATCH(DB2+IRLM) SYNCHRON. ASYNCH IXL REQUESTS: The time spent waiting for asynchronous IXLCACHE and IXLFCOMP requests in a data sharing environment.00 1.003100 0.

-.TS.00 00 00 0 . The number of wait trace events processed for waits for global contention for child L-locks.LO CKS -.00 00 00 0 . These will be reported if APAR PQ46636 is applied.-0 .-.-. 00 0. TA B. OTHER: The accumulated wait time due to global contention for other P-locks. tablespace.--.--. The number of wait trace events processed for waits for global contention for page P-locks.--.-0. shown in Figure 9-11.-.-0.--. 00 0.-.--.00 00 00 0 . Performance tools 191 .00 00 00 0 .-.00 00 00 0 .-. G lo b a l c o n te n tio n o n L -lo c k s : GL OBA L C ON TEN TIO N L.-.-.-.LOC KS PA GES ET /PA RT IT IO N PA GE OT HER A VE RA GE TI ME .--P. The accumulated wait trace events processed for waits for global contention of all L-locks. Parent L-locks are any of these L-lock types: database.--L.-.00 00 00 0 . The accumulated wait trace events processed for waits for global contention of all P-locks. Chapter 9.-. then additional information will be reported for the Accounting Report and Trace in a data sharing environment. PARENT (DB. partition. table.LO CKS -.-.-.--.--. The number of wait trace events processed for waits for global contention for parent L-locks.-. The definitions of the P-lock items are as follows: P-LOCKS: The accumulated wait times due to global contention for all P-locks. The components of Class 3 Global Contention wait time are reported in two new sections.-. PAGESET/PARTITION: The accumulated wait time due to global contention for pageset/partition P-locks.-.LOC KS PA REN T (DB .--.--. 00 0.-. CHILD: The accumulated wait time due to global contention for child L-locks.--. EVE NT . 00 0. 00 0. The number of wait trace events processed for waits for global contention for other P-locks.--. EVE NT . The number of wait trace events processed for waits for global contention for other L-locks.00 00 00 A V. OTHER: The accumulated wait time due to global contention for other L-locks.--. 00 Figure 9-11 Accounting global contention detail The definitions of the L-lock items are as follows: L-LOCKS: The accumulated wait times due to global contention for all L-locks. 00 G lo b a l c o n te n tio n o n P -lo c k s : GL OBA L C ON TEN TIO N P.--.-.00 00 00 A V.If APARs PQ43357 and PQ46636 are applied to DB2 PM. PAGE: The accumulated wait time due to global contention for page P-locks. The number of wait trace events processed for waits for global contention for pageset/partition P-locks.-.P ART ) CH ILD OT HER A VE RA GE TI ME .T S.-.PART): The accumulated wait time due to global contention for parent L-locks.TAB.-. Child L-locks are any of these L-lock types: page. 00 0. row.-0 .-.--.-.

3 Index Advisor The Index Advisor is part of DB2 UDB for UNIX. It is an extension of the DB2 UWO Optimizer. GROUP BP0 AVERAGE TOTAL -------------------.-------GBP-DEPEND GETPAGES N/A N/A READ(XI)-DATA RETUR 0.00 0 UNREGISTER PAGE 0. as shown Figure 9-12.00 0 PG P-LOCK LOCK REQ 0.00 0 EXPLICIT X-INVALID 0.Further information on page P-locks will be reported. DATA PAGES: The number of page P-lock lock requests for data pages.00 0 DATA PAGES 0.00 0 ASYNCH GBP REQUESTS 0. DATA PAGES: The number of page P-lock lock suspensions for data pages.00 0 INDEX LEAF PAGES 0. PG P-LOCK UNLOCK REQ: The number of page P-lock unlock requests. Windows. It is used to indicate the degree of data sharing.00 0 INDEX LEAF PAGES 0. This is further broken down by type of page: SPACE MAP PAGES: The number of page P-lock lock requests for space map pages.00 0 PG P-LOCK LOCK SUSP 0.00 0 CLEAN PAGES WRITTEN 0.00 0 CHANGED PAGES WRTN 0.00 0 WRITE TO SEC-GBP 0.00 0 ASYNCH SEC-GBP REQ 0. and OS/2 (DB2 UWO). It makes recommendations for indexes based on: The tables and views defined in the database The existing indexes The SQL workload 192 DB2 for z/OS and OS/390 Version 7 Performance Topics .00 0 SPACE MAP PAGES 0. This is further broken down by type of page: SPACE MAP PAGES: The number of page P-lock lock suspensions for space map pages.00 0 PG P-LOCK UNLOCK REQ 0.00 0 READ(XI)-NO DATA RT 0.00 0 Added by APAR PQ43357 Added by APAR PQ46636 Figure 9-12 Accounting GBP information The definitions of the new items are as follows: GBP-DEPEND GETPAGES: The number of getpages done for GBP-dependent objects. INDEX LEAF PAGES: The number of page P-lock lock requests for index leaf pages.00 0 READ(NF)-NO DATA RT 0. 9. The GBP-DEPEND GETPAGES is added by APAR PQ43357. if APAR PQ46636 is applied. PG P-LOCK LOCK REQ: The number of all page P-lock lock requests.00 0 PREFETCH PAGES READ 0.00 0 READ(NF)-DATA RETUR 0. INDEX LEAF PAGES: The number of page P-lock lock suspensions for index leaf pages.-------.00 0 SPACE MAP PAGES 0. PG P-LOCK LOCK SUSP: The sum of all page P-lock lock suspensions.00 0 DATA PAGES 0.

1 Index Advisor process for DB2 for z/OS and OS/390 The process consists of: A set of tools to capture DB2 for OS/390 metadata. and SQL workload A procedure for creating the model and using Index Advisor to analyze it This process is shown in Figure 9-13. The SQL workload is a group of related SQL statements processed over a period of time. 9. catalog statistics. The workload is stored in a workload table for input to the Index Advisor. DB2 for z/OS is supported by modeling a DB2 for z/OS subsystem on a DB2 UWO system. views.The recommendations provide before and after costs and the DDL to create the recommended indexes. calculated as (frequency * importance) The Index Advisor process is being extended to support DB2 for z/OS and OS/390 Version 7. Performance tools 193 . thus allowing Index Advisor to analyze the model. Each SQL statement has associated with it: Its frequency (how often it executes) Its importance (business importance — set manually) Its weight.3. indexes) DB2 UWO Catalog statistics DB2 for OS/390 SQL workload DBA Recommendations Create Index Index Advisor Figure 9-13 Index Advisor process for DB2 for z/OS and OS/390 Chapter 9. The software prerequisites are: DB2 for z/OS and OS/390 Version 7 DB2 for UWO Version 7 DB2 Connect System configuration parameters Metadata (tables.

views. Calls dynamic workload collector (DSNZSCH).3. Drops and recreates workload formatter tables. A number of jobs are provided to set up and execute this process.3. 4. Run job DSNTEJWF on the mainframe.3 Collecting the SQL workload You must identify an appropriate time period over which to collect workload data. Then you need to do the following: 1. 3. 2. and index definitions can be imported to the modeling database using the db2look command. 9. Starts traces for IFCIDs 0316 and 0317. The db2look command is a DB2 UWO tool. DSNTEJWD DSNTEJWF 194 DB2 for z/OS and OS/390 Version 7 Performance Topics . Guidelines are provided for setting the parameters. Use DB2 UWO LOAD to load the data to the Index Advisor Workload table. Extracts SQL statements from workload collector tables and reformats them into the format expected by the Index Advisor. In Version 7 it is enhanced to allow connection to DB2 for OS390 using dynamic bind.The process alters certain configuration settings of the database manager for the DB2 UWO instance that is used to model the DB2 for OS/390 subsystem Therefore it is recommended that a dedicated DB2 UWO instance be used for the DB2 for z/OS and OS/390 Index Advisor process. Reads these IFCIDS via IFI and inserts them to the workload collector tables on DB2 for OS/390. These are described briefly in Table 9-3. 9. It accesses the DB2 for OS/390 Catalog and generates: DDL for tables. view. Use DB2 UWO EXPORT to transfer data from mainframe to the DB2 UWO workstation. and indexes DML for propagating the Catalog statistics You can use the DB2 UWO Command Line Processor to process the DDL and DML files. Table 9-3 Index Advisor workload collection jobs Job DSNTEJWA DSNTEJWB DSNTEJWC Description Binds plans for workload collector and formatter programs. Run job DSNTEJWC on the mainframe.2 Modeling DB2 for z/OS and OS/390 You must create a modeling database on DB2 UWO and update the configuration parameters to mimic DB2 for OS/390. The application table. Drops and recreates workload collector tables. Calls dynamic workload formatter (DSNZSCJ). Inserts reformatted statements into workload formatter tables.

you can either use the Index SmartGuide.3. that is with CACHEDYNAMIC(YES) specified in your DNSNZPARM. It will also support workload collection for static SQL. The Index Advisor does not provide recommendations. The initial implementation of the Index Advisor supports dynamic SQL with dynamic statement caching enabled. not least in that they have different Optimizers. Be aware that there are differences between DB2 UWO and DB2 for OS/390.3. However. You will still need to decide the best index for clustering or partitioning. Performance tools 195 . The index space restrictions limit the completeness of the results. This will include a Control Center front end that provides increased automation of tasks and formal task guidance for tasks that are not automated. You can adjust the inputs as required: Add/remove/change SQL statement text Change frequency and importance Specify index space restrictions Specify analysis time limit You can use the results to reaffirm your existing indexes and to ensure that you have not overlooked beneficial indexes.3. Running the advisor for a longer time or without time limit may result in even better index suggestions. Chapter 9. you can run the Index Advisor. 9. The software will be downloadable from the DB2 for OS/390 web site.9. 9. which is in the DB2 UWO Control Center under then Create Index tab. To do this.4 Running the Index Advisor Once the metadata and SQL workload has been set up on DB2 UWO. The index advisor is based on the DB2 UWO Optimizer and therefore its recommendations may ignore issues specific to DB2 for OS/390.6 Availability There will be an informal delivery of this facility with DB2 for z/OS and OS/390 Version 7.5 Considerations The analysis time limit affects the completeness of the results. Deactivating this limit will cause indexes to be recommended that improve performance regardless of the disk space required for the indexes. the criteria for determining good indexes is largely platform independent and therefore the recommendations of the Index Advisor will be appropriate to DB2 for OS/390 in most cases. A formal delivery is planned at some future date. or use the db2advis command directly from the command line.

If you have created and saved the results of a capacity run for exporting. including: the new UNLOAD utility. a new facility modifies the transaction environment after a transaction is created. Unicode encoding scheme. Remember that DB2 Estimator is included in the DB2 Management Clients Package no-charge feature of DB2 V7. The new ESS and RVA DASD devices and the latest S/390 CPUs have been added to the DB2 Estimator project configuration file.4 DB2 Estimator The Windows based DB2 capacity planning modeling tool. you can create a new index. more parallel LOAD of partitions. using the old answers only if they still are correct. README. new built-in functions.TXT file available from Start menu Table and index partitions taken into account by Capacity Runs window DB2 V7 UNLOAD utility DB2 V7 more parallel LOAD partitions DB2 V7 Scrollable Cursors DB2 V7 FETCH FIRST n ROWS ONLY. you can open the SQL item and proceed through the cardinality questions again. provides: Bulk table change window Bulk SQL parsing window Bulk SQL cardinality repair window New "Getting Started" document available from Start menu Product Help.com/software/data/db2/os390/estimate 196 DB2 for z/OS and OS/390 Version 7 Performance Topics . the FETCH FIRST n ROWS ONLY clause. and Fast Implicit Close DB2 V7 Self-referencing subselect on UPDATE/DELETE DB2 V7 Unicode encoding scheme DB2 V7 new built-in functions and special registers DB2 V7 FOR UPDATE clause. This menu item also produces a list of SQL items that are not in the desired CARDOK status. enhanced for DB2 V7. Tutorial program. The status can change from the desired CARDOK status to PARSEOK or even to PARSEFAIL status if a table referenced by the SQL item has changed in one of many ways. for newer versions of DB2 Estimator. The Capacity Runs window now reports table and index device busy information for an average partition of the partitioned table or index. The SQL items should be in CARDOK status after this process. If an SQL item was demoted from CARDOK status to PARSEOK status.9. which is easy to do in DB2 Estimator. you can use the new Predicate Analysis window to analyze transactions and their SQL to create a list of all predicates used and the number of times each predicate is used per second. Support for the LOAD RESUME utility has been added to DB2 Estimator. A new function creates transactions from imported SQL based on the program name or package name from which the SQL was extracted. The new "Quick Check/Update Status of SubProj SQL" menu item quickly checks the status of each SQL item and updates the SQL item's status if it has changed. However. MVS. In addition. This will show a reduction in device busy performance estimates effects due to partitioning.CFG. If the same predicates are used many times without an applicable index. without column list DB2 V7 Statistics History option Several new DB2 V7 functions have been added to DB2 Estimator. you should also check the Web site: ibm. and Scrollable Cursors. This menu item allows you to scroll down the sub-project's list of SQL items and see the actual SQL status for each SQL item.

2001 197 . In this chapter we discuss improvements not strictly internal to DB2 that still positively impact DB2 performance. DB2 and zSeries: DB2 benefits from large real memory support. Synergy with host platform DB2 has several functions that are capable of exploiting the functionalities of the z/OS and OS/390 platform.10 Chapter 10. FlashCopy is the ESS feature to use for DB2 cloning/backup in combination with log suspend/resume. faster processors and better hardware compression VSAM striping: Striping becomes available for VSAM data sets with DFSMS in OS/390 V2R10 ESS enhancements: The IBM Enterprise Storage Server (ESS) exploits the Parallel Access Volume and Multiple Allegiance features of OS/390. © Copyright IBM Corp.

10. 64-bit support in z/OS V1R1 provides 64-bit arithmetic and 64-bit real addressing support. Later releases of z/OS will support 64-bit virtual addressing which means support for 16 exabyte address spaces.1 DB2 and zSeries overview In this section we provide an overview of DB2 and zSeries. first shipped with DB2 Version 6. more powerful processors in z900.1 zSeries The zSeries 900 and z/OS V1R1 deliver immediate performance benefits to DB2 in terms of real storage exploitation. on its chip. the key benefit of scaling with the larger memory is in the use of data spaces. allowing 3 to 4 times fewer cycles than the G6 servers. hardware compression was made by microcode. without significant paging activity. The larger number of processors and additional storage will enable higher degrees of parallelism for qualifying queries in all current DB2 versions.1. The z900 Processing Units have a new unit. More DB2 subsystems can be supported on a single OS image. PQ25914 — With this APAR data space buffers are allowed to be page fixed above 2 GB without being moved. The increased real memory provides performance and improved scaling for all customers. Larger number of faster processors DB2 query parallelism is positioned to take advantage of the additional. This new implementation provides better hardware compression performance. Unicode Unicode support in DB2 Version 7 will be able to use the new hardware translation services provided through architecture expansion in future hardware. 198 DB2 for z/OS and OS/390 Version 7 Performance Topics . With Versions 6 and 7 of DB2. To benefit from larger real memory the following PTFs must be applied to exploit the use of 64-bit real addressing. OS/390 V2R10 will also deliver 64-bit real addressing support. Compression In the G5/G6 generation of 9672 servers. Data spaces allow for buffer pools and EDM pool global dynamic statement cache to reside outside of the DBM1 address space. 64 GB central storage All DB2 Versions will be able to receive immediate benefits from the increased capacity of central memory—up to 64 GB. Customers who are reaching the 2 GB address space limit should migrate to this solution.10. DB2 256 GB central storage support PTFs Data space buffer pools can add up to 32 GB of 4 KB page size pools and up to 256 GB of 32 KB page size pools. Now more data can be kept in memory. The z900 hardware is currently supporting up to 64 GB of real storage. the Compression Unit. All supported releases of DB2 are compatible with z/OS. which can help reduce I/O time. architecture. from the current limit of 2 GB. PQ36933 — Virtual pool buffers and log buffers that reside above 2 GB real storage will not be moved when they need to be page fixed for I/O.

The continued evolution of CMOS processor and memory technology in G5/G6 and now zSeries has improved the synchronous data movement using the Move Page instruction to the point where its performance is on a par with ADMF. Synergy with host platform 199 . depending on the test 2 dedicated processors (OLTP workload). z/OS V1R1 DB2 V7 Performance of buffer pools in data spaces in 31-bit mode This test was run to compare the cost of buffer pools in data spaces to traditional virtual buffer pools allocated in the DBM1 address space.com/software/data/db2/os390/support Large real storage performance In this section we cover various performance related features for large real storage.1. The size of the buffer pools was 800 MB in both cases and they were completely backed by 1. a second test was executed. 10. 31-bit measurements: 9672-ZZ7 (G6 turbo): 1. The elapsed times were equivalent but the CPU overhead of data spaces was measured up to 10%. We will summarize the results of these tests in this section.8 GB central storage (no paging). Hiper pools can still be used even if the ADMF facility is not configured. 4 dedicated processors (query workload) ESS and RAMAC3 disk OS/390 V2R10. Transferring pages from data spaces to the lookaside buffers in the DBM1 address space is responsible for the CPU overhead. as it is now called. Measurement environment Here we provide the 31-bit and 64-bit specifications. once with 1. 6 GB expanded storage 2 dedicated processors (OLTP-IRWW workload). Paging was expected to expanded storage and some to auxiliary storage. is now indicated by the APAR to DB2 so that Move Page is used in place of ADMF.2 Performance measurements A set of measurements were executed at SVL to demonstrate the performance benefits of the z/Series servers. The presence of this Fast Synchronous Data Mover Facility.000 table space pages. 4 dedicated processors (query workload) ESS and RAMAC3 disk OS/390 V2R10 DB2 V7 64-bit measurements: z900 model 2064-M116: 12 GB and 16 GB central storage. Chapter 10. DB2 without this APAR will also continue to use ADMF on G5/G6. see the white paper DB2 UDB for z/OS and OS/390 Performance on the IBM zSeries 900 server by David Witkowski.PQ38174 — The asynchronous data mover facility (ADMF) was invented to improve storage-to-storage movement of large sets of data pages. For a more detailed evaluation of DB2 performance on z/Series. A query scanned a six million rows from 200. DB2 will continue to use ADMF on pre-G5 machines.8 GB central storage.2 GB primary buffer pools and once with 6 GB buffer pools in data spaces. In order to measure the effect of paging. which is available from the Web site: ibm.

A query scanned 45 million rows from 1. Performance of buffer pools in data spaces in 64-bit mode The same 45 million row scan as in the previous experiment was executed. and the CPU overhead due to data spaces would be 12%. If we ran the same test with a 100% miss ratio. This is due tot the extra data movement between the primary pool and the hiperpool. Hiperpools are backed by central storage Read workload: From a 1 million page table space. The CPU time dropped by 27% and the elapsed time was cut by a factor of 50. Large buffer pools in data spaces not backed by real storage are not a good performing alternative and this test does not even demonstrate the worst case while almost all paging was done to expanded storage. the performance of hiperpools and data space buffer pools was observed to be equivalent. With a 100% buffer miss ratio.100% MISS 60 primary Elapsed time in seconds 1000 800 50 40 data space CPU time in seconds 600 400 200 data space . 30 million rows were read via a table space scan. The results from this test are shown in Figure 10-1.5 million table space pages. The CPU overhead of data spaces was up to 60% and the elapsed time was 4. but now the data was cached in the data space buffer pool in order to achieve a 100% hit ratio. again the elapsed times would be almost equivalent. 200 DB2 for z/OS and OS/390 Version 7 Performance Topics .5 times greater. Bpool in data spaces performance 64-bit 1200 primary .100% HIT 30 20 10 0 Elapsed time CPU time 0 Figure 10-1 Buffer pool in data spaces performance 64-bit Performance of hiperpools versus data spaces z/Architecture provides hiperpool support through the Fast Synchronous Data Mover. If both pool types were sized for a 100% buffer hit ratio it turned out that data space buffer pools were approximately 30% more efficient in terms of CPU and elapsed time.

See Figure 10-2 for the results. Synergy with host platform ecaps ataD looprepiH looprepih .sv loopb ecaps ataD UPC despalE 05 052 002 T mi 001 e ni s e c o n d s 051 0 201 . including I/O performance and buffer pool thresholds. Elapsed and CPU time were almost equivalent due to the absence of I/O. this query was repeated 20 times. Chapter 10. Single thread table scan We scanned 8 million rows from 290. The test with the data space buffer pool was only slightly more CPU efficient than the one with the hiperpool but the elapsed time was only half. adequate storage was available in order to avoid database I/O and system paging I/O. Measurement environment Here we provide specifications for the 9672 and z900 environments. A reduction of 20-25% in elapsed time and CPU was measured when moving this workload from G6 to z/900. were sized to hold the entire 1GB data in order to avoid read I/O. To eliminate the effect of noise.8 million getpages. Figure 10-2 Data space versus hiperpool update performance Compression performance In this section we cover compression performance features. 9672 environment: 9672-ZZ7 (G6 turbo) 4 dedicated processors OS/390 V2R10 DB2 V7 z900 environment: z900 model 2064-M116 4 dedicated processors OS/390 V2R10 DB2 V7 In both environments.Update workload: 7 million rows representing 1GB data were updated in this test. the hiperpool and the data space buffer pool. The exact degree of elapsed time benefit will depend on many factors. Both. resulting in DB2 having to perform 5.000 non-compressed table space pages.

In the non-compressed test case elapsed time was equivalent because the query had become I/O bound as a result of database and log write I/O. but now compressed.000 pages were inserted. CPU cost improved with 25%. 202 DB2 for z/OS and OS/390 Version 7 Performance Topics UPC despalE 009z 6G 0 008 006 004 002 0021 0001 T mi e ni s e c o n d s . In the compressed test case CPU time was reduced by 40% and this reduction was significant enough to account for an elapsed time reduction of 30%. See Figure 10-4 for the results of these measurements. Compression performance G6 vs z900 single thread table scan Figure 10-3 Single thread table scan performance — compressed data Insert subselect performance An insert taking 4. Overhead of compression showed to be reduced from 42% on G6 to only 12% on a z900 server. This compares to 65. CPU overhead for decompression is reduced 3 to 4 times on z/900 compared to the G6 machine. The same 160 million rows were scanned. but this time from 4.6 million getpages. In non-compressed form 142. Elapsed time and CPU cost were reduced by 60% when the workload was moved from G6 to z/900. with a compression ratio of 21%.We ran the same query against the same data.000 pages in the compressed form for a compression ratio of 55%.4 million rows from a subselect (100% buffer hit) inserts at the end of a table space. The results are shown in Figure 10-3.

Table 10-1 Utility CPU time Partitioned table 20 million rows 2 indexes REORG — compressed data REORG — non-compressed data REORG SORTKEYS compressed data REORG SORTKEYS non-compressed data RUNSTATS — compressed data RUNSTATS — non-compressed data G6 CPU sec 699 393 662 355 479 411 z900 CPU sec 426 331 380 288 334 318 Delta CPU % -39.C om p ression perfo rm an ce G 6 vs z900 insert subselect Figure 10-4 Insert performance with and without compression DB2 utility performance Tests were performed to measure the benefit that the z900 faster processors have on utilities. Synergy with host platform UPC despalE pmoc 009z pmoc 6G pmoc non 009z pmoc non 6G 0 08 06 04 02 041 021 001 203 . with and without SORTKEYS option.27 -22. Utility CPU time is shown in Table 10-1. and RUNSTATS were run against compressed and non-compressed table spaces.6 -18. Chapter 10.63 Utilities run against compressed data experienced a significant reduction in CPU utilization. REORG.1 -15.8 -42. For the REORG wit SORTKEYS and compressed data.87 -30. the reduction in CPU cost was almost 43%.

2.10. a form of data striping has been available since the introduction of partitioned table spaces in DB2 Version 1 Release 3. Available for all VSAM data set organizations. Striping is a technique to improve the performance of data sets which are processed sequentially. to multiple disk arrays.2 VSAM Data Striping In this section we describe the DFSMS feature VSAM Data Striping and how DB2 can benefit from this functionality. SG24-6120.2. “ESS enhancements” on page 206. Additionally. 10. In DB2. This technique has been available for non-VSAM data sets since DFSMS/MVS Version 1 Release 1 and becomes available for VSAM data sets with DFSMS in OS/390 V2R10. Concurrent parallel I/O against these partitions/stripes is possible in DB2 as long as the partition pagesets are allocated on different volumes.1 Hardware versus software striping Whereas hardware striping facilitates parallel access to multiple physical disks in the same disk array. including linear data sets. and to multiple storage controllers. with each partition being a stripe. the use of the keyword piecesize. you can use the AMS REPRO command to convert existing standard VSAM data sets to extended format or to revert back to standard VSAM. and the redbook DFSMS Release 10 Technical Update. For a more detailed discussion of VSAM Data Striping see OS/390 V2R10 DFSMS Using Data Sets. VSAM striping is limited to 16 stripes. a method of data striping. Individual stripes can be extended to new volumes. implements a kind of data striping for non-partitioned indexes. Characteristics of VSAM Data Striping are: Data sets must be SMS managed and in extended format.3 VSAM Data Striping and DB2 VSAM Data Striping is transparent to DB2 and will work with all versions of DB2. Also.2. This is achieved by splitting the data set into segments or stripes and spreading those stripes across multiple volumes. 10.2 Description of VSAM striping DFSMS implements VSAM Data Striping by spreading control intervals in a control area across multiple devices. in fact. 10. Partitioning is. ESS devices and PAV can reduce contention (see 10. Notes Extended format data sets require storage control units that support non-synchronous I/O operation. DFSMS striping or software striping enables parallel access to multiple channels.3. SC26-7339. introduced in DB2 V4 on a CREATE INDEX statement.) 204 DB2 for z/OS and OS/390 Version 7 Performance Topics .

and the following characteristics: OS/390V2R10 Chapter 10. but internally the I/O will be reduced in scope to account for the allocated stripe. and VSAM I/O striping is independent of the optimizer and/or workload. Performance and usability tests are still under way. Less obvious candidates are the workfile table spaces. VSAM Data Striping could be a good solution for non-partitioned table spaces or for table spaces where partitioning cannot be implemented. Recent measurements done at SSD Performance Evaluation Lab on ESS model F20 showed a maximum throughput 11. be aware that parallelism due to partitioning will be decided by the optimizer. See 10. verified and approved.2.4 Measurements The performance measurements were executed with the specific objective of evaluating the DB2 log throughput with VSAM striping. DB2 logging and VSAM Data Striping Table 10-2 shows the measurement results for the log write throughput without and with VSAM Data Striping. Whether this is an advantage or a disadvantage depends on the workload. Also. The same query on a non-partitioned table space will run faster for the striped table space data set than for the non-striped one. the DB2 active log can be the limiting factor from a performance point of view. The measurements were executed in an environment using dual logging but no archiving to avoid interference. In the white paper DB2 for OS/390 Performance on IBM Enterprise Storage Server.4. Recommendation The usage of VSAM striping for the DB2 active logs is tested. 10. Be aware that: The current requirement on striping being applicable only to non-DB2-managed objects restricts the applicability of this solution. all sort work files are merged to one logical workfile which can result in contention for that merged workfile data set. In heavy update environments.2 MB/sec on ESS model E20. One difference between VSAM Data Striping and partitioning is that the sequential prefetch I/O quantity (number of pages returned by one prefetch I/O) is reduced by a factor equal to the degree of striping. such as segmented table spaces. “Enabling VSAM I/O striping in OS/390 V2R10” on page 215 for a description on how you can specify VSAM striping in DFSMS R10 for log data sets. and the results and recommendations are not available at this time. From the application point of view nothing changes. during the merge phase of a sort. a table space scan on a 16-stripe table space data set could definitely be slower than the same scan using parallelism on a 16-partition table space. it was indicated that the maximum throughput of the DB2 log was 8. due to the internal reduction of the prefetch quantity I/O from 32 to 2. “Measurements” on page 205 for details. we strongly advise you to wait for the results and recommendations from the DB2 labs before using VSAM striping for DB2 data. and striping further increased the throughput to 27 MB/sec (and this is not a theoretical limit). Synergy with host platform 205 . this is also true for deferred writes. the DB2 prefetch is still 32 pages.6 MB/sec.2. Enabling VSAM I/O striping See Appendix B. because the 16 parallel I/O streams only prefetch two pages each. VSAM striping for DB2 user data is still under investigation.DB2 candidate data sets for VSAM Data Striping DB2 active log data sets are good candidates for VSAM Data Striping. also non-partitioning indexes can benefit from striping.

But I/Os are not limited to coming from one host in parallel.40 57. Instead of one UCB per logical volume. The ESS introduces the concept of Alias addresses.0 CPU time (sec) Class 1 57.96 CPU time (sec) Class 2 54.67 57.96 55. The 1-striped case was included to demonstrate the slight overhead of striping. but also.3. 10. Not only were the S/390 systems limited to processing only one I/O at a time.5 27. Static PAV was introduced in OS/390 V2R3 and DFSMS 1. because of the overhead to write the 32 byte suffix using data chaining. This capability is called Multiple Allegiance. Dynamic PAV The association between the base UCB and the aliases is predefined but can be reassigned.5 18.68 54.76 54.5.3 DB2 log throughput (MB/sec) 11. (thousand) 161. WLM will instruct the I/O subsystem to reassign an alias UCB. The reassignment of the alias addresses is governed by WLM (goal mode) and based on the concurrent I/O activity for a volume. 10. The number of inserts is consistent with the log throughput.20 0 1 2 4 The log throughput rate increased 59% when the log data sets were 2-striped and 133% when 4-striped. Alias UCBs can be defined and used by OS/390 to issue I/Os in parallel to the same logical volume. and did not try to issue another I/O to a disk volume — represented in MVS by a Unit Control Block (UCB) — while an I/O was already active for that device. OS/390 systems knew that.DB2 UDB for OS/390 V6 ESS 2105-F20.2 382. Dynamic PAV was introduced in OS/390 V2R7 and DFSMS 1.3. the storage subsystems accepted only one I/O at a time from different system images to a shared disk volume. The function that allows parallel I/Os to a volume from one host is called Parallel Access Volumes (PAV). The ESS also accepts I/Os to a shared volume coming from different hosts in parallel. 16 paths — 8 per cluster DB2 INSERT intensive ERP workload Table 10-2 DB2 log throughput and CPU times # stripes INSERTs/min.1 Parallel Access Volumes The ESS has the capability to do more than one I/O to an emulated S/390 volume.7 257. Static PAV The association between the base UCB and the aliases is predefined and fixed.1 145. there is a 9% throughput reduction going from a non-striped log to a single striped log. 206 DB2 for z/OS and OS/390 Version 7 Performance Topics . disk hardware was only capable of processing one I/O at a time. Apart from the conventional Base UCB. an OS/390 host can now use up to 256 UCBs for the same logical volume.53 57. for the same reasons mentioned above.3 ESS enhancements In the early days.6 10.

Table 10-3 Define-Extent Domain in DB2 I/O DB2 Database I/O type Single page read/write I/O Sequential and Dynamic prefetch Sequential and Dynamic prefetch with DSNZPARM parameter SEQCACH=SEQ List prefetch and deferred write Define-Extent Domain 1 track 3 tracks for SQL. Parallel Access Volumes 10 9 8 7 6 5 4 3 2 1 0 IOSQ PEND DISC CONN Current disk Figure 10-5 Effect of PAV on I/O response time in msec ESS Concurrent read and write The unit of read and write I/O serialization for ESS when PAV is enabled is called the Define-Extent Domain. If applied. Read and write I/O is identified and serialization is done at the track level. Therefore. This is illustrated in Figure 10-5. Table 10-3 gives an overview of the size of the Define-Extent Domain. the I/O driver will ignore serialization at the define-extent domain level when PAV is enabled. the concurrency limitation imposed by DSNZPARM option SEQCACH=SEQ is hereby relieved. 6 tracks for utilities 3 tracks + 4 additional cylinders for SQL 6 tracks + 4 additional cylinders for utilities up to 1 cylinder APAR OW43946 introduces a no-serialization option. Synergy with host platform 207 . Define-Extent Domain The Define-Extent Domain is dependent on the type of I/O.Effect of PAV The effect of PAV on I/O response time is that IOSQ time almost disappears. Also. I/O wait will only happen for concurrent read and write I/Os against the same track. Chapter 10. DB2 V7 will exploit the no-serialization option for all database I/Os.

Example In order to illustrate the benefit that you can obtain with PAV. The DB2 optimizer is not aware of VSAM I/O striping nor of PAV. The ESS shows virtually no degradation when a parallel query scans one. The results are shown in Figure 10-6. DB2 I/O parallelism will not be selected for non-partitioned table spaces on striped or PAV enabled volumes. Elapsed Time (sec) 300 200 100 0 RAMAC 3 250 167 73 1 2 3 Number of concurrent prefetch streams Elapsed Time (sec) 300 200 100 ESS E20 34 0 33 37 1 2 3 Number of concurrent prefetch streams Figure 10-6 Parallel query performance with and without PAV Note Parallel Access Volumes is a special performance enhancement function. The same measurement on RAMAC-3 shows substantial degradation in elapsed time — two times worse for two partitions. It is provided by a separately priced feature that must be ordered to enable this function in the ESS. the performance of a parallel query was measured. 208 DB2 for z/OS and OS/390 Version 7 Performance Topics . and over three times worse for three partitions on one volume. 10.2 VSAM I/O striping versus PAV VSAM I/O striping alleviates contention on the data set level while PAV alleviates contention on the volume level whether the I/O is done against the same or different data sets. or three partitions simultaneously on the same volume. The access path selection will not take any of these features into account.3. two. The PAV function nearly eliminates the IOSQ time and removes the contention caused when multiple concurrent I/Os try to access the same volume.

Chapter 10.The process is intended to work as follows: Log suspend.3 FlashCopy FlashCopy provides an “instant”. Concurrent Copy delivers an image copy of the data. allows you to temporarily “freeze” updates to a DB2 subsystem while the logs and databases can be copied using FlashCopy for remote site recovery usage. FlashCopy requirements In order to take advantage of FlashCopy. you must have both software and hardware prerequisites. DB2 can use CC for their backups. FlashCopy the entire system. SC26-9945. Both source and target volumes must reside on the same logical subsystem (LSS). DB2 CC copy produces a consistent copy that can be used by the recover utility.3. FlashCopy and DB2 The SET LOG SUSPEND/RESUME option of DB2. FlashCopy operates at the logical volume level where CC can also operate at the data set level.10. log resume. A FlashCopy of an entire DB2 system has to be restored and possible inconsistencies are resolved during DB2 restart. FlashCopy is a feature of the IBM Enterprise Storage Server (ESS). CC enables you to copy or dump data while applications are updating the data. Copies made with Concurrent Copy can be registered in the SYSCOPY table if invoked via the image copy utility. At recovery site. point-in-time copy of the data for application usage such as backup and recovery operations. in a consistent form. FlashCopy and SnapShot copy SnapShot has been introduced to customers on the IBM RVA subsystem. restore everything and restart. Synergy with host platform 209 . also known as a Logical Control Unit (LCU). Log-only recovery with FlashCopy as an input is not supported. See the redbook Implementing ESS Copy Services on S/390. This would be a fuzzy backup in that uncommitted changes might still be in progress at the time of the copy. DFSMSdss automatically invokes FlashCopy when you issue the COPY FULL command on a subsystem that supports FlashCopy functions. FlashCopy enables you to copy or dump data while applications are updating the data. FlashCopy works entirely outside DB2. for a description of the copy process and the restrictions of CC. Customers have programs and policies that uses the RVA functions. It is intended that ESS implementation be as easy as possible for you to migrate from RVA to ESS. Concurrent Copy versus FlashCopy Concurrent Copy (CC) is both an extended function in the ESS and a component of DFSMSdss. SG24-5680 for more details. This would allow you to restart DB2 normally at the recovery site. See DB2 UDB For OS/390 and z/OS Utility Guide and Reference Version 7. and DFSMS/MVS Version1 Release3 and subsequent releases provide FlashCopy support. This is a unique feature of the IBM Enterprise Storage Server (ESS). taking also care of all in-flight URs. FlashCopy and Concurrent Copy (CC) are instant-related or so-called time-zero (T0) copy tools.

the ESS can make a FlashCopy across only one LSS of 256 drives. In the first implementation of FlashCopy. 210 DB2 for z/OS and OS/390 Version 7 Performance Topics . While RVA can make SnapShot across four logical subsystems (LSS).The FlashCopy function is similar to volume level SnapShot on the IBM RVA. however. it only operates on a volume basis. SnapShot can operate on either a volume. because it creates a physical point-in-time copy of the data. In contrast to the SnapShot implementation. you get an instant T0 copy when you start the command. As with SnapShot. FlashCopy on the ESS requires backend storage for the copy. or data set level.

A Appendix A. DSN8ED7: Sample DB2 for OS/390 Configuration Setting Report Generator Macro Name -------DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP DSN6SYSP DSN6SYSP ¦DSN6SYSP DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP DSN6SYSP DSN6SYSP DSN6SYSP DSN6SYSP ¦DSN6SYSP DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP DSN6SYSP DSN6SYSP DSN6SYSP DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP DSN6SYSP DSN6SYSP ¦DSN6SYSP ¦DSN6SYSP DSN6SYSP DSN6SYSP ¦DSN6SYSP Parameter Name ---------------AUDITST CONDBAT CTHREAD DLDFREQ PCLOSEN IDBACK IDFORE CHKFREQ MON MONSIZE SYNCVAL RLFAUTH RLF RLFERR RLFTBL MAXDBAT DSSTIME EXTSEC SMFACCT SMFSTAT ROUTCDE STORMXAB STORPROC STORTIME STATIME TRACLOC PCLOSET TRACSTR TRACTBL URCHKTH WLMENV LOBVALA LOBVALS LOGAPSTG DBPROTCL PTASKROL EXTRAREQ EXTRASRV TBSBPOOL IDXBPOOL LBACKOUT BACKODUR URLGWTH Current Setting --------------------------------------00000000000000000000000000000000 0000000064 00070 00005 00005 00020 00040 0000050000 00000000 0000008192 NO SYSIBM NO NOLIMIT 01 00064 00005 NO 10000000000000000000000000000000 10111000000000000000000000000000 1000000000000000 00000 DB2ASPAS 00180 00030 00016 00010 00000000000000000000000000000000 00016 000 0000002048 0000002048 000 DRDA YES 00100 00100 BP0 BP0 AUTO 005 0000000000 Description/ Install Field Name -----------------------------------AUDIT TRACE MAX REMOTE CONNECTED MAX USERS LEVELID UPDATE FREQUENCY RO SWITCH CHKPTS MAX BATCH CONNECT MAX TSO CONNECT CHECKPOINT FREQ MONITOR TRACE MONITOR SIZE STATISTICS SYNC RESOURCE AUTHID RLF AUTO START RLST ACCESS ERROR RLST NAME SUFFIX MAX REMOTE ACTIVE DATASET STATS TIME EXTENDED SECURITY SMF ACCOUNTING SMF STATISTICS WTO ROUTE CODES MAX ABEND COUNT DB2 PROC NAME TIMEOUT VALUE STATISTICS TIME RO SWITCH TIME TRACE AUTO START TRACE SIZE UR CHECK FREQ WLM ENVIRONMENT USER LOB VALUE STORAGE SYSTEM LOB VALUE STORAGE LOG APPLY STORAGE DATABASE PROTOCOL EXTRA BLOCKS REQ EXTRA BLOCKS SRV DEFAULT BUFFER POOL FOR USER DATA DEFAULT BUFFER POOL FOR USER INDEXES LIMIT BACKOUT BACKOUT DURATION UR LOG WRITE CHECK Install Fld Panel ID No. -------. The list can change with maintenance and needs to be verified. Updatable DB2 subsystem parameters Notes: Changeable subsystem parameters are marked with “¦”. 2001 211 .---DSNTIPN 1 DSNTIPE 4 DSNTIPE 2 DSNTIPL 14 DSNTIPL 12 DSNTIPE 6 DSNTIPE 5 DSNTIPL 6 DSNTIPN 9 DSNTIPN 10 DSNTIPN 7 DSNTIPP 8 DSNTIPO 4 DSNTIPO 6 DSNTIPO 5 DSNTIPE 3 DSNTIPN 8 DSNTIPR 11 DSNTIPN 4 DSNTIPN 5 DSNTIPO 1 DSNTIPX 4 DSNTIPX 2 DSNTIPX 5 DSNTIPN 6 DSNTIPL DSNTIPN DSNTIPN DSNTIPL DSNTIPX DSNTIP7 DSNTIP7 DSNTIPL DSNTIP5 DSNTIP5 DSNTIP5 DSNTIP1 DSNTIP1 DSNTIPL DSNTIPL DSNTIPL 13 2 3 8 6 1 2 5 6 4 5 1 2 10 11 9 © Copyright IBM Corp.

DSN6LOGP DSN6LOGP DSN6LOGP DSN6LOGP DSN6LOGP ¦DSN6LOGP ¦DSN6LOGP DSN6LOGP ¦DSN6LOGP ¦DSN6LOGP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6ARVP ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM ¦DSN6SPRM ¦DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM DSN6SPRM ¦DSN6SPRM DSN6SPRM DSN6SPRM TWOACTV OFFLOAD TWOBSDS TWOARCH MAXARCH DEALLCT MAXRTU OUTBUFF WRTHRSH ARC2FRST BLKSIZE CATALOG ALCUNIT PROTECT ARCWTOR COMPACT TSTAMP QUIESCE ARCRETN ARCPFX1 ARCPFX2 PRIQTY SECQTY UNIT UNIT2 ARCWRTC ABIND SYSADM2 AUTHCACH AUTH BMPTOUT LEMAX BINDNV CDSSRDEF DBCHK DEFLTID CHGDC AND EDPROP DECDIV3 DLITOUT DSMAX EDMPOOL RECALLD RELCURHL RECALL IRLMAUT ABEXP IRLMPRC IRLMSID IRLMSWT NUMLKTS NUMLKUS HOPAUTH SEQCACH RRULOCK DESCSTAT SEQPRES CACHEDYN RETLWAIT CACHERAC EDMDSPAC CONTSTOR MAXKEEPD RETVLCFK SYSOPR1 SYSOPR2 CACHEPAC PARAMDEG PARTKEYU STATHIST RGFNMPRT RGFCOLID RGFESCP RGFINSTL RGFDEDPL RGFFULLQ RGFDEFLT RGFDBNAM RGFNMORT MAXRBLK MINRBLK SYSADM SRTPOOL IRLMRWT ALPOOLX SITETYP UTIMOUT XLKUPDLT OPTHINTS TRKRSITE EDMBFIT EDMDSMAX STARJOIN DBACRVW CATALOG RESTART DEF 2 YES 2 2 0000001000 00000:00000 00002 0000004000 00020 NO 0000028672 NO BLK NO YES NO NO 00005 09999 DB2V710A. DIVIDE SCALE DLI BATCH TIMEOUT MAXIMUM OPEN DATA SETS EDMPOOL STORAGE SIZE RECALL DELAY RELEASE LOCKS RECALL DATA BASE AUTO START EXPLAIN PROCESSING PROC NAME SUBSYSTEM NAME TIME TO AUTO START LOCKS PER TABLE(SPACE) LOCKS PER USER AUTH AT HOP SITE SEQUENTIAL CACHE U LOCK FOR RR OR RS DESCRIBE FOR STATIC UTILITY CACHE OPTION CACHE DYNAMIC SQL RETAINED LOCK TIMEOUT ROUTINE AUTH CACHE EDMPOOL DATA SPACE SIZE CONTRACT THREAD STG MAX KEPT DYN STMTS VARCHAR FROM INDEX SYSTEM OPERATOR 1 SYSTEM OPERATOR 2 PACKAGE AUTH CACHE MAX DEGREE UPDATE PART KEY COLS STATISTICS HISTORY APPL REGISTRATION TABLE REGISTRATION OWNER ART-ORT ESCAPE CHAR INSTALL DDCTRL SUPT CONTROL ALL APPLICATIONS REQUIRE FULL NAMES UNREGISTERED DDL DEFAULT REGISTRATION DATABASE OBJT REGISTRATION TABLE RID POOL SIZE SYSTEM ADMIN 1 SORT POOL SIZE RESOURCE TIMEOUT SITE TYPE UTILITY TIMEOUT X LOCK FOR SEARCHED U OR D OPTIMIZATION HINTS TRACKER SITE LARGE EDM BETTER FIT EDMPOOL DATA SPACE MAX DBADM CREATE AUTH CATALOG ALIAS RESTART OR DEFER DSNTIPH DSNTIPH DSNTIPA DSNTIPA DSNTIPA DSNTIPL DSNTIPO DSNTIPA DSNTIPA DSNTIPA DSNTIPP DSNTIPA DSNTIPA DSNTIPH DSNTIPA DSNTIPA DSNTIPH DSNTIPH DSNTIPA DSNTIPA DSNTIPA DSNTIPA DSNTIPA DSNTIPO DSNTIPP DSNTIPP DSNTIPP DSNTIPI DSNTIP7 DSNTIPP DSNTIP4 DSNTIPP DSNTIPO DSNTIPF DSNTIPI DSNTIPC DSNTIPC DSNTIPO DSNTIP4 DSNTIPO DSNTIPI DSNTIPO DSNTIPI DSNTIPI DSNTIPI DSNTIPJ DSNTIPJ DSNTIP5 DSNTIPE DSNTIPI DSNTIPF DSNTIPE DSNTIP4 DSNTIPI DSNTIPP DSNTIPC DSNTIPE DSNTIPE DSNTIP4 DSNTIPP DSNTIPP DSNTIPP DSNTIP4 DSNTIP4 DSNTIPO DSNTIPZ DSNTIPZ DSNTIPZ DSNTIPZ DSNTIPZ DSNTIPZ DSNTIPZ DSNTIPZ DSNTIPZ DSNTIPC DSNTIPP DSNTIPC DSNTIPI DSNTIPO DSNTIPI DSNTIPI DSNTIP4 DSNTIPO DSNTIP4 DSNTIPC DSNTIPP DSNTIPA2 DSNTIPS 3 6 10 9 8 2 13 7 4 1 1 11 15 9 14 13 7 8 2 3 5 6 12 8 4 10 2 11 3 9 6 7 10 3 12 1 2 3 10 2 4 9 5 2 6 3 4 7 7 8 16 8 7 13 12 3 10 9 9 5 6 11 11 12 14 8 6 5 1 2 3 4 7 9 7 3 6 3 11 7 9 8 12 13 4 13 1 1 212 DB2 for z/OS and OS/390 Version 7 Performance Topics .ARCHLOG2 0000001234 0000000154 3490 NONE 1011000000000000 YES PAOLOR1 01024 YES 00004 00020 BINDADD ANY NO IBMUSER 1 NO 00006 0000003000 0015167488 00120 YES YES YES YES IRLAPROC IRLA 0000000300 0000001000 0000010000 BOTH BYPASS NO NO NO NO 00000 0000032768 0000000000 NO 0000005000 NO SYSOPR SYSOPR 0000032768 0000000000 YES NONE DSN_REGISTER_APPL DSNRGCOL NO NO YES APPL DSNRGFDB DSN_REGISTER_OBJT 0000000250 0000000001 KARRAS 0001024000 0000000060 0000032256 LOCALSITE 00006 NO NO NO NO 1073741824 DISABLE NO DB2V710A RESTART NUMBER OF COPIES NUMBER OF COPIES RECORDING MAX DEALLOC PERIOD READ TAPE UNITS OUTPUT BUFFER READ COPY2 ARCHIVE BLOCK SIZE CATALOG DATA ALLOCATION UNITS ARCHIVE LOG RACF WRITE TO OPER COMPACT DATA TIMESTAMP ARCHIVES QUIESCE PERIOD RETENTION PERIOD ARCH LOG 1 PREFIX ARCH LOG 2 PREFIX PRIMARY QUANTITY SECONDARY QTY DEVICE TYPE 1 DEVICE TYPE 2 WTOR ROUTE CODE AUTO BIND SYSTEM ADMIN 2 PLAN AUTH CACHE USE PROTECTION IMS BMP TIMEOUT MAXIMUM LE TOKENS BIND NEW PACKAGE CURRENT DEGREE UNKNOWN AUTHID DPROP SUPPORT MIN.ARCHLOG1 DB2V710A.

Updatable DB2 subsystem parameters 213 . D DEFAULT APOST NO 00037 65534 65534 00000 65534 65534 00367 01208 01200 EBCDIC EBCDIC ISO ISO 000 000 YES ALPHANUM DB2A 15 YES OFF DBSTARTX DDF THREADS TCP IP ALREADY VERIFIED RESYNC INTERVAL RLST ACCESS ERROR DDF STARTUP OPTION IDLE THREAD TIMEOUT MAX TYPE1 INACTIVE THREADS TCPIP KEEPALIVE POOL THREAD TIMEOUT ASSISTANT COORDINATOR IMMEDIATE WRITE DATA SHARING FUNCTION MEMBER NAME GROUP NAME LANGUAGE DEFAULT DECIMAL POINT IS STRING DELIMITER SQL STRING DELIMITER DIST SQL STR DELIMITER MIXED DATA EBCDIC CODED CHAR SET EBCDIC CODED CHAR SET EBCDIC CODED CHAR SET ASCII CODED CHAR SET ASCII CODED CHAR SET ASCII CODED CHAR SET UNICODE CCSID UNICODE CCSID UNICODE CCSID DEF ENCODING SCHEME APPLICATION ENCODING DATE FORMAT TIME FORMAT LOCAL DATE LENGTH LOCAL TIME LENGTH STD SQL LANGUAGE EBCDIC CODED CHAR SET SUBSYSTEM NAME DECIMAL ARITHMETIC USE FOR DYNAMIC RULES LOCALE LC_CTYPE DSNTIPS 2-37 DSNTIPR 7 DSNTIP5 3 DSNTIPR 6 DSNTIPR 5 DSNTIPR 1 DSNTIPR 10 DSNTIPR 8 DSNTIP5 8 DSNTIP5 9 DSNTIPK 6 DSNTIPK 5 DSNTIP4 14 DSNTIPA1 2 DSNTIPK 2 DSNTIPK 1 DSNTIPF 1 DSNTIPF 2 DSNTIPF 4 DSNTIPF 5 DSNTIPF 6 DSNTIPF 7 DSNTIPF 8 DSNTIPF 8 DSNTIPF 8 DSNTIPF 9 DSNTIPF 9 DSNTIPF 9 DSNTIPF 10 DSNTIPF 10 DSNTIPF 10 DSNTIPF 11 DSNTIPF 13 DSNTIP4 1 DSNTIP4 2 DSNTIP4 3 DSNTIP4 4 DSNTIP4 5 DSNTIPF 8 DSNTIPM 1 DSNTIPF 14 DSNTIPF 15 DSNTIPF 12 Appendix A.DSN6SPRM DSN6FAC DSN6FAC DSN6FAC ¦DSN6FAC DSN6FAC DSN6FAC DSN6FAC DSN6FAC DSN6FAC DSN6GRP DSN6GRP DSN6GRP DSN6GRP DSN6GRP DSN6GRP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP DSNHDECP ALL-DBNAME CMTSTAT TCPALVER RESYNC RLFERRD DDF IDTHTOIN MAXTYPE1 TCPKPALV POOLINAC ASSIST COORDNTR IMMEDWRI DSHARE MEMBNAME GRPNAME DEFLANG DECIMAL DELIM SQLDELI DSQLDELI MIXED SCCSID MCCSID GCCSID ASCCSID AMCCSID AGCCSID USCCSID UMCCSID UGCCSID ENSCHEME APPENSCH DATE TIME DATELEN TIMELEN STDSQL CHARSET SSID DECARTH DYNRULES COMPAT LC_CTYPE ALL ACTIVE NO 00002 NOLIMIT AUTO 00000 0000000000 ENABLE 00120 NO NO NO NO DSN1 DSNCAT IBMCOB .

214 DB2 for z/OS and OS/390 Version 7 Performance Topics .

They can only be allocated through the ACS routines.09 DEVSERV QDASD 317 UNIT VOLSER SCUTYPE DEVTYPE CYL SSID SCU-SERIAL DEV-SERIAL EF-CHK 6312 SBOX28 2105E20 2105 3339 8903 0113-12089 0113-12089 **OK** **** 1 DEVICE(S) MET THE SELECTION CRITERIA **** 0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING Figure B-1 DEVSERV QDASD command response © Copyright IBM Corp. Use the DATACLAS and STORAGECLASS parameters on DEFINE CLUSTER for non DB2 defined data sets. In this appendix we show how to define VSAM I/O striping using the Guaranteed Space attribute of the storage class definition. Define a data class with Data Set Name Type. Extended format requires storage control units that support non-synchronous I/O operation. Define a storage class with Sustained Data Rate > 0 and Guaranteed Space set to YES.B Appendix B.See Figure B-1 on page 215 for a sample command response DEVSERV QDASD. EXT. You have to do the following: Check if your disk supports extended format data sets. Check your disk To make sure your disk supports the extended format you can issue the DEVSERV QDASD command for the volumes you want to use. Adapt your ACS routines to use the new data class and storage class.00.6312 IEE459I 16.. Enabling VSAM I/O striping in OS/390 V2R10 VSAM striped data sets must be SMS managed and in extended format. 2001 215 . We used ISMF to define the data class and storage class..

. . . . . . . S CD S D at a Cl a s s N a me : D B 2S T R IP D at a Se t Na m e T y pe . . . . B WO . Availability . . . but the value will not be used to calculate the number of stripes. : CF Direct Weight . L og . . . . . . . .SMS. . . . . . . . . : S Y S1 . . . the SDR must be greater than zero. In this case. Sequential Millisecond Response Sequential Bias . . . See Figure B-2 for an example. . . . . R e d uc e Sp a c e U p T o ( % ) B lo c k S i z e L i mi t . . . . . . . Y N : : : : : : 40 : C : S : Figure B-3 Sample storage class definition The Guarantee Space attribute value is set to YES.See Figure B-3 for an example. . . . . . . . . . . : : : : : : : : : : : : : EX T E ND E D RE Q U IR E D NO USE R NO SPE E D NO Figure B-2 Sample data class definition Define a storage class Define a storage class with Guaranteed Space set to YES and Sustained Data Rate set to non-zero. . . I ni t i al L oa d . . . . CDS Name . . . .SCDS Storage Class Name : VSTRIPE Description : TEST STORAGE CLASS FOR VSAM STRIPING Performance Objectives Direct Millisecond Response . . . . . . . . Direct Bias . . . L og s t re a m I d . S pa c e C o n st r a in t R e l ie f . . . . 216 DB2 for z/OS and OS/390 Version 7 Performance Topics . . . C DS N am e . . . R eu s e . . . . . . . E x t en d e d A dd r e ss a b il i t y R e c or d Ac c e ss Bi a s . . . . . . . . . . . . . . . . . . . . Guaranteed Space . Initial Access Response Seconds Sustained Data Rate (MB/sec) . . the volume will be eligible for extended format data sets. . : Guaranteed Synchronous Write . : . . . . . . : Cache Set Name . . . . Versioning . . : SYS1. . . . S MS . . : CF Sequential Weight . .If the field EF-CHK shows **OK**. . . S pa n n ed / N o ns p a nn e d . . . . Define a data class You need a data class with Data Set Name Type set to EXT. the number of stripes is determined by the number of volumes specified in the DEFINE CLUSTER command. . . . . . . . . . . I f Ex t e nd e d . . . . . . . . . . . . . Backup .

3) SPEED UNIQUE NOERASE UNORDERED NOREUSE NONSPANNED EXTENDED STATISTICS Figure B-5 Extract from LISTCAT command response Appendix B. CLUSTER--DB2V710G. DEFINE CLUSTER ( NAME (DB2V710G.LOGCOPY1.DS04.LOGCOPY1.Define cluster For non-DB2 defined data sets.LOGCOPY1. an example of the DEFINE CLUSTER command is shown in Figure B-4.DS04 ATTRIBUTES KEYLEN-----------------0 AVGLRECL---------------0 RKP--------------------0 MAXLRECL---------------0 STRIPE-COUNT-----------4 SHROPTNS(1.DS04) VOLUMES(* * * *) DATACLASS(DB2STRIP) STORAGECLASS(VSTRIPE) RECORDS(8640) LINEAR ) DATA ( NAME (DB2V710G. See Figure B-5. as you can see from the response to the LISTCAT command.DATA) ) CATALOG(DB2V710G) Figure B-4 Sample DEFINE CLUSTER command The resulting defined VSAM striped data set is allocated with three stripes. Enabling VSAM I/O striping in OS/390 V2R10 217 .

218 DB2 for z/OS and OS/390 Version 7 Performance Topics .

PAGES READ VIA DYN. HPOOL WRITE. HPOOL WRITE-S the sum of these fields is called TOTAL HP WRITES Note These fields are reported in DB2PM version 7 on a per-second basis. ASYNC. PREFETCH. A method to assess the size of the buffer pools Collecting the statistics and careful evaluation of the numbers over a long enough time period — at least a complete production day — gives you helpful information to assess the size of your buffer pools. Statistics report information We will first look at the buffer pool related information reported in the STATISTICS REPORT LONG from DB2PM which will be used in our calculations. Before using them in the calculations. © Copyright IBM Corp. HPOOL READ-S the sum of these fields is called Total HP READS SYNC.VPOOL called VPSIZE in this appendix BUFFERS ALLOCATED . HPOOL WRITE. The simple approach explained in this appendix can be done with all releases of DB2. HPOOL READ.the sum of these fields is called TOTAL PAGES READ SYNC.HPOOL called HPSIZE GETPAGE REQUESTS . PAGES READ VIA LIST PREFTCH. these fields were reported on a per-minute basis.called GETPAGES SYNHRONOUS READS. HPOOL READ. PAGES READ VIA SEQ. BUFFERS ALLOCATED .DA. The use of data spaces is not considered. PREFETCH . convert the values to a per-second basis.MOVER.MOVER.C Appendix C. but it is understood that hiperpools or buffer pools in data spaces are interchangeable from the point of view of this methodology. ASYN. 2001 219 . ASYNC. ASYN.DA. If you are using earlier versions of DB2PM.

ETR = (VPSIZE + HPSIZE)/TOTAL PAGES READ Minimum Estimated Total Size for y minutes residency Minimum Estimated Total pool Size for y minutes residency (ETSmin (y)) is defined as the total buffer pool size that would accommodate a page to stay in the buffer pool for y minutes. we can calculate the following formula: EVR = VPSIZE / TOTAL HP WRITES if HPSIZE > 0 or EVR = VPSIZE / TOTAL PAGES READ if HPSIZE = 0 Minimum Estimated Vpool Size for x minutes residency Minimum Estimated Vpool Size for x minutes residency (EVSmin (x)) is defined as the virtual buffer pool size that would accommodate a page to stay in the buffer pool for x minutes. Using the fields of the DB2PM statistics report. enter the required fields and the foregoing formulas in a spreadsheet to calculate the values for the cells representing these parameters. The input fields are the data that you collected from the statistics report. this means the sum of VPSIZE and HPSIZE. Four concepts are defined: Estimated Vpool Residency Estimated Vpool Residency (EVR) time is defined as the time in seconds that an average page can stay un-referenced in the virtual buffer pool before being written to the hiperpool.Concepts In this section we introduce the concepts used in this approach and explain how to use them in a spreadsheet. The value can be calculated as follows: ETSmin (y) = TOTAL PAGES READ * 60 * y Spreadsheet example After you have collected the data. A sample spreadsheet is shown in Figure C-1. Altering x and y will result in new values for the minimum VP only size and the minimum total VP and HP size. 220 DB2 for z/OS and OS/390 Version 7 Performance Topics . The Estimated Total pool Residency (ETR) time is defined as the time in seconds that an average page is available from the buffer pools. The value can be calculated as follows: EVSmin (x) = TOTAL HP WRITES * 60 * x if HPSIZE > 0 or EVSmin (x) = TOTAL PAGES READ * 60 * x if HPSIZE = 0 Estimated Total pool Residency This concept accounts for the total buffer pool size. the result fields are the parameters defined in the previous section and the variables in the spreadsheet are x and y expressed in minutes.

if you can hold onto a page for much longer. so you may want to consider consolidating them. this selection should be based on the getpage rate and the estimated vpool residency.67 1584.78 0 0 Lower Bound for VP (X) Residency Lower Bound for VP+HP (Y) Residency BPID BP0 BP2 BP3 BP4 BP7 BP15 BP16 BP20 EVR EVSmin(x)ETR ETSmin(y) 2519 60 512. Our goal is to save virtual storage by shrinking and/or redistributing the virtual storage among the virtual buffer pools in the DBM1 address space and the hiperpools.67 1148.48 6054 40 100.31 15000 250000 4080.67 3348. although it can also be helpful in this area. the ETSmin (y) value should be split in 1/3 VP and 2/3 HP.BPID BP0 BP2 BP3 BP4 BP7 BP15 BP16 BP20 VPSIZE HPSIZE GetPages Total Pages read Total HP reads Total HP Writes 2500 6000 15. The basis for the evaluation is the "page miss ratio curve" where you plot buffer pool size versus miss rate.31 4000 0 186.37 245.6 1558. This approach is not a replacement for existing buffer pool tuning methodologies.7 327. Appendix C. you might be able to get onto the really flat part of the curve.15 1 5 59 200791 152677 40 26 14741 60965 68927 Figure C-1 Sample spreadsheet Evaluation The guidelines that we will discuss in this section are only mentioned to help you in the evaluation process. they should not be considered as axioms. Based on performance studies and direct customer experience.36 7 200899 2.31 143.28 0.71 0.67 102.19 25000 225000 1206. if you can hold onto a page in the buffer pool for about 30 seconds.99 0.39 0.51 16 14712 5. A method to assess the size of the buffer pools 221 . identify all buffer pools with a low getpage rate.22 0.86 25 60951 6.22 2.67 0. you might be able to avoid the "knee" in the reference curve (number of pages versus reference frequency).89 6 152839 4. From the spreadsheet.67 688. As a rule of thumb. Identify the buffer pools which are most interesting from a virtual storage saving point of view.91 6773 133 4163.99 22500 252500 5371. Similarly.00 986.01 2547.66 0 0 15000 40000 98. The values of 30 seconds and 5 minutes are offered only as rules of thumb. Such buffer pools may not justify the investment in terms of virtual storage.05 9 68927 0. evaluate the use of a hiperpool.85 10000 0 751. they are broad guidelines and not optimal. about 5 minutes. If the total calculated pool size is so large that it will constrain the virtual storage of the DBM1 address space.21 4000 32000 611.38 1015.84 1761.

222 DB2 for z/OS and OS/390 Version 7 Performance Topics .

00043600 5 S_MNSAQ FIXED BIN(31). /*TRACE FLAG*/ DCL TRACE CHAR VARYING. 00043300 5 S_OVRLP CHAR(1). 00043800 5 S_INSPN CHAR(1). EXEC SQL WHENEVER SQLERROR GO TO ERROR2. 00043900 5 S_INSSR CHAR(2). DCL SYSPRINT FILE PRINT. 00041700 DCL 1 INSTRUC BASED(ADDR(INAREA)). DCL CHECKFLG CHAR(1). 00042700 5 S_GRADE CHAR(3). EXEC SQL WHENEVER SQLWARNING GOTO ERROR3. 00042200 5 S_EFFBD fixed DEC(5).D Appendix D. 00041800 5 S_TABLN CHAR(8). 00043200 5 S_ORTIM FIXED BIN(31).NOSPIE.1). 00042500 5 S_ROUTC CHAR(1). 00042800 5 S_SUTIM FIXED BIN(31). 00044000 5 S_SHRFR fixed DEC(5. 00042900 5 S_SUCDE CHAR(1). 00044100 © Copyright IBM Corp. 00042100 5 S_DEPTN CHAR(3). Sample PL/1 program INSERTRS: PROCEDURE(TRACE) OPTIONS(MAIN). 00042600 5 S_WKCEN CHAR(5). 00040000 00040100 00040200 00040300 00040400 00040800 00040900 00041000 00041100 00041200 /********************************************************************/00041300 /* local declares */00041400 /********************************************************************/00041500 DCL INAREA CHAR(117). 2001 223 . 00043700 5 S_MNSAH FIXED BIN(31). 00043500 5 S_MAXFA FIXED BIN(31). 00042300 5 S_EFFED fixed DEC(5). 00043000 5 FILL1 CHAR(3). 00043400 5 FILL2 CHAR(3). 00042400 5 S_ROUTN fixed DEC(7). 00042000 5 S_OPERS CHAR(5). DCL PLIXOPT CHAR(30) VARYING STATIC EXTERNAL INIT('ISASIZE(64K).NOSTAE'). 00043100 5 S_MATIM FIXED BIN(31). EXEC SQL INCLUDE SQLCA. 00041900 5 S_PARTN CHAR(14).

:s_SUTIM. :s_ORTIM. 00049800 COMMITCTR = 0. :s_ROUTN. 00052000 5 5 5 5 5 S_TFACN S_HANIN S_HANDE S_HANTI S_FILL1 fixed DEC(3). 00047300 00047400 DO WHILE ((SQLCODE=0) & (¬EOF)) . :s_OVRLP. 00045300 ADDR BUILTIN. :s_INSSR. 00049700 EXEC SQL COMMIT. :s_DEPTN. :s_SUCDE. :s_HANDE. :s_EFFED. 00048500 :s_WKCEN. 00049400 COMMITCTR = COMMITCTR + 1. 00046700 L_EOF = '0'B. 00048900 :s_HANTI. 00050000 END. 00044900 00045000 DCL INFILE FILE RECORD INPUT SEQUENTIAL. :s_FILL1). 00046500 00046600 O_EOF = '0'B. :s_HANIN. :s_MNSAH. :s_TFACN. 00047200 READ FILE(INFILE) INTO(INAREA). 00046100 00046200 SQLCODE = 0. 00045600 00045700 /********************************************************************/ 00045800 /* initialization */ 00045900 /********************************************************************/ 00046000 COMMITCTR = 0. :s_ROUTC. :s_INSPN. 00048400 :s_EFFBD. 00047600 00047700 00048100 EXEC SQL INSERT INTO TABLE4UT 00048200 VALUES( 00048300 :s_TABLN. :s_GRADE. 00045400 UNSPEC BUILTIN. 00048600 :s_MATIM. 00046300 00046400 CHECKFLG=TRACE. 00044800 COMMITCTR BIN FIXED(31). 00048700 :s_MNSAQ. 00045500 NULL BUILTIN. 00051000 if (eof) then 00051100 EXEC SQL COMMIT. CHAR(8). 00049500 IF COMMITCTR = 10000 THEN 00049600 DO. 00045200 DCL I BIN FIXED(15). 224 DB2 for z/OS and OS/390 Version 7 Performance Topics .00044200 00044300 00044400 00044500 00044600 DCL 00044700 LINT BIN FIXED(31). 00048800 :s_SHRFR. 00047100 OPEN FILE(INFILE) . 00049900 END. 00050100 00050400 READ FILE(INFILE) INTO(INAREA). CHAR(4). 00045100 DCL EOF BIT(1) ALIGNED INIT('0'B). CHAR(4). 00046800 00046900 00047000 ON ENDFILE (INFILE) EOF = '1'B. :s_OPERS. :s_MAXFA. CHAR(12). 00049000 00049100 00049200 IF SQLCODE = 0 THEN 00049300 DO. :s_PARTN.

CLOSE FILE(infile). 00150000 olabel = 'ADVANCE O'.a(10). 00340000 DCL ID CHAR(2). 00510000 PUT SKIP DATA(SQLCA).to_orderkey) 00220000 (f(2). 00170000 iolabel = 'INS ORDER'. 00100000 DCL ID CHAR(2).tlabel. 00230000 if id = '12' then put skip edit(id. 00460000 PUT SKIP DATA(SQLCA).x(10). 00530000 OUTNOW: 00540000 END: END INSERTRS. GOTO END. 00450000 PUT SKIP LIST(SQLCODE). 00430000 ERROR2: 00440000 PUT SKIP LIST('SQL ERROR').tl_orderkey) 00280000 (f(2). 00200000 if id = '11' then put skip edit(id. 00140000 itlabel char(10).f(10)). 00190000 IF CHECKFLG¬='T' THEN GOTO ENDCHK. 00270000 if id = '21' then put skip edit(id.x(10). 00350000 IF CHECKFLG¬='C' THEN GOTO ENDCHK2.tl_orderkey) 00240000 (f(2).a(10). 00550000 END. 00250000 if id = '13' then put skip edit(id. 00160000 tlabel = 'ADVANCE I'. 00500000 PUT SKIP LIST(SQLCODE).iolabel. 00330000 CHECKID2: PROCEDURE(ID). Sample PL/1 program 225 .f(10)). 00520000 ERROR: EXEC SQL ROLLBACK.a(10). 00360000 ENDCHK2: END CHECKID2. 00400000 ERROR1: 00410000 PUT SKIP LIST('COUNT(*)=0'). Appendix D.tl_orderkey) 00300000 (f(2).tl_orderkey) 00260000 (f(2). 00480000 ERROR3: 00490000 PUT SKIP LIST('SQL WARNING').a(10). 00290000 if id = '22' then put skip edit(id.x(5). 00130000 dcl iolabel char(10). 00310000 ENDCHK: END CHECKID.olabel.itlabel.x(10).f(10)).00060000 00061000 00062000 00063000 00064000 /*******************************************************************/ 00070000 /* error handling routines */ 00080000 /********************************************************************/ 00090000 CHECKID: PROCEDURE(ID).f(10)).x(10). 00470000 GOTO OUTNOW.f(10)).tlabel. 00180000 itlabel = 'INS ITEM'.a(10). 00420000 GOTO ERROR. CALL CHECKID('99'). 00110000 dcl olabel char(10). 00120000 tlabel char(10).

226 DB2 for z/OS and OS/390 Version 7 Performance Topics .

5 12.41 JOB12124 IGD01008I &ALLVOL = 12.D1214.41 JOB12124 IGD01008I &ANYVOL = 12.10 JOB12124 IGD01008I &ANYVOL = 12.)-----PAGING COUNTS--12.N O D E W T S C P L X 2 12.18. 14 DEC 2000 ---12.DISP=SHR 00260000 //* 00270000 //* 12150000 //* STEP 18: REORGANIZE TABLESPACES.SDSNLOAD'.39 JOB12124 IGD01008I &ALLVOL = 12.17.50 MINUTES EXECUTION TIME 1 //PAOLOR5C JOB ACCNT#.41 JOB12124 IGD01008I &UNIT = SYSDA 12.10 JOB12124 IGD01008I &ALLVOL = 12.01 JOB12124 $HASP395 PAOLOR5C ENDED -----.TSLP0002. 12.19.31 JOB12124 ---.T1717 12.THURSDAY.D1214.19.19. 2001 227 .FIC.D1214.17.17.TSLP0001. 12.01 JOB12124 IEF404I PAOLOR5C .FIC.SDSNLOAD.03 .T1717 12.19.31 JOB12124 ICH70001I PAOLOR5 LAST ACCESS AT 12:16:36 ON THURSDAY. 12.17.10 JOB12124 IGD01008I &DSN = PAOLOR5.00 1.ASID=0032.03 TOTAL ELAPSED TIME= 1.10 JOB12124 IGD01008I &UNIT = SYSDA 12.39 JOB12124 IGD01008I &UNIT = SYSDA 12.19.01 JOB12124 --TIMINGS (MINS. DECEMBER 14.31 JOB12124 IEF403I PAOLOR5C .01 JOB12124 -PAOLOR5C PH01S18 DSNUPROC 00 8031 .17.INIT 1 .01 JOB12124 -JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK SERV PG PAGE SWAP VIO SWAPS 12.CLASS A . PRODUCE STATISTICS 12160000 //* 12170000 3 //PH01S18 EXEC DSNUPROC.JES2 JOB STATISTICS -----14 DEC 2000 JOB EXECUTION DATE 48 CARDS READ 223 SYSOUT PRINT RECORDS 0 SYSOUT PUNCH RECORDS 14 SYSOUT SPOOL KBYTES 1.DBLP0002. 2000 12.39 JOB12124 IGD01008I &ANYVOL = 12.5 166K 0 0 0 0 0 12.18.DBLP0001.17. Sample utilities output COPY output with LISTDEF and TEMPLATE J E S 2 J O B L O G -.41 JOB12124 IGD01008I &DSN = PAOLOR5.18.STARTED .18.E Appendix E.19.TSLP0003.17.ENDED .SYS SC63 12.01 JOB12124 -PAOLOR5C ENDED.COPYTS' 12180000 4 XXDSNUPROC PROC LIB='DSN510.FIC.18.T1717 12.PARM='DB2A.S Y S T E M S C 6 3 -. **JOB STATEMENT GENERATED BY SUBMIT** // NOTIFY=PAOLOR5.31 JOB12124 IRR010I USERID PAOLOR5 IS ASSIGNED TO THIS JOB.ASID=0032.DBLP0003. © Copyright IBM Corp.39 JOB12124 IGD01008I &DSN = PAOLOR5.1) //********************************************************************* 00240000 //* 00250000 2 //JOBLIB DD DSN=DSN710. // MSGLEVEL=(1. NAME-PAOLOR5 TOTAL CPU TIME= .31 JOB12124 $HASP373 PAOLOR5C STARTED . JOB12124 // PAOLOR5.17.18.17.18.18.

DISP=SHR XX* XX********************************************************************** XX* XX* THE FOLLOWING DEFINE THE UTILITIES' PRINT DATA SETS XX* XX********************************************************************** XX* IEFC653I SUBSTITUTION JCL .COPY PROCESSED FOR TABLESPACE DBLP0001.PAOLOR5C.COND CODE 0000 IEF285I DSN710.OPTIONS STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .REGION=0K.1217 IEF374I STEP/DSNUPROC/STOP 2000349.HALT) DSNU1035I DSNUILDR .T1717 CATALOGED IEF285I VOL SER NOS= SBOX02.PAOLOR5C.FIC..D1214.T&HOUR.1217 IEF376I JOB/PAOLOR5C/STOP 2000349.SDSNLOAD KEPT IEF285I VOL SER NOS= SBOX12.DBLP0003.18SEC DSNU000I DSNUGUTC .LISTDEF STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .DBLP0002..STEP WAS EXECUTED .18SEC VIRT 1176K SYS 380K EXT 4748K SYS 9784K IEF285I DSN710..DBLP0001.FIC.06SEC SRB 0MIN 00.1219 CPU 0MIN 02. IEF285I PAOLOR5. XX PARM='&SYSTEM. IGD100I 3F14 ALLOCATED TO DDNAME SYS00003 DATACLAS ( ) IGD01008I &DSN = PAOLOR5..? SYSOUT IEF285I PAOLOR5.&UTPROC' IEFC653I SUBSTITUTION JCL .TSLP0002.DATASET ALLOCATED.25) CYL DSNU1035I DSNUJTDR .REGION=&SIZE.PARM='DB2X.D1214.SDSNLOAD KEPT IEF285I VOL SER NOS= SBOX12.DBLP0001.T1717 IGD01008I &UNIT = SYSDA IGD01008I &ALLVOL = IGD01008I &ANYVOL = IEF285I PAOLOR5.DBLP0003.OUTPUT START FOR UTILITY.JOB12124.D0000103.SDSNLOAD.&UID. MESSAGE 3 IEFC001I PROCEDURE DSNUPROC WAS EXPANDED USING SYSTEM LIBRARY SYS1.T1717 DSNU400I DSNUBBID .T1717 IGD01008I &UNIT = SYSDA IGD01008I &ALLVOL = IGD01008I &ANYVOL = IEF285I PAOLOR5.JOB12124.D0000101. IEF142I PAOLOR5C DSNUPROC PH01S18 . 2000 IEF236I ALLOC.COPY LIST COPYLST SHRLEVEL REFERENCE FULL YES COPYDDN(COPYTMP) DSNU1038I DSNUGDYN . IGD100I 390D ALLOCATED TO DDNAME SYS00002 DATACLAS ( ) IGD01008I &DSN = PAOLOR5.D0000102.UTPROC='' XX* XX********************************************************************** 5 XXDSNUPROC EXEC PGM=DSNUTILB.&MINUTE.D1214.? SYSOUT IEF285I PAOLOR5.PAOLOR5C. UNIT SYSDA DISP( NEW.* DSNU1035I DSNUILDR .FIC.? SYSOUT IEF285I PAOLOR5.CATLG) SPACE(50.TEST1.TSLP0001.FIC.FIC. UTILID = COPYTS DSNU050I DSNUGUTC .LISTDEF COPYLST INCLUDE TABLESPACE DBLP00*.TSLP0001 NUMBER OF PAGES=16480 228 DB2 for z/OS and OS/390 Version 7 Performance Topics .&TS.TEMPLATE COPYTMP DSN &USERID.UID=''.PGM=DSNUTILB.&DAY.DSN=DSN510.FIC.T1717 CATALOGED IEF285I VOL SER NOS= SBOX02. TEMPLATE=COPYTMP DDNAME=SYS00001 DSN=PAOLOR5.06SEC SRB 0MIN 00.DISP=SHR 7 XXSYSPRINT DD SYSOUT=* 8 XXUTPRINT DD SYSOUT=* 9 XXSYSUDUMP DD SYSOUT=* XX*DSNUPROC PEND REMOVE * FOR USE AS INSTREAM PROCEDURE 10 //SYSIN DD * 12250000 //* 12330000 STMT NO.JOB12124.T1717 CATALOGED IEF285I VOL SER NOS= SBOX38.1219 CPU 0MIN 02.TSLP0003.D&MONTH.? SYSIN IEF373I STEP/DSNUPROC/START 2000349.CATLG.PAOLOR5C.' 6 //STEPLIB DD DSN=DSN710.D1214. DECEMBER 14.TSLP0001.D1214.XX SYSTEM=DB2X..JOB12124.D1214.FIC.PROCLIB ICH70001I PAOLOR5 LAST ACCESS AT 12:16:36 ON THURSDAY.DBLP0002. XX SIZE=0K.TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .T1717 IGD01008I &UNIT = SYSDA IGD01008I &ALLVOL = IGD01008I &ANYVOL = IEF285I PAOLOR5.OPTIONS EVENT(ITEMERROR.D1214.TSLP0002.D0000104. IEF375I JOB/PAOLOR5C/START 2000349.FIC. FOR PAOLOR5C DSNUPROC PH01S18 IEF237I 2661 ALLOCATED TO JOBLIB IEF237I 2661 ALLOCATED TO STEPLIB IEF237I JES2 ALLOCATED TO SYSPRINT IEF237I JES2 ALLOCATED TO UTPRINT IEF237I JES2 ALLOCATED TO SYSUDUMP IEF237I JES2 ALLOCATED TO SYSIN IGD100I 3F14 ALLOCATED TO DDNAME SYS00001 DATACLAS ( ) IGD01008I &DSN = PAOLOR5.DISP=SHR 12190000 X/STEPLIB DD DSN=&LIB.SDSNLOAD.DBLP0001.TSLP0003.TSLP0001.&DB.

"TBLP0003 " PART 1 INDDN TEMPINDN DISCARDDN TEMPDISC WHEN(1:2=X'0003') DSNU650I =DB2A DSNURWI . DSNU650I =DB2A DSNURWI "CHAR_FELT8 " POSITION(85:92) CHAR(8) NULLIF(84)=X'FF'.DBLP0003.TEMPLATE TEMPINDN DSN(&USERID.50) TRK DSNU1035I DSNUJTDR . DSNU650I =DB2A DSNURWI "TIMESTMP " POSITION(23:48) TIMESTAMP EXTERNAL NULLIF(22)=X'FF'.SYSUT1) DISP(NEW.TEMPLATE TEMPERR DSN(&USERID.DELETE.("PART_NO " POSITION(3:6) INTEGER.TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .0.DELETE) SPACE(5. DSNU650I =DB2A DSNURWI "NO_FELT2 " POSITION(13:16) INTEGER NULLIF(12)=X'FF'. Appendix E. Sample utilities output 229 .INTO TABLE "PAOLOR5 ".DATA. TEMPLATE=COPYTMP DDNAME=SYS00002 DSN=PAOLOR5."TBLP0003 " PART 2 INDDN TEMPINDN DISCARDDN TEMPDISC WHEN(1:2=X'0003') DSNU650I =DB2A DSNURWI .DELETE.. DSNU650I =DB2A DSNURWI "NO_FELT1 " POSITION(8:11) INTEGER NULLIF(7)=X'FF'.DELETE) SPACE(5. DSNU650I =DB2A DSNURWI "NO_FELT3 " POSITION(18:21) INTEGER NULLIF(17)=X'FF'.TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .P&PART.22 PERCENT OF CHANGED PAGES = 72. TEMPLATE=COPYTMP DDNAME=SYS00003 DSN=PAOLOR5.50) CYL DSNU1035I DSNUJTDR .SORTOUT) DISP(NEW.TEMPLATE TEMPDISC DSN(&USERID.07 PERCENT OF CHANGED PAGES = 0.P&PART. DSNU650I =DB2A DSNURWI "CHAR_FELT3 " POSITION(55:57) CHAR(3) NULLIF(54)=X'FF'.LOAD DATA LOG YES REPLACE SORTKEYS 4200 SORTNUM 16 WORKDDN(TEMPUT1.DISCARD) DISP(NEW.00 ELAPSED TIME=00:00:28 DATASET ALLOCATED.T1650) ISP(SHR.TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC . DSNU650I =DB2A DSNURWI "CHAR_FELT11 " POSITION(115:125) CHAR(11) NULLIF(114)=X'FF'.D1214.DBLP0002.TSLP0002. DSNU650I =DB2A DSNURWI "CHAR_FELT1 " POSITION(50:50) CHAR(1) NULLIF(49)=X'FF'.DELETE) SPACE(5.TSLP0003 UTILITY EXECUTION COMPLETE.SYSERR) DISP(NEW. DSNU650I =DB2A DSNURWI "CHAR_FELT4 " POSITION(59:62) CHAR(4) NULLIF(58)=X'FF'.TSLP0002 DB2 IMAGE COPY SUCCESSFUL FOR TABLESPACE DBLP0003.T1717 COPY PROCESSED FOR TABLESPACE DBLP0002. DSNU650I =DB2A DSNURWI "CHAR_FELT9 " POSITION(94:102) CHAR(9) NULLIF(93)=X'FF'.DELETE.50) TRK DSNU1035I DSNUJTDR . DSNU650I =DB2A DSNURWI "TIMESTMP " POSITION(23:48) TIMESTAMP EXTERNAL NULLIF(22)=X'FF'.50) TRK DSNU1035I DSNUJTDR .TSLP0003 NUMBER OF PAGES=13765 AVERAGE PERCENT FREE SPACE PER PAGE = 3.CATLG) SPACE(50. DSNU650I =DB2A DSNURWI "CHAR_FELT7 " POSITION(77:83) CHAR(7) NULLIF(76)=X'FF'..P&PART..D1115.. DSNU650I =DB2A DSNURWI "CHAR_FELT10 " POSITION(104:113) CHAR(10) NULLIF(103)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT2 " POSITION(52:53) CHAR(2) NULLIF(51)=X'FF'. DSNU650I =DB2A DSNURWI "NO_FELT1 " POSITION(8:11) INTEGER NULLIF(7)=X'FF'.22 PERCENT OF CHANGED PAGES = 0..DELETE) SPACE(5.TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC . DSNU650I =DB2A DSNURWI "NO_FELT3 " POSITION(18:21) INTEGER NULLIF(17)=X'FF'.TEMPSORT) EBCDIC CCSID( 37. DSNU650I =DB2A DSNURWI "CHAR_FELT3 " POSITION(55:57) CHAR(3) NULLIF(54)=X'FF'. DSNU650I =DB2A DSNURWI "NO_FELT2 " POSITION(13:16) INTEGER NULLIF(12)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT6 " POSITION(70:75) CHAR(6) NULLIF(69)=X'FF'.TSLP0003.D1214. DSNU650I =DB2A DSNURWI "CHAR_FELT5 " POSITION(64:68) CHAR(5) NULLIF(63)=X'FF'.00 ELAPSED TIME=00:00:22 DB2 IMAGE COPY SUCCESSFUL FOR TABLESPACE DBLP0001.50) CYL DSNU1035I DSNUJTDR ..T1717 COPY PROCESSED FOR TABLESPACE DBLP0003. DSNU650I =DB2A DSNURWI "CHAR_FELT4 " POSITION(59:62) CHAR(4) NULLIF(58)=X'FF'.DELETE..CATLG.TEMPLATE TEMPUT1 DSN(&USERID..FIC..("PART_NO " POSITION(3:6) INTEGER. DSNU650I =DB2A DSNURWI "CHAR_FELT5 " POSITION(64:68) CHAR(5) NULLIF(63)=X'FF'.FIC. DSNU650I =DB2A DSNURWI "CHAR_FELT2 " POSITION(52:53) CHAR(2) NULLIF(51)=X'FF'.TSLP0001.. DSNU650I =DB2A DSNURWI "CHAR_FELT1 " POSITION(50:50) CHAR(1) NULLIF(49)=X'FF'.0) ERRDDN TEMPERR DSNU650I =DB2A DSNURWI .P&PART.TSLP0001 DB2 IMAGE COPY SUCCESSFUL FOR TABLESPACE DBLP0002.TEMPLATE TEMPSORT DSN(&USERID.DSNU1038I DSNU400I DSNUGDYN DSNUBBID - DSNU1038I DSNU400I DSNUGDYN DSNUBBID - DSNU428I DSNU428I DSNU428I DSNU010I DSNUBBID DSNUBBID DSNUBBID DSNUGBAC - AVERAGE PERCENT FREE SPACE PER PAGE = 7. HIGHEST RETURN CODE=0 Job output of LOAD partition in parallel DSNU000I DSNUGUTC .INTO TABLE "PAOLOR5 ".OUTPUT START FOR UTILITY. UTILID = LOADTS DSNU050I DSNUGUTC .TSLP0002 NUMBER OF PAGES=15720 AVERAGE PERCENT FREE SPACE PER PAGE = 3.77 ELAPSED TIME=00:00:28 DATASET ALLOCATED.P&PART. DSNU650I =DB2A DSNURWI "REMARK " POSITION(127:198) CHAR(72) NULLIF(126)=X'FF') DSNU650I =DB2A DSNURWI .

T1650 DSNU1038I DSNUGDYN . DSNU650I =DB2A DSNURWI "CHAR_FELT7 " POSITION(77:83) CHAR(7) NULLIF(76)=X'FF'.P00001. DSNU650I =DB2A DSNURWI "TIMESTMP " POSITION(23:48) TIMESTAMP EXTERNAL NULLIF(22)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT8 " POSITION(85:92) CHAR(8) NULLIF(84)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT3 " POSITION(55:57) CHAR(3) NULLIF(54)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT2 " POSITION(52:53) CHAR(2) NULLIF(51)=X'FF'. DSNU650I =DB2A DSNURWI "REMARK " POSITION(127:198) CHAR(72) NULLIF(126)=X'FF') DSNU650I =DB2A DSNURWI .D1115. DSNU650I =DB2A DSNURWI "CHAR_FELT10 " POSITION(104:113) CHAR(10) NULLIF(103)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT7 " POSITION(77:83) CHAR(7) NULLIF(76)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT11 " POSITION(115:125) CHAR(11) NULLIF(114)=X'FF'. DSNU650I =DB2A DSNURWI "NO_FELT2 " POSITION(13:16) INTEGER NULLIF(12)=X'FF'. DSNU650I =DB2A DSNURWI "NO_FELT2 " POSITION(13:16) INTEGER NULLIF(12)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT5 " POSITION(64:68) CHAR(5) NULLIF(63)=X'FF'.DSNU650I =DB2A DSNURWI "CHAR_FELT6 " POSITION(70:75) CHAR(6) NULLIF(69)=X'FF'.T1650 DSNU1038I DSNUGDYN . DSNU650I =DB2A DSNURWI "CHAR_FELT2 " POSITION(52:53) CHAR(2) NULLIF(51)=X'FF'.DATASET ALLOCATED. DSNU650I =DB2A DSNURWI "CHAR_FELT5 " POSITION(64:68) CHAR(5) NULLIF(63)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT2 " POSITION(52:53) CHAR(2) NULLIF(51)=X'FF'.INTO TABLE "PAOLOR5 ". TEMPLATE=TEMPINDN DDNAME=SYS00005 DSN=PAOLOR5."TBLP0003 " PART 4 INDDN TEMPINDN DISCARDDN TEMPDISC WHEN(1:2=X'0003') DSNU650I =DB2A DSNURWI .DATASET ALLOCATED."TBLP0003 " PART 5 INDDN TEMPINDN DISCARDDN TEMPDISC WHEN(1:2=X'0003') DSNU650I =DB2A DSNURWI . DSNU650I =DB2A DSNURWI "CHAR_FELT4 " POSITION(59:62) CHAR(4) NULLIF(58)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT10 " POSITION(104:113) CHAR(10) NULLIF(103)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT10 " POSITION(104:113) CHAR(10) NULLIF(103)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT6 " POSITION(70:75) CHAR(6) NULLIF(69)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT8 " POSITION(85:92) CHAR(8) NULLIF(84)=X'FF'.("PART_NO " POSITION(3:6) INTEGER.TSLP0001.D1115.DISCARD DSNU1038I DSNUGDYN . DSNU650I =DB2A DSNURWI "CHAR_FELT3 " POSITION(55:57) CHAR(3) NULLIF(54)=X'FF'. TEMPLATE=TEMPINDN DDNAME=SYS00001 DSN=PAOLOR5.("PART_NO " POSITION(3:6) INTEGER.P00001. DSNU650I =DB2A DSNURWI "CHAR_FELT9 " POSITION(94:102) CHAR(9) NULLIF(93)=X'FF'. TEMPLATE=TEMPDISC DDNAME=SYS00002 DSN=PAOLOR5.DATASET ALLOCATED. DSNU650I =DB2A DSNURWI "TIMESTMP " POSITION(23:48) TIMESTAMP EXTERNAL NULLIF(22)=X'FF'. DSNU650I =DB2A DSNURWI "REMARK " POSITION(127:198) CHAR(72) NULLIF(126)=X'FF') DSNU1038I DSNUGDYN . DSNU650I =DB2A DSNURWI "CHAR_FELT9 " POSITION(94:102) CHAR(9) NULLIF(93)=X'FF'. TEMPLATE=TEMPDISC 230 DB2 for z/OS and OS/390 Version 7 Performance Topics . DSNU650I =DB2A DSNURWI "NO_FELT3 " POSITION(18:21) INTEGER NULLIF(17)=X'FF'.P00002. DSNU650I =DB2A DSNURWI "CHAR_FELT4 " POSITION(59:62) CHAR(4) NULLIF(58)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT11 " POSITION(115:125) CHAR(11) NULLIF(114)=X'FF'. DSNU650I =DB2A DSNURWI "REMARK " POSITION(127:198) CHAR(72) NULLIF(126)=X'FF') DSNU650I =DB2A DSNURWI . DSNU650I =DB2A DSNURWI "CHAR_FELT4 " POSITION(59:62) CHAR(4) NULLIF(58)=X'FF'.TSLP0001. DSNU650I =DB2A DSNURWI "NO_FELT3 " POSITION(18:21) INTEGER NULLIF(17)=X'FF'. TEMPLATE=TEMPINDN DDNAME=SYS00003 DSN=PAOLOR5.T1650 DSNU1038I DSNUGDYN . DSNU650I =DB2A DSNURWI "TIMESTMP " POSITION(23:48) TIMESTAMP EXTERNAL NULLIF(22)=X'FF'.INTO TABLE "PAOLOR5 ". TEMPLATE=TEMPDISC DDNAME=SYS00004 DSN=PAOLOR5. DSNU650I =DB2A DSNURWI "CHAR_FELT3 " POSITION(55:57) CHAR(3) NULLIF(54)=X'FF'.TSLP0001. DSNU650I =DB2A DSNURWI "CHAR_FELT9 " POSITION(94:102) CHAR(9) NULLIF(93)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT9 " POSITION(94:102) CHAR(9) NULLIF(93)=X'FF'. DSNU650I =DB2A DSNURWI "NO_FELT1 " POSITION(8:11) INTEGER NULLIF(7)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT11 " POSITION(115:125) CHAR(11) NULLIF(114)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT7 " POSITION(77:83) CHAR(7) NULLIF(76)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT5 " POSITION(64:68) CHAR(5) NULLIF(63)=X'FF'.INTO TABLE "PAOLOR5 ".P00003. DSNU650I =DB2A DSNURWI "NO_FELT2 " POSITION(13:16) INTEGER NULLIF(12)=X'FF'.D1115. DSNU650I =DB2A DSNURWI "CHAR_FELT1 " POSITION(50:50) CHAR(1) NULLIF(49)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT6 " POSITION(70:75) CHAR(6) NULLIF(69)=X'FF'. DSNU650I =DB2A DSNURWI "NO_FELT1 " POSITION(8:11) INTEGER NULLIF(7)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT11 " POSITION(115:125) CHAR(11) NULLIF(114)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT1 " POSITION(50:50) CHAR(1) NULLIF(49)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT6 " POSITION(70:75) CHAR(6) NULLIF(69)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT10 " POSITION(104:113) CHAR(10) NULLIF(103)=X'FF'.DATA."TBLP0003 " PART 3 INDDN TEMPINDN DISCARDDN TEMPDISC WHEN(1:2=X'0003') DSNU650I =DB2A DSNURWI . DSNU650I =DB2A DSNURWI "CHAR_FELT1 " POSITION(50:50) CHAR(1) NULLIF(49)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT8 " POSITION(85:92) CHAR(8) NULLIF(84)=X'FF'.DATASET ALLOCATED. DSNU650I =DB2A DSNURWI "CHAR_FELT7 " POSITION(77:83) CHAR(7) NULLIF(76)=X'FF'. DSNU650I =DB2A DSNURWI "REMARK " POSITION(127:198) CHAR(72) NULLIF(126)=X'FF') DSNU650I =DB2A DSNURWI .DATA.P00002.DATA.DISCARD DSNU1038I DSNUGDYN . DSNU650I =DB2A DSNURWI "NO_FELT1 " POSITION(8:11) INTEGER NULLIF(7)=X'FF'. DSNU650I =DB2A DSNURWI "CHAR_FELT8 " POSITION(85:92) CHAR(8) NULLIF(84)=X'FF'.DATASET ALLOCATED.DATASET ALLOCATED.("PART_NO " POSITION(3:6) INTEGER. DSNU650I =DB2A DSNURWI "NO_FELT3 " POSITION(18:21) INTEGER NULLIF(17)=X'FF'.

&DAY.TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .DISCARD DSNUGDYN .P00000. TEMPLATE=TEMPINDN DDNAME=SYS00009 DSN=PAOLOR5.UNLOAD LIST TSLPLIST UNLDDN TMPDATA PUNCHDDN TMPPUNCH DSNU1039I DSNUGULM . UNIT SYSDA DISP(NEW..NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0003 PART 1 DSNU348I =DB2A DSNURBXA . ELAPSED TIME=00:01:34 DSNUGSOR .BUILD PHASE COMPLETE.UTILITY EXECUTION COMPLETE. TEMPLATE=TEMPUT1 DDNAME=SYS00011 DSN=PAOLOR5.NUMBER OF KEYS=40960 FOR INDEX PAOLOR5.NUMBER OF RECORDS=8192 FOR TABLE PAOLOR5.TEMPLATE TMPDATA DSN &USERID. TEMPLATE=TEMPDISC DDNAME=SYS00008 DSN=PAOLOR5.25) TRK DSNU1035I DSNUJTDR .PARTITIONS WILL BE UNLOADED IN PARALLEL. TEMPLATE=TMPPUNCH DDNAME=SYS00001 Appendix E.NUMBER OF TASKS CONSTRAINED BY CPUS DSNU1038I DSNUGDYN .D1115.BUILD PHASE STATISTICS .(RE)LOAD PHASE COMPLETE.TSLP0001.DATASET ALLOCATED.(RE)LOAD PHASE STATISTICS .LISTDEF STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .SORTOUT DSNUGDYN .TSLP0003 PARTLEVEL(5) DSNU1035I DSNUILDR ...1) TRK DSNU1035I DSNUJTDR .OPTIONS STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .IXLP0003 PART 5 DSNU349I =DB2A DSNURBXA .DATASET ALLOCATED.&TS.HALT) DSNU1035I DSNUILDR .SYSERR =DB2A DSNURRST .EXISTING RECORDS DELETED FROM TABLESPACE DSNURPPL .D&MONTH.D&MONTH.P&PART. NUMBER OF TASKS = 3 =DB2A DSNURWT .DATASET ALLOCATED. TEMPLATE=TEMPSORT DDNAME=SYS00012 DSN=PAOLOR5.DATA.PROCESSING LIST ITEM: TABLESPACE DBLP0003.(RE)LOAD PHASE STATISTICS . Sample utilities output 231 .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.D1115.DATASET ALLOCATED.TSLP0003 PARTLEVEL(2) INCLUDE TABLESPACE DBLP0003.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.DISCARD DSNUGDYN .P00000.BUILD PHASE STATISTICS .(RE)LOAD PHASE STATISTICS .TSLP0001...P&PART.NUMBER OF RECORDS=8192 FOR TABLE PAOLOR5.DSNU1038I DSNU1038I DSNU1038I DSNU1038I DSNU1038I DSNU1038I DSNU1038I DSNU350I DSNU364I DSNU303I PART=1 DSNU303I PART=2 DSNU303I PART=3 DSNU303I PART=4 DSNU303I PART=5 DSNU302I DSNU300I DSNU042I DDNAME=SYS00006 DSN=PAOLOR5.P00005.LISTDEF TSLPLIST INCLUDE TABLESPACE DBLP0003.BUILD PHASE STATISTICS .SORT PHASE STATISTICS NUMBER OF RECORDS=81920 ELAPSED TIME=00:00:00 DSNU348I =DB2A DSNURBXA .CATLG) SPACE(1.P00004.(RE)LOAD PHASE STATISTICS . HIGHEST RETURN CODE=0 Job output of UNLOAD utility DSNU000I DSNUGUTC .&TS.BUILD PHASE STATISTICS .DATASET ALLOCATED. UNIT SYSDA DISP(NEW.T&HOUR.T1650 DSNUGDYN .(RE)LOAD PHASE STATISTICS .BUILD PHASE STATISTICS .PARTITIONS WILL BE LOADED IN PARALLEL. ELAPSED TIME=00:00:01 DSNU010I DSNUGBAC .TEMPLATE TMPPUNCH DSN &USERID..T&HOUR.P00000.NUMBER OF RECORDS=8192 FOR TABLE PAOLOR5. UTILID = DSNTEX DSNU050I DSNUGUTC .DATA.P00004.(RE)LOAD PHASE STATISTICS .&DAY.P00003.T1650 DSNUGDYN .BUILD PHASE STATISTICS .DISCARD DSNUGDYN .DATASET ALLOCATED. NUMBER OF TASKS = 2 DSNU397I DSNUUNLD .P00005.&MINUTE.TBLP0003 =DB2A DSNURWT .PUNCH.TSLP0003 PARTLEVEL(4) INCLUDE TABLESPACE DBLP0003.BUILD PHASE STATISTICS ..TEMPLATE STATEMENT PROCESSED SUCCESSFULLY DSNU050I DSNUGUTC .TSLP0003 PARTLEVEL(1) INCLUDE TABLESPACE DBLP0003.NUMBER OF RECORDS=8192 FOR TABLE PAOLOR5.IXLP1003 DSNU258I DSNURBXD .TBLP0003 =DB2A DSNURWT . TEMPLATE=TEMPERR DDNAME=SYS00013 DSN=PAOLOR5.OPTIONS EVENT(ITEMERROR.DATA.NUMBER OF RECORDS=8192 FOR TABLE PAOLOR5. TEMPLATE=TEMPINDN DDNAME=SYS00007 DSN=PAOLOR5.TSLP0003 PARTITION 1 DSNU1201I DSNUUNLD .NUMBER OF INPUT RECORDS PROCESSED=40960 DSNURILD .OUTPUT START FOR UTILITY.DATASET ALLOCATED.DATASET ALLOCATED.IXLP0003 PART 2 DSNU348I =DB2A DSNURBXA .&MINUTE.NUMBER OF INDEXES=2 DSNU259I DSNURBXD .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.TBLP0003 DSNURILD .IXLP0003 PART 4 DSNU348I =DB2A DSNURBXA .CATLG) SPACE(50.CATLG. TEMPLATE=TEMPDISC DDNAME=SYS00010 DSN=PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.TBLP0003 =DB2A DSNURWT .TSLP0003 PARTLEVEL(3) INCLUDE TABLESPACE DBLP0003.CATLG.TBLP0003 =DB2A DSNURWT ..SYSUT1 DSNUGDYN .IXLP0003 PART 3 DSNU348I =DB2A DSNURBXA .

IXLP0001 PART 3 DSNU393I =DB2A DSNURBXA .IXLP0001 PART 2 DSNU393I =DB2A DSNURBXA .NUMBER OF RECORDS UNLOADED=8192 FOR TABLESPACE DBLP0003. TEMPLATE=TMPDATA DDNAME=SYS00002 DSN=PAOLOR5.RUNSTATS CATALOG TIMESTAMP = 2000-11-14-20.UNLOAD PHASE STATISTICS .TSLP0001 NUMBER OF PAGES=16526 AVERAGE PERCENT FREE SPACE PER PAGE = 7.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.TSLP0003 PART 1 DSNU1038I DSNUGDYN . NUMBER OF TASKS = 6 DSNU400I DSNURBID .P00000.COPY PROCESSED FOR TABLESPACE DBLP0001. ELAPSED TIME=00:00:36 DSNU395I DSNURPIB .D1214.NUMBER OF RECORDS UNLOADED=327680 FOR TABLESPACE DBLP0001.TSLP0003 PART 4 DSNU251I DSNUULQB .T1755 DSNU251I DSNUULQB .DSN=PAOLOR5.14.TBLP0001 DSNU302I DSNURILD .TBLP0003 DSNU252I DSNUUNLD .T1755 DSNU251I DSNUULQB .00 ELAPSED TIME=00:01:15 DSNU610I =DB2A DSNUSUTP .T1755 DSNU251I DSNUULQB .TSLP0003 PART 2 DSNU1038I DSNUGDYN .SYSTABLESPACE CATALOG UPDATE FOR DBLP0001.06 PERCENT OF CHANGED PAGES =100.PUNCH.SORTBLD PHASE STATISTICS .NUMBER OF RECORDS UNLOADED=8192 FOR TABLESPACE DBLP0003.NUMBER OF RECORDS UNLOADED=40960 FOR TABLESPACE DBLP0003.T1755 DSNU1038I DSNUGDYN .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF RECORDS UNLOADED=40960 FOR TABLE PAOLOR5.DATASET ALLOCATED.TBLP0001 SUCCESSFUL DSNU610I =DB2A DSNUSUPC SYSCOLSTATS CATALOG UPDATE FOR PAOLOR5.DATA.UNLOAD PHASE STATISTICS . TEMPLATE=TMPDATA DDNAME=SYS00005 DSN=PAOLOR5.D1214.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 PART 4 DSNU393I =DB2A DSNURBXA .TSLP0003. UTILID = DSNTEX DSNU050I DSNUGUTC .DATASET ALLOCATED.TSLP0001 SUCCESSFUL DSNU620I =DB2A DSNURDRT .NUMBER OF RECORDS UNLOADED=8192 FOR TABLESPACE DBLP0003.SYSTABLEPART CATALOG UPDATE FOR DBLP0001.TSLP0003.TSLP0003. TEMPLATE=TMPDATA DDNAME=SYS00004 DSN=PAOLOR5.SORTBLD PHASE STATISTICS .P00002. TEMPLATE=TMPDATA DDNAME=SYS00003 DSN=PAOLOR5.P00005. TEMPLATE=TMPDATA DDNAME=SYS00006 DSN=PAOLOR5.D1214.IXLP0001 PART 5 DSNU393I =DB2A DSNURBXA .NUMBER OF RECORDS UNLOADED=8192 FOR TABLESPACE DBLP0003.NUMBER OF RECORDS=327680 FOR TABLE PAOLOR5.UNLOAD PHASE STATISTICS . ELAPSED TIME=00:00:03 DSNU010I DSNUGBAC .TBLP0001 SUCCESSFUL DSNU610I =DB2A DSNUSUCO SYSCOLUMNS CATALOG UPDATE FOR PAOLOR5.TBLP0001 SUCCESSFUL DSNU610I =DB2A DSNUSUTS .TSLP0003 PART 5 DSNU253I DSNUUNLD .DATA.P00003.DATASET ALLOCATED.SORTBLD PHASE STATISTICS .INDEXES WILL BE BUILT IN PARALLEL.SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .T1755 DSNUGDYN .NUMBER OF INPUT RECORDS PROCESSED=327680 DSNU300I DSNURILD .DATA.SORTBLD PHASE STATISTICS .D1214.NUMBER OF RECORDS UNLOADED=8192 FOR TABLESPACE DBLP0003.832335 DSNU304I =DB2A DSNURWT .TSLP0001 DSNU250I DSNURULD .P00001.IXLP0001 PART 7 232 DB2 for z/OS and OS/390 Version 7 Performance Topics .UTILITY EXECUTION COMPLETE. ELAPSED TIME=00:01:16 DSNU393I =DB2A DSNURBXA .REORG TABLESPACE DBLP0001.25.TSLP0001 LOG NO SORTDATA SORTKEYS COPYDDN(SYSCOPY) SHRLEVEL REFERENCE DEADLINE NONE FASTSWITCH YES STATISTICS TABLE(ALL) INDEX(ALL) UPDATE ALL HISTORY ALL DSNU252I DSNURULD .UNLOAD PHASE COMPLETE.UNLOAD PHASE STATISTICS .TSLP0003.OUTPUT START FOR UTILITY.T1755 DSNU251I DSNUULQB .UNLOAD PHASE STATISTICS .P00004.TSLP0003.TSLP0001 SUCCESSFUL DSNU610I =DB2A DSNUSUPT SYSTABSTATS CATALOG UPDATE FOR PAOLOR5.UNLOAD PHASE STATISTICS .UNLOAD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.(RE)LOAD PHASE STATISTICS .DATASET ALLOCATED.D1214.DATA.DATA.IXLP0001 PART 1 DSNU393I =DB2A DSNURBXA .TSLP0003 DSNU250I DSNUUNLD .TBLP0001 SUCCESSFUL DSNU610I =DB2A DSNUSUTB SYSTABLES CATALOG UPDATE FOR PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.(RE)LOAD PHASE COMPLETE.UNLOAD PHASE STATISTICS .IXLP0001 PART 6 DSNU393I =DB2A DSNURBXA .UNLOAD PHASE COMPLETE.TSLP0003 PART 3 DSNU1038I DSNUGDYN .DATASET ALLOCATED.TSLP0003.SORTBLD PHASE STATISTICS .D1214. HIGHEST RETURN CODE=0 DSNU1038I Job output of Online REORG DSNU000I DSNUGUTC .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.(RE)LOAD PHASE STATISTICS .

TBLP0001 SUCCESSFUL SYSINDEXES CATALOG UPDATE FOR PAOLOR5.IXLP0001 =DB2A DSNURBXA .IXLP0001 SUCCESSFUL SYSCOLDISTSTATS CATALOG UPDATE FOR PAOLOR5.SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .IXLP0001 SUCCESSFUL .562612 Appendix E.IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .RUNSTATS CATALOG TIMESTAMP = 2000-11-14-20.SYSINDEXPART CATALOG UPDATE FOR PAOLOR5.SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .IXLP0001 SUCCESSFUL SYSCOLUMNS CATALOG UPDATE FOR PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.TBLP0001 SUCCESSFUL SYSCOLDIST CATALOG UPDATE FOR PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A =DB2A =DB2A =DB2A =DB2A =DB2A =DB2A =DB2A DSNUSUIP DSNUSUPI DSNUSUPD DSNUSUPC DSNUSUIX DSNUSUCO DSNUSUCD DSNURDRI .IXLP0001 =DB2A DSNURBXA .IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .DSNU393I PART 8 DSNU393I PART 9 DSNU393I PART 10 DSNU393I PART 11 DSNU393I PART 12 DSNU393I PART 13 DSNU393I PART 14 DSNU393I PART 15 DSNU393I PART 16 DSNU393I PART 17 DSNU393I PART 18 DSNU393I PART 19 DSNU393I PART 20 DSNU393I PART 21 DSNU393I PART 22 DSNU393I PART 23 DSNU393I PART 24 DSNU393I PART 25 DSNU393I PART 26 DSNU393I PART 27 DSNU393I PART 28 DSNU393I PART 29 DSNU393I PART 30 DSNU393I PART 31 DSNU393I PART 32 DSNU393I PART 33 DSNU393I PART 34 DSNU393I PART 35 DSNU393I PART 36 DSNU393I PART 37 DSNU393I PART 38 DSNU393I PART 39 DSNU393I PART 40 DSNU610I DSNU610I DSNU610I DSNU610I DSNU610I DSNU610I DSNU610I DSNU620I =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .15.SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .IXLP0001 SUCCESSFUL SYSCOLSTATS CATALOG UPDATE FOR PAOLOR5.IXLP0001 SUCCESSFUL SYSINDEXSTATS CATALOG UPDATE FOR PAOLOR5.IXLP0001 =DB2A DSNURBXA .IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS . Sample utilities output 233 .IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .SORTBLD PHASE STATISTICS .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .NUMBER OF KEYS=8192 FOR INDEX PAOLOR5.IXLP0001 =DB2A DSNURBXA .IXLP0001 =DB2A DSNURBXA .25.IXLP0001 =DB2A DSNURBXA .

IXLP0002 =DB2A DSNUSUIP .IXLP0002 SUCCESSFUL =DB2A DSNUSUCO SYSCOLUMNS CATALOG UPDATE FOR PAOLOR5.NUMBER OF KEYS=327680 FOR INDEX PAOLOR5.IXLP0002 SUCCESSFUL =DB2A DSNUSUIX SYSINDEXES CATALOG UPDATE FOR PAOLOR5. NUMBER OF INDEXES = 2 DSNURPTB .SWITCH PHASE COMPLETE.IXLP0002 SUCCESSFUL =DB2A DSNURDRI .SORTBLD PHASE COMPLETE.SORTBLD PHASE STATISTICS .UTILITY EXECUTION COMPLETE.DSNU394I DSNU610I DSNU610I DSNU610I DSNU610I DSNU620I DSNU391I DSNU392I DSNU387I DSNU428I DSNU010I =DB2A DSNURBXA . ELAPSED TIME = 00:00:04 DSNURSWT .15.SYSINDEXPART CATALOG UPDATE FOR PAOLOR5.TBLP0001 SUCCESSFUL =DB2A DSNUSUCD SYSCOLDIST CATALOG UPDATE FOR PAOLOR5.TSLP0001 DSNUGBAC . HIGHEST RETURN CODE=0 234 DB2 for z/OS and OS/390 Version 7 Performance Topics .DB2 IMAGE COPY SUCCESSFUL FOR TABLESPACE DBLP0001.25.554778 DSNURPTB . ELAPSED TIME = 00:00:14 DSNURSWT .RUNSTATS CATALOG TIMESTAMP = 2000-11-14-20.SORTBLD PHASE STATISTICS.

The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. in the United States and/or other countries. 600A. Inc. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems. Customers attempting to adapt these techniques to their own environments do so at their own risk. an IBM company.Tivoli A/S. Mail Drop 1329. NY 10504-1785. C-bus is a trademark of Corollary. Anything. and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries. Manage. Any reference to an IBM product.. programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. and is limited in application to those specific hardware and software products and levels. or service may be used.. including in some cases. program. The furnishing of this document does not give you any license to these patents. PC Direct is a trademark of Ziff Communications Company in the United States and/or other © Copyright IBM Corp. Dept. other countries. Information in this book was developed in conjunction with use of the equipment specified.TME. While each item may have been reviewed by IBM for accuracy in a specific situation.. Tivoli Ready. and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems Inc. Microsoft. Armonk. Cross-Site. in the United States. in the United States and/or other countries. in writing.Special notices References in this publication to IBM products. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. Anywhere. North Castle Drive. You can send license inquiries. Windows NT. Anything. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged. to the IBM Director of Licensing. Planet Tivoli. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. Anywhere. IBM Corporation. IBM may have patents or pending patent applications covering subject matter in this document. Any functionally equivalent program that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product.. Tivoli is a trademark licensed from Kjøbenhavns Sommer . Windows. payment of a fee. Such information may be available. The following terms are trademarks of other companies: Tivoli. Somers. or both. NY 10589 USA. 2001 235 . there is no guarantee that the same or similar results will be obtained elsewhere. or service is not intended to state or imply that only IBM's product. subject to appropriate terms and conditions. In Denmark.The Power To Manage. Tivoli Certified. program or service. NetView. should contact IBM Corporation. Inc. program.

SET Secure Electronic Transaction. and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company. LANDesk. MMX. ActionMedia. and service names may be trademarks or service marks of others. SET.countries and is used by IBM Corporation under license. product. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. 236 DB2 for z/OS and OS/390 Version 7 Performance Topics . Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries.

SG24-5462 Implementing ESS Copy Services on S/390. SG24-2076-00 DB2 for OS390 Application Design for High Performance. see “How to get IBM Redbooks” on page 238. SG24-6121 DB2 UDB Server for OS/390 Version 6 Technical Update. SG24-6120 Storage Management with DB2 for OS/390. SC26-9945 © Copyright IBM Corp. SG24-5680 Other resources These publications are also relevant as further information sources: DB2 UDB for OS/390 and z/OS Version 7 What’s New. IBM Redbooks For information on ordering these publications. SG24-5945 DB2 UDB for OS/390 Version 6 Performance Topics. SG24-4562 DB2 UDB for OS/390 Version 6 Management Tools Package.Reference Guide. SG24-5333 IBM Enterprise Storage Server Performance Monitoring and Tuning Guide. GC26-9946 DB2 UDB for OS/390 and z/OS Version 7 Installation Guide.Learning by Example. GC26-9940 DB2 UDB for OS/390 and z/OS Version 7 Utility Guide and Reference. SG24-6289 DB2 UDB Server for OS/390 and z/OS Version 7 Presentation Guide. SG24-5486 Connecting WebSphere to DB2 UDB Server. SG24-2213 DB2 for MVS/ESA Version 4 Non-Data-Sharing Performance Topics. SG24-5485 DB2 for OS/390 and Continuous Availability. GC26-9936 DB2 UDB for OS/390 and z/OS Version 7 Command Reference.Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. SG24-62119 Parallel Sysplex Configuration: Cookbook. SC26-9934 DB2 UDB for OS/390 and z/OS Version 7 Messages and Codes. GG24-2233 Using RVA and SnapShot for Business Intelligence Applications with OS/390 and DB2. SG24-5421 DB2 for OS/390 Capacity Planning. DB2 for z/OS and OS/390 Version 7: Using the Utilities Suite. SG24-5759 DB2 Server for OS/390 Version 5 Recent Enhancements . SG24-5351 DB2 for OS/390 Version 5 Performance Topics. 2001 237 . SG24-6108 DB2 Java Stored Procedures -. SG24-2244 Developing Cross-Platform DB2 Stored Procedures: SQL Procedures and the DB2 Stored procedure Builder. SG24-5656 DFSMS Release 10 Technical Update.

SC26-9935 DB2 UDB for OS/390 and z/OS Version 7 Image. Redpieces are Redbooks in progress.com/redbooks Also download additional materials (code samples or diskette/CD-ROM images) from this Redbooks site. view. not all Redbooks become redpieces and sometimes just a few chapters will be published this way.htm How to get IBM Redbooks Search for additional Redbooks or redpieces. Click the CD-ROMs button on the Redbooks Web site for information about all the CD-ROMs offered. and Video Extenders. SC26-9948 DB2 UDB for OS/390 and z/OS Version 7 Data Sharing: Planning and Administration. SC26-9944 DB2 UDB for OS/390 and z/OS Version 7 Text Extender Administration and Programming. SC26-9932 DB2 UDB for OS/390 and z/OS Version 7 Administration Guide.htm Referenced Web sites These Web sites are also relevant as further information sources: ibm. SC26-9943 DB2 UDB for OS/390 and z/OS Version 7 SQL Reference.com/software/data/db2/os390/ DB2 for OS/390 DB2 Estimator ESS DB2 support and services ibm. SC26-9947 DB2 UDB for OS/390 and z/OS Version 7 ODBC Guide and Reference. SC26-9931 DB2 UDB for OS/390 and z/OS Version 7 Application Programming and SQL Guide. SC26-9949 OS/390 V2R10. Volume 7.0 DFSMS Using Data Sets. Spring 2000. white paper by David Witkowski available from ibm. 238 DB2 for z/OS and OS/390 Version 7 Performance Topics . SC26-9941 DB2 UDB for OS/390 and z/OS Version 7 XML Extender Administration and Reference.DB2 UDB for OS/390 and z/OS Version 7 Programming Guide and Reference for Java. as well as updates and formats. SC26-9933 DB2 UDB for OS/390 and z/OS Version 7 Release Planning Guide. SC26-7339 DB2 UDB for OS/390 Storage Management. or order hardcopy from the Redbooks Web site: ibm.com/storage/hardsoft/diskdrls/technology.com/software/data/db2/os390/support. by John Campbell and Mary Petras DB2 UDB for z/OS and OS/390 Performance on the IBM zSeries 900 Server. IBM Redbooks collections Redbooks are also available on CD-ROMs. Number 1.com/software/data/db2/os390/support. IDUG Solutions Journal.htm ibm.com/software/data/db2/os390/estimate/ ibm. download. The intent is to get the information out much quicker than the formal publishing process allows. Audio.

2001 239 . focuses on system capacity BLOB CCSID CCA CFCC CTT CEC CD CF CFRM CLI CLP CPU CSA DASD DB2 PM DBAT DBD DBID DBRM DSC DCL DDCS DDF DDL DLL DML DNS coded character set identifier client configuration assistant coupling facility control code created temporary table central electronics complex compact disk coupling facility coupling facility resource management call level interface command line processor central processing unit common storage area direct access storage device DB2 performance monitor database access thread database descriptor database identifier database request module dynamic statement cache.Abbreviations and acronyms AIX APAR ARM ASCII Advanced Interactive eXecutive from IBM authorized program analysis report automatic restart manager American National Standard Code for Information Interchange binary large objects DRDA DTT EA EBCDIC ECS ECSA EDM ERP ESA ETR distributed relational database architecture declared temporary tables extended addressability extended binary coded decimal interchange code enhanced catalog sharing extended common storage area environment descriptor management enterprise resource planning Enterprise Systems Architecture external troughput rate. local or global data control language distributed database connection services distributed data facility data definition language dynamic load library manipulation language data manipulation language domain name server FDT FTP GB GBP GRS GUI HPJ IBM ICF ICF ICMF IFCID IFI IRLM ISPF ISV I/O functional track directory File Transfer Program gigabyte (1.073. an elapsed time measure.741.824 bytes) group buffer pool global resource serialization graphical user interface high performance Java International Business Machines Corporation integrated catalog facility integrated coupling facility internal coupling migration facility instrumentation facility component identifier instrumentation facility interface internal resource lock manager interactive system productivity facility independent software vendor input/output © Copyright IBM Corp.

048. a processor time measure.576 bytes) object descriptor in DBD Open Data Base Connectivity Operating System/390 parallel access volume partitioned data set pageset identifier preventive service planning program temporary fix possibly uncommitted Query Management Facility Resource Access Control Facility relative byte address record format record identifier resource recovery services resource recovery services attach facility read stability repeatable read software developers kit System Management Interface Tool stored procedure system resource block task control block USS WLM Unix systems services workload manager ITSO IVP JDBC JFS JVM KB LOB LPL LPAR LRECL LRSN LVM MB OBD ODBC OS/390 PAV PDS PSID PSP PTF PUNC QMF RACF RBA RECFM RID RRS RRSAF RS RR SDK SMIT SP SRB TCB 240 DB2 for z/OS and OS/390 Version 7 Performance Topics .024 bytes) large object logical page list logically partitioned mode logical record length log record sequence number logical volume manager megabyte (1.ITR internal throughput rate. focuses on processor capacity International Technical Support Organization installation verification process Java Database Connectivity journaled file systems Java Virtual Machine kilobyte (1.

196 DB2 Installer 18 DB2 Management Tools Package 18 DB2 PM 185 DB2 PM and IFI enhancements 179 DB2 Restart Light 172 DB2 subsystem 2 DB2 subsystem parameters 211 DB2 subsystem performance 87 DB2 tools 17 DB2 V7 packaging 18 DB2 Version 7 overview 11 DB2 Warehouse Manager 17. 166 Cross Loader 14 CURRENT MEMBER 177 D Data Sharing 16 Bypass Group Attach 167 Data sharing 4 Group Attach support for DL/I Batch 168 local connect using STARTECB 167 DB2 Connect Personal Edition 18 DB2 Estimator 18. 19 db2advis 195 DB2CONN 168 DB2GROUPID 168 db2look 194 DBADM 13 DDL concurrency 99 deadlock detection 112 DEALLCT 104 DECLARE TEMPORARY TABLE 53 Declared Temporary Table 66 Declared Temporary Tables 62 DEGREE(ANY) 33 DELETE 2. 41. 2001 241 . 45 different data types 77 dimension table 82 DRAIN and RETRY 138 DRAIN_WAIT 138 DRDA server elapsed time reporting 162 DSETSTAT 186 DSN_STATEMENT_TABLE 27 DSN6SPRC 133 DSN8ED7 102 DSNDB07 65 DSNTEJWA 194 A ACCESS_DEGREE 30 Adding space to the workfiles 16 Adding workfiles 107 alias 13 Application enablement 12 ARESTP 105 assess the size of the Buffer Pools 219 Asynchronous preformat 88 AUTHCACH 102 Auto Alter 176 Availability and capacity 3 AVG 56 B Bind improvements 81 BUILD2 parallelism 134 Building indexes in parallel 121 C Cancel Thread NOBACKOUT 107 CARDF 142 CATMAINT utility 93 CFRM 175 Charge features 19 CHKFREQ 104 CICS group attach 168 CLUSTERATIO 142 Compression 198 Consistent restart 105 Consistent restart enhancements 16 © Copyright IBM Corp.Index Numerics 0002 183 0003 183 0147 183 0148 183 0217 180 0219 180 0220 180 0225 180 0319 180 -101 83 -118 46 -129 83 199 187 -216 36 225 189 5655-E62 19 5655-E63 19 5697-E98 19 64 GB central storage 198 Control Center 18 CopyToCopy 15 COPYTOCOPY utility 147 Correlated subquery 38 Coupling Facility Name Class Queues 16. 25.

DSNTEJWB 194 DSNTEJWC 194 DSNTEJWD 194 DSNTEJWF 194 DSNZPARM changes 185 DSSTIME 104 DYNAMIC 61 Dynamic utility jobs 14. 206 Evaluate uncommitted 98 EVALUNC 98 EXEC SQL 149 EXISTS predicate 41 EXPLAIN headings 27 EXPLAIN tables 26 EXTENTS 141 IFI 180 IMMEDWRI 170 IMMEDWRITE 170 IMMEDWRITE bind option 17 implementing new functions no effort 22 small effort 22 implementing new functions some effort 23 IMS 17 IMS group attach 169 IMS tools 17 IN predicate 35 incomplete units of recovery during shutdown 176 Index Advisor 192 INDREFLIMIT 143 IN-list 28 IN-List index access 28 INSENSITIVE 61 insensitive cursor 69 Introduction to the redbook 1 IRLM dynamic time out value 111 subsecond deadlock detection 112 IRLM time out 111 J Java BIND options 159 close prepared statements 161 dynamic SQL statement caching 160 matching data type and length 160 memory usage 159 positioned iterators 161 selecting columns 160 serialized profile 160 Java data types 159 Java support 13 JDBC and SQLJ performance considerations 159 JIT compilation 159 Join outer table 30 join transformation 38 JOIN_DEGREE 30 JVM 157 F fact table 82 failures on PREPARE 82 FARINDREF 143 FAROFFPOS 142 Fast switch 132 FETCH FIRST n ROWS 152 Fetch first n rows 70 FETCH INSENSITIVE 62 FETCH options 63 FETCH SENSETIVE 62 FlashCopy 209 FORCEROLLUP 138. 114 DYNAMICRULES(BIND) 159 E EDMBFIT 103 EDMDSPAC 104 EDMPOOL 103 Enabling VSAM I/O striping 205 ENDEXEC 149 Enhanced management of constraints 13 Enhanced stored procedures 13 Equal and Not Equal predicates 36 Equal predicate 34 ESS 90. 141 FREEPAGE 141 G Global transactions 15 Group Attach enhancements 17. 167 groupoverride 167 K Key performance enhancements 2 L leaf disorganization 146 LEAFFAR 146 LEAFNEAR 146 Limited fetch 12 LIST 117 LISTDEF 114 LOAD 88 LOAD partition parallelism 117 LOAD partitions in parallel 118 LOAD without SORTKEYS 122 H HPGRBRBA 98 I IDFORE 104 IFCID 217 92 IFCID 225 92 IFCIDs 180 242 DB2 for z/OS and OS/390 Version 7 Performance Topics .

15 Network monitoring 16 New features and tools 17 NUMLKTS 103 O OFFPOS 125 OFFPOSLIMIT 142 Online DSNZPARM 102 Online LOAD RESUME 14. 124 Online REORG enhancements 15. 107 Log suspend and resume 107 Log-only recovery 98 Long running UR warning message 110 M materialization 59 MAX 72 MAXDBAT 104 MAXRBLK 103 MAXRTU 104 message handling for CF/structure failure 176 Migration to DB2 Version 7 20 MIN 72 More parallelism with LOAD with multiple inputs 14 N NEARINDREF 143 NEAROFFPOS 142 Net Search Extender 17. 27 Planning for migration 20 R Reasons to migrate 20 Redbooks Web Site 238 Contact us xvii REFP 105 release skipping 20 REORG 88 repositioning 67 Restart Light 17 RESTART processing 117 RESTP 105 RESYNCMEMBER 169 RETRY 138 Retry of log read request 109 Index 243 . 191 PQ46759 148 PQ47178 59. 176 PQ46577 117 PQ46636 184. 131 Online subsystem parameters 16 OPTIMIZE FOR m ROWS 153 Optional no-charge features 18 OPTIONS 116 ORDER BY 74 ORGRATIO 145 Other enhancements 5 OW43946 207 PQ10465 79 PQ22046 77 PQ22895 170 PQ24933 77 PQ25337 170 PQ25914 198 PQ28813 82 PQ34667 20 PQ36206 82 PQ36933 198 PQ37807 186 PQ38035 97 PQ38174 199 PQ38455 111. 148 PQ45407 165.Data 18 Network computing 4. 82 PQ48588 60 PQ49458 153 precompiler services 13 PREFORMAT 88 preformat measurement 89 PREVIEW 116 pruning 57 PTASKROL 104 Q QBLOCK_TYPE 27 Quantified predicates 34 Query Management Facility 19 P packaging 18 Parallel Access Volumes 90.LOBVALA 103 LOBVALS 103 Log manager enhancements 16. 206 Parallel data set open 90 Parallelism 28 PARENT_QBLOCKNO 27 partial star join 84 PCTFREE 141 PERCDROP 144 Performance and availability 16 Performance tools 5 Persistent Coupling Facility Structure sizes 175 Persistent structure size changes 17 PLAN_TABLE 26. 60 PQ47833 83 PQ48306 81. 191 PQ43846 83 PQ44114 165 PQ44144 176 PQ44671 177 PQ44985 97 PQ45052 45 PQ45184 150 PQ45268 117. 112 PQ42180 169 PQ43357 188. 20 Net.

139 Stored Procedure Builder 18 Stored procedures COMMIT/ROLLBACK 157 String data types 160 Union everywhere 12 UNION syntax 49 uniqueness constraint 39 UNLOAD 14 UNLOAD utility 127 updatable DB2 subsystem parameters 211 UPDATE 2. 25. 60 PL/1 program 223 Searched UPDATE and DELETE 41 Security enhancements 15 SELECT MAX 74 self-referencing subselect 45 Self-referencing subselect on UPDATE or DELETE 13 self-referencing UPDATE/DELETE 46 SENSITIVE 61 sensitive cursor 69 SENSITIVE DYNAMIC 62 SEQCACH=SEQ 207 SET CURRENT DEGREE 28 SET LOG SUSPEND 108 -SET SYSPARM 102 SETXCF 175 Snapshot 209 SQL 2 SQL performance 2. 14 utilities output 227 V VARCHAR columns 79 VARCHAR index-only access 79 variable-length rows 99 VDWQ 90 view 13 Virtual storage 91 Visual Explain 18 VSAM Data Striping 204 VSAM I/O striping in OS/390 V2R10 215 X XML Extender 13 Z z/Series 198 T TABLE_TYPE 27 TEMP database 62 TEMPLATE 115 tools 17 U Unicode 161 UNICODE support 16 UNION EXISTS predicate 52 IN predicate 52 optimization 53 UNION ALL 56 UNION everywhere 49 244 DB2 for z/OS and OS/390 Version 7 Performance Topics . 41. 25 Star join 82 star join best environment 85 STARJOIN 82 STARTECB 167 STATHIST 139 STATIME 104 Statistics history 15. 45 UQ51114 177 USS 158 Utilities 3.RETRY_DELAY 138 RETVLCFK 79 REUSE 141 REXX language support 18 RLFERR 104 Row expression in IN predicate 12 Row expressions 34 RUNSTATS enhancements 138 RVA 209 S SCROLL 61 Scrollable cursors 12.

475”<->0.873” 250 <-> 459 pages .5” spine) 0.DB2 for z/OS and OS/390 Version 7 Performance Topics (0.

.

.

Back cover ® DB2 for z/OS and OS/390 Version 7 Performance Topics Description of performance and availability related functions Performance measurements of new or enhanced functions Usage considerations based on performance IBM DATABASE 2 Universal Database Server for z/OS and OS/390 Version 7 (DB2 Universal Database Server for z/OS and OS/390 Version 7.com/redbooks SG24-6129-00 ISBN 0738419672 . application development. This IBM Redbook describes the performance implications of several enhancements made available with DB2 V7. such as scrollable cursors. Specific recommendations are provided to help you implement IT solutions more effectively in your environment. There are many improvements to usability. or just DB2 V7 throughout this book) is the eleventh release of DB2 for MVS. and the new Restart Light option for data sharing environments. Customers and Partners from around the world create timely technical information based on realistic scenarios. This book will help you understand why migrating to Version 7 of DB2 can be beneficial for your applications and your DB2 subsystems. and performance. These enhancements include performance and availability delivered through new and enhanced utilities. For more information: ibm. It provides considerations and recommendations for the implementation of the new functions and for evaluating their performance and their applicability to your DB2 environments. dynamic changes to the value of many of the system parameters without stopping DB2. It brings to this platform many new data support. and the definition of view with the operators UNION or UNION ALL. and SQL language enhancements for e-business while building upon the traditional capabilities of availability. INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. support for UNICODE encoded data. support for COMMIT and ROLLBACK within a stored procedure. Experts from IBM. scalability. the option to eliminate the DB2 precompile step in program preparation.