| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Having an XA problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| klingelb |
 Posted: Fri Jan 03, 2003 5:07 am Post subject: Having an XA problem |
 |
|
Apprentice
Joined: 25 Sep 2002
Posts: 28
|
Having an XA Problem:
exhibit A
Software Stack:
AIX 5.1
DB2 7.2 with FP7
MQSeries 5.2 with CSD04
WMQI 2.1 with CSD03
exhibit B
qm.ini file for my QM:
#*******************************************************************#
#* Module Name: qm.ini *#
#* Type : MQSeries queue manager configuration file *#
# Function : Define the configuration of a single queue manager *#
#* *#
#*******************************************************************#
#* Notes : *#
#* 1) This file defines the configuration of the queue manager *#
#* *#
#*******************************************************************#
ExitPath:
ExitsDefaultPath=/var/mqm/exits/
#* *#
#* *#
Log:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=8192
LogType=CIRCULAR
LogBufferPages=17
LogPath=/var/mqm/log/DNIMQM1/
LogWriteIntegrity=TripleWrite
Service:
Name=AuthorizationService
EntryPoints=9
ServiceComponent:
Service=AuthorizationService
Name=MQSeries.UNIX.auth.service
Module=/usr/mqm/lib/amqzfu
ComponentDataSize=0
XAResourceManager:
Name=DB2 DNIDBRUN
SwitchFile=/usr/opt/mqsi/sample/xatm/db2swit
XAOpenString=DNIDBRUN,dniinst1,password
ThreadOfControl=PROCESS
exhibit C
system log file
Jan 3 07:08:43 ed2c WMQIv210[41154]: (DNIBRKSA)[1]BIP2001I: The WebSphere MQ Integrator service has started, process ID 20416. : DNIBRKSA.service: /build/
S210_BP/src/AdminAgent/ControlProcess/rios_aix_4/ImbControlService.cpp: 332: ImbControlService::StartNewAA: :
Jan 3 07:08:44 ed2c WMQIv210[27452]: (DNIBRKSA.SVTOU)[1]BIP2201I: Execution Group started: process '27452'; thread '1'; additional information: brokerName
'DNIBRKSA'; executionGroupUUID 'fbc39f76-f200-0000-0080-f61c755b3c94'; executionGroupLabel 'SVTOU'; defaultExecutionGroup 'true'; queueManagerName 'DNIMQM
1'; trusted 'false'; dataSourceName 'MQSIBKDB'; userId 'denali1'; migrationNeeded 'false'; brokerUUID '59cf8476-f200-0000-0080-f61c755b3c94'; filePath '/us
r/opt/wmqi'; workPath '/var/wmqi'. : DNIBRKSA.fbc39f76-f200-0000-0080-f61c755b3c94: /build/S210_BP/src/DataFlowEngine/ImbMain.cpp: 215: main: :
Jan 3 07:08:48 ed2c WMQIv210[33930]: (DNIBRKSA.SYSOU)[1]BIP2201I: Execution Group started: process '33930'; thread '1'; additional information: brokerName
'DNIBRKSA'; executionGroupUUID '66ad9f76-f200-0000-0080-f61c755b3c94'; executionGroupLabel 'SYSOU'; defaultExecutionGroup 'false'; queueManagerName 'DNIMQ
M1'; trusted 'false'; dataSourceName 'MQSIBKDB'; userId 'denali1'; migrationNeeded 'false'; brokerUUID '59cf8476-f200-0000-0080-f61c755b3c94'; filePath '/u
sr/opt/wmqi'; workPath '/var/wmqi'. : DNIBRKSA.66ad9f76-f200-0000-0080-f61c755b3c94: /build/S210_BP/src/DataFlowEngine/ImbMain.cpp: 215: main: :
Jan 3 07:08:49 ed2c WMQIv210[27452]: (DNIBRKSA.SVTOU)[3599]BIP2633W: Warning when starting transaction coordinated by MQSeries; MQBEGIN failed: MQCC=1; MQ
RC=2122; node 'SVT_IMWH.MWH_INSERT_Q'. : DNIBRKSA.fbc39f76-f200-0000-0080-f61c755b3c94: /build/S210_BP/src/DataFlowEngine/ImbMqInputNode.cpp: 778: ImbMqInp
utNode::readQueue: ComIbmMQInputNode: 39bffc45-f100-0000-0080-bf81414a0e25
Jan 3 07:08:49 ed2c WMQIv210[27452]: (DNIBRKSA.SVTOU)[2571]BIP2633W: Warning when starting transaction coordinated by MQSeries; MQBEGIN failed: MQCC=1; MQ
RC=2122; node 'SVT_UMWH.MWH_UPDATE_Q'. : DNIBRKSA.fbc39f76-f200-0000-0080-f61c755b3c94: /build/S210_BP/src/DataFlowEngine/ImbMqInputNode.cpp: 778: ImbMqInp
utNode::readQueue: ComIbmMQInputNode: 39bffc45-f100-0000-0080-bf81414a0e25
Jan 3 07:09:01 ed2c WMQIv210[33930]: (DNIBRKSA.SYSOU)[3856]BIP2633W: Warning when starting transaction coordinated by MQSeries; MQBEGIN failed: MQCC=1; MQ
RC=2122; node 'DNI_SECADM_2510.DniSecAdm.DniAdminIn'. : DNIBRKSA.66ad9f76-f200-0000-0080-f61c755b3c94: /build/S210_BP/src/DataFlowEngine/ImbMqInputNode.cpp
: 778: ImbMqInputNode::readQueue: ComIbmMQInputNode: bf6df856-ef00-0000-0080-d7c0e81f7d38.4622aa91-ea00-0000-0080-ea202f1a5000
Jan 3 07:09:01 ed2c WMQIv210[33930]: (DNIBRKSA.SYSOU)[4113]BIP2633W: Warning when starting transaction coordinated by MQSeries; MQBEGIN failed: MQCC=1; MQ
RC=2122; node 'DNI_SYSADM_2510.DniAdminIn'. : DNIBRKSA.66ad9f76-f200-0000-0080-f61c755b3c94: /build/S210_BP/src/DataFlowEngine/ImbMqInputNode.cpp: 778: Imb
MqInputNode::readQueue: ComIbmMQInputNode: 4622aa91-ea00-0000-0080-ea202f1a5000
My broker is running on AIX and I had successfully deployed my flows with the Property "Coordinated Transaction" turned ON.
I then increased the size of my db2 transaction log files and forgot to stop my broker and queue manager before issueing
a db2stop force and a db2start command so that the log file change would take effect. Ever since that point if I deploy
with the "Coordinated Transaction" property turned ON I get MQBEGIN failed. I have two db2 instances dniinst1 and denali1.
the broker service id and MQSIBKDB are under the denali1 db2 instance. The DNIRUNDB and DNICUSDB are under the dniinst1 db2
instance. I have tried everything from stopping the broker, qm, and all db2 instances to shutting down the AIX machine and
starting back up. Nothing seems to make the MQRC 2122 error go away. MQRC 2122 means MQRC_PARTICIPANT_NOT_AVAILABLE which
when I looked up in the MQSeries Administration Guide it said that usually this problem resolves itself or alternatively you
can run the rsvmqtrn command to explicitly resolve all in-doubt unit of work(Chapter 11 page 154). Well I tried this too and
it did not work. I can still deploy my flows WITHOUT the "Coordinated Transaction" property turned ON and it works fine.
Moreover, the fact that it was working until I interrupted it with the db2stop force means that the software levels should be
fine. There must be a way to recover from this, short of recreating everything. I have tried restarting all components multiple
times and it yielded nothing. Please Advise. |
|
| Back to top |
|
 |
| clindsey |
| Posted: Fri Jan 03, 2003 6:40 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
Take a look at the db2diag.log for the failing instance and see what the exact DB2 error is. This should help.
Some of the more common things that cause this is an invalid password for the user or that db2profile has not been run for the user starting the queue manager.
Charlie |
|
| Back to top |
|
|
| klingelb |
| Posted: Fri Jan 03, 2003 6:50 am Post subject: |
|
|
Apprentice
Joined: 25 Sep 2002
Posts: 28
|
my db2diag.log for dniinst1 db2 instance reads as follows:
2003-01-03-06.55.50.469209 Instance:dniinst1 Node:000
PID:34984(db2spmrm) Appid:none
oper_system_services sqloopenp Probe:36
errno: 0000 0011 ....
i verified that the user password is valid in the XA stanza of the qm.ini file and the db2profile is in the .profile of the user that starts the qm.
my db2diag.log for denali1 db2 instance reads as follows:
2003-01-03-07.09.17.631169 Instance:denali1 Node:000
PID:27452(DataFlowEngine) Appid:
oper_system_services sqlocshr2 Probe:200
pSetHdl 303b 8000 303b 8000 0001 0000 039a 0011 0;..0;..........
0004 0000 ....
2003-01-03-07.09.17.768750 Instance:denali1 Node:000
PID:27452(DataFlowEngine) Appid:
XA DTP Support sqlxa_open Probe:101
DIA4701E Database "DNIDBRUN" could not be opened for distributed transaction
processing.
String Title: XA Interface SQLCA PID:27452 Node:000
SQLCODE = -1224
String Title: XA Interface SQLCA PID:33930 Node:000
SQLCODE = -4917 TOKEN 1: SQL_CONNECT_TYPE value |
|
| Back to top |
|
|
| leongor |
| Posted: Sun Jan 05, 2003 1:03 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
Please, see below the general description of your problem.
My guess, you reached the limit of memory segments.
It's AIX known problem.
The solution we use with DB2 - working via TCP/IP node instead of local bindings.
| Quote: |
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.
Explanation: The message may be attributed to any of the following cases.
The database manager has not been started on the database server
The database manager was stopped
The database manager has already allocated the maximum number of agents
The database agent was forced off by the system administrator
The database agent was terminated due to an abnormal termination of a key database manager process
The application is using multiple contexts with local protocol. In this case the number of connections is limited by the number of shared memory segments to which a single process can be attached. For example, on AIX, the limit is ten shared memory segments per process.
Additional federated server cases are:
The maximum number of processes per user (maxuproc on AIX) at the operating system level has been exceeded.
In the client/server environment using the TCP/IP protocol, the port number assigned to the TCP/IP service name on the client is not the same as the port number on the server.
This situation can be detected by federated server or by the data source.
User Response: Reissue the database request. If a connection cannot be established, then ensure that the database manager has been started successfully. Additionally, ensure that the maxagents database manager configuration parameter is appropriately configured.
Federated system users, should also:
Isolate the problem to the data source rejecting the request (see the Troubleshooting Guide for procedures to follow to identify the failing data source) and ensure that the communication subsystem is active and that the database manager and required communication protocol server processes have been started on the database server.
For AIX operating systems, check the setting of maxuproc and change it if needed. maxuproc restricts the number of processes that can run under a given federated server. The default setting is 40.
You can check the current setting of maxuproc with the command:
.
lsattr -E -l sys0
To view the number of processes currently running under a given federated server, use the command:
ps -ef | grep instdj1 | wc -l
where "instdj1" is the instance name of the federated server.
To change maxuproc, use the command:
chdev -l sys0 -a maxuproc='nn'
where nn is the new integer value of maxuproc.
If the application is using multiple contexts with local protocol, then either reduce the number of connections in the application, or switch to another protocol (for example, TCP/IP). For users on AIX version 4.2.1 or newer, the environment variable EXTSHM can be set to ON to increase the number of shared memory segments to which a single process can be attached.
sqlcode: -1224
sqlstate: 55032
|
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| klingelb |
| Posted: Mon Jan 06, 2003 6:58 am Post subject: |
|
|
Apprentice
Joined: 25 Sep 2002
Posts: 28
|
| The wierd thing is that I had EXTSHM=ON and DB2ENVLIST=EXTSHM before I start the dbm. |
|
| Back to top |
|
|
| leongor |
| Posted: Mon Jan 06, 2003 11:40 pm Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
I think only starting from ver. 5.3 MQSeries can work with EXTSHM=ON.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| 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
|
|
|
|
