Sun Java System Application Server Enterprise Edition 8.2 Troubleshooting Guide

Description

This problem may occur due to any of the following reasons:

Cause 1

Shared memory is not configured or the configuration is not working.

Solution 1

Follow the instructions described in the Sun Java System Application Server 8.2 Installation Guide. Remember to reboot the system after configuring shared memory settings.

Cause 2

The physical memory is not enough to satisfy the node requirements. You may see the following error message:

HADB-S-05512: Attaching shared memory segment with key <xx\> failed, 
OS status=12 OS message: Not enough space.

Solution 2

Verify that shared memory is configured and the configuration is working, as mentioned above.

For production systems, reduce the number of nodes on the host or increase the physical memory on the host.

For test/development systems, reduce the shared memory usage by setting the LogBufferSize and DataBufferPoolSize to a value lower than the default values of 48 and 200MB, respectively. The allowed minimum for these variables are 32 and 64MB, respectively.

Cause 3

The size of a shared memory segment has exceeded the allowed maximum size.

HADB-S-05510: Getting shared memory segment with key <xx\> failed, 
OS status=22. OS message: Invalid argument.

Solution 3

Verify that shared memory is configured and the configuration is working, as mentioned above.

If shared memory is configured correctly, check whether you have specified any shared memory segment size (LogBufferSize or DataBufferPoolSize) larger than the system-configured maximum value set in the operating system configuration files (shmsys:shminfo_shmmax in /etc/system on Solaris).

Cause 4

There is already a shared memory segment created with the specified identifier:

HADB-S-05515: Shared memory segment with key <segment_key\> exists already.

Solution 4

List the shared memory segments and check. The ipcs can be used to list the segments in UNIX. Windows uses memory mapped files for shared memory. HADB uses the getTempPath system call to get the system-defined temporary directory where these files, named as f_segmentid, are stored.

Check whether there is already another running database or any other program using the shared memory segment with this identifier. If so, create a database with another port base. If there are no running databases or other programs using this segment, free the segment with hadbm delete unused_database.

Check whether the segments are freed. If they are still there, remove them (use ipcrm in UNIX and delete $TMP/f_* in Windows). The file name consists of the f_ prefix followed by the segment_key translated into hexadecimal. For example, if the error message indicates that segment key 15201 still exists, the temp file would be named f_3B61.