| Author |
Message
|
| kalam475 |
 Posted: Mon Jul 25, 2022 1:21 pm Post subject: RECLOG is not moving forward even after QMGR restart |
 |
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
I have been trying to clean up the archive logs. Apart from one qmgr the log extents are moving forward and was able to clean it up.
But for one qmgr the log extent are stuck on a particular log extent and not moving forward even after bouncing the QMGR and running the command "reset qmgr type(advancelog)".
It makes sense if there is any long running transactions are holding the extent hostage but we restarted the qmgr and it didn't have the desired effect. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jul 25, 2022 1:25 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Look for log-related error messages in the rrror log files for the particular qmgr. Post them here.
What was the response from running the command "reset qmgr type(advancelog)"?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| kalam475 |
| Posted: Mon Jul 25, 2022 1:33 pm Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
output of reset qmgr is "AMQ8649: Reset WebSphere MQ Queue Manager accepted"
after this command Current Log is moved ahead as it should but not the RECLOG.
Error logs did not write anything in particular to Log-related error or errors for that matter. No Trace of FDC as well |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Jul 25, 2022 2:42 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Issue the following MQSC command on your queue manager:-
| Code: |
| DISPLAY QMSTATUS LOG |
Look at the following three fields:-- ARCHLOG - Name of the oldest log extent for which the queue manager is waiting for archive notification.
- MEDIALOG - The name of the oldest log extent required by the queue manager to perform media recovery.
- RECLOG - The name of the oldest log extent required by the queue manager to perform restart recovery.
One of these will be showing the earliest log extent the queue manger needs (and the one that is "stuck" as you say). Whichever field is showing the oldest extent will show you what task you need to do to allow it to move forward.
If you are not sure what task to do, please post back here with the output from your DISPLAY QMSTATUS command and we can help you further.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| kalam475 |
| Posted: Mon Jul 25, 2022 3:06 pm Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
the output of "display qmstatus all" gives
CURRLOG= S0016291.LOG , RECLOG=S0016000.LOG & MEDIALOG=S0016291.LOG
as you can see the CURRLOG and MEDIALOG is moving forward and RECLOG is still stuck back.
Since RECLOG is used for successful restart of QMGR, after restart doesn't it be closer to CURRLOG so I can move the old linear log to my tape drive. |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Jul 25, 2022 3:13 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Do you see any AMQ7nnn messages in your queue manager error log, for example, are there any AMQ7466 messages?
Also, you said that you did a restart of the queue manager. Can you show the AMQ72nn messages that are written as it goes through restart and recovery. Are there any problems reported at that time?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| kalam475 |
| Posted: Mon Jul 25, 2022 3:39 pm Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
there are no AMQ7466 in the log file. But what can I find are
AMQ7229: 15 log records accessed on queue manager 'qmgr1' during the log
replay phase
AMQ7230: Log replay for queue manager 'qmgr1' complete.
AMQ7231: 2 log records accessed on queue manager 'qmgr1' during the recovery
phase.
AMQ7232: Transaction manager state recovered for queue manager 'qmgr1'
AMQ7467: The oldest log file required to start queue manager qmgr1 is
S0016000.LOG
AMQ7468: The oldest log file required to perform media recovery of queue
manager qmgr1 is S0016291.LOG |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Jul 25, 2022 3:49 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Presumably the transaction that is "holding the extent hostage" must be a prepared global transaction if a clean restart of the queue manager didn't resolve things.
Have you run dspmqtrn ?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| kalam475 |
| Posted: Mon Jul 25, 2022 4:09 pm Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
./dspmqtrn -m qmgr1 -e
AMQ7056: Transaction number 0,1 is in-doubt.
XID: formatID 1463898948, gtrid_length 36, bqual_length 54
gtrid [00000181F677C5E10000012659D5C6AC8187ABA938ADD0D8F0277EA8EA29DDBB6515231A]
bqual [00000181F677C5E10000012659D5C6AC8187ABA938ADD0D8F0277EA8EA29DDBB6515231A000000010000000000000000000000000003]
./dspmqtrn -m qmgr1 -i
There are no matching prepared or heuristically completed transactions.
/dspmqtrn -m qmgr1 -h
There are no matching prepared or heuristically completed transactions. |
|
| Back to top |
|
|
| Andyh |
| Posted: Tue Jul 26, 2022 9:01 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
"XID: formatID 1463898948"
463898948 is 0x57415344
0x57415344 is "WASD" and hence this looks like a WebSphere application server transaction in a prepared state. When the same instance of the application server next opens an XA session with MQ it should resolve this transaction.
As the head of the log isn't moving forwards I'd guess that you've probably defined a large active log. When the active log nears capacity any indoubt transaction will be rolled forwards in the log (the necessary log records will be re-written to a new log extent). Is there a good reason why you've defined a large active recovery log ? Giving MQ a large log is like saying "I'm happy for the queue manager to use that much disk space for active log records" and hence the queue manager isn't trying to reduce the size of the active log and has no need to move the head of the log forward as a result of the advance log command (that command is intended to move the tail of the log into a new extent such that the last extent is no longer being written to and can then safely be archived).
In a recent release (possibly 9.2, perhaps someone still emplyed by IBM can confirm?) I changed the queue manager to try harder to keep the log within the primary allocation of log space. Prior to that change a long lived indoubt transaction would result in both primary and secondary log space being used before that transaction would be rolled forwards in the log. |
|
| Back to top |
|
|
| kalam475 |
| Posted: Tue Jul 26, 2022 11:52 am Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
Totally agree with you Andyh it was a WAS transaction which was holding the log extent. But even after the WAS was making transactions with QMGR it was not clearing the uncommitted message in queue.
Had to resort to rsvmqtrn -m qmgr1 -c 0,1 to commit the message.
Once we run the command there were no uncommitted transactions and uncommitted count in display qs().
Log extent got released and the REC Log is now in line with the current log and made a way to clean the unnecessary old log files.
This forum never disappoints you. You learn new things everyday. |
|
| Back to top |
|
|
|
|
