| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SQLState=55032 |
« View previous topic :: View next topic » |
| Author |
Message
|
| Nyusser |
 Posted: Mon Jul 22, 2002 2:26 am Post subject: SQLState=55032 |
 |
|
Apprentice
Joined: 02 Jul 2002
Posts: 48
|
Hi,
I have a message flow on AIX (WMQI2.1 CSD2) which works fine most of the time, but sometimes the following error message is generated into the log:
[IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032.
A forced deploy is needed to recover. Have someone encountered (and overcome) same problem? Why is this happening? |
|
| Back to top |
|
 |
| kirani |
| Posted: Mon Jul 22, 2002 6:40 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
What version of MQSeries and DB2 are you using? what CSD/fixpack are you using? Is there any db2 dump or MQSeries FDC file created during this time?
I have seen this happening on our Development server while testing 2 phase commit. The number of connections to the database were getting released after transaction rollback. Pl check the values set for maxappls and avg_appls parameters for the database.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| Nyusser |
| Posted: Mon Jul 22, 2002 9:40 pm Post subject: |
|
|
Apprentice
Joined: 02 Jul 2002
Posts: 48
|
MQSeries version is 5.2.0.3 and DB2 version is 7.1.0.0, MAXAPPLS = 40 and AVG_APPLS = 1.
There seems to be 2 broker connections (for two brokers) and 9 dataflowengine connections (for 19 flows) to the broker database. So plenty of room for new connections...
The unstable message flow has two braches and resepctive two output nodes. The first node has TRANSACTION MODE = NO and the second one has TRANSACTION MODE = AUTOMATIC. FLOWORDER node is used to determine the execution order. The second branch may be rolled back to the input-node in the case of error in the branch. Could this lead to 55032? |
|
| Back to top |
|
|
| Nyusser |
| Posted: Wed Jul 24, 2002 8:46 pm Post subject: |
|
|
Apprentice
Joined: 02 Jul 2002
Posts: 48
|
I tried changing the flow (Transaction Mode = automatic for both), but that didn't help. In fact, it seems that the flow to be corrupted is arbitrary and can change after Forced deploy (or restart). Three different flows have so far reported the SQLSTATE 55032 (only one of them at the time) and only Forced deploy or restarting the brokers seems to correct the situation for a while.
A typical scenario:
1. After forced deploy I have nine connections to the broker database (two of them for two brokers).
2. I send two messages for two different flows successfully and after that there are twelve connections (two for brokers).
3. Third message into third message flow causes SQLSTATE 55032, no new connections
4. Fourth message into fourth message flow successfully, thirteen connections.
5. Fifth message into fifth message flow successfully, fourteen connections.
6. Several new messages to the failed third message flow -> SQLSTATE 55032 for all, no new connections.
7. Restart both brokers. Four connections to the db after restart (two for brokers, two for data flow engines).
8. A test message into third (= previously failing) message flow successfully -> seven connections.
9. A sequence of new messages to different flows cause an arbitrary flow to crash.
What can cause this kind of peculiar behavior? |
|
| Back to top |
|
|
| bolek |
| Posted: Thu Jul 25, 2002 2:00 am Post subject: |
|
|
Apprentice
Joined: 25 Jul 2002
Posts: 35
Location: Germany
|
it may help:
DB2 Knowledge base:
[IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032
Â
Possible cause
Â
The error return code 18 indicates that there are too many files open and therefore, no available segment registers. The application has reached AIX's limit of 10 shared memory segments per process, and so DIA9999E is generated.
SQL1224N and StaleConnectionException result as a result of DB2 not being able to obtain a new shared memory segment.
Â
Action
Â
DB2 UDB Version 7.2 (DB2 UDB Version 7.1 FixPak 3) or later
The support of EXTSHM has been added to V7.2 (V7.1 Fixpak 3). By default, AIX does not permit 32-bit applications to attach to more than 11 shared memory segments per process, of which a maximum of 10 can be used for local DB2 connections. To use EXTSHM with DB2, do the following:
In DB2 client sessions:
export EXTSHM=ON
When starting the DB2 UDB Server:
export EXTSHM=ON
db2set DB2ENVLIST=EXTSHM
db2start
On DB2 UDB EEE, also add the following lines to sqllib/db2profile:
EXTSHM=ON
export EXTSHM
The above information has been documented in the DB2 UDB Release Notes for Version 7.2 / Version V7.1 FixPak 3, page 366.
You can get it from: ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/
DB2 UDB Version 7.1 or earlier
The only way to get around the problem is to implement TCP/IP loopback. The normal way to implement the loopback requires the application be modified to connect to the new database alias and to specify the <user> and <using> parameters to perform authentication.
However, if the connection can be done using the existing datasource defination after implementing the loopback, there is no need to modify the application at all.
To implement TCP/IP loopback without having the need to change the application to connect to the new database alias using the <user> and <using> parameters, do the following:
Â
1. Set up a TCP/IP port in /etc/services if a port for remote DB2 clients has not been setup yet.
e.g.
db2cdb2inst1 50000/tcp # DB2 connection service port
Â
An existing port for remote DB2 clients may be used.
Steps (2) to (6) below require you log in as the DB2 instance owner.
Â
2. Configure the database manager to start connection manager for the TCP/IP communication
protocol. If you are not sure if this has already been done, issue the following command:
db2set db2comm
If the output does not contain the keyword "tcpip", you need to enter the following command
to update the db2comm registry variable to include "tcpip":
db2set db2comm=<existing protocol names>,tcpip
Â
The db2comm registry variable determines which protocol's connection manager will be
enabled when the database manager is started. You can set this variable for multiple
communication protocols by separating the keywords with commas. e.g.
db2set db2comm=tcpip,appc
 |
|
| Back to top |
|
|
| Nyusser |
| Posted: Fri Jul 26, 2002 2:21 am Post subject: |
|
|
Apprentice
Joined: 02 Jul 2002
Posts: 48
|
Thanks. 
- Nyusser |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
