GZJ 1100006WMT Visits (596)
Check out this handy link for access to key DB2 for z/OS information resources. The information here is useful to DB2 professionals of all levels of experience, from novice to old hand.
GZJ 1100006WMT Visits (998)
If you are migrating from DB2 Version 9 or DB2 Version 8 to DB2 10, then you need to check out Info APAR II14702. This APAR provides guidance on avoiding know issues both when moving to Conversion Mode(CM), and when entering Enabling New Function Mode (ENFM).
You can read this APAR here: II14702: AVOIDING MIGRATION ISSUES FOR FASTER MIGRATION HINTS & TIPS TO V10
Note that this APAR is in INTRAN status and such is likely to be updated as new information becomes available and as new issues are encountered. For that reason, this blog entry does not contain the APAR text. Instead, we strongly recommend that you read the APAR on a regular basis to ensure that you don't miss any important updates.
We further recommend that you track and remain alert on any HIPER maintenance relating to migration and to the ENFM process.The use of extended HOLD DATA is advisable.
In particular we'd like to draw your attention to the advice to perform ENFM in maintenance mode if at all possible, and if you are data sharing to shut down all members apart from the one in maintenance mode where you plan to run ENFM. If this is not possible, then we recommend that you run ENFM at as quiet a time as possible.
flodubois 270000K6H5 Visits (2293)
Here is the story:
Now, what follows is NOT meant to sound like a sales pitch, but the correct technical solution is to add more zIIPs. It would be prudent to have the zIIPs run in the 30-50% CPU busy range on average (peaks would obviously be higher). zIIPs should be thought of as assist processors and they are not intended to be run as hard as GCPs. This recommendation is not specific to DB2 10, but with DB2 10, it has become even more critical. This is the option that Customer X decided to take - they have now refreshed their processor technology and increased the ratio of zIIP engines to GCP engines. Consequently the original elapsed time performance problems have gone away.
KevinHarrison 1000005N52 Visits (1037)
There are some recent REORG issues that you should be aware of, but they do not affect directory or catalog REORGs.
PM69637 - Lost data on REORG if table has OBID=1. This defect applies to V9 also.
PM62449 - Lost data on REORG if table has OBID=1 in a segmented tablespace. V10 only.
PM73000 - Incorrect rows discarded with REORG DISCARD based on boolean logic conditions. V10 only.
PM68133 - REORG of an RRF PBG with growth of a new partition during the REORG and with zparm SPRMRRF set to DISABLE.
PM69073 - Same scenario as PM68133 but in addition requires that the REORG be materializing a pending alter.
PM61976 - REORG loads data into wrong partition if using SORTDATA NO (which is not the default). Caused by PE APAR PM44475.
PM66874 - Not specifically a REORG issue, but could occur during extend processing for REORG of LOB data.
PM63324 - REORG of multiple partitions of a compressed PBG tablespace can result in rows being compressed incorrectly
KevinHarrison 1000005N52 Visits (808)
If you want to REORG a LOB tablespace then you can just REORG that LOB tablespace. You want to run REORG of the base tablespace using AUX YES. This will work fine, but if you're doing this against a compressed SPT01 then make sure you do not also specify KEEPDICTIONARY until you have the fix on for PM67696.
Also you want to make sure you have PM66874 applied, when running the REORG.
Before you go ahead with the REORGs, we discussed that you would validate that there isn't any dormant corruption that REORG could trip over.
To do that, I recommend you run the following:
CHECK LOB SHRLEVEL CHANGE
CHECK INDEX SHRLEVEL CHANGE on the aux index
CHECK DATA SHRLEVEL CHANGE on the base tablespace using SCOPE AUXONLY AUXERROR REPORT.
KevinHarrison 1000005N52 Visits (1033)
LOB integrity abend during REORG of DBD01. Fix - PM66874,
Issue with catalog/directory space growth. FIX - PM64226 resolve for LOBs only!
For the base SPT01 growth Fix in separate APAR PM74659 not available - this will take some time!
Unformatted pages in SYSDBDXA directory LOB resulting in abends. No broken LOB data. REORG of tablespace to correct. APAR PM64226 to resolve.
Directory LOB extend failure. Fixed with APAR PM66874
REORG abend. Broken aux index. Fixed with APAR PM68842
KevinHarrison 1000005N52 Visits (923)
KevinHarrison 1000005N52 Visits (830)
PM77111: SERVICEABILITY ENHANCEMENT PROVIDING NEW IFCID FOR RIDPOOL FULL CONDITION
This is currently still open
KevinHarrison 1000005N52 Visits (680)
PM75711: SERVICEABILITY ENHANCEMENT TO PROVIDE DIAGNOSTIC LOGGING FOR UNEXPECTED PBG GROWTH ISSUE.
This PMR is still open, but should be monitored
flodubois 270000K6H5 Visits (849)
If you want to REORG a LOB tablespace then you can just REORG that LOB tablespace. If you want to run REORG on the base tablespace using AUX YES - this will work fine, but if you are doing this against a compressed SPT01 then make sure you do not also specify KEEPDICTIONARY until you have the PTF fix on for APAR PM67696.
flodubois 270000K6H5 Visits (840)
Q. If PIECESIZE is specified at maximum of 64GB and (LARGE or DSSIZE x is specified on tablespace), then is the maximum pageset size going to be 64GB*4096 parts =256TB?
A. The number of index data sets is influenced by the number of data partitions. Initially using PIECESIZE of 64GB you could not index 128TB of data using DSSIZE 128 GB or 256 GB due to the reduced number of index data sets. APAR PM42175 was created to allow the specification of 128 GB and 256 GB PIECESIZE.
Specification of 64GB is only allowed when the number of data partitions (derived from DSSIZE) is less than the following maximum data parts.
Chart for 128GB PIECESIZE
Chart for 256GB PIECESIZE
Q. Now that DB2 can support a DSSIZE of 256GB for tablespace what is the new max size for the NPI?
Q. Is the only way to influence it - by increasing DSSIZE for the tablespace?
Q. Is there a way to calculate how much is space is actual used/left to grow based on the Catalog or RTS?
flodubois 270000K6H5 Visits (1077)
Migrating an SQL stored procedure from external to native is not as simple as a DROP/CREATE. You need to understand the release incompatibilities related to SQL stored procedures, examine your external SQL procedure source code, and make any necessary adjustments. This APAR can help you do that. It provides sample job DSNTEJ67 which initiates the process of converting source for an external SQL procedure into source for a native SQL procedure. REXX services, native SQL PL and the HOST(SQLPL) checkout precompiler are combined to extract, inspect, analyze and convert external SQL procedure source code. The appropriate set of native SQL procedure options are applied and a listing of the modified SQL procedure source code is produced.
flodubois 270000K6H5 Visits (1051)
New Site (same URL)
(you will need an IBM ID in order to join the developerWorks community)
The DB2 for z/OS Best Practices web page has moved to a developerWorks community. This move brings with it the following features:
* Video content is streamed from YouTube with HD quality possible.
* From YouTube you can download video to your disk.
* The site allows you to comment on individual Best Practices.
* You can still download transcripts and slides of presentations from the site.
* Content is still organized using the DB2 Roadmap with tags for each category
* Feeds and Social Media integration provided by developerWorks communities.
The one-day seminar "Recommendations from DB2 Health Check Studies" by John Campbell and Florence Dubois has been recorded in 4 parts:
* Continuous Availability
* Special Considerations for WLM, CICS, and DDF
* Speed of Recovery
A popular presentation on writing SQL for improved performance is presented by Tom Beavin:
* SQL Performance (Part 1 & 2)
Best practices for achieving stability in your DB2 access paths is presented by Tom Beavin:
* Achieving Access Path Stability (Part 1 & 2)
Michael_D. 1100004WAH Visits (676)
Michael_D. 1100004WAH Visits (737)