New DB2 V10 Functionality Implemented at Anixter

Many new features were delivered in DB2 V10. This presentation shows

several that were used by Anixter to improve the performance, stability and

usability of their DB2 Applications and systems.

1

After migrating to DB2 V10, a wealth of new features becomes available for use. This

presentation will detail which of the features Anixter chose to implement first. We

will also discuss what features we plan on using next.

1. DSNDB01 tables SYSIBM.SYSLGRNX, SYSIBM.SYSUTIL and

SYSIBM.SYSUTILX were “exposed”. This has facilitated knowledge of the

object a utility is executing against and provided an easy method checking

recovery information.

2. Gain a better knowledge of the access paths of our packages. We use extended

plan management and APRETAINDUP(NO) so we can readily identify packages

whose access paths change during rebind. Use of the new SQL statement

“EXPLAIN PACKAGE” allows us to find and compare the actual access path

change.

3. Improve the management of the DASD space used by our DB2 catalogs.

Compression of SPT01 has facilitated some significant DASD savings.

Additionally we have implemented a Sharelevel Change Catalog Reorg to keep

our systems performing.

4. Some of the new functionality still had issues that we had to address. We’ll

discuss several issues and provide the APAR numbers you will want on in order to

avoid the same issues. We will also discuss what functionality the database staff

will be working on implementing next.

2

About Anixter

Anixter is a leading global supplier of communications and security products,

electrical and electronic wire and cable, fasteners and other small components.

Anixter helps its customers specify solutions and make informed purchasing

decisions around technologies, applications and relevant standards.

Throughout the world, Anixter provides innovative supply chain management

solutions to reduce customers' total cost of production and implementation.

Founded in 1957 and headquartered near Chicago, Anixter trades on The New

York Stock Exchange under the symbol AXE.

3

Three directory tables become “real tables” in V10. They are:

SYSIBM.SYSLGRNX

SYSIBM.SYSUTIL

SYSIBM.SYSUTILX

4

The information contained in these Directory tables has been known for a long

time, it was just never readable through SQL.

Two of the three here have given us some useful information. SYSUTILX is

still very “proprietary” in nature.

5

The table layouts for the exposed directory tables are documented in the SQL

Reference Manual Appendix under DB2 Directory Tables

6

The first exposed table is the log range table, SYSIBM.SYSLGRNX.

This table has a very “concise” row. All fields but one are CHARACTER and

the majority of those are “FOR BIT DATA”

7

Generally, it is not a good practice to put scalar functions around columns utilized as predicates. In this case it works best, although most queries against SYSLGRNX tend to be tablespace scans. The table has two indexes, but you cannot run runstats on those indexes. Therefore, most queries result in tablespace scans.

SELECT CHAR(TS.DBNAME,8) AS DBNAME

,CHAR(TS.NAME,8) AS TSNAME

,TSP.PARTITION

,TS.DBID

,TS.PSID

,LGRUCDT

,LGRUCTM

,HEX(LGRSRBA) AS START_RBA

,HEX(LGRSPBA) AS STOP_RBA

,HEX(LGRSLRSN) AS START_LRSN

,HEX(LGRELRSN) AS STOP_LRSN

,HEX(LGRMEMB) AS LGR_MEMBER

FROM SYSIBM.SYSTABLESPACE TS

INNER JOIN SYSIBM.SYSTABLEPART TSP

ON TS.DBNAME = TSP.DBNAME

AND TS.NAME = TSP.TSNAME

INNER JOIN SYSIBM.SYSLGRNX SL

ON HEX(TS.DBID) = HEX(SL.LGRDBID)

AND HEX(TS.PSID) = HEX(SL.LGRPSID)

AND TSP.PARTITION = SL.LGRPART

WHERE TS.DBNAME = 'EBDEBIZ'

AND TS.NAME = 'ACCOUNT'

AND SL.LGRUCDT IN ('022813', '030113' )

ORDER BY SL.LGRMEMB, SL.LGRSRBA

8

This is the result of the select on the prior slide.

First 4 Rows are from Data Sharing Member 1

Last 5 Rows are from Data Sharing Member 2

Within member, sorted by starting RBA

9

For comparison purposes, the REPORT RECOVERY utility is ran. Shown is

the JCL to report recovery information for the same tablespace the prior query

was ran against.

10

Now, the output from the SYSLGRNX query is presented along with the

output from the REPORT RECOVERY utility.

The content provided in the utility matches the rows selected from

SYSIBM.SYSLGRNX.

11

The two Directory tables exposed for Utility execution are SYSIBM.SYSUTIL

and SYSIBM.SYSUTILX.

As mentioned before, we have not used SYSUTILX as it is very “proprietary”

( VARCHAR(32000) ?!?! )

The one thing we quickly utilized was the DBNAME and SPNAME columns.

12

We have a “home grown” REXX screen to display utility information.

It has always simply placed the result of the DISPLAY UTILITY(*) command

into an ISPF table and displayed it. With the exposure of SYSIBM.SYSUTIL,

we were able to make a quick SQL call following the return of a UTILID ,

from the display command. Using the UTILITYID, we can execute a select to

retrieve the object name that a utility is executing on and append that info to

the line with the UTILITYID.

13

The following select takes the USUDBNAM ( Database ) and USUSPNAM (

Space name ) from SYSIBM.SYSUTIL and has two scalar-fullselects into

SYSIBM.SYSTABLES and SYSIBM.SYSINDEXES. The full-selects are

coalesced as only one will match.

SELECT USUDBNAM, USUSPNAM , HEX(USUDSNU2),

COALESCE(( SELECT

MAX('TB='||RTRIM(CREATOR)||'.'||RTRIM(NAME))

FROM SYSIBM.SYSTABLES T

WHERE T.DBNAME = U.USUDBNAM

AND T.TSNAME = U.USUSPNAM

AND T.TYPE = 'T' )

,(SELECT MAX('IX='||RTRIM(CREATOR)||'.'||RTRIM(NAME))

FROM SYSIBM.SYSINDEXES I

WHERE I.DBNAME = U.USUDBNAM

AND I.INDEXSPACE = U.USUSPNAM ))

FROM SYSIBM.SYSUTIL U

WHERE USUUID = 'DAMON' WITH UR

14

Our catalog and directory backup jobs failed once we exposed the directory

with maintenance months after we went NFM.

The problem was we were using LISTDEF to select the tablespaces and

suddenly the directory matched our LISTDEF wildcard.

Promptly changed our LISTDEF INCLUDES to contain specific tablespaces.

15

Plan management was introduced in V9. Having the ability to fall back to the

access path of the previous version was extremely valuable for migration.

As good as it was, some things were still “half baked”

16

V10 adds many improvements to plan management.

The ability to revert to the access path of the previous and original is still

there… of course!

One major enhancement is the ability to find out what the CURRENT,

ORIGINAL or PREVIOUS access paths are by issuing the EXPLAIN

PACKAGE SQL statement.

The presence of Package copies is in SYSIBM.SYSPACKCOPY

APRETAINDUP(NO) - Access Path Retain Duplicate is the “space saver”. If

you perform a rebind and the access path is unchanged from the current access

path, the current IS NOT copied to the previous and/or original.

Also delivered in V10 is the ability to stop a rebind that would change an

access path.

17

SELECT SUBSTR(SP.COLLID,1,8) AS COLLID,

SUBSTR(SP.NAME,1,28) AS NAME,

SUBSTR(SP.VERSION,1,28) AS VERSION, SP.BINDTIME,

CHAR(DATE(SP.LASTUSED),ISO) AS LASTUSED, SP.VALID AS C,

CASE WHEN SPCP.VALID IS NULL THEN ' ' ELSE 'P' END

CONCAT

CASE WHEN SPCP.VALID = 'N' THEN '(N)' ELSE ' ' END AS

PV,

CASE WHEN SPCO.VALID IS NULL THEN ' ' ELSE 'O' END

CONCAT

CASE WHEN SPCO.VALID = 'N' THEN '(N)' ELSE ' ' END AS

OV

FROM SYSIBM.SYSPACKAGE SP

LEFT JOIN SYSIBM.SYSPACKCOPY SPCP

ON SP.LOCATION = SPCP.LOCATION

AND SP.COLLID = SPCP.COLLID

AND SP.NAME = SPCP.NAME

AND SP.CONTOKEN = SPCP.CONTOKEN

AND SPCP.COPYID = 1

LEFT JOIN SYSIBM.SYSPACKCOPY SPCO

ON SP.LOCATION = SPCO.LOCATION

AND SP.COLLID = SPCO.COLLID

AND SP.NAME = SPCO.NAME

AND SP.CONTOKEN = SPCO.CONTOKEN

AND SPCO.COPYID = 2

WHERE SP.COLLID LIKE 'O%'

AND SP.NAME LIKE 'OE9%'

18

Above is the list of packages…. The SQL ‘flags’ the invalid Previous or

Original copies.

19

The command was successfully processed, but the invalid copy has replaced

the current package copy.

This copy cannot be used.

20

The SQL for the package dependency “report” is below. To get it in the notes

pages, it is in a very small font, so cut and paste…. Replace the collid,

package and version in the CTE.

WITH BIGLIST AS (

SELECT DISTINCT CASE BTYPE

WHEN 'R' THEN CHAR('4TABLESPACE------', 17)

WHEN 'T' THEN CHAR('5 TABLE---------', 17)

WHEN 'G' THEN CHAR('5 GTT---------', 17)

WHEN 'A' THEN CHAR('5 ALIAS---------', 17)

WHEN 'V' THEN CHAR('6 VIEW--------', 17)

WHEN 'I' THEN CHAR('7 INDEX-------', 17)

WHEN 'F' THEN CHAR('0FUNCTION--------', 17)

WHEN 'Q' THEN CHAR('0SEQUENCE--------', 17)

WHEN 'M' THEN CHAR('4 MQT-----------', 17)

WHEN 'O' THEN CHAR('0PROCEDURE-------', 17)

WHEN 'P' THEN CHAR('4PARTITION-------', 17)

WHEN 'S' THEN CHAR('0SYNONYM---------', 17)

ELSE CHAR(SPACE(1) CONCAT BTYPE, 17)

END AS COL1 ,

STRIP(D.BQUALIFIER) CONCAT '.' CONCAT

STRIP(D.BNAME) AS QUALNAME,

COALESCE(ST.DBNAME,IXTB.DBNAME,D.BQUALIFIER) AS DBNAME,

COALESCE(ST.TSNAME,IXTB.TSNAME,D.BNAME) AS TSNAME,

D.DLOCATION ,

D.DCOLLID ,

D.DNAME ,

D.DCONTOKEN ,

D.BQUALIFIER ,

D.BNAME ,

D.BTYPE

FROM SYSIBM.SYSPACKDEP D

INNER JOIN SYSIBM.SYSPACKAGE P

ON D.DLOCATION = P.LOCATION

AND D.DCOLLID = P.COLLID

AND D.DNAME = P.NAME

AND D.DCONTOKEN = P.CONTOKEN

LEFT OUTER JOIN SYSIBM.SYSTABLES ST

ON BNAME = ST.NAME

AND BQUALIFIER = ST.CREATOR

AND BTYPE IN ('T','A', 'V' )

LEFT OUTER JOIN SYSIBM.SYSINDEXES INDX

ON BNAME = INDX.NAME

AND BQUALIFIER = INDX.CREATOR

AND BTYPE = 'I'

LEFT OUTER JOIN SYSIBM.SYSTABLES IXTB

ON INDX.TBNAME = IXTB.NAME

AND INDX.TBCREATOR = IXTB.CREATOR

WHERE P.COLLID = 'OE'

AND P.NAME = 'OE41'

AND P.VERSION = '2013-05-03-12.48.36.146900' )

SELECT (SELECT CHAR(COALESCE(MAX('C'),' '),1)

FROM SYSIBM.SYSPACKDEP PDC

WHERE PDC.DLOCATION = BL.DLOCATION

AND PDC.DCOLLID = BL.DCOLLID

AND PDC.DNAME = BL.DNAME

AND PDC.DCONTOKEN = BL.DCONTOKEN

AND PDC.BQUALIFIER = BL.BQUALIFIER

AND PDC.BNAME = BL.BNAME

AND PDC.BTYPE = BL.BTYPE

AND PDC.DTYPE IN (' ','N')) CONCAT '/' CONCAT

(SELECT CHAR(COALESCE(MAX('P'),' '),1)

FROM SYSIBM.SYSPACKDEP PDP

WHERE PDP.DLOCATION = BL.DLOCATION

AND PDP.DCOLLID = BL.DCOLLID

AND PDP.DNAME = BL.DNAME

AND PDP.DCONTOKEN = BL.DCONTOKEN

AND PDP.BQUALIFIER = BL.BQUALIFIER

AND PDP.BNAME = BL.BNAME

AND PDP.BTYPE = BL.BTYPE

AND PDP.DTYPE = 'P' ) CONCAT '/' CONCAT

(SELECT CHAR(COALESCE(MAX('O'),' '),1)

FROM SYSIBM.SYSPACKDEP PDO

WHERE PDO.DLOCATION = BL.DLOCATION

AND PDO.DCOLLID = BL.DCOLLID

AND PDO.DNAME = BL.DNAME

AND PDO.DCONTOKEN = BL.DCONTOKEN

AND PDO.BQUALIFIER = BL.BQUALIFIER

AND PDO.BNAME = BL.BNAME

AND PDO.BTYPE = BL.BTYPE

AND PDO.DTYPE = 'O' )

, SUBSTR(COL1,2), QUALNAME

FROM BIGLIST BL

ORDER BY DBNAME, TSNAME, COL1

21

V10 allows you to do every permutation of explains… what are the access

paths, or what will they be if we rebind….

22

When a rebind is performed with Extended Plan Management set to Extended if you specify APRETAINDUP(NO) and the new access paths are the same as the old access paths, message DSN288I is issued.

DSNT288I ?D2D1 DSNTBRB2 REBIND PACKAGE DID NOT PRESERVE THE

PREVIOUS AND/OR ORIGINAL ACCESS PATHS FOR

STATIC SQL STATEMENTS IN PACKAGE =

DB2D.WC.WC80.(2010-02-08-20.21.17.440338)

BECAUSE THEY WERE IDENTICAL TO THE NEW

ACCESS PATHS

If you specify APCOMPARE(WARN) or APCOMPARE(ERROR), then message DSN285I is issued to give the result of APCOMPARE

DSNT285I ?D2D1 DSNTBBP2 REBIND FOR PACKAGE = DB2D.WC.WC06,

USE OF APCOMPARE RESULTS IN:

15 STATEMENTS WHERE COMPARISON IS SUCCESSFUL

1 STATEMENTS WHERE COMPARISON IS NOT SUCCESSFUL

0 STATEMENTS WHERE COMPARISON COULD NOT BE PERFORMED.

DSNT254I ?D2D1 DSNTBRB2 REBIND OPTIONS FOR

PACKAGE = DB2D.WC.WC06.(2011-12-13-18.28.13.934873)

ACTION

OWNER E200301

QUALIFIER E200301

…….

The difference between APCOMPARE(WARN) and APCOMPARE(ERROR) is that when APCOMPARE(ERROR) is specified and the rebind results in new access paths, the rebind fails.

23

The default in V10 is now plan management extended.

Other significant enhancements in the PACKAGES area is the LASTUSED

column in SYSPACKAGES is now populated. This will allow identification

of packages that are obsolete.

A final improvement in the SYSPACKAGES area is actually in the child table,

SYSPACKSTMT. During migration (ENFM) all the statements that were in

both EBCDIC and UNICODE format in the V9 and earlier catalogs are now in

a consistent UNICODE format. This greatly simplifies queries of the catalog

to get this information.

24

During migration from CM to ENFM, “Table Space Fan Out” causes all

Defined Global Temporary Tables to “move” from the DSNDB06.SYSPKAGE

to the DSNDB06.SYSTSTAB table space.

If you are still in V10 CM or earlier, this query can identify the packages that

will be affected:

SELECT STRIP(DCOLLID) CONCAT '.' CONCAT STRIP(DNAME)

FROM SYSIBM.SYSPACKDEP

WHERE BNAME = 'SYSPACKAGE'

AND BQUALIFIER = 'DSNDB06'

AND BTYPE = 'R'

25

We ran V8 and V9 with the COMPRESS_SPT01 ZPARM set to yes. This

worked very well for us.

Early doc on the compression of SPT01 was confusing, Read the most current

documentation carefully.

26

LOBs utilize auxiliary tablespaces for storage.

Inline-ing is an option that pulls the start of a LOB into the base tablespace.

Option is great for SLOBS ( Small Large Objects )

27

You can now inline and compress SPT01.

Realizing space savings from these options required two reorganizations for

us. This may have been an issue of maintenance, however this matches our

current experience with inlining and compressing application tables with

CLOBs.

28

This chart represents our experience with inlining an application tablespace

with a LOB column. The base tablespace was already compressed, we were

simply trying to move some of the “small” LOBs into the base tablespace.

The first reorganization brought the LOB inline but did not compress it.

The second reorganization compressed the base tablespace.

29

This is the reorganization compression report from the first reorganization.

The LOBs were inlined during this process, but the report clearly shows no

compression.

30

This is the reorganization compression report from the second reorganization.

The base tablespace with the inline LOBs are now being compressed.

31

32

Remaining space for LOB is available space minus sum of length of other

columns.

33

Under V10 the catalog becomes much easier to reorganize.

Prior releases of DB2 required you to pre-allocate and later delete the

“shadow” copy of catalog and directory tablespaces and indexes. This

process was eliminated by forcing the migration of the catalog and directory to

be SMS managed

Read over Reorganizing the catalog and directory under chapter 25 of the

utility manual.

34

35

Tables with LOBs or XML columns can now be UNLOADed and LOADed to

a single file containing all the data from the table by using spanned record

format.

Prior methodology used File Reference Variables PDS/PDSE or HFS where

each LOB/Document was a member and the Unload file pointed to it. ( Not a

handy format )

New method is orders of magnitudes faster.

Gotcha: In addition to specifying SPANNED, you must specify field

specifications (AKA: Columns) , coding the LOBs / XML at the end and you

must specify the datatype of the “spanning” columns ( CLOB, XML, etc…. )

36

Spanned specified, however unload dataset is not spanned.

37

Spanned specified as was the column datatype, now the unload dataset is

spanned.

38

This is an example of the problem encountered when the parameter signature

of a stored procedure changes.

In this example, a procedure was created to compress a tablespace. The

procedure had two input parameters ( database and tablespace ) and one output

parameter.

The parameter signature had to later change when it became necessary to pass

in the partition number of the tablespace.

All callers of the procedure with three parameters now need to change to add

the additional parameter.

Using the XML parameters that are new in V10, we can pass a simple

document containing the parameters as attributes.

39

This is the SQL to parse the XML into the parameters.

40

Prior to V10, if you revoke a privilege from a user, it would cause the

privilege to be revoked from other users dependent on the grant being revoked

( AKA: Cascading Revoke )

Pre-V10 process to avoid Cascading Revoke on SYSADM:

•Change ZParm Install SYSADM 1 or 2 to the ID you want to revoke.

•Relink the ZPARM

•Reload it: -SET SYSPARM RELOAD

•Cross Fingers

•Issue SQL: REVOKE SYSADM from the ID you want to revoke.

•Change ZParm Install SYSADM 1 or 2 back to the ID it was before you

started.

41

In V10, to cascade or not is controlled by 2 options:

Revoke dependent privileges Zparm, REVOKE_DEP_PRIVILEGES

Revoke dependent privileges SQL clause

ZParm options REVOKE_DEP_PRIVILEGES ( NO, YES, SQLSTMT )

When REVOKE_DEP_PRIVILEGES =NO

Privileges are not cascaded.

You cannot specify “INCLUDING DEPENDENT PRIVILEGES” on

the revoke.

When REVOKE_DEP_PRIVILEGES =YES

Most privileges are cascaded.

You cannot specify “NOT INCLUDING DEPENDENT PRIVILEGES”

on the revoke.

42

When REVOKE_DEP_PRIVILEGES = SQLSTMT

Cascading is controlled at the SQL statement level as specified in the

REVOKE statement.

Note: This is the default

This allows us to keep the SYSADM list accurate by removing SYSADMs

that no longer should have the authority.

43

Prior to V10, DB2 allowed checkpoints to be based on either number of log

records created or a fixed time interval.

DB2 10 enhances checkpoints thresholds to be scheduled on either or both.

Provides ability to use log records when subsystem is busy, and time interval

when subsystem is relatively inactive.

ZParm options that control this:

CHKTYPE ( LOGRECS,

MINUTES, BOTH )

CHKLOGR

CHKMINS

44

45

46

47

48

49

50

51

52

This list shows some of the problems we encountered when we migrated to

V10 NFM.

Some required “clean up” on our behalf, others required maintenance.

53

We had a couple of applications that had status code columns in parent tables

that were always being referenced. We had created additional indexes which

are the primary index keys plus the status code columns. This will allow us to

essentially turn the primary key index into the overloaded index and drop the

overloaded index.

Be careful if you are in this scenario and contemplating include columns.

54

Opening a service request will result in a lot of work on IBM’s behalf, but it

may also result in a lot of work on your behalf. When you encounter a

problem, do a little research and attempt to figure out the scenario that causes

the problem.

Try to code a script to recreate the issue. You’ve seen them before in PTFs. If

you can code a script, it will simplify your problem reporting significantly.

55

We often conduct “mini projects” to eliminate any deprecated features during

the time between actual upgrade projects. This greatly reduces the complexity

of the upgrade projects if you do not have to deal with the removal of obsolete

features. Several smaller projects are easier to deal with than one large project.

The rest of the list are features we will be utilizing in the near future.

56

Damon Anderson is the Manager of Data Services at Anixter Inc. He has

extensive experience in DB2, IMS, data replication, eBusiness, Disaster

Recovery, REXX, ISPF Dialog Manager, and related third-party tools and

technologies. He is a certified DB2 Database Administrator. He has written

articles for the IDUG Solutions Journal and presented at IDUG and various

regional user groups.

Damon can be reached at Damon.Anderson@Anixter.com

Steve Loesch is a Sr. Technical Database Administrator at Anixter Inc. DB2

Database Administration and Programming since 1988. All versions of DB2.

Motorola, 1998-1992 DB2 DBA, Platinum Technology, Inc, 1992-1999, DB2

Internal Application using DB2 C/S Applications and PeopleSoft, CA

Technology 2000-2009 DB2 DBA Manager, Managed DB2 SAP 2005-2009.

DB2 Consultant 2009-2010, Database Design and Performance Management,

Migrated DB2 V8-V9. Anixter Inc, 2010-2012 DB2 DBA, Database Design

and Performance Management, Migrated DB2 V9-V10.

Steve can be reached at Steven.Loesch@Anixter.com

57