Michael_D. 1100004WAH Visits (2155)
PTF UK91435 (APAR PM79520)
is required for DB2 10 for z/OS customers in a Data Sharing environment
PTF UK91435 is required for DB2 10 for z/OS customers
Michael_D. 1100004WAH Visits (1345)
APAR PM81799: ABEND04E RC00C90101 IN DSNIREDO ERQUAL5005 DURING A RECOVER UTILITY.
All DB2 10 for z/OS users who use COPY or RECOVER online utility with FLASHCOPY
DB2 has been modified to ensure compensation log records are not written while COPY FLASHCOPY is running.
Additionally, this APAR will insure ensure that error conditions are handled correctly.
All DB2 10 for z/OS users are affected who use COPY or RECOVER online utility with FLASHCOPYAll DB2 10 for z/OS users who use COPY or RECOVER online
utility with FLASHCOPY
Michael_D. 1100004WAH Visits (2102)
Michael_D. 1100004WAH Visits (1320)
In preparation to DB2 10 migration there is a need to answer the question if DB2 tooling will support the full functionality of a given DB2 version or will it tolerate the new version and worse if it will not support the new version. Mainly this will be most important if new functionality are effectively used and if the migration of a given DB2 environment completed the conversion to new function mode ( DB2 10 NFM ). Nevertheless, is is also important to watch and maintain the DB2 10 maintenance level to answer the question supported or tolerated.
This table provides information regarding DB2® Tools support for DB2® 10 for z/OS.
For more information on which new functions of DB2 10 are utilized by any specific product, or to find out about DB2 10 compatibility for products or releases not included in this matrix, please contact your IBM Customer Service Representative.
Michael_D. 1100004WAH Visits (1993)
Customers running with DB2 10 NFM have noticed that table spaces associated with the DB2 directory data base or catalog (DSNDB01 and SPT01) experience significant space growth resulting from BIND/REBIND operations, DDL, utility activity (Reorg). The only way customer could sustain the issue was by frequently scheduling reorgs on the DB2 directory and catalog in DB2 10 NFM.
Updated list of APARs for excessive SPT01/DBD01 growth – Base and LOB tablespaces - including related Utility APARs in this area!
DB2 10 NFM Cat/Dir SPT01/DBD01 excessive growth
APAR PM66874 to resolve: LOB integrity abend during REORG of DBD01.
DB2 10 NFM Cat/Dir SPT01/DBD01 excessive growth related
APAR PM68842 to resolve: REORG abend. Broken aux index.
agburke 060001QPDN Visits (859)
These two APARs address unexpected table space growth due to internal DB2 algo
· PM80804 – LOB space growth in V10 due to old read claim LRSN
agburke 060001QPDN Visits (1189)
Many of you, including our own L2 performance team have spent many years creating spreadsheets to combine the stats and accounting data to reveal things like average CPU seconds or elapsed time per occurrence or COMMIT based on the CONNTYPE. This can be used to get a profile of the typical transactions, then look for outlyers based on top 10 reports. Now there is a new IFCID that can aggregate such information, and it can be started by using the STATS CLASS 9 trace.
· PM62797 – IFCID 369 addition to aggregate stats and accounting information in Stats class 9
· PM72949 for OMPE V5.1.1
You will want to check with your vendors to determine when/if your other accounting and stats reports can take advantage of this new functionality.
agburke 060001QPDN Visits (826)
FlashCopy technology continues to become a more integral part of DB2 recoverability, especially in V10. There APARs relate to FlashCopy image copies and RESTORing a a system from Space Efficient FlashCopy.
This has to do with a Buffer manager flag.
· PM77661 – V10 FlashCopy image copy CONSISTENT shows broken page when used against classic segmented table space
These have to do with a flag that is set in HSM.
· PM76937 - V9 RESTORE SYSTEM fails using space efficient FlashCopy
· PM53237 – V10 RESTORE SYSTEM fails using space efficient FlashCopy
agburke 060001QPDN Visits (966)
Here are 2 zIIP related APARs.
In z/OS 1.10 (APAR) WLM started creating work dependent enclaves to allow difernt zIIP offload potential for related enclaves.
In DB2 v10 when Runstats offloads to ZIIP it creates dependent WLM enclaves in STC instead of work-dependent enclaves. This causes a problem for SAP customers who run WLM Enclaves and DB2 stored procedures like ADMIN_UTL_SCHEDULE. In the reported case, a SAP ABAP program calls DB2 stored procedure ADMIN_UTL_SCHEDULE with max_parallel 10 and 1000 tablespaces to process RUNSTATS.
· PM75060 – zIIP eligible RUNSTATS tasks were running in dependent enclaves under STC
This APAR affects QWACZIIP_ELIGIBLE, which represents zIIP eligible workload that executed on a CP. Some customers saw large amounts of zIIP eligible work running on CPs, but in actuality it was an incorrect calculation of the Utility's processing time.
· PM74888- zIIP eligible work incorrectly reported for Utility execution
agburke 060001QPDN Visits (1016)
Regarding the DB2 for z/OS migration process, customers have seen failures due to ALTERing a catalog table that has no available version numbers (SQLCODE4732).
In addition, we are changing the premigration checkout jobs, DSNTIJPM and DSNTIJPA, to add queries that will identify cases where the version numbers are bad. The premigration checkout jobs are to be run before migration processing begins (ie in the release being migrated from). If there is a version number problem then the version numbers can be corrected prior to the migration process. This will ensure that the migration process will not fail due to this problem. See the ++HOLD actions for this APAR for further guidance for using DSNTIJPM or DSNTIJPA.
The following SELECT statement can be used to determine if there are catalog objects that have version number problems:
SELECT SUBSTR(CREATOR,1,8) AS CREATOR,
SUBSTR(NAME,1,8) AS NAME,
WHERE DBID = 6
AND (CURRENT_VERSION < OLDEST_VERSION);
If there are table spaces returned with this query then the version numbers can be corrected by a REORG of the table space and then by running MODIFY RECOVERY with DELETE to recycle version numbers. Additional information about version numbers can be found in the Utility Guide and Reference and also in the Administration Guide.
· PM70914 – DB2 migration fails due to catalog tables having incorrect version numbers
agburke 060001QPDN Visits (881)
We have enhanced the storage request processing for distributed threads to avoid a bottleneck condition that can occur in the DDF communication buffer storage. 04E abends due to virtual storage constraints could be seen in V9 and V10 in some customer environments. This APAR has been marked HIPER, but can also improve the current DDF processing when a rush of distributed threads enter the system at the same time.
· PM75473 – DDF threads have slow response time, and bottleneck due to 64-bit storage requests
agburke 060001QPDN Visits (1072)
This APAR concerns customers who partition table spaces based on a timestamp column. When this customer moved to DB2 10 this query lost the ability to prune partitions on a partitioned table space and the response time increased dramatically. In this case the application was comparing the timestamp column to a host variable with a timestamp precision (6). The temporary fix is to use PLANMGMT to fall back to the previous access path.
· PM81692 – performance degradation for table partitioned on timestamp
This APAR deals with table insert experiencing longer than expected space search times. This can occur when the clustering index does not provide an adequate position for insert within the table.
· PM75921 – long insert times due to inadequate search for free space in the clustering index
agburke 060001QPDN Visits (713)
Since V9 of DB2 we have allowed the ACCESS DB MODE(OPEN) to allow customers to prime buffer pools with objects that will be opened by, for instance, the first application execution of the day. This command showed poor performance previously as it was single threaded. In the next version of DB2 this will be done in parallel, so we have retrofitted it back to DB2 10.
· PM80779- ACCESS DB performance improvement
agburke 060001QPDN Visits (727)
There have been several customers on DB2 10 who have taken partial dumps of DB2 even with MAXSPACE set at 16GBs-32GBs. Much of this has to do with the increased use of 64-bit addressing in DB2 10 and the way z/OS treats the address space to be dumped. The shared storage pools above the 2GB bar are large, but sparsely populated, and thus should not take up much room in the dump. DB2 level 2 has seen much of this storage being dumped inadvertently. These APARs have to do with extra storage being dumped in some cases, and not enough being dumped in others.
· OA39596 – excessive HVSHARE storage included in DUMPs when it is not needed
· OA40015 – SVCDUMP missing high virtual user region storage
· OA40015 – High virtual regions missing from dump
timmzzz 060000RTR7 Visits (2458)
When running more than one DB2 z/OS subsystem on a single LPAR, there is a danger a "runaway" (e.g. storage leak) DB2 subsystem is taking out the LPAR. As this could cause a domino effect of outages caused by that single DB2 subsystem, REALSTORAGE_MAX subsystem parameter was introduced. This parameter was hidden ZPARM SPRMRSMX in DB2 V9 and now with PM24723/PK18354 becomes opaque. With DB2 10 you now have REAL
As mentioned above, it is recommend to set REALSTORAGE_MAX if more than one DB2 subsystems resides on a single LPAR. The best practices as of today are to set this parameter 1.5 to 2 x from the normal DB2 subsystem storage usage. If REALSTORAGE_MAX (DB2 10) or SPRMRSMX in DB2 9 is set to low, the DB2 subsystem might gets terminated before a real storage problem exists. If you set it to high, the LPAR might be gone before the parameter is being considered.
In addition new DB2 10 messages are going along with the actions