agburke 060001QPDN Visits (542)
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 (708)
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 (556)
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 (614)
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 (687)
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 (645)
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 (740)
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 (521)
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 (468)
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 (1415)
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
timmzzz 060000RTR7 Visits (1157)
Customer X experienced Partition-By Growth (PBG) size increase with APPEND YES. Assuming the data is sparsely distributed across the PBG partitions. The following ONLINE REORG redistributed the data to the first 3 partitions. However, after the SWITCH PHASE, concurrent SQL would still append data to the last partition, leaving many partitions empty in between.
timmzzz 060000RTR7 Visits (819)
As of DB2 10 NFM, the Real-Time Statistics logic has been extended to cope with mass delete operations more accurate. Before DB2 10 NFM, the MASSDELETE counters have been incremented after a mass delete oper
A multi table table-space scenario is an exception. As the Real-Time Statistics information is based on page set level, DB2 does not know how many rows are associated to the table the mass delete was operated on. In this case, the SYSI
However, an APAR will be opened to be consistent with SYSI
PM81189: MSGDSNT217I ON REBIND PACKAGE SWITCH AND NO ROW IN SYSIBM.SYSPACKCOPY IN V10 NFM FOR PACKAGE THAT USES CGTT
timmzzz 060000RTR7 Visits (944)
Customer X experienced problems after migrating to DB2 10 NFM. Selected packages where rebound right after the migration. PLANMGMT EXTEND as the default in V10 NFM, shouldallow to return to prior access path if needed.
However, for some packages the old access path could not be reverted even under PLANMGMT EXTENDED.
The reason behind this are Created Global Temp Tables (CGTT). They do have a dependency on SYSPKAGE . During ENFM, when SYSPKAGE is dropped, all packages containing CGTTs
When running a REBIND in DB2 10 NFM, REBIND will return an error message and no previous copy is stored.
Please refer to APAR PM81189 for further details on this problem.
GZJ 1100006WMT Visits (677)
If you are planning for migration to DB2 10, then you should make sure you read this whitepaper by IBM Distinguished Engineer John Campbell.You have to log in using your IBM ID; if you don't have one then you'll need to register. This 28-page whitepaper is based on solid customer experience and gives sound, practical advice on migration that you should be aware of. The advice on maintenance is not a 'nice to do' item but is essential for a good experience.
GZJ 1100006WMT Visits (570)
Planning on using DB2 10 statement level access plan hints? Then you need to read about the new SET_PLAN_HINT stored procedure. This stored procedure is a "common SQL API stored procedure" that validates and deploys optimization hints for SQL statements. Because of the volume of information in this area, the web page linked to above is actually an anchor point for a series of Information Center topics which have been updated to support this new functionality.