Known issues for DB2 on AIX 5.2, 5.3, and 6.1

• Oct 26, 2009
  • Added information about AIX 5.3 TL11, AIX 6.1 TL03, AIX 6.1 TL04 to minimum recommended maintenance levels
• June 19, 2009
  • Added recommended minimum maintenance for DB2 9.7
• June 8, 2009
  • Information about DB2 Version 8.2, AIX 4.3.3 and AIX 5.1 has been moved to http://www.ibm.com/support/docview.wss?&uid=swg21224762
• May 19, 2009
  • Added information about AIX 5.3 TL10 to minimum recommended maintenance
• Nov 25, 2008
  • Added information about AIX 6.1 TL02 to minimum recommended maintenance
• Nov 17, 2008
  • Added AIX 5.3 APARs IZ22292/IZ22212 , AIX 6.1 APAR IZ22211
  • Increased the AIX 5.3 minimum recommended maintenance for DB2 Version 9.1 to TL08 SP2
  • Increased the AIX 6.1 minimum recommended maintenance for DB2 Version 9.1 to TL01 SP2
  • Increased the AIX 5.3 minimum recommended maintenance for DB2 Version 9.5 to TL08 SP2
  • Increased the AIX 6.1 minimum recommended maintenance for DB2 9.5 Version to TL01 SP2
  • Added information about AIX 5.3 TL09 to minimum recommended maintenance.

AIX version	Recommended minimum AIX maintenance
6.1	TL02 DB2 9.7 requires a C++ runtime level of xlC.rte 9.0.0.8 and xlC.aix61.rte 9.0.0.8 If upgrading to TL03, no additional APARs are required If upgrading to TL04, no additional APARs are required
5.3	TL09 64-bit AIX kernel is required DB2 9.7 requires a C++ runtime level of xlC.rte 9.0.0.8 and xlC.aix50.rte 9.0.0.8 If upgrading to TL10, no additional APARs are required If upgrading to TL11, no additional APARs are required

AIX version	Recommended minimum AIX maintenance
6.1	TL01 Service Pack 2 64-bit AIX kernel is required DB2 9.5 requires a C++ runtime level of xlC.rte 9.0.0.1 and xlC.aix61.rte 9.0.0.1 If upgrading to TL02, no additional APARs are required If upgrading to TL03, no additional APARs are required If upgrading to TL04, no additional APARs are required
5.3	TL08 Service Pack 2 64-bit AIX kernel is required DB2 9.5 requires a C++ runtime level of xlC.rte 9.0.0.1 and xlC.aix50.rte 9.0.0.1 If upgrading to TL09, no additional APARs are required If upgrading to TL10, no additional APARs are required If upgrading to TL11, no additional APARs are required

AIX version	Recommended minimum AIX maintenance
6.1	TL01 Service Pack 2 64-bit AIX kernel is required DB2 Version 9.1 requires a C++ runtime level of xlC.rte 9.0.0.0 and xlC.aix61.rte 9.0.0.0 If upgrading to TL02, no additional APARs are required If upgrading to TL03, no additional APARs are required If upgrading to TL04, no additional APARs are required
5.3	TL08 Service Pack 2 64-bit AIX kernel is required Prior to Fix Pack 4, DB2 Version 9.1 requires a C++ runtime level of xlC.rte 8.0.0.4 and xlC.aix50.rte 8.0.0.4 DB2 Version 9.1 Fix Pack 4 and higher requires a C++ runtime level of xlC.rte 8.0.0.6 and xlC.aix50.rte 8.0.0.6 If upgrading to TL09, no additional APARs are required If upgrading to TL10, no additional APARs are required If upgrading to TL11, no additional APARs are required
5.2	TL08 Service Pack 2 64-bit kernel is required Prior to Fix Pack 4, DB2 Version 9.1 requires a C++ runtime level of xlC.rte 8.0.0.4 and xlC.aix50.rte 8.0.0.4 DB2 Version 9.1 Fix Pack 4 and higher requires a C++ runtime level of xlC.rte 8.0.0.6 and xlC.aix50.rte 8.0.0.6 TL09 is not a recommended level due to AIX APAR IY98056 If upgrading to TL10, it is recommended to apply AIX APAR IY98056

• The AIX APARs listed in the tables below may not be DB2 version-specific (that is, they may apply to all in-service versions of DB2).
• If they are specific to a DB2 version, or if they are needed to support a certain DB2 function, they are marked as such in the comments.
• The ML / TL column indicates the Maintenance Level containing the APAR if one exists . "N/A" means that the APAR is not yet available in regular maintenance . Check the AIX Fix Distribution site at http://www.ibm.com/eserver/support/fixes/fixcentral/main/pseries/aix to see if an ifix is available , or contact AIX for further information . With the new AIX maintenance strategy, the listed level will include Release, Technical 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 of 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 Technical Level.

AIX 6.1 APARs for DB2 fixed after GA

APAR#	AIX APAR Description	ML/TL	Comments
IZ09600 IZ12763	SOME TEST CASES MENTIONED BELOW ARE FAILING IN DST.P.1	6100-00-02 6100-01-00	After upgrading a system to AIX 5.3 TL07, AIX 5.3 TL07 SP1, AIX 6.1 GA, or AIX 6.1 GA SP1, the system may report incorrect times for a given timezone. This impacts DB2 operations where times are reported in a local time zone, for example db2 values (CURRENT TIMESTAMP). Systems with any of the following AIX fileset levels are vulnerable : bos.rte.libc 5.3.7.0, 5.3.7.1, 6.1.0.0, or 6.1.0.1.
IZ13230 IZ06884	APP MAY CRASH IF LIBNSL.A IS LOADED AND UNLOADED REPEATEDLY	6100-00-03 6100-01-00	In environments where DB2 logs are archived to TSM, the DB2 command PRUNE HISTORY ... AND DELETE may trigger multiple calls to TSM, resulting in repeatedly loading/unloading the library libnsl.a. If enough calls are made, (for example, DB2 makes calls to delete a large number of logs), DB2 may crash due to the problem documented in this APAR. The suggested workaround is to avoid using the AND DELETE clause and delete logs manually through TSM.
IZ10179	MEMORY LEAK WITH GETGRSET ROUTINE WITH NIS SETUP	6100-01-00	Various memory usage issues, out of memory errors, or crashes in DB2 may be encountered due to this memory leak. Note that one secondary symptom of this problem is a trap in the NIS function yp_all(), which is addressed in AIX APAR IY98802.
IZ17835	PAGING OUT TO PGSPACE OF MEDIUM PAGES	6100-01-00	This problem affects systems running DB2 Version 9.1 or higher, 64-bit AIX TL05 or higher, and p5+ hardware or higher. In addition, the DB2 shared memory requirements must be volatile. With lru_file_repage=0 (see vmo -a), and numperm > minperm (see vmstat -v), there is an expectation that computational memory will not get paged out when there is a demand for memory. When there are volatile demands for 64K/medium pages, this may not always be the case. The symptom is that paging space usage may increase over time as different areas of DB2's shared memory are paged out. Note that as of DB2 Version 9.1, DB2 uses medium pages for shared memory on AIX when available. A workaorund exists to disable the use of 64K pages by DB2 using the command: db2set DB2_MEDIUM_PAGE_SUPPORT=OFF DB2 Version 9.5 also uses medium pages for private memory. In this case, the recommended workaround is to disable 64K pages at the AIX level. These steps require a reboot : vmo -r -o vmm_mpsize_support=0
IZ22211 IZ22571	INCONSISTENT SYSTEM TIME VALUES RELATED TO CHANGES TO AND FROM DAYLIGHT SAVINGS TIME	6100-01-01 6100-02-00	This HIPER APAR supercedes IZ11729/IZ09392/IZ12763, as incorrect timestamps (1 hour off) were observed going to and from Daylight Savings Time . Systems with any of the following AIX fileset levels are vulnerable : bos.rte.libc 5.3.7.2-4, 5.3.8.0-1, 6.1.1.0

APAR#	AIX APAR Description	ML/TL	Comments
IZ22292 IZ22212 IZ22646	INCONSISTENT SYSTEM TIME VALUES RELATED TO CHANGES TO AND FROM DAYLIGHT SAVINGS TIME	5300-07-04 5300-08-02 5300-09-00	This HIPER APAR supercedes IZ11729/IZ09392/IZ12763, as incorrect timestamps (1 hour off) were observed going to and from Daylight Savings Time . Systems with any of the following AIX fileset levels are vulnerable : bos.rte.libc 5.3.7.2-4, 5.3.8.0-1, 6.1.1.0

APAR#	AIX APAR Description	ML / TL	Comments
IY79272	SYSTEM CRASH	5200-09-00	This AIX APAR may result in an AIX system crash when using DB2 on the 32-bit AIX kernel. 32-bit DB2 UDB fenced mode processes ( db2fmp , db2hmon ) use the AIX 32-bit Large Memory Model and are therefore vulnerable to triggering the AIX crash. Note that the db2hmon runs on DB2 UDB Version 8.2 even when Health Monitor is not enabled . The following AIX levels are vulnerable : 5.2 TL08 SP2 (bos.up/mp/mp64 5.2.0.87).
IY89387	AIX STOPS RESPONDING TO KEEPALIVES	5200-09-03	This problem causes inactive TCP/IP connections from a DB2 UDB on AIX server to be dropped, resulting in various symptoms (SQL1224N, SQL30081N rc=32, SQL30108N in a DB2 UDB HADR environment). AIX systems with bos.net.tcp.client 5.2.0.95-97 or 5.3.0.50-52 are vulnerable.
IY97129	PASSWDEXPIRED ROUTINE LEAKS MEMORY ON AIX 5.2 FOR FAILURE CASE	5200-10-00	When the SYSADM_GROUP is not defined in the database manager configuration file, DB2 snapshot monitor requests will end up calling the AIX passwdexpired() as a non-root user as part of some authentication checking. This will trigger the memory leak described in this APAR. It can cause various excessive memory usage symptoms in a DB2 process, including crashes. If a system is vulnerable to this problem, it is recommended to explicitly set sysadm_group to the group of the instance owner ID or apply this APAR.
IY85298	35 SECOND DELAY IN AUTHENTICATION ON NIS CLIENT	5200-10-00	On systems using NIS authentication, if the ypbind process is restarted, DB2 may experience authentication delays due to this problem, which can cause connection slowdowns as well as other secondary effects. It can be verified on a system that the DB2 performance issues began at the same time the ypbind process was started using the ps command.
IY98056	DB2 COREDUMPS IN ULOAD() ON 5.2.0.99 / 5.3.0.60	5200-10-02	This problem causes DB2 to crash from a trap in the AIX uload() routine when loading or unloading libraries. The following AIX levels are vulnerable : 5.2 TL09/TL10 (bos.up/mp/mp64 5.2.0.95-105) and 5.3 TL06 (bos.mp/mp64 5.3.0.60-61). While the AIX APAR description states that TL05 is also vulnerable, the problem has not been seen in DB2 on TL05 kernel levels.
IZ04757	APP MAY CRASH IF LIBNSL.A IS LOADED AND UNLOADED REPEATEDLY	5200-10-05	In environments where DB2 logs are archived to TSM, the DB2 command PRUNE HISTORY ... AND DELETE may trigger multiple calls to TSM, resulting in repeatedly loading and unloading the library libnsl.a. If enough calls are made, (for example, DB2 makes calls to delete a large number of logs), DB2 may crash due to the problem documented in this APAR. The suggested workaround is to avoid using the AND DELETE clause and delete logs manually through TSM.

Issue	Comments
Using EXTSHM with DB2 on AIX may cause performance degradation	Refer to the following technote for details: Using EXTSHM with DB2 on AIX may cause performance degradation
DB2 password checking daemons are vulnerable to various AIX authentication APARs	Refer to the following technote: DB2 password checking daemons are vulnerable to various AIX authentication APARs on AIX 5.3 (1242877)
Does DB2 change the instance ID's resource limits ?	Yes. The data limit is set to 491519 (512-byte units) to avoid heap or stack collisions (memory overwrites), which is close to the practical limit for 32-bit DB2 on AIX and a reasonable starting point for 64-bit DB2 on AIX. The default is 128MB. Some users would set this to unlimited to increase the limit, which is ill-advised on 32-bit AIX. The stack limit is set to 32767 (512-byte units) for completeness. See the following technote: Setting the user data limit for DB2 on AIX (1175377) The file limit is set to unlimited to avoid unnecessary "file too big" errors .  The default is 1GB . The core limit is set to unlimited in order to get good diagnostic data on first failure in a DB2 crash or trap scenario . The default is 1MB, which is insufficient when diagnosing problems involving a trap . The rss limit is set to unlimited. This is not really necessary since the limit is ineffective, but it does avoid an additional possibility to consider when DB2 is reporting out of memory errors.
Installation of DB2 9 Fix Packs 1 or 2 on an AIX "CSP" service pack fails with "test: 0402-017 Specify a parameter with this command"	Refer to the following technote: DB2 Version 9 Fix Pack 2 install fails on AIX 5.3 TL 4 ... (1259943)
File descriptor leak using VAS (Vintela Authentication Services) with AIX 5.3 TL06	A leak of file descriptors allocated by VAS (Vintela Authentication Services) has been observed in systems after upgrading to AIX 5.3 TL06. Various symptoms are possible including: growing memory usage in DB2 processes AIX APAR IZ06123 - a vulnerability exposed by the leak which causes an AIX system crash DB2 APAR IZ04039 - a vulnerability exposed by the leak which causes memory corruption in DB2, resulting in an instance crash. 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 DB2 is configured to archive logs to TSM in an HA environment, a memory leak may 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 may 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 pth_mutex._mutex_lock lock__11LibDescLockFv terminateAndUnload() dlclose unload__11OSSHLibraryFv sqlexPluginUnload__Fib sqlexAppLibTerm__Fb sqloAppLibTerm mod_fini1 modfini __modfini exit
DB2/TSM environments prior to DB2 9.1 Fix Pack 3 may hang after upgrade to AIX 5.3 TL06	AIX APAR IY87862, fixed in AIX 5.3 TL06, corrects some behaviour in the inheritance of pthreads scheduling attributes. This causes TSM threads running in DB2 backup or archiving processes to run in "process" scope instead of "system" scope. The result is that some inter-process communication within DB2 may be sent to the wrong thread in the DB2 process which invoked TSM, and DB2 may hang. DB2 has implemented a fix to ensure all threads run in system scope. This is available in APAR IZ01069 (DB2 9.1 Fix Pack 3). A workaround, which is similar to the fix, is to implement the following, which requires recycling the DB2 instance : add "export AIXTHREAD_SCOPE=S" to the instance ID's .profile add "export AIXTHREAD_SCOPE=S" to sqllib/userprofile add "AIXTHREAD_SCOPE" to the DB2 registry variable "DB2ENVLIST": db2set DB2ENVLIST="AIXTHREAD_SCOPE"
Warnings about "aio0" device not being installed when installing DB2 on AIX 6.1	Warnings may be received at the end of installing DB2 Version 9.1 (prior to Fix Pack 4) on AIX 6.1. These include the following: ERROR:mkdev: 0514-519 The following device was not found in the customized device configuration database: name = 'aio0' These errors can be ignored as aio is not required to be configured on AIX 6.1 - the DB2 installation is successful and DB2 is able to make use of AIO.