Fixes are available
DB2 Version 9.1 Fix Pack 7 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 6 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 6a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 7a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 8 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
APAR status
Closed as program error.
Error description
When running db2batch on a server that contains CPUs with different speeds db2batch can report inaccurate timing results. This problem has only been seen on Solaris platforms. An example of inaccurate timing results follows: * Prepare Time is: 0.070687 seconds * Execute Time is: 783482.621185 seconds * Fetch Time is: 0.000255 seconds * Elapsed Time is: 783482.692127 seconds (complete) * Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output --------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- ------ ------- Statement 1 1 783482.692127 783482.692127 783482.692127 783482.692127 783482.692127 0 0 * Total Entries: 1 * Total Time: 783482.692127 seconds * Minimum Time: 783482.692127 seconds * Maximum Time: 783482.692127 seconds * Arithmetic Mean Time: 783482.692127 seconds * Geometric Mean Time: 783482.692127 seconds To check the CPUs speed, run the following command: Example: /usr/platform/sun4u/sbin/prtdiag System Configuration: Sun Microsystems sun4u Sun Fire 15000 System clock frequency: 150 MHz Memory size: 63488 Megabytes ========================= CPUs ========================= CPU Run E$ CPU CPU Slot ID ID MHz MB Impl. Mask -------- ------- ---- ---- ------- ---- /SB01/P0 32 1200 8.0 US-III+ 11.0 /SB04/P0 128 900 8.0 US-III+ 2.1 /SB08/P0 256 1050 8.0 US-III+ 2.3 : Different CPU speeds will have different tick values, therefore reporting inaccurate timing results. Example: CPU 32, the tick value is 0x9b8ef1df8dfa4 CPU 128, the tick value is 0x74ab35ed4a28b CPU 256, the tick value is 0x881d1458f0e6c The second symptom observed due to this APAR is SQL0973 - Not en ough storage is available in the "PCKCACHESZ" heap to process th e statement. This occurs because package cache space reuse is dependent on ti mestamps. Due to "bad" timestamp values, some misordering event ually prevents the package cache from freeing any space in the p ackage cache. Since PCKCACHESZ is a soft limit, memory usage by the package cache continually grows until some higher limit is hit.
Local fix
No workaround for this problem.
Problem summary
ERROR DESCRIPTION: When running db2batch on a server that contains CPUs with different speeds db2batch can report inaccurate timing results. This problem has only been seen on Solaris platforms. An example of inaccurate timing results follows: * Prepare Time is: 0.070687 seconds * Execute Time is: 783482.621185 seconds * Fetch Time is: 0.000255 seconds * Elapsed Time is: 783482.692127 seconds (complete) * Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output --------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- ------ ------- Statement 1 1 783482.692127 783482.692127 783482.692127 783482.692127 783482.692127 0 0 * Total Entries: 1 * Total Time: 783482.692127 seconds * Minimum Time: 783482.692127 seconds * Maximum Time: 783482.692127 seconds * Arithmetic Mean Time: 783482.692127 seconds * Geometric Mean Time: 783482.692127 seconds To check the CPUs speed, run the following command: Example: /usr/platform/sun4u/sbin/prtdiag System Configuration: Sun Microsystems sun4u Sun Fire 15000 System clock frequency: 150 MHz Memory size: 63488 Megabytes ========================= CPUs ========================= CPU Run E$ CPU CPU Slot ID ID MHz MB Impl. Mask -------- ------- ---- ---- ------- ---- /SB01/P0 32 1200 8.0 US-III+ 11.0 /SB04/P0 128 900 8.0 US-III+ 2.1 /SB08/P0 256 1050 8.0 US-III+ 2.3 : Different CPU speeds will have different tick values, therefore reporting inaccurate timing results. Example: CPU 32, the tick value is 0x9b8ef1df8dfa4 CPU 128, the tick value is 0x74ab35ed4a28b CPU 256, the tick value is 0x881d1458f0e6c
Problem conclusion
Apar first fixed in DB2 UDB Version 9.1 FixPak 6.
Temporary fix
Comments
APAR Information
APAR number
IZ13862
Reported component name
DB2 UDB ESE SOL
Reported component ID
5765F4102
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-01-24
Closed date
2008-11-03
Last modified date
2009-04-16
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
DB2 UDB ESE SOL
Fixed component ID
5765F4102
Applicable component levels
R910 PSY
UP
[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"DB2 for Linux- UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910"}]
Document Information
Modified date:
04 October 2021