Flashes (Alerts)
Abstract
This document describes known AIX® issues and APARs related to DB2® for Linux, UNIX, and Windows. Fixes for the AIX APARs described below can be obtained from Fix Central at
http://www.ibm.com/eserver/support/fixes/fixcentral/main/pseries/aix
Content
This document lists APARs and issues which relate to interaction between DB2 databases and the AIX operating system. It also makes recommendations on AIX technology levels in order to avoid common high impact issues. There might be additional AIX APARs that are unrelated to DB2 activity but can still impact DB2 databases. For example, certain AIX administration activity can lead to corrupted file systems that contain DB2 data. It is recommended that you consult the AIX fix distribution site at the following location to review other AIX APARs which might impact your system:
http://www.ibm.com/eserver/support/fixes/fixcentral/main/pseries/aix
Recent updates:
- Nov 24, 2023
- added AIX 7.2 APAR IJ48340 and AIX 7.3 APAR IJ47907
- Apr. 14, 2021
- Recommended levels are no longer being maintained. Please refer to minimum system requirements at https://www.ibm.com/support/pages/system-requirements-ibm-db2-linux-unix-and-windows
- Oct. 24, 2016
- added AIX 6.1 APAR IV79847
- July 14, 2016
- added runtime requirements for DB2 Version 11.1
- July 11, 2016
- added recommendations for DB2 Version 11.1
- added recommendations for AIX 7.2 on DB2 Versions 10.5 and 11.1
For further discussion on this topic, visit this developerWorks forum thread:
https://www.ibm.com/developerworks/community/forums/html/topic?id=668182c6-931f-4220-b779-1debaa3620bf
RECOMMENDED MINIMUM AIX TECHNOLOGY LEVELS:
Recommended AIX levels are no longer being maintained on this page. It is suggested to follow the minimum requirements for the most recent DB2 level on a given release at https://www.ibm.com/support/pages/system-requirements-ibm-db2-linux-unix-and-windows
The recommended minimum technology levels are minimum levels. Unless otherwise indicated, higher Technology (TL) or Service Pack (SP) levels are recommended. The prerequisite levels in the standard DB2 product documentation are the minimum levels required for support and do not change after the product becomes generally available; the recommended minimum levels presented in this document deal with issues discovered after the product became generally available. Following these recommendations can result in increased system stability and reliability.
If you are looking for the recommended levels for the IBM® InfoSphere® Balanced Warehouse™ or IBM Smart Analytics System, refer to this document: http://www.ibm.com/support/docview.wss?uid=swg21429594
Recommendations and documentation of issues specific to DB2 pureScale™ can be found at the following locations :
Recommended Software Levels and APAR fixes for the DB2 pureScale V10.5 feature on AIX
Recommended Software Levels and APAR fixes for DB2 PureScale V10.1 on AIX
The recommended minimum technology levels are minimum levels. Unless otherwise indicated, higher Technology (TL) or Service Pack (SP) levels are recommended. The prerequisite levels in the standard DB2 product documentation are the minimum levels required for support and do not change after the product becomes generally available; the recommended minimum levels presented in this document deal with issues discovered after the product became generally available. Following these recommendations can result in increased system stability and reliability.
If you are looking for the recommended levels for the IBM® InfoSphere® Balanced Warehouse™ or IBM Smart Analytics System, refer to this document: http://www.ibm.com/support/docview.wss?uid=swg21429594
Recommendations and documentation of issues specific to DB2 pureScale™ can be found at the following locations :
Recommended Software Levels and APAR fixes for the DB2 pureScale V10.5 feature on AIX
Recommended Software Levels and APAR fixes for DB2 PureScale V10.1 on AIX
Recommendations for running DB2 Version 11.1 on AIX
AIX version | Recommended minimum AIX technology levels |
7.2 |
|
7.1 |
|
Recommendations for running DB2 Version 10.5 on AIX
AIX version | Recommended minimum AIX technology levels |
7.2 |
|
7.1 |
|
6.1 |
|
Recommendations for running DB2 Version 10.1 on AIX
AIX version | Recommended minimum AIX technology levels |
7.1 |
|
6.1 |
|
Recommendations for running DB2 Version 9.7 on AIX
AIX version | Recommended minimum AIX technology levels |
7.1 |
|
6.1 |
|
5.3 | TL12 Service Pack 6 or higher
|
Recommendations for running DB2 Version 9.5 on AIX
AIX version | Recommended minimum AIX technology levels |
7.1 |
|
6.1 |
|
5.3 | TL12 Service Pack 6 or higher
|
Notes on following tables:
- The AIX APARs listed in the following tables might not be specific to any one version of DB2 for Linux, UNIX and Windows, which means they might apply to all in-service versions of the product.
- If they are specific to a DB2 version or needed to support a certain DB2 function, they are marked as such in the comments.
- The "Fixed Level" column indicates the Technology Level containing the APAR if one exists. "N/A" means that the APAR is not yet available. Check the AIX Fix Distribution site at http://www.ibm.com/eserver/support/fixes/fixcentral/main/pseries/aix to see if an interim fix is available or contact AIX for further information. With the new AIX service strategy, the listed level will include Release, Technology Level, and Service Pack. For example, 5300-04-02 is AIX 5.3, Technology Level 04, Service Pack 2. This is the same as the output from
oslevel -s
. - A "+" indicates that the fix has been made available after the indicated service level was released. It will also be contained in the next service level where applicable.
- "??" indicates that the APAR is not yet available in a service pack on the stated Technology Level.
AIX 7.3 APARs for DB2 for Linux, UNIX and Windows
APAR# | AIX APAR Description | Fixed Level | Comments |
IJ47907 | POTENTIAL UNDETECTED DATA LOSS BY USING ZLIBNX | 7300-01-03 | The zlibNX library using hardware acceleration compression on Power9/Power10 can generate incorrect compressed files that can't be uncompressed, resulting in potential undetected data loss if the original uncompressed data is no longer available. At the time of compression, there is a rare error path that will generate incorrect compressed data with no error or warning reported, and the resulting file cannot be uncompressed. This issue has been seen with DB2 compression and standard compress tools such as pigz, but can be seen with any application that uses zlibNX. See HIPER details: https://www.ibm.com/support/pages/node/7028659 |
AIX 7.2 APARs for DB2 for Linux, UNIX and Windows
APAR# | AIX APAR Description | Fixed Level | Comments |
IJ48340 | POTENTIAL UNDETECTED DATA LOSS BY USING ZLIBNX | 7200-05-07 | The zlibNX library using hardware acceleration compression on Power9/Power10 can generate incorrect compressed files that can't be uncompressed, resulting in potential undetected data loss if the original uncompressed data is no longer available. At the time of compression, there is a rare error path that will generate incorrect compressed data with no error or warning reported, and the resulting file cannot be uncompressed. This issue has been seen with DB2 compression and standard compress tools such as pigz, but can be seen with any application that uses zlibNX. See HIPER details: https://www.ibm.com/support/pages/node/7028659 |
AIX 7.1 APARs for DB2 for Linux, UNIX and Windows
APAR# | AIX APAR Description | Fixed Level | Comments |
IZ84576 | APPS USING USER TRACE HOOKS FAIL WHEN TRACE IS ENABLED | 7100-00-02 | All DB2 releases contain AIX user trace hooks as an aid to diagnosing low-level performance problems. The DB2 product might abend due to this AIX HIPER APAR if any of the following tools are used on systems running on AIX 6100-06-00/01 or AIX 7100-00-00/01 AIX: trace, tprof, perfpmr, filemon DB2: db2fodc -hang, db2fodc -perf DB2: db2service.perf1 An interim fix is available for the AIX 7.1 release at ftp://public.dhe.ibm.com/aix/efixes/iz84576. |
IZ90603 IZ96071 |
ISDIGIT CALL REFERENCING A BAD MEMORY ADDRESS | 7100-00-03 7100-01-00 |
This AIX APAR might cause the DB2 instance to crash. This is due to a trap in character checking or manipulation functions such as isdigit(), isspace(), wctomb(). |
IZ91562 IZ91842 |
64K KERNEL HEAP CAUSES PAGING WHEN RAM IS OTHERWISE AVAILABLE | 7100-00-03 7100-01-00 |
This HIPER AIX APAR affects systems running DB2 Version 9.1 or later, 64-bit AIX 6.1 or later, and p5+ hardware or higher. Performance degradation occurs due to paging and is accompanied by high CPU usage by the AIX psmd process. Please see the following technote for details : http://www.ibm.com/support/docview.wss?uid=swg21417752 |
IV14638 IV09962 |
SUPPORT FOR THREAD_UNLOCK_EXTENDED() | 7100-00-05 7100-01-02 7100-02-00 |
This AIX APAR delivers an enhancement to user mode lock implementations which may avoid specific cases of performance degradation observed when running a high OLTP workload on DB2/AIX. Systems must also be running a level of DB2 which takes advantage of this enhancement for it to be effective. DB2 version 10.1 and higher has this capability by default, however earlier DB2 levels require a specific Fix Pack and registry setting as documented in these APARs: DB2 Version 9.5 IT01204 (fix not yet available) DB2 Version 9.7 Fix Pack 6 IC79285 |
IV18483 IV15184 |
TCP RETRANSMIT PROCESSING IS VERY SLOW | 7100-01-04 7100-02-00 |
This HIPER AIX APAR addresses a problem where retransmission of TCP packets occurs only after a 64 second delay. The DB2 database might experience various performance issues due to client-server communication delays, slowdowns in inter-node communication on partitioned database environment systems, and NFS performance degradation. The vulnerable AIX levels are 6.1 TL06 SP7, 6.1 TL07 SP0-3, 7.1 TL01 SP0-3. An interim fix is available as indicated in the AIX APAR documentation. |
IV22132 IV24288 |
APPLICATION CRASHES WHEN CALLING DLCLOSE() | 7100-01-05 7100-02-00 |
This AIX APAR addresses a problem causing private memory corruption on all DB2 versions prior to DB2 Version 10.1. Only systems running AIX 6.1 TL06 SP8, TL07 SP4, or AIX 7.1 TL01 SP4 are vulnerable, with corresponding bos.rte.libc levels of 6.1.6.18, 6.1.7.15 and 7.1.1.15. The common symptoms are a DB2 server hang or crash due to malloc heap corruption, with trap file diagnostics frequently including malloc, initializeXalan, or other functions in operating system libraries. Interim fixes are available from IBM AIX support as follows: AIX 6.1 TL06 SP8 ftp://public.dhe.ibm.com/aix/efixes/iv22982 AIX 6.1 TL07 SP4 ftp://public.dhe.ibm.com/aix/efixes/iv22062 AIX 7.1 TL01 SP4 ftp://public.dhe.ibm.com/aix/efixes/iv22132 |
IV33484 IV20656 IV29837 IV32651 |
TCP CONNECTION MAY HANG - LAST FEW BYTES MAY NOT EVER BE SENT | 7100-00-09 7100-01-07 7100-02-01 7100-03-00 |
This AIX APAR addresses a rare timing problem, where TCP connections exhibiting very low latency might hang, and eventually time out. This is more likely to occur when communication is occurring over virtual Ethernet on the same machine and where large_send is enabled. The DB2 client or server threads might be seen to hang in TCP functions such as tcprecv , but can still be forced (using "force application"). TCP connections can be monitored with "netstat -Aan ". If the number of bytes is unchanging over a long period, this APAR might apply. |
IV37083 IV30075 IV33155 IV33316 |
SYSTEM CRASH IN SEMSLEEP() WHEN CREATING/DELETING SEMAPHORES | 7100-00-09 7100-01-07 7100-02-02 7100-03-00 |
This AIX APAR addresses a system crash which might be triggered by db2stop force / stopsap . It has been seen to occur when SAP and the DB2 software are running together on the same LPAR. One possible trigger of high create/delete semaphore activity is a high rate of connection attempts from the local DB2 client applications while db2stop force is in progress. |
IV54132 IV57047 IV53993 IV54215 |
MEMORY LEAK IN CRYPT CAUSING GETPWNAM_R AND CRYPT TO FAIL | 7100-01-10 7100-02-05 7100-03-03 7100-04-00 |
When using an Loadable Password Algorithm (anything other than the default DES algorithm), DB2/AIX systems may experience increased memory usage in the password authentication daemons (db2ckpwd processes). This is due to a memory leak in the AIX crypt() function. Authentication failures (SQL30082) will also occur if the memory usage in those processes hits the user data limit (128MB by default), The problem can be avoided by using the default AIX encryption method. |
IV71059 IV71930 |
PUTUSERATTR MEMORY LEAK | 7100-03-05 7100-04-00 |
On AIX 6.1 TL09 and AIX 7.1 TL03, a small memory leak will occur on each connect request within DB2's authentication daemons ( db2ckpwd processes ) as a result of calling the AIX loginsuccess() API . Memory consumption can be monitored by checking the SZ column in the output of "ps -elf" for db2ckpwd processes. Symptoms include:
A DB2 workaround exists for this problem by setting the following registry variable and recycling the DB2 instance: db2set DB2_NUM_CKPW_DAEMONS=10:FORK This results in the creation of a separately forked process to handle each connect request: This workaround may not satisfy performance requirements in all environments. Interim fixes are available from AIX at the following locations (the system must be rebooted after applying the fix): AIX 6100-09 (6.1TL09): ftp://aix.software.ibm.com/aix/ifixes/iv71849/ https://aix.software.ibm.com/aix/ifixes/iv71849/ AIX 7100-03 (7.1TL03): ftp://aix.software.ibm.com/aix/ifixes/iv71059/ https://aix.software.ibm.com/aix/ifixes/iv71059/ |
AIX 6.1 APARs for DB2 for Linux, UNIX and Windows fixed after TL06 GA
APAR# | AIX APAR Description | Fixed Level | Comments |
IZ84729 | APPS USING USER TRACE HOOKS FAIL WHEN TRACE IS ENABLED | 6100-06-02 | All DB2 releases contain AIX user trace hooks as an aid to diagnosing low-level performance problems. The DB2 software might abend due to this AIX HIPER APAR if any of the following tools are used on systems running on AIX 6100-06-00/01 or AIX 7100-00-00/01 AIX: trace, tprof, or perfpmr, filemon DB2: db2fodc -hang, db2fodc -perf DB2: db2service.perf1 An interim fix is available for the AIX 7.1 release at ftp://public.dhe.ibm.com/aix/efixes/iz84576 |
IZ92561 IZ92783 IZ87037 IZ91967 IZ91738 |
64K KERNEL HEAP CAUSES PAGING WHEN RAM IS OTHERWISE AVAILABLE | 6100-03-09 6100-04-09 6100-05-05 6100-06-04 6100-07-00 |
This HIPER AIX APAR affects systems running DB2 Version 9.1 or later, 64-bit AIX 6.1 or later, and p5+ hardware or later. Performance degradation occurs due to paging and is accompanied by high CPU usage by the AIX psmd process. See the following technote for details : http://www.ibm.com/support/docview.wss?uid=swg21417752 |
IV10811 IV10812 IV08112 |
POSSIBLE CRASH POSTING AIO/IOCP PACKET | 6100-05-08 6100-06-07 6100-07-01 |
This AIX APAR causes the system to crash under rare timing conditions when an application is using IOCP (I/O Completion Ports). The following AIX levels are vulnerable: AIX 5.1 TL12 SP5 - bos.iocp.rte 5.3.12.2 AIX 6.1 TL05 SP7 - bos.iocp.rte 6.1.5.2 AIX 6.1 TL06 SP6 - bos.iocp.rte 6.1.6.16 AIX 6.1 TL07 GA - bos.iocp.rte 6.1.7.0 DB2 Version 9.7 and higher use IOCP by default. The DB2 software's use of IOCP can be disabled with the following command: db2set DB2_USE_IOCP=OFF DB2 Version 9.5 does not use IOCP by default, so it is not vulnerable to this problem unless explicitly enabled. If IOCP has been enabled, disable by unsetting the registry variable: db2set DB2_USE_IOCP= The DB2 database must be recycled for these changes to take effect. Disabling use of IOCP in the DB2 database might result in a small performance degradation - the amount might not be significant but will vary from system to system. DB2 releases prior to Version 9.5 do not use IOCP and are not vulnerable. |
IV10954 IV10411 IV10010 IV13362 |
SUPPORT FOR THREAD_UNLOCK_EXTENDED() | 6100-05-08 6100-06-07 6100-07-02 6100-08-00 |
This AIX APAR delivers an enhancement to user mode lock implementations which may avoid specific cases of performance degradation observed when running a high OLTP workload on DB2/AIX. Systems must also be running a level of DB2 which takes advantage of this enhancement for it to be effective. DB2 version 10.1 and higher has this capability by default, however earlier DB2 levels require a specific Fix Pack and registry setting as documented in these APARs: DB2 Version 9.5 IT01204 (fix not yet available) DB2 Version 9.7 Fix Pack 6 IC79285 |
IV18483 IV14297 IV14524 |
TCP RETRANSMIT PROCESSING IS VERY SLOW | 6100-06-08 6100-07-04 6100-08-00 |
This HIPER AIX APAR addresses a problem where retransmission of TCP packets occurs only after a 64 second delay. The DB2 database might experience various performance issues due to client-server communication delays, slowdowns in inter-node communication on partitioned database environment systems, and NFS performance degradation. The vulnerable AIX levels are 6.1 TL06 SP7, 6.1 TL07 SP0-3, 7.1 TL01 SP0-3. An interim fix is available as indicated in the AIX APAR documentation. |
IV22982 IV22062 IV23254 |
APPLICATION CRASHES WHEN CALLING DLCLOSE() | 6100-06-09 6100-07-05 6100-08-00 |
This AIX APAR addresses a problem causing private memory corruption on all DB2 versions prior to DB2 Version 10.1. Only systems running AIX 6.1 TL06 SP8, TL07 SP4, or AIX 7.1 TL01 SP4 are vulnerable, with corresponding bos.rte.libc levels of 6.1.6.18, 6.1.7.15 and 7.1.1.15. The common symptoms are a DB2 server hang or crash due to malloc heap corruption, with trap file diagnostics frequently including malloc, initializeXalan, or other functions in operating system libraries. Interim fixes are available from IBM AIX support as follows: AIX 6.1 TL06 SP8 ftp://public.dhe.ibm.com/aix/efixes/iv22982 AIX 6.1 TL07 SP4 ftp://public.dhe.ibm.com/aix/efixes/iv22062 AIX 7.1 TL01 SP4 ftp://public.dhe.ibm.com/aix/efixes/iv22132 |
IV33483 IV32392 IV31959 IV32467 |
TCP CONNECTION MAY HANG - LAST FEW BYTES MAY NOT EVER BE SENT | 6100-06-11 6100-07-07 6100-08-02 6100-09-00 |
This AIX APAR addresses a rare timing problem, where TCP connections exhibiting very low latency might hang, and eventually time out. This is more likely to occur when communication is occurring over virtual Ethernet on the same machine and where large_send is enabled. The DB2 client or server threads might be seen to hang in TCP functions such as tcprecv , but can still be forced (using "force application"). TCP connections can be monitored with "netstat -Aan ". If the number of bytes is unchanging over a long period, this APAR might apply. |
IV30703 IV27680 IV32845 IV33641 |
SYSTEM CRASH IN SEMSLEEP() WHEN CREATING/DELETING SEMAPHORES | 6100-06-11 6100-07-07 6100-08-02 6100-09-00 |
This AIX APAR addresses a system crash which might be triggered by db2stop force / stopsap . It has been seen to occur when SAP and the DB2 software are running together on the same LPAR. One possible trigger of high create/delete semaphore activity is a high rate of connection attempts from the local DB2 client applications while db2stop force is in progress. |
IV53601 IV57392 IV53722 IV53722 |
MEMORY LEAK IN CRYPT CAUSING GETPWNAM_R AND CRYPT TO FAIL | 6100-07-10 6100-08-05 6100-09-03 6100-10-?? |
When using an Loadable Password Algorithm (anything other than the default DES algorithm), DB2/AIX systems may experience increased memory usage in the password authentication daemons (db2ckpwd processes). This is due to a memory leak in the AIX crypt() function. Authentication failures (SQL30082) will also occur if the memory usage in those processes hits the user data limit (128MB by default), The problem can be avoided by using the default AIX encryption method. |
IV71849 | PUTUSERATTR MEMORY LEAK | 6100-09-05 6100-10-?? |
On AIX 6.1 TL09 and AIX 7.1 TL03, a small memory leak will occur on each connect request within DB2's authentication daemons ( db2ckpwd processes ) as a result of calling the AIX loginsuccess() API . Memory consumption can be monitored by checking the SZ column in the output of "ps -elf" for db2ckpwd processes. Symptoms include:
A DB2 workaround exists for this problem by setting the following registry variable and recycling the DB2 instance: db2set DB2_NUM_CKPW_DAEMONS=10:FORK This results in the creation of a separately forked process to handle each connect request: This workaround may not satisfy performance requirements in all environments. Interim fixes are available from AIX at the following locations (the system must be rebooted after applying the fix): AIX 6100-09 (6.1TL09): ftp://aix.software.ibm.com/aix/ifixes/iv71849/ https://aix.software.ibm.com/aix/ifixes/iv71849/ AIX 7100-03 (7.1TL03): ftp://aix.software.ibm.com/aix/ifixes/iv71059/ https://aix.software.ibm.com/aix/ifixes/iv71059/ |
IV79847 | SHMAT() CAN RETURN ENOMEM EVEN THOUGH SYSTEM HAS FREE MEM | 6100 (FIN) | The default AIX 6.1 segment allocator may not reuse process address space (Effective Segment IDs) for processes with highly concurrent and volatile shared segment attachments. After a long period of process uptime, new segment allocations may fail, resulting in malloc and shmat failing with ENOMEM. Local DB2 connection attempts may fail with various errors, the most common being SQL1221 due to the inability to set up shared memory for local IPC communication. The recommendation is to upgrade to a recent level of AIX 7.1 or higher, which uses a newer segment allocator by default that is not vulnerable to this issue. Refer to the AIX APAR documentation for further details. Note that the FIN or "fixed in next" classification for the APAR means that the problem will not be fixed in the older segment allocator. |
AIX 5.3 APARs for DB2 for Linux, UNIX and Windows fixed after Technology Level 12 GA
APAR# | AIX APAR Description | Fixed Level | Comments |
IZ74749 IZ76228 |
IOCP GETMULTIPLE COMPLETIONSTATUS() NEVER RETURNS | 5300-11-05 5300-12-02 |
This AIX APAR causes the DB2 product to hang, thus performing asynchronous I/O writes in the function sqloGetMultipleCompletionStatus on AIX 6.1 TL04. On AIX 5.3 TL11, the symptom will be an AIX system crash.This is a pervasive problem - you are strongly advised to obtain the fix for the APAR if using IOCP with the DB2 product at the vulnerable AIX levels. An interim fix is available. DB2 Version 9.7 uses IOCP by default. The DB2 software's use of IOCP can be disabled with the following: db2set DB2_USE_IOCP=OFF DB2 Version 9.5 does not use IOCP by default, so DB2 Version 9.5 is not vulnerable to this problem unless explicitly enabled. If IOCP has been enabled, disable it by unsetting the registry variable: db2set DB2_USE_IOCP= The DB2 database must be recycled for these changes to take effect. Disabling use of IOCP in the DB2 database might result in a small performance degradation - the amount might not be significant but will vary from system to system. DB2 releases prior to Version 9.5 do not use IOCP and are not vulnerable. |
IV17950 | POSSIBLE CRASH POSTING AIO/IOCP PACKET | 5300-12-06 | This AIX APAR causes the system to crash under rare timing conditions when an application is using IOCP (I/O Completion Ports). The following AIX levels are vulnerable: AIX 5.1 TL12 SP5 - bos.iocp.rte 5.3.12.2 AIX 6.1 TL05 SP7 - bos.iocp.rte 6.1.5.2 AIX 6.1 TL06 SP6 - bos.iocp.rte 6.1.6.16 AIX 6.1 TL07 GA - bos.iocp.rte 6.1.7.0 DB2 Version 9.7 and higher use IOCP by default. The DB2 software's use of IOCP can be disabled with the following command: db2set DB2_USE_IOCP=OFF DB2 Version 9.5 does not use IOCP by default, so it is not vulnerable to this problem unless explicitly enabled. If IOCP has been enabled, disable by unsetting the registry variable: db2set DB2_USE_IOCP= The DB2 database must be recycled for these changes to take effect. Disabling use of IOCP in the DB2 database might result in a small performance degradation - the amount might not be significant but will vary from system to system. DB2 releases prior to Version 9.5 do not use IOCP and are not vulnerable. |
IV32615 | TCP CONNECTION MAY HANG - LAST FEW BYTES MAY NOT EVER BE SENT | 5300-12-07 | This AIX APAR addresses a rare timing problem, where TCP connections exhibiting very low latency might hang. This is more likely to occur when communication is occurring over virtual Ethernet on the same machine. Disabling large_send might work around the problem in some cases. The DB2 client or server threads might be seen to hang in TCP functions such as tcprecv , but can still be forced (using "force application"). TCP connections can be monitored with "netstat -Aan ". If the number of bytes is unchanging over a long period, this APAR might apply. |
IV37084 | SYSTEM CRASH IN SEMSLEEP() WHEN CREATING/DELETING SEMAPHORES | 5300-12-?? | This AIX APAR addresses a system crash which might be triggered by db2stop force / stopsap . It has been seen to occur when SAP and the DB2 software are running together on the same LPAR. One possible trigger of high create/delete semaphore activity is a high rate of connection attempts from the local DB2 client applications while db2stop force is in progress. |
IV54375 | MEMORY LEAK IN CRYPT CAUSING GETPWNAM_R AND CRYPT TO FAIL | 5300-12-?? | When using an Loadable Password Algorithm (anything other than the default DES algorithm), DB2/AIX systems may experience increased memory usage in the password authentication daemons (db2ckpwd processes). This is due to a memory leak in the AIX crypt() function. Authentication failures (SQL30082) will also occur if the memory usage in those processes hits the user data limit (128MB by default), The problem can be avoided by using the default AIX encryption method. |
Known issues for DB2 database products on AIX
Issue | Comments |
Using EXTSHM with the DB2 software on AIX may cause performance degradation. |
Refer to the following technote for details: Using EXTSHM with DB2 on AIX may cause performance degradation Note that AIX does not support the use of EXTSHM with 64K (medium) pages, which can improve performance and are requested by DB2 by default.. Messages may appear in the db2diag.log stating that DB2 has failed to enable 64k medium pages: FUNCTION: DB2 UDB, SQO Memory Management, sqloMemSetPageSize, probe:100 MESSAGE : ZRC=0x820F0002=-2112946174=SQLO_INV_MEM "Invalid memory addr" DIA8561C A invalid memory block was encountered. CALLED : OS, -, shmctl OSERR : EINVAL (22) "Invalid argument" DATA #1 : String, 44 bytes Failure enabling specified memory page size. DATA #2 : Logical page size, PD_TYPE_MEM_PAGE_SIZE, 8 bytes 65536 : |
File descriptor leak using Vintela Authentication Services (VAS) with AIX 5.3 TL06 | A leak of file descriptors allocated by VAS has been observed in systems after upgrading to AIX 5.3 TL06. Various symptoms are possible including:
While the root cause is still under investigation, a defensive fix which avoids the leak is available from Quest at: https://support.quest.com/SUPPORT/index?page=solution&id=SOL34944 |
HACMP APAR IZ07575/IZ08353 causes memory leak in DB2 log manager when archiving to TSM | If the DB2 database is configured to archive logs to TSM in an HA environment, a memory leak might occur in the DB2 log manager (db2logmgr ). This will cause excessive memory usage in the db2logmgr process. Eventually memory might become exhausted in the process, causing archive failures as well as a possible trap or DB2 instance crash. |
32-bit DB2 client applications might hang when they are exiting due to xlC APAR IZ09983/IZ12642 | When using version 9 of C++ (xlC) runtime, 32-bit DB2 C++ client applications might hang when they are exiting. Other symptoms include hanging or failing migration of 32-bit DB2 instances. Systems with xlC.rte fileset levels 9.0.0.0 - 9.0.0.3 are vulnerable. The problem is resolved in IZ12642, xlC.rte and xlC.aix50/61.rte 9.0.0.4 (December 2007 IBM C++ Runtime Environment Components for AIX). A sample stack of the hanging program shows : pth_spinlock._global_lock_common |
Use of unsupported password encryption methods causes hangs and unexpected errors | AIX allows additional password encryption options as of AIX 5.3 TL07 and AIX 6.1. Prior to DB2 Version 9.5 Fix Pack 4, there are restrictions on support for password lengths and encyrption options (see documentation for the appropriate release/fix pack for details). The DB2 product might hang or return unexpected errors when using an unsupported encryption option/password length combination. Symptoms include :
|
Veritas File System may corrupt DB2 SMS temporary files | See the following technote: Veritas File System may corrupt DB2 SMS termporary files (1495849) |
DB2 client applications fail with SQL30081 rc=32 or rc=73 after enabling IBM AIX TCP Traffic Regulation | DB2 client applications fail with SQL30081 rc=32 or rc=73 when communicating with a DB2 server on AIX, and IBM AIX TCP Traffic Regulation has been enabled. See the following technote: http://www.ibm.com/support/docview.wss?uid=swg21673820 |
For further discussion on this topic, visit this developerWorks forum thread:
https://www.ibm.com/developerworks/community/forums/html/topic?id=668182c6-931f-4220-b779-1debaa3620bf
Related Information
[{"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"},"ARM Category":[{"code":"a8m0z0000001gWHAAY","label":"Operating System or Hardware-\u003EOS patch"}],"Platform":[{"code":"PF002","label":"AIX"}],"Version":"All Version(s)"}]
Was this topic helpful?
Document Information
Modified date:
28 November 2023
UID
swg21165448