Basis Errors and Solutions

Symptom

This note contains patch information about the dmdb6srp program starting with patch 18 and higher.

Other terms

dmdb6srp, update, statistics, patch
Reason and Prerequisites

Patch list
===================
- Patch 26 (released in July 2008)
- Patch 25 (released in April 2008)
- Patch 24 (released in December 2007)
- Patch 23 (released in June 2007)
- Patch 22 (released in April 2007)
- Patch 21 (released in December 2006)
- Patch 20 (released in November 2006)
- Patch 19 (released in March 2006)
- Patch 18

Solution

Instructions:
Download the most recent version of the dmdb6srp program from SAP Service Marketplace and implement it according toNote 511323.
Naming convention:
In this note,DB2 9is used as a short version of “Version 9 by IBM DB2 for Linux, UNIX, and Windows”.

Problems solved in patch 26

The calculation of the F6 Reorgchk formula contained a small bug until dmdb6srp patch 25.
If PCTFREE was set to -1 (default), the
F6 formula was calculated incorrectly. This resulted in Reorgchk issueing another reorg recommendation
immediately after the reorg.
This error was corrected with dmdb6srp patch 26.

Problems solved in patch 25

When you call dmdb6srp patch 24 for a single table without index, the program incorrectly returns a return value of 255. This error has been corrected with patch 25.
In addition, when you use the single table call of dmdb6srp, the system accepts only table names that have less than 28 characters (including schema names) – even though system tables with longer names exist in DB2 V9.1 or higher. If you want to carry out a single tables RUNSTATS for these tables, this terminates with the following error message when you use dmdb6srp patch 24:
“no valid table name, name too long”.
This error has been corrected with dmdb6srp patch 25.With dmdb6srp patch 24, problems occur in connection with memory allocation. As a result, dmdb6srp terminates with an error “CLI0109E String data right truncation” in certain situations (dmdb6srp -t all). This problem has also been solved with dmdb6srp patch 25.

Problems solved in patch 24

With DB2 Version 8, a manual size calculation is executed in dmdb6srp, which is based on estimates. These may be inaccurate, which may result in implausible table sizes.
For example, this calculation may result in size values that are larger than the theoretical maximum of a table size (32 KB page size, 512 GB tablespace size; only one table in the tablespace
=> maximum tablespace 512 GB) .
The size calculation has been adjusted to prevent such values. With patch 24, the size of a table is the minimum from the calculated size and the system catalog value FPAGES * pagesize, rounded to the next full extent.

Problems solved in patch 23

The new method for size calculation and determination of REORGCHK information that was introduced with patch 20
requires the user temporary
tablespace SYSTOOLSTMPSPACE. If this does not exist in a DB2 system, the following error occurred in the previous versions of dmdb6srp:
DB6CliExecute(): [IBM][CLI Driver][DB2/AIX64] SQL0204N
“SYSTOOLSTMPSPACE” is an undefined name. SQLSTATE=42704
This error previously did not cause a program termination, and dmdb6srp
enters an incorrect RC=0 (corresponds to successful execution) into the log table.
This problem is solved with patch 23. If a
SYSTOOLSTMPSPACE is missing, dmdb6srp terminates with an error, and the system enters the corresponding error code ‘ERRORCODE’ in the log table..
Another problem that is solved with dmdb6srp patch 23 is theoutput of error messages on the console for tables without indexes.
This output is suppressed with dmdb6srp patch 23.

Problems solved in patch 22

Due to a source code error in dmdb6srp, the system did not perform optimally. In patch 22, the select statement that caused this problem has been corrected.

Problems solved in patch 21

When you have dmdb6srp Patch 20, the system only considers the size of the first partition in DB2 systems with several partitions.
This error is eliminated with patch 21.
If you use dmdb6srp Patch 20 with DB2 Version 8, a problem occurs due to a source code error. You try to use the new function (ADMIN_GET_TAB_INFO, REORGCHK_TB_STATS, REORGCHK_IX_STATS) that is only available in DB2 9.
This problem is solved with the new patch 21.

Problems solved in patch 20

DB2 9 provides a new function to calculate table sizes and determine the REORG recommendations.
This new DB2 9 function is first used with this patch.
For example:
When you use “Row Compression” available with DB2 9, incorrect size values are calculated in the old dmdb6srp (patch 19 and below) since the old source code did not take the option of compression into account.
This problem is solved with the new patch.

Problems solved in patch 19
In the display of the dmdb6srp program, for example, the system issues the following messages: “Object SYSIBM.xxxxxxx not found.” or “Unknown Column XML”
The messages in the display are due to an incompatibility between your version of dmdb6srp and DB2 9.
With DB2 9, new system tables were introduced, with a name length that exceeds the limit set in the “dmdb6rts” program. For this reason, the system issues a corresponding message when these tables are processed.
DB2 9 also contains a new XML data type that is not recognized in the previous versions of dmdb6srp.
The incompatibilities described were eliminated with dmdb6srp patch 19.

Problems solved in patch 18

You have a system with kernel 4.6D and the latest CCMS, which you have implemented by importing the relevant patch. If you now use the dmdb6srp program to execute a RUNSTATS for an individual table, you cannot see any log entries for this task in transaction DB13. This problem is solved with patch 18.