Hang on archive

[richard.crosh]

Hello,

Using DB2 8.2 FP 9 - 32bit on Solaris 5.8 and a tape management tool
of Veritas, the archive hangs on occassion. The error is "shmat
failed" in the db2diag.log. Then DB2 hangs and self corrects.

This seems to occur when a backup kicks off, initiating an archive.
But only on occassion.

Our intent is to upgrade but that may take months. This should be
solved first.

Your help is appreciated.

[The Boss]

ri***********@ama-assn.org wrote:

Hello,

Using DB2 8.2 FP 9 - 32bit on Solaris 5.8 and a tape management tool
of Veritas, the archive hangs on occassion. The error is "shmat
failed" in the db2diag.log. Then DB2 hangs and self corrects.

This seems to occur when a backup kicks off, initiating an archive.
But only on occassion.

Our intent is to upgrade but that may take months. This should be
solved first.

Your help is appreciated.

First of, issues like this should be taken up with Support, imho.
Second, you really have to provide more info like exact error codes etc. to
be able to help you.
To quote from Oracle newsgroup c.d.o.s.: "Crystal balls are not being sold
here" or similar...
Be prepared Support will also ask you to gather quite some info for them to
be able to help you.

Having said that, you should have a look at this article on DevWorks:
http://www.ibm.com/developerworks/db...6qi/index.html

It discusses DB2's Memory Model extensively, with specific emphasis on
32-bit environments and the differences between various hardware platforms.
For Solaris (a platform I'm not familiar with btw) there is a section that
starts with:

<quote>
Common problems with allocating database shared memory on 32-bit Sun Solaris

Kernel parameters not configured sufficiently and failure to initialize the
database shared memory properly can lead to failures like the following:

* At database start up time (activate database or database is being
connected to for the first time) - SQL1478W, SQL1084C, hang condition
* At runtime - SQL2043N, hang condition

On Solaris systems, DB2 provides a tool called db2osconf. This tool makes
recommendations for kernel parameter values based on the size of a system.
The recommended values are high enough for a given system that they can
accommodate most reasonable workloads.

The most common kernel parameter set incorrectly is shmmax. This parameter
specifies the maximum size in bytes of a shared memory segment which can be
allocated on the system. If DB2 is configured to create a database shared
memory set which is larger than this, the request will fail. Other kernel
parameters to be aware of is shmseg and shmmni.
</quote>

It goes on describing common issues on Solaris and gives 3 examples that are
extensively analysed.
If you're lucky one of them fits your case, if not.... well, like I said:
contact Support ...

HTH

--
Jeroen

[richard.crosh]

The Boss wrote:

ri***********@ama-assn.org wrote:

Hello,

Using DB2 8.2 FP 9 - 32bit on Solaris 5.8 and a tape management tool
of Veritas, the archive hangs on occassion. The error is "shmat
failed" in the db2diag.log. Then DB2 hangs and self corrects.

This seems to occur when a backup kicks off, initiating an archive.
But only on occassion.

Our intent is to upgrade but that may take months. This should be
solved first.

Your help is appreciated.

First of, issues like this should be taken up with Support, imho.
Second, you really have to provide more info like exact error codes etc. to
be able to help you.
To quote from Oracle newsgroup c.d.o.s.: "Crystal balls are not being sold
here" or similar...
Be prepared Support will also ask you to gather quite some info for them to
be able to help you.

Having said that, you should have a look at this article on DevWorks:
http://www.ibm.com/developerworks/db...6qi/index.html

It discusses DB2's Memory Model extensively, with specific emphasis on
32-bit environments and the differences between various hardware platforms.
For Solaris (a platform I'm not familiar with btw) there is a section that
starts with:

<quote>
Common problems with allocating database shared memory on 32-bit Sun Solaris

Kernel parameters not configured sufficiently and failure to initialize the
database shared memory properly can lead to failures like the following:

* At database start up time (activate database or database is being
connected to for the first time) - SQL1478W, SQL1084C, hang condition
* At runtime - SQL2043N, hang condition

On Solaris systems, DB2 provides a tool called db2osconf. This tool makes
recommendations for kernel parameter values based on the size of a system.
The recommended values are high enough for a given system that they can
accommodate most reasonable workloads.

The most common kernel parameter set incorrectly is shmmax. This parameter
specifies the maximum size in bytes of a shared memory segment which can be
allocated on the system. If DB2 is configured to create a database shared
memory set which is larger than this, the request will fail. Other kernel
parameters to be aware of is shmseg and shmmni.
</quote>

It goes on describing common issues on Solaris and gives 3 examples that are
extensively analysed.
If you're lucky one of them fits your case, if not.... well, like I said:
contact Support ...

HTH

--
Jeroen