| Author |
Message
|
| dextermbmq |
 Posted: Mon Mar 21, 2016 4:30 am Post subject: LOG SEQUENCE NO. NOT INCREASING AFTER RCDMQIMG |
 |
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
Hello All,
I am trying to archive the Linear logs using rcdmqimg command. However there is no change in the oldest log required :
to restart the qm
to refer for media recovery
before and after issuing this command. I used the below commands
rcdmqimg -m QMGR -l -t all \*
rcdmqimg -m QMGR -l -t syncfile \*
However i can see the same LOG file in following command output :
dis qmstatus reclog medialog
which was there befroe issuing rcdmqimg.
There are no errros htrown when i gave the rcdmqimg command , no errors/info in the QM Error logs and FDC files.
The QMGR ERRRO LOGS also show the same old log files required for QMGR restart and media recovery
Not sure what am I missing here ? 
Any help would be appreciated
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Mar 21, 2016 4:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
rcdmqimg will write a checkpoint into the log file. It will not make the log advance.
If you wish to advance the log see the reset qmgr command.
Depending on the number of needed logs (difference between currlog and medialog / restartlog) you may have to bounce the qmgr in order to be able to archive. This is relatively rare but has been known to happen once in a while.
This is why it may be of some advantage to allow for enough secondary log files so that you can bounce the qmgr before you run out of log space.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dextermbmq |
| Posted: Mon Mar 21, 2016 6:07 am Post subject: |
|
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 21, 2016 7:38 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
My experience says: rcdmqimg writes a new checkpoint into the current log. This may move the LSN forward... and free up old log files.
Now if there is only one log file and it is far from full... then no LSN move forward and no new log. However if you run reset qmgr type(advancelog) just before running rcdmqimg you may experience something different...
As I said, in rare cases (long running transaction usually missing a commit and long since timed out ... but still active to the qmgr), it may take a bounce of the qmgr to free up logs for archiving.
Hope it helps
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Mar 21, 2016 7:47 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
The most common reason for not being able to advance the log needed for media recovery, via rcdmqimg, is that some object is damaged.
The purpose of having a media image is to be able to recover from a damaged object, if an already damaged object was recorded in a media image then the object would only be recoverable to a damaged state, and hence the queue manager will not allow an image of a damaged object to be recorded in the log.
In most circumstances, rcrmqobj must be elected manually, the obvious exception being during QMgr restart where the QM will automatically recover any object that needs to be recovered to allow QMgr restart to complete.
Please check if you've got any damaged objects, and if so either recover or delete those objects.
There should be no need to "bounce the queue manager" in order to move the extent required for media recovery forwards.
If however an "old" log extent is required for both restart recovery, and for media recovery then that might be an indication of an issue with the checkpoint threads (part of amqzmuc0), or a very long running transaction. It would be very unusual for there to be a problem with the checkpoint threads and for no doc (e.g FDC's) to be produced.
Any long running transaction is bounded by the size of the active log (primary + secondary extents), at which point it will be rolled back to release log space.
In the unlikely event that you do have an issue with the checkpoint process
,the sooner you collect appropriate doc (have you contacted MQ support?) and bounce the queue manager the more likely you are to have a happy outcome. Running the queue manager for any significant time without a healthy set of checkpoint threads is likely to lead to a very long restart time. When the queue manager is eventually restarted it will replay everything since the last complete checkpoint. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 21, 2016 7:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Andyh, how do you go "hunting" for damaged objects?
I would expect that you'd need a diff of the dmpmqcfg output to highlight a damaged object?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Mar 21, 2016 8:44 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
1. the output of rcdmqimg -t * *
should indicate if any damaged objects were found.
2. It shouldn't be possible for a damaged object to have been detected without an FDC having been raised (although that might have since been deleted if the customer is clearing out 'old' FDC's).
3. Runmqsc dis XXX(*) should indicate if any objects of type XXX have been damaged, e.g runmqsc dis ql(*). |
|
| Back to top |
|
|
| dextermbmq |
| Posted: Mon Mar 21, 2016 11:48 am Post subject: |
|
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
Hello Andyh/fjb_saper,
Thanks for the solution. It turned out that 3 MQ Queue objects were damaged in my env. I had recovered the objects from Active logs using rcvrmqobj command and then again executed rcdmqimg. The issue got resolved. I got new LOG FILES for MEDIA and RESTART RECOVERY
 
Regards
Dexter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 21, 2016 1:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Thanks for getting back to us. Glad it works now.
I guess you looked for the damaged objects by going through the output of rcdmqimg...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| umatharani |
| Posted: Mon Mar 21, 2016 8:02 pm Post subject: |
|
|
Apprentice
Joined: 23 Oct 2008
Posts: 39
|
* You can check the FDCs or queue manager error logs for OBJECT_DAMAGE errors.
Example:
Run the ffstsummary command in /var/mqm/errors directory.
ffstsummary |grep -i damage
* It is also recommended to upgrade to 8004 as the OBJECT_DAMAGE problem might reoccur at 8002.
Thanks,
mahesh |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Mar 21, 2016 11:44 pm Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
Just to reinforce that it would be very strongly recommended to have the damaged objects fully investigated.
In this day and age it is extremely unusual for damaged objects to be caused by hardware (disk) failure. The most common causes are operator error (typically manual change to MQ files on disk) or a bug in either MQ or the OS.
Without more information I can't comment on whether migrating to 8.0.0.4 would resolve the issue, although 8.0.0.2 is quite an early V8 service level and hence I'd support a general recommendation to upgrade to 8.0.0.4. |
|
| Back to top |
|
|
|
|
