Professional Documents
Culture Documents
DB2 (Mainframe)
DB2 (Mainframe)
Performance measurements of
new or enhanced functions
Paolo Bruni
Leif Pedersen
Mike Turner
Jan Vandensande
ibm.com/redbooks
International Technical Support Organization
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.
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.
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.
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.1 Key performance enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Performance highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Query performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Transaction performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Utility performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Subsystem and host platform synergy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.5 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Contents v
6.1.3 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.1.4 RESTART processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.1.5 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.2 LOAD partition parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.2.1 LOAD partitions in parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2.2 Building indexes in parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.2.3 Performance measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.3 Online LOAD RESUME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.3.1 Performance measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.3.2 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.3.3 Performance recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.4 UNLOAD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.4.1 Performance measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.4.2 Unloading partitions in parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.4.3 Unload from copy data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.5 Online REORG enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.5.1 Fast switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.5.2 BUILD2 parallelism for NPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.5.3 DRAIN and RETRY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.6 RUNSTATS enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.6.1 Statistics history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.6.2 DB2 catalog changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.6.3 Force update of aggregate statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.6.4 Performance considerations using new statistics columns . . . . . . . . . . . . . . . . . 141
6.7 COPYTOCOPY utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.7.1 Performance measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.8 Cross Loader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.8.1 The EXEC SQL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.9 MODIFY RECOVERY enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Contents vii
Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Spreadsheet example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Figures xi
xii DB2 for z/OS and OS/390 Version 7 Performance Topics
Tables
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, or just DB2 V7 throughout this book) is the
eleventh release of DB2 for MVS. It brings to this platform many new data support, application
development, and SQL language enhancements for e-business while building upon the
traditional capabilities of availability, scalability, and performance.
This IBM Redbook describes the performance implications of several enhancements made
available with DB2 V7. These enhancements include performance and availability delivered
through new and enhanced utilities, dynamic changes to the value of many of the system
parameters without stopping DB2, and the new Restart Light option for data sharing
environments. There are many improvements to usability, such as scrollable cursors, support
for UNICODE encoded data, support for COMMIT and ROLLBACK within a stored procedure,
the option to eliminate the DB2 precompile step in program preparation, and the definition of
view with the operators UNION or UNION ALL.
This book will help you understand why migrating to Version 7 of DB2 can be beneficial for
your applications and your DB2 subsystems. It provides considerations and
recommendations for the implementation of the new functions and for evaluating their
performance and their applicability to your DB2 environments.
Paolo Bruni is on assignment as a Data Management Specialist for DB2 for OS/390 at the
International Technical Support Organization, San Jose Center, where he conducts projects
on all areas of DB2 for OS/390. Before joining the ITSO in 1998, Paolo worked as a
Consultant IT Architect in IBM Italy. During his 31 years with IBM, in development and in the
field, Paolo’s work has been mostly related to database systems.
Leif Pedersen is an Advisory IT specialist in IBM Denmark with 12 years of experience with
DB2. During this period, Leif first designed and developed business applications running
against DB2, and, in the last 8 years, he assumed the role of DB2 system administrator. His
areas of expertise include DB2 performance and database design.
Mike Turner is an independent consultant based in the United Kingdom. He has 30 years of
experience in the mainframe database management field. His areas of expertise include DB2
performance, recovery, and data sharing. He has taught extensively on these topics.
Emma Jacobs
Yvonne Lyon
IBM International Technical Support Organization, San Jose Center
Ying Chang
IBM San Jose Laboratory
Vasilis Karras
IBM International Technical Support Organization, Poughkeepsie Center
Norbert Jenninger
DB2 PM Development, IBM Germany
Bart Steegmans
IBM Belgium
IBM trademarks
The following terms are trademarks of the International Business Machines Corporation in the
United States and/or other countries:
e (logo)® Redbooks
IBM ® Redbooks Logo
OS/390 S/390
DB2 DATABASE 2
Comments welcome
Your comments are important to us!
We want our IBM Redbooks to be as helpful as possible. 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.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to the address on page ii.
Preface xvii
xviii DB2 for z/OS and OS/390 Version 7 Performance Topics
1
Chapter 1. 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,
application development and SQL language enhancements for e-business while building
upon the traditional capabilities of availability, scalability, and performance.
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. A skip-level
migration, from DB2 for OS/390 Version 5, is also supported for the first time.
In this chapter we briefly introduce the major DB2 V7 enhancements specifically related to
performance in the areas of SQL, subsystem function, capacity and availability, utilities,
network computing, data sharing, and performance tools, and provide some general
considerations on the utilization and expectation of the performance related functions.
Chapter 2, “Overview of DB2 Version 7” on page 11 contains a more general but brief
description of most the functions available with DB2 V7. Detailed information is provided in
the documents and Web sites listed in “Related publications” on page 237. The redbook DB2
UDB Server for OS/390 and z/OS Version 7 Presentation Guide, SG24-6121, is also useful
and is referenced frequently throughout this publication.
This redbook is not exhaustive and does not include all descriptions and measurements
related to the new V7 features. DB2 and the MVS platform continue to evolve; the related
performance measurements are a work in progress. More information is planned to be
provided before the end of the year and will be included in other redbooks and redpapers.
As for each new version of DB2, 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, by means
of analyzing the path length for single-thread and multi-thread measurements, at the different
stages of DB2 product development. This is an on-going process during the whole
development cycle that involves a minimum of two very active releases of the product. Similar
measurements take place also for the performance assessment of the new DB2 V7 functions.
This document outlines the performance-related functions of DB2 V7, describes the
measured environments, and draws conclusions and recommendations based on the
measurements.
SQL
These enhancements affect SQL performance:
– Plan table changes: The V7 PLAN_TABLE has two new columns, and both the
PLAN_TABLE and the DSN_STATEMENT_TABLE have some new values in the
existing columns.
– 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, CURRENT DEGREE = ‘ANY’).
– Row value expressions: A predicate can compare a list of columns to a list of
expressions.
– Correlated subquery to join transformation: There are some additional situations
when transformation can take place for correlated subqueries only.
– 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.
– Union everywhere: The use of unions is expanded to anywhere that a subselect
clause was valid in previous versions of DB2.
– Scrollable cursors: Scrolling backwards as well as forwards is now allowed. This
enhancement also provides 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.
– MIN/MAX enhancement: A more efficient use of indexes for evaluation MIN and MAX
functions is now provided.
– Fewer sorts with order by: A better use of indexes now provides ordering of result
sets.
– 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. In order for this to be true you must, in your SQL, cast one column to the data
type of the other.
– VARCHAR index-only access: It is no longer necessary to set RETVLCFK=YES to
get index-only access in this special case.
– 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.
– Star join: Externalized parameter to allow star join at subsystem level and other
maintenance in this rapidly evolving area.
DB2 subsystem
These enhancements affect DB2 subsystem performance:
– Asynchronous preformat: Asynchronous preformat improves insert performance.
– Parallel data set open: Data set open/close processing for partitions in the same
partitioned table space/index is no longer a serial process.
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, work data sets, sort data
sets, and so on.
– 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.
– Online LOAD RESUME: It is now possible to load data into tables with a utility that
acts like a normal insert program.
– UNLOAD: This is a new utility to unload data from tables without any influence on
business applications.
– Online REORG enhancements: The FAST SWITCH phase has been improved 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.
Chapter 1. Introduction 3
– 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.
– Cross Loader: This new functionality makes it possible to move data across multiple
databases, even across multiple platforms.
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.
Stored procedures with COMMIT/ROLLBACK: This makes it possible to implement
more complex stored procedures that are invoked by Windows and UNIX clients.
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.
Considerations on SQLJ and JDBC performance: These recommendations, if they are
implemented, can have a dramatic effect on the performance of your SQLJ applications.
UNICODE: This provides full support for a third encoding scheme.
DRDA server elapsed time reporting: This makes it easier to monitor bottlenecks in
client/server applications.
Data sharing
These enhancements improve availability, 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, PSID and partition number.This enhancement reduces the performance impact of
purging group buffer pool (GBP) entries for GBP dependent page sets.
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. Applications, using
the group attach name, can request to be notified when a member of the data sharing
group becomes active on the executing OS/390 image. With DB2 V7 you can specify the
group attach name for DL/I batch applications.
IMMEDWRITE bind option: The IMMEDWRITE bind/rebind option, introduced by APAR
in DB2 V5 and V6, is fully implemented in DB2 V7.
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.
Persistent Coupling Facility structure sizes: After altering the size of DB2 structures,
DB2 V7 keeps track of their size across DB2 executions and structure allocations.
Miscellaneous items:
• During normal shutdown processing, 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.
• DB2 V7 reduces the MVS to DB2 communication that occurs during a coupling
facility/structure failure. This enhancement will decrease recovery time in such a
failure situation.
Performance tools
These enhancements are related to performance tools in DB2 V7:
IFI enhancements for V7: Several new IFCIDs have been added, others have changed,
and the DSNZPARM has a new parameter to help in synchronizing the writing of IFCID
records.
DB2 PM changes and new functions: Statistics and accounting records have been
improved to help in identifying the event involved.
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, the existing indexes, and the SQL workload.
DB2 Estimator: Several new DB2 for OS/390 V7 functions have been added to DB2
Estimator, including: the new UNLOAD utility, more parallel LOAD of partitions, UNICODE
encoding scheme, new built-in functions, the FETCH FIRST n ROWS ONLY clause, and
scrollable cursors.
Other enhancements
These improvements are not strictly internal to DB2, but still impact DB2 performance:
DB2 and zSeries: DB2 will benefit from large real memory support, 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. FlashCopy is the ESS feature
to use for DB2 backup in combination with log suspend/resume.
Here we list the performance enhancements which we considered most important based on
current measurement results and value. We have arbitrarily grouped them in the areas of:
Query performance
Transaction performance
Utility performance
Subsystem and host platform synergy
Migration
Chapter 1. Introduction 5
Correlated subquery transformation to join:
SELECT A1 FROM TABA WHERE A1 IN
(SELECT B1 FROM TABB WHERE B2=A2)...
This is transformed into:
SELECT A1 FROM TABA,TABB WHERE A1=B1 AND B2=A2...
The transformation improves performance by allowing a reduction in CPU time and up to
10 times faster elapsed time. The larger the outer table in comparison with the result table,
the more the benefits. The IN, +ANY, +SOME, EXISTS predicates can be transformed to
join for SELECT, UPDATE, and DELETE. Duplicate rows must be removed from TABB.
Sorting can be avoided for the = predicate on ORDER BY key:
SELECT FROM TABA WHERE A2=5 ORDER BY A1,A2,A3
This is equivalent to:
SELECT FROM TABA WHERE A2=5 ORDER BY A1,A3
The presence of an index on A1,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,
avoiding the need for 2 indexes, one ascending, one descending, 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. With DB2 V7, 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, CURRENT DEGREE = ‘ANY’.)
Parallelism for IN-list access show improvements in elapsed time up to 5 times.
20 18.5
MB/sec
15
11.4 10.5
10 8.2
5 4.2 4.5
2.5 3.2
0
3390-3 Ramac3 ESS E20 ESS F20 - 1 ESS F20 - 4
RVA T82 RVA X82 ESS F20 - 0 ESS F20 - 2
Asynchronous preformatting
Disk space needs to be preformatted before a row/key can be inserted. Prior to V7,
preformatting takes place at CREATE or REORG time, and then when the limit of the
highest allocated RBA is reached during INSERT. This was a synchronous operation
which could impact performance. With V7, an internal threshold triggers the formatting
asynchronously before the end of the formatted area is reached. 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.
Chapter 1. Introduction 7
S W IT C H a n d F A S T S W IT C H tim e s
0.5
0
3390 RVA2 ESS
O n lin e LO AD RESUM E
300 281
230 214
200 171
100
0
INSERT Online LOAD RESUME
The introduction of the new zSeries processor and OS/390 2.10 has enabled the exploitation
of real storage exceeding the already theoretical 2 GB limit. The new z900 servers have
increased the single processor speed by 20%, and the number of engines in a complex is
increased to 16. The maximum configurable real storage is 64 GB. The dataspace buffer pool
support, introduced with DB2 V6, can now be utilized to provide virtual storage constraint
relief to the DBM1 address space. Larger buffer pools can reduce disk I/O rate. With virtual
storage and I/O relieved, DB2 can promote an almost linear performance scalability taking full
advantage of the bigger and faster processors.
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. By
contrast, the hiperpool provides less storage, 8 GB total, no direct I/O support, and it cannot
contain updated pages.
1.2.5 Migration
CATMAINT, the Catalog migration utility, has been largely improved (see Figure 1-4). The
execution of step1 of the utility, the actual migration, 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. Catalog getpages are reduced 7 times and the internal sorts have been almost
completely eliminated.
Chapter 1. Introduction 9
C a t a lo g M ig r a tio n U t ility (C A T M A IN T )
1000
944
900 CPU time Elapsed time
834
Time in seconds 800 768
700
600
500
400
300 250
192 194
200
100 82
6
0
V5->V6 V5->V6 V5->V7 V6->V7
In this chapter, we summarize the main enhancements of DB2 V7, we look at the changes in
the packaging of the product, and we provide some considerations on migration.
UNION everywhere
This enhancement satisfies a long-standing requirement. 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.
Scrollable cursors
Scrollable cursors give your application logic ease of movement through the result table using
simple SQL and program logic. 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.
Support for scrollable cursors enables applications to use a powerful new set of SQL to fetch
data using a cursor at random, both in the forward and backward direction. The syntax can
replace cumbersome logic techniques and coding techniques and improve performance.
Scrollable cursors are especially useful for screen-based applications. You can specify that
the data in the result table remain static, or do the data updates dynamically.
You can also specify that the data in the result table remain insensitive or sensitive to
concurrent changes in the database. If you choose to be sensitive to changes, you can
update the database. For example, an accounting application can require that data remain
constant, while an airline reservation system application must display the latest flight
availability information.
Limited fetch
This function consists of a FETCH FIRST ’n’ ROWS SQL clause and a fast implicit close.
A new SQL clause and a fast close improve performance of applications in a distributed
environment. You can use the FETCH FIRST ’n’ ROWS clause to limit the number of rows
that are prefetched and returned by the SELECT statement. 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. This tells DB2 that you are only interested in the first row, and
you want DB2 to ignore the other rows.
Precompiler services
With DB2 V7, you can take advantage of precompiler services to perform the tasks currently
executed by the DB2 precompiler. This API can be called by the COBOL compiler. By using
this option, you can eliminate the DB2 precompile step in program preparation and take
advantage of language capabilities that had been restricted by the precompiler. Use of the
host language compiler enhances DB2 family compatibility, making it easier to import
applications from other database management systems and from other operating
environments.
Java support
DB2 V7 implements support for the JDBC 2.0 standard and, in addition, support for
userid/password usage on SQL CONNECT via URL, and the JDBC Driver execution under
IMS.
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), as well as support for user-defined external (non-SQL) functions
written in Java.
The base object for both the UPDATE statement and the WHERE clause is the EMP table.
DB2 evaluates the complete subquery before performing the update.
XML Extender
DB2 V7 provides more flexibility for your enterprise applications and makes it easier to call
applications. The family adds DB2 XML Extender support for the XML data type. This
extender allows you to store an XML object either in an XML column for the entire document,
or in several columns containing the fields from the document structure.
Using a LISTDEF facility, you can standardize object lists and the utility control statements
that refer to them. Standardization reduces the need to customize and change utility job
streams over time. The use of TEMPLATE utility control statements simplifies your JCL by
eliminating most data set DD cards. Now you can provide data set templates, and the DB2
product dynamically allocates the data sets that are required based on your allocation
information. Database administrators require less time to maintain utilities jobs, and database
administrators who are new to DB2 will learn to perform these tasks more quickly.
UNLOAD
With DB2 V7 you can take advantage of a new utility, UNLOAD, which provides faster data
unloading than was available with the DSNTIAUL program. The UNLOAD utility combines the
unload functions of REORG UNLOAD EXTERNAL with the ability to unload data from an
image copy.
The SORTKEYS keyword enables the parallel index build of indexes. Each load task takes
input from a sequential data set and loads the data into a corresponding partition. 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. If there is too much data to perform the sort in memory, the sort
product writes the keys to the sort work data sets. The sort tasks pass the sorted keys to their
corresponding build task, each of which builds one index. If the utility encounters errors
during the load, DB2 writes error and error mapping information to the error and map data
sets.
Cross Loader
The enhancement allows EXEC SQL statements results as input to the Load utility. Both local
DB2s and remote DRDA compliant databases can be accessed.
CopyToCopy
This feature provides the capability to produce additional image copies recorded in the DB2
catalog.
Statistics history
As the volume and diversity of your business activities grow, you may require changes to the
physical design of DB2 objects. V7 of DB2 collects statistic history to track your changes.
With historical statistics available, DB2 can predict the future space requirements for table
spaces and indexes more accurately and run utilities to improve performance. DB2 Visual
Explain utilizes statistics history for comparison with new variations that you enter so you can
improve your access paths. DB2 stores statistics in catalog history tables. To maintain
optimum performance of processes that access the tables, use the MODIFY STATISTICS
utility. 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.
Global transactions
Privileged application can use multiple DB2 agents or threads to perform processing that
requires coordinated commit processing across all the threads. DB2 V7 (and V6 RML), via a
transaction processor, treats these separate DB2 threads as a single “global transaction” and
commits all or none.
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.
This enhancement:
Eliminates the flow of unencrypted user IDs and passwords across the network.
Enables single-logon capability for DRDA clients by using the Kerberos principle name as
the global identity for the end user.
Simplifies security administration by using the Kerberos principle name for connection
processing and by automatically mapping the name to the local user ID.
Uses the Resource Access Control Facility (RACF) product to perform much of the
Kerberos configuration. RACF is a familiar environment to administrations of OS/390.
Eliminates the need to manage authentication in two places, the RACF database, and a
separate Kerberos registry.
Network monitoring
DB2 V7 introduces reporting server elapsed time at the workstation. Workstations accessing
DB2 data can now request that DB2 return the elapsed time of the server, which is used to
process a request in reply from the DB2 subsystem. The server elapsed time allows remote
clients to quickly determine the amount of time it takes for DB2 to process a request. The
server elapsed time does not include any network delay time, which allows workstation
clients, in real-time, to determine performance bottlenecks among the client, the network, and
DB2.
Restart Light
A new feature of the START DB2 command allows you to choose Restart Light for a DB2
member. Restart Light allows a DB2 data sharing member to restart with a minimal storage
footprint, and then to terminate normally after DB2 frees retained locks. 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. If you experience a system failure in a
Parallel Sysplex, the automated restart in “light” mode removes retained locks with minimum
disruption. You should consider using DB2 Restart Light with restart automation software,
such as OS/390 Automatic Restart Manager.
Net Search Extender adds the power of fast full-text retrieval to Net.Data, Java, or DB2 CLI
applications. It also offers application programmers a variety of search functions.
With V7, DB2 delivers even more tools, which have been the subject of specific
announcements in September 2000 and March 2001, together with several IMS tools. You
have the opportunity of a trial period to discover and verify the benefits of these tools, some
completely new to the server, others being new versions of tools already available with DB2
V6. Some of the new tools are:
DB2 Bind Manager, to avoid unnecessary binds
DB2 Log Analysis Tool, to assist in using the log information
DB2 SQL Performance Analyzer, to evaluate the cost of a query before it runs
DB2 Change Accumulation, to consolidate copies and logging offline
DB2 Recovery Manager, to simplify recovery of data from DB2 and IMS
These features and tools work directly with DB2 applications to help you use the full potential
of your DB2 system. When ordering the DB2 base product, you can select the free and
chargeable features to be included in the package.
With DB2 V7, most utilities have been grouped in separate independent products. All the
utilities are shipped deactivated with the Base Engine. The corresponding product licences
must be obtained to activate the specific functions of the utilities. However, all utilities are
always available for execution on DB2 Catalog and Directory and for the Sample Database.
DB2 Extenders:
– Text
– Image
– Audio
– Video
– XML
The Query Management Facility product is part of the DB2 Warehouse Manager feature, but
it is also still available as a separate feature on its own.
With DB2 V7, 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 optional associated agreements for Acquisition of Support. The DB2 Utilities are
grouped in these categories:
DB2 Operational Utilities, program number 5655-E63, which include Copy, Load (with the
DB2 family Cross Loader function), Rebuild, Recover, Reorg, Runstats, Stospace, and the
new utilities Unload and Exec SQL.
DB2 Diagnostic and Recovery Utilities, program number 5655-E62, which include Check
Data, Check Index, Check LOB, Copy, CopyToCopy, Mergecopy, Modify Recovery, Modify
Statistics, Rebuild, and Recover.
DB2 Utilities Suite, program number 5697-E98, which combines the functions of both DB2
Operational Utilities and DB2 Diagnostic and Recovery Utilities in the most cost effective
option.
If you are planning to skip Version 6, you must get the right level of education and make sure
that all of the incompatible changes are found. You need to plan for adequate time. PQ34667
must be applied, prerequisite software must be installed, and third parties must have their
support in place. Finally, you must plan for testing for the applications and settings that are
unique to your installation.
If you are running Version 5 today and considering moving to Version 6 or waiting for Version
7, you should consider that the customer base for Version 6 is now covering most workloads,
and weigh that against saving a cycle but running some risks on going to Version 7. Of course
there are functions that are only in Version 7, and if you need them, you may want to get there
quickly, but with some extra testing.
While we expect the majority of our customers to be migrated to Version 6 in the next few
months, there are some important quality improvements in Version 7 that may allow some
customers to save time by skipping over Version 6. As time goes by, release skipping to V7 is
expected to become more typical. 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, or have just migrated to Version 5.
They can migrate to Version 5 if needed, and then skip over Version 6 directly to Version 7
next year.
The result of extra work in testing the DB2 V7 at the lab is a more solid product, with a
significantly higher availability under stress conditions. Your choice will depend upon whether
you need some specific functions of Version 6 or Version 7 this year. If so, then it is time to
find the needed resources and migrate. 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, especially if you
migrate to the new release much earlier than you intended.
Several of these changes are also crucial for warehouse type of solutions. The improvement
provided by correlated subqueries is huge for applications that make use of them, such as
PeopleSoft.
There are some useful functions for users and vendors, 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, patterns, and dynamic allocation
Better handling of DEFER DEFINE data sets
DBAs and system programmers will appreciate the warehouse integration utilities:
– New UNLOAD utility
– LOAD enhancements:
• LOAD from cursor, 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
3.1.1 PLAN_TABLE
The V7 PLAN_TABLE has two new columns, giving it a total of 51 columns and some new
values. The complete PLAN_TABLE definition is shown in Figure 3-1.
QUERYNO INTEGER NOT NULL PREFETCH CHAR(1) NOT NULL WITH DEFAULT
QBLOCKNO SMALLINT NOT NULL COLUMN_FN_EVAL CHAR(1) NOT NULL WITH DEFAULT
APPLNAME CHAR(8) NOT NULL MIXOPSEQ SMALLINT NOT NULL WITH DEFAULT
PROGNAME CHAR(8) NOT NULL --------- 28 column format ---------
PLANNO SMALLINT NOT NULL VERSION VARCHAR(64) NOT NULL WITH DEFAULT
METHOD SMALLINT NOT NULL COLLID CHAR(18) NOT NULL WITH DEFAULT
CREATOR CHAR(8) NOT NULL ---------30 column format ---------
TNAME CHAR(18) NOT NULL ACCESS_DEGREE SMALLINT
TABNO SMALLINT NOT NULL ACCESS_PGROUP_ID SMALLINT
ACCESSTYPE CHAR(2) NOT NULL JOIN_DEGREE SMALLINT
MATCHCOLS SMALLINT NOT NULL JOIN_PGROUP_ID SMALLINT
ACCESSCREATOR CHAR(8) NOT NULL ---------34 column format ---------
ACCESSNAME CHAR(18) NOT NULL SORTC_PGROUP_ID SMALLINT
INDEXONLY CHAR(1) NOT NULL SORTN_PGROUP_ID SMALLINT
SORTN_UNIQ CHAR(1) NOT NULL PARALLELISM_MODE CHAR(1)
SORTN_JOIN CHAR(1) NOT NULL MERGE_JOIN_COLS SMALLINT
SORTN_ORDERBY CHAR(1) NOT NULL CORRELATION_NAME CHAR(18)
SORTN_GROUPBY CHAR(1) NOT NULL PAGE_RANGE CHAR(1) NOT NULL WITH DEFAULT
SORTC_UNIQ CHAR(1) NOT NULL JOIN_TYPE CHAR(1) NOT NULL WITH DEFAULT
SORTC_JOIN CHAR(1) NOT NULL GROUP_MEMBER CHAR(8) NOT NULL WITH DEFAULT
SORTC_ORDERBY CHAR(1) NOT NULL IBM_SERVICE_DATA VARCHAR(254) NOT NULL WITH DEFAULT
SORTC_GROUPBY CHAR(1) NOT NULL --------43 column format ----------
TSLOCKMODE CHAR(3) NOT NULL WHEN_OPTIMIZE CHAR(1) NOT NULL WITH DEFAULT
TIMESTAMP CHAR(16) NOT NULL QBLOCK_TYPE CHAR(6) NOT NULL WITH DEFAULT
REMARKS VARCHAR(254) NOT NULL BIND_TIME TIMESTAMP NOT NULL WITH DEFAULT
--------- 25 column format --------- ------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------------
New columns PARENT_QBLOCKNO SMALLINT NOT NULL WITH DEFAULT
TABLE_TYPE CHAR(1)
-------51 column format-----------
PARENT_QBLOCKNO Contains the QBLOCKNO of the parent query block. It shows the
hierarchy of dependencies between query blocks.
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.6, “UNION everywhere” on page 49).
QB QBLOCKNO
PN PLANNO
MT METHOD
TABLE TNAME
AT ACCESSTYPE
MC MATCHCOLS
INDEX ACCESSNAME
PF PREFETCH
IXO INDEXONLY
PQ PARENT_QBLOCKNO
TT TABLE_TYPE
JT JOIN_TYPE
CFE COLUMN_FN_EVAL
PM PARALLELISM_MODE
AD ACCESS_DEGREE
AG ACCESS_PGROUP_ID
JD JOIN_DEGREE
JG JOIN_PGROUP_ID
SCG SORTC_PGROUP_ID
SNG SORTN_PGROUP_ID
QBT QBLOCK_TYPE
3.2.1 Description
IN-List parallelism is now fully supported in DB2 V7. DB2 V7 adds parallelism support not
only for the outer table, but also for access to a single table. This enhancement has the
potential of improving elapsed times significantly over the non-parallel performance,
depending on the number of parallel processes available.
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.
The examples below were Explained in both V6 and V7 via SPUFI after issuing a SET
CURRENT DEGREE = ‘ANY’. The definition of the tables and indexes used in the examples
are shown in Figure 3-2.
800 rows
Note: CUST_PART is partitioned into 4 partitions Note: ORD_PART is partitioned into 4 partitions
by CUST_NO values: by CUST_NO values:
CREATE UNIQUE INDEX XCUSTNOP CREATE INDEX X2CNO
ON TABLE CUST_PART(CUST_NO) ON TABLE ORD_PART(CUST_NO)
CLUSTER CLUSTER
(PART 1 VALUES (2000), (PART 1 VALUES (2000),
PART 2 VALUES (4000), PART 2 VALUES (4000),
PART 3 VALUES (6000), PART 3 VALUES (6000),
PART 4 VALUES (99999)) ... PART 4 VALUES (99999)) ...
Figure 3-2 Table and index definitions for IN-List parallelism example
CPU parallelism is always chosen by the Optimizer in preference to I/O parallelism, except in
a few cases where CPU parallelism is not supported, but I/O parallelism is. CPU parallelism
has all the benefits of I/O parallelism (multiple I/O streams) plus more. CPU parallelism is
used for both I/O-bound and CPU-bound queries.
SELECT *
FROM ORD_PART
WHERE CUST_NO IN (1, 2001, 4001, 6001)
Version 6 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 ORD_PART N 1 X2CNO N NNNN NNNN -- -- -- -- -- --- ---
Version 7 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 ORD_PART N 1 X2CNO S N NNNN NNNN C 2 1 -- -- --- ---
In both V6 and V7, the Optimizer has chosen a Hybrid join (METHOD = 4) with ORD_PART
as the outer table of the join. The access to the outer table is via the index X2CNO using the
special index access for IN-list predicates (ACCESS_TYPE = ‘N’).
In V6, this IN-list access prevents the use of parallelism. In V7, the Optimizer chooses CPU
parallelism with degree three for both the table accesses (ACCESS_DEGREE = 3) and for
the join (JOIN_DEGREE = 3).
SELECT *
FROM ORD_PART O INNER JOIN CUST_PART C
ON O.CUST_NO = C.CUST_NO
WHERE O.CUST_NO IN (1, 2001, 4001, 6001)
Version 6 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 ORD_PART N 1 X2CNO N NNNN NNNN -- -- -- -- -- --- ---
1 2 4 CUST_PART I 1 XCUSTNOP L N NNNN NNNN -- -- -- -- -- --- ---
Version 7 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 ORD_PART N 1 X2CNO S N NNNN NNNN C 3 1 -- -- --- ---
1 2 4 CUST_PART I 1 XCUSTNOP L N NNNN NNNN C 3 1 3 1 --- ---
3.2.2 Performance
The performance tests were performed on a 9672-ZZ7 LPAR with four processors, RAMAC 3
DASD, and OS/390 2.8.
A single table performance test was run. The SQL and Explain output are shown in
Figure 3-5. The CUSTOMER table used in the test is taken from the TPC-H benchmark
definition. The table contained 4.5 million rows.
The column definitions of the CUSTOMER table are shown Table 3-3. The index XNKEY is an
index on the column C_NATIONKEY. The results of the test are shown in Table 3-4. In this
test the query was I/O bound and therefore the Optimizer has chosen to use parallelism with
degree seven, which is the number of values in the IN-list predicate. 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.
Version 6 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 CUSTOMER N 1 XNKEY S N NNNN NNNN -- -- -- -- -- --- ---
Version 7 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 CUSTOMER N 1 XNKEY S N NNNN NNNN C 7 1 -- -- --- ---
C_NAME VARCHAR(25)
C_ADDRESS VARCHAR(40)
C_PHONE CHAR(15)
C_ACCTBAL DECIMAL
C_MKTSEGMENT CHAR(10)
C_COMMENT VARCHAR(117)
Table 3-4 IN-List performance test results for single table access
Test Elapsed secs CPU secs
V6 1032.13 20.16
V7 223.32 21.63
A second test was run, using a join. The SQL and Explain outputs are shown in Figure 3-6.
The PART and LINEITEM tables used in the test are also taken from the TPC-H benchmark.
The PART table contained 6 million rows and the LINEITEM table contained 180 million rows.
The column definitions of the PART table are shown Table 3-5. The index XPSTPM is an
index on the PART table columns P_SIZE, P_TYPE, P_PARTKEY, and P_MFGR. The column
definitions of the LINEITEM table are shown Table 3-6. The index XLPART is an index on the
LINEITEM table column L_PARTKEY.
Version 6 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 PART N 2 XPSTPM N NNNN NNNN -- -- -- -- -- --- ---
1 2 1 LINEITEM I 1 XLPART N NNNN NNNN -- -- -- -- -- --- ---
Version 7 Explain
QB PN MT TABLE AT MC INDEX PF IXO SORTN SORTC PM AD AG JD JG SCG SNG
1 1 0 PART N 2 XPSTPM N NNNN NNNN C 10 1 -- -- --- ---
1 2 1 LINEITEM I 1 XLPART N NNNN NNNN C 10 1 10 1 --- ---
P_NAME VARCHAR(55)
P_MFGR CHAR(25)
P_BRAND CHAR(10)
P_TYPE VARCHAR(25)
P_SIZE INTEGER
P_CONTAINER CHAR(10)
P_RETAILPRICE DECIMAL
P_COMMENT VARCHAR(23)
L_PARTKEY INTEGER
L_SUPPKEY INTEGER
L_QUANTITY DECIMAL
L_EXTENDEDPRICE DECIMAL
L_DISCOUNT DECIMAL
L_TAX DECIMAL
L_RETURNFLAG CHAR(1)
L_LINESTATUS CHAR(1)
L_SHIPDATE DATE
L_COMMITDATE DATE
L_RECEIPTDATE DATE
L_SHIPINSTRUCT CHAR(25)
L_SHIPMODE CHAR(10)
L_COMMENT VARCHAR(44)
V6 2611.92 22.22
V7 278.46 23.7
3.2.3 Conclusions
Significant improvements in elapsed time can be achieved by exploiting query parallelism for
queries containing IN-list predicates.
3.2.4 Recommendations
Consider rebinding with DEGREE(ANY) those packages containing large queries for which
Explain shows an access type of ‘N’.
expression = expression
<> (fullselect)
>
<
>=
<=
=
>
<
, ,
( expression2 ) = ( expression2 )
<> New in V7
=
Basic predicates
SELECT *
Show all indexes for table FROM SYSIBM.SYSINDEXES T1
PAOLOR2.ACCOUNT WHERE (T1.TBCREATOR, T1.TBNAME) = ('PAOLOR2', 'ACCOUNT')
ORDER BY T1.CREATOR, T1.NAME;
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. See
Figure 3-9 for the IN predicate syntax. See Figure 3-10 for an example.
expression IN (fullselect)
NOT ,
( expression )
,
( expression ) IN (fullselect) New in V7
NOT
IN predicate
3.3.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, then SQLCODE -216 will be returned:
Multiple expressions are not valid in an IN-list, only a subquery that returns multiple rows. For
example, this predicate is valid:
WHERE (T1.NAME, T1.CREATOR) IN (SELECT T2.TBCREATOR, T2.TBNAME
FROM SYSIBM.SYSINDEXES T2)
3.3.5 Performance
This is primarily a usability enhancement, but it can impact performance. Rewriting a query to
use row expressions may significantly change the access path for that query. The change
may improve or worsen performance depending on the new access path.
It is a matching index scan on two columns of the index DSNDXX03, which contains key
columns TBCREATOR, TBNAME, CREATOR, and NAME. Since the access path is the
same, there is no performance impact of using a row expression in this case.
The column headings of the Explain output are described in Table 3-2 on page 27.
Version 7 Explain:
Let us look at another example, the row expression shown in Figure 3-12.
Row expressions:
SELECT L_DISCOUNT,SUM(L_QUANTITY),
AVG(L_QUANTITY*L_EXTENDEDPRICE)
FROM LINEITEM
WHERE L_ORDERKEY BETWEEN 10220001 and 1030000
AND L_QUANTITY>10
AND(L_SUPPLY,LPARTKEY)IN
(SELECT PS_SUPPKEY,PS_PARTKEY
FROM PARTSUPP
PS_SUPPLYCOST BETWEEN 115 AND 116)
GROUP BY DISCOUNT;
QB MT TABLE AT MC IXO
1 0 LINEITEM N 3 Y
1 3
2 0 PARTSUPP I 0 Y
2 3
This query can be rewritten using EXISTS, or using a join, as shown in Figure 3-13. Here the
rewrite can significantly alter the access path, as shown in Figure 3-12. Performance in these
queries depends on the number of rows that are qualified from the PARTSUPP table. If the
number of qualified rows from the subquery is large, the row expression generally tends to
have worse performance.
3.3.6 Conclusions
Row expressions can make a query easier to read and understand. Performance can vary.
3.3.7 Recommendations
Always compare the access paths with and without row expressions so that you are aware of
any performance implications.
DB2 V7 adds some additional situations when transformation can take place, for correlated
subqueries only (for non-correlated subqueries, all conditions continue to apply):
The requirement for the single column returned by the subquery to be unique is removed.
The EXISTS predicate is supported.
A subquery in a WHERE clause can be transformed, not only when the outer statement is
a SELECT, but also when it is a searched UPDATE or DELETE statement.
The transformation is most likely to provide performance benefits when the result table in the
subquery is much smaller than the outer table. The join gives DB2 the opportunity to process
the smaller table first.
Figure 3-14 shows the definition of the tables used in the following examples. The table CUST
is a Customer table. The table ORD is an Order table connected to the CUST table by RI.
Figure 3-14 Table and index definitions for correlated subquery examples
In DB2 V7, in order to avoid incorrect results, duplicates must be eliminated when accessing
the ORD table. 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).
SELECT *
FROM CUST C
WHERE CUST_NO IN
(SELECT CUST_NO
FROM ORD O
WHERE O.AMOUNT = C.CRED_LIM );
Version 6 Explain:
Version 7 Explain:
Example 2 in Figure 3-16 shows the same query as before, but with a restrictive predicate in
the subquery (ORD_DATE < ‘1999-01-01’) which reduces the size of the subquery result set.
In DB2 V7 the query is again transformed into a nested loop join, but this time the ORD table
is the outer table. It is accessed using the index XODATE which is an index on the
ORD_DATE column.
This shows one of the advantages of the transformation. It gives DB2 flexibility to decide in
which order to process the tables. Once again, duplicate CUST_NO values must be
eliminated from the ORD table to avoid incorrect results. In Example 2 this is done by sorting
to eliminate the duplicate CUST_NO values. This is shown in the Explain by SORTC_UNIQ =
SORTC_JOIN = ‘Y’ in the join row.
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 . A M OU N T = C .C R E D_ L IM
AN D O . O R D_ D AT E < ' 1 9 99 - 01 - 0 1 ') ;
V e rs i on 6 Ex p l ai n :
QB PN MT T A BL E AT MC I N D EX PF I XO SORTN S OR T C JT QBT
1 1 0 C U ST R 0 S N NNNN N NN N S E LE C T
2 1 0 ORD I 1 X O D AT E N NNNN N NN N C O RS U B
V e rs i o n 7 Ex p l a in :
QB PN MT T A B LE AT MC I N D EX PF IXO S OR T N S O RT C JT QBT
1 1 0 ORD I 1 X O D AT E N N NN N N N NN S E L EC T
1 2 1 CUST I 1 X C U ST N O N N NN N Y Y NN S E L EC T
Example 3:
SELECT *
FROM CUST C
WHERE EXISTS
(SELECT 1
FROM ORD O
WHERE O.CUST_NO = C.CUST_NO);
Version 6 Explain:
Version 7 Explain:
UPDATE CUST C
SET CRED_LIM = CRED_LIM * 1.1
WHERE CUST_NO IN
(SELECT CUST_NO
FROM ORD O
WHERE O.AMOUNT = C.CRED_LIM);
Version 6 Explain:
Version 7 Explain:
Version 6 Explain:
Version 7 Explain:
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 )
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.
Version 7 Explain:
The test was repeated a number of times. The total measurements are shown in Table 3-8.
Table 3-8 Subquery transformation select performance
UPDATE T1 X
SET C2 = C2 + 1
WHERE C3 IN
(SELECT C2
FROM T2
WHERE T2.C3 = 'A' AND T2.C1 = X.C1)
Version 7 Explain:
V6 72.6 16.72
parallel,
degree 7
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.
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 )
UPDATE CUST C1
SET CRED_LIM = (SELECT MAX(CRED_LIM)
FROM CUST C2
WHERE C2.TOWN = C1.TOWN)
DB2 now will accept the syntax of this statement, and the SQLCODE -118 will not be
returned.
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
Two-step processing will NOT occur because the
SET CRED_LIM = CRED_LIM *1.1
WHERE EXISTS (SELECT 1
updated column does not appear either in the
FROM CUST C2 WHERE clause of the UPDATE or the correlation
WHERE TOWN = 'MANCHESTER' predicate of the subquery.
AND C2.CUST_NO = C1.CUST_NO);
3.5.3 Performance
The only performance issues relate to the two-step processing of a correlated subquery. A
simple test was run. 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. These figures are not from measurements in a fully controlled environment (DB2
was dedicated, not the hardware), but they are indicative of relative cost. The two update
statements and their Explain outputs are shown in Figure 3-26. The table CUST2 is identical
in every way to the table CUST.
Delta +76 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. That work file is
then read to apply the updates. The extra getpages to BP1 are caused by this second
updating step. The rows in the CUST table are mapped two per page (MAXROWS 2).
Therefore 150 rows, if randomly distributed, would be held on 75 pages. The actual increase
in BP1 getpages is 76.
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. 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,
we get the results shown in Table 3-12. The self-referencing update performs better overall in
this case.
Table 3-12 Self-referencing UPDATE versus INSERT and non-self-referencing update
Test BP1 getpage BP1 update BP7 getpage BP7 update
3.5.4 Conclusions
This enhancement is primarily functional. There may be some performance penalty for using
a self-referencing correlated subquery because of the two-step processing.
3.5.5 Recommendations
Use this feature where it is needed. Be aware of the cost of two-step processing when using a
correlated subquery, although this will probably still perform better than the equivalent
solution without a self-referencing update.
DB2 V7 has expanded the use of unions to anywhere that a subselect clause was valid in
previous versions of DB2. This enhancement extends compatibility with other members of the
DB2 UDB family and complies with the SQL99 standard.
Wherever a subselect was supported in DB2 V6, it can be replaced by a fullselect in DB2 V7.
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
V6
CREATE
CREATE v ie w - n a m e ,
V IE W
V IE W
S y n ta x ( c o lu m n -n a m e )
V7
CREATE A S s u b s e le c t
V IE W CASCADED
CHECK
S y n ta x W IT H
LO CAL O P T IO N
C R E A T E V IE W v ie w - n a m e ,
( c o lu m n - n a m e )
AS f u lls e le c t
CASCADED
W IT H C H E C K O P T IO N
LO CAL
V7: OK
V6: DSNT408I SQLCODE = -154, ERROR: THE STATEMENT IS INVALID BECAUSE THE VIEW OR
TABLE DEFINITION CONTAINS A UNION, A UNION ALL, OR A REMOTE OBJECT
V 6 ta b le - s p e c ta b le -s p e c
ta b le - n a m e
v ie w -n a m e c o r r e la t i o n - c l a u s e
t a b l e - lo c a t o r - r e f e r e n c e
( subs e le c t ) c o r r e la t i o n - c l a u s e
TABLE
V 7 ta b le - s p e c t a b l e - f u n c t i o n - r e fe r e n c e
jo in e d - ta b le
ta b le -s p e c
ta b le - n a m e
v ie w -n a m e c o r r e la tio n - c la u s e
t a b l e - lo c a t o r - r e f e r e n c e
( ) c o r r e la tio n - c la u s e
fu lls e le c t
T A B LE
t a b l e - f u n c t i o n - r e fe r e n c e
jo in e d - ta b le
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, ERROR: ILLEGAL USE OF KEYWORD UNION, TOKEN ) WAS
EXPECTED
,
( 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
expression IN (fullselect)
NOT ,
( expression )
,
( expression ) IN (fullselect)
NOT
IN predicate
ch an g ed fro m s u b s ele ct
E X IS T S p re d ica te
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
,
( column-spec )
LIKE table-name
view-name COLUMN ATTRIBUTES
INCLUDING IDENTITY
AS-(-fullselect-)-DEFINITION ONLY
AS-attribute
3.6.2 Optimization
DB2 uses two techniques to optimize access paths containing UNIONs. These are:
Distribution of predicates, joins, and aggregation.
Pruning of subqueries.
An example of using the first two of these operations is shown in Figure 3-37. The predicates
from the query WHERE clause are distributed to the WHERE clauses of the individual
subqueries. Then pruning removes the subquery with the predicate:
WHERE TOWN = 'MANCHESTER'
AND TOWN IN ('LONDON', 'LEEDS')
This is so, because the predicate will always evaluate to False. Any subselect where the
predicates, after predicate distribution, always evaluate to False will be removed by pruning.
The Explain output is shown in Figure 3-38. The first Explain example has the rows ordered in
the normal way, in ascending query block number. It is easier to see what is happening if we
re-sequence the rows as shown in the second Explain example, so that the parent query
block comes before its dependent query blocks.
When UNION optimization takes place, the QBLOCKNO values are not indicative of
dependencies between the query blocks. You must use the PARENT_QBLOCK (PQ) values
to identify dependencies between query blocks. In our example, both query block 1 and query
block 5 are children of query block 2. For a description of the headings used in the Explain
output, see Table 3-2 on page 27.
In this example, we can see the effect of pruning. There are only two component subqueries.
The Explain row with QBLOCK_TYPE (QBT) set to ‘SELECT’ does not represent any actual
work when the query executes. It is merely documentation showing that the two component
queries are combined with a UNION ALL.
For static SQL, the pruning shown here is performed at Bind time. 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. If host variables are used, then DB2 cannot determine at
Bind time that the combination of predicates will always evaluate to False.
Some pruning can be deferred until execution time if host variables are used. The pruning
takes place once the contents of the host variables are known. This will not show in the
Explain output.
Now let us look at a simpler example, shown in Figure 3-39, where no pruning takes place.
SELECT *
FROM CUST_X
ORDER BY CUST_NO
Now let us look at the distribution of joins and aggregations. Figure 3-40 shows a join using
the AVG function against the view containing UNIONs.
When the Explain rows are reordered, we can see that the join has been distributed to the
individual component subqueries. These are then written to a workfile and sorted for the
GROUP BY.
The TABLE_TYPE (TT) column can contain either ‘W’ or ‘Q’ when a temporary result table is
processed. 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. The value ‘Q’ indicates
that the result of the UNION or UNION ALL is fed directly to the parent Query Block without
materialization.
We cannot see how the AVG function is processed from the Explain, but the result of the
internal rewrite will be similar to that shown in Figure 3-41. 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 CUST_NO,
CASE WHEN SUM(CNT_X) = 0 THEN NULL
ELSE SUM(SUM_X)/SUM(CNT_X)
END
FROM ( SELECT C1.CUST_NO, SUM(O1.AMOUNT), COUNT(O1.AMOUNT)
FROM CUST C1 INNER JOIN ORD O1
ON C1.CUST_NO = O1.CUST_NO
WHERE C1.TOWN = 'MANCHESTER'
GROUP BY C1.CUST_NO
UNION ALL
SELECT C2.CUST_NO, SUM(O2.AMOUNT), COUNT(O2.AMOUNT)
FROM CUST C2 INNER JOIN ORD O2
ON C2.CUST_NO = O2.CUST_NO
WHERE C2.CRED_LIM > 1000
GROUP BY C2.CUST_NO
UNION ALL
SELECT C3.CUST_NO, SUM(O3.AMOUNT), COUNT(O3.AMOUNT)
FROM CUST C3 INNER JOIN ORD O3
ON C3.CUST_NO = O3.CUST_NO
WHERE C3.CUST_NAME LIKE 'S%'
GROUP BY C3.CUST_NO
) AS X (CUST_NO, SUM_X, CNT_X)
GROUP BY X.CUST_NO
ORDER BY X.CUST_NO
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’;
and so on ...
However, we will not get subquery pruning in this case. We know that the range of
ORD_DATE values in each table is limited, but the DB2 Optimizer does not know this.
In order to get subquery pruning, we must code redundant predicates in the view definition to
tell the Optimizer that the ORD_DATE values are limited for each table. If we change the view
definition as follows, then the SELECT statement can benefit from subquery pruning:
CREATE VIEW ALL_ORD (ORD_NO, CUST_NO, ORD_DATE, AMOUNT) AS
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’
...
With this revised view definition, the Optimizer can recognize that our SELECT statement
only needs to access the MONTH3 table. The subqueries that access each of the other tables
can be pruned, thus significantly improving performance.
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 parent QB references no other tables in the FROM clause after join distribution has
taken place. In other words, any joins must be distributed by the Optimizer.
The parent QB needs to perform a DB2 sort on the UNION ALL result table, for example,
because of a GROUP BY or ORDER BY.
There are no predicates to be applied to the UNION ALL result table. In other words, all
predicates must have been distributed.
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.
If all these conditions are met for a query, the APAR should improve performance. In the
Explain output you will see the TABLE_TYPE change from ‘W’ (workfile materialization) to ‘Q’
(queue without materialization). The query shown in Figure 3-40 on page 56 would meet the
criteria for improvement by the APAR.
3.6.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. The partitioned table had 10
partitions and contained 10 million rows. It had a partitioning index and one non-partitioning
index. The 10 small tables each contained 1 million rows and had two indexes.
The tests selected 10 million rows, 200000 rows and one row respectively from the large table
and from a view which is a UNION ALL of the ten small tables. The Class 2 elapsed and CPU
times in seconds for each test are shown in Table 3-13, Table 3-14, and Table 3-15.
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.
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.
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.
DECLARE cursor-name
INSENSITIVE SCROLL
New in V7 SENSITIVE STATIC
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.
FROM
cursor-name
single-fetch-clause
single-fetch-clause
,
INTO host-variable
USING DESCRIPTOR descriptor-name
FETCH
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.
Base Table
DB2 Table Result Table
DB2 Declared Temp Table
SCROLL
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.
...ABSOLUTE 4...
...RELATIVE -3...
...RELATIVE 3...
...AFTER...
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.
A test was run using each cursor in which the cursor was opened and all rows were fetched in
a forward direction. The getpage and update counts for each bufferpool as shown by the
accounting trace are shown in Table 3-16.
Table 3-16 Scroll versus normal cursor
Cursor type BP1 getpage BP7 getpage BP7 update BP8 getpage BP8 update
Normal 83 8 6 0 0
Scroll 83 8 6 7 165
The tests were run when the ORD table was entirely resident in the buffer pool, and therefore
there was no I/O to the table during any of the tests. The buffer pool for the DSNDB07 table
spaces was also large enough to avoid any I/O. In the normal cursor case, there was no read
or write I/O from any buffer pool. The buffer pool for the TEMP database was also large
enough to avoid read I/O, and in the scroll cursor test, there were just two synchronous write
I/Os and no read I/Os in the TEMP buffer pool. The BP8 getpages and updates reflect the
activity on the temporary tables.
The Class 2 and Class 3 times (in seconds) are shown in Table 3-17. These figures are not
from measurements in a fully controlled environment (DB2 was dedicated, not the hardware)
but they are indicative of relative cost.
Table 3-17 Accounting Class 2 and Class 3 times
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 commit processing is necessary because Undo log
records are created for DTTs to support rollback to a commit or a savepoint.
The locking impact is shown in Table 3-18. With the non-scroll cursor, there were these locks:
an S-Lock on the SKPT, an IS-Lock on the table space containing the ORD table, an S-Lock
on the work table space used by the sort, and an S-Lock on the DBD for DSNDB07.
Table 3-18 Locking with scroll cursors
Normal 4
Scroll 10
With the scroll cursor, there were six additional lock requests. These are DBD locks, pageset
locks and mass delete locks on the TEMP database and its table spaces. There had been no
recent updates to the ORD table, and so lock avoidance occurred on all data pages in both
the normal and scroll cursor cases.
Test BP0 getpage BP1 getpage BP7 getpage BP7 update BP8 getpage BP8 update
Scroll 0 83 8 6 7 165
Scroll 10
DTT 63
Explain
QB PN MT TABLE AT MC INDEX PF IXO PQ TT SORTN SORTC JT QBT
1 1 0 ORD_PART I 1 XOR2NO L N 0 T NNNN NNNN SELECT
1 2 3 0 N 0 -- NNNN NNYN SELECT
The second version of the program used an insensitive scrollable cursor and repositioned
using FETCH RELATIVE as shown in Figure 3-50.
Explain
QB PN MT TABLE AT MC INDEX PF IXO PQ TT SORTN SORTC JT QBT
1 1 0 ORD_PART R 0 S N 0 T NNNN NNNN SELECT
1 2 3 0 N 0 -- NNNN NNYN SELECT
The figures from the two tests are shown in Table 3-22 and Table 3-23. The index XOR2NO
was in BP2. The Class 2 and 3 times are in seconds.
Test BP1 getpage BP2 getpage BP7 getpage BP7 update BP8 getpage BP8 update
Close/open 1124 15 49 50 0 0
It can be seen that in our test the scrollable cursor performed significantly better than the
close and re-open approach. 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. The benefits will be
most apparent where a DB2 sort is invoked for the close and re-open.
Cursor type BP1 getpage BP7 getpage BP7 update BP8 getpage BP8 update
Insensitive 83 8 6 7 165
cursor
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. There
are 160 rows in the result set and therefore the test programs issued 160 FETCH statements
to read them, resulting in 160 extra getpages. 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. This extra work was reflected in the Class 2 and 3
times as shown in Table 3-25.
Table 3-25 Class 2 and 3 times for insensitive versus sensitive cursor
3.7.3 Conclusions
In general, trying to draw conclusions from small differences, it costs more to use a scrollable
cursor than a non-scrollable cursor. It also costs more to use a sensitive cursor than an
insensitive cursor, at least if you use FETCH SENSITIVE. The cost overheads are very
reasonable for the additional functionality.
3.7.4 Recommendations
There are costs associated with using scrollable cursors, so only use them when you need
the extra functionality. 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.
You wish to freeze the result set so that it is not changed by any updates made outside the
cursor.
Only use a sensitive scrollable cursor if you really need to pick up updates and deletes made
outside the cursor. As we have seen, there is significant cost resynchronizing with the base
table at each FETCH.
3.8.1 Description
There are many possible solutions to the problem of existence checking (checking whether
any row satisfies a specified condition). For dynamic SQL, when no supporting programming
language, such as COBOL, is available, one approach that is used is to use a SELECT
statement like that shown in Figure 3-51. 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. Handling the possible existence of multiple rows in the result
set creates unnecessary performance overhead.
Existence checking: Are there any ORD rows with AMOUNT > 1000?
SELECT 1
FROM ORD
WHERE AMOUNT > 1000;
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, OPEN the cursor, and FETCH the first row. If we code it as a singleton
SELECT, then we will get an SQLCODE -811 at execution time if more than one row satisfies
the predicate.
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. Figure 3-52 shows the
effect of adding FETCH FIRST 1 ROW ONLY on the access path. Both statements were
Explained under V7. Both use a tablespace scan to access the table, but when the FETCH
FIRST 1 ROW ONLY is added, DB2 no longer chooses sequential prefetch.
See also 7.1.3, “Singleton select” on page 155 for more details on the comparison.
SELECT 1
FROM ORD
WHERE AMOUNT > 1000
FETCH FIRST 1 ROW ONLY;
Then the statement will execute without error, returning a single row if there are any matching
rows and returning SQLCODE +100 if there are no matching rows.
3.8.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.
Figure 3-53 shows extracts from the SQL traces for both statements.
Without the FETCH FIRST, 32 rows were returned and 33 FETCHes executed, 32 to return
the rows and the last receiving SQLCODE +100. With FETCH FIRST 1 ROW ONLY added to
the SELECT, only one row was processed and two FETCHes were executed, the second
receiving SQLCODE +100. In these tests the getpage count for the tablespace was reduced
from 83 to 2 by adding the FETCH FIRST 1 ROW ONLY clause.
FETCH 16:31:24.65 0.000138 0.000136 STMT# 183 CURSOR: C1 SQLSTATE: 00000 SQLCODE: 0
--- 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
--- SCAN ACTIVITY ------------------------------------------------------------------------------------------------------------
------ROWS------ --QUALIFIED AT-- ----------ROWS----------- --MASS- --PAGES- ---------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
FETCH 16:31:24.66 0.000102 0.000100 STMT# 183 CURSOR: C1 SQLSTATE: 00000 SQLCODE: 0
FETCH 16:31:24.66 0.000056 0.000054 STMT# 183 CURSOR: C1 SQLSTATE: 00000 SQLCODE: 0
...
FETCH 16:39:57.54 0.000139 0.000138 STMT# 183 CURSOR: C1 SQLSTATE: 00000 SQLCODE: 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
--- SCAN ACTIVITY ------------------------------------------------------------------------------------------------------------
------ROWS------ --QUALIFIED AT-- ----------ROWS----------- --MASS- --PAGES- ---------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
FETCH 16:39:57.54 0.000045 0.000045 STMT# 183 CURSOR: C1 SQLSTATE: 02000 SQLCODE: 100
CLOSE 16:39:57.54 0.000012 0.000012 STMT# 197 CURSOR: C1 SQLSTATE: 00000 SQLCODE: 0
3.8.3 Conclusions
In a non-client/server environment, the use of FETCH FIRST n ROWS is probably limited.
However, 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.
3.8.4 Recommendations
Use for existence checking where appropriate to improve performance or to simplify code in
an application program.
3.9.1 Description
When a SELECT MIN(col) is coded and there is an ascending index on col, then DB2 can use
a one-fetch index access (ACCESSTYPE = I1) to retrieve the MIN value. Two examples of
this are shown in Figure 3-54.
The index XCUSTNO is an ascending index on the column CUST_NO. On the other hand, if a
SELECT MAX(col) is coded in DB2 V6, and if there is no descending index on col, only an
ascending index, then DB2 performs a non-matching index scan (ACCESSTYPE = I,
MATCHCOLS = 0) to locate the MAX value.
SELECT MIN(CUST_NO)
FROM CUST
WHERE CUST_NO > 10;
In V7, DB2 can use a new facility to read an index backwards. It can now use a one-fetch
index access on an ascending index to evaluate a MAX function, as shown in Figure 3-55.
Similarly, 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:
Version 7 Explain:
SELECT MAX(CUST_NO)
FROM CUST
WHERE CUST_NO < 1000;
Version 6 Explain:
Version 7 Explain:
3.9.2 Performance
The first MAX function shown in Figure 3-55 was tested. The Explain output was as shown.
The tests were run in an environment where the DB2 subsystem was dedicated to the tests,
but the OS/390 LPAR was not dedicated. As a result, elapsed and CPU times produced by
the tests could are only indicative of comparison. The ascending index XCUSTNO was
assigned to BP2 and was very small: 2 leaf pages and one root page. The results of the test
on V6 and V7 are shown in Table 3-26. The Class 2 times are in seconds.
Table 3-26 MAX test results
V6 0.037438 0.010332 3
V7 0.006577 0.001387 2
The test was run with all index pages in the buffer pool (BP2) and there was no Class 3 wait
time. The test probably represent the least performance benefit in percentage terms that is
likely to be achieved by the improved access path. With a larger index the performance
improvements should be greater.
3.9.3 Conclusions
It is no longer necessary to create a descending index to support a MAX function where an
ascending index already exists. It may be possible to drop some indexes that were created
explicitly for the purpose of supporting the MAX (or MIN) function.
3.9.4 Recommendations
Consider rebinding packages containing SELECT MAX(col) statements if there is an
ascending index on col, or SELECT MIN(col) statements if there is an descending index on
col. They may benefit from the improved access path.
Review whether any indexes created to support MAX or MIN processing can be dropped.
An example is shown in Figure 3-56. We have created an extra index on the CUST table, with
key columns CUST_NAME, TOWN, and CRED_LIM. Because of the predicate TOWN =
value in each of the queries shown, the column TOWN can be ignored in both the ORDER BY
clause and the index definition. DB2 treats the query as though it specified ORDER BY
CUST_NAME, CRED_LIM. It also treats the index XCNTC as though it were defined on the
columns (CUST_NAME, CRED_LIM). It therefore recognizes that the index can satisfy the
ORDER BY clause and no sort is required. It is, of course, necessary that the remaining
columns in the ORDER BY are in the same order as the remaining columns in the index
definition.
SELECT * SELECT *
FROM CUST FROM CUST
WHERE TOWN = 'MANCHESTER'
ORDER BY TOWN, CUST_NAME, CRED_LIM
or WHERE TOWN = :WK-TOWN
ORDER BY TOWN, CUST_NAME, CRED_LIM
; ;
Version 6 Explain:
Version 7 Explain:
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. 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.
It does not matter where in the ORDER BY column list or the index column order the
predicate column comes, DB2 can still avoid the sort. In our example, all the following
ORDER BY clauses could also be satisfied by the index XCNTC:
ORDER BY CUST_NAME, TOWN, CRED_LIM
ORDER BY CUST_NAME, CRED_LIM, TOWN
ORDER BY CUST_NAME, CRED_LIM
Figure 3-57 shows another example. This time it is a join of two tables and once again a sort
for the ORDER BY is avoided. The CUST column TOWN is in the index XCNTC but not in the
ORDER BY. It can be ignored because of the equal predicate on TOWN. The ORD column
AMOUNT is in the ORDER BY, but not in the index. It can also be ignored because of the
equal predicate on AMOUNT. Therefore, in V7, the CUST index XCNTC is used to establish
the correct order for the result rows via a non-matching index scan. The ORD rows are then
joined using a nested loop join.
SELECT *
FROM CUST C INNER JOIN ORD O
ON C.CUST_NO = O.CUST_NO
WHERE O.AMOUNT = 1000
AND C.TOWN = 'MANCHESTER'
ORDER BY AMOUNT, CUST_NAME, CRED_LIM;
Version 6 Explain:
Version 7 Explain:
DB2 will not always eliminate sorts for ORDER BY in the situations discussed above. It will
only eliminate a sort if that produces a lower cost access path. A sort is still required if the
ORDER BY applies to the result of a UNION.
3.10.2 Performance
These figures are not from measurements in a fully controlled environment (DB2 was
dedicated, not the hardware) but they are indicative of relative cost. The query shown in
Figure 3-56 on page 75 was run against a CUST table containing 10 rows. The results are
shown in Table 3-27. The extra getpages, updates and lock requests shown for V6 are due to
the use of a work table space in DSNDB07 by the DB2 sort.
Table 3-27 ORDER BY test results
V6 0.018109 0.017487 9 4 4
V7 0.001658 0.001330 3 0 2
3.10.4 Recommendations
Consider rebinding packages that might benefit from this enhancement. They will contain
SQL with ORDER BY clauses that could be satisfied by composite indexes in the way
described above.
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. In order for this to be true you must, in your
SQL, cast one column to the data type of the other.
3.11.1 Description
In Figure 3-58 we look at some examples. The CUST table is the same definition as we have
seen before. We have created a copy of the ORD table, called ORD_DEC, in which the only
difference is the definition of the CUST_NO column which is DECIMAL(15,0) instead of
INTEGER. XCUSTNO is an index on CUST(CUST_NO). Index XOCND is an index on
ORD_DEC(CUST_NO).
Table ORD_DEC:
Table CUST: CREATE TABLE ORD_DEC
CUST_NO INTEGER NOT NULL, (ORD_NO INTEGER NOT NULL,
CUST_NAME CHAR(20), CUST_NO DECIMAL(15,0),
TOWN CHAR(20), ORD_DATE DATE,
CRED_LIM DEC(7,2), AMOUNT DECIMAL(7,2),
SELECT * PRIMARY KEY (CUST_NO) PRIMARY KEY (ORD_NO))
FROM CUST C INNER JOIN ORD_DEC O
ON C.CUST_NO = O.CUST_NO
SELECT *
FROM CUST C INNER JOIN ORD_DEC O
ON C.CUST_NO = INTEGER(O.CUST_NO)
SELECT *
FROM CUST C INNER JOIN ORD_DEC O
ON DECIMAL(C.CUST_NO,15,0) = O.CUST_NO
The first example does not use a cast function and therefore the data type mismatch makes
the join predicate Stage 2. DB2 uses a tablespace scan for the inner table (ORD_DEC)
access despite the existence of an index on the ORD_DEC join column.
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. DB2 has changed
the order of table access. 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.
In the third example we have cast the CUST column CUST_NO in the join predicate to match
the data type (DECIMAL(15,0)) of the ORD_DEC table CUST_NO column. DB2 has made
ORD_DEC the inner table and used the index XOCND on ORD_DEC(CUST_NO) to access
the ORD_DEC table.
We can see from these examples that it makes a difference which side of the join predicate
we apply the cast function to. 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.
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.
If we use the alternative syntax to cast a column to the data type of the other column, we still
see the same effect. So, 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.CUST_NO = CAST(O.CUST_NO AS INTEGER)
In the third example we get the same Explain output if we specify the join predicate as:
ON CAST(C.CUST_NO AS DECIMAL(15,0)) = O.CUST_NO
If we cast to a decimal data type, we can make the precision different from the matching
column without loosing the Stage 1 benefit, but if we make the scale different then the
predicate remains Stage 2. In our example, the CUST_NO column in ORD_DEC is defined as
DECIMAL(15,0). The following join predicate, with a different precision in the cast, will use the
index on ORD_DEC(CUST_NO):
ON DECIMAL(C.CUST_NO,12,0) = O.CUST_NO
However, the next example, with a different scale, uses a tablespace scan:
ON DECIMAL(C.CUST_NO,15,1) = O.CUST_NO
The same need to cast exists if the join columns are INTEGER and SMALLINT respectively.
If we create a table ORD_SMINT, the same as ORD except that the CUST_NO column is
defined as SMALLINT instead of INTEGER, then we see the following, if O is the correlation
name of the ORD_SMINT table.
This predicate is Stage 2:
ON C.CUST_NO = O.CUST_NO
This predicate is Stage 1 and Indexable:
ON C.CUST_NO = INTEGER(O.CUST_NO)
This predicate is Stage 1 and Indexable:
ON SMALLINT(C.CUST_NO) = O.CUST_NO
3.11.3 Conclusions
This enhancement solves most of the problems of joining on columns with different
declarations. It will be necessary to recode joins to include the casting function in order to get
the performance benefits.
It is important to choose the correct join column to cast to the data type of the other. You need
to know what indexes are available on each of the columns and, if both columns are indexed,
you need to decide which index will give the best performance in the join.
3.11.4 Recommendations
It will be worth identifying joins that can take advantage of this enhancement and recoding
them. 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. 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.
Let us use a variant of our CUST table, called CUST_VAR, in which the two CHAR columns
are defined as VARCHAR. Let us also create an index on those columns and one other:
CREATE TABLE CUST_VAR
(CUST_NO INTEGER NOT NULL,
CUST_NAME VARCHAR(20),
TOWN VARCHAR(20),
CRED_LIM DEC(7,2))
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 PN MT TABLE AT MC INDEX PF IXO SORTN SORTC
1 1 0 CUST_VAR I 1 XVTNC L N NNNN 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 PN MT TABLE AT MC INDEX PF IXO SORTN SORTC
1 1 0 CUST_VAR I 1 XVTNC Y NNNN NNNN
3.12.1 Description
The enhancement in V7 concerns the case when a VARCHAR index key column is specified
in the WHERE clause, but only non-VARCHAR columns from the index are specified in the
select list. We can see such a case in Figure 3-60. The VARCHAR column TOWN is specified
in the WHERE clause, as before, but the only column in the select list is the DECIMAL column
CRED_LIM, which is also part of the index XVTNC.
SELECT CRED_LIM
FROM CUST_VAR
WHERE TOWN = 'MANCHESTER';
In V7, you do not need to set RETVLCFK=YES to get index-only access in this special case.
As can be seen in the example, 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.12.2 Performance
The SQL shown in Figure 3-60 on page 80 was tested in V6 and V7 with RETVLCFK=NO.
These figures are not from measurements in a fully controlled environment (DB2 was
dedicated, not the hardware) but they are indicative of relative cost. The tablespace was
allocated to BP1 and the index to BP2. The resulting getpage counts for the two tests are
shown in Table 3-29. In V7 we have avoided the 16 data getpages that were required in V6.
Table 3-29 VARCHAR index-only test results
Test BP1 getpages BP2 getpages
V6 16 2
V7 0 2
3.12.3 Conclusions
This enhancement can be of benefit for installations that have VARCHAR columns in indexes.
3.12.4 Recommendations
For those installations that avoid the use of VARCHAR columns in indexes, there is now
slightly less reason for doing so. If you have VARCHAR columns in indexes consider
rebinding those packages that may be able to exploit the index-only access.
3.13.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. This
enhancement is also extended to outer joins by APAR PQ48306. The two-pass approach
consumes much less RDS subpool storage than V6 for these multi-table joins. It also reduces
CPU cost. CPU cost is also reduced in V7 by using a more efficient search to locate cost
entries.
CPU reduction is only applicable for complex joins of 10 or more tables. The tests showed a
CPU reduction of 19% for a 15-table join and 70% for a 19-table join.
Another set of measurements, after applying the fix for PQ48306, with two different BI and
CRM workloads, 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.
3.13.3 Conclusions
This enhancement and the follow-up APAR are of great interest for DB2 environments running
complex BI and CRM type applications. These sites tend to use dynamic SQL and perform
joins of large numbers of tables. For such sites, 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.13.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.
In DB2 DB2 V7, the parameter that enables or disables this feature is changed from a hidden
to an externalized keyword. Also, the default value for the parameter is DISABLE, whereas it
was ENABLE in V6.
When you want to specify a value deviating from default, 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. The parameter cannot be
set through the install panels. Acceptable values are ENABLE, DISABLE or 1-32768. See
Figure 3-61 for a description.
Star join support for DB2 V6 was delivered by the fixes to APARs PQ28813 and PQ36206.
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, if possible, using the next key feedback feature
With this implementation, a star schema query that contains large number of dimension
tables is able to be bound without SQL code -101 or -129. The execution time has also been
largely cut for some queries with star schema. However, 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.
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.
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. With this new threshold, potential performance
degradation can be prevented for relatively small OLTP type queries that are qualified as
the star schema.
Consequently, 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").
A partial star join plan (not all the dimension tables are "star joined"). The residual
dimension tables are joined after the fact table using the regular join methods. The join
order of the residual dimension tables are determined by heuristic rules.
Not a star join plan at all. If Explain is run for the query, the join_type column of the
plan_table will not contain 'S' in such a case.
Users should note that the new implementation could generate different access plans,
depending on the value of the CURRENT DEGREE special register.
For example, 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, D2, D3, D4 (this
example is for illustration purpose only -- 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, all dimension tables and the fact tables are "star joined". The
first column represents the tables in the join order; the second column is the join_type.
Table 3-30 Star join access plan: case 1
D1 ‘S’
D2 ‘S’
D3 ‘S’
D4 ‘S’
F ‘S’
Possible case 2: In Table 3-31, some dimension tables and the fact tables are "star joined"
(a partial star join case). The rest of the dimension tables are joined after the fact table using
regular join methods (the order is determined by heuristic rules).
Table 3-31 Star join access plan: case 2
D1 ‘S’
D2 ‘S’
F ‘’
D4 ‘’
D3 ‘’
D2 ‘’
F ‘’
D4 ‘’
D3 ‘’
Note: The star join activation is based on a threshold represented by the number of tables in
a query block.
A new ZPARM will be defined through an APAR so that the users can change the value (the
default is 10). This ZPARM is in effect only when the star join is enabled by the already
existing ZPARM STARJOIN.
When the space in a table space is not preformatted by LOAD or REORG, performance is
impacted when insert processing is touching the limit of the preformatted area and
synchronous preformatting need to be done. See Figure 4-1.
This typically takes 0.2 to 1 second, and during this time period, insert processing is held up.
Preformat will format 2 cylinders at a time on a 3390 device unless the allocated space is
smaller then a cylinder; then only 2 tracks will be formatted.
DB2 V7 brings relief for this issue with the asynchronous preformat functionality.
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
Disk space needs to be preformatted before a row/key can be inserted. First, preformatting is
done at table space/index/partition create time.
Insert activity will use the formatted space in a table space/index/partition pageset until a
threshold is reached. Hitting this threshold triggers a preformat service task. DB2 supports up
to 20 preformat/extend service tasks to perform preformat/extend processing in parallel. Only
one preformat/extend service task can be active on a given table space/index/partition
pageset at one time.
Measurement environment
Two test scenarios were executed:
CPU bound test case — sequential insert of 8 million rows, 200 bytes per row
I/O bound test case — sequential insert of 2 million rows, 800 bytes per row
For this measurement, 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
500
Elapsed time in seconds
400 Unaccounted
-38% EXT/FMT/DEL
300 TS or log writes
lock/latch suspension
200 CPU time
100
0
V7 V6
-19%
250
Unaccounted
200 EXT/FMT/DEL
TS or log writes
150 lock/latch suspension
CPU
100
50
0
V7 V7 V6
after reorg
preformat
The test results, after a Reorg with preformat was executed on the table space, represent the
optimal performance attainable if asynchronous preformat was 100% concurrent with other
processes.
In this test case, insert reaches the preformat threshold; the preformat service task is then
triggered, and preformat I/Os are done. In the meantime, the insert job could concurrently
insert into the available already formatted storage. After some time, data buffers are filled and
deferred writes are scheduled once the VDWQ threshold is reached.
DB2 may then schedule a deferred write I/O concurrently with a preformat service task for the
same table space/index. In this case, 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. On top of this deferred write, task(s) will compete for
the same I/O resources (UCB,...) as the preformat service task. In this situation, if possible, it
is better to use LOAD/REORG preformat prior to execution of the sequential inserts.
The ESS Parallel Access Volumes feature can bring some relief for this situation. See
Chapter 10, “Synergy with host platform” on page 197, for a description of ESS from a DB2
point of view.
Before DB2 V5, there was only a single task to perform open/close processing of DB2
database data sets. DB2 V5 10 parallel tasks for open/close processing and this number was
increased to 20 in DB2 V6. 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. 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.
4.04
4
Elapsed time in seconds
3
V6
1.85 V7
2
0
Figure 4-4 Parallel data set open performance
Even though you are not planning to use new DB2 V7 functions, before you start migrating
you must be aware of changes that might affect your migration. You must consult the current
standard documentation for details. A starting point for your evaluation is the DB2 UDB for
OS/390 and z/OS Version 7 Installation Guide, GC26-9936, specifically the two chapters on
migration from V6 and V5. You must also check with the IBM support organization regarding
the correct maintenance levels on both starting and target systems.
The first step of DSNTIJTC creates new catalog and directory objects, adds columns to
existing catalog tables and creates and updates indexes on the catalog tables to
accommodate new Version 7 objects. All IBM-supplied indexes are created or updated
sequentially during the execution of DSNTIJTC.
The second step of DSNTIJTC searches for the unsupported objects to display the warning
messages. The third step does the stored procedure migration processing and is only for
migration from V5.
A new status message, DSNU777I, is issued at several points during the migration process to
indicate migration progress. New diagnostic error messages are issued when CATMAINT
processing fails. If a problem is found during the SQL processing phase of migration, then
message DSNU778I is issued. If non-supported functions such as type 1 indexes are
encountered, then message DSNU776I is issued. All of these messages are written to the
SYSPRINT data set. If job DSNTIJTC fails, because CATMAINT failures roll back all Version 7
changes, the catalog and directory are in Version 6 format. Altered indexes are not rolled
back and need to be verified with the CHECK INDEX utility.
Non-data-sharing group
V6 -> V7 82 6 76,889 24
Data-sharing group
V6 -> V7 74 6 76,571 32
600 600
400 400
200 200
82
0 0
Note: Make sure that APARs PQ38035 and PQ44985 are applied to your system. With
PQ38035 CATMAINT no longer fails when an unsupported object is found. PQ44985
solves a performance problem with CREATE/DROP/ALTER of table spaces, tables and
indexes related to declared temporary tables.
600 600
400 400
200 200
74
0 0
4.5.1 Description
Specify whether predicate evaluation can occur on uncommitted data of other transactions.
The option applies only to stage 1 predicate processing that uses table access (table space
scan, index-to-data access, and RID list processing) for queries with isolation level RS or CS.
Although the option influences whether predicate evaluation can occur on uncommitted data,
it does not influence whether uncommitted data is returned to an application. Queries with
isolation level RS or CS will return only committed data.They will never return the
uncommitted data of other transactions, even if predicate evaluation occurs on such. If data
satisfies the predicate during evaluation, the data is locked as needed, and the predicate is
re-evaluated as needed before the data is returned to the application.
If you specify NO, the default, predicate evaluation occurs only on committed data (or on the
application’s own uncommitted changes). NO ensures that all qualifying data is always
included in the answer set.
If you specify YES, predicate evaluation can occur on uncommitted data of other transactions.
With YES, data can be excluded from the answer set. Data that does not satisfy the predicate
during evaluation — but then, because of undo processing (ROLLBACK or statement failure),
reverts to a state that does satisfy the predicate — is excluded from the answer set. A value of
YES enables DB2 to take fewer locks during query processing. 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.5.2 Recommendation
Specify YES to improve concurrency, if your applications can tolerate returned data, to falsely
exclude any data that would be included as the result of undo processing (ROLLBACK or
statement failure).
In DB2 V7 the HPGRBRBA value is updated every nth checkpoint, where n is controlled by
the value of the DSNZPARM parameter DLDFREQ.
In DB2 V7, the data logged starts at the first byte of the first changed column to the last byte
of the last changed column.
Restrictions
The update does not change the row length.
No hardware compression is done, and no editprocs are used.
For a complete listing of the updatable parameters, refer to Appendix A, “Updatable DB2
subsystem parameters” on page 211.
For most parameters, the online change is transparent, with the change taking effect
immediately. There are several parameters for which this is not the case, because of the type
of functions that they impact. 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.
Message DSNZ014I is generated if the value for an unchangeable parameter differs from the
startup value:
If the EDM pool is 10M and the request is to increase it to 12M, then it is increased to 15M:
Changing the DSNZPARM parameters back to their start-up value also set the EDM pool
back to its initial value:
DB2 V7 introduces further enhancements on this issue. The -RECOVER POSTPONED CANCEL
command allows you to cancel postponed units of recovery. Impacted page sets/partitions
are marked Refresh Pending (REFP) and LPL. In order to make the units of recovery aware
of the REFP status, LPL was added.
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. See Figure 5-2.
A new diagnostic log record is added that can log successful START DATABASE
ACCESS(FORCE) commands. The DBID/OBID/PART is logged, as well as the database and
page set name. The log record will be of type DIAGNOSTIC subtype name START
DATABASE FORCE. See Figure 5-3.
All customers will benefit from this enhancement, particularly large sites where significant
space needs to be allocated for large workdays, and/or large query sorting, and/or 24x7
applications. You will also be able to better manage your workfile space, by changing the
workfile allocations more frequently. This enhancement reduces performance problems and
improves availability in a 24x7 environment, because changing workfile space allocation is
much less disruptive.
In a non-data sharing environment, a U lock is taken on the workfile DBD. Therefore while you
are creating or dropping a workfile table space, other DB2 agents are able to continue to use
other table spaces in the workfile database.
However, in a data sharing environment, 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. Otherwise, an X lock is taken on the DBD. Therefore, 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. Otherwise, DB2 will not allow concurrent
access to the other workfile table spaces in the database being modified.
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. In addition to
holding up normal activity, 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.
You can compare the restart process following a restore of the copy with the restart
process after a system crash.
Depending on the activity, the RVA/ESS will require more space until the copy offload
process completes.
You can display the current CHKTIME value as well as current log information using the
-DISPLAY LOG command.
Note:
Remember, the higher the values for LOGLOAD or CHKTIME, the longer it takes for DB2 to restart.
Avoid using the time interval controlled checkpoint frequency while it can influence a DB2
consistent restart time. As you know, 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.
When DB2 is restarted, it again picks up the value for the LOGLOAD parameter from your
DSNZPARM start up module.
A new warning message is issued when a unit of recovery has written a predefined number of
log records without committing. Every time the threshold is reached, message DSNJ031I is
generated. 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.
The value of this threshold is specified in the parameter URLGWTH (UR log record written
threshold) of the DSNZPARM. The value of this parameter can be modified using the -SET
SYSPARM command
Any syntax error in issuing the command will receive DXR106E. Syntax errors include
TIMEOUT value out-of-range or invalid identified subsystem name. A syntax error message
will also be given if the DXR177I message has not been received for the prior command
completion.
The TIMEOUT value must be a multiple of the local deadlock parameter. If the value entered
is not an even multiple of the deadlock parameter, IRLM will increase the timeout value to the
next highest multiple.
The value used by IRLM for timeout will be displayed in the DXR177I message which is
issued during deadlock processing. This new value is used until the IRLM or identified
subsystem is terminated, or the timeout is change again by the operator. The value specified
on the command does NOT affect the timeout value in the DB2ZPARM.
Example
Enter the command on an MVS console:
/F DB2GIRLM,SET,TIMEOUT=65,DB2G
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.
This enhancement provides the ability to specify a value in milliseconds for the IRLMPROC
DEADLOK parameter for the local deadlock frequency. You can also dynamically change the
deadlock frequency with the new command:
MODIFY irlmproc,SET,DEADLOCK=nnnn
In this command, the value for nnnn ranges from 100 to 5000 msec.
DSNTIPJ, the install panel for IRLM, is modified in accordance with the new allowed values.
Measurements
The IRWW workload was used to evaluate the impact of the subsecond value for DEADLOK.
Two measurements were collected, one with DEADLOK=1000 (the current lower limit), and
one with DEADLOK=100 (the new lower limit after applying the fix). The results are
summarized in Table 5-1 and show no appreciable impact.
Table 5-1 Subsecond deadlock detection impact
Measurement value DEADLOK=1000 DEADLOK=100 Delta %
For more information on DB2 utilities, you can refer to the upcoming redbook DB2 for z/OS
and OS/390 Version 7 Using the Utilities Suite, SG24-6289, planned to be available by
3Q2001.
As new objects are constantly created, others are deleted, and since the sizes of most
objects vary over time, 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. Development and maintenance of jobs has
become easier. Also, as changes are reflected automatically, less user activity is required,
and thus the possibility for errors is reduced. As a consequence, the total cost of operations
can be minimized.
6.1.1 LISTDEF
LISTDEF is used to define dynamic list of DB2 objects, namely table spaces, index spaces or
their partitions. The defined list can be used in one or more utilities in the job step. The
defined list can be any combination of including or excluding specific names, name patterns
and even other lists. 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.
Figure 6-1 shows the differences in JCL using LISTDEFs. For more information about
LISTDEF. See DB2 UDB for OS/390 and z/OS Utility Guide and Reference, SC26-9945.
D a ta b a s e D B X D a ta b a s e D B Y
RI RI RI
TS0 PTS1 TS2 TS3 TS4
//SYSIN DD *
V6 RECOVER TABLESPACE DBX.PTS1
TABLESPACE DBX.TS2
TABLESPACE DBY.TS3
TABLESPACE DBY.TS4
TOLOGPOINT X'xxxxxxxxxxxx'
/*
//SYSIN DD *
V7 LISTDEF RECLIST INCLUDE TABLESPACE DBY.T* RI
RECOVER LIST RECLIST
TOLOGPOINT X'xxxxxxxxxxxx'
/*
Figure 6-1 Sample JCL from DB2 V6 and DB2 V7 using LISTDEF
You can see the number of objects included in a list and the number of the current active
objects.
6.1.2 TEMPLATE
With TEMPLATE you can define a dynamic list of data set allocations. You can create a
skeleton or a pattern for the names of the data sets to allocate. The list of these data sets to
allocate is dynamic. This list is generated each time the template is used by an executing
utility. Therefore a template automatically reflects the data set allocations currently needed.
Figure 6-3 shows the differences in JCL using templates. For more information. See DB2
UDB for OS/390 and z/OS Utility Guide and Reference, SC26-9945.
//COPYPRI1 DD DSN=DBX.PTS1.P00001.P.D2000166,
V6 // DISP=...,UNIT=...,SPACE=...
//COPYPRI2 DD DSN=DBX.PTS1.P00002.P.D2000166,
// DISP=...,UNIT=...,SPACE=...
//COPYPRI3 DD DSN=DBX.PTS1.P00003.P.D2000166,
// DISP=...,UNIT=...,SPACE=...
//COPYSEC1 DD DSN=DBX.PTS1.P00001.B.D2000166,
// DISP=...,UNIT=...,SPACE=...
//COPYSEC2 DD DSN=DBX.PTS1.P00002.B.D2000166,
// DISP=...,UNIT=...,SPACE=...
//COPYSEC3 DD DSN=DBX.PTS1.P00003.B.D2000166,
// DISP=...,UNIT=...,SPACE=...
//SYSIN DD *
COPY TABLESPACE DBX.PTS1 DSNUM 1 COPYDDN (COPYPRI1,COPYSEC1)
COPY TABLESPACE DBX.PTS1 DSNUM 2 COPYDDN (COPYPRI2,COPYSEC2)
COPY TABLESPACE DBX.PTS1 DSNUM 3 COPYDDN (COPYPRI3,COPYSEC3)
/*
Figure 6-3 Sample JCL from DB2 V6 and DB2 V7 using TEMPLATE
The PREVIEW option will parse all utility control statements for syntax errors but normal utility
execution will not take place. If syntax is valid, all LISTDEF lists and TEMPLATE DSNAMEs
which appear in SYSIN will be expanded. See Figure 6-4.
If you have added or changed your LISTDEF or TEMPLATE statements, we recommend that
you use the PREVIEW option before running utilities.
For more information about OPTIONS. See DB2 UDB for OS/390 and z/OS Utility Guide and
Reference, SC26-9945.
Verify that the PTF for APAR PQ45268 (open at the time of writing) is applied.
Restart from the last commit point (RESTART or RESTART(CURRENT)) and restart from the
beginning of the current phase (RESTART(PHASE)) are supported. However, current utility
specific restart restrictions apply. For example, the COPY utility cannot be restarted with
RESTART(PHASE).
There are obvious benefits obtained from using LISTDEF to ensure that utilities run against
all old and future new DB2 objects, as well as the time that you save to maintain utility jobs.
It is recommended that you use LISTDEF for specifying the DB2 objects that you want to
include in your utility jobs.
To get most benefit out of using LISTDEF, it is necessary that you have a good naming
convention for your DB2 objects, so the pattern you have specified for your DB2 objects will
cover future new objects too.
The performance degradation of using TEMPLATE on simple table spaces is less than 7% in
elapsed time, so the performance overhead must be considered negligible when compared
with the benefit you get out of using TEMPLATE. You no longer need to change space
allocation of data sets used for utilities, and the problems with running out of space (abend
D37) during utilities are eliminated. However, you must ensure that you have enough free
space available to allocate the data sets needed for the execution of the utilities.
SYS R ELO AD
R EC 1 Part 1 SYS SO RT S O RT B UILD PI
U T1 O UT Part 1
Error/M ap key/R ID pairs
SO R TW K nn
B
U
IL
D
ke y/RID pa irs PI
Error/Map SYS SO R T SO R T BUILD
U T1 OUT Part 2
SYS
R EC 2
R ELOAD Part 2 S O R TW K nn BU
ILD
N P I1
IL D
BU
N P I2
S YS
REC3
R ELO AD Part 3 SYS SO R T S O RT BUILD PI
UT 1 O UT Part 3
Error/M ap key/R ID pairs I LD
S O RT W K nn U
B
ke y/RID pa irs
SYS SO RT S O RT B UILD PI
Error/Map
U T1 O UT Part 4
SYS
R EC 4
R ELO AD Part 4 SO R TW K nn
To avoid the contention problem, you have to drop all the NPIs, and after running the LOAD
utility, you have to recreate and REBUILD all the NPIs again.
You can now LOAD data into a partition table in parallel without building indexes in parallel.
See Figure 6-6.
S YS R ELOAD
R EC 1 P art 1
PI
BUILD
D
S YS
IL
R E LOAD P art 2
BU
R EC 2
BUILD
S YS
R E C3
R ELOAD Part 3 S OR T W K n n
N PI2
S YS
RE C4
R E LOAD P art 4
Indexes will not be built in parallel when loading data into a partition table, if any one of the
following conditions is true:
There is only one index to be built.
In the LOAD job, the keyword SORTKEYS is not specified.
In the LOAD job, the keyword SORTKEYS is specified with an estimated value of 0.
The default estimated value for SORTKEYS is 0.
For loading partitions in parallel, the optimal approach would be to start one subtask for each
partition to be loaded. However, it might not be possible to start the optimal number of
subtasks. This constraint could arise from lack of sufficient virtual memory, insufficient
available DB2 threads, or insufficient processors (CPUs) to handle more tasks. If fewer
subtasks are started than there are partitions to be loaded, one or more subtasks will load
more than one partition. When a subtask finishes with loading a partition, if there are any
partitions not yet being loaded, DB2 will start the next available partition.
We recommend that you check the value of IDBACK and CTHREAD in ZPARM, so you can
start the necessary number of subtasks.
Restriction: In a data sharing group, if the utility is running on a member other than the one
to which the DISPLAY UTILITY() command is directed, the status represents the status of the
utility at its last checkpoint. In addition, the DSNU111I messages will not be issued.
You can find information about how many subtasks the utility has started by looking at the
SYSPRINT output from the LOAD utility, where you will find the following messages:
When loading data into a partition table, you can benefit from running the LOAD utility in
parallel, and you only have to run and maintain one job, instead of running and maintaining
multiple jobs.
E rro r/M a p
SYS R EL O AD
REC1 P art 1
SORT S ORTBLD PI
SW 01W Knn
S W 0 1 W K xx
B U IL D
SYS R E L O AD
REC2 Pa rt 2
SO RT SOR TBLD
SW 02W Knn
S W 0 2 W K xx N P I1
B U IL D
S YS R EL O AD
REC3
P a rt 3
SYS
REC4
R E L O AD P art 4
The LOAD utility builds indexes in parallel, if all of the following conditions are true:
There is more than one index to be built.
In the LOAD job, the keyword SORTKEYS is specified, with a non-zero estimate of the
number of keys.
You either allow the utility to dynamically allocate the data sets needed by SORT, or
provide the necessary data sets yourself.
For loading partition in parallel, the optimal approach would be to start one subtask for each
partition to be loaded and two for each index to built; one subtask to sort extracted keys while
the other subtask builds the index. However, it might not be possible to start the optimal
number of subtasks. This constraint could arise from lack of sufficient virtual memory,
insufficient available DB2 threads, or insufficient processors (CPUs) to handle more tasks. If
fewer subtasks are started than there are partitions to be loaded, one or more subtasks will
load more than one partition. When a subtask finishes with loading a partition, if there are any
partitions not yet being loaded, DB2 will start the next available partition.
We recommend that you check the value of IDBACK and CTHREAD in ZPARM, so you can
start the necessary number of subtasks.
When loading data into a partition table, you can benefit from running the LOAD utility in
parallel and by building the indexes in parallel. You only have to run and maintain one job,
instead of running and maintaining multiple jobs and you do not have to drop and recreate
NPIs to avoid contention problems.
Note: Without SORTKEYS, this means that the keyword SORTKEYS was not specified or
SORTKEYS was specified with an estimated value of zero. With SORTKEYS, this means that
the keyword SORTKEYS was specified with an estimated value greater than zero.
When loading partitions in parallel without building NPIs in parallel (without specifying
SORTKEYS), if there is only one index, the CPU time degrades up to 22.7% and the elapsed
time improves up to 32.5%. When there are more than one index on a partition table, the CPU
overhead is lower, even though managing the parallel subtasks for loading partitions in
parallel contributes to an increase in CPU time.
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 LOAD table with 20 jobs Parallel LOAD partition
in parallel
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.
LOAD whole table with LOAD table with 20 jobs Parallel LOAD parallel
SORTKEYS in parallel with with SORTKEYS
SORTKEYS
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.
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.
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.
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.
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 10 jobs inserting
2,000,000 rows 2,000,000 rows
in parallel in parallel Delta %
BP3=5,000 pages BP3=40,000 pages
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 Parallel partition
Online LOAD Online LOAD
RESUME into RESUME into Delta %
10 partitions 10 partitions
BP3=5,000 pages BP3=40,000 pages
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%.
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.
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.
single
data set data set
Partition parallelism
for part1
data set
for part2
Note: All measurements were performed using an IBM G5 3-way processor and with 4
channels on ESS.
20
15
Reorg
Unload
10
0
CHAR DEC INT
The improvement shows a 15% to 18% reduction of the CPU time. Because the UNLOAD
utility is I/O bound, there was no reduction of the elapsed time.
Performance measurements
Figure 6-11 shows the performance measurements of unloading partitions in parallelism. The
following table is used during the tests:
6 million rows per partitions
Table with 16 columns per row
0.82 GB per partition and 1.03 GB when unloaded
The difference between the size of the partition and the unloaded data set is due to
VARCHAR columns.
Note: All measurements are performed using an IBM 7-way G6 processor, and this requires
at least 2 channels per CPU to avoid channel contention.
200 191
150
100 86 86 89
50
0
1 4 7 14
Number of partitions
The elapsed time for unloading 1 to 4 partitions is the same. There is no extra cost in elapsed
time for unloading the 3 extra partitions.
The elapsed time only increase a little bit, when unloading 7 partitions in parallel. The
increase in elapsed time is due to handling more subtasks and partitions. The elapsed time
for unloading 1 or 7 partitions in parallel is almost the same.
The elapsed time for unloading 14 partitions in parallel shows that the elapsed time is more
than double, because the UNLOAD utility could only start 7 subtasks, which have to unload
more than one partition each and the overhead to handle more partitions than subtasks
increased too.
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.
We recommend that you check the value of IDBACK and CTHREAD in ZPARM.
You can find information about how many subtasks the utility has started by looking at the
SYSPRINT output from the UNLOAD utility, where you will find the following messages:
When you UNLOAD data from a partitioned table, you can benefit from running the UNLOAD
utility in parallel. Thus you only have to run and maintain one job, instead of running and
maintaining many jobs.
In the output from the UNLOAD utility, you can see that parallelism is not activated when you
unload data from an image copy data set.
When running the Online REORG TABLESPACE utility, data is unavailable from the last part
of the LOG phase and during the SWITCH and BUILD2 phases. See Figure 6-13.
U n lo a d R e lo a d S o rt B u ild U nLl o g
ad S w itc h B u ild
2
With a faster SWITCH phase and a new BUILD2 phase for building NPI in parallel, the time
when data is unavailable during Online REORG TABLESPACE utility has been minimized.
In the UTILINIT phase, shadow objects of the table space (or its partitions) and for the index
spaces (or their partitions) are created. Strictly speaking, this is not true, as these shadow
objects are not reflected in the catalog. What it means is, that new shadow data sets are
created, one for each data set of the original objects (or their partitions). The data set names
of these shadow data sets differ from the original data set names insofar as their fifth qualifier,
also referred to as the instance node, is S0001’ rather than ‘I0001’.
In the SWITCH phase, DB2 renames the original data sets and the shadow data sets. More
specifically, the instance node of the original data sets, ‘I0001’ is renamed to a temporary
one, ‘T0001’; afterwards, the fifth qualifier of the shadow data set, ‘S0001’, is renamed to
‘I0001’.
In the UTILTERM phase, the data sets with ‘T0001’ are deleted, as they are not needed any
more.
Notes:
This description applies to DB2-managed table spaces.
During the last log iteration and during the BUILD2 phase, SQL accesses are also limited.
Some applications design DB2 tables with several hundred indexes. Others use partitioned
table spaces with some hundred partitions. In both cases, several hundred data sets (both
cluster and data component of the VSAM data set) must be renamed in the SWITCH phase.
For the renaming, DB2 invokes Access Method Services (AMS). In turn, AMS invokes MVS
supervisor calls (SVCs) which result in further cascading SVCs, for example, for checking
whether the new name exists already, and whether the rename was successful.
DB2 V7 gives an alternative to speed up the SWITCH phase, thus making the phase less
intrusive to data access by others:
Invocation of AMS to rename the data sets is eliminated.
An optional process, the FASTSWITCH, takes place:
a. In the UTILINIT phase, DB2 creates shadow data sets. The fifth qualifier of these data
sets is now ‘J0001’.
b. In 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. During that time, applications cannot access the table space.
c. After the SWITCH phase, the applications can resume their processing, now on the
new ‘J0001’ data sets.
d. In the UTILTERM phase, DB2 deletes the obsolete original data sets with the instance
node ‘I0001’.
Notes:
This description applies to DB2-managed table spaces. 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.
As a result, the SWITCH phase is much shorter; therefore, the applications are less likely to
time out.
As the data set names of a table space now vary, DB2 queries the OBD of the object being
reorganized in the UTILINT phase in order to check, whether the current instance node is
‘I0001’ or ‘J0001’. If the current data base object has a ‘J0001’ instance node then DB2 will
create a shadow object with an ‘I0001’ instance node. Thus, during the SWITCH phase, the
OBD and the DB2 catalog are updated registering the ‘I0001’ object as the active data base
object. The UTILTERM phase then deletes the data base objects with the ‘J0001’ instance
node, the old originals.
Notes: You can only use FASTSWITCH NO for DB2 catalog and directory.
Performance measurements
All measurements were performed using an IBM G6 3-way processor and ESS disks. The
following table space is used:
254 partitions table space STOGROUP defined
1 partition index
There is a 92% reduction in elapsed time and no change in the CPU time by using the new
FASTSWITCH functionality. The elapsed time for switching a data set is very constant, and it
is about 0.05 seconds. In this test case, the total number of data sets switched was 508 (254
table space partitions and 254 index partitions), and that was done in 28 seconds.
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.
The BUILD2 phase has been improved by updating of NPIs using parallel subtasks. That
gives you availability improvement and better performance in reducing elapsed time.
Optimally, if you have one subtask for each NPI, the elapsed time of the BUILD2 phase could
be the time it takes to process the NPI with the most RIDs. It might not be possible to start the
optimal number of subtasks. This constraint could arise from lack of sufficient virtual memory,
insufficient available DB2 threads, or insufficient processors (CPUs) to handle more tasks. If
fewer subtasks are started than there are NPIs to update, one or more subtasks will update
more than one NPI. When a subtask finishes with a NPI, if there are any NPIs not yet being
updated, it will start the next available NPI.
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. In this worst case scenario, the
BUILD2 phase shows an improvement in elapsed time of 35% in elapsed time with an
improvement in CPU time of 29%. This improvement, obtained when there is no multitasking
of NPIs, is due to other internal enhancements in the handling of log writes.
Table 6-10 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility
using SHRLEVEL CHANGE, SORTKEYS, NOSYSREC and inline COPY with the DB2 V7
REORG utility.
Table 6-10 BUILD2 — example 2
Running REORG against a range of partitions (in this case, three partitions) of a partition
table space with only one NPI, shows the improvement of the BUILD2 phase in a worst case
scenario. In this worst case scenario, the BUILD2 phase shows an improvement in elapsed
time of 36%, and the CPU time is improved by 33%.
Table 6-12 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility
using SHRLEVEL CHANGE, SORTKEYS, NOSYSREC, and inline COPY with the DB2 V7
REORG utility, when reorganizing the first 3 partitions.
Table 6-12 BUILD2 — example 4
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. In
this worst-case scenario, the BUILD2 phase shows an improvement in elapsed time of 37%,
and in CPU time of 34%.
The BUILD2 phase in DB2 V7 improves the elapsed time by 82% and the CPU time by 25%.
Managing the parallel subtasks for building the five NPIs has reduced the improvement in
CPU time.
Table 6-14 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility
using SHRLEVEL CHANGE, SORTKEYS, NOSYSREC, and inline COPY with the DB2 V7
REORG utility.
Table 6-14 BUILD2 — example 6
The BUILD2 phase in DB2 V7 improves the elapsed time by 81% and the CPU time by 23%.
The BUILD2 phase in DB2 V7 improves the elapsed time by 83% and the CPU time by 29%.
Table 6-16 summarizes the comparison of the BUILD2 phase for the DB2 V6 REORG utility
using SHRLEVEL CHANGE, SORTKEYS, NOSYSREC, and inline COPY with the DB2 V7
REORG utility, when reorganizing the first three partitions.
The BUILD2 phase in DB2 V7 improves the elapsed time by 83% and CPU time by 29%.
Managing the parallel subtasks to building the five NPIs in parallel, has contributed to an
increase in CPU time.
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, the
larger the improvement of the BUILD2 phase will be. These measurements show that the
BUILD2 phase has been improved with up to 83% in elapsed time, and with up to 29% in
CPU time in the case of five NPIs.
If you only have one NPIs on a partitioned table space, you can still expect an improvement in
the BUILD2 phase up to 37% in elapsed time, and up to 34% in CPU time.
Some DB2 catalog tables has been changed, to enable RUNSTATS to update more
information about space.
A new keyword FORCEROLLUP, allows you to force the roll up of statistics to aggregate
tables, even if any partitions are empty.
You can overwrite the default value for STATISTIC HISTORY at RUNSTATS level by specifying
the keyword HISTORY and the level you want: ALL, ACCESSPATH, SPACE, or NONE.
The STATISTICS HISTORY will save the data in the following new DB2 catalog tables:
SYSIBM.SYSCOLDIST_HIST
SYSIBM.SYSCOLUMNS_HIST
SYSIBM.SYSINDEXES_HIST
SYSIBM.SYSINDEXPART_HIST
SYSIBM.SYSINDEXSTATS_HIST
SYSIBM.SYSLOBSTATS_HIST
SYSIBM.SYSTABLEPART_HIST
SYSIBM.SYSTABLES_HIST
SYSIBM.SYSTABSTATS_HIST
Note: If you are dropping an object, all the information in the history tables will be deleted too.
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).
However, the increase of elapsed time and CPU time will be less than 5%.
In DB2 V7 you have the option to force the roll up of statistics to aggregate tables, even if
some partitions are empty. You can set up a default value for FORCEROLLUP by setting the
value of STATROLL in ZPARM. The value of STATROLL can be:
YES forces statistic roll up for partitions tables and indexes, where some of the partitions
are empty.
NO specifies no statistic roll up for partitions tables and indexes where some of the
partitions are empty, as RUNSTATS does prior to DB2 V7. This is the default for the
STATROLL parameter.
The value of STATROLL can be overridden at RUNSTATS level, by specify the keyword
FORCEROLLUP and YES or NO.
We recommend, for DB2 systems that have large partitioned table spaces and indexes, that
the value for STATROLL in ZPARM is set to YES especially if some of the partitions are
empty.Then you do not have to change any of your RUNSTATS job to take advantage of
forcing statistics roll up to aggregate tables.This will help the optimizer to choose a better
access path.
C lust er ing
TS IX TS
R3 K1 R1
K2 R2
deleted K3 R3
K4 R4
R2
R4
d eleted
R1
d eleted
p re fe tc h fa c to r
NEAROFFPOS is the number of rows in a non-optimal position, but within the range of 16
pages. FAROFFPOS is the number of rows outside this range. The FAROFFPOS value is
more significant and likely to affect performance than the NEAROFFPOS value, but both
values indicate disorganization of the data, that can lead to performance degradation.
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. We recommend that you run REORG TABLESPACE, if the percent of off-position
rows is greater than 10%.
When using the OFFPOSLIMIT keyword for REORG TABLESPACE, 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. If the calculated value exceeds the specified value of OFFPOSLIMIT, then REORG
is performed.
R ow 2
Row 3
R ow 4
ID M a p ID M a p
Reorganizing the table space eliminates all indirect references to overflow pages.
NEARINDREF is the number of indirect references to overflow rows on another page within
the 16 pages. FARINDREF is the number of indirect references to overflow rows outside this
range. When considering the statistics, both values indicate disorganization of the data.
When rows are placed in another page than their home page, lock avoidances cannot be
used, so DB2 has to take a lock. That can lead to performance degradation, especially in a
data sharing environment.
You can calculate the percentage of indirect row references based on the values of
NEARINDREF, FARINDREF and CARDF in SYSTABLEPART:
((NEARINDREF+FARINDREF)/CARDF)*100
You can then determine if you should run REORG TABLESPACE to remove indirect row
references. We recommend that you run REORG TABLESPACE, if the percent of indirect row
references is greater than 10% for non-data-sharing environment, and for a data-sharing
environment if the percent of indirect row references is greater than 5%.
When using the INDREFLIMIT keyword for REORG TABLESPACE, 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. If the calculated value exceeds the specified value of INDREFLIMIT, then REORG is
performed.
For simple table spaces, dropping a table results in that table’s data rows remaining. The
amount of dead space for a simple table space can be tracked directly with PERCDROP in
SYSTABLEPART.
For an index, deleted keys are marked as pseudo deleted. Actual cleaning up will not occur
except during certain processes, such as before a page split.
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.
To minimize the CPU cost of an index scan, it is important to remove pseudo deleted entries.
Every time an SQL statement makes a scan of an index, it has to scan all entries in the index,
including pseudo deleted entries, that have not yet been removed.
We recommend that you run REORG INDEX, if the percent of pseudo deleted entries is
greater than 10%.
For LOB table spaces, an updated LOB will be written without reclaiming the old version of
the LOB immediately.
When FREESPACE approaches zero for a LOB table space, it is a good time to reclaim the
space, but there are no direct statistics indicating how much will be reclaimed. 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, if the percent of free space is less
than 10%.
The FREESPACE gives an indication of how many more LOBs can be added into the existing
extents already allocated.
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
A u x ilia r y ta b le ( L O B t a b le s p a c e )
DB2 allocates space for LOBs in chunks. A chunk is 16 contiguous pages of a LOB. If the size
of a LOB is smaller than a chunk, then it is expected to fit in 1 chunk. If the size is greater than
a chunk, then it is optimized to fit into the minimum number of chunks. The fragmentation or
non-optimal organization of a LOB table space is measured in the value of ORGRATIO in
SYSLOBSTATS. Due to fragmentation within chunks, LOBs are split up to store in more
chunks than would be optimal, and ORGRATIO in SYSLOBSTATS will increase. A value of
1.0 is optimal for ORGRATIO. 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
A u x ilia r y ta b le ( L O B t a b le s p a c e )
We recommend that you reorganize LOB table spaces, if the value of ORGRATIO in
SYSLOBSTATS is greater than 2.0.
When considering the statistics, the LEAFFAR value is more significant and likely to affect
performance than the LEAFNEAR value, but both values indicate disorganization of the leaf
pages, which can lead to performance degradation.
LEAFDIST also measures index leaf pages disorganization, but it is not as good a
measurement as using LEAFNEAR and LEAFFAR. For DB2 V7, we recommend the use of
LEARNEAR and LEAFFAR instead of LEAFDIST. See Figure 6-18.
L e a f P a g e L e a f P a g e L e a f P a g e L e a f P a g e
1 3 1 4 7 8 7 9
H O T J A K F R I G R U
0 -3 2 6 5 -9 6
p re fe tc h
q u a n t it y
After reorganizing the index, the leaf pages are in the optimal physical position. For small
indexes, LEAFNEAR and LEAFFAR will be 0 after reorganization. See Figure 6-19.
L e a f P a g e L e a f P a g e
L e a f P a g e 8 L e a f P a g e 9
1 0 1 1
F R I G R U H O T J A K
0 -3 2 6 5 -9 6
p r e fe tc h
q u a n t it y
For large indexes, LEAFNEAR may not be 0 after reorganization. This is because space map
pages are periodically placed throughout the pages set, and the jump over space map pages
shows up as a count in LEAFNEAR.
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. We recommend that you run REORG INDEX, if the percent of physical leaf
disorganization is greater than 10%.
When using DB2 V7, we recommend that you use the above formula to determine when to
run the REORG INDEX utility, instead of using the LEAFDISTLIMIT keyword for REORG
INDEX utility.
Im age
1)
C opies
C O P Y TO C O P Y TAB LE S P AC E D B1 .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)
C o py the c opy
2)
R e cord in ca talog
The COPYTOCOPY utility does not support the following catalog and directory objects:
DSNDB01.SYSUTILX, and its indexes
DSNDB01.DBD01, and its indexes
DSNDB06.SYSCOPY, and its indexes
The SYSCOPY columns, ICDATE, ICTIME, START_RBA will be those of original entries in
SYSCOPY row when the COPY utility recorded them. While columns DSNMAE,
GROUP_MEMBER, JOBNAME and AUTHID will be those of the COPYTOCOPY job.
COPYTOCOPY will leave the target object in read-write access (UTRW), and that allows
other utilities and SQL statements to run concurrently with the same target objects, except for
utilities that insert or delete records in SYSCOPY; namely COPY, LOAD, MERGECOPY,
MODIFY, RECOVER, QUIESCE, and REORG utilities, or utilities with SYSCOPY as the
target object.
Table 6-17 summarizes the comparison of using the COPY utility with the COPYTOCOPY
utility to make additional full image copies.
Table 6-17 Using COPYTOCOPY utility to make additional full image copies
COPY utility COPYTOCOPY utility Delta in %
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. The
measurements show that you can save up to 4.9% in elapsed time per copy by using the
COPYTOCOPY utility instead of the COPY utility. Another advantage is that COPYTOCOPY
leaves the target object in read-write access (UTRW), and that allows other utilities and SQL
statements to run concurrently with the same target object.
If you need to minimize the time that some critical objects are unavailable due to making
additional copies to a remote site, the new COPYTOCOPY utility is the right way to make
additional copies of these objects.
The enhancement is provided by the PTFs for APARs PQ46759 and PQ45268. Check their
prerequisites; at the time of our installation we also needed PQ43771, PQ45015, PQ45776,
PQ46245, PQ47035, PQ51501, and PQ52120.
D B 2 fo r
O S /3 9 0
a n d Z /O S
Since the SQL SELECT statement can access any DRDA server, the data source may be any
member of the DB2 Family, Data Joiner, or any other vendor who has implemented DRDA
server capabilities. Using Cross Loader is much simpler and easier than unloading the data,
transferring the output file to the target site, and then running the LOAD utility.
Figure 6-22 shows the output from Cross Loader, 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.
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, to avoid
problems when converting data from one code page to another.
The new utility statement EXEC SQL can be used before and/or after any of the utilities, that
is, RUNSTATS, COPY, and so on.
The measurements were performed under DB2 V7 with and without this enhancement, for a
customer SYSCOPY table with 975,341 rows, with 7,476 entry records for the specific
tablespace. The results are listed in Table 6-18.
With this enhancement, the improvements are over 90% in both CPU and elapsed time.
Prior to V7, DB2 would prefetch blocks. The blocks might contain more rows than the
application needed and this could have a negative impact on the performance of such
statements. Although there is a performance improvement in CPU savings in DB2, most of
the performance improvement comes in the form of elapsed time savings. This is because in
an environment of short running SQL transactions, the network latency adds a higher level of
magnitude to the overall transaction time, as opposed to the actual processing of the SQL
statement.
If DB2 knows that only one row, or few rows, are required, the block prefetching does not take
place, and only the specified number of rows is returned in the result set.
This new clause FETCH FIRST n ROWS ONLY, does not allow the application to fetch more
rows than the specified number n. An attempt to fetch more rows than specified is handled the
same way as normal end of data (SQLCODE +100, SQLSTATE 02000). See Figure 7-1.
CREATOR NAME
---------+---------+---------+---------+---------+---------
SYSIBM SYSAUXRELS
SYSIBM SYSCHECKDEP
SYSIBM SYSCHECKS
SYSIBM SYSCHECKS2
SYSIBM SYSCOLAUTH
DSNE610I NUMBER OF ROWS DISPLAYED IS 5
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
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. The processing also results in an implicit close of
the cursor at the server when reaching the value of n. This saves line flow in the network by
not requiring the client to explicitly close the cursor with extra communications.
For example, if m is less than n, there will be "n divided by m rounded up" blocks sent to
return n rows. This has the performance implications discussed below. When m is greater
than n, there is no effect, since the result set is truncated to the value of n, and all n rows will
be returned in a single block.
Currently, with DB2 V7, the lower value between n and m is also assumed by DB2 optimizer
for access path selection of the query; this is no longer the case with the change implemented
by the PTF for APAR PQ49458 (still open at the time of writing.) If both clauses are explicitly
specified, DB2 will honor the specified values and keep the two options independent.
If the OPTIMIZE FOR clause is not specified, a default of OPTIMIZE FOR m ROWS is
assumed, where m is equal to the value of n in the FETCH FIRST n ROWS ONLY clause.
Each row is 20 bytes. A larger row size would create even larger differences in the
comparisons. The semantics of OPTIMIZE FOR 1 (or 2 or 3) ROW clause results in a query
block of 16 rows. This forces a network turnaround when the result set is greater than 16
rows. OPTIMIZE FOR m ROWS would cause line turnarounds at the value of m, which is an
even greater performance degradation.
The effect of performance degradation is obvious in Figure 7-2, which shows the overall
transaction rate for the three versions of the SQL statements for the three result set row
counts of 50, 200, and 400.
150
50
0
50 200 400
Number of Rows
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. This is because they
return the same number of rows. 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).
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, 200, and 400.
0.01
0.009
0.008
CPU time per transaction
0.007
SELECT * FROM Y
0.006
Seconds
0.002
0.001
0
50 200 400
Number of Rows
Figure 7-4 shows the elapsed time outside of DB2 and the host to perform the transactions.
Notice that the elapsed time slowly increases for the SELECT statement without the FETCH
FIRST n ROWS ONLY clauses. This is the result of the increased number of bytes as the
result set increases. Notice also that the elapsed time for the SELECT with the OPTIMIZE
FOR 1 ROW clause is much larger than the other two. This is an example of the high cost of
network turnarounds.
0.06
0.05
Elapsed time per transaction
0.04
SELECT * FROM Y
Seconds
0.01
0
50 200 400
Number of Rows
The performance measurements shows that if you do not need to fetch all the rows in a result
set, you can benefit from using FETCH FIRST n ROWS ONLY. It is recommended that you
use FETCH FIRST n ROWS ONLY, every time you do not need a full result set, but can
minimize the numbers of rows in the result set.
After you have declared the cursor, you have to open it:
EXEC SQL
OPEN 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.
The performance impact of using a non-singleton SELECT statement to retrieve only one
qualified row from a table into an application, has an extra CPU cost in the DDF address
space of 4%. See Figure 7-5.
58
in micro seconds
57
56
55
54
53
52
51
50
No singleton SELECT
Singleton SELECT
The extra CPU cost can be up to 30% in other environments such as CICS. The extra cost of
CPU time for using non-singleton SELECT statement is used to OPEN and CLOSE the
cursor.
When COMMIT/ROLLBACK is used in a stored procedure, the whole unit of work, including
uncommitted changes made from the client before the stored procedure was called, will be
committed or rolled back.
Unlike compiled Java stored procedures which are executed in a WLM stored procedure
address space, the interpreted Java is invoked by the WLM stored procedure address space,
but is executed in a JVM under OS/390 UNIX System Services (USS). See Figure 7-6.
OS/390 System
DRDA
or Stored
Procedures PROCLIB
Java DB2
or Address Space SPAS
Native EXEC SQL JCL
Catalog Entry LE Enclave
CALL
Client PROGX
Sched Driver Driver:
JDBC/SQLJ
Driver
...
CALL SYSJAROBJECTS
ADD_CUSTOMER 3
JARSCHEMA JAR_ID JAVA_DATA ...
(FIRSTNAME,...)
... MY JAR
Although there are no syntax changes, two parameters are enhanced. The LANGUAGE
parameter now accepts JAVA, which indicates the stored procedure or functions written in
Java and the Java Byte code will be executed in the OS/390 JVM, under USS.
The EXTERNAL parameter, which specifies the program that runs when the procedure name
is specified in a CALL statement, is also extended. If LANGUAGE is JAVA then the
EXTERNAL NAME clause defines a string of one or more external Java routine name(s),
enclosed in single quotes.
DB2 executes Interpreted Java stored procedures and functions using the OS/390 JDK 1.1.8
and above. Using the JDK 1.1.8, the JVM is created and destroyed each time the Java stored
procedure is invoked. The OS/390 JDK 1.3 should overcome this problem.
The points we make here are not necessarily listed in order of importance. They should be
implemented as a whole.
This defines the way in which dynamic memory is used by SQLJ and JDBC applications. If
you do not specify heappools(on), then you incur the very considerable overhead of memory
being repeatedly freed and allocated as objects are instantiated.
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. Otherwise, you
will have to grant authorization over the underlying DB2 objects to the authorization id
executing the plan. Dynamic SQL includes JDBC and cursor controlled updates and deletes
in SQLJ.
Use the QUALIFIER keyword of the BIND command to provide qualification for unqualified
table or view names referenced in JDBC and SQLJ.
INTEGER int
DATE java.sql.Date
CHAR String
VARCHAR String
TIME java.sql.Time
TIMESTAMP java.sql.Timestamp
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.
Ensure JIT compilation for every Java method Systems Programmer/Application Integrator
7.5 Unicode
DB2 V7 introduces full support for a third encoding scheme besides EBCDIC and ASCII,
Unicode.
The Unicode encoding standard is an encoding scheme that can include characters for
almost all the languages in the world.
If these recommendations are not followed, the results of SQL may be unpredictable.
UCS-2
UCS-2 is a fixed-width 16-bit encoding standard, with a range of 2*16 code points.
UCS-4
UCS-4 is a fixed-width 32-bit encoding standard, with a range of 2*31 code points. The 2*31
code points are grouped into 2*15 planes, each consisting of 2*16 code points. The planes
are numbered form 0. Plan2 0, the Basic Multilingual Plane (BMP), corresponds to UCS-2.
UTF-8
UTF-8 is a transformation format in 8 bits and uses a sequence of 8-bit values to encode UCS
code points.
UTF-16
UTF-16 is a transformation format in 16 bits and uses a sequence of 16-bit values to encode
UCS code points.
Even without translation, there is still a small CPU cost to handling Unicode data types.
Server elapsed time allows remote clients to determine the actual amount of time it takes for
DB2 to parse a remote request, process any SQL statements required to satisfy the request,
and generate the reply. It does not include any of the network time used to receive the request
or send the reply. A timestamp is recorded when DDF first receives a remote request.
In a DB2 data sharing environment, 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. This occurs during:
Read-only switching (pseudo close)
DB2 shutdown and this member was the last updater of the page set/partition.
Without this enhancement, DB2 had to scan the whole GBP directory looking for the entries
for a particular page set. DB2 V7 requests to use Name Class Queues at group buffer pool
connect.
Name Class Queues allows the CFCC to organize the GBP directory entries into queues
based on DBID, PSID and partition number. Locating and purging these entries will now
happen more efficiently.
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:
.
DSNB797I -DBG2 OTHER INTERACTIONS
REGISTER PAGE =0
UNREGISTER PAGE =0
DELETE NAME = 0
READ STORAGE STATISTICS = 12
EXPLICIT CROSS INVALIDATIONS =0
ASYNCHRONOUS GBP REQUESTS =0
The required levels and service levels for the CFCC are:
CFCC level 7 at service level 1.06
CFCC level 8 at service level 1.03
CFCC level 9
Prior to OS/390 Version 2.8 the level of the CFCC was not externalized. The only way to
safely determine what level the CFCC was running at was to ask the system administrator.
OS/390 Version 2.8 enhances the D CF command output. To externalize the level of the
CFCC. See Figure 8-1.
Applications using TSO attach to DB2 can use the parameter GROUP(NO) on the DSN
command.
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, it posts any startup ECBs that might exist to notify the waiting applications
that DB2 is now available for work.
Limited support for using the group attach for DL/I batch is available in DB2 for MVS Version
4, DB2 UDB for OS/390 Versions 5 and 6 by arrangement with IBM Support, via APAR only.
This support has restrictions. DB2 ignores the STARTECB parameter on the CONNECT call,
when the group attach name is coded. DB2 therefore behaves differently, depending on if you
specify the Data Sharing group name or DB2 subsystem name with the STARTECB
parameter.
Now that STARTECB is supported for group attach, the incompatibility is removed and
therefore group attach support can now be safely added for DL/I Batch without any
incompatible behavior being introduced.
EXEC CICS CREATE DB2CONNl supports DB2GROUPID. It fails with an INVREQ if both
DB2GROUPID and DB2ID are specified.
The semantics of CEMT/EXEC CICS INQUIRE DB2CONN DB2ID() change slightly. When
not using group attach, there is no change, 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; it could be blank). When connected to DB2, this is the name of the DB2
connected to. For group attach this field will be blank if CICS is not connected to DB2.
However when CICS is connected to DB2, it contains the member of the DB2 data sharing
group that was chosen. 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.
Whether it be via DSNC STRT xxxx or INITPARM, or EXEC CICS SET DB2ID(), a request to
connect to a specific DB2 always overrides group attach. This gives the user the override
capability if it is required. It should be noted, however, that DB2GROUPID has to be reset
explicitly should group attach be wanted later.
Indoubt resolution
The DB2 V7 enhancements to group attach do not include solving the problem of unresolved
indoubts. There is no DB2 peer recovery.
Indoubt resolution depends on which action, YES or NO, you specify for the keyword
RESYNCMEMBER on the DB2CONN definition.
IMS looks for a DB2 group name if the following conditions for the dependent region SSM
member are met:
SST=DB2 was specified.
SSM= was specified when the dependent region was started.
A subsystem with the name specified in the SSM member parameter SSN was not found
to be connected to the IMS control region.
The subsystem name specified in the dependent region SSM member is then interpreted as a
DB2 group name and IMS calls MVS Name Services. If MVS returns a positive response to
the group inquiry, IMS selects a member of the DB2 group that is connected to the IMS
control region and connect that DB2 to the dependent region.
All DB2s IMS and any of its dependent regions can connect to must still be specifically named
in the IMS control region SSM member.
DB2 V5 APAR PQ22895 introduces a new bind/rebind option that can be considered when
none of the above actions are desirable. 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.
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.
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. If the transaction subsequently rolls back, the pages will be updated again during the
rollback process and will be written again to the CF at the end of abort.
This option is only useful if the dependent transaction is spawned during syncpoint
processing of the originating transaction.
Table 8-1 illustrates the effect of the IMMEDWRI subsystem parameter and the
IMMEDWRITE bind option on the value at run time. A value of YES takes precedence
whether it is the subsystem parameter or the bind option.
Table 8-1 Immediate write hierarchy
IMMEDWRITE bind option IMMEDWRI subsystem value at run time
parameter
NO NO NO
NO PH1 PH1
NO YES YES
PH1 NO PH1
YES NO YES
IMMEDWRITE(PH1) IMMEDWRITE(YES)
IMMEDWRITE(PH1) IMMEDWRITE(NO)
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.
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.
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.
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
Software
– OS/390 V2R8, CF micro code level 8
– DB2 V7
– IMS V6 DCCTL — 78 IMS regions — 750 terminals per member
– TPNS
ARM delay 7 6
DB2 restart 67 55
DB2 shutdown 16 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.
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.
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.
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.
Recommendation
Choose a value for the INITSIZE of the CF Lock structure that is a power of 2. 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. If you plan to change the value for the
parameter HASH, validate the lock structure sizing with IBM support.
IFCID 0217
This record details the amount of available storage in the DBM1 address space, the amount
of storage for MVS use, the total Getmained stack storage and the total Getmained storage.
This is followed by information on each DBM1 storage pool and each agent storage pool. If
there are more than 250 such pool entries, they will overflow to another IFCID 217 record. For
each pool, the total storage used is recorded. For agent pools, the thread is identified by
Authorization ID, Correlation ID, Connection Name, and Plan Name. The description of this
IFCID is shown in Figure 9-1.
IFCID 0219
Each time a LISTDEF is used by a utility it is recorded by this IFCID. 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, I for
an index space list, or M for a mixed list.
IFCID 0220
This record is written whenever a dynamically allocated utility data set is closed. It contains
the DD name, the data set name, and the template name. It also contains the number of
reads, writes, and check macro invocations, and the number of times an end of volume
condition occurred during writing. The timestamp of the first open for the data set, 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. See 4.3.2, “Database address
space — virtual storage consumption” on page 92 for some more information. The
description of this IFCID is shown in Figure 9-2.
*/********************************************************************/
*/* IFCID 0217 for storage manager pool statistics. */
*/********************************************************************/
* DCL 1 QW0217HE BASED BDY(WORD), /* IFCID(QWHS0217) HEADER */
* 3 QW0217AV FIXED(32), /* AMOUNT OF AVAIL STORAGE */
* 3 QW0217MV FIXED(32), /* AMOUNT OF STG FOR MVS USAGE */
* 3 QW0217CR FIXED(32), /* STG RSRVD ONLY FOR MUST CMPLT */
* 3 QW0217SO FIXED(32), /* STG CUSHION WARNING TO CONTRACT*/
* 3 QW0217AL FIXED(32), /* TOTAL GETMAINED STACK STORAGE */
* 3 QW0217GM FIXED(32), /* TOTAL GETMAINED STORAGE */
* 3 * CHAR(8); /* Reserved */
* DCL 1 QW02172 BASED BDY(WORD), /* POINTED TO BY QWT02R20 */
* 3 QW0217PH FIXED(32), /* (S) */
* 3 QW0217ST FIXED(32), /* TOTAL STORAGE IN THE POOL */
* 3 QW0217CL FIXED(8), /* STORAGE CLASS */
* 3 QW0217BP FIXED(8), /* MVS SUBPOOL */
* 3 QW0217FL BIT(8), /* FLAGS */
* 5 QW0217FX BIT(1), /* 1=FIXED-STORAGE POOL */
* 5 QW0217VR BIT(1), /* 1=VARIABLE-STORAGE POOL */
* 5 QW0217LS BIT(1), /* 1=MORE QW02172 DATA WILL FOLLOW*/
* /* 0=THIS IS THE LAST QW02172 DATA*/
* 3 * FIXED(8), /* Not used */
* 3 QW0217DE CHAR(24), /* STORAGE POOL DESCRIPTION */
* 3 * CHAR(8); /* Reserved */
* DCL 1 QW02173 BASED BDY(WORD), /* POINTED TO BY QWT02R30 */
* 3 QW02173H FIXED(32), /* (S) */
* 3 QW02173T FIXED(32), /* TOTAL STORAGE IN THE POOL */
* 3 QW02173L FIXED(8), /* STORAGE CLASS */
* 3 QW02173P FIXED(8), /* MVS SUBPOOL */
* 3 QW02173F BIT(8), /* FLAGS */
* 5 QW02173X BIT(1), /* 1=FIXED-STORAGE POOL */
* 5 QW02173R BIT(1), /* 1=VARIABLE-STORAGE POOL */
* 5 QW02173S BIT(1), /* 1=MORE QW02172 DATA WILL FOLLOW*/
* /* 0=THIS IS THE LAST QW02173 DATA*/
* 5 QW02173A BIT(1), /* 1=PARENT TASK FOR PARALLELISM */
* 5 QW02173I BIT(1), /* 1=CHILD TASK FOR PARALLELISM */
* 3 * FIXED(8), /* Not used */
* 3 QW02173C FIXED(32), /* (S) */
* 3 QW0217QC CHAR(8), /* AUTHORIZATION ID */
* 3 QW0217QR CHAR(12), /* CORRELATION ID */
* 3 QW0217QN CHAR(8), /* CONNECTION NAME */
* 3 QW0217QP CHAR(8), /* PLAN NAME */
* 3 QW0217QD CHAR(16), /* THE END USER'S USERID AT THE
* USER'S WORKSTATION */
* 3 QW0217QX CHAR(32), /* THE END USER'S TRANSACTION NAME*/
* 3 QW0217QW CHAR(18), /* THE END USER'S WORKSTATION NAME*/
* 3 * FIXED(16), /* Not used */
* 3 * CHAR(8); /* Reserved */
* DCL 1 QW02174 BASED BDY(WORD), /* POINTED TO BY QWT02R40 */
* 3 QW02174D FIXED(32), /* TOTAL DICTIONARY STORAGE */
* 3 QW02174T FIXED(32), /* TOTAL STORAGE IN THE AGENT LOCAL
* POOLS */
* 3 QW02174A FIXED(32), /* # OF ACTIVE ALLIED THREADS */
* 3 QW02174C FIXED(32), /* # OF CASTOUT ENGINES */
* 3 QW02174E FIXED(32), /* # OF P-LOCK/NOTIFY EXIT ENGINES*/
* 3 QW02174F FIXED(32), /* # OF PREFETCH ENGINES */
* 3 QW02174G FIXED(32), /* # OF GBP WRITE ENGINES */
* 3 QW02174W FIXED(32), /* # OF DEFERRED WRITE ENGINES */
IFCID Changes
0002 Page P-lock counters recorded at the Group Bufferpool level. Field added to record
number of times pages were added to LPL.
0003 More granular information on wait times for global locks. Page P-lock counters recorded
at the Group Bufferpool level.
0023, These record are now written for each subtask of a utility that uses multiple subtasks
0024, (REORG and LOAD). They are also written for the new utilities (UNLOAD, MODIFY
0025 HISTORY, and COPY2COPY).
0148 More granular information on wait times for global locks. Page P-lock counters recorded
at the Group Bufferpool level. Fields added to track DDF block fetch.
0150 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.
0254 This IFCID, which records statistics for a CF cache structure (Group Buffer Pool) is now
written at the Statistics Interval. It is added to Statistics Class 5.
0313 Field added to indicate if long running UR was detected by number of checkpoints
(parameter URCHKTH) or number of log records written (parameter URLGWTH).
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, table space, table, or partition)
Waits for child L-locks (page, or row)
Waits for other L-locks
Waits for pageset and partition P-locks
Waits for page P-locks
Waits for other P-locks
The parameter has no effect if the STATIME parameter is greater than 60. It is set on the
install panel DSNTIPN, as shown in Figure 9-4. 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. It can also be used to synchronize between the DB2 statistics trace and RMF.
If STATIME=15 and SYNCVAL=5, then Statistics records will be written at 5, 20, 35, and 50
minutes past each hour.
Figure 9-5 DB2 PM Statistics Report Long with data set statistics
The data set statistics are reported after the buffer pool information. The output looks as
shown in Figure 9-6.
For each buffer pool, only the 10 most active data sets by I/O are reported. The column
DATABASE/SPACENAM/PART reports the pageset name and partition (or data set) number.
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, ASYNCH I/O
AVERAGE is the average number of asynchronous I/Os per second, ASY I/O PGS AVG is the
average number of pages read or written per asynchronous I/O. 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 equivalent asynchronous figures are per page.
Finally, 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.
The restriction to the 10 most active data sets per buffer pool only applies to the DB2PM
Statistics Report Long. Trace records are generated for all data sets and the FILE and SAVE
options will process all IFCID 199 trace records.
BPOOL DATABASE TYPE SYNCH I/O AVG SYN I/O AVG DELAY ASYN I/O AVG DELAY CURRENT PAGES (VP)
SPACENAM GBP ASYNC I/O AVG SYN I/O MAX DELAY ASYN I/O MAX DELAY CHANGED PAGES (VP)
PART ASY I/O PGS AVG CURRENT PAGES (HP)
----- -------- ---- --------------- ----------------- ------------------ ------------------
BP0 DSNDB01 TSP 0.00 14.00 0.00 40.00
DBD01 N 0.00 21.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB06 IDX 0.00 7.00 0.00 4.00
DSNATX02 N 0.00 18.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB06 IDX 0.00 7.00 0.00 4.00
DSNDSX01 N 0.00 14.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB06 IDX 0.00 7.00 0.00 4.00
DSNDTX01 N 0.00 16.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB06 IDX 0.00 7.00 0.00 4.00
DSNDXX01 N 0.00 16.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB06 IDX 0.00 8.00 0.00 4.00
DSNTTX01 N 0.00 21.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB01 IDX 0.00 9.00 0.00 3.00
DSNSPT01 N 0.00 18.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB01 TSP 0.00 1.00 0.00 5.00
SCT02 N 0.00 1.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB01 TSP 0.00 11.00 0.00 2.00
SPT01 N 0.00 14.00 0.00 0.00
1 N/C 0.00
BP0 DSNDB01 TSP 0.00 1.00 0.00 5.00
SYSLGRNX N 0.00 1.00 0.00 0.00
1 N/C 0.00
BP1 DB246129 TSP 18.11 1.00 0.00 60.00
TS612903 N 0.00 89.00 0.00 0.00
4 N/C 0.00
BP1 DB246129 TSP 8.34 1.00 0.00 81.00
TS612903 N 0.00 28.00 0.00 0.00
3 N/C 0.00
BP1 DB246129 TSP 8.31 1.00 0.00 78.00
TS612903 N 0.00 46.00 0.00 0.00
2 N/C 0.00
BP1 DB246129 TSP 7.83 2.00 0.00 81.00
TS612903 N 0.00 65.00 0.00 0.00
1 N/C 0.00
BP7 DSNDB07 TSP 0.00 0.00 0.00 2.00
DSN4K01 N 0.00 0.00 0.00 1.00
1 N/C 0.00
BP7 DSNDB07 TSP 0.00 0.00 0.00 2.00
DSN4K02 N 0.00 0.00 0.00 1.00
1 N/C 0.00
The IFCID 199 records can also be printed using a record trace, as shown in Figure 9-7.
If APAR PQ43357 is applied to DB2 PM, then some additional information is reported in the
Statistics Report and Trace for a data sharing environment as shown in Figure 9-8. The new
item is titled GBP-DEPENDENT GETPAGES and is reported for each Group Buffer Pool. It
records the number of getpages performed for GBP-dependent objects. It is used to indicate
the degree of data sharing.
PAGE P-LOCK LOCK REQ: The sum of all page P-lock lock requests, which can be broken
down further as follows:
SPACE MAP PAGES: The number of page P-lock lock requests for space map pages.
DATA PAGES: The number of page P-lock lock requests for data pages.
INDEX LEAF PAGES: The number of page P-lock lock requests for index leaf pages.
PAGE P-LOCK UNLOCK REQ: The number of page P-lock unlock requests.
PAGE P-LOCK LOCK SUSP: The sum of all page P-lock lock suspensions, which can be
broken down further as follows:
SPACE MAP PAGES: The number of page P-lock lock suspensions for space map pages.
DATA PAGES: The number of page P-lock lock suspensions for data pages.
INDEX LEAF PAGES: The number of page P-lock lock suspensions for index leaf pages.
PAGE P-LOCK LOCK NEG: The sum of all page P-lock lock negotiations, which can be
broken down further as follows:
SPACE MAP PAGES: The number of page P-lock lock negotiations for space map pages.
DATA PAGES: The number of page P-lock lock negotiations for data pages.
INDEX LEAF PAGES: The number of page P-lock lock negotiations for index leaf pages.
The Statistics Report Long will also, in the near future, include the DBM1 storage information
from IFCID 225. The new Storage Statistics section of the report will look something like
Figure 4-5 on page 92.
These are the new items in the Class 3 times, introduced by DB2 in Version 6:
Waits for Commit are now reported in three places in the Class 3 times:
The LOG WRITE I/O figure under SYNCHRON. I/O is the time spent waiting for log write
during Phase 1 of a Two-Phase Commit.
The UPDATE COMMIT figure under SER. TASK SWTCH is the time spent during Phase 2
of a Two-Phase Commit or during a One-Phase Commit (Synchronization Commit).This
includes any wait for log write.
The FORCE-AT-COMMIT figure is the time spent writing LOB values back to the LOB
table space at Commit.
Note that FORCE-AT-COMMIT does not include time spent writing pages to the Group
Buffer Pools at Commit in a data sharing environment.
G lo b a l c o n te n tio n o n L -lo c k s :
G lo b a l c o n te n tio n o n P -lo c k s :
L-LOCKS: The accumulated wait times due to global contention for all L-locks. The
accumulated wait trace events processed for waits for global contention of all L-locks.
PARENT (DB,TS,TAB,PART): The accumulated wait time due to global contention for parent
L-locks. Parent L-locks are any of these L-lock types: database, tablespace, table, partition.
The number of wait trace events processed for waits for global contention for parent L-locks.
CHILD: The accumulated wait time due to global contention for child L-locks. Child L-locks
are any of these L-lock types: page, row. The number of wait trace events processed for waits
for global contention for child L-locks.
OTHER: The accumulated wait time due to global contention for other L-locks. The number of
wait trace events processed for waits for global contention for other L-locks.
P-LOCKS: The accumulated wait times due to global contention for all P-locks. The
accumulated wait trace events processed for waits for global contention of all P-locks.
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 page P-locks.
OTHER: The accumulated wait time due to global contention for other P-locks. The number of
wait trace events processed for waits for global contention for other P-locks.
PG P-LOCK LOCK REQ: The number of all page P-lock lock requests. This is further broken
down by type of page:
SPACE MAP PAGES: The number of page P-lock lock requests for space map pages.
DATA PAGES: The number of page P-lock lock requests for data pages.
INDEX LEAF PAGES: The number of page P-lock lock requests for index leaf pages.
PG P-LOCK LOCK SUSP: The sum of all page P-lock lock suspensions. This is further
broken down by type of page:
SPACE MAP PAGES: The number of page P-lock lock suspensions for space map pages.
DATA PAGES: The number of page P-lock lock suspensions for data pages.
INDEX LEAF PAGES: The number of page P-lock lock suspensions for index leaf pages.
The SQL workload is a group of related SQL statements processed over a period of time. The
workload is stored in a workload table for input to the Index Advisor. Each SQL statement has
associated with it:
Its frequency (how often it executes)
Its importance (business importance — set manually)
Its weight, calculated as (frequency * importance)
The Index Advisor process is being extended to support DB2 for z/OS and OS/390 Version 7.
DB2 for z/OS is supported by modeling a DB2 for z/OS subsystem on a DB2 UWO system,
thus allowing Index Advisor to analyze the model.
9.3.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, catalog statistics, and SQL workload
A procedure for creating the model and using Index Advisor to analyze it
DB2 UWO
Metadata (tables, views, indexes)
Catalog statistics
SQL workload
Create Index
DBA
Recommendations Index
Advisor
Figure 9-13 Index Advisor process for DB2 for z/OS and OS/390
The db2look command is a DB2 UWO tool. In Version 7 it is enhanced to allow connection to
DB2 for OS390 using dynamic bind. It accesses the DB2 for OS/390 Catalog and generates:
DDL for tables, views, and indexes
DML for propagating the Catalog statistics
You can use the DB2 UWO Command Line Processor to process the DDL and DML files.
A number of jobs are provided to set up and execute this process. These are described briefly
in Table 9-3.
Table 9-3 Index Advisor workload collection jobs
Job Description
DSNTEJWC Calls dynamic workload collector (DSNZSCH). Starts traces for IFCIDs 0316 and
0317. Reads these IFCIDS via IFI and inserts them to the workload collector
tables on DB2 for OS/390.
DSNTEJWF Calls dynamic workload formatter (DSNZSCJ). Extracts SQL statements from
workload collector tables and reformats them into the format expected by the
Index Advisor. Inserts reformatted statements into workload formatter tables.
You can use the results to reaffirm your existing indexes and to ensure that you have not
overlooked beneficial indexes.
9.3.5 Considerations
The analysis time limit affects the completeness of the results. Running the advisor for a
longer time or without time limit may result in even better index suggestions.
The index space restrictions limit 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.
You will still need to decide the best index for clustering or partitioning. The Index Advisor
does not provide recommendations.
Be aware that there are differences between DB2 UWO and DB2 for OS/390, not least in that
they have different Optimizers. The index advisor is based on the DB2 UWO Optimizer and
therefore its recommendations may ignore issues specific to DB2 for OS/390. However, 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.
The initial implementation of the Index Advisor supports dynamic SQL with dynamic
statement caching enabled, that is with CACHEDYNAMIC(YES) specified in your
DNSNZPARM.
9.3.6 Availability
There will be an informal delivery of this facility with DB2 for z/OS and OS/390 Version 7. The
software will be downloadable from the DB2 for OS/390 web site.
A formal delivery is planned at some future date. This will include a Control Center front end
that provides increased automation of tasks and formal task guidance for tasks that are not
automated. It will also support workload collection for static SQL.
Several new DB2 V7 functions have been added to DB2 Estimator, including: the new
UNLOAD utility, more parallel LOAD of partitions, Unicode encoding scheme, new built-in
functions, the FETCH FIRST n ROWS ONLY clause, and Scrollable Cursors.
The Capacity Runs window now reports table and index device busy information for an
average partition of the partitioned table or index. This will show a reduction in device busy
performance estimates effects due to partitioning.
A new function creates transactions from imported SQL based on the program name or
package name from which the SQL was extracted. In addition, a new facility modifies the
transaction environment after a transaction is created.
If you have created and saved the results of a capacity run for exporting, 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. If the same
predicates are used many times without an applicable index, you can create a new index,
which is easy to do in DB2 Estimator.
Support for the LOAD RESUME utility has been added to DB2 Estimator. The new ESS and
RVA DASD devices and the latest S/390 CPUs have been added to the DB2 Estimator project
configuration file, MVS.CFG.
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. 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. 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.
This menu item also produces a list of SQL items that are not in the desired CARDOK status.
If an SQL item was demoted from CARDOK status to PARSEOK status, you can open the
SQL item and proceed through the cardinality questions again, using the old answers only if
they still are correct. The SQL items should be in CARDOK status after this process.
Remember that DB2 Estimator is included in the DB2 Management Clients Package
no-charge feature of DB2 V7. However, for newer versions of DB2 Estimator, you should also
check the Web site:
ibm.com/software/data/db2/os390/estimate
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. OS/390 V2R10 will also deliver 64-bit real addressing support.
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, from the current limit of 2 GB. More DB2 subsystems can be
supported on a single OS image, without significant paging activity. The increased real
memory provides performance and improved scaling for all customers.
With Versions 6 and 7 of DB2, the key benefit of scaling with the larger memory is in the use
of data spaces, first shipped with DB2 Version 6. architecture. Data spaces allow for buffer
pools and EDM pool global dynamic statement cache to reside outside of the DBM1 address
space. Now more data can be kept in memory, which can help reduce I/O time. Customers
who are reaching the 2 GB address space limit should migrate to this solution.
Compression
In the G5/G6 generation of 9672 servers, hardware compression was made by microcode.
The z900 Processing Units have a new unit, the Compression Unit, on its chip. This new
implementation provides better hardware compression performance, allowing 3 to 4 times
fewer cycles than the G6 servers.
Unicode
Unicode support in DB2 Version 7 will be able to use the new hardware translation services
provided through architecture expansion in future hardware.
PQ25914 — With this APAR data space buffers are allowed to be page fixed above 2 GB
without being moved.
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.
Measurement environment
Here we provide the 31-bit and 64-bit specifications.
31-bit measurements:
9672-ZZ7 (G6 turbo): 1.8 GB central storage, 6 GB expanded storage
2 dedicated processors (OLTP-IRWW workload),
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, depending on the test
2 dedicated processors (OLTP workload), 4 dedicated processors (query workload)
ESS and RAMAC3 disk
OS/390 V2R10, z/OS V1R1
DB2 V7
A query scanned a six million rows from 200,000 table space pages. The elapsed times were
equivalent but the CPU overhead of data spaces was measured up to 10%. Transferring
pages from data spaces to the lookaside buffers in the DBM1 address space is responsible
for the CPU overhead.
In order to measure the effect of paging, a second test was executed, once with 1.2 GB
primary buffer pools and once with 6 GB buffer pools in data spaces. Paging was expected to
expanded storage and some to auxiliary storage.
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.
If we ran the same test with a 100% miss ratio, again the elapsed times would be almost
equivalent, and the CPU overhead due to data spaces would be 12%.
400 20
200 10
data space - 100% HIT
0 0
200
sd
no 150
ce Hiperpool
s Data space
ni
e 100
m
iT
50
Elapsed CPU
Compression performance
In this section we cover compression performance features.
Measurement environment
Here we provide specifications for the 9672 and z900 environments.
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, adequate storage was available in order to avoid database I/O and
system paging I/O.
1000
sd 800
no
ce Elapsed
s 600
ni CPU
e
im
T 400
200
0
G6 z900
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. CPU cost improved with 25%.
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%.
Overhead of compression showed to be reduced from 42% on G6 to only 12% on a z900
server. See Figure 10-4 for the results of these measurements.
40
20
0
G6 non comp G6 comp
z900 non comp z900 comp
Utilities run against compressed data experienced a significant reduction in CPU utilization.
For the REORG wit SORTKEYS and compressed data, the reduction in CPU cost was almost
43%.
Striping is a technique to improve the performance of data sets which are processed
sequentially. This is achieved by splitting the data set into segments or stripes and spreading
those stripes across multiple volumes. 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.
For a more detailed discussion of VSAM Data Striping see OS/390 V2R10 DFSMS Using
Data Sets, SC26-7339, and the redbook DFSMS Release 10 Technical Update, SG24-6120.
Notes
Extended format data sets require storage control units that support non-synchronous I/O
operation.
In DB2, a form of data striping has been available since the introduction of partitioned table
spaces in DB2 Version 1 Release 3. Partitioning is, in fact, a method of data striping, with
each partition being a stripe. Concurrent parallel I/O against these partitions/stripes is
possible in DB2 as long as the partition pagesets are allocated on different volumes.
Additionally, the use of the keyword piecesize, introduced in DB2 V4 on a CREATE INDEX
statement, implements a kind of data striping for non-partitioned indexes. Also, ESS devices
and PAV can reduce contention (see 10.3, “ESS enhancements” on page 206.)
VSAM Data Striping could be a good solution for non-partitioned table spaces or for table
spaces where partitioning cannot be implemented, such as segmented table spaces; also
non-partitioning indexes can benefit from striping. Less obvious candidates are the workfile
table spaces; during the merge phase of a sort, all sort work files are merged to one logical
workfile which can result in contention for that merged workfile data set. Be aware that:
The current requirement on striping being applicable only to non-DB2-managed objects
restricts the applicability of this solution.
Performance and usability tests are still under way, and the results and recommendations
are not available at this time.
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; this is also true for deferred writes. From the application point of view
nothing changes, the DB2 prefetch is still 32 pages, but internally the I/O will be reduced in
scope to account for the allocated stripe. Whether this is an advantage or a disadvantage
depends on the workload; 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, due to
the internal reduction of the prefetch quantity I/O from 32 to 2.
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, because the 16 parallel I/O streams only prefetch two
pages each. Also, be aware that parallelism due to partitioning will be decided by the
optimizer, and VSAM I/O striping is independent of the optimizer and/or workload.
Recommendation
The usage of VSAM striping for the DB2 active logs is tested, verified and approved. VSAM
striping for DB2 user data is still under investigation; we strongly advise you to wait for the
results and recommendations from the DB2 labs before using VSAM striping for DB2 data.
10.2.4 Measurements
The performance measurements were executed with the specific objective of evaluating the
DB2 log throughput with VSAM striping.
# stripes INSERTs/min. DB2 log CPU time (sec) CPU time (sec)
(thousand) throughput Class 1 Class 2
(MB/sec)
The log throughput rate increased 59% when the log data sets were 2-striped and 133%
when 4-striped. The number of inserts is consistent with the log throughput. The 1-striped
case was included to demonstrate the slight overhead of striping; there is a 9% throughput
reduction going from a non-striped log to a single striped log, because of the overhead to
write the 32 byte suffix using data chaining.
Static PAV
The association between the base UCB and the aliases is predefined and fixed. Static PAV
was introduced in OS/390 V2R3 and DFSMS 1.3.
Dynamic PAV
The association between the base UCB and the aliases is predefined but can be reassigned.
The reassignment of the alias addresses is governed by WLM (goal mode) and based on the
concurrent I/O activity for a volume. WLM will instruct the I/O subsystem to reassign an alias
UCB. Dynamic PAV was introduced in OS/390 V2R7 and DFSMS 1.5.
Define-Extent Domain
The Define-Extent Domain is dependent on the type of I/O. Table 10-3 gives an overview of
the size of the Define-Extent Domain.
Table 10-3 Define-Extent Domain in DB2 I/O
DB2 Database I/O type Define-Extent Domain
Sequential and Dynamic prefetch with 3 tracks + 4 additional cylinders for SQL
DSNZPARM parameter SEQCACH=SEQ 6 tracks + 4 additional cylinders for utilities
APAR OW43946 introduces a no-serialization option. If applied, the I/O driver will ignore
serialization at the define-extent domain level when PAV is enabled. Read and write I/O is
identified and serialization is done at the track level.
DB2 V7 will exploit the no-serialization option for all database I/Os. Therefore, I/O wait will
only happen for concurrent read and write I/Os against the same track. Also, the concurrency
limitation imposed by DSNZPARM option SEQCACH=SEQ is hereby relieved.
300
250
200 167
100 73
0
1 2 3
Number of concurrent prefetch streams
300
200
100
34 33 37
0
1 2 3
Number of concurrent prefetch streams
Note
Parallel Access Volumes is a special performance enhancement function. It is provided by a
separately priced feature that must be ordered to enable this function in the ESS.
FlashCopy requirements
In order to take advantage of FlashCopy, you must have both software and hardware
prerequisites.
FlashCopy is a feature of the IBM Enterprise Storage Server (ESS), and DFSMS/MVS
Version1 Release3 and subsequent releases provide FlashCopy support. See the redbook
Implementing ESS Copy Services on S/390, SG24-5680 for more details.
This would be a fuzzy backup in that uncommitted changes might still be in progress at the
time of the copy. This would allow you to restart DB2 normally at the recovery site, taking also
care of all in-flight URs.The process is intended to work as follows:
Log suspend, FlashCopy the entire system, log resume.
At recovery site, restore everything and restart.
FlashCopy and Concurrent Copy (CC) are instant-related or so-called time-zero (T0) copy
tools. FlashCopy operates at the logical volume level where CC can also operate at the data
set level. Copies made with Concurrent Copy can be registered in the SYSCOPY table if
invoked via the image copy utility. FlashCopy works entirely outside DB2. DB2 CC copy
produces a consistent copy that can be used by the recover utility. A FlashCopy of an entire
DB2 system has to be restored and possible inconsistencies are resolved during DB2 restart.
Log-only recovery with FlashCopy as an input is not supported.
DEVSERV QDASD,6312
IEE459I 16.00.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
C DS N am e . . . : S Y S1 . S MS . 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 . . . : EX T E ND E D
I f Ex t e nd e d . . . . . . : RE Q U IR E D
E x t en d e d A dd r e ss a b il i t y : NO
R e c or d Ac c e ss Bi a s . . : USE R
R eu s e . . . . . . . . . . : NO
I ni t i al L oa d . . . . . . : SPE E D
S pa n n ed / N o ns p a nn e d . . :
B WO . . . . . . . . . . . :
L og . . . . . . . . . . . :
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 . : NO
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 . . . . :
Performance Objectives
Direct Millisecond Response . . . :
Direct Bias . . . . . . . . . . . :
Sequential Millisecond Response . :
Sequential Bias . . . . . . . . . :
Initial Access Response Seconds . :
Sustained Data Rate (MB/sec) . . . : 40
Availability . . . . . . . . . . . . : C
Backup . . . . . . . . . . . . . . : S
Versioning . . . . . . . . . . . . :
Guaranteed Space . . . . . . . . : Y
Guaranteed Synchronous Write . . : N
Cache Set Name . . . . . . . . . :
CF Direct Weight . . . . . . . . :
CF Sequential Weight . . . . . . :
The Guarantee Space attribute value is set to YES, the SDR must be greater than zero, but
the value will not be used to calculate the number of stripes. In this case, the number of
stripes is determined by the number of volumes specified in the DEFINE CLUSTER
command.
DEFINE CLUSTER -
( NAME (DB2V710G.LOGCOPY1.DS04) -
VOLUMES(* * * *) -
DATACLASS(DB2STRIP) -
STORAGECLASS(VSTRIPE) -
RECORDS(8640) -
LINEAR ) -
DATA -
( NAME (DB2V710G.LOGCOPY1.DS04.DATA) -
) CATALOG(DB2V710G)
The resulting defined VSAM striped data set is allocated with three stripes, as you can see
from the response to the LISTCAT command. See Figure B-5.
CLUSTER--DB2V710G.LOGCOPY1.DS04
ATTRIBUTES
KEYLEN-----------------0 AVGLRECL---------------0
RKP--------------------0 MAXLRECL---------------0
STRIPE-COUNT-----------4
SHROPTNS(1,3) SPEED UNIQUE NOERASE
UNORDERED NOREUSE NONSPANNED EXTENDED
STATISTICS
Note
These fields are reported in DB2PM version 7 on a per-second basis. If you are using earlier
versions of DB2PM, these fields were reported on a per-minute basis. Before using them in
the calculations, convert the values to a per-second basis.
Spreadsheet example
After you have collected the data, 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, the result fields are
the parameters defined in the previous section and the variables in the spreadsheet are x and
y expressed in minutes.
Altering x and y will result in new values for the minimum VP only size and the minimum total
VP and HP size.
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. 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. This approach is not a replacement for existing
buffer pool tuning methodologies, although it can also be helpful in this area.
The basis for the evaluation is the "page miss ratio curve" where you plot buffer pool size
versus miss rate. Based on performance studies and direct customer experience, you might
be able to avoid the "knee" in the reference curve (number of pages versus reference
frequency), if you can hold onto a page in the buffer pool for about 30 seconds. Similarly, you
might be able to get onto the really flat part of the curve, if you can hold onto a page for much
longer, about 5 minutes. The values of 30 seconds and 5 minutes are offered only as rules of
thumb, they are broad guidelines and not optimal.
From the spreadsheet, identify all buffer pools with a low getpage rate. Such buffer pools may
not justify the investment in terms of virtual storage, so you may want to consider
consolidating them.
Identify the buffer pools which are most interesting from a virtual storage saving point of view;
this selection should be based on the getpage rate and the estimated vpool residency.
If the total calculated pool size is so large that it will constrain the virtual storage of the
DBM1 address space, evaluate the use of a hiperpool. As a rule of thumb, the ETSmin (y)
value should be split in 1/3 VP and 2/3 HP.
References in this publication to IBM products, programs or services do not imply that IBM
intends to make these available in all countries in which IBM operates. Any reference to an
IBM product, program, or service is not intended to state or imply that only IBM's product,
program, or service may be used. Any functionally equivalent program that does not infringe
any of IBM's intellectual property rights may be used instead of the IBM product, program or
service.
Information in this book was developed in conjunction with use of the equipment specified,
and is limited in application to those specific hardware and software products and levels.
IBM may have patents or pending patent applications covering subject matter in this
document. The furnishing of this document does not give you any license to these patents.
You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation,
North Castle Drive, Armonk, NY 10504-1785.
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,
should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions, including in
some cases, payment of a fee.
The information contained in this document has not been submitted to any formal IBM test
and is distributed AS IS. 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. While each item may have been
reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or
similar results will be obtained elsewhere. Customers attempting to adapt these techniques to
their own environments do so at their own risk.
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.
C-bus is a trademark of Corollary, Inc. in the United States and/or other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of
Sun Microsystems, Inc. in the United States and/or other countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United States and/or other
UNIX is a registered trademark in the United States and other countries licensed exclusively
through The Open Group.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET
Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks” on page 238.
DB2 for z/OS and OS/390 Version 7: Using the Utilities Suite, SG24-6289
DB2 UDB Server for OS/390 and z/OS Version 7 Presentation Guide, SG24-6121
DB2 UDB Server for OS/390 Version 6 Technical Update, SG24-6108
DB2 Java Stored Procedures -- Learning by Example, SG24-5945
DB2 UDB for OS/390 Version 6 Performance Topics, SG24-5351
DB2 for OS/390 Version 5 Performance Topics, SG24-2213
DB2 for MVS/ESA Version 4 Non-Data-Sharing Performance Topics, SG24-4562
DB2 UDB for OS/390 Version 6 Management Tools Package, SG24-5759
DB2 Server for OS/390 Version 5 Recent Enhancements - Reference Guide, SG24-5421
DB2 for OS/390 Capacity Planning, SG24-2244
Developing Cross-Platform DB2 Stored Procedures: SQL Procedures and the DB2 Stored
procedure Builder, SG24-5485
DB2 for OS/390 and Continuous Availability, SG24-5486
Connecting WebSphere to DB2 UDB Server, SG24-62119
Parallel Sysplex Configuration: Cookbook, SG24-2076-00
DB2 for OS390 Application Design for High Performance, GG24-2233
Using RVA and SnapShot for Business Intelligence Applications with OS/390 and DB2,
SG24-5333
IBM Enterprise Storage Server Performance Monitoring and Tuning Guide, SG24-5656
DFSMS Release 10 Technical Update, SG24-6120
Storage Management with DB2 for OS/390, SG24-5462
Implementing ESS Copy Services on S/390, 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, GC26-9946
DB2 UDB for OS/390 and z/OS Version 7 Installation Guide, GC26-9936
DB2 UDB for OS/390 and z/OS Version 7 Command Reference, SC26-9934
DB2 UDB for OS/390 and z/OS Version 7 Messages and Codes, GC26-9940
DB2 UDB for OS/390 and z/OS Version 7 Utility Guide and Reference, SC26-9945
Also download additional materials (code samples or diskette/CD-ROM images) from this
Redbooks site.
Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes
just a few chapters will be published this way. The intent is to get the information out much
quicker than the formal publishing process allows.
K
G Key performance enhancements 2
Global transactions 15
Group Attach enhancements 17, 167
groupoverride 167 L
leaf disorganization 146
LEAFFAR 146
H LEAFNEAR 146
HPGRBRBA 98 Limited fetch 12
LIST 117
I LISTDEF 114
IDFORE 104 LOAD 88
IFCID 217 92 LOAD partition parallelism 117
IFCID 225 92 LOAD partitions in parallel 118
IFCIDs 180 LOAD without SORTKEYS 122
P
packaging 18 R
Parallel Access Volumes 90, 206 Reasons to migrate 20
Parallel data set open 90 Redbooks Web Site 238
Parallelism 28 Contact us xvii
PARENT_QBLOCKNO 27 REFP 105
partial star join 84 release skipping 20
PCTFREE 141 REORG 88
PERCDROP 144 repositioning 67
Performance and availability 16 Restart Light 17
Performance tools 5 RESTART processing 117
Persistent Coupling Facility Structure sizes 175 RESTP 105
Persistent structure size changes 17 RESYNCMEMBER 169
PLAN_TABLE 26, 27 RETRY 138
Planning for migration 20 Retry of log read request 109
Index 243
RETRY_DELAY 138 Union everywhere 12
RETVLCFK 79 UNION syntax 49
REUSE 141 uniqueness constraint 39
REXX language support 18 UNLOAD 14
RLFERR 104 UNLOAD utility 127
Row expression in IN predicate 12 updatable DB2 subsystem parameters 211
Row expressions 34 UPDATE 2, 25, 41, 45
RUNSTATS enhancements 138 UQ51114 177
RVA 209 USS 158
Utilities 3, 14
utilities output 227
S
SCROLL 61
Scrollable cursors 12, 60 V
PL/1 program 223 VARCHAR columns 79
Searched UPDATE and DELETE 41 VARCHAR index-only access 79
Security enhancements 15 variable-length rows 99
SELECT MAX 74 VDWQ 90
self-referencing subselect 45 view 13
Self-referencing subselect on UPDATE or DELETE 13 Virtual storage 91
self-referencing UPDATE/DELETE 46 Visual Explain 18
SENSITIVE 61 VSAM Data Striping 204
sensitive cursor 69 VSAM I/O striping in OS/390 V2R10 215
SENSITIVE DYNAMIC 62
SEQCACH=SEQ 207
SET CURRENT DEGREE 28 X
SET LOG SUSPEND 108 XML Extender 13
-SET SYSPARM 102
SETXCF 175 Z
Snapshot 209 z/Series 198
SQL 2
SQL performance 2, 25
Star join 82
star join
best environment 85
STARJOIN 82
STARTECB 167
STATHIST 139
STATIME 104
Statistics history 15, 139
Stored Procedure Builder 18
Stored procedures COMMIT/ROLLBACK 157
String data types 160
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