This document describes known Oracle Solaris issues, related to DB2® database products.
Three most recent additions.
- May 2014:
Updated Solaris 11 support statement.
- May 2012:
Added notes regarding Solaris 11 support and Branded Zones.
Added APAR details for issues with 2gb hardware pages on SPARC T4 processors.
- June 2011:
Added note regarding FASTGROUPS APARs.
For further discussion on this topic, visit this developerWorks forum thread:
General Statement Regarding Oracle Solaris 11 Support
Support for Oracle Solaris 11.1 was added as of DB2 v10.1 fixpack 4, released May 23rd, 2014. The DB2 v10.1 Information Centre does not yet reflect this change. Plans for DB2 v10.5 will be announced at a later date.
DB2 on Solaris 11 is supported on SPARC only. At this time there are no announced plans to support Solaris 11 for x64 platforms, or versions of DB2 prior to v10.1.
Known Issues with DB2 on Oracle Solaris
Sun bug ID
|NONE||DB2 fixes are required to support 2gb hardware page size on SPARC T4 processors||Solaris 10||SPARC T4 processors implement hardware support for 2gb memory pages. If this support is enabled at the operating system level, DB2 will fail to start with an error code of SQL10003.
This problem is addressed by the following APARs:
v9.5: IC81653, first fixed in fixpack 10
v9.7: IC81649, first fixed in fixpack 6
DB2 v10 is not affected by this issue.
|6692931||DB2 hang with multiple DB2 locks held and outstanding Async I/O||Solaris 10||DB2 might appear to hang waiting for disk I/O to complete. Analysis of stack traces will show significant DB2 lock contention rooted at locks held for outstanding asynchronous I/O operations. The DB2 async I/O collector thread will be blocked in the aio_waitn call.
This issue is addressed by Sun bug 6692931:
aio_waitn does not poll with timeout argument of zero sec, zero nsec
An official fix for this bug is not yet available from Oracle. An interim fix may be available through Oracle support.
|4673568||DB2 may hang or report I/O errors||Solaris 10||DB2 may hang or report I/O errors when accessing a tablespace on a UFS filesystem configured for logging but with insufficient log space.
The following Sun bug addresses this issue:
4673568 Solaris System May Hang Due to Insufficient Log Space Allocation on UFS With Logging Enabled
There is no fix available from Oracle for this issue. Care must be taken to configure enough space when using logged UFS filesystems.
|6901652||DB2 Hang||Solaris 10||DB2 or other applications may appear to hang while retrieving group information. A stack trace will show "__door_call" last the last function to be called.
This is addressed by Sun bug 6901652:
nscd could better handle running out of naming enumeration contexts.
Fixed by the following patches:
A workaround exists: setting the DB2 registry variable "FASTGROUPS" to "true" will cause DB2 to call different Solaris APIs that are are not exposed to this issue:
If this workaround is used, be aware of APAR IC73162: "WITH FASTGROUPS=TRUE, GROUP LOOKUP IS LIMITED TO 64", addressed in DB2 v9.7 fp4. The equivalent v9.5 APAR is IZ90472.
|6200096||DB2 SYSTEM CRASH||All level of Solaris||DB2 will trap on Sun SPARC T2/T2+ based hardware such as the Sun SPARC Enterprise T5120 Server or Sun SPARC Enterprise T5220 Server.
The problem is caused by a hypervisor bug in the hardware firmware. SUN's bug ID is 6200096. The fix is in Sun Firmware 7.0.3.c or later. It is recommended to install the firmware fix when running any version of DB2 on those hardwares. There is no workaround for the problem.
|6559612||DB2 report DIA8305C error.||All level of Solaris||DB2 9.5 may crash on Sun hardware that supports 256M memory pages when there are a large number of concurrent database connections.
In the db2diag.log DB2 will report "DIA8305C Memory allocation failure occurred" from the sqlbReadPage function.
Solaris bug ID 6559612 was created for this problem, which is addressed by upgraded to Solaris 10 update XX or applying the following Solaris patch;
Alternatively, DB2 9.5 Fixpack 2 contains a workaround that avoid this issue.
Sample db2diag.log entry:
|6337073||Performance degradation due to significant increase of CPU user Time.||Solaris 10 GA and Solaris 10 update 1||Performance degradation with Solaris 10 and Solaris 10 Update 1 due to significant increase in CPU User Time (up to 30%).
The problem is a result of a bug in a Page Coloring mechanism, identified in SUN's CR 6337073. This bug was fixed in the kernel patch 118833-02, though it is recommended to install Solaris 10 Update 2, which comes with kernel patch 118833-17. Another way of fixing the problem is setting consistent_coloring = 2 in /etc/system.
|6657170||DB2 load command does not complete when loading a table||Solaris 10 GA to Solaris 10 update 4.||DB2 load command does not complete when loading a table, which defined in tablespace with more than one container.
The problem caused by the msgrcv() bug, introduced in kernel patch 127111-02. SUN's bug CR 6657170 had been opened. It is recommended to uninstall the identified kernel patch. Another way of avoiding the problem is setting DISK_PARALLELISM option of DB2 load command to 1, but it may harm load performance and should only be used if uninstalling the patch 127111-02 is impossible. The problem also can fixed by install Solaris 10 Update 5 release or Solaris 10 kernel patch 127127-11.
|NONE||STMM did not honor the memory limit on Solaris zone.||Solaris 10 GA to Solaris 10 update 6.||DB2 creates instance (db2icrt) with a value for INSTANCE_MEMORY
based on the full memory of the machine and not from the dedicated zone when zone is created with capped-memory option.
SUN Microsystems fixed the problem in Solaris 10 Update 7. It has been done by virtualizing the zone memory cap through sysconf(_SC_PHYS_PAGES). There is no need to add additional code to DB2 to fix the issue - INSTANCE_MEMORY value will be correct after customers install Solaris 10 Update 7.
Known Issues with Third Party Products
- See the following technote if your Solaris systems use the Veritas filesystem (vxfs):
"Veritas File System may corrupt DB2 SMS temporary files" (1495849)
Clarification of Global vs. Local Zone Requirements
Some versions of the DB2 Information Center contain the following statement related to support for Solaris Zones:
Support is only for DB2® to be installed on local zones. Installation on the global zone is not supported by DB2 at this time.
This statement is incorrect and will be corrected in a future DB2 Information Center refresh. Specifically:
- In environments where no local zones exist, leaving only the default global zone, DB2 may be installed normally.
- In environments where one or more local zones exist, DB2 may be installed on each local zone independently.
- Potential issues exist if DB2 is installed on both the global zone and one or more local zones. These issues are under investigation and support for this type of configurations will be clarified in the DB2 Information Center and this document when the investigation is complete. In the meantime, questions about specific local+global zone installation scenarios may be directed to DB2 support via the PMR process.
As stated on the DB2 Virtualization Support page, Branded (non-native) Zones are not a supported environment for DB2 on Solaris. This limitation applies to both SPARC and x64 systems.
For further discussion on this topic, visit this developerWorks forum thread:
Installation requirements for DB2 Version 9.1 (Solaris)
Installation requirements for DB2 Version 9.5 (Solaris)
Installation requirements for DB2 Version 9.7 (Solaris)
Installation requirements for DB2 Version 10.1 (Solaris
Known issues for DB2 on AIX
Known issues for DB2 on HP-UX
|Information Management||DB2 Connect||Solaris||9.7, 9.5, 9.1, 10.1|