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
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
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
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
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
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
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
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 [email protected]
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 [email protected]
57