From the manual for AIX The user data limit that is displayed when you issue the ulimit -d command is the soft user data limit. It is not necessary to set the hard user data limit for DB2. The default soft user data limit is 128 MB. This is equivalent to the value of 262,144 512-byte units as set in /etc/security/limits folder, or 131,072 KB units as displayed by the ulimit -d command. This setting limits private memory usage to about one half of what is available in the 256 MB private memory segment available for a 32-bit process on AIX.
Note: A DB2 server instance cannot make use of the Large Address Space or of very large address space AIX 32-bit memory models due to shared memory requirements. On some systems, for example those requiring large amounts of sort memory for performance, it is best to increase the user data limit to allow DB2 to allocate more than 128 MB of memory in a single process. You can set the user data memory limit to "unlimited" (a value of "-1"). This setting is not recommended for 32-bit DB2 because it allows the data region to overwrite the stack, which grows downward from the top of the 256 MB private memory segment. The result would typically be to cause the database to end abnormally. It is, however, an acceptable setting for 64-bit DB2 because the data region and stack are allocated in separate areas of the very large address space available to 64-bit AIX processes. Best Regards, _________________________________________________________ Ronald C. Delaware IBM Level 2 - IT Plus Certified Specialist – Expert IBM Corporation | Tivoli Software IBM Certified Solutions Advisor - Tivoli Storage IBM Certified Deployment Professional Butterfly Solutions Professional 916-458-5726 (Office 925-457-9221 (cell phone) email: [email protected] Storage Services Offerings From: "Sims, Richard B" <[email protected]> To: [email protected] Date: 07/08/2014 04:50 AM Subject: Re: [ADSM-L] ANS1809W-messages using shared memory communication? Sent by: "ADSM: Dist Stor Manager" <[email protected]> There can be other causes of this message, such as preemption by higher priority tasks (particularly restores, retrieves, and recalls). See what the server Activity Log contains at the time that the client encountered its error, and examine the log prior to that for resource consumption (drives, etc.) by other sessions or processes leading up to the problem for the affected backup session. If you are using disk storage pools for arriving data, insufficient sizing can result in filling and then an elevated demand for tape drive resources and thus contention and delays. I would also inspect the client logs to see if client processing got mired such that even a 60 minute Idletimeout would have been exceeded. Richard Sims
