ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » RECLOG is not moving forward even after QMGR restart

Post new topic  Reply to topic
 RECLOG is not moving forward even after QMGR restart « View previous topic :: View next topic » 
Author Message
kalam475
PostPosted: Mon Jul 25, 2022 1:21 pm    Post subject: RECLOG is not moving forward even after QMGR restart Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Mon Jul 25, 2022 1:25 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
kalam475
PostPosted: Mon Jul 25, 2022 1:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Mon Jul 25, 2022 2:42 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
kalam475
PostPosted: Mon Jul 25, 2022 3:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Mon Jul 25, 2022 3:13 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
kalam475
PostPosted: Mon Jul 25, 2022 3:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Mon Jul 25, 2022 3:49 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
kalam475
PostPosted: Mon Jul 25, 2022 4:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
Andyh
PostPosted: Tue Jul 26, 2022 9:01 am    Post subject: Reply with quote

Master

Joined: 29 Jul 2010
Posts: 237

"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
View user's profile Send private message
kalam475
PostPosted: Tue Jul 26, 2022 11:52 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » RECLOG is not moving forward even after QMGR restart
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.